TECHNICAL FIELD

Various example embodiments relate to wireless communications.

BACKGROUND

Multiple universal subscriber identity module (MUS1M) mobile terminals support more than one universal subscriber identity module (US1M) card on the substantially same physical device. One or more of these US1M cards can be operational at any given time depending on the hardware and software capabilities of the MUS1M mobile terminal. When the network infrastructure is not aware that these multiple USIMs are co-located in the substantially same MUS1M device, it will be unable to optimize certain procedures (e.g. paging and quality of service (QoS)) and instead will treat at least one US1M card independently. Thus, there is a need for a solution to overcome said limitation.

BRIEF DESCRIPTION

According to an aspect, there is provided the subject matter of the independent claims. Embodiments are defined in the dependent claims. The scope of protection sought for various embodiments of the invention is set out by the independent claims.

The embodiments and features, if any, described in this specification that do not fall under the scope of the independent claims are to be interpreted as examples useful for understanding various embodiments of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

In the following, some example embodiments will be described with reference to the accompanying drawings, in which

Figure 1 illustrates an example of a communications system to which embodiments may be applied;

Figures 2A, 2B, 3A, 3B, 4A, 4B and 5 illustrate exemplary processes according to embodiments; and

Figures 6 to 8 illustrate exemplary apparatuses according to embodiments.

DETAILED DESCRIPTION OF SOME EMBODIMENTS

In the following, different exemplifying embodiments will be described using, as an example of an access architecture to which the embodiments may be applied, a radio access architecture based on long term evolution advanced (LTE Advanced, LTE-A) or new radio (NR, 5G), without restricting the embodiments to such an architecture, however. It is obvious for a person skilled in the art that the embodiments may also be applied to other kinds of communications networks having suitable means by adjusting parameters and procedures appropriately. Some examples of other options for suitable systems are the universal mobile telecommunications system (UMTS) radio access network (UTRAN or E-UTRAN), long term evolution (LTE, the substantially same as E-UTRA), wireless local area network (WLAN or WiFi), worldwide interoperability for microwave access (WiMAX), Bluetooth®, personal communications services (PCS), ZigBee®, wideband code division multiple access (WCDMA), systems using ultra-wideband (UWB) technology, sensor networks, mobile ad-hoc networks (MANETs) and Internet Protocol multimedia subsystems (IMS) or any combination thereof.

Figure 1 depicts examples of simplified system architectures showing some elements and functional entities, at least one being logical units, whose implementation may differ from what is shown. The connections shown in Figure 1 are logical connections; the actual physical connections maybe different. It is apparent to a person skilled in the art that the system typically comprises also other functions and structures than those shown in Figure 1.

The embodiments are not, however, restricted to the system given as an example but a person skilled in the art may apply the solution to other communication systems provided with necessary properties.

The example of Figure 1 shows a part of an exemplifying radio access network.

Figure 1 shows user devices 100 and 102 (equally called terminal devices) configured to be in a wireless connection on one or more communication channels in a cell with an access node (such as (e/g)NodeB) 104 providing the cell. The physical link from a user device to a (e/g)NodeB is called uplink or reverse link and the physical link from the (e/g)NodeB to the user device is called downlink or forward link. It should be appreciated that (e/g)NodeBs or their functionalities may be implemented by using any node, host, server or access point etc. entity suitable for such a usage.

A communications system typically comprises more than one (e/g)NodeB in which case the (e/g)NodeBs may also be configured to communicate with one another over links, wired or wireless, designed for the purpose. These links may be used for signalling purposes. The (e/g)NodeB is a computing device configured to control the radio resources of communication system it is coupled to. The NodeB may also be referred to as a base station, an access point or any other type of interfacing device including a relay station capable of operating in a wireless environment. The (e/g)NodeB includes or is coupled to transceivers. From the transceivers of the (e/g)NodeB, a connection is provided to an antenna unit that establishes bi-directional radio links to user devices. The antenna unit may comprise a plurality of antennas or antenna elements. The (e/g)NodeB is further connected to core network 110 (CN or next generation core NGC). Depending on the system, the counterpart on the CN side can be a serving gateway (S-GW, routing and forwarding user data packets), packet data network gateway (P-GW), for providing connectivity of user devices (UEs) to external packet data networks, or mobile management entity (MME), etc.

The user device (also called UE, user equipment, user terminal or terminal device) illustrates one type of an apparatus to which resources on the air interface are allocated and assigned, and thus any feature described herein with a user device may be implemented with a corresponding apparatus, such as a relay node. An example of such a relay node is a layer 3 relay (self-backhauling relay) towards the base station.

The user device typically refers to a portable computing device that includes wireless mobile communication devices operating with or without a subscriber identification module (SIM), including, but not limited to, the following types of devices: a mobile station (mobile phone), smartphone, personal digital assistant (PDA), handset, device using a wireless modem (alarm or measurement device, etc.), laptop and/or touch screen computer, tablet, game console, notebook, and multimedia device. It should be appreciated that a user device may also be a nearly exclusive uplink only device, of which an example is a camera or video camera loading images or video clips to a network. A user device may also be a device having capability to operate in Internet of Things (loT) network which is a scenario in which objects are provided with the ability to transfer data over a network without requiring human-to-human or human- to-computer interaction. The user device (or in some embodiments a layer 3 relay node) is configured to perform one or more of user equipment functionalities. The user device may also be called a subscriber unit, mobile station, remote terminal, access terminal, user terminal or user equipment (UE) just to mention but a few names or apparatuses. The user device may be a MUS1M user device.

Various techniques described herein may also be applied to a cyberphysical system (CPS) (a system of collaborating computational elements controlling physical entities). CPS may enable the implementation and exploitation of massive amounts of interconnected ICT devices (sensors, actuators, processors microcontrollers, etc.) embedded in physical objects at different locations. Mobile cyber physical systems, in which the physical system in question has inherent mobility, are a subcategory of cyber-physical systems. Examples of mobile physical systems include mobile robotics and electronics transported by humans or animals. It should be understood that, in Figure 1 user devices are depicted to include 2 antennas for the sake of clarity. The number of reception and/or transmission antennas may naturally vary according to a current implementation.

Additionally, although the apparatuses have been depicted as single entities, different units, processors and/or memory units (not all shown in Figure 1) may be implemented.

5G enables using multiple input - multiple output (MIMO) antennas, many more base stations or nodes than the LTE (a so-called small cell concept), including macro sites operating in co-operation with smaller stations and employing a variety of radio technologies depending on service needs, use cases and/or spectrum available. 5G mobile communications supports a wide range of use cases and related applications including video streaming, augmented reality, different ways of data sharing and various forms of machine type applications, including vehicular safety, different sensors and real-time control. 5G is expected to have multiple radio interfaces, namely below 6GHz, cmWave and mmWave, and also being integrable with existing legacy radio access technologies, such as the LTE. Integration with the LTE may be implemented, at least in the early phase, as a system, where macro coverage is provided by the LTE and 5G radio interface access comes from small cells by aggregation to the LTE. In other words, 5G is planned to support both inter-RAT operability (such as LTE-5G) and inter-Rl operability (inter-radio interface operability, such as below 6GHz - cmWave, below 6GHz - cmWave - mmWave) . One of the concepts considered to be used in 5G networks is network slicing in which multiple independent and dedicated virtual sub-networks (network instances) may be created within the substantially same infrastructure to run services that have different requirements on latency, reliability, throughput and mobility.

The current architecture in LTE networks is fully distributed in the radio and fully centralized in the core network. The low latency applications and services in 5G require to bring the content closer to the radio which leads to local break out and multi-access edge computing (MEC). 5G enables analytics and knowledge generation to occur at the source of the data. This approach requires leveraging resources that may not be continuously connected to a network such as laptops, smartphones, tablets and sensors. MEC provides a distributed computing environment for application and service hosting. It also has the ability to store and process content in close proximity to cellular subscribers for faster response time. Edge computing covers a wide range of technologies such as wireless sensor networks, mobile data acquisition, mobile signature analysis, cooperative distributed peer-to-peer ad hoc networking and processing also classifiable as local cloud/fog computing and grid/mesh computing, dew computing, mobile edge computing, cloudlet, distributed data storage and retrieval, autonomic self-healing networks, remote cloud services, augmented and virtual reality, data caching, Internet of Things (massive connectivity and/or latency critical), critical communications (autonomous vehicles, traffic safety, real-time analytics, time-critical control, healthcare applications).

The communication system is also able to communicate with other networks, such as a public switched telephone network or the Internet 112, or utilize services provided by them. The communication network may also be able to support the usage of cloud services, for example at least part of core network operations may be carried out as a cloud service (this is depicted in Figure 1 by "cloud" 114). The communication system may also comprise a central control entity, or a like, providing facilities for networks of different operators to cooperate for example in spectrum sharing.

Edge cloud may be brought into radio access network (RAN) by utilizing network function virtualization (NVF) and software defined networking (SDN). Using edge cloud may mean access node operations to be carried out, at least partly, in a server, host or node operationally coupled to a remote radio head or unit or base station comprising radio parts. It is also possible that node operations will be distributed among a plurality of servers, nodes or hosts. Application of cloudRAN architecture enables real time functions being carried out at the RAN side (in a distributed unit, DU 104) and non-real time functions being carried out in a centralized manner (in a centralized unit, CU 108).

It should also be understood that the distribution of labor between core network operations and base station operations may differ from that of the LTE or even be non-existent. Some other technology advancements probably to be used are Big Data and all-IP, which may change the way networks are being constructed and managed. 5G (or new radio, NR) networks are being designed to support multiple hierarchies, where MEC servers can be placed between the core and the base station or NodeB (gNB). It should be appreciated that MEC can be applied in 4G networks as well.

