Multi-SIM call setup optimization for inactive states

Abstract

A user equipment (UE) configured to enter an RRC inactive state on a first network using a first SIM and to enter an RRC inactive state or an RRC idle state on a second network using a second SIM; initiating, on the first SIM, RRC recovery comprising a recovery request, the recovery request comprising a cause indication; during the RRC recovery, decoding a trigger of a service on the second SIM having a higher priority than the RRC recovery; initiating a multi-SIM pause procedure on the first SIM based on the trigger, the multi-SIM pause procedure comprising a multi-SIM pause request from the NAS entity of the first SIM to the RRC entity of the first SIM; and at the RRC entity of the first SIM, delaying execution of the multi-SIM pause request until a response to an RRC recovery request is received from the first network.

Description

[0001] Inventors: A.K. Singh, A. Venugopal and Xiaolin Zhao

[0002] Priority / Incorporation by Reference

[0003] This application claims priority to U.S. Provisional Application Serial No. 63 / 376,662, filed on September 22, 2022, entitled “Multi-SIM Call Setup Optimizations For Inactive State,” the entire contents of which are incorporated herein by reference. Background Art

[0004] A user equipment (UE) may be equipped with multiple subscriber identity modules (SIMs), and each SIM may enable the UE to establish an independent network connection. Thus, a multi-SIM UE may establish a first network connection using a first SIM, and a second network connection using a second SIM.

[0005] During multi-SIM operation, a UE may be in a radio resource control (RRC) inactive state on a first SIM with a first network (e.g., a 5G New Radio (NR) radio access network (RAN)) and may be in an idle or inactive state on a second SIM with a second network. The UE may initiate or receive a trigger (e.g., a paging message) for an RRC recovery procedure on the first SIM, for example, to enter an RRC connected state, perform a RAN-based Notification Area (RNA) procedure, or for other reasons. The RRC recovery procedure requires multiple processing steps at the lower layers of the UE, as well as signaling exchanges with the network, which may last, for example, hundreds of milliseconds. During the recovery operation on the first SIM, the second SIM may request a service, for example, a high priority voice call may be triggered. The UE behavior in this scenario is not well defined and may depend on the UE specific implementation. In one example, the UE may terminate the recovery operation on the first SIM early and provide Layer 1 (L1) resources to the second SIM. However, such behavior may lose the RRC inactive context on the first SIM (e.g., causing the first SIM to enter an RRC idle state) and / or cause an RRC context mismatch between the UE and the first network. Summary of the invention

[0006] Some exemplary embodiments relate to an apparatus of a user equipment (UE), the apparatus having a processing circuit configured to: enter a radio resource control (RRC) inactive state on a first network using a first subscriber identity module (SIM) and enter an RRC inactive state or an RRC idle state on a second network using a second SIM; initiate an RRC recovery procedure on the first SIM, the RRC recovery procedure comprising sending a recovery request including a cause indication from a non-access stratum (NAS) entity of the first SIM to an RRC entity of the first SIM; during the RRC recovery procedure on the first SIM, based on a signal received from a base station, decoding a trigger of a service on the second SIM having a higher priority than the RRC recovery procedure on the first SIM; based on the trigger of the service on the second SIM, initiating a multi-SIM suspension procedure on the first SIM, the multi-SIM suspension procedure comprising sending a multi-SIM suspension request from the NAS entity of the first SIM to the RRC entity of the first SIM; and delaying execution of the multi-SIM suspension request at the RRC entity of the first SIM until a response to the RRC recovery request is received from the first network.

[0007] Other exemplary embodiments relate to a user equipment (UE) having a transceiver configured to communicate with a first network and a second network and a processor communicatively coupled to the transceiver. The processor is configured to: enter a radio resource control (RRC) inactive state on the first network using a first subscriber identity module (SIM) and enter an RRC inactive state or an RRC idle state on the second network using a second SIM; initiate an RRC recovery procedure on the first SIM, the RRC recovery procedure comprising sending a recovery request including a cause indication from a non-access stratum (NAS) entity of the first SIM to an RRC entity of the first SIM; during the RRC recovery procedure on the first SIM, based on a signal received from a base station, a trigger of a service on the second SIM having a higher priority than the RRC recovery procedure on the first SIM is decoded; based on the trigger of the service on the second SIM, a multi-SIM suspension procedure is initiated on the first SIM, the multi-SIM suspension procedure comprising sending a multi-SIM suspension request from the NAS entity of the first SIM to the RRC entity of the first SIM; and delay execution of the multi-SIM suspension request at the RRC entity of the first SIM until a response to the RRC recovery request is received from the first network. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1 Exemplary network arrangements are shown according to various exemplary embodiments.

[0009] Figure 2 An exemplary multi-SIM UE is shown according to various exemplary embodiments.

[0010] Figure 3 An exemplary network base station is shown according to various exemplary embodiments.

[0011] Figure 4 A signaling diagram for multi-SIM (MSIM) high priority call handling is shown according to an example, when a high priority call is triggered on a second SIM (SIM B) of a multi-SIM UE while an RRC recovery procedure is in progress for a first SIM (SIM A) of the UE.

[0012] Figure 5 A signaling diagram for multi-SIM (MSIM) high priority call handling is shown according to a first aspect of these exemplary embodiments, when a high priority call is triggered on a second SIM (SIMB) of a multi-SIM UE while an RRC recovery procedure is in progress for a first SIM (SIM A) of the UE.

[0013] Figure 6 A signaling diagram for multi-SIM (MSIM) high priority call handling is shown according to a second aspect of these exemplary embodiments, when a high priority call is triggered on a second SIM (SIMB) of a multi-SIM UE while an RRC recovery procedure is in progress for a first SIM (SIM A) of the UE.

[0014] Figure 7 A signaling diagram for multi-SIM (MSIM) high priority call handling is shown according to a third aspect of these exemplary embodiments, when a high priority call is triggered on a second SIM (SIMB) of a multi-SIM UE while an RRC recovery procedure is in progress for a first SIM (SIM A) of the UE.

[0015] Figure 8 According to a fourth aspect of these exemplary embodiments, a signaling diagram for multi-SIM (MSIM) high priority call handling is shown when a high priority call is triggered on a second SIM (SIMB) of a multi-SIM UE while an RRC recovery procedure is in progress for a first SIM (SIM A) of the UE.

[0016] Fig. 9 According to a fifth aspect of these exemplary embodiments, a signaling diagram for multi-SIM (MSIM) high priority call handling is shown when a high priority call is triggered on a second SIM (SIMB) of a multi-SIM UE while an RRC recovery procedure is in progress for a first SIM (SIM A) of the UE. DETAILED DESCRIPTION

[0017] The exemplary embodiments may be further understood with reference to the following description and related drawings, in which like elements are provided with like reference numerals. The exemplary embodiments describe operations of a user equipment (UE) to maintain a radio resource control (RRC) inactive state on a first SIM and / or avoid an RRC state mismatch with a network during multiple subscriber identity module (SIM) operations when an RRC recovery procedure on the first SIM is interrupted by a service request on a second SIM.

[0018] In some aspects, the RRC entity of the first SIM may save the suspension request from the multi-SIM manager of the UE or delay the execution of the suspension request until a response to the resume request on the first SIM is received from the network. After receiving the response, the UE may first process the response (and possibly maintain an inactive context on the first SIM), and then process the multi-SIM suspension request to allow high priority services on the second SIM. In other aspects, the RRC entity of the first SIM may terminate the RRC resumption procedure early while ensuring that the network and the UE have (or will have) matching RRC contexts. In one embodiment, the UE provides UE assistance information to the network indicating a preferred RRC state.

[0019] The exemplary embodiments provide a mechanism to enable the UE to maintain an inactive context while minimizing signaling between the UE and the network and avoiding the need for a Tracking Area Update (TAU) procedure. This can save UE power, improve user experience, and optimize the use of network resources.

[0020] The exemplary embodiments are described with reference to UE. However, reference to UE is provided for illustration purposes only. The exemplary embodiments may be used with any electronic component that can establish a connection with a network and is configured with hardware, software and / or firmware for exchanging information and data with the network. Therefore, the UE described herein is used to represent any electronic component.

[0021] Throughout the specification, the UE is characterized as a multi-SIM UE. The term "multi-SIM UE" may refer to a UE equipped with multiple (e.g., two or more) SIMs. Each SIM may be used to establish an independent network connection, and each network connection may exist simultaneously. Therefore, each SIM may be associated with: its own phone number and / or a contract with a cellular service provider. Therefore, a single UE may be associated with two or more phone numbers and / or subscriptions. Throughout the specification, in order to distinguish between SIMs, reference will be made to a first SIM (SIM A) connected to a first network (NW) (NW A) and a second SIM (SIM B) connected to a second network (NWB). However, this is only used to distinguish between the two SIMs and is not intended to indicate that there is any priority / preference between SIM A or SIM B. In one example, SIM A refers to a SIM with simId=0, and SIM B refers to a SIM with simID=1 stored locally at the UE. In addition, SIM A, SIM B, NW A, and NW B are described only for illustrative purposes, and the principles described in the present disclosure may be applied to any number of SIMs and network combinations.

[0022] It will be appreciated by those skilled in the art that a SIM contains information used by a UE to establish a network connection. For example, a SIM may include an International Mobile Subscriber Identifier (IMSI) that may be used to authenticate a network provider. A user may have a first subscription with a cellular service provider enabled by SIMA and a second subscription with a cellular service provider enabled by SIM B. A network to which a UE may connect using SIM A may be referred to as Network A (NW A), and a network to which a UE may connect using SIM B may be referred to as Network B (NW B). In one example, the same cellular service provider is associated with both SIM A and SIM B. In another example, a different cellular service provider is associated with each SIM. References to any particular type of information contained within a SIM are provided for illustrative purposes only. A SIM may contain a wide variety of different types of information that may be referred to by different names for different networks or different entities. Therefore, the exemplary embodiments may be applicable to a SIM containing any type of information used by a multi-SIM UE to establish a network connection.

