Multi-sim ue assistance information with unavailable times

Abstract

Method, apparatus, computer program for a user equipment having at least two connections to at least two network nodes, each connection corresponding to a different user identity, selecting, by the user equipment, one of the at least two network nodes to communicate exclusively with that network node during one or more time intervals; and sending, by the user equipment, one or more messages to the other of the at least two network nodes, the one or more messages indicating to the other of the at least two network nodes that the user equipment is unavailable for communication during the one or more time intervals.

Description

TECHNICAL FIELD

[0001] The present disclosure relates generally to wireless networks, and more specifically to a wireless device, referred to as a user equipment, that uses multiple Universal Subscriber Identity Module (USIM) cards to access networks. BACKGROUND

[0002] A Subscriber Identity Module (SIM) is a memory chip used in mobile phones. The SIM has largely been replaced by a Universal Subscriber Identity Module (USIM) card, which provides enhanced features over the SIM card, such as enhanced security, etc. The USIM is essentially a micro “computer” that provides many different features.

[0003] Recently, there have been developments towards user equipment (UE) with multiple USIMs (or multi-USIMs). These devices are referred to as MUSIM devices. While such MUSIM devices can provide additional or multiple services, coordination and use of two different services and activities between different network operators can be problematic in such devices. BRIEF DESCRIPTION OF DRAWINGS

[0004] In the drawings:

[0005] Figure 1 is a block diagram of one possible and non-limiting example system in which example embodiments can be practiced;

[0006] FIG. 2(a) is an illustration of a cellular network with a MUSIM UE having USIMs belonging to the same MNO;

[0007] FIG. 2(b) is an illustration of a cellular network with a MUSIM UE having USIMs belonging to different MNOs;

[0008] Figure 3 is an example of a priority table (Table 1) across different signaling procedures;

[0009] Figure 4 is a signaling diagram and message sequence chart according to example embodiments showing an example of RRC messaging from a UE to a gNB with one or more unavailable time intervals, for example;

[0010] Figure 5 shows an example proposal in example embodiments to extend the UEAssistanceInformation message by adding the possibility for the UE to inform about its unavailability time;

[0011] Figure 6is a signaling diagram and message sequence chart according to exemplary embodiments showing an example of a UCI message from a UE to a gNB with an “unavailable flag.” DETAILED DESCRIPTION

[0012] Abbreviations that can be found in the specification and / or drawings include the following:

[0013] The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any implementation described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other implementations. All of the

[0014] Exemplary embodiments herein describe techniques for multiple USIM (MUSIM) UE assistance information and its unavailable time. Additional description of these techniques is presented after describing a system in which the exemplary embodiments can be used.

[0015] Turning to Figure 1 , which shows a block diagram of one possible and non-limiting exemplary system in which exemplary embodiments can be practiced. A user equipment (UE) 110, radio access network (RAN) nodes 170 and 170-1, and network element(s) 190 are shown. In Figure 1In overview, a user equipment (UE) 110 is in wireless communication with a wireless (e.g., cellular) network 100. The UE is wireless, typically a mobile device that can access a wireless network. The UE 110 includes one or more processors 120, one or more memories 125, and one or more transceivers 130 interconnected through one or more buses 127. Each of the one or more transceivers 130 includes a receiver, Rx 132, and a transmitter, Tx 133. The one or more buses 127 can be address, data, or control buses, and can include any interconnection mechanism, such as a motherboard or a series of lines on an integrated circuit, optical fiber or other optical communication device, etc. The one or more transceivers 130 are connected to one or more antennas 128. The one or more memories 125 include computer program code 123. The UE 110 includes a control module 140, which includes one or both of portions 140-1 and / or 140-2, which can be implemented in a variety of ways. The control module 140 can be implemented in hardware as control module 140-1, such as being implemented as part of the one or more processors 120. The control module 140-1 can also be implemented as an integrated circuit or through other hardware, such as a programmable gate array, etc. In another example, the control module 140 can be implemented as control module 140-2, which is implemented as computer program code 123 and executed by the one or more processors 120. For example, the one or more memories 125 and computer program code 123 can be configured to, with the one or more processors 120, cause the user equipment 110 to perform one or more of the operations as described herein. The UE 110 communicates with a RAN node 170 via a wireless link 111.

[0016] The RAN nodes 170, 170-1 are base stations that provide access to wireless devices, such as the UE 110, to the wireless network 100. The RAN node 170 is also referred to herein as gNB-1, and the RAN node 170-1 is also referred to herein as gNB-2. It is assumed that the RAN node 170-1 is similar to the RAN node 170, and thus only the possible internal configuration of the RAN node 170 is described herein.

[0017] The RAN node 170 can be, for example, a base station for 5G, also known as New Radio (NR). In 5G, the RAN node 170 can be an NG-RAN node, which is defined to be a gNB or ng-eNB. A gNB is a node providing NR user plane and control plane protocol terminations towards the UE and connected via an NG interface to a 5GC (e.g., network element(s) 190). An ng-eNB is a node providing E-UTRA user plane and control plane protocol terminations towards the UE and connected via an NG interface to a 5GC. An NG-RAN node can include multiple gNBs, which can also include a central unit (CU) (gNB-CU) 196 and distributed unit(s) (DU) (gNB-DU), of which a gNB-DU is shown. Note that a DU can include or be coupled to and control a radio unit (RU). A gNB-CU is a logical node hosting the RRC, SDAP, and PDCP protocols of a gNB or the RRC and PDCP protocols of an en-gNB that controls the operation of one or more gNB-DUs. The gNB-CU terminates the F1 interface with the gNB-DU. The F1 interface is shown as reference 198, although reference 198 also shows a link between a remote element of a RAN node 170 and a centralized element of a RAN node 170, such as between a gNB-CU 196 and a gNB-DU 195. A gNB-DU is a logical node hosting the RLC, MAC, and PHY layers of a gNB or en-gNB and whose operation is controlled in part by the gNB-CU. One gNB-CU supports one or more cells. One cell is supported by only one gNB-DU. The gNB-DU terminates the F1 interface 198 with the gNB-CU. Note that the DU 195 is considered to include the transceiver 160, e.g., as part of a RU, although some examples of this aspect can have the transceiver 160 as part of a separate RU, e.g., under the control of and connected to the DU 195. The RAN node 170 can also be an eNB (evolved NodeB) base station for LTE (Long Term Evolution), or any other suitable base station.