5G may also utilize satellite communication to enhance or complement the coverage of 5G service, for example by providing backhauling. Possible use cases are providing service continuity for machine-to-machine (M2M) or Internet of Things (loT) devices or for passengers on board of vehicles, or ensuring service availability for critical communications, and future railway/maritime/aeronautical communications. Satellite communication may utilise geostationary earth orbit (GEO) satellite systems, but also low earth orbit (LEO) satellite systems, in particular mega-constellations (systems in which hundreds of (nano) satellites are deployed). At least one satellite 106 in the mega-constellation may cover several satellite-enabled network entities that create on-ground cells. The on-ground cells may be created through an on-ground relay node 104 or by a gNB located on-ground or in a satellite.

5G may also utilize unlicensed spectrum, similar to WLAN or Multefire. 5G operating in unlicensed spectrum is also referred to as NR-U.

In some embodiments, the core network 110 may comprise at least an access and mobility management function (AMF), a policy control function (PCF) and a unified data repository (UDR). The AMF performs operations such as mobility management, registration management, connection management and UE based authentication. Based on a service requested by a user (i.e., a consumer), the AMF selects the respective session management function (SMF) for managing the user session context. The PCF is a function providing policy rules for application and service data flow detection, gating, QoS, and flow-based charging to the SMF and access and mobility management (AM) related policies to the AMF. The UDR is a repository for subscription data, application data and policy data connected via interfaces to, for example, the AMF and/or the PCF.

It is obvious for a person skilled in the art that the depicted system is only an example of a part of a radio access system and in practice, the system may comprise a plurality of (e/g)NodeBs, the user device may have an access to a plurality of radio cells and the system may comprise also other apparatuses, such as physical layer relay nodes or other network elements, etc. At least one of the (e/g)NodeBs may be a Home(e/g)NodeB. Additionally, in a geographical area of a radio communication system a plurality of different kinds of radio cells as well as a plurality of radio cells may be provided. Radio cells may be macro cells (or umbrella cells) which are large cells, usually having a diameter of up to tens of kilometers, or smaller cells such as micro-, femto- or picocells. The (e/g)NodeBs of Figure 1 may provide any kind of these cells. A cellular radio system may be implemented as a multilayer network including several kinds of cells. Typically, in multilayer networks, one access node provides one kind of a cell or cells, and thus a plurality of (e/g)NodeBs are needed to provide such a network structure.

For fulfilling the need for improving the deployment and performance of communication systems, the concept of "plug-and-play" (e/g)NodeBs has been introduced. Typically, a network which is able to use "plug-and-play" (e/g)NodeBs, includes, in addition to Home (e/g)NodeBs (H(e/g)nodeBs), a Home NodeB gateway, or HNB-GW (not shown in Figure 1). An HNB Gateway (HNB-GW), which is typically installed within an operator’s network may aggregate traffic from a large number of HNBs back to a core network.

A multiple universal subscriber identity module (MUS1M) mobile terminal (equally called a MUS1M terminal devices or MUS1M user equipment, MUS1M UE) is a mobile terminal which supports the use of multiple universal subscriber identity modules (USIMs) (equally called US1M cards) in parallel. One or more of these USIMs may be operational in an active and/or inactive Radio Resource Control (RRC) state at any given time depending on the hardware and software capabilities of the MUS1M mobile terminal. When the network infrastructure is not aware that these multiple USIMs are co-located in the substantially same MUS1M device, it will be unable to optimize certain procedures (e.g. paging and quality of service, QoS) and instead will treat at least one US1M independently. Specifically, the policy association for a terminal device in AMF may be carried out without considering the MUS1M capability as follows:

1. Terminal device registers with AMF.

2. On receiving the registration request, the AMF contacts PCF to fetch the Access and Mobility control policy including Service Area Restrictions, and/or a RAT Frequency Selection Priority (RFSP) Index, and/or Policy Control Request Trigger parameters.

3. AMF deploys the Access and Mobility control policy information if received which includes storing the Service Area Restrictions, provisioning the Service Area Restrictions to the terminal device and/ or provisioning the RFSP index and Service Area Restrictions to the NG-RAN.

Thus, there is a need for a solution for overcoming said limitation. Specifically, there is a need for a signalling mechanism which would enable the networks associated with at least one of the USIMs of the terminal device to become aware of the MUS1M priorities of the terminal device and to be able to use this information in their procedures. The MUS1M policy support would improve the decision-making on, e.g., QoS requirements and location mapping aspects of a MUS1M terminal device.

Figure 2A illustrates processes according to embodiments for providing information on USIMs of the MUS1M terminal device to an access node (and further to a core network). The process of Figure 2A may be carried out by a MUS1M terminal device in communication with an access node. The MUS1M terminal device may correspond to either of the terminal devices 100, 102 of Figure 1 and the access node may correspond to the access node 104 of Figure 1. The access node of Figure 2A may correspond to a distributed access node or specifically a distributed unit of a distributed access node. The MUS1M terminal device carrying out the process may comprise a plurality of USIMs. At least the elements illustrated in Figure 2A with dashed lines may correspond to features which are optional in view of the embodiments (i.e., optional in view of informing the access node of USIMs of the MUS1M terminal device). In Figure 2A, it may be initially assumed that one (or at least one) of the plurality of USIMs of the MUS1M terminal device is operational. Said one of the plurality of USIMs is called, in the following, a first US1M. Initially, the MUS1M terminal device is specifically operating, in block 201, in a radio resource control (RRC) idle or inactive state (or equally mode) using at least said first US1M. The RRC idle state is a non-connected state having the lowest energy consumption (that is, lowest energy consumption for the radio part of the terminal device) while the RRC inactive state exists between the RRC idle and RRC connected enabling suspension of a RRC connected session and subsequent efficient resuming of said session (i.e., moving back to the RRC connected mode). The RRC idle /inactive states may correspond specifically to 5G NR idle/inactive states.

Then, the MUS1M terminal device carries out (with an access node) a transition from said one of the RRC idle or the RRC inactive state to a RRC connected state (elements 202 to 211). Said transition may be carried out according to the conventional 5G NR state transition procedure, apart from the inclusion of a new flag in the RRC setup request (as will be described below in more detail).

First, the MUS1M terminal device transmits, in message 202, a physical random access channel (PRACH) preamble to the access node. The PRACH preamble transmission may be associated with a random access radio network temporary identifier (RA-RNT1). By transmitting the PRACH preamble (comprising the RA-RNT1), the MUS1M terminal device effectively initiates a session to the access node. The physical random access channel (PRACH) preamble may be transmitted over a random access channel (RACH). The physical random access channel preamble may be called "Msgl" of the RRC setup procedure (i.e., contention-based random access procedure).

In response to receiving the PRACH preamble from the terminal device in block 203, the access node transmits, in message 204, a random access response (RAR) to the MUS1M terminal device. The random access response may comprise the RA- RNT1, a (temporary) cell radio network temporary identifier (C-RNT1), timing alignment information and/or initial uplink grant information (for scheduling the transmission of message 206). The random access response may be transmitted over a downlink shared channel (DL-SCH). The random access response may be called "Msg2" of the RRC setup procedure.

In response to receiving the random access response in block 205, the MUS1M terminal device transmits, in message 206, a RRC setup request (e.g., a "RRCSetupRequest" message) to the access node. The RRC setup request comprises a flag having a value indicating presence of the plurality of USIMs in the MUS1M terminal device. In other words, said flag indicates whether or not the terminal device is a MUS1M terminal device with priority (here, it is assumed that said flag has value indicating that the terminal device in question is a MUSIM terminal device). Said flag may correspond to a single bit having a value (e.g., 1) indicative of the presence of the plurality of USIMs in the MUSIM terminal device. Said flag may be equally called a MUSIM priority flag as it indicates that the terminal device in question a MUSIM terminal device with priority. Additionally, the RRC setup request may comprise, for example, information on the identity of the terminal device and information on an establishment cause. The RRC setup request may be called "Msg3" of the RRC setup procedure.

In some alternative embodiments, said flag may be transmitted using a dedicated medium access control protocol data unit (MAC PDU), instead of including it in the RRC setup request.

In response to receiving the RRC setup request comprising said flag from the MUSIM terminal device in block 207, the access node transmits, in message 208, a RRC setup message (e.g., a "RRCSetup" message) to the MUSIM terminal device. The RRC setup message may comprise information on radio bearer configuration and cell group configuration. The RRC setup message may be called "Msg4" of the RRC setup procedure. The actions pertaining to elements 208 to 211 may be carried out according to conventional 5G NR RRC setup procedure, that is, the inclusion of the flag may not have any effect on said actions.

In response to receiving the RRC setup message from the access node in block 209, the MUSIM terminal device configures, in block 209, itself according to the RRC setup message and transmits, in message 210, a RRC setup complete message to the access node for informing the terminal device of the successful completion of the RRC setup. The RRC setup complete message may be called "Msg5" of the RRC setup procedure. The access node receives, in block 211, the RRC setup complete message. In some embodiments, element 210, 211 may be omitted.