[0023] Throughout the specification, reference is made to a SIM that performs functions (e.g., communicates with a wireless network). However, those skilled in the art will appreciate that the SIM itself does not perform any functions or operations. Instead, the UE, or more precisely the processor of the UE, uses the credentials and other information stored on the SIM to implement one or more protocol stacks, which are then used to establish a connection with the network. Therefore, when reference is made to the SIM communicating with the network, this should be understood to include the UE or the processor of the UE communicating via a connection associated with the SIM. Similarly, any other operations attributed to the SIM herein should be understood as operations performed by the protocol stack implemented by the processor using information provided by the SIM.

[0024] The exemplary embodiments will be described with respect to a Multi-SIM UE equipped with two SIMs, for example, SIM A and SIM B. However, those skilled in the art will appreciate that the exemplary embodiments may also be applicable to devices having more than two SIMs.

[0025] The multi-SIM UE may utilize the same hardware, software, and / or firmware components to perform operations associated with a network connection associated with SIM A and a network connection associated with SIM B. For example, the multi-SIM UE may be configured to use the same transceiver to perform operations associated with both network connections. Using the same component to perform operations for both network connections may create a scenario where the multi-SIM UE is unable to perform operations associated with a network connection associated with one of SIM A or SIM B because the multi-SIM UE is currently using the component to perform operations associated with a network connection associated with the other SIM.

[0026] A multi-SIM UE may be in an RRC inactive state on NW A with SIM A, and in an RRC inactive state or an RRC idle state on NW B with SIM B. An RRC recovery procedure may be initiated on SIM A for any of a variety of reasons, such as to enter an RRC connected state, to perform a RAN-based Notification Area (RNA) procedure, or for other reasons. During the RRC recovery operation on the first SIM, a second SIM may request a high priority service, such as a high priority voice call may be triggered. Example embodiments describe operations for providing the UE with an opportunity to re-enter an RRC inactive state on SIM A (and NW A) and / or to avoid an RRC context mismatch with NW A in the event that the RRC recovery procedure ends prematurely.

[0027] Figure 1A network arrangement 100 according to an exemplary embodiment is shown. The network arrangement 100 includes a multi-SIM UE 110, which includes at least two SIMs. Those skilled in the art will understand that the multi-SIM UE 110 can be any type of electronic component configured to communicate via a network, such as a mobile phone, a tablet, a smart phone, a phablet, an embedded device, a wearable device, a Cat-M device, a Cat-M1 device, an MTC device, an eMTC device, other types of Internet of Things (IoT) devices, etc. A practical network arrangement may include any number of UEs used by any number of users. Therefore, the example of a single multi-SIM UE 110 is provided for illustrative purposes only.

[0028] The multi-SIM UE 110 may communicate with one or more networks. In the example of the network configuration 100, the networks with which the multi-SIM UE 110 may wirelessly communicate are a 5G New Radio (NR) radio access network (5G NR-RAN) 120, an LTE radio access network (LTE-RAN) 122, a legacy access network (legacy RAN), and a wireless local access network (WLAN) 126. However, the multi-SIM UE 110 may also communicate with other types of networks, and the multi-SIM UE 110 may also communicate with the network through a wired connection. Thus, the multi-SIM UE 110 may include a 5G NR chipset that communicates with the 5G NR-RAN 120, an LTE chipset that communicates with the LTE-RAN 122, a legacy chipset that communicates with the legacy RAN 124, and an ISM chipset that communicates with the WLAN 126.

[0029] The multi-SIM UE 110 may establish multiple independent network connections that may exist simultaneously. For example, the multi-SIM UE 110 may establish a first network connection using SIM A and a second network connection with a network using SIM B. The first network connection and the second network connection may be independent of each other and exist simultaneously. In the example of the network configuration 100, the multi-SIM UE 110 is pre-occupied on the gNB 120A of the 5G NR-RAN 120 for the first network connection and is pre-occupied on the eNB 122A of the LTE-RAN 122 for the second network connection. However, this is provided for illustration purposes only. For example, the multi-SIM UE 110 may establish a first network connection and a second network connection to the 5G NR-RAN 120 via the gNB 120A. In another example, the multi-SIM UE 110 may establish a first network connection to the 5G NR-RAN 120 via the gNB 120A and establish a second network connection to the traditional RAN 124 via the corresponding base station 124A. Therefore, in an actual network configuration, the multi-SIM UE 110 may camp on a first cell corresponding to a first network for a first network connection and a second cell corresponding to a second network for a second network connection.

[0030] 5G NR-RAN 120, LTE-RAN 122, and legacy RAN 124 may be parts of cellular networks that may be deployed by cellular providers (e.g., Verizon, AT&T, T-Mobile, etc.). These networks 120, 122, 124 may include, for example, base stations (NodeB, eNodeB, HeNB, eNBS, gNB, gNodeB, macrocell base stations, microcell base stations, small cell base stations, femtocell base stations, etc.) configured to transmit and receive traffic from UEs equipped with appropriate cellular chipsets. WLAN 126 may include any type of wireless local area network (WiFi, hotspot, IEEE 802.11x network, etc.).

[0031] The base station (e.g., gNB 120A, eNB 122A, base station 124A) may include one or more communication interfaces to exchange data and / or information with the occupied UE, the corresponding RAN, the cellular core network 130, the Internet 140, etc. In addition, the base station may include a processor configured to perform various operations. For example, the processor of the base station may be configured to perform operations related to paging. However, reference to the processor is for illustrative purposes only. The operation of the base station may also be represented as an independent combined component of the base station, or may be a modular component coupled to the base station, such as an integrated circuit with or without firmware. For example, the integrated circuit may include an input circuit for receiving a signal and a processing circuit for processing the signal and other information. In addition, in some base stations, the functionality of the processor is shared between two or more processors such as a baseband processor and an application processor. The exemplary embodiment may be implemented in any of these or other configurations of the base station.

[0032] Those skilled in the art will appreciate that any relevant procedures may be performed to connect the multi-SIM UE 110 to the 5G NR-RAN 120, the LTE-RAN 122, and the traditional RAN 124. To provide an example, the 5G NR-RAN 120 may be associated with a specific cellular service provider at which the multi-SIM UE 110 and / or its user has protocol and credential information (e.g., stored on each of SIM A and SIM B). In the case of a multi-SIM UE 110, each SIM will independently connect to the corresponding network. Upon detecting the presence of the 5G NR-RAN 120, the multi-SIM UE 110 may send the corresponding credential information in order to associate with the 5G NR-RAN 120. More specifically, the multi-SIM UE 110 may be associated with a specific cell (e.g., the gNB 120A of the 5G NR-RAN 120). Similar association procedures may be performed for the multi-SIM UE 110 to connect to the LTE-RAN 122 and the traditional RAN 124.

[0033] In addition to the networks 120, 122, 124, and 126, the network arrangement 100 includes a cellular core network 130, the Internet 140, an IP multimedia subsystem (IMS) 150, and a network service backbone 160. The cellular core network 130 can be viewed as an interconnected set of components that manage the operation and services of the cellular network. The cellular core network 130 also manages the services that flow between the cellular network and the Internet 140. The IMS 150 can generally be described as an architecture for delivering multimedia services to multiple SIM UEs 110 using IP protocols. The IMS 150 can communicate with the cellular core network 130 and the Internet 140 to provide multimedia services to multiple SIM UEs 110. The network service backbone 160 communicates directly or indirectly with the Internet 140 and the cellular core network 130. The network service backbone 160 can generally be described as a set of components (e.g., servers, network storage arrangements, etc.) that implement a set of services that can be used to extend the functionality of multiple SIM UEs 110 to communicate with various networks.

[0034] Figure 2 An exemplary multi-SIM UE 110 is shown according to various exemplary embodiments. Figure 1 100 is used to describe a multi-SIM UE 110. The multi-SIM UE 110 may represent any electronic device and may include a processor 205, a memory arrangement 210, a display device 215, an input / output (I / O) device 220, a transceiver 225, and other components 230. The other components 230 may include, for example, an audio input device, an audio output device, a battery providing a limited power source, a data acquisition device, a port for electrically connecting the multi-SIM UE 110 to other electronic devices, a sensor for detecting the status of the UE 110, etc. The multi-SIM UE 110 may include a SIM A 240 and a SIM B 245. However, as described above, the exemplary embodiments may be applicable to UEs equipped with more than two SIMs.

[0035] The processor 205 may be configured to execute multiple engines of the multi-SIM UE 110. For example, the engine may include an RRC recovery engine 235. The RRC recovery engine 235 may perform operations to handle the following scenario: an RRC recovery procedure is in progress on a first SIM (e.g., SIM A) and a high priority service is requested on a second SIM (e.g., SIM B). The operations performed by the RRC recovery engine 235 may depend on the reason for the RRC recovery procedure, for example, whether the RRC recovery is for an RNA procedure. The RRC recovery engine 235 may save the multi-SIM suspension request until a response to the RRC recovery request is received from the network, whereby the UE will first process the response and then perform the multi-SIM suspension request. The RRC recovery engine 235 may also provide UE assistance information to the network to indicate a preferred RRC state. Examples of these operations will be described in more detail below.