[0018] The RAN node 170 includes one or more processors 152, one or more memories 155, one or more network interfaces ((N / W I / F(s)) 161, and one or more transceivers 160 interconnected through one or more buses 157. Each of the one or more transceivers 160 includes a receiver, Rx 162, and a transmitter, Tx 163. The one or more transceivers 160 are connected to one or more antennas 158. The one or more memories 155 include computer program code 153. The CU 196 can include the processor(s) 152, the memory 155, and the network interface 161. Note that the DU 195 can also include its own memory / memories and processor(s), and / or other hardware, but these are not shown.

[0019] The RAN node 170 includes a control module 150, which includes one or both of parts 150-1 and / or 150-2, which can be implemented in a variety of ways. The control module 150 can be implemented in hardware as control module 150-1, such as being implemented as part of the processor(s) 152. The control module 150-1 can also be implemented as an integrated circuit or through other hardware such as a programmable gate array. In another example, the control module 150 can be implemented as control module 150-2, which is implemented as computer program code 153 and executed by the processor(s) 152. For instance, the memory(ies) 155 and the computer program code 153 are configured to, with the processor(s) 152, cause the RAN node 170 to perform one or more of the operations as described herein. Note that the functionality of the control module 150 can be distributed, such as between the DU 195 and the CU 196, or implemented solely in the DU 195.

[0020] The one or more network interfaces 161 communicate over a network, such as via links 176 and 131. Two or more RAN nodes 170, 170-1 (or additional) communicate using, for example, the link(s) 176. The link(s) 176 can be wired or wireless or both and can implement, for example, the Xn interface for 5G, the X2 interface for LTE, or other suitable interfaces for other standards.

[0021] The one or more buses 157 can be address, data, or control buses, and can include any interconnection mechanism, such as a series of lines on a motherboard or integrated circuit, fiber optics or other optical communication equipment, wireless channels, and the like. For example, the one or more transceivers 160 can be implemented as a remote radio head (RRH) 195 for LTE or a distributed unit (DU) 195 for a gNB implementation for 5G, where other elements of the RAN node 170 can be physically located in a different location from the RRH / DU, and the one or more buses 157 can be implemented, in part, as, for example, fiber optic cables or other suitable network connections for connecting the other elements of the RAN node 170 (e.g., central unit (CU), gNB-CU) to the RRH / DU 195. Reference 198 also indicates these suitable network link(s).

[0022] Note that the description herein indicates that a "cell" performs a function, but it should be clear that the base station forming the cell can perform the function. A cell constitutes a part of a base station. That is, each base station can have multiple cells. For example, a single carrier frequency and associated bandwidth can have three cells each covering one third of a 360 degree area, so the coverage area of a single base station covers an approximately elliptical or circular shape. Also, each cell can correspond to a single carrier and a base station can use multiple carriers. So if there are 3 120 degree cells per carrier and there are 2 carriers, then a base station has a total of 6 cells.

[0023] The wireless network 100 can include one or more network elements 190 that can include core network functionality and provide connectivity to additional networks (e.g., the Internet) such as telephone networks and / or data communication networks via one or more links 181. Such core network functionality for 5G can include Access and Mobility Management Function(s) (AMF(s)) and / or User Plane Function(s) (UPF(s)) and / or Session Management Function(s) (SMF(s)). Such core network functionality for LTE can include MME (Mobility Management Entity) / SGW (Serving Gateway) functionality. These are merely exemplary functionality that can be supported by the network element(s) 190, and note that both 5G and LTE functionality can be supported. A core network 191 of a 5GC or EPC is shown, including the network element(s) 190. The RAN nodes 170, 170-1 are coupled via one or more links 131 to the network elements 190. The link(s) 131 can be implemented, for example, as an NG interface for 5G, or an SI interface for LTE, or other suitable interface for other standards. The network elements 190 include one or more processors 175, one or more memories 171, and one or more network interfaces (N / W I / F(s)) 180 interconnected through one or more buses 185. The one or more memories 171 include computer program code 173. The one or more memories 171 and the computer program code 173 are configured to, with the one or more processors 175, cause the network elements 190 to perform one or more operations.

[0024] The wireless network 100 can implement network virtualization, which is a process that combines hardware and software network resources and network functionality into a single, software- based administrative unit (virtual network). Network virtualization involves platform virtualization, which is often used in conjunction with resource virtualization. Network virtualization is divided into external network virtualization, which combines many networks or parts of networks into a virtual unit, or internal network virtualization, which provides software containers on a single system with network-like functionality. Note that the virtualized entities resulting from network virtualization are still implemented to some extent using hardware such as the processors 152 or 175 and memories 155 and 171, and such virtualized entities also produce technical effects.

[0025] The computer-readable storage media 125, 155, and 171 can be of any type suitable to the local technical environment and can 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. The computer-readable storage media 125, 155, and 171 can be means for storing information and / or functionality. The processors 120, 152, and 175 can be of any type suitable to the local technical environment, and can include one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on multi-core processor architectures, as non-limiting examples. The processors 120, 152, and 175 can be means for performing functions, such as controlling the UE 110, the RAN node 170, and other functions described herein.

[0026] Generally, the various embodiments of the User Equipment 110 can include, but are not limited to, cellular telephones such as smart phones, tablets, personal digital assistants (PDAs), portable computers, vehicles having modem devices for wireless V2X (Vehicle-to-anything) communications, image capture devices such as digital cameras, gaming devices, music storage and playback appliances, Internet devices (including IoT devices) allowing wireless Internet access and possibly web browsing, IoT devices with wireless communication capability for automation applications with sensors and / or actuators, tablets, and portable units or terminals that incorporate combinations of such functions.

[0027] Having thus introduced one suitable, but non-limiting, technological background for the practice of the exemplary embodiments of the present application, the exemplary embodiments will now be described in more detail.

[0028] Note that the exemplary embodiments are presented herein in the context of 5G. However, it should be appreciated that the exemplary embodiments can encompass NR, EUTRA, and NR-EUTRA dual connectivity cases. For example, the RAN node 170 can be an eNB as a legacy EUTRA, with both control plane and user plane towards the UE 110 and connected to an EPC 191. Other options are also possible.

[0029] The exemplary embodiments herein are in the context of supporting multi-USIM devices, mainly in 5G NR and LTE. There is an ongoing Rel-17 study item on Service and System Aspects (SA) (see SP-190248, “Study on system enablers for multi-USIM devices (FS_MUSIM)” (3GPP Work Item Description approved in TSG SA meeting #SP-83, March 2019 and the corresponding Technical Report 3GPP TR 23.761 V0.1.0 (2019-10)) and Radio Access Network (RAN) (see RP-190282, “Study on multi-SIM devices in RAN” (3GPP Work Item Description presented as information in TSG RAN meeting #SP-83, March 2019 and the corresponding 3GPP Technical Report TR 22.834 V17.1.0 (2019-09)).

[0030] The main objectives proposed in the SA study and the work of the upcoming Rel-17 work item are shown below (see SP-190248, “Study on system enablers for multi-USIM devices (FS_MUSIM)” (3GPP Work Item Description approved in TSG SA meeting #SP-83, March 2019):

[0031]

[0032]

[0033] The following statement in the above material is of particular importance: “The study shall determine how the network handles suspending MT data or MT control plane activities on a connection where the other occurs.” That is, MT (Mobile Terminal) data or corresponding control plane activities will be studied, while the impact of MT data is not yet clear.

[0034] The main objectives of the RAN study item or core part of the work items including the testing part are as follows (see RP-190282, “New Rel-17 SID proposal: Study on multi-SIM devices in RAN” (3GPP Work Item Description presented as information in TSG RAN meeting #SP-83, March 2019)):

[0035]

[0036]

[0037] As this example and the previous example on MT data illustrate, a lot of technical details on the operation of MUSIM devices are unknown or under examination.

[0038] Background on Multi-USIM (MUSIM) devices and existing solutions, a MUSIM device (such as UE 110) has two (dual) or more (multi) simultaneous 3GPP / 3GPP2 network subscriptions with multiple corresponding International Mobile Subscriber Identities (IMSI), each IMSI is associated with a specific USIM belonging to the same or different Mobile Network Operator (MNO( / Mobile Network Virtual Operator (MNVO). A MUSIM device connected to one or more gNBs 170, 170-1 (or additional gNBs) with independent subscriptions is illustrated in FIG. 2(a) and FIG. 2(b). In FIG. 2(a), the two USIMs 250-1, 250-2 in UE 110 belong to the same MNO / MVNO, are registered at the core network EPC / 5GC 191-1 to two independent IDs (ID_a 230 and ID_b 230-1), and can use the same cell 210 (formed by gNB 170) or two adjacent cells 210, 210-1 (formed by gNB 170, 170-1, respectively) as serving cells. For example, the two (or more) USIMs in the device can use the exact same serving cell. From the gNB’s (and CN’s) perspective, this device is treated as two independent UEs. The dashed line 280 illustrates that even if the two USIMs 250, 250-1 belong to the same MNO, the UE can use two adjacent serving cells (e.g., if the UE is at the edge of both). The RNTI 220 from gNB 170 has an indication of ID_b 230-1 and the RNTI 220-1 from gNB 170-1 has an indication of ID_a 230. In FIG. 2(a), cells 1 through 9 are shown, where cells 1, 2, and 3 are formed by gNB 170, cells 4, 5, and 6 are formed by gNB 170-1, and cells 7, 8, and 9 are formed by gNB 170-2.

[0039] In Figure 2(b), two USIMs 250-1, 250-2 in the UE 110 belong to different MNOs, indicated by two different core networks EPC / 5GC-1 191-1 and EPC / 5GC-1 191-2, and can use two neighboring or collocated cells 220 from each MNO as serving cells. In this case, the cells are neighboring cells 210, 210-2. RNTI 220-1 with ID_a comes from gNB 170-4, while RNTI 220 with ID_b comes from gNB 170. Cells 1-9 correspond to EPC / 5GC-1 191-1, and cells 10-15 correspond to EPC / 5GC-1 191-2. Cells 10-15 are shown as “overlapping” with cells 1 and 4-9. For example, cell 15 overlaps with cell 1; cell 10 overlaps with cell 4; and cell 11 overlaps with cell 5. Other cells of EPC / 5GC-1 191-1 are hidden. gNB 170-3 forms cells 10, 11, and 12, while gNB 170-4 forms cells 13, 14, and 15. Here, the UE uses two completely different serving cells (from different PLMNs / MNOs), but here also, the two cells (from different PLMNs / MNOs) can potentially be collocated or neighboring. For example, the UE can connect to gNBs 170-1 and 170-3, which can be collocated (e.g., in the same tower) as shown in Figure 2(b).

[0040] MUSIM devices are available everywhere in the market - especially in the enhanced mobile broadband (eMBB) part of the market. However, there is no 3GPP standard support tailored for MUSIM usage, so there is no specified way of coordination across 2 PLMNs, nor is there a possibility to perform performance / consistency testing of the device in the MUSIM use cases defined by 3GPP. Current existing products use UE proprietary implementation without any possibility to control the behavior from the NW (network).

[0041] Single USIM UE devices 110 that are compliant with Carrier Aggregation (CA) and Dual Connectivity (DC) (introduced in 3GPP Release 10 and enhanced with increasing number of carriers in successive releases) or diversity / MIMO requirements already have several RX and TX chains, typically 5-8 RX and 3-4 TX for supporting Release 15. However, due to one or several of the following reasons or other hardware limitations, the user equipment cannot support 5-8 parallel independent RX or 3-4 parallel independent TX.

[0042] 1) According to RF HW (hardware) design, not all RX and TX chains cover the entire frequency range (also called band groups) - i.e. low band (LB), mid band (MB), high band (HB), ultra-high band (UHB) and millimeter wave (mmW) - for cellular communication and support MIMO.

[0043] 2) According to RF HW design, front-end components are shared for carriers in band groups.

[0044] 3) Intermodulation products across several RX frequencies and TX frequencies and local oscillators generate continuous waveforms (CWs) and modulated spurs, which cause interference to the received signals. In-device self-interference cancellation is used to cancel the generated CWs and modulated spurs. However, this cancellation requires dynamic time-accurate synchronization knowledge about RX and TX LOs (local oscillators).

[0045] Due to the increasing challenging requirements on device size and weight and battery life, eMBB MUSIM devices will use the same single USIM HW for multi-USIM operation by sharing the increasing number of RX and TX chains in both USIMs.

[0046] Regarding the multi-USIM terminology, depending on the simultaneous RRC_states supported on USIMs, two main types of MUSIM devices are usually referred to:

[0047] 1) Dual SIM dual standby (DSDS) or multi-USIM multi-standby (MUMS). These are MUSIM devices registered with two or more independent subscriber IDs (USIMs) and can be in RRC_IDLE mode on all USIMs. However, the device can only be in RRC_CONNECTED mode with a single USIM at a given time.

[0048] 2) Dual SIM dual active or multi-USIM multi-active (MUMA). These are MUSIM devices registered with two or more independent subscriber IDs (USIMs) and can be in RRC_IDLE mode on all USIMs. In addition, the device can maintain RRC_CONNECTED mode activity on all USIMs.

[0049] Furthermore, the UE behavior in handling multiple USIMs simultaneously can depend on the UE's HW and SW capabilities, as follows:

[0050] a) SingleRx / SingleTx: UE can only receive traffic from one network and / or transmit traffic to one network at a time;

[0051] b) DualRx / SingleTx: UE is able to receive traffic from both networks simultaneously, but can only transmit to one network at a time; or

[0052] c) DualRx / DualTx: UE is able to receive traffic from both networks simultaneously and / or transmit traffic to both networks simultaneously.

[0053] One technical problem that exists is that SingleRx / SingleTx or DualRx / DualTx MUSIM devices will not be able to avoid interrupting certain services from one USIM due to activities related to the other USIM. Therefore, current UE proprietary implementations use different priority schemes and UE-specific time multiplexing of DL and UL activities across the two USIMs to solve MUSIM conflict use cases, while there is no possibility for a control behavior at the network side. Unless well designed, these devices have the ability to disrupt or bypass existing network services. An example of a priority scheme as a UE implementation is shown in Table 1, which is an example of a priority table across different signaling procedures. Any procedure with higher priority (lower value) on one USIM can interrupt ongoing activities with lower priority (higher value) on the other USIM. Figure 3

[0054] One problem with the UE performing autonomous prioritization of its radio activities is that neither serving network is aware that the UE is de-prioritizing its corresponding activities, and therefore, network resources can be spent in scheduling the UE that is not monitoring traffic from this network. In extreme cases, this can lead to radio link failure in the lower priority USIM, which will result in additional signaling to restore the connection of the USIM with the network.

[0055] There is currently no available mechanism to coordinate actions between networks for MUSIM operation.

[0056] To solve these problems, in example embodiments, a signaling mechanism is introduced in which the UE is able to indicate its “availability” to the serving networks. Under current network operation, it is assumed that the UE can be available to serve on a near-constant basis, except for configured measurement gaps in which the UE is configured with a period of time to perform inter-frequency measurements.

[0057] In contrast, the example signaling mechanism in the examples herein will allow the UE to indicate in a structured manner that the UE will not monitor DL traffic or be available for UL scheduling. In the DL, the proposed scheme can include PDCCH as well as PDSCH. The signaling mechanism can include a combination of long-term indication and short-term self-organizing indication. In the UL, one example proposed scheme has the UE inform the gNB which periods the UE is not available to be scheduled for UL transmission. ​

[0058] In particular, in the exemplary embodiments herein, the following can be performed:

[0059] 1) Changes to the 3GPP standard can be implemented to allow the UE to inform the gNB of the UE's future planned activities as well as short term dynamic activities, for example:

[0060] a) Changes to the existing UL-DCCH messages, UEAssistanceInformation, or introducing new dedicated messages for future scheduled and / or periodic activities with known specified length; and / or

[0061] b) UCI messages carried in PUCCH or PUSCH with information about short term unavailability at the start and end of the unavailable time or at the start of the unavailable time length of a dynamically scheduled activity.

[0062] 2) Exemplary embodiments also propose defining a minimum time drift across two networks for which the reported unavailable time is valid.

[0063] An overview of the exemplary proposed solution is now presented. According to exemplary embodiments, the NW (network) will receive from the UE an indication about the time(s) and / or period(s) when the UE will be unavailable for DL or UL scheduling of the serving network. During these times, the serving network can also consider the UE as unavailable for scheduling. It is to be noted that the UE is assumed to have accurate knowledge of the relative timing of the affected network (if other networks being simultaneously served cause the unavailability) and can convert the timing requirements across networks.

[0064] According to exemplary embodiments, the indication of the UE's availability will potentially take two forms or types, depending on the UE activity and the advance time available for knowledge about the activity, which can be combined. For long term indications (e.g. indication accuracy will be at frame level), these are denoted as "Type 1", while for dynamic indications of unavailability (e.g. indication accuracy will be at slot level or lower), these are denoted as "Type 2", as detailed below.