Upon completion of the RRC setup procedure in elements 202 to 211, the MUSIM terminal device operates, in block 212, in the RRC connected state using the first US1M (or at least the first US1M). During the operation, the access node determines that further information on the plurality of USIMs (or, specifically, of one or more USIMs other than the first US1M) is needed by it. Consequently, the access node transmits, in message 213, a request for MUSIM priority information on the MUSIM terminal device (or specifically on one or more USIMs of the plurality of USIMs of the MUSIM terminal device) to the MUSIM terminal device. Specifically, the MUSIM priority information may comprise information (or identification information) on one or more USIMs of the plurality of USIMs of the MUSIM terminal device which are to be prioritized in policy association/handling processes performed by one or more core network nodes towards the MUSIM terminal device. In the following (and specifically in the associated Figures), the MUSIM priority information on one or more USIMs of the plurality of USIMs is sometimes called simply MUSIM info with priority. The transmission in message 213 may be based on the value of said flag in that the access node transmits said request for MUSIM priority information if the terminal device in question comprises more than one US1M. Said one or more USIMs may comprise at least one US1M other than the first US1M. The MUSIM priority information on the first US1M may be known to the access node (acquired, e.g., during the RRC setup procedure). The MUSIM priority information on the first US1M may be configurable by a user of the MUSIM terminal device and/or it may have a definition which varies with time. In some embodiments, the one or more USIMs comprise said plurality of US1M of the MUSIM terminal device.

The request for MUSIM priority information may be specifically a terminal device capability enquiry (i.e., a "UECapabilityEnquiry" message). Some changes may be needed to the conventional terminal device capability enquiry to enable indicating that information on the one or more USIMs other than the first US1M is requested. In some embodiments, a new field may be added into the UE- CapabilityRequestFilterCommon information element (IE) for this purpose. This may be implemented, for example, as follows (bold line indicating MUSIM functionalities):

-ASN1START

- TAG-UECAPABILITYENQUIRY-START UECapabilityEnquiry ::= SEQUENCE { rrc-Transactionldentifier RRC-Transactionldentifier, criticalExtensions CHOICE { ueCapability Enquiry UECapabilityEnquiry-IEs, criticalExtensionsFuture SEQUENCE {} } } UECapabilityEnquiry-IEs ::= SEQUENCE { ue-CapabilityRAT-RequestList UE-CapabilityRAT-RequestList, lateNonCriticalExtension OCTET STRING OPTIONAL, ue-CapabilityEnquiry Ext OCTET STRING (CONTAINING UECapabilityEnquiry-vl560-IEs) OPTIONAL } UECapabilityEnquiry-vl560-IEs ::= SEQUENCE { capabilityRequestFilterCommon UE-CapabilityRequestFilterCommon OPTIONAL, - Need N nonCriticalExtension SEQUENCE}} OPTIONAL

}

- TAG-UECAPABILITYENQUIRY-STOP

—ASN1STOP

The "UE-CapabilityRequestFilterCommon" information element which is used, in general, to request filtered terminal device capabilities, may be specifically defined, according to embodiments, as follows (bold line indicating MUSIM functionalities):

UE-CapabilityRequestFilterCommon ::= SEQUENCE { mrdc-Request SEQUENCE { omitEN-DC ENUMERATED {true} OPTIONAL, - Need N includeNR-DC ENUMERATED {true} OPTIONAL, - Need N includeNE-DC ENUMERATED {true} OPTIONAL, - Need N } OPTIONAL, - Need N MUSIMPriority ENUMERATED true} OPTIONAL [■■■] }

Here, the last field "MUSIMPriority" has been added to indicate whether the MUS1M priority information is requested from the MUS1M terminal device.

In response to receiving the request for MUS1M priority information on the one or more USIMs from the access node while the RRC connected state is active at least for the first US1M in block 214, the MUS1M terminal device transmits, in message 215, a response comprising the MUS1M priority information on said one or more USIMs. The MUS1M priority information may comprise, for at least one of the one or more USIMs, (complete) temporary mobile subscriber identity (TMS1) information or (identification) information on a public land mobile network of the US1M, a cell of the US1M, a radio channel associated with the US1M in said cell and/or a location of the US1M (i.e., a location of the MUS1M terminal device). The (complete) temporary mobile subscriber identity information or said (identification) information may be defined separately per US1M. Specifically, in the latter case, the MUS1M priority information may comprise at least a public land mobile network (PLMN) identifier (PLMNld), a cell identifier (Cellld), a cell radio network temporary identifier (C-RNT1) and information on a location of the US1M, for example. The latter option provides the advantage of increased data privacy (i.e., reduced risk of compromising privacy of data of a user). In such a case, the access node and/or core network node(s) may indirectly derive the (complete) temporary mobile subscriber identity information based on the provided "incomplete" information (i.e., based on PLMNld, Cellld, C-RNT1 and information on the location of the MUS1M terminal device). Additionally or alternatively, the MUS1M priority information may comprise, for at least one of the one or more USIMs (or for at least some of them), a subscription permanent identifier (SUP1) for a US1M. Additionally or alternatively, the MUS1M priority information may comprise, for at least one of the one or more USIMs (or for at least some of them), an autonomously selected identifier for a US1M (i.e., an identifier for the US1M defined or selected by the MUS1M terminal device). For example, the MUS1M terminal device may select a random value (different from the temporary mobile subscriber identity) as said autonomously selected identifier.

The response (message 215) may be specifically a terminal device capability information message (i.e., a "UECapabilitylnformation" message). In other words, the terminal device may set MUS1M as one of its capabilities with priority in a terminal device capability information message. Similar to as discussed for the terminal device capability enquiry, some changes may be needed to the conventional terminal device capability information message to enable inclusion of (priority) information on the one or more USIMs. In some embodiments, a new container may be added into UE-CapabilityRAT-ContainerList information element. This may be implemented, for example, as follows (see bold lines):

- ASN1START

- TAG-UECAP ABILITYINFORMATION-START UECapabilitylnformation ::= SEQUENCE { rrc-Transactionldentifier RRC-Transactionldentifier, criticalExtensions CHOICE { ueCapabilitylnformation UECapabilitylnformation-IEs, criticalExtensionsFuture SEQUENCE {} } }