[0036] The above-described engine as an application (e.g., program) executed by the processor 205 is merely exemplary. The functionality associated with the engine may also be represented as an independent combined component of the multi-SIM UE 110, or may be a modular component coupled to the multi-SIM UE 110, such as an integrated circuit with or without firmware. For example, the integrated circuit may include an input circuit for receiving a signal and a processing circuit for processing the signal and other information. The engine may also be embodied as an application or multiple independent applications. In addition, in some UEs, the functionality described for the processor 205 is shared between two or more processors, such as a baseband processor and an application processor. The exemplary embodiments may be implemented in any of these or other configurations of the UE.

[0037] The memory 210 may be a hardware component configured to store data related to operations performed by the multi-SIM UE 110. As will be described in further detail below, when performing a determination of an operating mode, the memory 210 may store data associated with the status of the multi-SIM UE 110. The display device 215 may be a hardware component configured to display data to a user, and the I / O device 220 may be a hardware component that enables a user to enter input. The display device 215 and the I / O device 220 may be separate components or may be integrated together (such as a touch screen).

[0038] The transceiver 225 may be a hardware component configured to establish a connection with the LTE-RAN 120, LTE-RAN 122, traditional RAN 124, and WLAN 126, etc. Therefore, the transceiver 225 may operate on a plurality of different frequencies or channels (e.g., a continuous frequency group). The transceiver 225 includes a circuit configured to send and / or receive signals (e.g., a control signal, a data signal). Such signals may be encoded with information for implementing any of the methods described herein. The processor 205 may be operably coupled to the transceiver 225 and configured to receive signals from the transceiver 225 and / or send signals to the transceiver. The processor 205 may be configured to encode and / or decode signals (e.g., signaling from a base station of a network) for implementing any of the methods described herein.

[0039] Figure 3 An exemplary network cell, in this case a gNB 120A, is shown according to various exemplary aspects. As described above with respect to UE 110, gNB 120A may represent a serving cell for UE 110. gNB 120A may represent any access node belonging to a 5G NR network that UE 110 may use to establish a connection and manage network operations.

[0040] The gNB 120A may include a processor 305, a memory arrangement 310, an input / output (I / O) device 320, a transceiver 325, and other components 330. The other components 330 may include, for example, an audio input device, an audio output device, a battery, a data acquisition device, a port for electrically connecting the gNB 120A to other electronic devices, and the like.

[0041] The processor 305 may be configured to perform various operations for the gNB 120A. For example, the processor may perform an RRC recovery procedure with a UE that is in an RRC inactive state. The operations described above as an application (e.g., a program) executed by the processor 305 are merely exemplary. The functionality may also be represented as an independently combined component of the gNB 120A, or may be a modular component coupled to the gNB 120A, such as an integrated circuit with or without firmware. For example, the integrated circuit may include input circuits for receiving signals and processing circuits for processing signals and other information. In addition, in some gNBs, the functionality described for the processor 305 is split between multiple processors (e.g., a baseband processor, an application processor, etc.). The exemplary aspects may be implemented in any of these or other configurations of the gNB.

[0042] Memory 310 may be a hardware component configured to store data related to operations performed by UE 110. I / O device 320 may be a hardware component or port that enables a user to interact with gNB 120A.

[0043] The transceiver 325 may be a hardware component configured to exchange data with the UE 110 and any other UE in the system 100. The transceiver 325 may operate on a variety of different frequencies or channels (e.g., a continuous frequency set). Therefore, the transceiver 325 may include one or more components (e.g., a radio component) to enable data exchange with various networks and UEs. The transceiver 320 includes a circuit configured to send and / or receive signals (e.g., control signals, data signals). Such signals may be encoded with information that implements any of the methods described herein. The processor 305 may be operably coupled to the transceiver 320 and configured to receive signals from the transceiver 320 and / or send signals to the transceiver. The processor 305 may be configured to encode and / or decode signals (e.g., signaling from the UE) for implementing any of the methods described herein.

[0044] The Radio Resource Control (RRC) protocol includes a state machine that defines the operating states of the UE, each state having different radio resources associated with it. In 5G NR and in LTE, the RRC states include an RRC connected state, an RRC inactive state, and an RRC idle state. The UE enters the RRC idle state when it is powered on, and can perform operations including receiving broadcast messages, receiving paging messages, PLMN selection, and cell reselection mobility. While in the RRC idle state, the UE follows a discontinuous reception (DRX) cycle for periodically waking up to listen to paging messages from the network. The UE is not registered to the cell and has no access stratum (AS) context. The UE can perform initial access operations (including random access (RACH) procedures) to pre-camp on a network cell and enter the RRC connected state to establish a network connection with the network and exchange transmissions. If there is no communication traffic to or from the UE for some predefined time period while in the RRC connected state, the network can suspend the RRC connection and instruct the UE to enter the RRC inactive state. In the RRC inactive state, the UE can perform operations similar to the RRC idle state. In addition, the access stratum (AS) context can be saved at the UE and the network, allowing the UE to quickly re-enter the RRC connected state using the recovery procedure when network activity for the UE is received at the UE / network. A UE in the RRC inactive state can resume a suspended RRC connection in a scenario when, for example, the UE is to enter the RRC connected state, the UE is to perform an RNA update, or when a paging message is received from the 5G RAN.

[0045] A RAN-based Notification Area (RNA) relates to an area in which a UE in an RRC inactive state can move without notifying the RAN. The last serving gNB saves the UE context, and if downlink data / signaling for the UE is received from the AMF or UPF, the gNB may instruct the cell in the RNA to page the UE. When the UE is configured for an inactive state, the gNB may configure the UE with a timer value (e.g., a t380 timer) for triggering a periodic RNA update after the timer expires. The RNA update may also be initiated by the UE when the UE moves out of the configured RNA. The RNA update is performed via an RRC recovery procedure, where the recovery cause in the UE recovery request is set to rna-Update. The gNB may also configure a second timer value (e.g., a t319 timer) for the UE to receive a response after the UE sends an RRC recovery request, where the expiration of the timer causes the UE to enter the RRC idle state and indicates the cause value of the RRC recovery failure.

[0046] The RRC recovery procedure includes a contention-based random access (RACH) procedure, in which an RRC recovery request is sent in MSG3. The UE recovery request (RRCResumeRequest or RRCResumeRequest1) may indicate one of the following: emergency, highPriorityAccess, mt-Access, mo-Signalling, mo-Data, mo-VoiceCall, mo-VideoCall, mo-SMS, rna-Update, mps-PriorityAccess, or mcs-PriorityAccess. The gNB receiving the recovery request may move the UE to the RRC connected state (RRCResume or RRCSetup), the RRC idle state (RRCRelease), or the RRC inactive state (RRCRelease with suspension configuration, or RRCReject).

[0047] When an RNA update is requested, in many cases the network will respond with an RRCRelease with a suspended configuration that includes the RNA configuration, which may be a new configuration or the same configuration that was previously used. The UE re-enters the RRC Inactive state with a new t380 timer value and may use this RNA configuration until another RNA update is initiated / triggered.

[0048] Multi-SIM operation is defined in 3GPP TS 38.331 and 38.304. A multi-SIM UE may be in an RRC inactive state on NW A with SIM A, and in an RRC inactive state or an RRC idle state on NW B with SIM B. An RRC recovery procedure may be initiated on SIM A to perform an RNA update or for another reason, and during the RRC recovery operation on SIM A, SIM B may request a high priority service, for example, a high priority voice call may be triggered. Currently, these 3GPP specifications do not specify handling of this situation. In particular, it is not specified how the access stratum (AS) inactive context of SIM A should be handled. Currently, UE vendors leave this to proprietary UE specific implementations. In one example, the UE may end (e.g., terminate) the ongoing recovery procedure early, discard the RRC inactive context and enter the RRC idle state on SIM A to provide UE layer 1 (L1) resources to SIM B for the high priority call.

[0049] Figure 4 A signaling diagram 400 for multi-SIM (MSIM) high priority call handling is shown according to an example when a high priority call is triggered on a second SIM (SIM B) of a multi-SIM UE while an RRC recovery procedure is in progress for a first SIM (SIM A) of the UE. The signaling diagram 400 includes a first non-access stratum (NAS) entity 408 of the first SIM (NAS_SIM A), an NR RRC entity 410 of the first SIM (NR_RRC_SIM A), a second NAS entity 402 of the second SIM (NAS_SIM B), and an RRC entity 404 of the second SIM (x_RRC_SIM B). For example, the UE may have a first subscription to a first network (NW A) enabled by the first SIM (SIM A) and a second subscription to a second network (NW B) enabled by the second SIM (SIM B). The first SIM may be associated with a first ID (simID=0) and the second SIM may be associated with a second ID (simID=1). In this example, NW A is a 5G NR RAN, and NW B may represent any suitable RAT for performing voice calls, such as NR, LTE, etc. (indicated by the "x" of the second RRC entity 404 of SIM B). The signaling diagram 400 also includes a multi-SIM manager 406 (MSIM_MGR) for managing multi-SIM functionality of the UE. The first RRC entity 410 of SIM A may communicate with a gNB 412 of the 5G NR RAN. The gNB may be a serving gNB associated with the current RNA or a serving gNB associated with a different RNA.

[0050] In this example scenario, SIM A is in RRC inactive state and maintains an RRC inactive context for the access stratum (AS) at the UE (NR_RRC_SIM A 410) and the network (e.g., at gNB 412 or another gNB (e.g., the last serving gNB in ​​the RNA)). SIM B is in RRC idle state and maintains an RRC idle context at the UE (x_RRC_SIM B 404) with the corresponding network of SIM B, which can be the same network as SIM A (e.g., 5G NR RAN) or a different network. The RRC recovery procedure can be initiated on SIM A for a variety of reasons. In this example, the RRC recovery procedure is initiated for RNA update, which can be triggered based on, for example, the expiration of a T380 timer, the UE moving to a different RNA, or a paging received from gNB 412.