[0065] Regarding Type 1, (semi-)static, periodic scheduled activities, these are intended for cases where the UE has a known specified length of scheduled and / or periodic activities in the future. An exemplary signaling scheme for this information can be RRC, as the regulation rate of RRC signaling is slow and the signaling is carried on a reliable control channel. An exemplary signaling and message sequence for this case is shown in Figure 4 , and the steps are as follows. Figure 4 Signaling between the UE 110 (e.g. under control of the control module 140) and gNB-1 170 and gNB-2 170-1 (e.g. under control of the corresponding control module 150) is shown.

[0066] In step 410, SIM1 in the UE has UL data to be transmitted to gNB-1. In step 420, UE 110 therefore sends a scheduling request (SR) message to gNB-1 170, and in step 430, in response to the UE's scheduling request and its buffer state, receives one or more UL grants for one or more subframes (SF) from gNB-1. That is, in this example, the UE executes a scheduling request (SR) and an associated buffer state report (BSR), and the UE receives the corresponding UL grant in response. The mechanism for sending SR and BSR depends on the current UE state, including whether the UE has allocated SR resources. SR can be sent via PUCCH resources or as part of the PUSCH payload, where SR is part of uplink control information (UCI). UL grants use PDCCH. In this example, UL grants involve subframe SF. n and SF n+x While UL licensing can be used for consecutive subframes from n to n+x, this example points to two non-consecutive licenses, one in SF. n In the middle, another one is in SF n+x As shown in the figure, there are two rectangles and time intervals of 450 and 460.