UECapabilitylnformation-IEs ::= SEQUENCE { ue-CapabilityRAT-ContainerList UE-CapabilityRAT-ContainerList OPTIONAL, //Supports MUSIM priority lateNonCriticalExtension OCTET STRING OPTIONAL, nonCriticalExtension SEQUENCER OPTIONAL }

- TAG-UECAP ABILITYINFORMATION-STOP

— ASN1STOP

The "UE-CapabilityRAT-ContainerList" information element may be specifically defined, according to embodiments, as follows:

UE-CapabilityRAT-ContainerList ::=SEQUENCE (SIZE (0..maxRAT-CapabilityContainers)J OF UE- CapabilityRAT-Container

UE-CapabilityRAT-Container ::= SEQUENCE { rat- Type RAT-Type, ue-CapabilityRAT-Container OCTET STRING, ng-5G-S- TMSI -List SEQUENCE (SIZE (l..maxNrofS- TMSI) ) OF S- TMSI OPTIONAL }

Here, the last field "ng-5G-S-TMSl -List" has been added to include the MUSIM priority information.

The access node receives, in block 216, the response to the request for MUSIM priority information on the one or more USIMs from the terminal device. In response to the receiving in block 216, the access node may transmit or forward, in block 216, the MUSIM priority information (or a part thereof) from the terminal device to a network function service consumer node (and/or other core network node) of a core network for enabling MUSIM-specific optimization. The network function service consumer node may correspond to an access & mobility management function (AMF). The MUSIM-specific optimization may relate to, for example, MUSIM aware QoS handling, location-based services and/or billing. The MUSIM priority information at least for the first US1M (i.e., the active US1M) as well as at least one other US1M may be transmitted in block 216. Figure 2B illustrates an alternative set of processes according to embodiments for providing information on USIMs of the MUS1M terminal device to an access node (and further to a core network) (i.e., for informing the network about the terminal device being a MUS1M terminal device with priority). The process of Figure 2B may be carried out by a MUS1M terminal device in communication with an access node. The MUS1M terminal device may correspond to either of the terminal devices 100, 102 of Figure 1 and the access node may correspond to the access node 104 of Figure 1. The access node of Figure 3B may correspond to a distributed access node or specifically a distributed unit of a distributed access node. The MUS1M terminal device carrying out the process may comprise a plurality of USIMs. At least the elements illustrated in Figure 2B with dashed lines may correspond to features which are optional in view of the embodiments (i.e., optional in view of informing the access node of USIMs of the MUS1M terminal device).

Similar to Figure 2A, Figure 2B illustrates a procedure for transitioning between a RRC idle or inactive state of the MUS1M terminal device and an RRC connected state of the MUS1M terminal device and using said processes (or message transmitted as a part of said transition procedure) for communicating information on the MUS1M nature of the MUS1M terminal device to the access node. Thus, the processes illustrated in Figure 2B correspond to a large extent to the processes of Figure 2A and the above discussion applies, mutatis mutandis, to Figure 2B, unless otherwise stated. Namely, the initial actions pertaining to elements 221 to 225 may correspond fully to actions discussed in connection with elements 201 to 205 of Figure 2A.

However, instead of including a flag indicative of MUS1M nature of the MUS1M terminal device in the RRC setup request as in Figure 2A, the MUS1M terminal device in Figure 2B transmits, in message 226, a RRC setup request comprising MUS1M priority information on one or more USIMs of the plurality of USIMs to the access node. Here, the one or more USIMs may comprise at least one US1M other than the first US1M. Thus, instead of performing the communication of the MUS1M priority information in two phases (transmitting the flag and thereafter transmitting MUS1M priority information upon receiving a request), the MUS1M priority information is communicated from the terminal device to the access node in a single phase (i.e., message 226). Correspondingly, the processes for requesting MUS1M priority information described in connection with elements 212 to 215 are not included in Figure 2B. Instead, the access node may transmit or forward the MUS1M priority information to the core network (e.g., to an AMF or to other network function service consumer node) directly upon receiving the RRC setup request. In Figure 2B, this forwarding is performed in block 213 following the reception in block 231 of a RRC setup complete message (message 230) though, in other embodiments, said forwarding may be carried out even before that.

In some embodiments, the RRC setup request comprising the MUSIM priority information on one or more USIMs (other than the first USIM directly involved in the RRC setup procedure), i.e., message 226, may be have the following form (MUSIM-related line emphasized in bold):

-ASN1START

- TAG-RRCSETUPREQUEST-START RRCSetupRequest ::= SEQUENCE { rrcSetupRequest RRCSetupRequest-IEs }

RRCSetupRequest-IEs ::= SEQUENCE { ue-Iden tity InitialUE-Iden tity, establishmentcause Establishmentcause, spare BIT STRING (SIZE (1)) }

InitialUE-Identity ::= CHOICE { ng-5G-S-TMSI-Partl BIT STRING (SIZE (39)), randomValue BIT STRING (SIZE (39)) //with MUSIM priority information }

Establishmentcause ::= ENUMERATED { emergency, highPriorityAccess, mt-Access, mo-Signalling, mo-Data, mo-VoiceCall, mo-VideoCall, mo-SMS, mps-PriorityAccess, mcs-PriorityAccess, spare6, spareS, spared, spare3, spare2, sparel }

- TAG-RRCSETUPREQUEST-STOP

—ASN1STOP

The processes relating to elements 227 to 230, 232 in Figure 2B may correspond (fully) to processes described in connection with element 207 to 210, 212 of Figure 2A and are thus not described here (again) for brevity.

In some alternative embodiments, said MUSIM priority information on the one or more USIMs may be transmitted using a dedicated medium access control protocol data unit (MAC PDU), instead of including it in the RRC setup request.

In an embodiment, the sequence in which the MUSIM priority information on the one or more USIMs or specifically the temporary mobile subscriber identity (TMS1) information of the one or more USIMs is listed (in "ng-5G-S-TMSl -List" comprised in a RRC setup complete message 230) implicitly defines the priority order of the one or more USIMs. The RRC setup complete message may be defined as follows (added feature indicated in bold):

-ASN1START

- TAG-RRCSETUPCOMPLETE-START

RRCSetupComplete ::= SEQUENCE { rrc-Transaction Identifier RRC-Transactionldentifier, criticalExtensions CHOICE { rrcSetupComplete RRCSetupComplete-IEs, criticalExtensionsFuture SEQUENCE {} }

}

RRCSetupComplete-IEs ::= SEQUENCE { selectedPLMN-Identity INTEGER (l..maxPLMN}, registeredAMF RegisteredAMF OPTIONAL, guami-Type ENUMERATED {native, mapped} OPTIONAL, s-NSSAI-List SEQUENCE (SIZE (E.maxNrofS-NSSAI}} OFS-NSSAI OPTIONAL, dedicatedNAS-Message DedicatedNAS-Message, ng-5G-S- TMSI -List SEQUENCE (SIZE (L.maxNrofS- TMSI) ) OF S- TMSI OPTIONAL, ng-5G-S-TMSI-Value CHOICE { ng-5G-S-TMSI NG-5G-S-TMSI, ng-5G-S-TMSI-Part2 BIT STRING (SIZE (9}}

} OPTIONAL, lateNonCriticalExtension OCTET STRING OPTIONAL, nonCriticalExtension SEQUENCE}} OPTIONAL }

RegisteredAMF ::= SEQUENCE { pimn-Identity PLMN-Identity OPTIONAL, amf-Iden tifier AMF-Iden tifier }

- TAG-RRCSETUPCOMPLETE-STOP

The information on the priority order may be forwarded also to the core network in block 231 and may be subsequently employed in MUSIM-specific optimization procedures.

Figure 3A illustrates another set of processes according to embodiments for providing information on USIMs of the MUS1M terminal device to an access node (and further to a core network). The process of Figure 3A may be carried out by a MUSIM terminal device in communication with an access node. The MUSIM terminal device may correspond to either of the terminal devices 100, 102 of Figure 1 and the access node may correspond to the access node 104 of Figure 1. The access node of Figure 3A may correspond to a distributed access node or specifically a distributed unit of a distributed access node. The MUSIM terminal device carrying out the process may comprise a plurality of USIMs. At least the elements illustrated in Figure 3A with dashed lines may correspond to features which are optional in view of the embodiments (i.e., optional in view of informing the access node of USIMs of the MUSIM terminal device).

Similar to Figure 2A, in Figure 3A, it may be initially assumed that one (or at least one) of the plurality of USIMs of the MUSIM terminal device is operational using a RRC idle or inactive state. Said one of the plurality of USIMs is called, in the following, a first US1M. In other words, the MUSIM terminal device is initially operating, in block 301, in a RRC idle or inactive state (or equally mode) using at least said first US1M.

While Figure 2A illustrates the so-called four-step contention-based random access procedure (or five-step contention-based random access procedure if message 210 is included), Figure 3A illustrates a so-called two-step contention-based random access procedure. In the two-step contention-based random access procedure, the first and third messages (Msg 1 & Msg 3) of the four-step contention-based random access procedure are combined into a single message (so-called MsgA). Similarly, the second and fourth messages (Msg 2 & Msg 4) of the four-step contention-based random access procedure are also combined into a single message (so-called MsgB).

Correspondingly, in Figure 3A, the MUSIM terminal device transmits a PRACH preamble and a RRC setup request comprising a flag indicating presence of the plurality of USIMs in the MUSIM terminal device as a single message 302 to an access node. In response to receiving the PRACH preamble and the RRC setup request in block 303, the access node transmits, in message 304, a random access response and a RRC setup message in as a single message 304 to the MUSIM terminal device. In response to receiving the random access response and the RRC setup message in block 305, the MUSIM terminal device configures, in block 305, itself according to the RRC setup message. The PRACH preamble, the RRC setup request, the random access response and the RRC setup message may be defined as described in connection with Figure 2A.

In some alternative embodiments, said flag may be transmitted using a dedicated medium access control protocol data unit (MAC PDU), instead of including it in the RRC setup request. Actions pertaining to elements 308 to 310 may correspond fully to actions discussed in relation to elements 213 to 216 of Figure 2A and are thus not discussed here for brevity.

Figure 3B illustrates another set of processes according to embodiments for providing (priority) information on USIMs of the MUS1M terminal device to an access node (and further to a core network) in connection with a two-step random access procedure. The process of Figure 3B maybe carried out by a MUS1M terminal device in communication with an access node. The MUS1M terminal device may correspond to either of the terminal devices 100, 102 of Figure 1 and the access node may correspond to the access node 104 of Figure 1. The access node of Figure 3B may correspond to a distributed access node or specifically a distributed unit of a distributed access node. The MUS1M terminal device carrying out the process may comprise a plurality of USIMs. At least the elements illustrated in Figure 3B with dashed lines may correspond to features which are optional in view of the embodiments (i.e., optional in view of informing the access node of USIMs of the MUS1M terminal device).

Similar to Figure 3A, Figure 3B illustrates a two-step contention-based random access procedure where the first and third messages (Msg 1 & Msg 3) of the four-step contention-based random access procedure are combined into a single message (MsgA) and the second and fourth messages (Msg 2 & Msg 4) of the four-step contention-based random access procedure are also combined into a single message (MsgB). In general, the discussion provided in connection with Figure 3A applies, mutatis mutandis, to Figure 3B, unless otherwise stated. Specifically, the processes relating to elements 321, 324, 325, 326 in Figure 3B may correspond (fully) to processes described in connection with element 301, 304, 305, 306 of Figure 3A and are thus not described here (again) for brevity.

The difference between Figure 3B and Figure 3A lies in that Figure 3B is a single-phase procedure for communicating the MUS1M priority information, similar to Figure 2B. Thus, the RRC setup request, transmitted as a part of message 322 (MsgA) to the access node, comprises the MUS1M priority information on one or more USIMs of the plurality of USIMs of the MUS1M terminal device, instead of including merely a flag. Again, said one or more USIMs may comprise at least one US1M other than the first US1M. The MUS1M priority information may be defined as discussed in connection with above embodiments. Correspondingly, the processes for requesting MUS1M priority information described in connection with elements 307 to 309 are not included in Figure 3B. Instead, the access node may transmit or forward the MUS1M priority information to the core network (e.g., to an AMF or to other network function service consumer node) directly upon receiving the RRC setup request (i.e., message 302). In Figure 3B, this forwarding is performed in block 323 directly following the reception in block 323 of the message comprising the PRACH preamble and the RRC setup request (message 322) though, in other embodiments, said forwarding may be carried out later than that.

It should be noted that random access procedures illustrated in Figures 2A, 2B, 3A and 3B may also comprise one or more further actions not illustrated in Figures 2A, 2B, 3A and 3B. Namely, Figures 2A, 2B, 3A and 3B illustrate such actions which may be considered pertinent to the embodiments. Said one or more further actions may relate, for example, to communication and configuration between the access node and one or more core network nodes.

In embodiments discussed in connection with Figures 2A and 3A, the flag indicating that the terminal device is a MUS1M terminal device was communicated to the access node in a RRC setup request transmitted as a part of an initial access procedure (i.e., a procedure for transitioning the MUS1M terminal device from an idle or inactive state to a RRC connected state). However, in other embodiments, said flag may be transmitted as a part of another procedure. Specifically, Figure 4A illustrates one example of such an alternative procedure, namely a procedure of performing initial registration of the terminal device to a mobile network. The process of Figure 4A may be carried out by a MUS1M terminal device in communication with an access node. The MUS1M terminal device may correspond to either of the terminal devices 100, 102 of Figure 1 and the access node may correspond to the access node 104 of Figure 1. The access node of Figure 4A may correspond to a distributed access node or specifically a distributed unit of a distributed access node. The MUS1M terminal device carrying out the process may comprise a plurality of USIMs. At least the elements illustrated in Figure 4A with dashed lines may correspond to features which are optional in view of the embodiments (i.e., optional in view of informing the access node of USIMs of the MUS1M terminal device).

Referring to Figure 4A, the MUS1M terminal device may initially operate, in block 401, with a first universal subscriber identity module (US1M) of a plurality of USIMs of the MUS1M terminal device in an active state. The MUS1M terminal may operate specifically in a RRC connected state using said first US1M. The terminal device may have, for example, carried out an initial access procedure as discussed in connection with elements 201 to 211 of Figure 2A or elements 301 to 306 of Figure 3A with or without including the flag in the RRC setup request (i.e., in message 206 or 302).

The registration of the MUS1M terminal device to a mobile network is initiated by the MUS1M terminal device transmitting, in message 402, a RRC registration request to an access node. The RRC registration request may comprise, for example, information on registration type, 5G global unique temporary identifier (5G- GUT1), last visited registered tracking area identity (TAI), requested Network Slice Selection Assistance Information (NSSAI), information on terminal device capability and/or a list of PDU sessions. In some embodiments, the RRC registration request may be transmitted as a part of the RRC setup complete message (i.e., message 210) as discussed in connection with Figure 2A.

In response to receiving the RRC registration request block 403, the MUS1M terminal device selects, in block 403, an access and mobility management function (AMF) for this session. The access node may also allocate an identifier (namely, a "RAN UE NGAP ID") for use for addressing the terminal device context on the access node.

The access node transmits, in message 404, a next generation application protocol (NGAP) registration request to the selected AMF. The NGAP registration request may comprise the RRC registration request received from the terminal device. The NGAP registration request may also comprise, for example, the RAN UE NGAP ID and information on establishment cause. In response to receiving the NGAP registration request in block 405, the AMF transmits, in message 406, a NGAP identity request to the access node. The AMF may also obtain at this point the terminal device context from the old AMF of the terminal device (not shown in Figure 4A).

In response to receiving the NGAP identity request in block 407, the access node transmits, in message 408, a RRC identity request (corresponding to the NGAP identity request) to the terminal device. The NGAP and RRC identity request may specifically be requesting a subscription concealed identifier (SUC1) of the first US1M (i.e., an active US1M of the MUS1M terminal device).

In response to receiving the RRC identity request from the access node in block 409, the MUS1M terminal device transmits, in message 410, a RRC identity response to the access node. The RRC identity response may comprise a SUC1 of the terminal device derived from a home PLMN public key of the first US1M.

At least one of the RRC registration request (i.e., message 402) and the RRC identity response (i.e., message 410) comprises a flag having a value indicating presence of the plurality of USIMs in the MUS1M terminal device (i.e., indicating that the MUS1M terminal device is, in fact, a MUS1M terminal device). The flag may be defined as described in relation to Figure 2A.

The following registration steps (i.e., elements 411 to 410) may correspond to conventional registration procedure. Namely, in response to receiving the RRC identity response in block 411, the access node transmits, in message 412, a NGAP identity response (corresponding to the RRC identity response) to the AMF. The AMF receives the NGAP identity response in block 413. Then, a security and authentication procedure may be carried out, in block 414, across the MUS1M terminal device, radio access network, the AMF, an authentication server function (AUSF) and a unified data management (UDM). Details of this procedure are not relevant in view of the embodiments and are thus not discussed here.

Following the performing of the security and authentication procedure, the AMF transmits, in message 415, an initial context setup request to the access node. The message 415 may specifically comprise a registration accept non-access stratum message. The message may carry one or more PDU Session setup requests and an uplink TE1D for at least one PDU session. In response to receiving the initial context setup request from the AMF in block 416, the access node configures, in block 416, itself and the MUS1M terminal device according to the initial context setup request. The configuration in block 416 may comprise carrying out, between the access node and the MUS1M terminal device, an access stratum (AS) security procedure and/or RRC reconfiguration procedure for setting up radio bearers, setup a secondary cell and initiate terminal device measurements.

Then, the access node transmits, in message 417, a response to the initial context setup request. The message 417 indicates to the AMF that the PDU session(s) were set up successfully. The message 417 may carry the downlink tunnel endpoint identifier (TE1D) that should be used (specified per PDU session). The AMF receives, in block 418, the response to the initial context setup request completing the registration procedure of the MUS1M terminal device to the mobile network. Thereafter, the terminal device may start transmitting data to the access node (not shown in Figure 4A).

Only information regarding the other (i.e., non-active) USIMs of the MUS1M terminal device communicated to the access node and the core network during the registration procedure was the flag indicating that the terminal device is a MUS1M terminal device. Therefore, similar to the embodiments discussed in relation to Figures 2A and 3A, further information on the other USIMs may be needed following the registration. The procedure for acquiring such information may be similar to the process discussed in connection with elements 213 to 216 of Figure 2A and elements 307 to 310 Figure 3A. Namely, the access node transmits, in message 419, based on the value of the flag, a request for MUS1M priority information on one or more USIMs of the plurality of USIMs to the MUS1M terminal device, where the one or more USIMs may comprise at least one US1M other than the first US1M being currently active (specifically operating in the RRC connected state). In response to receiving the request for MUS1M priority information on the one or more USIMs of the plurality of USIMs from the access node in block 420, the MUS1M terminal device transmits, in message 421, MUS1M priority information on the one or more USIMs (and optionally, on the first US1M) to the access node which, upon receiving the MUS1M priority information in block 422, transmits or forwards, in message 423, said MUS1M priority information to a network function service consumer node (in Figure 4A, being specifically the AMF) of a core network of the mobile network for enabling MUSIM-specific network policy optimization.

In some embodiments, the access node, upon being informed that the terminal device is a MUS1M terminal device (i.e., upon receiving the corresponding flag) according to any of the above embodiments, may configure the terminal device to comply with a special regime which is more friendly towards coexistence with other networks. Namely, the MUS1M terminal device may be configured, according to said special regime, to generate less traffic and less interference towards other networks by having less frequent periodic reports towards home network. Alternatively, the terminal device may be configured, according to said special regime, with more frequent options (or opportunities) for accessing home networks, for example, by scheduling requests for network resources.

Figure 4B illustrates another example of a procedure of transmitting MUS1M priority information to the access node in connection with an initial registration of the terminal device to a mobile network. The process of Figure 4B may be carried out by a MUS1M terminal device in communication with an access node. The MUS1M terminal device may correspond to either of the terminal devices 100, 102 of Figure 1 and the access node may correspond to the access node 104 of Figure 1. The access node of Figure 4B may correspond to a distributed access node or specifically a distributed unit of a distributed access node. The MUS1M terminal device carrying out the process may comprise a plurality of USIMs. At least the elements illustrated in Figure 4B with dashed lines may correspond to features are optional in view of the embodiments (i.e., optional in view of informing the access node of USIMs of the MUS1M terminal device).

Similar to Figures 2B and 3B, Figure 4B illustrates a single phase procedure for providing MUS1M priority information to the access node, as opposed to a two- phase procedure where a flag is initially transmitted as in Figure 5A. Specifically, Figure 4B illustrates effectively a one-phase version of the two-phase procedure of Figure 4A (the relationship between procedures of Figures 4A and 4B being analogous with the relationship between procedures of Figures 2A and 2B and procedures of Figure 3A and 3B). In general, Figure 4B corresponds to a large extent to Figure 4A and thus the discussion provided in connection with Figure 4A applies, mutatis mutandis, to Figure 4B, unless otherwise stated. Specifically, elements 431, 433 to 448, 449 of Figure 4B may correspond fully to elements 401, 403 to 418, 423 of Figure 4A, respectively.

The difference between Figure 4B and Figure 4A lies in that, in Figure 4B, the RRC registration request (i.e., message 432) transmitted to the access node comprises the MUS1M priority information on one or more USIMs of the plurality of USIMs of the MUS1M terminal device (with said on one or more USIMs comprising at least one USIM other than the first USIM being currently active). The one or more USIMs for which MUS1M priority information is transmitted may comprise, in some embodiments, the plurality of USIMs of the MUS1M terminal device. As the MUS1M priority information is provided directly (in a single step) to the access node, no flag needs to be included in the RRC registration request or the RRC identity response and no separate request for MUS1M priority information needs to be transmitted from the access node to the MUS1M terminal device, in contrast to Figure 4A. Correspondingly, the elements 419 to 421 of Figure 4A are not included in Figure 4B. Specifically, the RRC registration request may comprise a set of parameters indicating the radio capabilities and/or mobility management (MM) capabilities of the (MUS1M) terminal device. Said set of parameters may extended or modified to comprise information on the MUS1M support provided by the MUS1M terminal device (e.g., at least said flag indicating the presence of the plurality of USIMs of the MUS1M terminal device) and information on the one or more USIMs (namely, at least on at least one non-active USIM). (e.g. its SUP1, cell ID for its camping/serving cell if available and/or any other data discussed above as being comprised in the MUS1M priority information).

Figure 5 illustrates processes according to embodiments for performing MUS1M aware policy handling. The process of Figure 5 may be carried out by an AMF, a policy control function (PCF) (or a visited PCF, V-PCF) and a unified data repository (UDR). The AMF, the PCF and the UDR may be comprised in the core network 110 of Figure 1. In some embodiments, the functions carried out by the AMF may be performed by another NF service consumer node of the core network, instead.

The process of Figure 5 may be initiated by the AMF receiving, in block 501, MUS1M priority information on a plurality of USIMs of a MUS1M terminal device (i.e., MUS1M information) from an access node. The plurality of USIMs may comprise all or some of the USIMs of the MUS1M terminal device. Said MUS1M priority information may have been derived and transmitted to the AMF as described in connection with any of Figures 2A, 2B, 3A, 3B, 4A and 4B. The MUS1M priority information may be received, e.g., in a registration request.

Based on local policy, the AMF may select to contact the (V-)PCF to create the policy association with the (V-)PCF and to retrieve an access and mobility control policy. Thus, the AMF transmits, in message 502, a request for creating a MUSIM-aware access and mobility control policy to the PCF. Said request may comprise said MUS1M priority information on the plurality of USIMs of the MUS1M terminal device.

The request in message 502 may be specifically a Npcf_AMPolicyControl_Create Request (i.e., the AMF may invoke the Npcf_AMPolicyControl_Create service operation in transmitting message 502). The Npcf_AMPolicyControl_Create Request maybe specifically an HTTP POST request. Said HTTP POST request may have "{apiRoot}/npcf-am-policy-control/vl/policies" as a uniform resource identifier (URI) and the PolicyAssociationRequest data structure as a request body comprising said MUSIM priority information on the USIMs of the MUSIM terminal device. The HTTP POST requests with "{apiRoot}/npcf-am-policy- control/vl/policies" as the URI are used, in general, for creating new individual AM policies. The {apiRoot} may be defined as a concatenation of the following parts:

- scheme ("http" or "https")

- the fixed string

- authority (host and optional port) - an optional deployment-specific string (API prefix) that starts with a character.

API (or api) refers here to an application programming interface, "npcf-am-policy- control" and "vl" correspond, respectively, to a name of the API, a version of the API while "policies" is an API specific string. The PolicyAssociationRequest data structure may comprise, in addition to the aforementioned MUSIM priority information, one or more of the data types as specified in the table below.

Specifically, the PolicyAssociationRequest may have the following form (added MUSIM-specific field emphasized in bold):

PolicyAssociationRequest: type: object properties: notificationllri:

$ref: 'TS29571_CommonData.yaml#/components/schemas/Uri' altNotif!pv4Addrs: type: array items:

$ref: 'TS29571_CommonData.yaml#/components/schemas/Ipv4Addr' mini terns: 1 description: Alternate or backup IPv4 Address(es) where to send Notifications. altNotiflpv6Addrs: type: array items:

$ref: 'TS29571_CommonData.yaml#/components/schemas/Ipv6Addr' mini terns: 1 description: Alternate or backup IPv6 Address(es) where to send Notifications. supi:

$ref: 'TS29571_CommonData.yaml#/components/schemas/Supi' gpsi:

$ref: 'TS29571_CommonData.yaml#/components/schemas/Gpsi' accessType:

$ref: 'TS29571_CommonData.yaml#/components/schemas/AccessType' pei:

$ref: 'TS29571_CommonData.yaml#/components/schemas/Pei' userLoc:

$ref: 'TS29571_CommonData.yaml#/components/schemas/UserLocation' timeZone:

$ref: 'TS29571_CommonData.yaml#/components/schemas/TimeZone' servingPlmn:

$ref: 'TS29571_CommonData.yaml#/components/schemas/NetworkId' ratType:

$ref: 'TS29571_CommonData.yaml#/components/schemas/RatType' group I ds: type: array items:

$ref: 'TS29571_CommonData.yaml#/components/schemas/GroupId' mini terns: 1 servAreaRes:

$ref: 'TS29571_CommonData.yaml#/components/schemas/ServiceAreaRest riction' rfsp:

$ref: 'TS29571_CommonData.yaml#/components/schemas/RfspIndex' guami:

$ref: 'TS29571_CommonData.yaml#/components/schemas/Guami'

MUSIMInfo: type: string description: MUSIM based information availability in AMF to support policy association serviveName: type: string description: If the NF service consumer is an AMF, it should provide the name of a service produced by the AMF that makes use of information received within the

Npcf AMPolicyControl UpdateNotify service operation. It corresponds to serviceName in the main body. traceReq:

$ref: 'TS29571_CommonData.yaml#/components/schemas/TraceData ' suppFeat:

$ref: 'TS29571_CommonData.yaml#/components/schemas/SupportedFeatur es' required:

- notificationUri

In response to receiving the request in block 503, the PCF carries out a policy decision procedure illustrated with elements 504 to 511.

First, assuming that the PCF does not have subscription data (or specifically policy control subscription data), it invokes the Nudr_DataRepository_Query service operation to the UDR by transmitting, in message 504, a request (or a query) for the subscription data (namely, a Nudr_DataRepository_Query request) to the UDR. Specifically, the Nudr_DataRepository_Query request may correspond to an HTTP GET request to the "AccessAndMobilityPolicyData" resource. The MUS1M priority information on the plurality of USIMs of the MUS1M terminal device may be used by the PCF in the querying of the policy control subscription data from the UDR with message 504.

In response to receiving request for the subscription data (e.g., the Nudr_DataRepository_Query request) block 505, the UDR transmits, in message 506, a response to said request (namely, a Nudr_DataRepository_Query response) comprising the subscription data back to the PCF. Specifically, the Nudr_DataRepository_Query response may correspond to an HTTP "200 OK" response comprising the subscription data.

In response to receiving the response (Nudr_DataRepository_Query request) in block 507, the PCF requests notifications from the UDR on changes in the subscription information by invoking Nudr_DataRepository_Subscribe service operation. Specifically, the PCF transmits, in message 508, a subscription request (namely, a Nudr_DataRepository_Subscribe request) to the UDR. Specifically, the Nudr_DataRepository_Subscribe request may correspond to an HTTP POST request to the "IndividualPolicyDataSubscription" resource. The request in message 508 may comprise, for example, the SUP1, the data set identifier (policy data), the data subset identifier (UE context policy control) and/or event reporting information (continuous reporting). The PCF may also supply a Notification UR1 to the UDR to indicate where to send a notification, and a Notification Correlation ID to correlate notifications with this subscription.

In response to receiving the subscription request in block 509, the UDR transmits, in message 510, a response (namely, a Nudr_DataRepository_Subscribe response) back to the (V-)PCF. Specifically, the Nudr_DataRepository_Subscribe response may correspond to an HTTP "201 Created" response to acknowledge the subscription from the PCF.

In response to receiving the response (Nudr_DataRepository_Subscribe response) in block 511, the (V-)PCF carries out, in block 511, the requested policy decision, that is, the (V-)PCF determines (AM) policy information for the plurality of USIMs. The (V-)PCF may also determine applicable policy control request trigger(s).

The (V)PCF transmits, in message 512, a response to the request for creating MUS1M AM policy to the AMF, where the response comprises the determined policy information for the plurality of USIMs. Said response may be an Npcf_AMPolicyControl_Create response. Specifically, the

Npcf_AMPolicyControl_Create response may correspond to an HTTP "201 Created" response. The determined AM policy may comprise, for example, service area restrictions and/or a RAT Frequency Selection Priority (RFSP) index and/or policy control request trigger parameters.

In response to receiving the response in block 513, the AMF may deploy, in block 513, the access and mobility control policy information. The deploying may comprise storing the service area restrictions, provisioning the service area restrictions to the terminal device and/or provisioning the RFSP index and service area restrictions to one or more access node. In some embodiments, the deploying in block 513 may be omitted (or at least postponed).

Once the AMF has available to it both MUS1M priority information (obtained from the MUS1M terminal device via the access node) and policy information (obtained from the PCF) regarding the plurality of USIMs of the MUS1M terminal device, the AMF optimizes, in block 514, one or more procedures of the AMF towards the MUS1M terminal device (i.e., towards the plurality of USIMs of the MUS1M terminal device) based on the priority and policy information. Said one or more procedures may comprise one or more pre-emption procedures, one or more (MUSIM-aware) quality of service (QoS) handling procedures, one or more locationbased services (e.g., relating to health, indoor object search, entertainment, work and/or personal life applications) and/or one or more billing services for supporting MUSIM-based billing. Said optimization in block 514 may correspond to implementing the aforementioned special regime which is more friendly towards coexistence with other networks. Namely, the MUS1M terminal device may be configured, by the AMF according to said special regime, to generate less traffic and less interference towards other networks by having less frequent periodic reports towards home network. Alternatively, the terminal device may be configured, by the AMF according to said special regime, with more frequent options (or opportunities) for accessing home networks, for example, by scheduling requests for network resources

The AMF, acting as a NF service producer node, may provide subscriptions for the PCF, acting a NF service consumer node, to event(s) supported by Namf_EventExposure service using an AmfEventSubscription data element. The AmfEventSubscription data element represents an individual event subscription resource on AMF. Said event(s) may comprise, for example, an NF service registration event. A change in AmfEventSubscription data element, as indicated below in bold, may be implemented to register for AMF subscription events also for MUS1M terminal devicesfi.e., to enable MUSIM-awareness in registering AMF subscription events):

