Method for multi-SIM UE connected mode operation

Abstract

The invention relates to a method for multi-SIM UE connected mode operation. Methods and apparatus for multi-subscriber identification module (SIM) connected mode operation are described herein. In one embodiment, a wireless communication device may receive a requested access to a receiver chain from an access stratum interface during a reception opportunity. The wireless communication device may determine that the receiver chain is available during the reception opportunity. The wireless communication device may send a response indicating that access is granted to cause the access stratum interface to receive downlink transmissions during the receive opportunity. The wireless communication device may receive a second request for a transmitter chain from the access layer interface during a transmit opportunity. The wireless communication device may determine that the transmitter chain is available during the transmission opportunity. The wireless communication device may send a second response indicating that access is granted to enable the access stratum interface to transmit an uplink transmission during the transmission opportunity.

Description

[0001] This application is a divisional application of the invention patent application with application number 202080085557.3, application date November 13, 2020, and name “Method for multi-SIM UE connection mode operation”.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application claims the benefit of U.S. Provisional Patent Application No. 62 / 934,748, filed on November 13, 2019, which is hereby incorporated by reference in its entirety. Background Art

[0004] A multi-SIM UE is a UE with two or more SIMs (Subscriber Identity Module or Service Identity Module). These devices have become increasingly common in various locations. However, multi-SIM operation presents many challenges in terms of UE behavior, which may negatively impact the user experience and negatively impact overall system performance. Therefore, there is a need for improved procedures for multi-SIM operation. Summary of the invention

[0005] The purpose of providing this summary is to introduce selected concepts in a simplified form, which are further described in the following detailed description. This summary is neither intended to identify the key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. In addition, the claimed subject matter is not limited to limitations that address any or all disadvantages noted in any part of this disclosure.

[0006] Methods and apparatus for multi-subscriber identity module (SIM) connected mode operation are described herein. According to one embodiment, a wireless communication device may receive a request access to a receiver chain from an access layer interface during a receive opportunity. The wireless communication device may determine that the receiver chain is available during the receive opportunity. The wireless communication device may send a response indicating that access is authorized so that the access layer interface receives downlink transmissions during the receive opportunity. The wireless communication device may receive a second request for a transmitter chain from the access layer interface during a transmit opportunity. The wireless communication device may determine that the transmitter chain is available during the transmit opportunity. The wireless communication device may send a second response indicating that access is authorized so that the access layer interface can transmit uplink transmissions during the transmit opportunity. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The foregoing summary of the invention and the following detailed description will be better understood when read in conjunction with the accompanying drawings. In order to illustrate the present disclosure, various aspects of the present disclosure are shown. However, the present disclosure is not limited to the specific aspects discussed. In the accompanying drawings:

[0008] Figure 1shows the UE state machine and state transitions in NR;

[0009] Figure 2 The UE state machine and state transitions between NR / 5GC, E-UTRA / EPC and E-UTRA / 5GC are shown;

[0010] Figure 3 A multi-Sim UE AS model is shown;

[0011] Figure 4 A multi-SIM UE RRC is shown;

[0012] Figure 5 shows a multi-SIM UE intermediate AS in the C-plane;

[0013] Figure 6 shows a multi-SIM UE intermediate AS in the U-plane;

[0014] Figure 7 The multi-SIM UE lower layer AS is shown;

[0015] Figure 8 A multi-SIM MAC is shown;

[0016] Fig. 9 Multi-SIM NAS - Example 1 is shown;

[0017] Fig.10 Multi-SIM NAS - Example 2 is shown;

[0018] Fig.11 A multi-SIM upper layer NAS is shown;

[0019] Fig.12 A multi-SIM underlying NAS is shown;

[0020] Fig.13 shows a multi-SIM UE control plane architecture;

[0021] Fig.14 shows a high-level end-to-end control plane architecture supporting multi-SIM UEs;

[0022] Fig.15 shows a multi-SIM UE level RRC state machine;

[0023] Fig.16 shows a multi-SIM UE level NAS state machine;

[0024] Fig.17 shows dynamic sharing of RX / TX chains using an RX / TX chain arbiter;

[0025] Fig.18Shown is the interface between the AS and the RX / TX chain arbiter - Option 1;

[0026] Fig.19 Shown is the interface between the AS and the RX / TX chain arbiter - Option 2;

[0027] Fig. 20 The interface between the AS and the RX / TX chain arbiter is shown - option 3;

[0028] Fig.21 shows a signaling diagram for dynamic sharing of RX / TX chains - Option 1;

[0029] Fig. 22 shows a signaling diagram for dynamic sharing of RX / TX chains - Option 2;

[0030] Fig.23 A signaling diagram showing dynamic sharing of RX / TX chains in case of missed RXOP / TXOP - Option 1;

[0031] Fig.24 shows a signaling diagram for dynamic sharing of RX / TX chains in case of missing RXOP / TXOP - Option 2;

[0032] Fig.25 shows a signaling diagram for semi-static sharing with RRC suspension;

[0033] Fig.26 shows a signaling diagram for semi-static sharing with RRC release;

[0034] Fig.27A One embodiment of an exemplary communication system in which the methods and apparatus described and claimed herein may be embodied is illustrated;

[0035] Fig.27B is a block diagram of an exemplary apparatus or device, such as, for example, a wireless transmit / receive unit (WTRU), configured for wireless communication according to embodiments illustrated herein;

[0036] Fig.27C is a system diagram of a RAN and a core network according to an embodiment;

[0037] Fig.27D is a system diagram of a RAN and a core network according to an embodiment;

[0038] Fig.27E is a system diagram of a RAN and a core network according to an embodiment;

[0039] Fig.27F It can be specifically implemented Fig.27A , Fig.27C, Fig.27D and Fig.27E A block diagram of an exemplary computing system of one or more devices of a communication network as shown in FIG. 1 ; and

[0040] Figure 27G One embodiment of an example communication system is presented in which the methods and apparatus described and claimed herein may be embodied. DETAILED DESCRIPTION

[0041] Methods and apparatus for multiple Subscriber Identity Module (SIM) connected mode operation are described herein.

[0042] The following abbreviations and definitions may be used in this article:

[0043] 3GPP Third Generation Partnership Project

[0044] 5G Fifth Generation

[0045] 5GS 5G System

[0046] 5G-S-TMSI 5G Shortened Temporary Mobile Subscriber Identity

[0047] AS Access Layer

[0048] BWP Bandwidth Part

[0049] BSR Buffer Status Report

[0050] CORESET Control Resource Set

[0051] CN Core Network

[0052] CM Connection Management

[0053] CoMAC Shared MAC CoNAS Shared NAS CoRRC Shared RRC C-RNTI Cell Radio Network Temporary Identifier CSI Channel State Information CSI-RS Channel State Information Reference Signal DCI Downlink Control Information DSSS Dual SIM Single Standby UE DSDS Dual SIM Dual Standby DSDA Dual SIM Dual Activity DeMAC Dedicated MAC DeNAS Dedicated NAS DeRRC Dedicated RRC DRX Discontinuous Reception ECM EPS Connection Management eNB Evolved Node B EPS Evolved Packet System E-UTRA Evolved UMTS Terrestrial Radio Access gNB NR Node B HARQ Hybrid Automatic Repeat Request ID Identity or identifier LCG Logical Channel Group LCP Logical Channel Priority LTE Long Term Evolution MAC Medium Access Control MAC CE MAC Control Element MNO Mobile Network Operator Msg2 Message 2 of the random access process Msg3 Message 3 of the random access procedure NAS Non-AS NB Node B

[0054] NR New Radio

[0055] N TA Timing advance between downlink and uplink

[0056] PDCCH Physical Downlink Control Channel

[0057] PDCP Packet Data Convergence Protocol

[0058] PDU Protocol Data Unit

[0059] PHR Power Headroom

[0060] PHY Physical Layer

[0061] PLMN Public Land Mobile Network

[0062] PRACH Physical Random Access Channel

[0063] P-RNTI Paging Radio Network Temporary Identifier

[0064] PTAG Primary Timing Advance Group

[0065] PUCCH Physical Uplink Control Channel

[0066] PUSCH Physical Uplink Shared Channel

[0067] QoS Quality of Service

[0068] RA-RNTI Random Access Radio Network Temporary Identifier

[0069] RAR Random Access Response

[0070] RLC Radio Link Control

[0071] RRC Radio Resource Control

[0072] RTT Round Trip Time

[0073] RXOP Receive Opportunity

[0074] SDAP Service Data Adaptation Protocol

[0075] SDU Service Data Unit

[0076] SIM Subscriber Identity Module or Service Identity Module

[0077] SCell Secondary Cell

[0078] SpCell Special Cell

[0079] SDAP Service Data Adaptation Protocol

[0080] SI System Information

[0081] SPS Semi-Persistent Scheduling

[0082] SR Scheduling Request

[0083] SRS Sounding Reference Signal

[0084] SSB Synchronous Signal Block

[0085] STAG auxiliary timing advance group

[0086] TAG Timing Advance Group

[0087] TXOP Transmission Opportunity

[0088] RACH Random Access Channel

[0089] RAN Radio Access Network

[0090] RAT Radio Access Technology

[0091] Req Request

[0092] RLC Radio Link Control

[0093] RNTI Radio Network Temporary Identifier

[0094] RRC Radio Resource Control

[0095] Rsp response

[0096] RSU Roadside Unit

[0097] RX Receiver or receiving

[0098] RXOP RX Opportunity

[0099] TDM Time Division Multiplexing

[0100] TX Transmitter or Transmit

[0101] TXOP TX Opportunity

[0102] UCI Uplink Control Information

[0103] UE User Equipment

[0104] UL Uplink

[0105] UL-SCH Uplink Shared Channel

[0106] UMTS Universal Mobile Telecommunications System

[0107] USIM Universal SIM

[0108] Uu Interface connecting UE to RAN

[0109] V2X Vehicle-to-Everything Communications

[0110] A multi-SIM UE is a UE with two or more SIMs. A dual-SIM UE is a UE with two SIMs. The terms multi-SIM and dual-SIM are used interchangeably herein. Multi-USIM devices have become increasingly common in different countries / regions. A user may have both private and commercial subscriptions in one device or two private subscriptions for different services in one device (e.g., using one personal subscription and one "family circle" plan). However, support for multiple USIMs within a device is currently handled in an implementation-specific manner without any support from the 3GPP specification, resulting in a variety of implementations and UE behaviors (e.g., passive dual SIM, dual SIM single standby, dual SIM dual standby, dual SIM dual active, etc.). Such situations may result in increased complexity for UE vendors, unexpected UE behaviors for network vendors or operators, and a reduced user experience.

[0111] This document defines the following terms:

[0112] Passive Dual SIM: The device contains two SIMs, but only one can be selected at any given time, assuming that both SIMs share a single transceiver. While this implementation may be attractive in terms of equipment complexity or unexpected UE behavior for network vendors or operators, it does not achieve the mission of a dual SIM device to allow a user to have the dual SIM device reachable or available at any given time through two networks or to allow a user to perform simultaneous communications through two networks that may belong to the same or different operators.

[0113] Dual SIM Single Standby UE (DSSS): While actively communicating with the first system, the UE needs to occasionally check the other system (e.g., read the paging channel, perform measurements, or read system information). Depending on the UE implementation, i.e., single Rx or dual Rx, this occasional activity on the second system may or may not have any performance impact.

[0114] Dual SIM Dual Standby (DSDS): Both SIMs can be used for idle mode network connections, but when the radio connection is active, the second connection is disabled. Just as in the passive case, the SIMs in a DSDS device share a single transceiver. Through time multiplexing, both radio connections are maintained in idle mode. When one SIM is in a call on a network, although registration to the second network is maintained, it is no longer possible to maintain a radio connection to the second SIM's network, so the connection is unavailable for the duration of the call.

[0115] Dual SIM Dual Active (DSDA): Both SIMs can be used in both idle and connected modes, for example, one communication can be used for voice services and the other communication can be used for data services. It is generally assumed that each SIM has a dedicated transceiver, which means that there is no mutual dependence on idle or connected mode operation at the modem level. However, even in this case, simultaneous communication with two systems has challenges that can affect UE performance and network performance, some of which include UE power control and capability coordination so that the power budget and capability budget of the multi-SIM device are not exceeded.

[0116] Serving SIM: A SIM that has been selected for use by a UE for either idle mode operation or connected mode operation. In the following, the terms serving SIM and SIM are used interchangeably.

[0117] Serving RAN: The RAN that serves the UE for idle mode operation or connected mode operation. The serving RAN is associated with the serving SIM.

[0118] Serving PLMN: The PLMN that serves the UE for idle mode operation or connected mode operation. The serving PLMN is associated with the serving SIM.

[0119] Serving Network: The network that serves the UE for idle mode operation or connected mode operation. The serving network is associated with the serving SIM. The network can refer to the RAN or PLMN or a combination of them.

[0120] The term time domain multiplexing (TDM) of UE capabilities or UE capability multiplexing in the time domain refers to the sharing of the UE capabilities between the serving networks supporting idle mode operation or connected operation in the serving network, where the idle mode operation or connected mode operation can occur simultaneously. Examples of UE capabilities to be time domain multiplexed may include transmitters, receivers, transmit power budgets, etc.

[0121] This document describes multi-SIM use cases and deployment scenarios. It should be noted that these are provided as examples only and are not meant to limit the applicability of the solutions described herein in any way.

[0122] Use Case 1: A user is traveling from the United States to Asia and has a UE that supports multiple USIM cards. For cost reduction purposes, the UE is implemented with common radio and baseband components, with USIMs sharing access. Therefore, only one USIM can be active at any one time. The user purchases a USIM upon arrival to access cellular services while traveling within the destination country / region. The travel USIM card can provide local voice, text, and high-speed data services, while the home USIM card is mostly used to provide voice and text that the user may want to receive while traveling.

[0123] Use Case 2: Another prominent use case for utilizing multiple USIMs centers around a user who has both business and private subscription services and wants to use both services on the same device. The user's company issues a UE with subscription services to USIM 1 of operator 1, while the user also has private subscription services to USIM 2 of operator 2. The user wants to be able to receive voice calls from services and access data services based on the subscription of USIM 1 or USIM 2 depending on the time of day or application that is using the service.

[0124] The multi-SIM deployment scenario may include one or more of the following deployment scenarios in terms of each of the following subsystems.

[0125] Core network: a) Both SIMs are in 5GS; b) Both SIMs are in EPS; c) SIM A is in 5GS and SIM B is in EPS; d) SIM A and SIM B belong to the same operator (intra-MNO case); e) SIM A and SIM B belong to two different operators (inter-MNO case).

[0126] Radio Access Network (RAN): a) SIM A is in LTE and SIM B is in LTE; b) SIM A is in LTE and SIM B is in NR; c) SIM A is in NR and SIM B is in NR.

[0127] UE capability: a) Single RX and single TX; b) Dual RX and single TX; c) Dual RX and dual TX

[0128] AS state combinations: a): LTE IDLE and NR IDLE or INACTIVE; b): LTE CONNECTED and NR IDLE or INACTIVE; c): LTE IDLE and NR CONNECTED; d): LTE CONNECTED and NR CONNECTED; e): NR IDLE or INACTIVE and NR IDLE or INACTIVE; f): NR CONNECTED and NR CONNECTED; g): NR IDLE or INACTIVE and NR CONNECTED; h): LTE IDLE and LTE IDLE; i): LTE CONNECTED and LTE CONNECTED; j): LTE IDLE and LTE CONNECTED.

[0129] Figure 1 An exemplary UE state machine and state transitions in NR 100 are shown. Figure 1 The example shows a transition from the NR RRC_CONNECTED state 101 to the NR RRC_INACTIVE state 102 / from the NR RRC_INACTIVE state 102 to the NR RRC_CONNECTED state 101 during resumption / release in case of suspension and a transition from the NR RRC_CONNECTED state 101 to the NR RRC_IDLE state 103 / from the NR RRC_IDLE state 103 to the NR RRC_CONNECTED state 101 during establishment / release. A transition from the NR RRC_INACTIVE state 102 to the NR RRC_IDLE state 103 / from the NR RRC_IDLE state 103 to the NR RRC_INACTIVE state 102 during release is also shown.

[0130] Figure 2 An exemplary UE state machine and state transitions between NR / 5GC, E-UTRA / EPC and E-UTRA / 5GC 200 are shown. Figure 2The example of FIG. 1 shows a transition from the EUTRA RRC_CONNECTED state 201 to the EUTRA RRC_INACTIVE state 202 / from the EUTRA RRC_INACTIVE state 202 to the EUTRA RRC_CONNECTED state 201 during setup / release and a transition from the EUTRA RRC_CONNECTED state 201 to the EUTRA RRC_IDLE state 203 / from the EUTRA RRC_IDLE state 203 to the EUTRA RRC_CONNECTED state 201. A transition from the EUTRA RRC_INACTIVE state 202 to the EUTRA RRC_IDLE state 203 / from the EUTRA RRC_IDLE state 203 to the EUTRA RRC_INACTIVE state 202 during release is also shown.