[0051] In 414, the first NAS entity 408 of SIM A sends an RRC recovery approval request indicating the SIM ID of SIM A (e.g., simID=0) to the MSIM manager 406. In 416, the MSIM manager 406 sends an RRC recovery approval confirmation including the SIM ID of SIM A to the first NAS entity 408. In 418, the NAS entity 408 of SIM A sends the recovery request to the RRC entity 410 of SIM A. In this example, the reason for the recovery request indicates RNA update.

[0052] When an RRC recovery request is received at the RRC entity 410 of SIM A, various operations then occur in the lower layers of the SIM A protocol stack and the network. For example, a RACH process is initiated so that the RRC recovery request can be transmitted to the gNB 412. The RRC recovery process is not completed until a response (e.g., RRCReject, RRCResume, RRCSetup, or RRCRelease) is received from the network and the UE implements the appropriate configuration. The execution of these operations typically takes several hundred milliseconds. As described above, when an RNA update is requested, the network can respond with RRCReject or RRCRelease. The following will describe the RRC recovery process. Figures 5 to 9 The exemplary embodiments of the present invention describe in more detail the signaling exchanges between the UE and the network for various types of RRC recovery procedures.

[0053] While the MSIM manager 406 is waiting for the resume confirmation from the NAS entity 408 of SIM A, a high priority voice call may be triggered on the second SIM (SIM B) of the UE.

[0054] In 420, the second NAS entity 402 of SIM B sends an RRC setup approval request including the SIM ID of SIM B (simId=1) and a cause value indicating a voice call to the MSIM manager 406. The MSIM manager 406 may determine that the voice call on SIM B has a higher priority than the RNA update on SIM A, and determine to provide layer 1 resources to SIM B.

[0055] In 422, the MSIM manager 406 sends an RRC suspend request to the first NAS entity 408 of SIM A. In this example, the first NAS entity 408 has not received a resume confirmation for RNA update from the first RRC entity 410. In 424, the first NAS entity 408 sends a multi-SIM suspend request to the first RRC entity 410 of SIM A.

[0056] Upon receiving the multi-SIM suspension request, the first RRC entity 410 locally releases the ongoing RRC recovery procedure. Therefore, the RRC recovery operation ends early regardless of the stage the procedure is currently in. For example, the UE may not have sent an RRC recovery request to the gNB, or the UE may be waiting for a response to an RRC recovery request that has been sent. When the RRC recovery operation ends early, the UE locally deletes the SIM A inactive context, and SIM A enters the RRC idle state. The network (e.g., gNB 412) may not be aware that the UE has entered the RRC idle state.

[0057] In 426, the first RRC entity 410 of SIM A sends a multi-SIM suspension confirmation to the first NAS entity 408. In 428, the first NAS entity 408 sends a suspension confirmation to the MSM manager 406. In 430, the MSIM manager 406 sends a setup approval confirmation to the second NAS entity 402 of SIM B to indicate the SIM ID of SIM B (e.g., simID=1) and a cause value indicating a voice call. The voice call can then be started on SIM B.

[0058] Above Figure 4 There are various disadvantages to the procedures described in . In some scenarios, the rrcResume procedure for SIM A has not yet been completed and the inactive context for the SIM A RRC entity has been deleted. In use cases such as receiving rrcReject or rrcRelease (suspendConfig=true) in response to rrcResumeRequest / 1 (cause=rna-Update), the UE loses a good opportunity to keep the RRC inactive context and therefore loses all the benefits of the end-to-end system specified by 3GPP for the RRC inactive state.

[0059] In addition, after the call on SIM B ends, SIM A must perform a RACH procedure and initiate an RNA update again with the network. This requires multiple over-the-air (OTA) message exchanges between the UE and the network, which is inefficient in terms of air interface resources for both the network and the UE. In addition, during this re-establishment process on SIM A, SIM B again temporarily stops using its Tx and Rx capabilities.

[0060] In addition, in some scenarios, there is a context mismatch issue for UE and NW. When interrupted by SIM B, SIM A has deleted the entire inactive context before the random access of rrcResumeRequest / 1 succeeds. The UE will be in RRC idle state and the gNB will be in RRC inactive state.

[0061] The exemplary embodiments describe operations for providing the UE with an opportunity to re-enter the RRC inactive state on a first SIM (SIM A) and / or to avoid an RRC context mismatch with the network of SIM A (NW A) in the event that the RRC recovery procedure on SIM A ends prematurely. For example, as described above, the RRC recovery procedure on SIM A may be interrupted by a high priority call trigger on a second SIM (SIM B). In some embodiments, the UE may allow the RRC recovery procedure on SIM A to continue before suspending the RRC connection and switching to SIM B. In other embodiments, the UE terminates the RRC recovery procedure on SIM A prematurely only after receiving an RRC recovery response from the network / gNB, and based on the response (e.g., if RRCResume is received), UE assistance information may be provided to the network to indicate a preferred RRC state (e.g., RRC idle).

[0062] In some aspects of these example embodiments, with respect to an NR RRC entity of a first SIM currently performing an (ongoing) RRC recovery procedure on the first SIM, the NR RRC entity may receive and save a multi-SIM suspend request received from the multi-SIM manager. The NR RRC entity may delay execution / processing of the multi-SIM suspend request until an RRC release message is received from the network / gNB.

[0063] In some aspects, the RRC recovery procedure is used for RNA update. During the RNA update procedure, the NR RRC entity sends an RRC recovery request (including a cause value indicating RNA update) to the network, and may receive an RRC release (including or not including suspension configuration) or an RRC rejection in response. In these aspects where the cause value is RNA update, even when the NR RRC entity receives a multi-SIM suspension request before sending the RRC recovery request to the network, the NR RRC entity will send a recovery request and receive a response from the network before performing the multi-SIM suspension request. In some scenarios, the UE may re-enter the RRC inactive state before performing the multi-SIM suspension request.

[0064] In other aspects, the RRC recovery process may be for reasons different from RNA update. In these aspects, the UE may receive an RRC recovery, an RRC establishment, an RRC release, or an RRC rejection in response to an RRC recovery request. In various examples to be described below, the UE may re-enter the RRC inactive state or may enter the RRC idle state. In some embodiments, when it is not possible to maintain the RRC inactive state, the UE may provide the network with UE assistance information indicating a preferred RRC state (which may be an RRC idle state).

[0065] In some scenarios, the RRC resume procedure is used for RNA update. The following procedure may be used regardless of whether the UE has sent an RRC resume request (indicating RNA update) to the network before receiving the Multi-SIM Suspend Request.

[0066] Figure 5 A signaling diagram 500 for multi-SIM (MSIM) high priority call handling is shown according to a first aspect of these exemplary embodiments, when a high priority call is triggered on a second SIM (SIMB) of a multi-SIM UE while an RRC recovery procedure is in progress for a first SIM (SIM A) of the UE. Figure 4Similar to the signaling diagram 400 of , the signaling diagram 500 includes a second non-access stratum (NAS) entity 502 of a second SIM (NAS_SIM B), an RRC entity 504 of a second SIM (x_RRC_SIM B), a multi-SIM manager 506 (MSIM_MGR), a first NAS entity 508 of a first SIM (NAS_SIM A), an NR RRC entity 510 of a second SIM (NR_RRC_SIM A), and a gNB 512. Similar to the above, the UE may have a first subscription to a first network (NW A) enabled by a first SIM (SIM A) and a second subscription to a second network (NW B) enabled by a second SIM (SIM B), wherein the first SIM may be associated with a first ID (simID=0) and the second SIM may be associated with a second ID (simID=1). The first SIM (SIM A) is in RRC inactive state and maintains an RRC inactive context at the UE (NR_RRC_SIM A 510) and the network (gNB 512), and the second SIM (SIM B) is in RRC idle state and maintains an RRC idle context at the UE (x_RRC_SIM B 404) with the corresponding network of SIM B (the corresponding network may be the same network as SIM A (e.g., 5G NR RAN) or a different network).

[0067] Figure 5 Steps 514-518 of the signaling diagram 500 may be associated with Figure 4 Steps 414-418 of the signaling diagram 400 are similarly executed. The first NAS entity 508 of the first SIM (NAS_SIM A) sends an RRC recovery approval request indicating the SIM ID of SIM A (e.g., simID=0) to the MSIM manager 506 (step 514); the MSIM manager 506 sends an RRC recovery approval confirmation including the SIM ID of SIM A to the first NAS entity 508 (step 516); and the NAS entity 508 of SIM A sends a recovery request indicating the RNA update cause value to the RRC entity 510 of SIM A (step 518).

[0068] Figure 5 Steps 520-524 of the signaling diagram 500 may be associated with Figure 4Steps 420-424 of the signaling diagram 400 of FIG. 4 are similarly executed. A service on the second SIM (SIM B) is triggered (e.g., a high priority voice call), and the second NAS entity 502 of SIM B sends an RRC establishment approval request including the SIM ID of SIM B (simId=1) and a cause value indicating a voice call to the MSIM manager 506 (step 520); the MSIM manager 506 determines that the voice call on SIM B has a higher priority than the RNA update on SIM A, and sends an RRC suspension request to the first NAS entity 508 of SIM A (step 522); and the first NAS entity 508 sends a multi-SIM suspension request to the first RRC entity 510 of SIM A (step 524).

[0069] As described above, the NR RRC entity 510 of SIM A has not yet received a response to the RRC recovery request from the network (gNB 512). In this example, the NR RRC entity 510 has not yet sent an RRC recovery request (step 526 below). However, regardless of whether an RRC recovery request has been sent, the UE behavior described below is performed.