[0067] In step 432, UE 110 calculates the corresponding unavailability times associated with gNB-2. For example, this could be the frame and subframe numbers of gNB-2, and these in... Figure 4 From t(SF) n (Corresponding to SF on gNB-1) n ) and t(SF n+x (Corresponding to SF on gNB-1) n+x In step 435, UE 110 sends an RRC message (in this example) to gNB-2 to notify gNB-2170-1 that the UE has completed the time interval t(SF). n ) and t(SF n+x The unavailability of ) is noted. Note that there can be multiple discontinuous time intervals within a specified time period (e.g., SF). n to SF n+x and SFN m To SFN m+y ).

[0068] In response, in step 440, gNB-2 170-1 will refrain from scheduling the UE during the informed time interval(s), e.g., by signing off. This is illustrated by time intervals 450 and 460, where the UE is not scheduled (i.e., gNB-2 does not transmit data to the UE, and the UE has no UL grant for these periods). Time intervals 450 and 460 correspond to t(SF n ) and t(SF n+x ), respectively. Note that in this exemplary embodiment, what is communicated to gNB2 is t(SF n ) and t(SF n+x ), where t(x) is a time conversion function that converts a corresponding SF to actual time, e.g., at gNB-1 170-1. gNB-2 170-1 can still override the UE’s unavailability, in case, for example, gNB-2 has high priority activity (e.g., an emergency MT call) that requires the UE to respond.

[0069] The UE performs a scheduled UL transmission to gNB-1 170 in SF n , in step 470, and performs a scheduled UL transmission to gNB-1 170 in SF n+x , in step 480.

[0070] The message in step 435 can be informed to the NW using, for example, an RRC message that is fast enough for this type of information. The RRC message can be in the uplink dedicated control channel (UL-DCCH) message class, i.e., in the set of RRC messages that can be sent from the UE to the network on the UL-DCCH logical channel. Two exemplary embodiments can then be applied, as described below.

[0071] In a first exemplary embodiment, the existing UL-DCCH message UEAssistanceInformation is modified. This message is currently used by a UE in RRC_connected state to indicate UE assistance information to the network, if the UE is configured to do so by the NW. The message is specified for the UE to provide delay budget reporting, and when a change in delay budget preference occurs, upon detecting internal overheating, or upon detecting that the UE no longer experiences an overheating situation. The exemplary embodiments herein propose to extend this message by adding the possibility for the UE to inform of its unavailability time. See the exemplary method in Figure 5 .

[0072] Figure 5 An exemplary proposal to extend the UEAssistanceInformation message by adding the possibility for the UE to inform of its unavailability time is shown. As Figure 5As shown, upon initiation of the procedure (e.g., to inform the network of the unavailability time), the UE 110 will perform the following operations:

[0073] 1> if configured to provide UE availability reports:

[0074] 2> if the UE it (UE) is configured to provide UE availability reports and has not transmitted a UEAssistanceInformation message with availablityReport; or

[0075] 2> if the current availability report is different from the one indicated in the last transmission of the UEassistanceInformation message;

[0076] 3> initiate transmission of a UEAssistanceInformation message with its availability report.

[0077] In a second example embodiment, instead, one of the three remaining spare messages can be used to introduce a new RRC message as a new UL-DCCH message class. The NW can then configure the UE to send availability information either autonomously or as a response to a NW triggered request.

[0078] In one variant of this type of signaling, the UE's availability report can be provided as a bitmap, where each position in the bitmap indicates the UE's intention to monitor for DL traffic from the serving network. The bit in the example embodiment represents a time period, which can be from a time slot to a subframe to a group of frames, etc. Since the bitmap is expected to repeat over time, the UE will be able to indicate specific periodic instances where the UE will be unavailable. This type of signaling can be used to indicate unavailability due to a need to monitor for paging messages from other network(s). Furthermore, when this periodic bitmap is no longer valid (e.g., one of the SIM cards at the UE enters an idle state), then the UE can inform the network by transmitting a new periodic bitmap.