[0131] Also shown are transitions from the NR RRC_CONNECTED state 204 to the NR RRC_INACTIVE state 205 / from the NR RRC_INACTIVE state 205 to the NR RRC_CONNECTED state 204 during setup / release and transitions from the NR RRC_CONNECTED state 204 to the NR RRC_IDLE state 206 / from the NR RRC_IDLE state 206 to the NR RRC_CONNECTED state 204 during setup / release. Also shown are transitions from the NR RRC_INACTIVE state 205 to the NR RRC_IDLE state 206 / from the NR RRC_IDLE state 206 to the NR RRC_INACTIVE state 205 during release.

[0132] Also shown is a transition from the EUTRA RRC_INACTIVE state 202 to the NR RRC_IDLE state 206 during reselection. Also shown is a transition from the NR RRC_INACTIVE state 205 to the EUTRA RRC_IDLE state 206 during reselection. Also shown is a transition from the EUTRA RRC_IDLE state 203 to the NR RRC_IDLE state 206 / from the NR RRC_IDLE state 206 to the EUTRA RRC_IDLE state 203 during reselection.

[0133] This document describes UE Registration Management (RM). A UE performs a registration when initially registering with the network due to certain mobility events, or when certain timers (ie, periodic registration update timer or non-3GPP deregistration timer) expire.

[0134] The RM states of the UE include RM-DEREGISTERED and RM-REGISTERED. The UE and the network maintain separate RM states for each RAT (ie, 3GPP and non-3GPP).

[0135] In RM-DEREGISTERED state: The UE is unreachable. The AMF may cache some UE context. The UE leaves this state by initiating an initial registration procedure.

[0136] In RM-REGISTERED state: UE performs registration update upon mobility and timer expiration. UE or AMF may perform deregistration procedure at any time. AMF may perform implicit deregistration upon timer expiration.

[0137] UE Connection Management (CM) generally refers to the state of the UE's NAS connection with the AMF. The UE and the network may maintain separate CM states for each RAT (i.e., 3GPP and non-3GPP).

[0138] The Registration Management (CM) states of the UE are CM-IDLE and CM-CONNECTED. The UE and the network may maintain separate CM states for each RAT (ie, 3GPP and non-3GPP).

[0139] In CM-IDLE state: No NAS signaling connection is established with AMF via N1

[0140] In CM-CONNECTED state: The UE has a NAS connection. This requires an RRC connection in the NG-RAN. The UE may be RRC-Inactive; in this case, reachability is managed by the RAN. When the UE's AN signaling connection is released, the UE may return to CM-IDLE state.

[0141] As noted above, dual SIM or multi-SIM operation presents many challenges in terms of UE behavior that, if not addressed by specification, may negatively impact the user experience and negatively impact overall system performance. The method and apparatus described herein address multi-SIM operation issues such as:

[0142] Issue 1: Enhancement of UE AS protocol architecture:

[0143] To minimize processing overhead and power consumption, enhancements to the UE protocol architecture (e.g., AS) and state machines are needed. For example, most idle mode procedures (e.g., cell selection (reselection) and pre-camping, to name a few) would benefit from coordination to reduce UE processing overhead and power consumption, especially in the case of multi-SIM intra-MNO deployment scenarios.

[0144] Issue 2: Potential collision of UL transmissions from two RATs:

[0145] This issue addresses the regulatory impact due to time domain multiplexing (TDM) of UE capabilities (such as transmitter chain capabilities) to maintain simultaneous uplink communications with two PLMNs. For example, considering a multi-SIM device with a single RX and a single TX or dual RX and a single TX, there is a need to study the use of TDM to implement a single TX chain, thereby allowing the process of suspending (or releasing) and resuming an ongoing connection in the 3GPP system associated with USIM A so that the UE can temporarily access the 3GPP system associated with USIM B. There is also a need to study the associated UE behavior, including the handling of HARQ timing and UE timers (such as MAC timers and RRC timers) due to UL transmission gaps. This issue should be understood in the context of inter-PLMN operations, where the multi-SIM deployment scenarios highlighted in this article cover the listed CN deployment scenarios, the listed RAN deployment scenarios, and the listed connection mode related AS state combinations.

[0146] Issue 3: Potential conflict in DL data reception, e.g., both RATs are in CONNECTED:

[0147] This issue addresses the regulatory impact due to time domain multiplexing (TDM) of the receiver chain to maintain simultaneous downlink communications with two PLMNs. For example, considering a multi-SIM device with a single RX and a single TX or a single RX and dual TX, there is a need to study the use of TDM to implement a single RX chain, thereby allowing the process of suspending (or releasing) and resuming an ongoing connection in the 3GPP system associated with USIM A so that the UE can temporarily access the 3GPP system associated with USIM B. There is also a need to study the associated UE behavior, including the handling of HARQ timing and UE timers (such as MAC timers and RRC timers) due to DL reception gaps. This issue should be understood in the context of inter-PLMN operations, where the multi-SIM deployment scenarios highlighted in this article cover the listed CN deployment scenarios, the listed RAN deployment scenarios, and the listed connection mode related AS state combinations.

[0148] Figure 3An exemplary access stratum (AS) protocol 300 is shown. According to one embodiment, the AS protocol of a multi-SIM UE may include an upper AS layer 301, a middle AS layer 302, and a lower AS layer 303. In the control plane, the upper AS layer 301 may implement RRC functions. The lower AS layer 303 may implement the functions of the MAC layer and the PHY layer. The lower AS layer 303 also includes a common MAC (CoMAC) for the UE and a dedicated MAC (DeMAC) for each service SIM (i.e., for a service network associated with each service SIM). The CoMAC may assist the DeMAC entity, may arbitrate its actions, and may implement logic for efficient coordination across service networks associated with the service SIMs, for example, logic for time domain multiplexing of UE capabilities (such as transceivers or power budgets across service networks associated with the service SIMs of the UE).

[0149] The NAS may include an upper NAS and a lower NAS, wherein the upper NAS may include a common NAS (CoNAS) for the UE and a set of DeNAS entities with one dedicated NAS (DeNAS) per serving SIM (i.e., for a serving network associated with each serving SIM). The CoNAS may assist the DeNAS entities and may coordinate their actions in order to ensure efficient operation of the UE, for example, in order to minimize UE processing overhead, power consumption and achieve efficient overall system performance.

[0150] New UE-level state machines and SIM-level state machines for both the RRC layer and the NAS layer are also proposed.

[0151] This document describes an AS procedure for implementing TDM sharing of RX / TX chains. This document describes a method for performing dynamic sharing of RX / TX chains based on a request to the RX / TX chain arbiter (where access can be granted on a first-come, first-served basis), USIM identity, or priority of the service for which access is being requested.

[0152] This document describes a method for performing semi-static sharing of RX / TX chains based on suspending or releasing an RRC connection, where each SIM is associated with a dedicated RRC (DeRRC) layer and a common RRC (CoRRC) layer can determine which DeRRC should be active at a given time.

[0153] A method for performing a random access procedure that takes into account the effect of sharing RX / TX chains is described herein, including:

[0154] Mechanism for performing random access resource selection after failure to access the RX / TX chain;

[0155] a mechanism for adapting the start of the RAR window, conditional upon gaining access to the RX chain within the duration of the ra-ResponseWindow; and

[0156] A mechanism for adapting the start of the contention resolution window, conditional on gaining access to the RX chain within the duration of ra-ContentionResolutionTimer.

[0157] A method for performing sharing of an RX / TX chain based on adapting MAC counters and timers in response to lost RXOPs / TXOPs is described herein, comprising:

[0158] A mechanism for controlling the setting of an inhibit timer and the incrementing of a transmit counter in response to a lost TXOP; and

[0159] Mechanism for pausing or extending a timer used to control DL monitoring in response to a lost RXOP.