[0070] According to the exemplary embodiments described herein, when the NR RRC entity 510 receives the multi-SIM suspension request, the NR RRC entity 510 temporarily stores the message and delays the execution of the multi-SIM suspension request. For example, the NR RRC entity 510 may store the message in the RRC. The execution of the multi-SIM suspension request of step 524 is delayed until the NR RRC entity 510 receives an RRC release or an RRC rejection from the network.

[0071] In 526, the NR RRC entity 510 sends an RRC resume request indicating a cause value of RNA update to the gNB 512. In this example, in 528, the gNB 512 responds with an RRC release including a suspend configuration (e.g., suspendConfig=true and associated suspend parameters).

[0072] The NR RRC entity 510 processes the response, and based on the response from the gNB 512 (not including the suspension configuration), the NR RRC entity 510 enters the RRC inactive state. In this way, the benefits of the RRC inactive state are retained while avoiding the UE from entering the RRC idle state.

[0073] In case the RRC inactive state remains unchanged, the NR RRC entity 510 retrieves the saved Multi-SIM Suspension Request message and executes it. Figure 5 Steps 530-534 of the signaling diagram 500 may be associated with Figure 4Steps 426-430 of the signaling diagram 400 are similarly performed. The NR RRC entity 510 of SIM A sends a multi-SIM suspension confirmation to the first NAS entity 508 (step 530); the first NAS entity 508 sends a suspension confirmation to the MSIM manager 506 (step 532); and the MSIM manager 506 sends a setup approval confirmation to the second NAS entity 502 of SIM B to indicate the SIM ID of SIM B (e.g., simID=1) and a cause value indicating a voice call (step 534). A voice call can then be started on SIM B.

[0074] Figure 5 The process described in gives priority to completing RNA update before providing the UE's L1 resources to SIM B to provide high priority services. Although there is a slight delay in the high priority service of SIM B, the delay is relatively short. For example, the delay for the UE to process the RRC release message is typically about 150ms to 300ms. The benefits of the RRC inactive state on SIM A remain unchanged, and there is no RRC state mismatch between the UE and the 5G NR RAN.

[0075] When the UE requests an RNA update, the most likely response from the network is an RRC release with a suspended configuration, as described above in Figure 5 However, it is also possible for the network to respond with an RRC Release or RRC Reject without suspending the configuration.

[0076] The following will refer to Figure 7 The RRC reject case is described in more detail and is applicable to any RRC resume reason (including RNA update or different reasons). Figure 6 The request for RNA update in describes the case of RRC release without suspension configuration. Figure 5 Similar to the signaling diagram 500 of , the following procedure may be used regardless of whether the UE has sent an RRC resume request (indicating an RNA update) to the network before receiving the multi-SIM suspend request.

[0077] In some scenarios, the RRC resume procedure is used for RNA update. The following procedure can be used regardless of whether the UE has sent an RRC resume request to the network before receiving the Multi-SIM Suspend Request.

[0078] Figure 6 A signaling diagram 600 for multi-SIM (MSIM) high priority call handling is shown according to a second aspect of these exemplary embodiments, when a high priority call is triggered on a second SIM (SIMB) of a multi-SIM UE while an RRC recovery procedure is in progress for a first SIM (SIM A) of the UE. Figure 5Similar to the signaling diagram 500 of , the signaling diagram 600 includes a second non-access stratum (NAS) entity 602 of a second SIM (NAS_SIM B), an RRC entity 604 of a second SIM (x_RRC_SIM B), a multi-SIM manager 606 (MSIM_MGR), a first NAS entity 608 of a first SIM (NAS_SIM A), an NR RRC entity 610 of a second SIM (NR_RRC_SIM A), and a gNB 612. Similar to the above, the UE may have a first subscription to a first network (NW A) enabled by a first SIM (SIM A) and a second subscription to a second network (NW B) enabled by a second SIM (SIM B), wherein the first SIM may be associated with a first ID (simID=0) and the second SIM may be associated with a second ID (simID=1). The first SIM (SIM A) is in RRC inactive state and maintains an RRC inactive context at the UE (NR_RRC_SIM A 610) and the network (gNB 612), and the second SIM (SIM B) is in RRC idle state and maintains an RRC idle context at the UE (x_RRC_SIM B 604) with the corresponding network of SIM B (the corresponding network may be the same network as SIM A (e.g., 5G NR RAN) or a different network).

[0079] Figure 6 Steps 614-618 of the signaling diagram 600 may be associated with Figure 5 Steps 514-518 of the signaling diagram 500 are similarly executed. The first NAS entity 608 of the first SIM (NAS_SIM A) sends an RRC recovery approval request indicating the SIM ID of SIM A (e.g., simID=0) to the MSIM manager 606 (step 614); the MSIM manager 606 sends an RRC recovery approval confirmation including the SIM ID of SIM A to the first NAS entity 608 (step 616); and the NAS entity 608 of SIM A sends a recovery request indicating the RNA update cause value to the RRC entity 610 of SIM A (step 618).

[0080] Figure 6 Steps 620-624 of the signaling diagram 600 may be associated with Figure 5Steps 520-524 of the signaling diagram 500 are similarly executed. A service on the second SIM (SIM B) is triggered (e.g., a high priority voice call), and the second NAS entity 602 of SIM B sends an RRC establishment approval request including the SIM ID of SIM B (simId=1) and a cause value indicating a voice call to the MSIM manager 606 (step 620); the MSIM manager 606 determines that the voice call on SIM B has a higher priority than the RNA update on SIM A, and sends an RRC suspension request to the first NAS entity 608 of SIM A (step 622); and the first NAS entity 608 sends a multi-SIM suspension request to the first RRC entity 610 of SIM A (step 624).

[0081] As described above, the NR RRC entity 610 of SIM A has not yet received a response to the RRC recovery request from the network (gNB 612). In this example, the NR RRC entity 610 has not yet sent an RRC recovery request (step 626 below). However, regardless of whether an RRC recovery request has been sent, the UE behavior described below is performed.

[0082] and Figure 5 Similar to the signaling diagram 500 of FIG. 5 , when the multi-SIM suspension request is received by the NR RRC entity 610, the NR RRC entity 610 temporarily stores the message and delays the execution of the multi-SIM suspension request. For example, the NR RRC entity 610 may store the message in the RRC. The execution of the multi-SIM suspension request of step 624 is delayed until the NR RRC entity 610 receives an RRC release or an RRC rejection from the network.

[0083] In 626, the NR RRC entity 610 sends an RRC resume request indicating a cause value of RNA update to the gNB 612. In this example, in 628, the gNB 612 responds with an RRC release that does not include a suspend configuration (e.g., suspendConfig=false).

[0084] The NR RRC entity 610 processes the response and based on the response from the gNB 612 (excluding the suspension configuration), the NR RRC entity 610 enters the RRC idle state. The network (gNB 612) also enters the RRC idle state. Thus, it is ensured that the UE and the network are synchronized with respect to the RRC context.

[0085] and Figure 5 Similar to the signaling diagram 500, the NR RRC entity 610 retrieves the saved multi-SIM suspend request message and executes the message. Figure 6 Steps 630-634 of the signaling diagram 600 may be associated with Figure 5 Steps 526-530 of the signaling diagram 500 are similarly performed. The NR RRC entity 610 of SIM A sends a multi-SIM suspension confirmation to the first NAS entity 608 (step 630); the first NAS entity 608 sends a suspension confirmation to the MSIM manager 606 (step 632); and the MSIM manager 606 sends a setup approval confirmation to the second NAS entity 602 of SIM B to indicate the SIM ID of SIM B (e.g., simID=1) and a cause value indicating a voice call (step 634). A voice call can then be started on SIM B.

[0086] Figure 6 The process described in gives priority to completing RNA update before providing the UE's L1 resources to SIM B to provide high priority services. There is no RRC state mismatch between the UE and the 5G NR RAN.

[0087] As mentioned above, RNA update can be considered as a special case where the UE behavior does not depend on the current stage of the RRC recovery procedure. That is, RNA update is allowed to proceed regardless of whether an RRC recovery request has been sent to the network.

[0088] In other scenarios, the RRC recovery procedure may be initiated for reasons other than RNA update. Figures 7 to 9 The following operations are described below. Figure 7 In the description, the UE behavior is described for the scenario where the UE receives an RRC Reject from the network in response to an RRC Resume Request. An RRC Reject may be received in response to any RRC Resume cause, including an RNA update or any other specified cause. Figures 8 to 9 In the description, the UE behavior is described for the scenario where the UE receives RRC recovery from the network in response to an RRC recovery request. RRC recovery may be received in response to various RRC recovery causes, however, these causes do not include RNA update causes (where only RRC release or RRC reject may be received).

[0089] Figure 7A signaling diagram 700 for multi-SIM (MSIM) high priority call handling is shown according to a third aspect of these exemplary embodiments, when a high priority call is triggered on a second SIM (SIMB) of a multi-SIM UE while an RRC recovery procedure is being performed for a first SIM (SIM A) of the UE. Similar to the above, the signaling diagram 700 includes a second non-access stratum (NAS) entity 702 of the second SIM (NAS_SIM B), an RRC entity 704 of the second SIM (x_RRC_SIM B), a multi-SIM manager 706 (MSIM_MGR), a first NAS entity 708 of the first SIM (NAS_SIM A), an NR RRC entity 710 of the second SIM (NR_RRC_SIM A), and a gNB 712. Similar to the above, the UE may have a first subscription to a first network (NW A) enabled by a first SIM (SIM A) and a second subscription to a second network (NW B) enabled by a second SIM (SIM B), wherein the first SIM may be associated with a first ID (simID=0) and the second SIM may be associated with a second ID (simID=1). The first SIM (SIM A) is in an RRC inactive state and maintains an RRC inactive context at the UE (NR_RRC_SIM A 710) and the network (gNB 712), and the second SIM (SIM B) is in an RRC idle state and maintains an RRC idle context at the UE (x_RRC_SIM B 704) with the corresponding network of SIM B (which may be the same network as SIM A (e.g., 5G NR RAN) or a different network).