AmfEventSubscription: type: object properties: eventList: type: array items:

$ref: '#/components/schemas/AmfEvent' mini terns: 1 eventNotifyUri:

$ref: 'TS29571_CommonData.yaml#/components/schemas/Uri' no tify Correia tionld: type: string nfld:

$ref: 'TS29571_CommonData.yaml#/components/schemas/NfInstanceId' subsChangeNotifyUri:

$ref: 'TS29571_CommonData.yaml#/components/schemas/Uri' subsChangeNotifyCorrela tionld: type: string supi:

$ref: 'TS29571_CommonData.yaml#/components/schemas/Supi'

MUSIMInfo: type: string groupld: $ref: 'TS29571_CommonData.yamI#/components/schemas/GroupId' gpsi:

$ref: 'TS29571_CommonData.yaml#/components/schemas/Gpsi' pet:

$ref: 'TS29571_CommonData.yaml#/components/schemas/Pei' anyUE: type: boolean

The blocks, related functions, and information exchanges described above by means of Figures 2A, 2B, 3A, 3B, 4 and 5 are in no absolute chronological order, and some of them may be performed simultaneously or in an order differing from the given one.

Figure 6 provides a MUS1M terminal device 601 for according to some embodiments. Specifically, Figure 6 may illustrate a MUS1M terminal device comprising a plurality of USIMs and being configured to carry out at least some of the functions described above in connection with MUS1M terminal device. In some embodiments, Figure 6 may illustrate a part of such a MUS1M terminal device. The MUS1M terminal device 601 may be any of the terminal devices 100, 102 of Figure 1. The MUS1M terminal device may comprise one or more communication control circuitry 620, such as at least one processor, and at least one memory 630, including one or more algorithms 631, such as a computer program code (software) wherein the at least one memory and the computer program code (software) are configured, with the at least one processor, to cause the MUS1M terminal device to carry out any one of the exemplified functionalities of the MUS1M terminal device described above. Said at least one memory 630 may also comprise at least one database 632.