[0160] Figure 4 An RRC 400 is shown. The RRC may include a common RRC (CoRRC) entity 401 and a set of dedicated RRC (DeRRC) entities 402, one DeRRC entity per serving SIM (i.e., for a serving network associated with each serving SIM). The CoRRC 401 may assist the DeRRC 402 entities and may coordinate / arbitrate their actions in order to ensure efficient operation of the UE, e.g., in order to minimize UE processing overhead, power consumption, and achieve efficient overall system performance (including use of radio resources). The CoRRC 401 may implement logic for efficient coordination across serving networks associated with a serving SIM, e.g., logic for time domain multiplexing of UE capabilities (such as transceivers or power budgets across serving networks associated with the UE's serving SIM).

[0161] In one embodiment, the CoRRC entity 401 within the UE may implement multiplexing functions or one or more shared capabilities of the UE, such as a shared transmitter, a shared receiver, a shared transceiver, a shared power budget, a shared amplifier, or any other transmit and / or receive shared hardware.

[0162] In another embodiment, the CoRRC entity 401 may assist other entities in the UE or in the network (e.g., entities in the lower AS) in multiplexing one or more capabilities of the UE shared between service networks associated with the SIM of the UE. DeRRC may implement the RRC protocol architecture according to, for example, a legacy system that supports carrier aggregation or multiple connections within a service network associated with the same SIM. For example, in the case of multiple connections in a service network for a given SIM, the DeRRC associated with the service network may be configured in multiple instances, one instance for each cell group (e.g., a primary cell group and a secondary cell group).

[0163] The CoRRC entity 401 may implement one or more functions of an RRC IDLE state, an RRC INACTIVE state, or an RRC CONNECTED state. Similarly, the DeRRC may implement one or more functions of an RRC IDLE state, an RRC INACTIVE state, or an RRC CONNECTED state. In one embodiment, the CoRRC may implement the RRC IDLE or RRC INACTIVE functions, while the DeRRC may implement the RRC CONNECTED functions, wherein the CoRRC ensures coordination between the DeRRC entity and the reuse of the shared capabilities of the UE across independent networks, for example, to enable efficient operation of the UE operation so as to minimize UE processing overhead, power consumption. The CoRRC may implement logic that reflects the overall RRC state of the UE, as opposed to the state regarding the serving network associated with each of the SIMs in the UE.

[0164] In the user plane, the upper layer may or may not exist. For example, in one embodiment where the AS upper layer exists in the user plane, the upper layer may implement SDAP functionality.

[0165] Figure 5 A multi-SIM UE intermediate AS in C-plane 500 is shown. Figure 5 The example of FIG. 5 shows that in the control plane, an intermediate AS may implement the functions of the PDCP layer 501 and the RLC layer 502. The RLC 502 and the PDCP 501 may be dedicated to each serving SIM.

[0166] Figure 6 A multi-SIM UE intermediate AS in U-plane 600 is shown. Figure 6 The example of FIG. 6 shows that in the user plane, the intermediate AS may implement the functions of the SDAP layer 601, the PDCP layer 602, and the RLC layer 603. The SDAP 601, the RLC 602, and the PDCP 603 may be specific to each service network associated with each SIM.

[0167] Figure 7A multi-SIM UE underlying AS 700 is shown. Figure 7 It is shown that the lower layer AS can implement the functions of the MAC layer 701 and the PHY layer 702 .

[0168] Figure 8 A multi-SIM MAC 800 is shown. Figure 8 It is shown that the MAC may include a common MAC (CoMAC) entity 801 and a set of dedicated MAC (DeMAC) entities 802, one DeMAC entity per serving SIM.

[0169] The CoMAC 801 may assist the DeMAC 802 entity and may coordinate its actions to ensure efficient operation of the UE, for example, to minimize UE processing overhead, power consumption and achieve efficient overall system performance (including use of radio resources). In one embodiment, the CoMAC entity within the UE may implement multiplexing functions or one or more shared capabilities of the UE, such as a shared transmitter, a shared receiver, a shared transceiver, a shared power budget, a shared shared amplifier, or any other transmit and / or receive shared hardware. In another embodiment, the CoMAC entity may assist other entities in the UE or in the network (e.g., an entity in an upper AS) to multiplex one or more capabilities of the UE shared between service networks associated with the SIM of the UE. DeMAC may implement a MAC protocol architecture in accordance with, for example, an old system that supports carrier aggregation or multiple connections within a service network associated with the same SIM. For example, in the case of multiple connections in a service network for a given SIM, the DeMAC associated with the service network may be configured in multiple instances, one instance for each cell group (e.g., a primary cell group and a secondary cell group).

[0170] Fig. 9 An exemplary multi-SIM NAS 900 is shown. Fig. 9 It is shown that a non-access stratum (NAS) protocol of a multi-SIM UE may be modeled to include an upper layer NAS 901 and a lower layer NAS 902 .

[0171] Fig.10 Another exemplary multi-SIM NAS 1000 is shown. In this example, the NAS may include a common NAS (CoNAS) 1001 and a set of dedicated NAS (DeNAS) entities 1002, one DeNAS entity per serving SIM.

[0172] Fig.11 A multi-SIM upper layer NAS 1100 is shown. The upper layer NAS 1100 includes a CoNAS 1101 .

[0173] Fig.12A multi-SIM lower layer NAS 1200 is shown. The lower layer NAS 1200 comprises a DeNAS entity 1201 .

[0174] CoNAS may assist DeNAS entities and coordinate their actions to ensure efficient operation of the UE, for example, to minimize UE processing overhead, power consumption and achieve efficient overall system performance. In one embodiment, the CoNAS entity within the UE may implement a multiplexing function of one or more shared capabilities of the UE, such as the number of simultaneous communication sessions within the UE. In another embodiment, the CoNAS entity may assist other entities in the UE or in the network (e.g., entities in the lower layer NAS or in the AS) in multiplexing one or more capabilities of the UE shared between service networks associated with the SIM of the UE. DeNAS may implement the NAS protocol architecture in accordance with, for example, a legacy system that supports 3GPP AS and non-3GPP access to each of the service networks associated with the SIM of the UE. CoNAS may handle or assist in the coordination of the handling of user preferences (e.g., the priority of services between service networks associated with the SIM in the UE).

[0175] CoNAS may implement or assist in the implementation of one or more functions of the NAS IDLE state (e.g., CM IDLE or ECM IDLE) or one or more functions of the NAS CONNECTED state (e.g., CM CONNECTED or ECM CONNECTED). Similarly, DeNAS may implement one or more functions of the NAS IDLE state or the NAS CONNECTED state. For example, in one embodiment, CoNAS may implement or assist in the implementation of functions such as PLMN selection or UE reachability in the NAS IDLE state. Similarly, when the UE is in the NAS CONNECTED state with respect to some of the service networks associated with the SIM in the UE, CoNAS may implement or assist in the implementation of policy coordination and UE reachability. As opposed to the state regarding the service networks associated with each of the SIMs in the UE, CoNAS may implement logic that reflects the overall NAS state of the UE.

[0176] In one embodiment, the DeNAS entity may be associated with each SIM in the SIM of the UE. The DeNAS entity may maintain one or more registration management (RM) states (e.g., an RM state for 3GPP access and an RM state for non-3GPP access). The DeNAS entity may also maintain one or more connection management (CM) states (e.g., a CM state for 3GPP access and a CM state for non-3GPP access). As described above, CoNAS may implement logic that reflects the overall NAS state of the UE on each available RAT in the available RATs of the UE. In addition, the CoNAS state machine may be driven by requests and indications received from the DeNAS entity in the lower layer NAS. The CoNAS state machine and how its states transition are further described below. The CoNAS entity may maintain a separate state for each available RAT in the available RATs of the UE (i.e., non-3GPP and 3GPP). It should be noted that a separate state may be maintained for each transceiver. In other words, if the UE includes two 3GPP transceivers, the UE may maintain a CoNAS state for each transceiver.

[0177] Fig.13 A high-level view of the NAS and AS protocol stacks in a UE 1300 is shown. The NAS 1301 may include a shared NAS 1302 and a dedicated NAS 1303. The RRC 1304 may include a shared RRC 1305 and a dedicated RRC 1304.

[0178] Fig.14 A high level diagram of a UE to network NAS and AS protocol stack 1400 is shown. Fig.14 The example of FIG. 14 shows that UE 1401 may include NAS 1410 including a shared NAS 1411 and a dedicated NAS 1410. UE 1401 may include RRC 1420 including a shared RRC 1421 and a dedicated RRC 1420.

[0179] Fig.14 The example also shows two PLMNs, namely, PLMN A 1402 and PLMN B 1403. PLMN A 1402 may include a base station 1430, which includes an RRC 1431, which includes a shared RRC 1432 and a dedicated RRC 1433. PLMN A 1402 may include a CN 1440, which includes a NAS 1441, which includes a shared NAS 1442 and a dedicated NAS 1443.

[0180] PLMN B 1403 may include a base station 1450 including an RRC 1451 including a shared RRC 1452 and a dedicated RRC 1453. PLMN B 1403 may include a CN 1460 including a NAS 1461 including a shared NAS 1462 and a dedicated NAS 1463.

[0181] It should be noted that Fig.13 The use of the depicted multi-SIM UE control plane architecture does not require the network to implement a similar architecture, such as having a shared NAS to a dedicated NAS offload or a shared RRC to a dedicated RRC offload, as Fig.14 shown.

[0182] An RRC state machine is described herein. An RRC state may be described with respect to a serving SIM or equivalently with respect to a serving network associated with a serving SIM. Such an RRC state may be represented as a SIM-level RRC state (i.e., an RRC state within the scope of a serving SIM). Similarly, an RRC state may be described with respect to a UE as a whole (i.e., as a combination of individual serving SIM-level RRC states). Such an RRC state may be represented as a UE-level RRC state.

[0183] Fig.15 An example RRC state machine 1500 is shown. Fig.15 The example of FIG. 1 shows the overall RRC state machine at the UE level, where the RRC architecture is as follows: Figure 4 Depicted. Fig.15 Each RRC state captured in the RRC state can be referred to as Figure 4 CoRRC or DeRRC depicted. The RRC state machine for a multi-SIM UE may be designed to reduce any increase in power consumption and avoid shortening of UE battery life due to the multi-SIM operating mode. It is proposed to introduce a multi-SIM power saving operating mode. A multi-SIM mode UE may be designed to operate in a multi-SIM power saving mode, or may be designed to operate in such a mode based on UE configuration (e.g., via a GUI), UE capabilities, or user preferences. The UE may exchange signaling with the network to determine whether it can operate in a multi-SIM power saving mode.

[0184] The UE level RRC states are described as follows:

[0185] FULL RRC IDLE 1501: In this state, the UE may be in a SIM-level RRC IDLE state for each SIM in the SIM within the UE (i.e., each SIM in the SIM in the UE or alternatively each SIM in the SIM in the UE selected for use), the UE has performed PLMN selection and camped on a cell, but has no RRC connection in any of the cells in which the UE has camped. Note that hereinafter, the terms "SIM in the UE" or "SIM in the UE selected for use" or "serving SIM" are used interchangeably. The UE may transition from this state to the MIXED_RRC_IDLE_CONNECTED 1506 state. For example, when the UE transitions to SIM-level RRC_CONNECTED for one of the SIMs in the UE, the UE transitions from FULL RRC IDLE 1501 to the MIXED_RRC_IDLE_CONNECTED 1506 state. In the FULL RRC_IDLE state 1501, the UE may perform "reduced power" idle mode operations, such as "reduced power" support for PLMN selection, "reduced power" cell reselection, and "reduced power" cell pre-camping. The term "reduced power" and the term "multi-SIM power saving" mode may be used interchangeably herein. In addition to the reduced power operations, the FULL_RRC_IDLE state 1501 may also be described as follows:

[0186] SIM-specific DRX may be configured by upper layers. In addition, UE-specific DRX may be configured by upper layers. In this case, the UE may provide the network with SIM-specific DRX or UE-specific DRX.

[0187] UE controlled mobility based on network configuration, or reduced power UE controlled mobility based on UE capabilities, user preferences and network configuration;

[0188] The UE of each serving SIM can perform the following operations:

[0189] maintaining at least one P-RNTI for each of the serving networks associated with a SIM in the UE. Additionally, the UE may maintain a common P-RNTI across serving networks regardless of the SIM with which the serving network is associated;

[0190] Monitor short messages transmitted via DCI using P-RNTI;

[0191] maintaining at least one 5G-S-TMSI, i.e., at least one 5G-S-TMSI for each of the serving networks associated with the SIM in the UE;

[0192] 5G-S-TMSI is used to monitor the paging channel for CN paging. The monitoring of paging can be performed using multi-SIM non-power saving mode or multi-SIM power saving mode;

[0193] performing neighbor cell measurements and cell selection (reselection) as needed taking into account UE operation and SIM level status with respect to other SIMs; cell measurements and cell selection (reselection) may be performed using a multi-SIM non-power saving mode or a multi-SIM power saving mode; and

[0194] Acquire system information and may send SI request (if configured). Acquisition of system information or transmission of SI request may be performed using multi-SIM non-power saving mode or multi-SIM power saving mode.

[0195] FULL RRC INACTIVE 1502: In this state, the UE is in a SIM level RRC INACTIVE state for each of the SIMs in the UE. In the FULL RRC_INACTICE state 1502, the UE may perform "reduced power" idle mode operations, such as "reduced power" support for PLMN selection, "reduced power" cell reselection, and "reduced power" cell camping. In addition to the reduced power operations, the FULL_RRC_INACTIVE state 1502 may also be described as follows:

[0196] SIM-specific DRX may be configured by upper layers; in addition, UE-specific DRX may be configured by upper layers. In this case, the UE may provide the network with SIM-specific DRX or UE-specific DRX.

[0197] UE controlled mobility based on network configuration, or reduced power UE controlled mobility based on UE capabilities, user preferences and network configuration;

[0198] The UE stores a dedicated UE-inactive AS context and a common UE-inactive AS context, ie, context for both DeRRC and CoRRC.

[0199] For each serving SIM or serving network, the RAN-based notification area is configured by the RRC layer.

[0200] The UE of each serving SIM can perform the following operations:

[0201] maintaining at least one P-RNTI for each of the serving networks associated with a SIM in the UE. Additionally, the UE may maintain a common P-RNTI across serving networks (e.g., in the case of RAN sharing), regardless of the SIM with which the serving network is associated;

[0202] Monitor short messages transmitted via DCI using P-RNTI;

[0203] maintaining at least one 5G-S-TMSI, i.e., at least one 5G-S-TMSI for each of the serving networks associated with the SIM in the UE;

[0204] 5G-S-TMSI is used to monitor the paging channel for CN paging; paging monitoring can be performed using multi-SIM non-power saving mode or multi-SIM power saving mode.

[0205] Perform neighbor cell measurements and cell selection (reselection); Cell measurements and cell selection (reselection) may be performed using multi-SIM non-power saving mode or multi-SIM power saving mode;

[0206] Performing RAN-based notification area updates periodically and when moving outside of a configured RAN-based notification area. Performing RAN-based notification area updates may be performed using a multi-SIM non-power saving mode or a multi-SIM power saving mode; and

[0207] Acquire system information and may send SI request (if configured). Acquisition of system information or transmission of SI request may be performed using multi-SIM non-power saving mode or multi-SIM power saving mode.

[0208] The UE may transition from this state to MIXED_RRC_INACTIVE_CONNECTED 1504 or MIXED_RRC_IDLE_INACTIVE 1505. Note that for the remainder of this document, the UE level state transitions are described one SIM level state transition at a time.

[0209] Transition to MIXED_RRC_INACTIVE_CONNECTED 1504: The UE may transition to this state from FULL_RRC_INACTIVE 1502 when the UE transitions to SIM level RRC_CONNECTED for one of the SIMs in the UE.

[0210] Transition to MIXED_RRC_IDLE_INACTIVE 1505: The UE may transition to this state from FULL_RRC_INACTIVE 1502 when the UE transitions to SIM level RRC_IDLE for one of the SIMs in the UE.

[0211] FULL RRC CONNECTED 1503: In this state, the UE is in a SIM-level RRC_CONNECTED state for each of the SIMs in the UE. In this state, the UE stores a dedicated AS context and a common AS context, where the common AS context relates to context information across the serving networks associated with the SIMs in the UE. The UE may transition from this state to a MIXED_RRC_IDLE_CONNECTED state 1506 or a MIXED_RRC_INACTIVE_CONNECTED state 1504.

[0212] Transition to MIXED_RRC_IDLE_CONNECTED state 1506: When the UE transitions to SIM level RRC_IDLE for one of the SIMs in the UE, the UE may transition to this state from FULL_RRC_CONNECTED state 1503. The UE may perform RRC_IDLE mode procedures specific to multi-SIM power save mode or multi-SIM non-power save mode, e.g., based on network configuration or UE preference settings.

[0213] Transition to MIXED_RRC_INACTIVE_CONNECTED state 1504: When the UE transitions to SIM level RRC_INACTIVE for one of the SIMs in the UE, the UE may transition to this state from FULL_RRC_CONNECTED state 1503. The UE may perform RRC_INACTIVE mode procedures specific to multi-SIM power save mode or multi-SIM non-power save mode, e.g., based on network configuration or UE preference settings.

[0214] MIXED RRC IDLE_CONNECTED 1506: In this state, the UE is in the SIM-level RRC_IDLE state for one or more SIMs, and in the SIM-level RRC_CONNECTED state for one or more SIMs, and none of the SIMs in the UE is in the RRC_INACTIVE state. For the SIMs in the RRC_IDLE state, the UE may, for example, based on network configuration or UE preference settings, perform RRC_IDLE mode procedures specific to multi-SIM power saving mode or multi-SIM non-power saving mode, as described in this document. The UE may transition from this state to the FULL_RRC_CONNECTED state 1503, the FULL_RRC_IDLE state 1501, the MIXED RRC_IDLE_INACTIVE state 1505, or the MIXED_RRC_IDLE_INACTIVE_CONNECTED state 1507.

[0215] Transition to FULL_RRC_CONNECTED state 1503: The UE may transition to this state from MIXED_RRC_IDLE_CONNECTED state 1506 when the UE transitions to SIM-level RRC_CONNECTED for the UE's only SIM in SIM-level RRC_IDLE state.

[0216] Transition to FULL_RRC_IDLE state 1501: The UE may transition to this state from MIXED_RRC_IDLE_CONNECTED state 1506 when the UE transitions to SIM level RRC_IDLE for the UE's only SIM in SIM level RRC_CONNECTED.

[0217] Transition to MIXED RRC_IDLE_INACTIVE state 1505: The UE may transition to this state from MIXED_RRC_IDLE_CONNECTED state 1506 when the UE transitions to SIM-level RRC_INACTIVE state for the UE's only SIM in SIM-level RRC_CONNECTED state.

[0218] Transition to MIXED_RRC_IDLE_INACTIVE_CONNECTED state 1507: The UE may transition to this state from MIXED_RRC_IDLE_CONNECTED state 1506 when the UE transitions to SIM-level RRC_INACTIVE state for one of the SIMs in which the UE is in SIM-level RRC_CONNECTED state.

[0219] MIXED RRC INACTIVE_CONNECTED 1504: In this state, the UE is in the SIM-level RRC_INACTIVE state for one or more SIMs, and in the SIM-level RRC_CONNECTED state for one or more SIMs, and none of the SIMs is in the RRC_IDLE state. For the SIMs in the RRC_INACTIVE state, the UE may, for example, based on network configuration or UE preference settings, perform RRC_INACTIVE mode procedures specific to multi-SIM power saving mode or multi-SIM non-power saving mode, as described in this document. The UE may transition from this state to the FULL_RRC_CONNECTED state 1503, the FULL_RRC_INACTIVE state 1502, the MIXED_RRC_IDLE_INACTIVE state 1505, the MIXED_RRC_IDLE_CONNECTED state 1506, or the MIXED_RRC_IDLE_INACTIVE_CONNECTED state 1507.

[0220] Transition to FULL_RRC_CONNECTED state 1503: The UE may transition to this state from MIXED_RRC_INACTIVE_CONNECTED state 1504 when the UE transitions to SIM-level RRC_CONNECTED state for the UE's only SIM that is in SIM-level RRC_INACTIVE state.

[0221] Transition to FULL_RRC_INACTIVE state 1502: The UE may transition to this state from MIXED_RRC_INACTIVE_CONNECTED state 1504 when the UE transitions to SIM-level RRC_INACTIVE state for the UE's only SIM in SIM-level RRC_CONNECTED state.

[0222] Transition to MIXED_RRC_IDLE_INACTIVE state 1505: The UE may transition to this state from MIXED_RRC_INACTIVE_CONNECTED state 1504 when the UE transitions to SIM-level RRC_INACTIVE state for the UE's only SIM in SIM-level RRC CONNECTED state.

[0223] Transition to MIXED_RRC_IDLE_CONNECTED state 1506: The UE may transition to this state from MIXED_RRC_INACTIVE_CONNECTED state 1504 when the UE transitions to SIM-level RRC_IDLE for the UE's only SIM that is in SIM-level RRC_INACTIVE state.

[0224] Transition to MIXED_RRC_IDLE_INACTIVE_CONNECTED state 1507: The UE may transition to this state from MIXED_RRC_INACTIVE_CONNECTED state 1504 when the UE transitions to SIM-level RRC_IDLE state for one of the SIMs in which the UE is in SIM-level RRC_CONNECTED state or for one of the SIMs in which the UE is in RRC_INACTIVE state.

[0225] MIXED RRC IDLE_INACTIVE 1505: In this state, the UE is in the SIM-level RRC_IDLE state for one or more SIMs, and in the SIM-level RRC_INACTIVE state for one or more SIMs, and none of the SIMs are in the RRC_CONNECTED state. The UE may, for example, perform RRC_IDLE mode procedures or RRC_INACTIVE mode procedures specific to multi-SIM power saving mode or multi-SIM non-power saving mode based on network configuration or UE preference settings, as described in this document. The UE may transition from this state to the FULL_RRC_IDLE state 1501, the MIXED_RRC_IDLE_CONNECTED state 1506, the MIXED RRC_INACTIVE_CONNECTED 1507, or the MIXED_RRC_IDLE_INACTIVE_CONNECTED state.

[0226] Transition to FULL_RRC_IDLE state 1501: The UE may transition to this state from MIXED_RRC_IDLE_INACTIVE state 1505 when the UE transitions to SIM-level RRC_IDLE for the UE's only SIM that is in SIM-level RRC_INACTIVE state.

[0227] Transition to MIXED_RRC_IDLE_CONNECTED state 1506: The UE may transition to this state from MIXED_RRC_IDLE_INACTIVE state 1505 when the UE transitions to SIM-level RRC_CONNECTED for the UE's only SIM that is in SIM-level RRC_INACTIVE state.

[0228] Transition to MIXED_RRC_INACTIVE_CONNECTED state 1504: The UE may transition to this state from MIXED_RRC_IDLE_INACTIVE state 1505 when the UE transitions to SIM-level RRC_CONNECTED state for the UE's only SIM in SIM-level RRC_IDLE state.

[0229] Transition to MIXED_RRC_IDLE_INACTIVE_CONNECTED state 1507: The UE may transition to this state from MIXED_RRC_IDLE_INACTIVE state 1505 when the UE transitions to SIM-level RRC_CONNECTED state for one of the SIMs in which the UE is in SIM-level RRC_INACTIVE state or for one of the SIMs in which the UE is in SIM-level RRC_IDLE state.

[0230] MIXED RRC_IDLE_INACTIVE_CONNECTED 1507: In this state, the UE is in a SIM-level RRC_IDLE state for one or more SIMs, in a SIM-level RRC_INACTIVE state for one or more SIMs, and in a SIM-level RRC_CONNECTED state for one or more SIMs. The UE may, for example, based on network configuration or UE preference settings, perform RRC_IDLE mode procedures or RRC_INACTIVE mode procedures specific to multi-SIM power saving mode or multi-SIM non-power saving mode, as described in this document. The UE may transition from this state to one of the above-mentioned mixed RRC states. For example, the UE may transition from this state to MIXED RRC_INACTIVE_CONNECTED state 1504, MIXEDRRC_IDLE_CONNECTED state 1506, or MIXED RRC_IDLE_INACTIVE state 1505.

[0231] Transition to MIXED RRC_INACTIVE_CONNECTED state 1504: The UE may transition to this state from MIXED_RRC_IDLE_INACTIVE_CONNECTED state 1507 when the UE transitions to SIM-level RRC_CONNECTED state for the UE's only SIM in SIM-level RRC_IDLE state.

[0232] Transition to MIXED RRC_IDLE_CONNECTED state 1506: The UE may transition to this state from MIXED_RRC_IDLE_INACTIVE_CONNECTED state 1507 when the UE transitions to SIM-level RRC_CONNECTED state for the UE's only SIM in SIM-level RRC_INACTIVE state or when the UE transitions to SIM-level RRC_IDLE state for the UE's only SIM in SIM-level RRC_INACTIVE state.

[0233] Transition to MIXED RRC_IDLE_INACTIVE state 1505: The UE may transition to this state from MIXED_RRC_IDLE_INACTIVE_CONNECTED state 1507 when the UE transitions to SIM-level RRC_INACTIVE state for the UE's only SIM in SIM-level RRC_CONNECTED state or when the UE transitions to SIM-level RRC_IDLE state for the UE's only SIM in SIM-level RRC_CONNECTED state or when the UE transitions to SIM-level RRC_IDLE state for the UE's only SIM in SIM-level RRC_CONNECTED state.

[0234] Fig.16 A UE level CoNAS state machine 1600 is shown. The CoNAS state machine for a multi-SIM UE may be designed to reduce any increase in power consumption and avoid shortening of UE battery life due to a multi-SIM mode of operation. The CoNAS state machine may have FULL RM-DEREGISTERED 1601, SINGLE RM-REGISTERED 1602, and MULTIPLE RM-REGISTERED states 1603. The states may generally be differentiated or characterized by the amount of arbitration that the CoNAS entity needs to perform between the DeNAS entities. The arbitration performed by the CoNAS entity involves when each DeNAS entity is permitted to use a transceiver to send or receive NAS signaling. One CoNAS state machine may be maintained by the CoNAS of each transceiver.

[0235] Power saving mode (PSM) and extended idle mode DRX parameters may be proposed by the UE to the network during the registration process. The DeNAS entity may provide the values ​​of the CoNAS entity, which are then provided to the network, and the CoNAS may propose new values ​​or approve these values. For example, the CoNAS entity may propose a longer periodic registration timer or a shortened activity timer to make the DeNAS state more likely to be CM-IDLE for a longer period of time. Alternatively, the CoNAS entity may propose timers that are better aligned with the timers of other DeNAS entities to avoid situations when DeNAS entities request to perform functions at the same time.

[0236] The following describes the states of the CoNAS state machine. As mentioned above, these states relate to a single RAT (ie, non-3GPP or 3GPP).

[0237] FULL RM-DEREGISTERED 1601: In this state, all RM states of all DeNAS entities are in RM-DEREGISTERED for the associated RAT (i.e., 3GPP or non-3GPP). The FULL RM-DEREGISTERED state may be further characterized as follows:

[0238] When in this state, the CoNAS entity may receive a request from any DeNAS entity for permission to send a registration request for the associated RAT. The CoNAS entity may typically grant this request because none of the RM states of the other DeNAS state machines is currently in RM-REGISTERED for the associated RAT; therefore, no arbitration of NAS functions is required.

[0239] When the CoNAS entity receives an indication from the DeNAS entity that it is now RM-REGISTERED on the associated RAT, the CoNAS entity may transition to the SINGLE RM-REGISTERED state 1602 . Fig.16 This transformation is shown in step 1 of .

[0240] SINGLE RM-REGISTERED 1602: In this state, only one DeNAS entity's RM state is in RM-REGISTERED on the associated RAT (i.e., 3GPP or non-3GPP); the rest are in RM-DEREGISTERED on the associated RAT. In this state, the CoNAS entity does not need to perform any arbitration functions until the RM state machine associated with the second DeNAS entity indicates that it wishes to initiate registration on the associated RAT. The SINGLE RM-REGISTERED state 1602 can be further characterized as follows:

[0241] When in this state, the CoNAS entity may receive a request for permission to send a NAS message request (e.g., a mobility registration update, a periodic registration update, a service request, or a UE configuration update) from a DeNAS entity that is RM-REGISTERED on the associated RAT. The CoNAS entity may typically grant the request because none of the RM states of the other DeNAS state machines is currently RM-REGISTERED for the associated RAT; therefore, no arbitration of NAS functions is required.

[0242] When in this state, the CoNAS entity may receive a request for permission to send an initial registration request for the associated RAT from a DeNAS entity whose RM state machine is in RM-DEREGISTERED on the associated RAT. The CoNAS entity may indicate to the DeNAS an acceptable time to send the request, and the CoNAS may indicate to other DeNAS entities (whose RM state machine may be in RM-REGISTERED) that they should not initiate new NAS activities on the associated RAT at the same time.

[0243] Note that when the DeNAS entity may receive a notification that a different DeNAS entity may use the associated RAT at a specific time, the DeNAS may release the AN signaling connection, thereby causing the CM state of the DeNAS to transition to CM-IDLE.

[0244] The CoNAS entity may transition to the FULL RM-DEREGISTERED state 1601 when the DeNAS entity that was RM-REGISTERED on the associated RAT indicates that it is now RM-DEREGISTERED on the associated RAT. Fig.16 This transformation is shown in step 2 of .

[0245] The CoNAS entity may transition to the MULTIPLE RM-REGISTERED state 1603 when the DeNAS entity that was not RM-REGISTERED on the associated RAT indicates that it is now RM-REGISTERED on the associated RAT. Fig.16 This transformation is shown in step 3 of .

[0246] Note that when the CoNAS entity notifies the DeNAS entity that it can perform some operations (e.g., periodic registration updates), the CoNAS entity may also indicate to the DeNAS entity that the DeNAS entity is only allowed to perform specific operations and is not allowed to perform additional activities (e.g., establishing a PDU session and sending UL data or receiving downlink data). The CoNAS entity may indicate this to the DeNAS layer because the DeNAS entity is waiting to perform some higher priority activities. Therefore, when the DeNAS performs a periodic registration update, the DeNAS may indicate to the network that it is performing a periodic registration update, but it cannot perform other operations (i.e., receive DL data) at this time. The UE may indicate this condition by providing a PSM activity timer value of 0 during the periodic registration. Therefore, the UE is instructed to immediately enter CM-IDLE again.

[0247] MULTIPLE RM-REGISTERED 1603: In this state, at least two DeNAS entities are RM-REGISTERED on the associated RAT. In this state, the CoNAS entity needs to perform arbitration between the NAS functions of the DeNAS entities that have at least one state machine that is RM-REGISTERED on the associated RAT. The MULTIPLE RM-REGISTERED 1603 state can be further described as follows:

[0248] When in this state, the CoNAS entity may receive a request for permission to send a NAS message request (e.g., Mobility Registration Update, Periodic Registration Update, Service Request, or UE Configuration Update) from a DeNAS entity with an RM state machine in RM-REGISTERED on the associated RAT. The CoNAS entity may indicate to the requesting DeNAS entity an acceptable time to send a request for the associated RAT, and it may indicate to other DeNAS entities that no new NAS activities should be initiated on the associated RAT at the same time.

[0249] It should be noted that the request from the DeNAS entity to the CoNAS entity to send a periodic registration update may be based on the periodic registration update timer being about to expire.

[0250] It is noted that the request to send a mobility registration update from the DeNAS entity to the CoNAS entity may be based on a mobility event.

[0251] Alternatively, the DeNAS entity may provide a periodic registration update timer (or non-3GPP deregistration timer) to the CoNAS entity so that the CoNAS entity can detect when a periodic registration update is required.

[0252] Alternatively, the DeNAS entity may provide the CoNAS entity with a registration area so that the CoNAS entity can detect when a mobility registration update is required.

[0253] Note that when the DeNAS entity may receive a notification that a different DeNAS entity may use the associated RAT at a specific time, the DeNAS may release the AN signaling connection, thereby causing the CM state of the DeNAS to transition to CM-IDLE.

[0254] When in this state, the CoNAS entity may receive a request for permission to send a registration request from a DeNAS entity whose RM state is in RM-DEREGISTERED on the associated RAT. The CoNAS entity may indicate to the DeNAS an acceptable time to send a request for the associated RAT, and the CoNAS may indicate to other DeNAS entities (whose RM state machines may be in RM-REGISTERED) that they should not initiate new NAS activities on the associated RAT at the same time.

[0255] Note that when the DeNAS entity may receive a notification that a different DeNAS entity may use the associated RAT at a specific time, the DeNAS may release the AN signaling connection, thereby causing the CM state of the DeNAS to transition to CM-IDLE.

[0256] When a DeNAS entity having an RM state machine in RM-REGISTERED on an associated RAT indicates to a CoNAS entity that it is RM-DEREGISTERED on the associated RAT, the CoNAS entity may transition to the SINGLE RM-REGISTERED state 1602 if there is now only one DeNAS entity having an RM state machine in RM-REGISTERED on the associated RAT. Fig.16 This transformation is shown in step 4 of .

[0257] Note that when the CoNAS entity informs the DeNAS entity that it can perform some operations (e.g., periodic registration updates), the CoNAS entity may also indicate to the DeNAS entity that the DeNAS entity is only allowed to perform specific operations and is not allowed to perform additional activities (e.g., establish a PDU session and send UL data or receive downlink data). The CoNAS entity may indicate this to the DeNAS layer because the DeNAS entity is waiting to perform some higher priority activities. Therefore, when the DeNAS performs a periodic registration update, the DeNAS may indicate to the network that it is performing a periodic registration update, but it cannot perform other operations (i.e., receive DL data) at this time. The UE may indicate this condition by providing a PSM activity timer value of 0 during the periodic registration. Therefore, the UE is instructed to immediately enter CM-IDLE again.

[0258] According to another embodiment, the present invention describes an AS process for implementing TDM sharing of RX / TX chains. In order to maintain simultaneous UL / DL communication with multiple PLMNs of multi-SIM devices with single RX and single TX chain or dual RX and single TX chain, the present invention proposes an AS process to implement sharing of RX / TX chains in a TDM manner. Signaling at the AS layer within the UE and / or between the UE and the network is used to coordinate communication with multiple PLMNs. For illustrative purposes, the present invention considers the following scenario, in which the UE is configured with two SIMs, namely SIM 1 and SIM 2, but the solution described in this article can be extended to configurations with more than 2 SIMs.

[0259] Various types of solutions can be envisioned, where the type of solution depends on the number of RX / TX chains, the length of gaps required in UL / DL communications with the first PLMN to accommodate UL / DL transmissions with the second PLMN, and / or the level of coordination between network nodes of the PLMNs.

[0260] For scenarios where short gaps (e.g., 10ms-100ms) or micro gaps (e.g., <10ms) in UL / DL transmissions with a first PLMN are needed to accommodate UL / DL transmissions with a second PLMN, a class of solutions that allow dynamic sharing of RX / TX chains can be used. Further optimizations in these solutions can be achieved when coordination between network nodes of multiple PLMNs is possible (e.g., shared deployment within an MNO or RAN).

[0261] For scenarios where long gaps (e.g., >100ms) in UL / DL transmissions with a first PLMN are needed to accommodate UL / DL transmissions with a second PLMN, a class of solutions that allow semi-static sharing of RX / TX chains may be used. This class of solutions may also be applied to other scenarios, such as when UL / DL transmissions with a second PLMN are delay tolerant or when coordination between network nodes of multiple PLMNs is not possible (e.g., inter-MNO deployment).

[0262] Fig.17 Dynamic sharing of RX / TX chains with RX / TX chain arbiters 1700 is shown. In one class of solutions, TDM access to a shared RX / TX chain is implemented using an RX / TX chain arbiter 1702. Before an RXOP or TXOP, a request for access to a shared RX / TX chain is made to the RX / TX chain arbiter 1702 by an AS (e.g., a dedicated AS 1701 or a dedicated AS 1702). The RX / TX chain arbiter 1702 may provide a response to the AS to indicate whether access to the shared RX / TX chain is authorized. In the following, the term RX / TX chain arbiter and the term arbiter function may be used interchangeably. In one embodiment, the arbiter function may be implemented by an RRC layer, a MAC layer, or a PHY layer. In another embodiment, the arbiter function may be implemented by a NAS layer.

[0263] Access to the RX / TX chain may be granted on a first-come, first-served basis by the RX / TX chain arbiter 1702. Alternatively, priority may be given based on USIM identity, priority of the service requesting access, the MAC process that is requesting access, etc.

[0264] The request provided by the AS to the RX / TX chain arbiter 1702 may indicate when the RX / TX chain is expected to be accessed and how long the RX / TX chain is expected to be accessed; for example, a start time and a duration, a start time and an end time, etc. The request may also include an indication of the priority of the access. The AS may determine when the RXOP occurs based on the configured CORESET, search space, SPS configuration, DRX configuration, etc. The AS may determine when the TXOP occurs based on a dynamic or configured grant, PUCCH timing, RACH timing, etc.

[0265] The response provided by the RX / TX chain arbiter 1702 to the AS indicates whether access is granted; for example, a Boolean flag where true indicates that access is granted and false indicates that access is not granted.

[0266] If access to the shared RX / TX chain is granted, monitor the DL during the RXOP or transmit the UL during the TXOP. If access to the shared RX / TX chain is not granted, the AS process may adapt to account for the missed RXOP / TXOP.

[0267] For scenarios where access to the RX / TX chain may be predetermined based on traffic patterns and / or AS configuration, an explicit request / response may be provided for each access attempt. Conversely, when such an event occurs, relevant information may be provided to the RX / TX chain arbiter and an indication of a missed RXOP / TXOP may be provided to the affected dedicated AS.

[0268] An indication of a missed RXOP / TXOP may also be provided to the network. An indication of the occurrence of a missed RXOP / TXOP may be provided to the network during a TXOP to enable the network to take proactive action to address the missed RXOP / TXOP. Alternatively, the UE may provide the indication during a subsequent TXOP to enable the network to take reactive action to the missed RXOP / TXOP. Furthermore, in another alternative, to reduce the signaling overhead associated with providing an explicit indication of a missed RXOP / TXOP, the UE may provide the network with a schedule for access to the RX / TX chain so the network can predict when a missed RXOP / TXOP may occur.

[0269] The RX / TX chain arbiter may support preemption. For example, for a scenario where access is priority-based, the RX / TX chain arbiter may allow a pending or ongoing access to be interrupted by a higher priority access. When such an interruption occurs, the RX / TX chain arbiter 1702 may provide an indication to the dedicated AS of the interruption so that the interruption may be handled accordingly.

[0270] The interface between the AS and the RX / TX chain arbiter 1702 may be provided at one or more AS layers.

[0271] Fig.18 The interface between the AS and the RX / TX chain arbiter 1800 is shown. Each SIM is associated with a dedicated AS (e.g., dedicated AS 1801 and dedicated AS 1802) and the MAC layer of each dedicated AS; that is, the DeMAC interfaces with the RX / TX chain arbiter 1802 (this can be implemented in CoMAC) to request access to the shared RX / TX chain. When an indication of a missed RXOP / TXOP is received from the RX / TX chain arbiter, signaling within the MAC can be used to adapt the behavior of the MAC process.

[0272] Fig.19 An exemplary interface between the AS and the RX / TX chain arbiter according to another embodiment is shown. Fig.19In the example of , the PHY layer of each dedicated AS (e.g., dedicated AS 1901 and dedicated AS 1903) interfaces with the RX / TX chain arbiter 1902 to request access to the shared RX / TX chain. If access to the shared RX / TX chain is not authorized, the PHY may provide a missing RXOP / TXOP indication 1910 to the MAC, and the MAC process is adapted to account for the missing RXOP / TXOP. Alternatively, an indication of authorized access to the RX / TX chain may be provided instead. And in yet another alternative, two types of indications may be provided.

[0273] Fig. 20 Another exemplary interface between the AS and the RX / TX chain arbiter according to another embodiment 2000 is shown. Fig. 20 In the example of , the PHY layer or MAC layer of each dedicated AS (e.g., dedicated AS 2001 and dedicated AS 2002) interfaces with RX / TX chain arbiters 2003 and 2004 to request access to the shared RX / TX chain. In this example, the PHY layer of each dedicated AS interfaces with RX / TX chain arbiters 2003 and 2004 to request access to the shared RX chain and MAC; for example, the HARQ entity interfaces with the RX / TX chain arbiter to request access to the TX chain.

[0274] Fig.21 An exemplary signaling diagram 2100 for dynamic sharing of RX / TX chains using an RX / TX chain arbiter is shown. In the text used to describe the steps of the signaling diagram, the symbol ASX is used to refer to the AS associated with SIM X, and the term gNBY is used to refer to the gNB associated with PLMN Y.

[0275] refer to Fig.21 , A.S. 1 Access to the RX chain may be requested (step 1). The RX / TX chain arbiter may determine that the RX is available during the requested RXOP and may provide a response indicating that access is granted (step 2). 1 During the requested RXOP, the gNB can A Receive DL transmission (step 3). AS 1 Access to the TX chain may be requested (step 4). The RX / TX chain arbiter may determine that the TX is available during the requested TXOP and may provide a response indicating that access is granted (step 5). 1 May transmit UL to gNB during requested TXOP A (Step 6). 2 Access to the TX chain may be requested (step 7). The RX / TX chain arbiter may determine that the TX may be available during the requested TXOP and may provide a response indicating that access is granted (step 8). 2May transmit UL to gNB during requested TXOP B (Step 9).

[0276] Fig. 22 An exemplary signaling diagram 2200 for dynamic sharing of RX / TX chains using an RX / TX chain arbiter is shown, wherein the PHY layer of each dedicated AS interfaces with the RX / TX chain arbiter. Fig. 22 , A.S. 1 The PHY of the AS may request access to the RX chain (step 1). The RX / TX chain arbiter may determine that the RX may be available during the requested RXOP and may provide a response indicating that access is granted (step 2). 1 The PHY can receive data from the gNB during the requested RXOP. A Receive DL transmission (step 3). AS 1 The PHY can send the received MAC PDU to the AS 1 MAC of AS (step 4). 1 The MAC can send the MAC PDU to the AS 1 PHY (step 5). AS 1 The MAC can send the UL authorization to the AS 1 PHY (step 6). AS 1 The PHY of the AS may request access to the TX chain (step 7). The RX / TX chain arbiter may determine that the TX may be available during the requested TXOP and may provide a response indicating that access is granted (step 8). 1 The PHY can transmit UL to the gNB during the requested TXOP A (Step 9). 2 The MAC can send the MAC PDU to the AS 2 PHY (step 10). AS 2 The MAC can send the UL authorization to the AS 2 PHY (step 11). AS 2 The PHY of the AS may request access to the TX chain (step 12). The RX / TX chain arbiter may determine that the TX may be available during the requested TXOP and may provide a response indicating that access is granted (step 13). 2 The PHY can transmit UL to the gNB during the requested TXOP B (Step 14).

[0277] Fig.23 A signaling diagram 2300 is shown for dynamic sharing of RX / TX chains using an RX / TX chain arbiter in the event of a missed RXOP and TXOP. Fig.23 , A.S.2 Access to the RX chain may be requested (step 1). The RX / TX chain arbiter may determine that the RX may be available during the requested RXOP and may provide a response indicating that access is granted (step 2). 1 Access to the RX chain may be requested (step 3). The RX / TX chain arbiter may determine that the RX may not be available during the requested RXOP and may provide a response indicating that access is not granted (step 4). 1 Adapt the AS process to account for the missed RXOP (step 5). 2 During the requested RXOP, the gNB can B Receive DL transmission (step 6). AS 1 Access to the RX chain may be requested (step 7). The RX / TX chain arbiter may determine that the RX may be available during the requested RXOP and may provide a response indicating that access is granted (step 8). 1 During the requested RXOP, the gNB can A Receive DL transmission (step 9). AS 1 Access to the TX chain may be requested (step 10). The RX / TX chain arbiter may determine that the TX may be available during the requested TXOP and may provide a response indicating that access is granted (step 11). 2 Access to the TX chain may be requested (step 12). The RX / TX chain arbiter may determine that the TX may not be available during the requested TXOP and may provide a response indicating that access is not granted (step 13). 2 The AS process is adapted to account for the missing TXOP (step 14). 1 May transmit UL to gNB during requested TXOP A (Step 15). 2 Access to the TX chain may be requested (step 16). The RX / TX chain arbiter may determine that the TX may be available during the requested TXOP and may provide a response indicating that access is granted (step 17). 2 May transmit UL to gNB during requested TXOP B (Step 18).

[0278] Fig.24 A signaling diagram 2400 is shown for dynamic sharing of RX / TX chains using an RX / TX chain arbiter in the event of a missed RXOP and TXOP, wherein the PHY layer of each dedicated AS interfaces with the RX / TX chain arbiter. Fig.24 , A.S. 2The PHY of the AS may request access to the RX chain (step 1). The RX / TX chain arbiter may determine that the RX may be available during the requested RXOP and may provide a response indicating that access is granted (step 2). 1 The PHY of the AS may request access to the RX chain (step 3). The RX / TX chain arbiter may determine that the RX may not be available during the requested RXOP and may provide a response indicating that access is not granted (step 4). 1 The PHY can provide AS 1 The MAC provides a Missed RXOP indication (step 5). 1 The MAC of AS adapts the MAC process to account for the missing RXOP (step 6). 2 The PHY can receive data from the gNB during the requested RXOP. B Receive DL transmission (step 7). AS 2 The PHY can send the received MAC PDU to the AS 2 MAC of AS (step 8). 1 The PHY of the AS may request access to the RX chain (step 9). The RX / TX chain arbiter may determine that the RX may be available during the requested RXOP and may provide a response indicating that access is granted (step 10). 1 The PHY can receive data from the gNB during the requested RXOP. A Receive DL transmission (step 11). AS 1 The PHY can send the received MAC PDU to the AS 1 MAC of AS (step 12). 1 The MAC can send the MAC PDU to the AS 1 PHY (step 13). AS 1 The MAC can send the UL authorization to the AS 1 PHY (step 14). AS 1 The PHY of the AS may request access to the TX chain (step 15). The RX / TX chain arbiter may determine that the TX may be available during the requested TXOP and may provide a response indicating that access is granted (step 16). 2 The MAC can send the MAC PDU to the AS 2 PHY (step 17). AS 2 The MAC can send the UL authorization to the AS 2 PHY (step 18). AS 2 The PHY of the AS may request access to the TX chain (step 19). The RX / TX chain arbiter may determine that the TX may not be available during the requested TXOP and may provide a response indicating that access is not granted (step 20). 2 The PHY can provide AS2 The MAC of the AS provides a missing TXOP indication (step 21). 2 The MAC of AS adapts the MAC process to take into account the missing TXOP (step 22). 1 The PHY can transmit UL to the gNB during the requested TXOP A (Step 23). 2 The MAC can send the MAC PDU to the AS 2 PHY (step 24). AS 2 The MAC can send the UL authorization to the AS 2 PHY (step 25). AS 2 The PHY of the AS may request access to the TX chain (step 26). The RX / TX chain arbiter may determine that the TX may be available during the requested TXOP and may provide a response indicating that access is granted (step 27). 2 The PHY can transmit UL to the gNB during the requested TXOP B (Step 28).

[0279] In another type of solution, semi-static sharing of RX / TX chains is described herein. Semi-static sharing of RX / TX chains can be achieved by suspending or releasing the RRC connection.

[0280] In one embodiment of the solution, each SIM is associated with a DeRRC, and the CoRRC can determine which DeRRC should be active at a given time. The determination of which DeRRC should be active can be based on the establishment cause of the RRC setup request from higher upper layers, the QoS or priority of the logical channel or radio bearer configured for the AS connection, and the procedures currently being performed by the AS connection; for example, random access, beam failure detection and recovery.

[0281] Fig.25 A process 2500 is shown in which semi-static sharing of RX / TX chains is achieved using RRC suspension. Fig.25 , the upper layer (e.g., NAS) may request to establish an RRC connection for SIM 1 (step 1). The DeRRC for SIM 1 may request to establish a new RRC connection (step 2). The CoRRC may determine that an RRC connection can be established (step 3). The CoRRC may provide a response indicating that the request is authorized (step 4). The DeRRC for SIM 1 may establish a connection with the gNB A DeRRC can perform RRC connection with gNB (step 5). AUL / DL communications for SIM 2 (step 6). An upper layer (e.g., NAS) may request to establish an RRC connection for SIM 2 (step 7). The DeRRC for SIM 2 may request to establish a new RRC connection (step 8). The CoRRC may determine that the RRC connection for SIM 1 must be suspended before the RRC connection for SIM 2 can be established (step 9). The CoRRC may provide a response to the DeRRC for SIM 1 indicating that the RRC connection should be suspended (step 10). The dedicated sublayer for SIM 1 may suspend the RRC connection (step 11). The CoRRC may provide a response to the DeRRC for SIM 2 indicating that the request to establish a new RRC connection is authorized (step 12). The DeRRC for SIM 2 establishes a connection with the gNB. B DeRRC can perform RRC connection with gNB (step 13). B UL / DL communication (step 14).

[0282] Fig.26 An exemplary process 2600 is shown in which another aspect of the solution RRC release can be used to implement semi-static sharing of RX / TX chains. Fig.26 , an upper layer (e.g., NAS) may request to establish an RRC connection for SIM 1 (step 1). The DeRRC for SIM 1 may request to establish a new RRC connection (step 2). The CoRRC may determine that an RRC connection can be established (step 3). The CoRRC may provide a response indicating that the request is authorized (step 4). The DeRRC for SIM 1 establishes a connection with the gNB A DeRRC can perform RRC connection with gNB (step 5). A UL / DL communications for SIM 2 (step 6). An upper layer (e.g., NAS) may request to establish an RRC connection for SIM 2 (step 7). The DeRRC for SIM 2 may request to establish a new RRC connection (step 8). CoRRC may determine that the RRC connection for SIM 1 must be released before the RRC connection for SIM 2 can be established (step 9). CoRRC may provide a response to the DeRRC for SIM 1 indicating that the RRC connection for SIM 1 should be released (step 10). The dedicated sublayer for SIM 1 may release the RRC connection (step 11). The dedicated sublayer for SIM 1 may inform the upper layer that the RRC connection is released (step 12). CoRRC may provide a response to the DeRRC for SIM 2 indicating that the request to establish a new RRC connection is authorized (step 13). The DeRRC for SIM 2 may establish a connection with the gNB. B DeRRC can perform RRC connection with gNB (step 14). B UL / DL communication (step 15).

[0283] This document describes the impact of sharing RX / TX chains on the MAC. The solutions described in this document apply to overall MAC operations, and specifically to MAC processes that rely on timers and counters to control their behavior. Such MAC processes include, but are not limited to, the following: random access, maintenance of uplink time alignment, UL / DL HARQ operations, scheduling requests, buffer status reporting, power headroom reporting, discontinuous reception, activation / deactivation of SCells, bandwidth fractional operations, and beam failure detection and recovery. Missing RXOP / TXOP may cause unnecessary and unintended impacts on these MAC processes. With the knowledge of missing RXOP / TXOP, these MAC processes can operate similarly to the operation when sharing of the RX / TX chain is not required.

[0284] Regarding the impact on the MAC process, the UL and DL consider the impact of shared RX / TX chains. Depending on the MAC process, both missed RXOPs and missed TXOPs may be considered; or only missed RXOPs or missed TXOPs may be considered. How to request access to shared RX and TX chains may be different.

[0285] The UE may perform sharing of the TX chain, according to which no transmission is performed if access to the shared TX chain is not granted. When access to the shared TX chain is requested before a transmission, an indication is provided to the MAC entity as to whether access is granted. Unless otherwise specified, the MAC entity considers the transmission to have been performed regardless of the access request outcome. For transmissions in which an access request is not performed, the access request is considered to be granted.

[0286] This document describes informing the NW of missing RXOP / TXOP. For scenarios where a priori determination of missing RXOP / TXOP is possible, the UE may transmit an indication to inform the network of the possible missed RXOP / TXOP, thereby allowing adaptation of the MAC behavior to be coordinated between the network and the UE. How the MAC behavior is adapted may be predetermined / preconfigured, and an indication from the UE may be used to trigger when the adaptation may occur. Alternatively, the indication may consist of information informing the network how the UE may adapt the MAC behavior. Moreover, in yet another alternative, how the MAC process is adapted may be negotiated between the network and the UE.

[0287] For scenarios where a priori determination of a missed RXOP is not possible but a TX chain is available when a missed RXOP occurs, if UL resources scheduled via dynamic grant are not available, pre-configured (e.g., via configured grant or PUCCH) UL resources may be used to transmit an indication of a missed RXOP.

[0288] This document describes the impact on MAC counters and timers. Sharing RX / TX chains may result in lost RXOPs and TXOPs, which results in a longer period of time to achieve a successful transmission. The MAC process considers the number of opportunities and / or time periods to complete the process before declaring the process failed. In order to correctly perform the process when sharing RX / TX chains, the missed RXOPs and TXOPs need to be considered.

[0289] For example, processes such as random access, scheduling requests, and beam failure detection and recovery use counters to control how many unsuccessful attempts should occur before declaring the process failed. Incrementation of such counters should take into account missed RXOPs and TXOPs to avoid declaring failure prematurely.

[0290] The existing MAC process assumes that UL transmission occurs when the PHY is instructed to perform UL transmission of a MAC PDU or UCI (e.g., SR). In order to limit the frequency of transmission of MAC CE and UCI in the case of a specific MAC process, a prohibit timer is set to prevent retransmission of MAC CE or UCI until the prohibit timer expires. In order to properly control the frequency of transmitting MAC CE or UCI and ensure that transmission occurs when needed, the setting of these prohibit timers needs to take into account missed TXOPs; for example, if no transmission occurs due to a missed TXOP, the timer should not be set.

[0291] Timers may be used to control when the UE monitors the DL for procedures such as random access and DRX. For scenarios where access to the RX chain is not authorized, monitoring the DL may cause unnecessary power consumption and should not be performed. Therefore, when determining whether the DL should be monitored while such timers are running, missed RXOPs should be taken into account. In addition, in some scenarios, it may be appropriate to extend the timer to account for missed RXOPs. To ensure that the timers maintained by the UE and the gNB are synchronized, the UE may provide an indication to the gNB that the timer is being extended. Alternatively, the UE may provide an indication requesting an extension of the timer, and the network may then provide an indication in the DL to confirm whether the request is authorized.

[0292] This document describes the impact due to missing TXOPs. The MAC process should take into account when UL transmissions cannot be performed due to missing TXOPs. For example, if access to the shared TX chain is not granted for the duration corresponding to the uplink grant indicated to the HARQ entity, no MAC PDU should be generated.

[0293] This paper describes the impact on specific MAC procedures such as random access procedure and random access resource selection. This paper proposes the following procedure to take into account the impact of shared RX / TX chains:

[0294] After selecting a PRACH opportunity, the MAC entity may request access to the TX chain for a duration corresponding to the selected PRACH opportunity. If access is not granted, the MAC entity may select the next available PRACH opportunity and may request access to the TX chain for a duration corresponding to the next available PRACH opportunity. The process may be repeated until access to the TX chain is granted for a duration corresponding to one of the selected PRACH opportunities, or access to the TX chain fails in all PRACH opportunities. If access to the TX chain fails in all PRACH opportunities, the random access resource selection process is repeated. The MAC entity may delay performing the random access resource selection process until after a backoff time, wherein the backoff time may be equal to or greater than the duration for which the TX chain is considered busy; that is, the random access resource selection process is not performed until the TX chain is idle. Alternatively, a fixed or randomly selected backoff time may be used. A process may be defined to count the number of failed RX chain access requests or the number of consecutive failed RX chain access requests. The count may be determined within a configured duration, wherein the duration may include infinity as a configuration option. If the count of (consecutive) failed RX link access requests exceeds a configured threshold, the random access procedure is considered to have been completed unsuccessfully and the MAC entity may indicate a random access problem to upper layers.

[0295] To implement this behavior, the process can be performed as follows:

[0296] 1) If ra-AssociationPeriodIndex and si-RequestPeriod are configured, then:

[0297] 2) Within the limits given by ra-ssb-OccasionMaskIndex (if configured), si-

[0298] The next available PRACH opportunity is determined from the PRACH opportunity corresponding to the selected SSB and for which access to the TX chain is authorized in the association period given by ra-AssociationPeriodIndex in RequestPeriod (the MAC entity can randomly select a PRACH opportunity among consecutive PRACH opportunities corresponding to the selected SSB with equal probability).

[0299] 1) Otherwise if SSB is selected as above, then:

[0300] 2) Determine the next available PRACH opportunity from the PRACH opportunity corresponding to the selected SSB given by ra-ssb-OccasionMaskIndex (if configured) or permitted by the restriction indicated by PDCCH and for which access to the TX chain is authorized (the MAC entity may randomly select a PRACH opportunity among the consecutive PRACH opportunities corresponding to the selected SSB with equal probability; when determining the next available PRACH opportunity corresponding to the selected SSB, the MAC entity may take into account possible measurement gaps that may occur).

[0301] 1) Otherwise, if CSI-RS is selected as above, then:

[0302] 2) If there is no contention-free random access resource associated with the selected CSI-RS, then:

[0303] 3) Determine the next available PRACH opportunity from the PRACH opportunities restricted by ra-ssb-OccasionMaskIndex (if configured), corresponding to the SSB in candidateBeamRSList that is quasi-co-located with the selected CSI-RS and for which access to the TX chain is authorized (the MAC entity may randomly select a PRACH opportunity among consecutive PRACH opportunities corresponding to the SSB that is quasi-co-located with the selected CSI-RS with equal probability; when determining the next available PRACH opportunity corresponding to the SSB that is quasi-co-located with the selected CSI-RS, the MAC entity may take into account possible measurement gaps that may occur).