[0090] Figure 7 Steps 714-718 of the signaling diagram 700 may be associated with Figure 6 Steps 614-618 of the signaling diagram 600 of FIG. 6 are similarly performed. The first NAS entity 708 of the first SIM (NAS_SIM A) sends an RRC recovery approval request indicating the SIM ID of SIM A (e.g., simID=0) to the MSIM manager 706 (step 714); the MSIM manager 706 sends an RRC recovery approval confirmation including the SIM ID of SIM A to the first NAS entity 708 (step 716); and the NAS entity 708 of SIM A sends a recovery request indicating any cause value to the RRC entity 710 of SIM A (step 718).

[0091] Figure 7 Steps 720-724 of the signaling diagram 700 may be associated with Figure 6Steps 620-624 of the signaling diagram 600 of FIG. 6 are similarly executed. A service on the second SIM (SIM B) is triggered (e.g., a high priority voice call), and the second NAS entity 702 of SIM B sends an RRC establishment approval request including the SIM ID of SIM B (simId=1) and a cause value indicating a voice call to the MSIM manager 706 (step 720); the MSIM manager 706 determines that the voice call on SIM B has a higher priority than the RRC resumption on SIM A, and sends an RRC suspension request to the first NAS entity 708 of SIM A (step 722); and the first NAS entity 708 sends a multi-SIM suspension request to the first RRC entity 710 of SIM A (step 724).

[0092] As described above, the NR RRC entity 710 of SIM A has not received a response to the RRC resume request from the network (gNB 712). In this example, in 726, the NR RRC entity 710 sends an RRC resume request indicating any cause value to the gNB 712 before receiving the multi-SIM suspend request in 724.

[0093] and Figure 6 Similar to the signaling diagram 600 of FIG. 5 , when the NR RRC entity 710 receives the multi-SIM suspension request, the NR RRC entity 710 temporarily stores the message and delays the execution of the multi-SIM suspension request. For example, the NR RRC entity 710 may store the message in the RRC. The execution of the multi-SIM suspension request of step 724 is delayed until the NR RRC entity 710 receives a response from the network.

[0094] In this example, in 728, the gNB 712 responds with an RRC reject. The NR RRC entity 710 processes the response and, based on the RRC reject response from the gNB 712, the NR RRC entity 710 re-enters the RRC inactive state. The network (gNB 712) also enters the RRC inactive state. Thus, the inactive context is maintained and it is ensured that the UE and the network are synchronized with respect to the RRC context.

[0095] and Figure 6 Similar to the signaling diagram 600, the NR RRC entity 710 retrieves the saved multi-SIM suspend request message and executes the message. Figure 7 Steps 730-734 of the signaling diagram 700 may be associated with Figure 6Steps 626-630 of the signaling diagram 600 are similarly performed. The NR RRC entity 710 of SIM A sends a multi-SIM suspension confirmation to the first NAS entity 708 (step 730); the first NAS entity 708 sends a suspension confirmation to the MSIM manager 706 (step 732); and the MSIM manager 706 sends a setup approval confirmation to the second NAS entity 702 of SIM B to indicate the SIM ID of SIM B (e.g., simID=1) and a cause value indicating a voice call (step 734). A voice call can then be started on SIM B.

[0096] exist Figure 7 In the described process, the UE has sent an RRC resume request to the network. Since the UE typically receives a response from the network within 100ms to 200ms, the NR RRC entity 710 will save the suspension because when the network transmits an RRC reject, the UE can save the inactive context on SIM A before confirming the multi-SIM suspension.

[0097] As described above, for cause values ​​other than RNA Update, the UE may receive RRC Resume from the network to move the UE to the RRC Connected state. Figures 8 to 9 In , the UE behavior is described for these scenarios. Figure 8 In , an RRC resume request is sent to the network before a multi-SIM suspend request is received. Fig. 9 In the case of a multi-SIM suspend request, the RRC resume request has not yet been sent to the network before the multi-SIM suspend request is received.

[0098] Figure 8A signaling diagram 800 for multi-SIM (MSIM) high priority call handling is shown according to a fourth aspect of these exemplary embodiments, when a high priority call is triggered on a second SIM (SIMB) of a multi-SIM UE while an RRC recovery procedure is being performed for a first SIM (SIM A) of the UE. Similar to the above, the signaling diagram 800 includes a second non-access stratum (NAS) entity 802 of the second SIM (NAS_SIM B), an RRC entity 804 of the second SIM (x_RRC_SIM B), a multi-SIM manager 806 (MSIM_MGR), a first NAS entity 808 of the first SIM (NAS_SIM A), an NR RRC entity 810 of the second SIM (NR_RRC_SIM A), and a gNB 812. Similar to the above, the UE may have a first subscription to a first network (NW A) enabled by a first SIM (SIM A) and a second subscription to a second network (NW B) enabled by a second SIM (SIM B), wherein the first SIM may be associated with a first ID (simID=0) and the second SIM may be associated with a second ID (simID=1). The first SIM (SIM A) is in an RRC inactive state and maintains an RRC inactive context at the UE (NR_RRC_SIM A 810) and the network (gNB 812), and the second SIM (SIM B) is in an RRC idle state and maintains an RRC idle context at the UE (x_RRC_SIM B 804) with the corresponding network of SIM B (which may be the same network as SIM A (e.g., 5G NR RAN) or a different network).

[0099] Figure 8 Steps 814-818 of the signaling diagram 800 may be associated with Figure 7 Steps 614-618 of the signaling diagram 700 of SIM A are similarly executed. The first NAS entity 808 of the first SIM (NAS_SIM A) sends an RRC recovery approval request indicating the SIM ID of SIM A (e.g., simID=0) to the MSIM manager 806 (step 814); the MSIM manager 806 sends an RRC recovery approval confirmation including the SIM ID of SIM A to the first NAS entity 808 (step 816); and the NAS entity 808 of SIM A sends a recovery request indicating any cause value to the RRC entity 810 of SIM A (step 818). It should be noted that although step 818 indicates "any cause", the UE will not receive an RRC recovery in response to the RNA update request.

[0100] Figure 8 Steps 820-824 of the signaling diagram 800 may be associated with Figure 7Steps 720-724 of the signaling diagram 700 of FIG. 8 are similarly performed. A service on the second SIM (SIM B) is triggered (e.g., a high priority voice call), and the second NAS entity 802 of SIM B sends an RRC establishment approval request including the SIM ID of SIM B (simId=1) and a cause value indicating a voice call to the MSIM manager 806 (step 820); the MSIM manager 806 determines that the voice call on SIM B has a higher priority than the RRC resumption on SIM A, and sends an RRC suspension request to the first NAS entity 808 of SIM A (step 822); and the first NAS entity 808 sends a multi-SIM suspension request to the first RRC entity 810 of SIM A (step 824).

[0101] As described above, the NR RRC entity 810 of SIM A has not received a response to the RRC resume request from the network (gNB 812). In this example, in 826, the NR RRC entity 810 sends an RRC resume request indicating any cause value to the gNB 812 before receiving the multi-SIM suspend request in 824.

[0102] and Figure 7 Similar to the signaling diagram 700 of FIG. 8 , when the NR RRC entity 810 receives the multi-SIM suspension request, the NR RRC entity 810 temporarily stores the message and delays the execution of the multi-SIM suspension request. For example, the NR RRC entity 810 may store the message in the RRC. The execution of the multi-SIM suspension request of step 824 is delayed until the NR RRC entity 810 receives a response from the network.

[0103] In this example, the gNB 812 responds with an RRC resume in 828. Thus, the gNB 812 adopts the RRC connection context with the NR RRC entity 810 of SIM A. However, in the event that a high priority service is pending on SIM B, the NR RRC entity 810 will not enter the RRC connected state.

[0104] To allow high priority services to continue on SIM B, the NR RRC entity 810 ends the RRC recovery process on SIM A prematurely and does not send an RRC recovery complete message to gNB 812. The UE discards the AS context and enters the RRC idle state. Although gNB 812 temporarily enters the RRC connected state with the UE, when the RRC recovery complete is not received from the UE before the T319 timer expires, gNB 812 enters the RRC idle state with the UE. Therefore, although gNB 812 does not know the reason why the UE did not send the RRC recovery complete, both the NR RRC entity 810 and gNB 812 enter the RRC idle state and there is no context mismatch between the UE and gNB 812.

[0105] and Figure 7 Similar to the signaling diagram 700, the NR RRC entity 810 retrieves the saved multi-SIM suspend request message and executes the message. Figure 8 Steps 830-834 of the signaling diagram 800 may be associated with Figure 7 Steps 726-730 of the signaling diagram 700 are similarly performed. The NR RRC entity 810 of SIM A sends a multi-SIM suspension confirmation to the first NAS entity 808 (step 830); the first NAS entity 808 sends a suspension confirmation to the MSIM manager 806 (step 832); and the MSIM manager 806 sends a setup approval confirmation to the second NAS entity 802 of SIM B to indicate the SIM ID of SIM B (e.g., simID=1) and a cause value indicating a voice call (step 834). A voice call can then be started on SIM B.