Referring to Figure 6, the one or more communication control circuitry 620 of the MUS1M terminal device 601 comprise at least MUS1M information communication circuitry 621 which is configured at least to provide information (e.g., a flag for indicating that the terminal device is a MUS1M terminal device and MUS1M priority information) on USIMs of the MUS1M terminal device to one or more access nodes. To this end, the MUS1M information communication circuitry 621 of the MUS1M terminal device 601 is configured to carry out at least some of the functionalities described above for the MUS1M terminal device by means of any of Figures 2A, 2B, 3A, 3B, 4A and 4B using one or more individual circuitries. The one or more communication control circuitry 620 may also comprise said plurality of the USIMs of the MUS1M terminal device.

Referring to Figure 6, the memory 630 may be implemented using any suitable data storage technology, such as semiconductor based memory devices, flash memory, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory.

Referring to Figure 6, the MUS1M terminal device 601 may further comprise different interfaces 610 such as one or more signaling interfaces (TX/RX) comprising hardware and/or software for realizing communication connectivity according to one or more communication protocols. Specifically, the one or more signaling interfaces 610 may comprise, for example, interfaces providing a connection to one or more access nodes. The one or more signaling interface 610 may provide the MUS1M terminal device with communication capabilities to communicate in a cellular or wireless communication system, to access the Internet and a core network of a wireless communications network and/or to enable communication between user devices (terminal devices) and different network nodes or elements, for example. The one or more signaling interfaces 610 may comprise standard well-known components such as an amplifier, filter, frequency-converter, (de) modulator, and encoder/decoder circuitries, controlled by the corresponding controlling units, and one or more antennas.