[0304] 2) Otherwise:

[0305] 3) Determine the next available PRACH opportunity from the PRACH opportunities in the ra-OccasionList that correspond to the selected CSI-RS and for which access to the TX chain is authorized (the MAC entity may randomly select a PRACH opportunity from the PRACH opportunities corresponding to the selected CSI-RS that occur simultaneously but on different subcarriers with equal probability; when determining the next available PRACH opportunity corresponding to the selected CSI-RS, the MAC entity may take into account possible measurement gaps).

[0306] 1) If the PRACH timing is determined, then:

[0307] 2) Execute the random access preamble code transmission process.

[0308] 1) Otherwise:

[0309] 2)If NUM_FAILED_RX_CHAIN_ACCESS_REQUESTS>MAX_FAILED

[0310] _TX_CHAIN_ACCESS_REQUESTS, then:

[0311] 3) If the random access resource is selected for SpCell, then:

[0312] 4) Indicate random access issues to upper layers;

[0313] 4) If the random access procedure is triggered for an SI request, then:

[0314] 5) The random access procedure is considered to have not been completed successfully.

[0315] 3) Otherwise, if a random access preamble is transmitted on the SCell, then:

[0316] 4) The random access process is considered to have not been successfully completed.

[0317] 2) If the random access process is not completed, then:

[0318] 3) Choose a backoff time equal to or greater than the duration of unauthorized access to the TX chain.

[0319] 3) Perform the random access resource selection process after the backoff time.

[0320] In order to avoid repeated failures of the random access resource selection procedure due to failures in access to the TX chain within the selected PRACH opportunity, the SSB or CSI-RS selected during the failed attempt of the random access resource selection procedure may be excluded as an option for selection on subsequent attempts of the procedure. Alternatively, subsequent attempts of the random access resource selection procedure may be delayed until the TX chain is no longer used by another DeRRC.

[0321] Random access preamble transmission

[0322] This article proposes the following process to account for the impact of shared RX / TX chains:

[0323] Access to the TX chain may be requested during the Random Access Preamble Transmission procedure as an alternative to requesting during the Random Access Resource Selection procedure.If access is not granted, the MAC entity returns to the Random Access Resource Selection procedure and neither the PREAMBLE_POWER_RAMPING_COUNTER nor the PREAMBLE_TRANSMISSION_COUNTER is incremented.