[0106] exist Figure 8 In the described process, the UE has already sent an RRC resume request to the network when the multi-SIM suspend request is received from the MSIM manager 806. Since the UE typically receives a response from the network within 100ms to 200ms, the NR RRC entity 810 will save the suspension because when the network transmits the RRC resume, the UE knows that prematurely ending the RRC resume procedure will ultimately result in the 5G NR RAN entering an RRC idle context before confirming the multi-SIM suspension.

[0107] Fig. 9A signaling diagram 900 for multi-SIM (MSIM) high priority call handling is shown according to a fifth aspect of these exemplary embodiments, when a high priority call is triggered on a second SIM (SIMB) of a multi-SIM UE while an RRC recovery procedure is being performed for a first SIM (SIM A) of the UE. Similar to the above, the signaling diagram 900 includes a second non-access stratum (NAS) entity 902 of the second SIM (NAS_SIM B), an RRC entity 904 of the second SIM (x_RRC_SIM B), a multi-SIM manager 906 (MSIM_MGR), a first NAS entity 908 of the first SIM (NAS_SIM A), an NR RRC entity 910 of the second SIM (NR_RRC_SIM A), and a gNB 912. Similar to the above, the UE may have a first subscription to a first network (NW A) enabled by a first SIM (SIM A) and a second subscription to a second network (NW B) enabled by a second SIM (SIM B), wherein the first SIM may be associated with a first ID (simID=0) and the second SIM may be associated with a second ID (simID=1). The first SIM (SIM A) is in an RRC inactive state and maintains an RRC inactive context at the UE (NR_RRC_SIM A 910) and the network (gNB 912), and the second SIM (SIM B) is in an RRC idle state and maintains an RRC idle context at the UE (x_RRC_SIM B 904) with the corresponding network of SIM B (which may be the same network as SIM A (e.g., 5G NR RAN) or a different network).

[0108] Fig. 9 Steps 914-918 of the signaling diagram 900 may be associated with Figure 8 Steps 614-618 of the signaling diagram 800 of SIM A are similarly executed. The first NAS entity 908 of the first SIM (NAS_SIM A) sends an RRC recovery approval request indicating the SIM ID of SIM A (e.g., simID=0) to the MSIM manager 906 (step 914); the MSIM manager 906 sends an RRC recovery approval confirmation including the SIM ID of SIM A to the first NAS entity 908 (step 916); and the NAS entity 908 of SIM A sends a recovery request indicating any cause value to the RRC entity 910 of SIM A (step 918). It should be noted that although step 918 indicates "any cause", the UE will not receive an RRC recovery in response to the RNA update request.

[0109] Fig. 9 Steps 920-924 of the signaling diagram 900 may be associated with Figure 8Steps 820-824 of the signaling diagram 800 are similarly executed. A service on the second SIM (SIM B) is triggered (e.g., a high priority voice call), and the second NAS entity 902 of SIM B sends an RRC establishment approval request including the SIM ID of SIM B (simId=1) and a cause value indicating a voice call to the MSIM manager 906 (step 920); the MSIM manager 906 determines that the voice call on SIM B has a higher priority than the RRC resumption on SIM A, and sends an RRC suspension request to the first NAS entity 908 of SIM A (step 922); and the first NAS entity 908 sends a multi-SIM suspension request to the first RRC entity 910 of SIM A (step 924).

[0110] As described above, the NR RRC entity 910 of SIM A has not yet received a response to the RRC recovery request from the network (gNB 912). In this example, the NR RRC entity 910 has not yet sent the RRC recovery request (step 926 below).

[0111] and Figure 8 Similar to the signaling diagram 800 of , when the NR RRC entity 910 receives the multi-SIM suspension request, the NR RRC entity 910 temporarily stores the message and delays the execution of the multi-SIM suspension request. For example, the NR RRC entity 910 may store the message in the RRC. The execution of the multi-SIM suspension request of step 924 is delayed until the NR RRC entity 910 receives a response from the network.

[0112] At 926, the NR RRC entity 910 sends an RRC resume request indicating any cause value to the gNB 912. In this example, at 928, the gNB 912 responds with an RRC resume. Thus, the gNB 912 adopts the RRC connection context of the NR RRC entity 910 with SIM A. However, in the event that a high priority service is pending on SIM B, the NR RRC entity 910 will not enter the RRC connected state.

[0113] To ensure that the gNB 912 enters the RRC idle state, in 930, the NR RRC entity 910 sends UE assistance information indicating a preferred RRC state (e.g., RRC idle state) to the gNB 912.

[0114] To allow high priority services to continue on SIM B, the NR RRC entity 910 prematurely terminates the RRC recovery procedure on SIM A. The UE discards the AS context and enters the RRC idle state. Although the gNB 912 temporarily enters the RRC connected state with the UE, based on the UE assistance information received from the UE, the gNB 912 determines to release the RRC connected state.

[0115] In 938, the gNB 912 sends an RRC release without a suspension configuration to the NR RRC entity 910 and enters the RRC idle state with the UE. Therefore, both the NR RRC entity 910 and the gNB 912 enter the RRC idle state, and there is no context mismatch between the UE and the gNB 912.

[0116] and Figure 8 Similar to the signaling diagram 800, the NR RRC entity 910 retrieves the saved multi-SIM suspend request message and executes the message. Fig. 9 Steps 932-936 of the signaling diagram 900 may be associated with Figure 8 Steps 826-830 of the signaling diagram 800 are similarly executed. The NR RRC entity 910 of SIM A sends a multi-SIM suspension confirmation to the first NAS entity 908 (step 932); the first NAS entity 908 sends a suspension confirmation to the MSIM manager 906 (step 934); and the MSIM manager 906 sends a setup approval confirmation to the second NAS entity 902 of SIM B to indicate the SIM ID of SIM B (e.g., simID=1) and a cause value indicating a voice call (step 936). A voice call can then be started on SIM B.

[0117] exist Fig. 9 In the described process, when the multi-SIM suspension request is received from the MSIM manager 906, the UE has not yet sent an RRC resume request to the network. However, to ensure that there is no context mismatch in the event that an RRC resume is received, the UE continues to perform the RRC resume process so that the UE can indicate the preferred RRC state of RRC idle to the network. The signaling required for this process includes only two OTA messages (e.g., UE assistance information transmission at 930 and RRC release at 932), which is a small number compared to the OTA messages required when there is an RRC context mismatch.

[0118] In an additional embodiment, the UE may maintain an internal timer to control the waiting time between the sending of the RRC recovery request and the reception of any DL message to ensure that the UE does not wait too long, in rare cases the T319 timer is longer than, for example, 100ms.

[0119] In summary, according to the above Figures 5 to 9 The exemplary embodiment of the present invention provides the UE with every possible opportunity to maintain the inactive context on SIM A when the RRC recovery procedure on SIM B is interrupted, while minimizing the signaling between the UE and the gNB. This saves the UE's power and avoids the need for a TAU procedure in most cases due to multi-SIM conflicts. The exemplary embodiment will result in optimized network resource usage, for example, improving end-to-end system performance as specified by 3GPP.

[0120] The exemplary embodiment further avoids context mismatches between the UE and the gNB. The UE is provided with the opportunity to continuously send rrcResumeRequest / 1 and receive rrcRelease(suspendConfig=True) / rrcReject to ensure that both the UE and the gNB are in the RRC inactive state. Upon receiving rrcResume in response to rrcResumeRequest, the UE may transmit UeAssistanceInformation(state=idle) and then immediately release the rrcConnection locally or discard the rrcResume and release the inactive context. Since the gNodeB will not receive rrcResumeComplete, it will release the inactive context after the process protection timer expires, thereby ensuring that both entities are in the RRC_IDLE state.

[0121] In many use cases, the exemplary embodiments can provide an enhanced user experience due to low latency in call setup, since the inactive state context is preserved. In addition, the UE also avoids affecting the Tx and Rx capabilities of the SIM due to additional signaling between the UE and the network.

[0122] The exemplary embodiments are also applicable to any RAT for which the 3GPP inactive state is applicable, including 4G and future RATs such as 5G-Advanced, 6G, etc.

[0123] Example

[0124] In a first embodiment, a method performed by a user equipment (UE) includes: entering a radio resource control (RRC) inactive state on a first network using a first subscriber identity module (SIM) and entering an RRC inactive state or an RRC idle state on a second network using a second SIM; initiating an RRC recovery procedure on the first SIM, the RRC recovery procedure including sending a recovery request including a cause indication from a non-access stratum (NAS) entity of the first SIM to an RRC entity of the first SIM; receiving, during the RRC recovery procedure on the first SIM, a trigger for a service on the second SIM having a higher priority than the RRC recovery procedure on the first SIM; initiating a multi-SIM suspension procedure on the first SIM based on the trigger for the service on the second SIM, the multi-SIM suspension procedure including sending a multi-SIM suspension request from the NAS entity of the first SIM to the RRC entity of the first SIM; and delaying execution of the multi-SIM suspension request at the RRC entity of the first SIM until a response to the RRC recovery request is received from the first network.

[0125] In a second embodiment, the method according to the first embodiment, wherein the cause indication comprises a radio access network (RAN) based notification area (RNA) update.

[0126] In a third embodiment, according to the method of the second embodiment, when the multi-SIM suspend request is received at the RRC entity of the first SIM, the execution of the multi-SIM suspend request is delayed regardless of whether the RRC resume request of the RRC resume procedure has been sent to the first RAN.

[0127] In a fourth embodiment, according to the method of the third embodiment, wherein the response to the RRC resume request includes an RRC reject or an RRC release including a suspension configuration, the method further includes re-entering the RRC inactive state on the first SIM based on a previous suspension configuration or the suspension configuration in the RRC release, and performing the multi-SIM suspension request on the first SIM and starting the service on the second SIM.