[0079] In another variant of this type of signaling, the UE indicates a set of time instants when the UE is unavailable for scheduling by a local time reference and a duration. One example of such an indication is that the UE is unavailable for scheduling starting from system frame number (SFN) "x", time slot "y" and for a duration of "z" time slots.

[0080] Turning to the description of Type 2, it is used for dynamically scheduled activities, in which case the UE needs to quickly indicate unavailability (or extension of upcoming unavailability) to the NW (e.g., if the UE has received an indication about an upcoming paging) and the RRC message would be too slow. As is known, the uplink control information (UCI) is a physical layer payload, and thus is decoded faster than L3 payloads, which in some cases can require some communication between the gNB and the core network for proper handling. In this case, the UE signaling is dynamic in nature, and one exemplary way to provide this information is through an uplink control information (UCI) based message. In Figure 6 The signaling sequence is shown in Figure 6 as an example of this case, and the steps are described below. Figure 6 is a signaling diagram and message sequence chart according to exemplary embodiments, showing an example of a UCI message from the UE to the gNB with an “unavailable flag”. Figure 6 Signaling between the UE 110, e.g., under control of the control module 140, and the gNB-1 170 and gNB-2 170-1, e.g., under control of the corresponding control modules 150, is shown.

[0081] In step 610, each gNB supporting UE unavailability has configured the UE for a maximum (max) allowed unavailability time with a t_xxx value. In step 615, the UE 110 receives a paging (or indication of paging) from the gNB-1 170. In step 620, the UE 110 prioritizes the gNB-1 activity. In response, in step 630, the UE 110 will generate an “unavailable flag” 631 at the gNB-2, so as not to be disturbed by the UE’s inability to respond. This example uses a UCI message with information indicating UE unavailability (unavailable flag 631 with a value of “unavailable” (1 in this case)), although other signaling can be used and other than a “flag” can be used.

[0082] In step 645, the gNB-2 170-1 will consider the UE unavailable at the time of the notification, and will suspend (e.g., postpone) its activities with the UE. The term deregistering the UE at a specified time includes this suspension / postponement. The gNB-2 can still ignore the UE’s unavailability in case the gNB-2 has a high priority activity (e.g., that needs to be responded to within a specific time), which requires the UE’s response (e.g., an emergency MT call).

[0083] In this example, the UE 110 is active with gNB-1 170 in step 640 (e.g., transmitting to and / or receiving from gNB-1 170). In step 655, when the UE’s activity with gNB-1 is complete, the UE can remove the “unavailable flag” at gNB-2 170-1. This availability can be signaled to the NW through a UCI message indicating that the UE is now available (e.g., the unavailable flag 631 has a “available” value, or 0 in this example), the UCI message being transmitted through a physical uplink control channel (PUCCH) or a physical uplink shared channel (PUSCH). In response, gNB-2 170-1, in block 660, gNB-2 will resume or have the ability to resume any activity with the UE 110. That is, in step 655, gNB-2 can resume activity in response to receiving the message. The time period 665 (655-1 + 655-2) is the original time period, defined by the maximum unavailability time, with a value t_xxx, from 667-0 to 667-2, for the activity suspension. However, in this example, this time period 665 is split into a time period 655-1 (from time 667-0 to time 667-1) with activity suspension and a time period 665-2 (from time 667-1 to 667-2) with (possible) activity resumption.

[0084] Alternatively, the unavailability timer can be configured by the NW. If the UE is still unavailable when the timer value has elapsed, the UE has to explicitly reset this timer. In Figure 6 In the example of FIG. 6, the timer T starts in reference 635 with a timer value 638 of t_xxx and should end after t_xxx seconds. In block 650, if the UE is available before the time has elapsed, the timer is stopped (by the UE). If the NW does not receive a message of UE availability before the timer expires, the NW considers the UE available at the latest at the expiration of the timer T.

[0085] In one embodiment, the UCI message for unavailability can be carried on the PUCCH under the framework of a scheduling request (SR). Under the SR framework, the UE is configured with a physical resource for UL transmission. This physical resource will allow the UE to indicate to the network that the UE has data in its buffer and therefore needs a scheduling grant for UL transmission. According to exemplary embodiments, a similar physical channel can allow the UE to indicate that the UE will be unavailable for DL traffic for a specific or pre-configured amount of time.

[0086] To indicate a specific amount of time, the UE can use an UL channel capable of carrying multiple bits for the unavailability information, and in this case, the UL signaling for this can be an indication of the start and duration of the unavailability time (e.g., in a pre-defined granularity or pre-defined duration).

[0087] Now consider the time drift between USIM considerations. The commonality between these two types is that a certain degree of time accuracy is needed to ensure that the time drift of the corresponding NWs across the two USIMs does not invalidate the reported “unavailable time” before the time end arrives. To achieve this accuracy, certain example embodiments propose the following recommendations.

[0088] The UE can periodically update the time conversion (e.g., using the function t(x) above) and transmit a new report when the time drift is greater than a specified value. In example embodiments, the time drift is the time difference between the two USIMs and possibly even the two networks. The periodicity and / or max tolerable time drift can be preconfigured by the NW according to, for example, the subcarrier spacing.

[0089] The UE can add a margin to the reported “unavailable time” so that the calculated time drift does not exceed the specified value before the report is updated.

[0090] While the above example embodiments have been described using a subscriber identity module, other information can also be used. For example, a user identity can be used, e.g., using known techniques. These identities can also be determined using at least a corresponding subscriber identity module. That is, the user identity can include a subscriber identity or other user identity.

[0091] Without in any way limiting the scope, interpretation, or application of the claims appearing below, technical effects and advantages of one or more example embodiments disclosed herein include the following:

[0092] 1) The UE is not interrupted from its activity by the gNB when it is occupied for communication with another gNB. Note that “another gNB” can be the same physical node. However, the UE has independent communication for each of its subscriptions (USIMs) without knowing whether the two NBs are the same.