[0324] For each random access preamble, the MAC entity may:

[0325] 1) If access to the TX chain is granted for the duration corresponding to the selected PRACH opportunity, then:

[0326] 2) If PREAMBLE_TRANSMISSION_COUNTER is greater than one; and

[0327] 2) if a notification of suspending the power ramp counter has not been received from the lower layers; and

[0328] 2) If the selected SSB or CSI-RS has not changed since the selection in the last random access preamble transmission, then:

[0329] 3) Increment PREAMBLE_POWER_RAMPING_COUNTER by 1.

[0330] 2) Select the value of DELTA_PREAMBLE;

[0331] 2) Set PREAMBLE_RECEIVED_TARGET_POWER to preambleReceivedTargetPower + DELTA_PREAMBLE +

[0332] (PREAMBLE_POWER_RAMPING_COUNTER–1)×

[0333] PREAMBLE_POWER_RAMPING_STEP;

[0334] 2) Calculate the RA-RNTI associated with the PRACH opportunity in which the random access preamble is transmitted, except for the contention-free random access preamble used for beam failure recovery request;

[0335] 2) Instruct the physical layer to transmit a random access preamble using the selected PRACH opportunity, the corresponding RA-RNTI (if available), PREAMBLE_INDEX and PREAMBLE_RECEIVED_TARGET_POWER.

[0336] 1) Otherwise:

[0337] 2) Perform random access resource selection process.

[0338] Random access response reception

[0339] This article proposes the following process to account for the impact of shared RX / TX chains:

[0340] The start of the RAR window is conditional upon obtaining access to the RX chain within the duration of the ra-ResponseWindow. If access is not granted, the random access response reception is deemed unsuccessful and the MAC entity performs a random access resource selection procedure. The MAC entity may delay performing the random access resource selection procedure until after a backoff time, where the backoff time may be equal to or greater than the duration for which the RX chain is considered busy; i.e., the random access resource selection procedure is not performed until the RX chain is idle. Alternatively, a fixed or randomly selected backoff time may be used.

[0341] To implement this behavior, the procedure can be defined as follows:

[0342] 1) If a contention-free random access preamble for a beam failure recovery request is transmitted by the MAC entity, then:

[0343] 2) If the grant is configured in BeamFailureRecoveryConfig starting at the first PDCCH opportunity corresponding to the end of the random access preamble transmission,

[0344] Access to the RX chain for the duration of the ResponseWindow, then:

[0345] 3) the ra-ResponseWindow configured in BeamFailureRecoveryConfig starting from the first PDCCH opportunity after the end of the random access preamble transmission;

[0346] 3) While ra-ResponseWindow is running, monitor PDCCH transmission on the search space indicated by recoverySearchSpaceId of the SpCell identified by C-RNTI.

[0347] 1) Otherwise:

[0348] 2) If access to the RX chain is granted for the duration corresponding to the ra-ResponseWindow configured in RACH-ConfigCommon starting at the first PDCCH opportunity from the end of the random access preamble transmission, then:

[0349] 3) Starting from the first PDCCH opportunity after the end of the random access preamble transmission, the RACH-

[0350] ra-ResponseWindow configured in ConfigCommon;

[0351] 3) While the ra-ResponseWindow is running, monitor the PDCCH of the SpCell of the random access response identified by the RA-RNTI.

[0352] 1) If the ra-ResponseWindow configured in BeamFailureRecoveryConfig expires and if a PDCCH transmission on the search space indicated by recoverySearchSpaceId addressed to the C-RNTI has not been received on the serving cell that transmitted the preamble; or

[0353] 1) If the ra-ResponseWindow configured in RACH-ConfigCommon expires and if a Random Access Response containing a Random Access Preamble identifier matching the transmitted PREAMBLE_INDEX has not been received; or

[0354] 1) If access to the RX chain is not authorized, then:

[0355] 2) The random access response reception is considered unsuccessful;

[0356] 2) Increment PREAMBLE_TRANSMISSION_COUNTER by 1;

[0357] 2) If PREAMBLE_TRANSMISSION_COUNTER =

[0358] preambleTransMax+1, then:

[0359] 3) If a random access preamble is transmitted on the SpCell, then:

[0360] 4) Indicate random access issues to upper layers;

[0361] 4) If the random access procedure is triggered for an SI request, then:

[0362] 5) The random access procedure is considered to have not been completed successfully.

[0363] 3) Otherwise, if a random access preamble is transmitted on the SCell, then:

[0364] 4) The random access process is considered to have not been successfully completed.

[0365] 2) If the random access process is not completed, then:

[0366] 3) If access to the RX chain is authorized, then:

[0367] 4) A random backoff time is selected according to a uniform distribution between 0 and PREAMBLE_BACKOFF;

[0368] 3) Otherwise:

[0369] 4) Select a backoff time corresponding to the duration of unauthorized access to the RX chain.

[0370] 3) If the criteria for selecting a contention-free random access resource are met during the backoff time; and

[0371] 3) If the RX chain is considered idle, then:

[0372] 4) Execute random access resource selection process;

[0373] 3) Otherwise:

[0374] 4) Perform the random access resource selection process after the backoff time.

[0375] To facilitate the use of HARQ for Msg3 when sharing a TX chain, if the random access response reception is considered successful and the RAR includes a UL grant, the MAC entity shall obtain the MAC PDU for transmission from the multiplexing and combining entity and store it in the Msg3 buffer, regardless of whether access to the TX chain is granted for the duration corresponding to the RAR UL grant.

[0376] This article describes contention resolution. This article proposes the following process to take into account the impact of shared RX / TX chains:

[0377] The start of the contention resolution window is conditional upon obtaining access to the RX chain within the duration of ra-ContentionResolutionTimer. If access is not granted, contention resolution is considered unsuccessful and the MAC entity performs a random access resource selection procedure. The MAC entity may delay performing the random access resource selection procedure until after a backoff time, where the backoff time may be equal to or greater than the duration for which the RX chain is considered busy; i.e., the random access resource selection procedure is not performed until the RX chain is idle. Alternatively, a fixed or randomly selected backoff time may be used.

[0378] Note that HARQ is used for Msg3. Therefore, if the gNB does not receive Msg3 before the ra-ContentionResolutionTimer expires, the DCI can be used to schedule retransmissions. To facilitate the use of HARQ for Msg3 when sharing a TX chain, the starting of the ra-contentionResolutionTimer and the monitoring of the PDCCH while the ContentionResolutionTimer is running are not conditional on gaining access to the TX chain for the duration corresponding to the RAR UL grant or retransmission scheduled via DCI.

[0379] To implement this behavior, the procedure can be defined as follows:

[0380] 1) If access to the RX chain is granted for a duration corresponding to the ra-ContentionResolutionTimer in the first symbol after the end of the Msg3 transmission (retransmission), then:

[0381] 2) Start ra-ContentionResolutionTimer and restart ra-ContentionResolutionTimer at each HARQ retransmission in the first symbol after the end of Msg3 transmission;

[0382] 2) Monitor the PDCCH while the ra-ContentionResolutionTimer is running, regardless of whether a measurement gap may occur;

[0383] 1) If ra-ContentionResolutionTimer expires; or

[0384] 1) If access to the RX chain is not authorized, then:

[0385] 2) discard TEMPORARY_C-RNTI;

[0386] 2) The contention resolution is deemed unsuccessful.

[0387] 1) If contention resolution is deemed unsuccessful:

[0388] 2) Refresh the HARQ buffer for transmission of the MAC PDU in the Msg3 buffer;

[0389] 2) Increment PREAMBLE_TRANSMISSION_COUNTER by 1;

[0390] 2) If PREAMBLE_TRANSMISSION_COUNTER =

[0391] preambleTransMax+1, then:

[0392] 3) Indicate random access problems to upper layers.

[0393] 3) If the random access procedure is triggered for an SI request, then:

[0394] 4) The random access process is considered to have not been successfully completed.

[0395] 2) If the random access process is not completed, then:

[0396] 3) If access to the RX chain is authorized, then:

[0397] 4) A random backoff time is selected according to a uniform distribution between 0 and PREAMBLE_BACKOFF;

[0398] 3) Otherwise:

[0399] 4) Select a backoff time corresponding to the duration of unauthorized access to the RX chain.

[0400] 3) If the criteria for selecting a contention-free random access resource are met during the backoff time; and

[0401] 3) If the RX chain is considered idle, then:

[0402] 4) Execute random access resource selection process;

[0403] 3) Otherwise:

[0404] 4) Perform the random access resource selection process after the backoff time.

[0405] This article describes the maintenance of uplink time alignment. This article proposes the following procedure to account for the impact of shared RX / TX chains:

[0406] A missed RXOP may result in a missed timing advance command MAC CE, causing the MAC entity to unnecessarily perform actions associated with the expiration of timeAlignmentTimer. For scenarios where timeAlignmentTimer would expire during a missed RXOP, timeAlignmentTimer may be extended for the duration of the missed RXOP, providing the network with an additional opportunity to transmit a timing advance command MAC CE.

[0407] To implement this behavior, the procedure can be defined as follows:

[0408] 1) When timeAlignmentTimer expires:

[0409] 2) If expiration occurs during a missing RXOP, then:

[0410] 3) Extend timeAlignmentTimer by the duration corresponding to the missed RXOP.

[0411] 2) Otherwise:

[0412] 3) If timeAlignmentTimer is associated with PTAG, then:

[0413] 4) Refresh all HARQ buffers of all serving cells;

[0414] 4) Notify RRC to release PUCCH of all serving cells (if configured);

[0415] 4) Notify RRC to release the SRS of all serving cells (if configured);

[0416] 4) Clear any configured downlink assignments and configured uplink grants;

[0417] 4) Clear any PUSCH resources used for semi-persistent CSI reporting;

[0418] 4) All running timeAlignmentTimers are considered expired;

[0419] 4) Maintain NTA of all TAGs.

[0420] 3) Otherwise, if timeAlignmentTimer is associated with a STAG, then for all serving cells belonging to the TAG:

[0421] 4) Refresh all HARQ buffers;

[0422] 4) Notify RRC to release PUCCH (if configured);

[0423] 4) Notify RRC to release SRS (if configured);

[0424] 4) Clear any configured downlink assignments and configured uplink grants;

[0425] 4) Clear any PUSCH resources used for semi-persistent CSI reporting;

[0426] 4) Maintain the NTA of the TAG.

[0427] This article describes the HARQ operation and logical channel prioritization. This article proposes the following process to take into account the impact of shared RX / TX chains:

[0428] If access to the TX chain is not authorized within the duration corresponding to the uplink grant indicated to the HARQ entity, then the MAC PDU may not be generated.

[0429] To implement this behavior, the steps of the HARQ entity procedure may be conditional on access to the TX chain, and the procedure may be defined as follows:

[0430] For each uplink grant, the HARQ entity may:

[0431] 1) If access to the TX chain is authorized within the duration corresponding to the grant, then:

[0432] 2) <Steps of the HARQ entity procedure>

[0433] Alternatively, the steps of the HARQ entity procedure may remain unchanged, and the steps of the LCP procedure corresponding to when the MAC entity may not generate the MAC PDU of the HARQ entity may be defined as follows:

[0434] The MAC entity may not generate the MAC PDU of the HARQ entity if the following conditions are met:

[0435] Access to the TX chain is not authorized within the duration corresponding to the uplink grant indicated to the HARQ entity; or

[0436] The MAC entity is configured with skipUplinkTxDynamic with a value of true, and the grant indicated to the HARQ entity is addressed to a C-RNTI, or the grant indicated to the HARQ entity is a configured uplink grant; and

[0437] There is no aperiodic CSI for the PUSCH transmission request; and

[0438] The MAC PDU includes zero MAC SDUs; and

[0439] The MAC PDU includes only a periodic BSR and there is no data available for any LCG, or the MAC PDU includes only a padding BSR.

[0440] Scheduling requests are described herein. The following procedure is proposed to account for the impact of sharing the RX / TX chain:

[0441] A procedure may be defined to count the number of failed TX link access requests or the number of consecutive failed TX link access requests. The count may be determined within a configured duration, where the duration may include infinity as a configuration option. If the count of (consecutive) failed TX link access requests exceeds a configured threshold, then a random access procedure is initiated.

[0442] To implement this behavior, the procedure can be defined as follows:

[0443] 1) If the MAC entity does not have a valid PUCCH resource configured for the pending SR; or

[0444] 1) If NUM_FAILED_TX_CHAIN_ACCESS_REQUESTS > MAX_FAILED

[0445] _TX_CHAIN_ACCESS_REQUESTS, then:

[0446] 2) Initiate a random access procedure on the SpCell and cancel the pending SR.

[0447] To avoid unnecessarily delaying subsequent SR transmissions due to failures in accessing the TX chain and incorrectly reaching sr-TransMax, if access to the TX chain is authorized, only SR_COUNTER should be incremented and only sr-ProhibitTimer should be started.

[0448] To implement this behavior, the procedure can be defined as follows:

[0449] 2) If the PUCCH resource for the SR transmission opportunity does not overlap with the UL-SCH resource, then:

[0450] 3) If SR_COUNTER < sr-TransMax, then:

[0451] 4) Instruct the physical layer to signal the SR on a valid PUCCH resource for the SR;

[0452] 4) If access to the TX chain is authorized, then:

[0453] 5) Increment SR_COUNTER by 1;

[0454] 5) Start sr-ProhibitTimer.

[0455] This document describes buffer status reports. The following procedures are proposed to account for the impact of sharing the RX / TX chain:

[0456] When checking whether the UL resources can accommodate the BSR MAC CE, the MAC entity also checks whether access to the TX chain is granted for the duration corresponding to the UL resources. If access is not granted, no BSR MAC CE is generated; and the timers periodicBSR-Timer and retxBSR-Timer are not started (restarted). In addition, if access is not granted when the regular BSR has been triggered and the logicalChannelSR-DelayTimer is not running, a scheduling request is triggered.

[0457] To implement this behavior, the procedure can be defined as follows:

[0458] 1) If the buffer status reporting process can determine that at least one BSR has been triggered and not cancelled, then:

[0459] 2) If, due to logical channel priority, UL-SCH resources are available for new transmissions and UL-

[0460] The SCH resource can accommodate the BSR MAC CE plus its sub-header; and

[0461] 2) If access to the TX chain is granted for the duration corresponding to the UL resources, then:

[0462] 3) Instruct the multiplexing and combining process to generate the BSR MAC CE;

[0463] 3) Start or restart the periodicBSR-Timer, except when all generated BSRs are long or short truncated BSRs;

[0464] 3) Start or restart retxBSR-Timer.

[0465] 2) If the regular BSR has been triggered and logicalChannelSR-DelayTimer is not running, then:

[0466] 3) If there are no UL-SCH resources available for new transmission; or

[0467] 3) If the MAC entity is configured with a configured uplink grant and a regular BSR is triggered for a logical channel with logicalChannelSR-Mask set to false; or

[0468] 3) If the UL-SCH resources available for the new transmission do not satisfy the LCP mapping restrictions configured for the logical channel that triggered the BSR; or

[0469] 3) If access to the TX chain is not granted for the duration corresponding to the UL resources, then:

[0470] 4) Trigger a scheduling request.

[0471] This article describes the power headroom reporting. This article proposes the following process to take into account the impact of shared RX / TX chains:

[0472] When checking whether the UL resources can accommodate the MAC CE of the PHR, the MAC entity also checks whether access to the TX chain is authorized for the duration corresponding to the UL resources. If access is not authorized, no PHR MAC CE is generated; the triggered PHR is not canceled; and the timers phr-PeriodicTimer and phr-ProhibitTimer are not started (restarted).

[0473] To implement this behavior, the procedure can be defined as follows:

[0474] If the MAC entity has UL resources allocated for a new transmission, the MAC entity may:

[0475] 1) If this is the first UL resource allocated for a new transmission since the last MAC reset, then:

[0476] 2) Start phr-PeriodicTimer;

[0477] 1) If the power headroom reporting procedure can determine that at least one PHR has been triggered and not cancelled; and

[0478] 1) if due to LCP, the allocated UL resources can fit into the MAC CE of the PHR (the MAC entity is configured to transmit this MAC CE) plus its sub-header; and

[0479] 1) If access to the TX chain is granted for the duration corresponding to the UL resources, then:

[0480] 2) If Multi-PHR is configured with a value of true, then:

[0481] 3) For each activated serving cell with configured uplink associated with any MAC entity:

[0482] 4) obtaining a value of a Type 1 or Type 3 power headroom corresponding to an uplink carrier;

[0483] 4) if the MAC entity has UL resources allocated for transmission on the serving cell; or

[0484] 4) If other MAC entities (if configured) have UL resources allocated for transmission on this serving cell, and phr-ModeOtherCG is set to true by upper layers, then:

[0485] 5) Obtain the corresponding PCMAX,f,c field value from the physical layer.

[0486] 3) If phr-Type2OtherCell is configured with a value of true, then:

[0487] 4) If the other MAC entity is an E-UTRA MAC entity, then:

[0488] 5) obtaining a value of a Type 2 power headroom of the SpCell of another MAC entity (ie, an E-UTRA MAC entity);