[0128] In a fifth embodiment, according to the method of the third embodiment, the response to the RRC resume request includes an RRC release that does not include a suspension configuration, and the method further includes entering the RRC idle state on the first SIM based on the RRC release, and performing the multi-SIM suspension request on the first SIM and starting the service on the second SIM.

[0129] In a sixth embodiment, according to the method of the first embodiment, the cause indication includes any cause, and the RRC resume request is sent to the first network before the RRC entity of the first SIM receives the multi-SIM suspend request.

[0130] In a seventh embodiment, the method according to the sixth embodiment, wherein the response to the RRC resume request comprises an RRC reject, the method further comprising re-entering the RRC inactive state on the first SIM based on a previous suspension configuration, and performing the multi-SIM suspension request on the first SIM and starting the service on the second SIM.

[0131] In an eighth embodiment, according to the method of the sixth embodiment, wherein the response to the RRC resumption request includes RRC resumption, the method further includes ending the RRC resumption procedure and entering the RRC idle state on the first SIM, and performing the multi-SIM suspension request on the first SIM and starting the service on the second SIM.

[0132] In a ninth embodiment, according to the method of the first embodiment, wherein the cause indication includes any cause, and the multi-SIM suspension request is received before sending the RRC resumption request to the first network, the method further comprising sending the RRC resumption request to the first network and receiving RRC resumption from the first network.

[0133] In a tenth embodiment, the method according to the ninth embodiment further includes: sending UE auxiliary information indicating a preferred RRC state to the first network, the preferred RRC state including the RRC idle state; ending the RRC recovery process on the first SIM and entering the RRC idle state; and executing the multi-SIM suspension request on the first SIM and starting the service on the second SIM.

[0134] In an eleventh embodiment, the method according to the tenth embodiment further includes: receiving an RRC release without suspension configuration from the first network in response to the UE assistance information.

[0135] In a twelfth embodiment, the method according to the first embodiment, wherein the multi-SIM suspension request is stored in the RRC until executed.

[0136] In a thirteenth embodiment, the method according to the first embodiment, wherein the service on the second SIM is a high priority voice call.

[0137] In a fourteenth embodiment, a processor is provided, wherein the processor is configured to execute any of the methods according to the first to thirteenth embodiments.

[0138] In a fifteenth embodiment, a user equipment (UE) comprises: a transceiver configured to communicate with a network; and a processor communicatively coupled to the transceiver and configured to perform any one of the methods described in the first to thirteenth embodiments.

[0139] Those skilled in the art will appreciate that the exemplary embodiments described above may be implemented with any suitable software configuration or hardware configuration or a combination thereof. Exemplary hardware platforms for implementing the exemplary embodiments may include, for example, Intel x86-based platforms with compatible operating systems, Windows OS, Mac platforms and MAC OS, mobile devices with operating systems such as iOS, Android. In other examples, the exemplary embodiments of the above methods may be embodied as a program including lines of code stored on a non-transitory computer-readable storage medium, which, when compiled, may be executed on a processor or microprocessor.

[0140] Although this application describes various embodiments, each having different features in various combinations, those skilled in the art will understand that any feature of one embodiment may be combined with features of other embodiments in any manner that is not expressly negated or that is not functionally or logically inconsistent with the operation of the device or the prescribed function of the disclosed embodiment.

[0141] It is understood that the use of personally identifiable information should be subject to privacy policies and practices that are generally recognized to meet or exceed industry or government requirements for maintaining user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of unintentional or unauthorized access or use, and the nature of the authorized use should be clearly stated to users.

[0142] It will be apparent to those skilled in the art that various modifications may be made to the present disclosure without departing from the spirit or scope of the present disclosure. Therefore, it is intended that the present disclosure covers modifications and variations of the present disclosure as long as they fall within the scope of the appended claims and their equivalents.

Claims

1. An apparatus of a user equipment (UE), the apparatus comprising a processing circuit, the processing circuit being configured to: entering a radio resource control (RRC) inactive state on a first network using a first subscriber identity module (SIM) and entering an RRC inactive state or an RRC idle state on a second network using a second SIM; Initiating an RRC recovery procedure on the first SIM, the RRC recovery procedure comprising sending a recovery request including a cause indication from a non-access stratum (NAS) entity of the first SIM to an RRC entity of the first SIM; decoding, in the RRC recovery procedure on the first SIM, a triggering of a service on the second SIM having a higher priority than the RRC recovery procedure on the first SIM based on a signal received from a base station; Based on the triggering of the service on the second SIM, initiating a multi-SIM suspension procedure on the first SIM, the multi-SIM suspension procedure comprising sending a multi-SIM suspension request from the NAS entity of the first SIM to the RRC entity of the first SIM; as well as At the RRC entity of the first SIM, execution of the multi-SIM suspend request is delayed until a response to an RRC resume request is received from the first network.

2. The apparatus of claim 1, wherein the cause indication comprises a radio access network (RAN) based notification area (RNA) update.

3. The apparatus of claim 2, wherein when the multi-SIM suspend request is received at the RRC entity of the first SIM, the execution of the multi-SIM suspend request is delayed regardless of whether the RRC resume request of the RRC resume procedure has been sent to the first RAN.

4. The apparatus of claim 3, wherein the response to the RRC resume request comprises an RRC reject or an RRC release comprising a suspension configuration, wherein the processing circuit is further configured to: re-entering the RRC inactive state on the first SIM based on a previous suspension configuration or the suspension configuration in the RRC release; and The multi-SIM suspension request is performed on the first SIM and the service is started on the second SIM.

5. The apparatus of claim 3, wherein the response to the RRC resume request comprises an RRC release that does not include a suspension configuration, wherein the processing circuit is further configured to: Based on the RRC release, entering the RRC idle state on the first SIM; and The multi-SIM suspension request is performed on the first SIM and the service is started on the second SIM.

6. The apparatus of claim 1, wherein the cause indication comprises any cause, and the RRC resume request is sent to the first network before the RRC entity of the first SIM receives the multi-SIM suspend request.

7. The apparatus of claim 6, wherein the response to the RRC resume request comprises an RRC reject, wherein the processing circuit is further configured to: re-entering the RRC inactive state on the first SIM based on a previous suspension configuration; and The multi-SIM suspension request is performed on the first SIM and the service is started on the second SIM.

8. The apparatus of claim 6, wherein the response to the RRC resume request comprises an RRC resume, wherein the processing circuit is further configured to: ending the RRC recovery procedure and entering the RRC idle state on the first SIM; and The multi-SIM suspension request is performed on the first SIM and the service is started on the second SIM.

9. The apparatus of claim 1 , wherein the cause indication comprises any cause, and the multi-SIM suspension request is received before sending the RRC resume request to the first network, wherein the processing circuit is further configured to: configuring transceiver circuitry to send the RRC resume request to the first network; and An RRC recovery is decoded based on the signal received from the first network.

10. The apparatus of claim 9, wherein the processing circuit is further configured to: configuring transceiver circuitry to send UE assistance information indicating a preferred RRC state to the first network, the preferred RRC state comprising the RRC idle state; Ending the RRC recovery procedure and entering the RRC idle state on the first SIM; as well as The multi-SIM suspension request is performed on the first SIM and the service is started on the second SIM.

11. The apparatus of claim 10, wherein the processing circuit is further configured to: In response to the UE assistance information, an RRC release without suspension configuration is decoded based on a signal received from the first network.

12. The apparatus of claim 1, wherein the multi-SIM suspension request is saved in the RRC until executed.

13. The apparatus of claim 1, wherein the service on the second SIM is a high priority voice call.

14. A user equipment (UE), comprising: a transceiver configured to communicate with a first network and a second network; as well as a processor communicatively coupled to the transceiver and configured to: entering a radio resource control (RRC) inactive state on the first network using a first subscriber identity module (SIM), and entering an RRC inactive state or an RRC idle state on the second network using a second SIM; Initiating an RRC recovery procedure on the first SIM, the RRC recovery procedure comprising sending a recovery request including a cause indication from a non-access stratum (NAS) entity of the first SIM to an RRC entity of the first SIM; decoding, in the RRC recovery procedure on the first SIM, a triggering of a service on the second SIM having a higher priority than the RRC recovery procedure on the first SIM based on a signal received from a base station; Based on the triggering of the service on the second SIM, initiating a multi-SIM suspension procedure on the first SIM, the multi-SIM suspension procedure comprising sending a multi-SIM suspension request from the NAS entity of the first SIM to the RRC entity of the first SIM; as well as At the RRC entity of the first SIM, execution of the multi-SIM suspend request is delayed until a response to an RRC resume request is received from the first network.

15. The UE of claim 14, wherein the cause indication comprises a Radio Access Network (RAN) based Notification Area (RNA) update.

16. The UE of claim 15, wherein when the multi-SIM suspend request is received at the RRC entity of the first SIM, the execution of the multi-SIM suspend request is delayed regardless of whether the RRC resume request of the RRC resume procedure has been sent to the first RAN.

17. The UE of claim 14, wherein the cause indication comprises any cause, and the RRC resume request is sent to the first network before the RRC entity of the first SIM receives the multi-SIM suspend request.

18. The UE of claim 14, wherein the cause indication comprises any cause, and the multi-SIM suspension request is received before sending the RRC resume request to the first network, wherein the processor is further configured to: configuring the transceiver to send the RRC recovery request to the first network; and An RRC recovery is decoded based on the signal received from the first network.

19. The UE of claim 14, wherein the multi-SIM suspension request is saved in the RRC until executed.

20. The UE of claim 14, wherein the service on the second SIM is a high priority voice call.

Images