Figure 7 provides an access node 701 according to some embodiments. Specifically, Figure 7 may illustrate an access node configured to carry out at least the functions described above in connection with an access node in communication with a MUS1M terminal device and/or a NF service consumer node (e.g., an AMF) of a core network. The access node 701 maybe the access node 104 of Figure 1. The access node 701 may comprise one or more communication control circuitry 720, such as at least one processor, and at least one memory 730, including one or more algorithms 731, such as a computer program code (software) wherein the at least one memory and the computer program code (software) are configured, with the at least one processor, to cause the access node to carry out any one of the exemplified functionalities of the access node described above. Said at least one memory 730 may also comprise at least one database 732.

Referring to Figure 7, the one or more communication control circuitry 720 of the access node 701 comprise at least MUS1M handling circuitry 721 which is configured to receive information (e.g., a flag for indicating that the terminal device is a MUS1M terminal device and MUS1M priority information) on USIMs of one or more MUS1M terminal device, to request at least some of said information from the MUS1M terminal device (namely, MUS1M priority information) and/or to perform MUS1M aware policy handling. To this end, the MUS1M handling circuitry 721 of the access node 701 is configured to carry out at least some of the functionalities described above for the access node by means of any of Figures 2A, 2B, 3A, 3B, 4A, 4B and 5 using one or more individual circuitries. Referring to Figure 7 , the memory 730 may be implemented using any suitable data storage technology, such as semiconductor based memory devices, flash memory, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory.

Referring to Figure 7, the access node 701 may further comprise different interfaces 710 such as one or more signaling interfaces (TX/RX) comprising hardware and/or software for realizing communication connectivity according to one or more communication protocols. Specifically, the one or more signaling interfaces 710 may comprise, for example, interfaces providing a connection to one or more MUS1M terminal devices and/or a AMF (or other network function service consumer node). The one or more signaling interface 710 may provide the access node with communication capabilities to communicate in a cellular or wireless communication system, to access the Internet and a core network of a wireless communications network and/or to enable communication to user devices (terminal devices) and different network nodes or elements, for example. The one or more signaling interfaces 710 may comprise standard well-known components such as an amplifier, filter, frequency-converter, (de) modulator, and encoder/decoder circuitries, controlled by the corresponding controlling units, and one or more antennas.

In some embodiments, Figure 7 may illustrate a distributed access node or specifically a distributed unit of a distributed access node.

Figure 8 provides a NF service consumer node 801 (e.g., an AMF) of a core network according to some embodiments. Specifically, Figure 8 may illustrate a NF service consumer node configured to carry out at least the functions described above in connection with a NF service consumer node in communication with an access node and/or one or more core network nodes (e.g., a PCF). The NF service consumer node 801 may comprise one or more communication control circuitry 820, such as at least one processor, and at least one memory 830, including one or more algorithms 831, such as a computer program code (software) wherein the at least one memory and the computer program code (software) are configured, with the at least one processor, to cause the NF service consumer node to carry out any one of the exemplified functionalities of the NF service consumer node described above. Said at least one memory 830 may also comprise at least one database 832.

Referring to Figure 8, the one or more communication control circuitry 820 of the NF service consumer node 801 comprise at least MUS1M aware policy handling circuitry 821 which is configured to receive information (e.g., MUS1M priority information) on USIMs of one or more MUS1M terminal devices and employ said information for performing MUS1M aware policy handling. To this end, the MUS1M aware policy handling circuitry 821 of the NF service consumer node 801 is configured to carry out at least some of the functionalities described above for the NF service consumer node 801 (namely, the AMF in the above discussion) by means of any of Figures 4A, 4B and 5 using one or more individual circuitries.

Referring to Figure 8, the memory 830 may be implemented using any suitable data storage technology, such as semiconductor based memory devices, flash memory, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory.

Referring to Figure 8, the NF service consumer node 801 may further comprise different interfaces 810 such as one or more signaling interfaces (TX/RX) comprising hardware and/or software for realizing communication connectivity according to one or more communication protocols. Specifically, the one or more signaling interfaces 810 may comprise, for example, interfaces providing a connection to the (V-)PCF and/or UDR. The one or more signaling interface 810 may provide the NF service consumer node with communication capabilities to communicate in a cellular or wireless communication system, to access the Internet and a core network of a wireless communications network and/or to enable communication to other core network nodes, for example. The one or more signaling interfaces 810 may comprise standard well-known components such as an amplifier, filter, frequency-converter, (de) modulator, and encoder/decoder circuitries, controlled by the corresponding controlling units, and one or more antennas.

As used in this application, the term 'circuitry' may refer to one or more or all of the following: (a) hardware-only circuit implementations, such as implementations in only analog and/or digital circuitry, and (b) combinations of hardware circuits and software (and/or firmware), such as (as applicable): (i) a combination of analog and/or digital hardware circuit(s) with software/firmware and (ii) any portions of hardware processor(s) with software, including digital signal processor(s), software, and memory(ies) that work together to cause an apparatus, such as a terminal device or an access node, to perform various functions, and (c) hardware circuit(s) and processor(s), such as a microprocessor(s) or a portion of a microprocessor(s), that requires software (e.g. firmware) for operation, but the software may not be present when it is not needed for operation. This definition of 'circuitry' applies to all uses of this term in this application, including any claims. As a further example, as used in this application, the term 'circuitry' also covers an implementation of merely a hardware circuit or processor (or multiple processors) or a portion of a hardware circuit or processor and its (or their) accompanying software and/or firmware. The term 'circuitry' also covers, for example and if applicable to the particular claim element, a baseband integrated circuit for an access node or a terminal device or other computing or network device. In an embodiment, at least some of the processes described in connection with Figures 2A, 2B, 3A, 3B, 4A, 4B and 5 may be carried out by an apparatus comprising corresponding means for carrying out at least some of the described processes. Some example means for carrying out the processes may include at least one of the following: detector, processor (including dual-core and multiple-core processors), microprocessor, digital signal processor (DSP), controller, microcontroller, receiver, transmitter, encoder, decoder, memory, RAM, ROM, software, firmware, display, user interface, display circuitry, user interface circuitry, user interface software, display software, circuit, antenna, antenna circuitry, applicationspecific integrated circuit (ASIC), digital signal processing device (DSPD), programmable logic device (PLD) and field programmable gate array (FPGA). For firmware or software, the implementations according embodiments may be carried out through modules of at least one chipset (procedures, functions, and so on) that perform the functions described herein. The software codes may be stored in a memory unit and executed by processors. The memory unit may be implemented within the processor or externally to the processor. In the latter case, it can be communicatively coupled to the processor via various means, as is known in the art. In an embodiment, the at least one processor, the memory, and the computer program code form processing means or comprises one or more computer program code portions for carrying out one or more operations according to any one of the embodiments of Figures 2A, 2B, 3A, 3B, 4A, 4B and 5 or operations thereof.