[0489] 5) If phr-ModeOtherCG is set to true by the upper layer, then:

[0490] 6) Obtain the value of the corresponding PCMAX,f,c field of the SpCell of other MAC entities (ie, E-UTRA MAC entity) from the physical layer.

[0491] 3) Instructs the multiplexing and combining process to generate and transmit a multi-entry PHR MAC CE based on the values ​​reported by the physical layer.

[0492] 2) Otherwise (i.e., using the single-entry PHR format):

[0493] 3) Obtain the value of the Type 1 power headroom of the uplink carrier corresponding to the PCell from the physical layer;

[0494] 3) Obtain the corresponding PCMAX,f,c field value from the physical layer;

[0495] 3) Instructs the multiplexing and combining process to generate and transmit a single entry PHR MAC CE based on the value reported by the physical layer.

[0496] 2) Start or restart phr-PeriodicTimer;

[0497] 2) Start or restart phr-ProhibitTimer;

[0498] 2) Cancel all triggered PHRs.

[0499] This article describes Discontinuous Reception (DRX). This article proposes the following procedure to take into account the impact of shared RX / TX chains:

[0500] The MAC entity may request access to the RX chain at the beginning of the DRX cycle for the duration of drx-onDurationTimer. If access is granted, normal DRX operation follows; for example, start drx-onDurationTimer, monitor PDCCH, etc. If access is not granted, drx-onDurationTimer is not started, and the MAC entity enters DRX. Alternatively, the MAC entity may extend drx-onDurationTimer for the duration corresponding to the missed RXOP.

[0501] drx-InactivityTimer is the duration that the MAC entity waits for a successful decoding of the PDCCH from the last successful decoding of the PDCCH. If the PDCCH is not successfully decoded before the drx-InactivityTimer expires, the MAC entity enters DRX. The MAC entity starts or restarts the drx-InactivityTimer after successfully decoding the PDCCH. When the drx-InactivityTimer is started (restarted), the MAC entity may request access to the RX chain for the duration of the drx-InactivityTimer. If access is granted, normal DRX operation is followed. If access is not granted, the drx-InactivityTimer is stopped and the MAC entity enters DRX. Alternatively, the MAC entity may extend or suspend the drx-InactivityTimer for a duration corresponding to the missed RXOP.

[0502] If the PDCCH indicates a DL transmission or a MAC PDU is received in the configured downlink assignment, the drx-HARQ-RTT-TimerDL is started. When the timer is started, the MAC entity may request access to the RX chain for the duration of the drx-HARQ-RTT-TimerDL. Regardless of whether access is granted, when the drx-HARQ-RTT-TimerDL expires, if the data of the corresponding HARQ process is not successfully decoded, the drx-RetransmissionTimerDL is started. When the timer is started, the MAC entity may request access to the RX chain for the duration of the drx-RetransmissionTimerDL. If access is granted, normal DRX operation is followed. If access is not granted, the drx-RetransmissionTimerDL is stopped and the MAC entity enters DRX. Alternatively, the MAC entity may extend or suspend the drx-RetransmissionTimerDL for the duration corresponding to the missed RXOP.

[0503] To facilitate the use of HARQ when sharing a TX chain, for scenarios where a MAC PDU is not transmitted in a configured / dynamic uplink grant due to a missed TXOP, the drx-HARQ-RTT-TimerUL of the corresponding HARQ process is still started. Moreover, when the drx-HARQ-RTT-TimerUL expires, the drx-RetransmissionTimerUL is started.

[0504] When the DRX timer is suspended / extended due to a missed RXOP, if the TX chain is available, an indication may be transmitted to the gNB to inform it of the action.

[0505] This article describes the activation / deactivation of SCells. This article proposes the following process to take into account the impact of shared RX / TX chains:

[0506] If running, the sCellDeactivationTimer of a given SCell may be suspended during the missed RXOP of the serving cell that schedules the SCell.

[0507] If no MAC PDU is transmitted in a configured / dynamic uplink grant due to a missed TXOP, the sCellDeactivationTimer associated with the SCell shall be restarted.

[0508] This article describes the bandwidth partial operation. This article proposes the following process to take into account the impact of shared RX / TX chains:

[0509] A missed RXOP may result in a missed DL assignment and UL grant, resulting in the bwp-InactivityTimer not being reset, which may cause an erroneous BWP exchange. For scenarios where the bwp-InactivityTimer will expire during a missed RXOP, the bwp-InactivityTimer may be extended for the duration of the missed RXOP, thereby providing the network with an additional opportunity to trigger a restart of the bwp-InactivityTimer.

[0510] To implement this behavior, the procedure can be defined as follows:

[0511] 2) If the bwp-InactivityTimer associated with the active DL BWP expires, then:

[0512] 3) If expiration occurs during a missing RXOP, then:

[0513] 4) Extend bwp-InactivityTime by the duration corresponding to the missed RXOP.

[0514] 3) Otherwise:

[0515] 4) If defaultDownlinkBWP-Id is configured, then:

[0516] 5) Perform a BWP switch to the BWP indicated by defaultDownlinkBWP-Id.

[0517] 4) Otherwise:

[0518] 5) Perform BWP switch to initialDownlinkBWP.

[0519] This article describes beam failure detection and recovery. This article proposes the following process to account for the impact of shared RX / TX chains:

[0520] If running, the beamFailureDetectionTimer may be extended or paused for a duration corresponding to the missed RXOP.

[0521] To achieve this behavior, a process can be defined that includes the following:

[0522] 1) If an indication of a missed RXOP has been received and beamFailureDetectionTimer is running, then:

[0523] 2) Make beamFailureDetectionTimer extend the duration of missed RXOP.

[0524] If it can be assumed that the lower layers may not generate beam failure instance indications during a missed RXOP, then further modification of the process may not be required. However, if such an assumption cannot be made, then the process may be further modified so that beam failure instance indications received from the lower layers during a missed RXOP are ignored.

[0525] To implement this behavior, the process can be modified as follows:

[0526] 1) If a beam failure instance indication has been received from lower layers during an RXOP that is not considered to have been missed, then:

[0527] 2) Start or restart beamFailureDetectionTimer;

[0528] 2) Increment BFI_COUNTER by 1;

[0529] 2) If BFI_COUNTER ≥ beamFailureInstanceMaxCount, then:

[0530] 3) Initiate a random access process on the SpCell.

[0531] In any of the schemes for TX or RX capability sharing described herein, the TX capability of the UE may include one or more of the number of transmitters, transmit power budget, uplink (UL) multiple input multiple output (MIMO) capability, UL carrier aggregation (CA) capability, and UL bandwidth part (BWP) operation capability. Similarly, the RX capability of the UE may include one or more of the number of receivers, downlink (DL) MIMO capability, DL CA capability, and DL bandwidth part (BWP) operation capability. The UE may signal one or more of these capabilities to one or more of the multiple networks. In addition, the UE may signal changes in these capabilities to one or more of the multiple networks. For example, a UE having two receivers performing dual-connection reception from a network may indicate to the network that its reception capability is limited to one receiver in the case where one of the UE's receivers is reassigned for reception from another network.

[0532] The 3rd Generation Partnership Project (3GPP) develops technical standards for cellular telecommunication network technologies, including radio access, core transport networks, and service capabilities, including research on codecs, security, and quality of service. Recent radio access technology (RAT) standards include WCDMA (commonly referred to as 3G), LTE (commonly referred to as 4G), and LTE Advanced standards. 3GPP has begun working on the standardization of the next generation cellular technology (also known as "5G") called New Radio (NR). The development of the 3GPP NR standard is expected to include the definition of the next generation radio access technology (new RAT), which is expected to include the provision of new flexible radio access below 6 GHz, and the provision of new ultra-mobile broadband radio access above 6 GHz. The flexible radio access is expected to include new non-backward compatible radio access in new spectrum below 6 GHz, and is expected to include different operating modes that can be multiplexed together in the same spectrum to address a wide range of 3GPP NR use cases with different needs. It is expected that ultra-mobile broadband includes centimeter wave and millimeter wave spectrum, which can provide opportunities for ultra-mobile broadband access for indoor applications and hotspots, for example. In particular, ultra mobile broadband is expected to share a common design framework with sub-6 GHz flexible radio access, while having centimeter-wave and millimeter-wave specific design optimizations.

[0533] 3GPP has identified a variety of use cases that NR is expected to support, resulting in a wide variety of user experience requirements for data rates, latency, and mobility. Use cases include the following general categories: enhanced mobile broadband (e.g., broadband access in dense areas, ultra-high broadband access indoors, broadband access in crowded places, 50+Mbps everywhere, ultra-low-cost broadband access, mobile broadband in vehicles); critical communications; massive machine-type communications; network operations (e.g., network slicing, routing, migration and interworking, energy saving); and enhanced vehicle-to-everything (eV2X) communications, which may include any of vehicle-to-vehicle communications (V2V), vehicle-to-infrastructure communications (V2I), vehicle-to-network communications (V2N), vehicle-to-pedestrian communications (V2P), and vehicle-to-other-entities communications. Specific services and applications in these categories include, for example: surveillance and sensor networks, device remote control, two-way remote control, personal cloud computing, video streaming, cloud-based wireless offices, first responder connectivity, car e-calling, disaster alerts, real-time gaming, multi-person video calling, autonomous driving, augmented reality, tactile Internet, and virtual reality, among others. All of these use cases and others are considered in this article.

[0534] Fig.27A An embodiment of an exemplary communication system 100 in which the methods and apparatus described and claimed herein may be embodied is illustrated. As shown, the exemplary communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g (which may be generally or collectively referred to as WTRUs 102), a radio access network (RAN) 103 / 104 / 105 / 103b / 104b / 105b, a core network 106 / 107 / 109, a public switched telephone network (PSTN) 108, the Internet 110, other networks 112, and a V2X server (or ProSe function and server) 113, although it should be understood that the embodiments disclosed herein contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d, 102e, 102f, 102g may be any type of device or apparatus configured to operate and / or communicate in a wireless environment. FIG. 27A to FIG. 27E, but it should be understood that, with the wide variety of use cases envisioned for 5G wireless communications, each WTRU may include, or be embodied in, any type of apparatus or device configured to transmit and / or receive wireless signals, including, by way of example only, a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, a laptop, a tablet, a netbook, a notebook computer, a personal computer, a wireless sensor, a consumer electronic device, a wearable device (such as a smart watch or smart clothing), a medical or e-health device, a robot, an industrial equipment, a drone, a vehicle (such as a car, truck, train or airplane), etc.

[0535] The communication system 100 may also include a base station 114a and a base station 114b. The base station 114a may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or other networks 112. The base station 114b may be any type of device configured to wiredly and / or wirelessly interface with at least one of the RRHs (remote radio heads) 118a, 118b, TRPs (transmit and receive points) 119a, 119b, and / or RSUs (roadside units) 120a and 120b to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, other networks 112, and / or V2X servers (or ProSe functions and servers) 113. The RRHs 118a, 118b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102c to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or other networks 112. The TRPs 119a, 119b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102d to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or other networks 112. The RSUs 120a and 120b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102e or 102f to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, other networks 112, and / or a V2X server (or ProSe function and server) 113. By way of example, the base stations 114a, 114b may be base transceiver stations (BTS), Node Bs, eNode Bs, Home Node Bs, Home eNode Bs, site controllers, access points (APs), wireless routers, etc. Although the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0536] Base station 114a may be part of RAN 103 / 104 / 105, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSC), radio network controllers (RNC), relay nodes, etc. Base station 114b may be part of RAN 103b / 104b / 105b, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSC), radio network controllers (RNC), relay nodes, etc. Base station 114a may be configured to transmit and / or receive wireless signals within a specific geographic area, which may be referred to as a cell (not shown). Base station 114b may be configured to transmit and / or receive wired signals and / or wireless signals within a specific geographic area, which may be referred to as a cell (not shown). The cell may be further divided into cell sectors. For example, a cell associated with base station 114a may be divided into three sectors. Therefore, in one embodiment, base station 114a may include three transceivers, for example, one transceiver for each sector of the cell. In one embodiment, the base station 114a may employ multiple-input multiple-output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.

[0537] The base station 114a may communicate with one or more of the WTRUs 102a, 102b, 102c over an air interface 115 / 116 / 117, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). The air interface 115 / 116 / 117 may be established using any suitable radio access technology (RAT).

[0538] The base station 114b may communicate with one or more of the RRHs 118a, 118b, the TRPs 119a, 119b, and / or the RSUs 120a and 120b via a wired or air interface 115b / 116b / 117b, which may be any suitable wired communication link (e.g., cable, optical fiber, etc.) or a wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). The air interface 115b / 116b / 117b may be established using any suitable radio access technology (RAT).

[0539] The RRHs 118a, 118b, TRPs 119a, 119b and / or RSUs 120a, 120b may communicate with one or more of the WTRUs 102c, 102d, 102e, 102f via an air interface 115c / 116c / 117c, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). The air interface 115c / 116c / 117c may be established using any suitable radio access technology (RAT).

[0540] The WTRUs 102a, 102b, 102c, 102d, 102e, 102f and / or 102g may communicate with each other via an air interface 115d / 116d / 117d (not shown in the figures), which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). The air interface 115d / 116d / 117d may be established using any suitable radio access technology (RAT).

[0541] More specifically, as noted above, the communication system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c or the RRHs 118a, 118b, the TRPs 119a, 119b and the RSUs 120a, 120b and the WTRUs 102c, 102d, 102e, 102f in the RAN 103b / 104b / 105b may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interface 115 / 116 / 117 or 115c / 116c / 117c, respectively. WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed ​​Downlink Packet Access (HSDPA) and / or High Speed ​​Uplink Packet Access (HSUPA).

[0542] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c or RRHs 118a, 118b, TRPs 119a, 119b and / or RSUs 120a, 120b, and WTRUs 102c, 102d in the RAN 103b / 104b / 105b may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may use Long Term Evolution (LTE) and / or LTE Advanced (LTE-A) to establish the air interface 115 / 116 / 117 or 115c / 116c / 117c, respectively. In the future, the air interface 115 / 116 / 117 may implement 3GPP NR technology. LTE and LTE-A technologies include LTE D2D and V2X technologies and interfaces (such as sidelink communications, etc.). 3GPP NR technologies include NR V2X technologies and interfaces (such as sidelink communications, etc.).

[0543] In one embodiment, the base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c or RRHs 118a, 118b, the TRPs 119a, 119b and / or the RSUs 120a, 120b, and the WTRUs 102c, 102d, 102e, 102f in the RAN 103b / 104b / 105b may implement a radio technology such as IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rates for GSM Evolution (EDGE), GSM Evolution (GERAN), etc.

[0544] Fig.27AThe base station 114c in the WTRU 102d may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business, a home, a vehicle, a campus, etc. In one embodiment, the base station 114c and the WTRU 102d may implement a radio technology (such as IEEE 802.11) to establish a wireless local area network (WLAN). In one embodiment, the base station 114c and the WTRU 102d may implement a radio technology (such as IEEE 802.15) to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114c and the WTRU 102e may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or a femtocell. Fig.27A As shown, the base station 114b may have a direct connection to the Internet 110. Therefore, the base station 114c may not need to access the Internet 110 via the core network 106 / 107 / 109.

[0545] The RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b may be in communication with a core network 106 / 107 / 109, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. For example, the core network 106 / 107 / 109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication.

[0546] although Fig.27A Although not shown, it will be appreciated that the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b and / or the core network 106 / 107 / 109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b or a different RAT. For example, in addition to being connected to the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b, which may be utilizing an E-UTRA radio technology, the core network 106 / 107 / 109 may also be in communication with another RAN (not shown) employing a GSM radio technology.

[0547] The core network 106 / 107 / 109 may also act as a gateway for the WTRUs 102a, 102b, 102c, 102d, 102e to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and the Internet Protocol (IP) in the TCP / IP Internet protocol suite. The networks 112 may include wired or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b or a different RAT.

[0548] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities. For example, the WTRUs 102a, 102b, 102c, 102d, and 102e may include multiple transceivers for communicating with different wireless networks via different wireless links. Fig.27A The illustrated WTRU 102e may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114c, which may employ an IEEE 802 radio technology.

[0549] Fig.27B 1 is a block diagram of an exemplary apparatus or device (such as, for example, WTRU 102) configured for wireless communication according to an embodiment illustrated herein. Fig.27B As shown, the exemplary WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad / indicator 128, a non-removable memory 130, a removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It should be understood that the WTRU 102 may include any sub-combination of the foregoing elements while being consistent with an embodiment. In addition, embodiments contemplate that the base stations 114a and 114b and / or nodes that the base stations 114a and 114b may represent (such as, but not limited to, transceiver stations (BTS), Node Bs, site controllers, access points (APs), Home Node Bs, evolved Home Node Bs (eNodeBs), Home Evolved Node Bs (HeNBs), Home Evolved Node B gateways, and proxy nodes, etc.) may be included in the Fig.27B Some or all of the elements depicted in and described herein.