[0093] 2) The MUSIM device has the ability to interrupt or bypass existing network services by silently degrading the priority of certain services without notifying the network. When the NW knows that the UE is unavailable due to the other USIM, the network has the potential to optimize the performance degradation at the UE and also save network resources and traffic load that would not have been used by the UE otherwise.

[0094] As used in this application, the term “circuitry” can refer to one or more or all of the following:

[0095] (a) hardware-only circuitry (e.g., in analog and / or digital circuitry);

[0096] (b) a combination of hardware circuit(s) and software, such as (as applicable): (i) combinations of analog and / or digital hardware circuit(s) with software / firmware and (ii) combinations of hardware processors with software (including digital signal processors), software, and memory(ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions), and

[0097] (c) hardware circuit(s) and / or processor(s), such as a microprocessor(s) or a portion of microprocessor(s), that requires software (e.g., firmware) for operation, but is not working in combination with software.

[0098] This definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation that includes one or more processors and / or

[0099] Embodiments herein can be implemented in software (executed by one or more processors), hardware (e.g., an application specific integrated circuit), or a combination of software and hardware. In an example embodiment, software (e.g., application logic, an instruction set) is maintained in any of various conventional computer-readable media. In the context of this document, a "computer-readable medium" can be any media or means that can contain, store, communicate, propagate or transport the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer with one of its Figure 1 Embodiments herein can be implemented in software (executed by one or more processors), hardware (e.g., an application specific integrated circuit), or a combination of software and hardware. In an example embodiment, software (e.g., application logic, an instruction set) is maintained in any of various conventional computer-readable media. In the context of this document, a "computer-readable medium" can be any media or means that can contain, store, communicate, propagate or transport the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer with one of its

[0100] If desired, the different functions discussed herein can be performed in a different order and / or concurrently with each other. Furthermore, if desired, one or more of the above-described functions can be optional or can be combined.

[0101] While various aspects have been set forth above, other aspects include other combinations of the features described above, and not solely the combinations explicitly set forth above.

[0102] It is also noted herein that while the above describes example embodiments of the application, these descriptions should not be viewed in a limiting sense. Rather, there are several variations and modifications which can be made without departing from the scope of the present application.

[0103] The following abbreviations which can occur in the specification and / or drawings, are defined as follows:

[0104] 3GPP Third Generation Partnership Project

[0105] 5G Fifth Generation

[0106] 5GC 5G Core Network

[0107] AMF Access and Mobility Management Function

[0108] CS Circuit Switched

[0109] CU Central Unit

[0110] CW Continuous Waveform

[0111] DC Dual Connectivity

[0112] DCCH Dedicated Control Channel

[0113] DSDA Dual SIM Dual Active

[0114] DSDS Dual SIM Dual Active

[0115] DU Distributed Unit

[0116] eMBB Enhanced Mobile Broadband

[0117] eNB (or eNodeB) Evolved Node B (e.g., an LTE base station)

[0118] EN-DC E-UTRA-NR Dual Connectivity

[0119] en-gNB or En-gNB A node that provides NR user plane and control plane protocol terminations towards the UE and acts as a secondary node in EN-DC

[0120] EPC Evolved Packet Core

[0121] E-UTRA Evolved Universal Terrestrial Radio Access, i.e., LTE radio access technology

[0122] gNB (or gNodeB) A base station for 5G / NR, i.e., a node that provides NR user plane and control plane protocol terminations towards the UE and is connected via an NG interface to a 5GC

[0123] HB High Band

[0124] HW hardware

[0125] ID identification

[0126] I / F interface

[0127] IMSI international mobile subscriber identity

[0128] LB low band

[0129] LTE long term evolution

[0130] MAC medium access control

[0131] max maximum

[0132] MB mid band

[0133] MIMO multiple input multiple output

[0134] MME mobility management entity

[0135] mmW millimeter wave

[0136] MNO mobile network operator

[0137] MNVO mobile network virtual network

[0138] MT mobile terminated

[0139] MUMA multiple USIM multiple active

[0140] MUMS multiple USIM multiple standby

[0141] MUSIM multiple universal subscriber identity module

[0142] ng or NG next generation

[0143] ng-eNB or NG-eNB next generation eNB

[0144] NR new radio

[0145] N / W or NW network

[0146] PDCP packet data convergence protocol

[0147] PHY physical layer

[0148] PLMN public land mobile network

[0149] PUCCH primary physical uplink control channel

[0150] PUSCH primary physical uplink shared channel

[0151] RAN radio access network

[0152] Rel release

[0153] RLC radio link control

[0154] RNTI radio network temporary identifier

[0155] RRH remote radio head

[0156] RRC radio resource control

[0157] RSSI received signal strength indicator

[0158] RU radio unit

[0159] Rx or RX receiver or receive

[0160] SA service and system aspects

[0161] SDAP service data adaptation protocol

[0162] SF subframe

[0163] SGW serving gateway

[0164] SIB system information block

[0165] SIM subscriber identity module

[0166] SMF session management function

[0167] SR scheduling request

[0168] TR technical report

[0169] TS technical specification

[0170] Tx or TX transmitter or transmit

[0171] UCI uplink control information

[0172] UE user equipment (e.g., wireless device, typically a mobile device)

[0173] UHB ultra-high band

[0174] UL uplink (from user equipment to network)

[0175] UL-DCCH uplink dedicated control channel

[0176] UPF user plane function

[0177] USIM universal subscriber identity module

[0178] VoIP voice over Internet Protocol

[0179] VoLTE voice over long term evolution

[0180] VoNR voice over new radio

Claims