According to an embodiment, there is provided an apparatus for a multiple universal subscriber identity module, MUS1M, terminal device. Said apparatus comprises at least one processor and at least one memory including computer program code, the at least one memory and the computer program code being configured, with the at least one processor, to cause the apparatus to perform: operating the MUS1M terminal device in one of a radio resource control, RRC, idle state and a RRC inactive state using a first universal subscriber identity module, US1M, of a plurality of USIMs of the MUS1M terminal device; and causing the MUS1M terminal device to transition from said one of the RRC idle and the RRC inactive state to a RRC connected state, wherein the transitioning comprises transmitting a RRC setup request to an access node, the RRC setup request comprising either a flag having a value indicating presence of the plurality of USIMs in the MUS1M terminal device or MUS1M priority information on one or more USIMs of the plurality of USIMs, the one or more USIMs comprising at least one US1M other than the first US1M, wherein, if the at least one memory and the computer program code are configured, with the at least one processor, to cause the apparatus to include said flag in the RRC setup request, the at least one memory and the computer program code are configured, with the at least one processor, to cause the apparatus to perform: causing transmitting, in response to receiving a request for MUSIM priority information on one or more USIMs of the plurality of USIMs from the access node while the RRC connected state is active for the first US1M, a response comprising the MUSIM priority information on the one or more USIMs, the one or more USIMs comprising at least one US1M other than the first US1M.

According to an embodiment, there is provided an apparatus for a multiple universal subscriber identity module, MUSIM, terminal device. Said apparatus comprises at least one processor and at least one memory including computer program code, the at least one memory and the computer program code being configured, with the at least one processor, to cause the apparatus device to perform: operating the MUSIM terminal device with at least a first universal subscriber identity module, US1M, of a plurality of USIMs of the MUSIM terminal device in an active state; causing the MUSIM terminal device to register with a mobile network by transmitting a radio resource control, RRC, registration request to an access node and transmitting, in response to receiving a RRC identity request from the access node, a RRC identity response to the access node, wherein at least one of the RRC registration request and the RRC identity response comprises either a flag having a value indicating presence of the plurality of USIMs in the MUSIM terminal device or the RRC registration request comprises MUSIM priority information on one or more USIMs of the plurality of USIMs, the one or more USIMs comprising at least one US1M other than the first US1M, wherein, if the at least one memory and the computer program code are configured, with the at least one processor, to cause the apparatus to include said flag in said at least one of the RRC registration request and the RRC identity response, the at least one memory and the computer program code are configured, with the at least one processor, to cause the apparatus to perform: causing transmitting, in response to receiving a request for MUSIM priority information on one or more USIMs of the plurality of USIMs from the access node, a response comprising the MUSIM priority information on the one or more USIMs, the one or more USIMs comprising at least one US1M other than the first US1M. According to an embodiment, there is provided an apparatus for an access node. Said apparatus comprises at least one processor and at least one memory including computer program code, the at least one memory and the computer program code being configured, with the at least one processor, to cause the apparatus to perform: establishing a connection to a multiple universal subscriber identity module, MUS1M, terminal device comprising a plurality of universal subscriber identity modules, USIMs, causing the MUS1M terminal device to transition to operation in a radio resource control, RRC, connected state using at least a first US1M of the plurality of USIMs, wherein the establishing comprises receiving a RRC setup request from the MUS1M terminal device and, the RRC setup request comprising either a flag having a value indicating presence of the plurality of USIMs or MUS1M priority information on one or USIMs of the plurality of USIMs of the MUS1M terminal device, the one or more USIMs comprising at least one US1M other than the first US1M, wherein, if the at least one memory and the computer program code are configured, with the at least one processor, to cause the apparatus to receive said flag in the RRC setup request, the at least one memory and the computer program code are configured, with the at least one processor, to cause the apparatus to perform: transmitting, based on the value of the flag, a request for MUS1M priority information on one or more USIMs of the plurality of USIMs to the MUS1M terminal device, the one or more USIMs comprising at least one US1M other than a first US1M being currently active; and receiving a response comprising the MUS1M priority information on the one or more USIMs, wherein, if the at least one memory and the computer program code are configured, with the at least one processor, to cause the apparatus to receive either said flag or said MUS1M priority information in the RRC setup request, the at least one memory and the computer program code are configured, with the at least one processor, to cause the apparatus to perform: transmitting MUS1M priority information on the first US1M and said at least one US1M to a network function service consumer node of a core network for enabling MUSIM-specific optimization.

According to an embodiment, there is provided an apparatus for an access node. Said apparatus comprises at least one processor and at least one memory including computer program code, the at least one memory and the computer program code being configured, with the at least one processor, to cause the apparatus to perform: causing registering a multiple universal subscriber identity module, MUS1M, terminal device comprising a plurality of universal subscriber identity modules, USIMs, to a mobile network, wherein the registering comprises: transmitting, in response to receiving a radio resource control, RRC, registration request from the MUS1M terminal device, a RRC identity request to the MUS1M terminal device and receiving a RRC identity response from the MUSIM terminal device, wherein at least one of the RRC registration request and the RRC identity response comprises a flag having a value indicating presence of the plurality of USIMs in the MUSIM terminal device or the RRC registration request comprises MUSIM priority information on one or more USIMs of the plurality of USIMs to the MUSIM terminal device, the one or more USIMs comprising at least one US1M other than a first US1M being currently active, wherein, if the at least one memory and the computer program code are configured, with the at least one processor, to cause the apparatus to receive said flag in said at least one of the RRC registration request and the RRC identity response, the at least one memory and the computer program code are configured, with the at least one processor, to cause the apparatus to perform: transmitting, based on the value of flag, a request for MUSIM priority information on one or more USIMs of the plurality of USIMs to the MUSIM terminal device, the one or more USIMs comprising at least one US1M other than a first US1M being currently active, wherein, if the at least one memory and the computer program code are configured, with the at least one processor, to cause the apparatus to receive said flag in either of said at least one of the RRC registration request and the RRC identity response or to receive said MUSIM priority information in the RRC registration request, the at least one memory and the computer program code are configured, with the at least one processor, to cause the apparatus to perform: transmitting MUSIM priority information on the first US1M being currently active and said at least one US1M other than the first US1M to a network function service consumer node of a core network of the mobile network for enabling MUS1M- specific network policy optimization.

According to an embodiment, there is provided an apparatus for a network function service consumer node of a core network. Said apparatus comprises at least one processor and at least one memory including computer program code, the at least one memory and the computer program code being configured, with the at least one processor, to cause the apparatus to perform:

MUSIM, terminal device from an access node; transmitting a request for creating a MUSIM-aware access and mobility management policy to a policy control function, wherein the request comprises the MUSIM priority information on the plurality of USIMs; receiving a response to the request from the policy control function, wherein the response comprises policy information for the plurality of USIMs; and optimizing one or more procedures of the network function service consumer node towards the MUSIM terminal device based on the priority and policy information, wherein the one or more procedures comprise one or more pre-emption procedures, one or more quality of service handling procedures, one or more location-based services and/or one or more billing services for supporting MUS1M- based billing.Any of the above embodiments for apparatuses comprising at least one processor and at least one memory including computer program code may be combined with any further features of embodiments discussed in connection with Figures 2A, 2B, 3A, 3B, 4A, 4B and 5 to 8.

Embodiments as described may also be carried out in the form of a computer process defined by a computer program or portions thereof. Embodiments of the methods described in connection with Figures 2A, 2B, 3A, 3B, 4A, 4B and 5 may be carried out by executing at least one portion of a computer program comprising corresponding instructions. The computer program may be provided as a computer readable medium comprising program instructions stored thereon or as a non- transitory computer readable medium comprising program instructions stored thereon. The computer program may be in source code form, object code form, or in some intermediate form, and it may be stored in some sort of carrier, which may be any entity or device capable of carrying the program. For example, the computer program may be stored on a computer program distribution medium readable by a computer or a processor. The computer program medium may be, for example but not limited to, a record medium, computer memory, read-only memory, electrical carrier signal, telecommunications signal, and software distribution package, for example. The computer program medium may be a non-transitory medium. Coding of software for carrying out the embodiments as shown and described is well within the scope of a person of ordinary skill in the art.

Even though the invention has been described above with reference to an example according to the accompanying drawings, it is clear that the invention is not restricted thereto but can be modified in several ways within the scope of the appended claims. Therefore, all words and expressions should be interpreted broadly, and they are intended to illustrate, not to restrict, the embodiment. It will be obvious to a person skilled in the art that, as technology advances, the inventive concept can be implemented in various ways. Further, it is clear to a person skilled in the art that the described embodiments may, but are not required to, be combined with other embodiments in various ways.