[0550] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Fig.27B The processor 118 and the transceiver 120 are depicted as separate components, but it is understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0551] Transmit / receive element 122 can be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via air interface 115 / 116 / 117. For example, in one embodiment, transmit / receive element 122 can be an antenna configured to transmit and / or receive RF signals. In one embodiment, transmit / receive element 122 can be a transmitter / detector configured to transmit and / or receive, for example, IR, UV or visible light signals. In another embodiment, transmit / receive element 122 can be configured to transmit and receive both RF signals and optical signals. It should be understood that transmit / receive element 122 can be configured to transmit and / or receive any combination of wireless signals.

[0552] Furthermore, although the transmit / receive element 122 is Fig.27B Although depicted as a single element in the figure, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115 / 116 / 117.

[0553] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and to demodulate signals received by the transmit / receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11.

[0554] The processor 118 of the WTRU 102 may be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad / indicator 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit), and may receive user input data from the foregoing components. The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad / indicator 128. In addition, the processor 118 may access information from and store data in any type of suitable memory, such as a non-removable memory 130 and / or a removable memory 132. The non-removable memory 130 may include a random access memory (RAM), a read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, or the like. In one embodiment, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0555] The processor 118 may receive power from the power source 134, and may be configured to distribute and / or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries, solar cells, fuel cells, etc.

[0556] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or in lieu of the information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the air interface 115 / 116 / 117 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by any suitable location-determination method while remaining consistent with an embodiment.

[0557] The processor 118 may also be coupled to other peripherals 138, which may include one or more software modules and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include various sensors such as accelerometers, biometric (e.g., fingerprint) sensors, electronic compasses, satellite transceivers, digital cameras (for photos or videos), universal serial bus (USB) ports or other interconnect interfaces, vibration devices, television transceivers, hands-free headsets, modules, FM radio units, digital music players, media players, video game player modules, Internet browsers, and more.

[0558] The WTRU 102 may be embodied in other apparatuses or devices, such as sensors, consumer electronic devices, wearable devices (such as smart watches or smart clothing), medical or e-health equipment, robots, industrial equipment, drones, vehicles (such as cars, trucks, trains, or airplanes). The WTRU 102 may be connected to other components, modules, or systems of such apparatuses or devices via one or more interconnect interfaces, such as an interconnect interface that may include one of the peripheral devices 138.

[0559] Fig.27C 1 is a system diagram of the RAN 103 and the core network 106 according to one embodiment. As described above, the RAN 103 may employ a UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 115. The RAN 103 may also be in communication with the core network 106. Fig.27C As shown, the RAN 103 may include Node-Bs 140a, 140b, 140c, which may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 115. The Node-Bs 140a, 140b, 140c may each be associated with a particular cell (not shown) within the RAN 103. The RAN 103 may also include RNCs 142a, 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and RNCs while remaining consistent with an embodiment.

[0560] like Fig.27CAs shown, Node B 140a, 140b can communicate with RNC 142a. In addition, Node B 140c can communicate with RNC 142b. Node B 140a, 140b, 140c can communicate with corresponding RNC 142a, 142b via Iub interface. RNC 142a, 142b can communicate with each other via Iur interface. Each of RNC 142a, 142b can be configured to control the corresponding Node B 140a, 140b, 140c to which it is connected. In addition, each of RNC 142a, 142b can be configured to perform or support other functionality, such as outer loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, data encryption, etc.

[0561] Fig.27C The core network 106 shown in FIG. 1 may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and / or a gateway GPRS support node (GGSN) 150. Although each of the foregoing elements is depicted as part of the core network 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0562] The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices.

[0563] The RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0564] As described above, the core network 106 may also be connected to the networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0565] Fig.27D1 is a system diagram of the RAN 104 and the core network 107 according to one embodiment. As described above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 116. The RAN 104 may also be in communication with the core network 107.

[0566] The RAN 104 may include evolved Node-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of evolved Node-Bs while remaining consistent with an embodiment. The evolved Node-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the evolved Node-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the evolved Node-B 160a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0567] Each of the evolved Node Bs 160a, 160b, and 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in the uplink and / or downlink, etc. Fig.27D As shown, the eNode-Bs 160a, 160b, 160c may communicate with one another via an X2 interface.

[0568] Fig.27D The illustrated core network 107 may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. While each of the foregoing elements is depicted as part of the core network 107, it should be understood that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0569] The MME 162 may be connected to each of the evolved Node-Bs 160a, 160b, and 160c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, etc. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

[0570] The serving gateway 164 may be connected to each of the evolved Node-Bs 160a, 160b, and 160c in the RAN 104 via an S1 interface. The serving gateway 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The serving gateway 164 may also perform other functions, such as anchoring a user plane during inter-evolved Node-B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, and the like.

[0571] The serving gateway 164 may also be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0572] The core network 107 may facilitate communications with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the core network 107 may include, or may be in communication with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the core network 107 and the PSTN 108. In addition, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and / or operated by other service providers.

[0573] Fig.27E 1 is a system diagram of the RAN 105 and the core network 109 according to one embodiment. The RAN 105 may be an access service network (ASN) that employs IEEE 802.16 radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 117. As will be discussed further below, the communication links between the different functional entities of the WTRUs 102a, 102b, 102c, the RAN 105, and the core network 109 may be defined as reference points.

[0574] like Fig.27EAs shown, the RAN 105 may include base stations 180a, 180b, 180c and an ASN gateway 182, but it should be understood that the RAN 105 may include any number of base stations and ASN gateways while remaining consistent with the embodiment. The base stations 180a, 180b, 180c may each be associated with a specific cell in the RAN 105 and may include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 117. In one embodiment, the base stations 180a, 180b, 180c may implement MIMO technology. Thus, the base station 180a, for example, may use multiple antennas to transmit wireless signals to the WTRU 102a and receive wireless signals from the WTRU 102a. The base stations 180a, 180b, 180c may also provide mobility management functions, such as handover triggering, tunnel establishment, radio resource management, service classification, quality of service (QoS) policy implementation, and the like. The ASN gateway 182 may serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 109, and the like.

[0575] The air interface 117 between the WTRUs 102a, 102b, 102c and the RAN 105 may be defined as an R1 reference point that implements the IEEE 802.16 specification. In addition, each of the WTRUs 102a, 102b, and 102c may establish a logical interface (not shown) with the core network 109. The logical interface between the WTRUs 102a, 102b, 102c and the core network 109 may be defined as an R2 reference point, which may be used for authentication, authorization, IP host configuration management, and / or mobility management.

[0576] The communication link between each of the base stations 180a, 180b, and 180c may be defined as an R8 reference point, which includes protocols for facilitating WTRU handovers and transfer of data between base stations. The communication link between the base stations 180a, 180b, 180c and the ASN gateway 182 may be defined as an R6 reference point. The R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 102c.

[0577] like Fig.27EAs shown, the RAN 105 may be connected to a core network 109. The communication link between the RAN 105 and the core network 109 may be defined as an R3 reference point, which includes, for example, protocols for facilitating data transfer and mobility management capabilities. The core network 109 may include a mobile IP home agent (MIP-HA) 184, an authentication, authorization, accounting (AAA) server 186, and a gateway 188. Although each of the foregoing elements is depicted as part of the core network 109, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0578] The MIP-HA may be responsible for IP address management and may enable the WTRUs 102a, 102b, and 102c to roam between different ASNs and / or different core networks. The MIP-HA 184 may provide the WTRUs 102a, 102b, and 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, and 102c and IP-enabled devices. The AAA server 186 may be responsible for user authentication and supporting user services. The gateway 188 may facilitate interworking with other networks. For example, the gateway 188 may provide the WTRUs 102a, 102b, and 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and 102c and traditional land-line communication devices. In addition, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and / or operated by other service providers.

[0579] Despite Fig.27E Not shown, but it will be appreciated that the RAN 105 may be connected to other ASNs, and the core network 109 may be connected to other core networks. The communication link between the RAN 105 and the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the WTRUs 102a, 102b, 102c between the RAN 105 and the other ASNs. The communication link between the core network 109 and the other core networks may be defined as an R5 reference point, which may include protocols for facilitating interworking between a home core network and a visited core network.

[0580] Described in this article and Fig.27A , Fig.27C , Fig.27D and Fig.27EThe core network entities shown in the are identified by the names given to those entities in certain existing 3GPP specifications, but it should be understood that those entities and functionality may be identified by other names in the future and that certain entities or functions may be combined in future specifications published by 3GPP (including future 3GPP NR specifications). Fig.27A , Fig.27B , Fig.27C , Fig.27D and Fig.27E The specific network entities and functionality described and illustrated in the present disclosure are provided by way of example only, and it should be understood that the subject matter disclosed and claimed herein may be embodied or implemented in any similar communication system (whether currently defined or defined in the future).

[0581] Fig.27F It is achievable Fig.27A , Fig.27C , Fig.27D and Fig.27E 106 / 107 / 109, PSTN 108, Internet 110 or other network 112. The computing system 90 may include a computer or server and may be controlled primarily by computer-readable instructions, which may be in the form of software, regardless of where or by what means such software is stored or accessed. Such computer-readable instructions may be executed within a processor 91 to enable the computing system 90 to operate. The processor 91 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, and the like. The processor 91 may perform signal encoding, data processing, power control, input / output processing, and / or any other functionality that enables the computing system 90 to operate in a communication network. Coprocessor 81 is an optional processor distinct from main processor 91 that may perform additional functions or assist processor 91. Processor 91 and / or coprocessor 81 may receive, generate, and process data related to the methods and apparatus disclosed herein.

[0582] In operation, processor 91 fetches, decodes and executes instructions, and transfers information to and from other resources via the computing system's main data transfer path (system bus 80). Such a system bus connects components in computing system 90 and defines a medium for data exchange. System bus 80 typically includes data lines for sending data, address lines for sending addresses, and control lines for sending interrupts and for operating the system bus. An example of such a system bus 80 is a PCI (Peripheral Component Interconnect) bus.

[0583] The memory coupled to the system bus 80 includes a random access memory (RAM) 82 and a read-only memory (ROM) 93. Such memory includes a circuit system that allows information to be stored and retrieved. ROM 93 generally contains stored data that cannot be easily modified. The data stored in RAM 82 can be read or changed by a processor 91 or other hardware device. Access to RAM 82 and / or ROM 93 can be controlled by a memory controller 92. The memory controller 92 can provide an address translation function that converts a virtual address into a physical address as an instruction is executed. The memory controller 92 can also provide a memory protection function that isolates processes within the system and isolates system processes from user processes. Therefore, a program running in the first mode can only access memory mapped by its own process virtual address space; unless memory sharing between processes has been set, it cannot access memory within the virtual address space of another process.

[0584] In addition, computing system 90 may include a peripheral device controller 83 responsible for passing instructions from processor 91 to peripheral devices such as printer 94 , keyboard 84 , mouse 95 , and disk drive 85 .

[0585] The display 86 controlled by the display controller 96 is used to display the visual output generated by the computing system 90. Such visual output may include text, graphics, animated graphics, and video. The visual output can be provided in the form of a graphical user interface (GUI). The display 86 can be implemented with a CRT-based video display, an LCD-based flat panel display, a gas plasma-based flat panel display, or a touch pad. The display controller 96 includes the electronic components required to generate the video signal sent to the display 86.

[0586] Additionally, computing system 90 may include communications circuitry, such as a network adapter 97, which may be used to connect computing system 90 to an external communications network, such as Fig.27A , Fig.27B , Fig.27C , Fig.27D and Fig.27EThe RAN 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110 or other network 112 of the processor 91 may be used to enable the computing system 90 to communicate with other nodes or functional entities of those networks. The communication circuit system alone or in combination with the processor 91 may be used to perform the transmission and reception steps of certain devices, nodes or functional entities described herein.

[0587] Figure 27G An embodiment of an example communication system 111 in which the methods and apparatus described and claimed herein may be embodied is shown. As shown, the example communication system 111 may include wireless transmit / receive units (WTRUs) A, B, C, D, E, F, base stations, V2X servers, and RSUs A and B, but it should be understood that the embodiments disclosed herein contemplate any number of WTRUs, base stations, networks, and / or network elements. One or several or all of the WTRUs A, B, C, D, E may be outside the range of the network (e.g., outside the cell coverage boundary as shown by the dashed line in the figure). WTRUs A, B, C form a V2X group, with WTRU A being the group leader and WTRUs B and C being group members. WTRUs A, B, C, D, E, F may communicate via a Uu interface or a sidelink (PC5) interface.

[0588] It should be understood that any or all of the devices, systems, methods, and processes described herein can be implemented in the form of computer executable instructions (e.g., program code) stored on a computer-readable storage medium, which, when executed by a processor (such as processor 118 or 91), causes the processor to execute and / or implement the systems, methods, and processes described herein. Specifically, any of the steps, operations, or functions described herein can be implemented in the form of such computer executable instructions executed on a processor of a device or computing system configured for wireless and / or wired network communication. Computer-readable storage media include volatile and non-volatile, removable and non-removable media implemented with any non-temporary (e.g., tangible or physical) method or technology for storing information, but such computer-readable storage media do not include signals. Computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, cassettes, tapes, magnetic disk storage or other magnetic storage devices, or any other tangible or physical media that can be used to store the desired information and can be accessed by a computing system.

Claims

1. A wireless transmit / receive unit WTRU, comprising a processor, wherein the processor is configured to: determining first information indicating one or more receive RX opportunities RXOP or receive capabilities; establishing one or more connections to one or more networks associated with one or more subscriber identity modules SIM based on the first information; receiving second information from the one or more networks; as well as Third information is sent to the one or more networks.

2. The WTRU of claim 1 , wherein: Sending the third information is in response to one or more missed RXOPs.

3. The WTRU of claim 1 , wherein: The third information comprises an indication of an adapted behavior of a Medium Access Control MAC layer interface.

4. The WTRU of claim 1 , wherein: The one or more networks include a first network and a second network, the one or more SIMs include a first SIM and a second SIM, the first network is associated with the first SIM, and the second network is associated with the second SIM.

5. The WTRU of claim 4, wherein: A receiver or transmitter chain is shared between the first network and the second network.

6. The WTRU of claim 5, wherein: The sharing of the receiver or transmitter chains is based on one or more medium access control (MAC) timers in response to one or more missed RXOPs.

7. The WTRU of claim 1 , wherein: The processor is configured to adapt one or more medium access control (MAC) timers in response to one or more missed RXOPs to avoid prematurely declaring a failure.

8. The WTRU of claim 1 , wherein: The processor is further configured to send an indication of reception failure to one or more upper layers when the number of missed RXOPs exceeds a threshold.

9. A method performed by a wireless transmit / receive unit WTRU, the method comprising: determining first information indicating one or more receive RX opportunities RXOP or receive capabilities; establishing one or more connections to one or more networks associated with one or more subscriber identity modules SIM based on the first information; receiving second information from the one or more networks; as well as Third information is sent to the one or more networks.

10. The method according to claim 9, wherein: Sending the third information is in response to one or more missed RXOPs.

11. The method according to claim 9, wherein: The third information comprises an indication of an adapted behavior of a Medium Access Control MAC layer interface.

12. The method according to claim 9, wherein: The one or more networks include a first network and a second network, the one or more SIMs include a first SIM and a second SIM, the first network is associated with the first SIM, and the second network is associated with the second SIM.

13. The method according to claim 12, wherein: A receiver or transmitter chain is shared between the first network and the second network.

14. The method according to claim 13, wherein: The sharing of the receiver or transmitter chains is based on one or more medium access control (MAC) timers in response to one or more missed RXOPs.

15. The method of claim 9, comprising adapting one or more medium access control (MAC) timers in response to one or more missed RXOPs to avoid prematurely declaring a failure.

16. The method of claim 9, comprising sending an indication of reception failure to one or more upper layers when the number of missed RXOPs exceeds a threshold.

17. A system including an access layer AS protocol of multiple subscriber identity modules SIM wireless transmit / receive units WTRU, the AS protocol comprising: The upper AS layer is configured to implement the radio resource control RRC function; The intermediate AS layer is configured to implement the functions of the radio layer control RLC, the packet data convergence protocol PDCP layer and the service data adaptation protocol SDAP layer; and A lower AS layer is configured to implement medium access control MAC and physical layer functions, wherein the lower AS layer includes a first common MAC (CoMAC) entity associated with the WTRU and a first dedicated MAC (DeMAC) entity associated with the first SIM, as well as a second CoMAC entity associated with the WTRU and a second DeMAC entity associated with the second SIM, wherein the first CoMAC entity and the second CoMAC entity are configured to coordinate across service networks associated with the first SIM and the second SIM.

18. The system according to claim 17, further comprising a common non-access stratum NAS entity and a plurality of dedicated NAS entities, wherein: Each dedicated NAS entity of the plurality of dedicated NAS entities is associated with a respective SIM.

19. A wireless transmit / receive unit WTRU, comprising a processor, wherein the processor is configured to: Send a request for system information; and In response to a request for system information, receiving system information, wherein: Receiving system information using a Multiple Subscriber Identity Module SIM power saving mode.

20. The WTRU of claim 19 wherein: The multi-SIM power saving mode is associated with a Radio Resource Control (RRC) inactive state.

Images