1. A method of communication, comprising: receiving, by a user equipment at the user equipment having at least two connections to at least two network nodes, a maximum allowed unavailable time from one or both of the network nodes, wherein each connection corresponds to a different user identity, wherein each user identity is determined using at least a subscriber identity module; selecting, by the user equipment, one of the at least two network nodes to communicate exclusively with the one network node during one or more time intervals; and sending, by the user equipment, one or more messages to the other of the at least two network nodes, the one or more messages indicating to the other of the at least two network nodes that the user equipment is unavailable for communication during the one or more time intervals, wherein the one or more time intervals for the other of the at least two network nodes are indicated using a function that converts one time frame from one network node to another time for the other network node to account for a time drift in communication of the user equipment with the one network node and the other network node.

2. An apparatus for communication, comprising: at least one processor; and at least one memory storing instructions that, when executed with the at least one processor, cause the apparatus to perform: receiving, by a user equipment at the user equipment having at least two connections to at least two network nodes, a maximum allowed unavailable time from one or both of the network nodes, wherein each connection corresponds to a different user identity, wherein each user identity is determined using at least a subscriber identity module; selecting, by the user equipment, one of the at least two network nodes to communicate exclusively with the one network node during one or more time intervals; and sending, by the user equipment, one or more messages to the other of the at least two network nodes, the one or more messages indicating to the other of the at least two network nodes that the user equipment is unavailable for communication during the one or more time intervals, wherein the one or more time intervals for the other of the at least two network nodes are indicated using a function that converts one time frame from one network node to another time for the other network node to account for a time drift in communication of the user equipment with the one network node and the other network node.

3. The apparatus of claim 2, wherein the instructions stored by the at least one memory, when executed with the at least one processor, cause the apparatus to perform: communicating, by the user equipment, with the selected network node during the one or more time intervals.

4. The apparatus of claim 2, wherein the instructions stored by the at least one memory, when executed using the at least one processor, cause the apparatus to select the one of the at least two network nodes in response to the user equipment determining that uplink data corresponding to a user identity needs to be transmitted and selecting the network node corresponding to the user identity.

5. The apparatus of claim 4, the instructions stored by the at least one memory, when executed using the at least one processor, cause the apparatus to receive, by the user equipment, an uplink grant indicating a time period to be used for uplink transmission of the uplink data and set the one or more time intervals to the time period.

6. The apparatus of claim 5, wherein the time period comprises one or more subframes, one or more frames, a group of frames, one or more time slots, one or more symbols, or a specific time interval in seconds.

7. The apparatus of claim 5, wherein there are multiple discontinuous time intervals within the indicated time period.

8. The apparatus of claim 5, wherein the instructions stored by the at least one memory, when executed using the at least one processor, cause the apparatus to send, by the user equipment, one or more messages further comprise sending the one or more messages using radio resource control signaling indicating the time period.

9. The apparatus of claim 8, wherein the one or more messages comprise a user equipment availability report.

10. The apparatus of claim 2, wherein the instructions stored by the at least one memory, when executed using the at least one processor, cause the apparatus to: in response to the user equipment being configured to provide a user equipment availability report, the user equipment performs the following: transmit, by the user equipment, a current availability report in response to the user equipment not transmitting an availability report since the user equipment was configured to provide the user equipment availability report; or transmit, by the user equipment, the current availability report in response to the current availability report being different from an availability report indicated in a last transmission of an availability report.

11. The apparatus of claim 2, wherein the instructions stored by the at least one memory, when executed using the at least one processor, cause the apparatus to select the one of the at least two network nodes in response to the user equipment receiving a page or an indication of the page from the selected network node, and selecting the network node corresponding to the received page or indication of the page.

12. The apparatus of claim 11, wherein a maximum allowed unavailable time is divided into a time period for suspending activity and a time period for resuming activity.

13. The apparatus of claim 11, wherein the one or more messages indicate to the other network node that the user equipment is unavailable, but do not indicate a corresponding one or more time intervals, as the other network node is to associate the maximum allowed unavailable time as a time period during which the user equipment is unavailable for communication with the other network node.

14. The apparatus of claim 11, wherein the instructions stored by the at least one memory, when executed with the at least one processor, cause the apparatus to perform: sending, by the user equipment, one or more messages to the other network node indicating that the user equipment is now available for communication prior to expiration of the maximum allowed unavailable time.

15. The apparatus of claim 13, wherein the one or more messages indicating that the user equipment is now available for communication comprise uplink control information messages that are transmitted over one of a physical uplink control channel or a physical uplink shared channel.

16. The apparatus of claim 2, wherein the instructions stored by the at least one memory, when executed with the at least one processor, cause the apparatus to perform: setting, by the user equipment, a time for responding with an availability message in response to sending the one or more messages to the other of the at least two network nodes, and in response to expiration of the time: performing, by the user equipment, no action with respect to sending additional messages indicating availability in response to the user equipment completing the dedicated communication; and sending, by the user equipment to the other of the at least two network nodes, additional one or more messages indicating to the other of the at least two network nodes that the user equipment is unavailable for communication during additional one or more time intervals in response to the user equipment not completing the dedicated communication.

17. The apparatus of claim 2, wherein the instructions stored by the at least one memory, when executed with the at least one processor, cause the apparatus to perform: periodically updating, by the user equipment, the function and transmitting, by the user equipment to the other network node, further one or more messages in response to the time drift being greater than a specified value.

18. An apparatus for communication, comprising: at least one processor; and at least one memory storing instructions that, when executed with the at least one processor, cause the apparatus to perform: sending, at a network node having a connection to a user equipment based on a user identity, a maximum allowed unavailable time to the user equipment, wherein the user equipment has at least two connections to at least two network nodes, wherein each connection corresponds to a different user identity, wherein each user identity is determined using at least a subscriber identity module; receiving, by the network node from the user equipment, one or more messages indicating that the user equipment is unavailable for communication during one or more time intervals; and ​ not to communicate with the user equipment by the network node during the indicated one or more time intervals, wherein the one or more time intervals for another network node of the at least two network nodes are indicated using a function that converts one time frame from one network node to another time of another network node to account for time drift in communication of the user equipment with the one network node and the another network node.

Images