Method for multiple SIM ue connection mode operation

Abstract

To improve a multiple subscriber identification module (SIM) connection mode operation.SOLUTION: A method contains: a step (1) of requesting an access to a RX (reception) chain by an AS (access layer) 1; a step (2) of providing a response that indicates an access permission by determining that a RX / TX (transmission) chain arbiter can be used in a RX chance to be required; a step (3) of receiving a DL transmission from a gNBA in the RX chance to be required by an AS1; a step (4) of requesting the access to a TX chain; a step (5) of providing a response that indicates the access permission by determining that the RX / TX chain arbiter can be used in the TX chance to be required; a step (6) of transmitting an UL in the TX chance to be required by the AS1 to the gNBA; a step (7) of requesting the access to the TX chain by the AS2; a step (8) of providing a response that indicates the access permission by determining that the RX / TX chain arbiter can be used in the TX chance to be requested; and a step (9) of transmitting the UL in the TX chance to be requested by the AS2 to a gNBB.SELECTED DRAWING: Figure 21

Description

Technical Field

[0001] (Cross - Reference to Related Applications) This application claims the benefit of U.S. Provisional Patent Application No. 62 / 934,748, filed on November 13, 2019, the entire content of which is incorporated herein by reference.

Background Art

[0002] A multi - SIM UE is a UE having two or more SIMs (Subscriber Identity Modules or Service Identity Modules). These devices are becoming popular in various places. However, multi - SIM operation presents many challenges regarding UE behavior that can negatively impact the user experience and the overall system performance. Therefore, improved procedures for multi - SIM operation are needed.

Summary of the Invention

[0003] This summary is provided to introduce a selection of concepts in a simplified form, which are further described below in the "Detailed Description of the Invention". This summary is not intended to identify 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. Further, the claimed subject matter is not limited to restrictions that solve any or all of the disadvantages described in any part of this disclosure.

[0004] This specification describes methods and apparatuses for multi-subscriber identification module (SIM) connection mode operation. According to one embodiment, a wireless communication device can receive a requested access to a receiver chain during a reception opportunity from an access layer interface. The wireless communication device can determine that the receiver chain is available during the reception opportunity. The wireless communication device can transmit a response indicating that access is permitted to cause the access layer interface to receive a downlink transmission during the reception opportunity. The wireless communication device can receive a second request for a transmitter chain during a transmission opportunity from the access layer interface. The wireless communication device can determine that the transmitter chain is available during the transmission opportunity. The wireless communication device can transmit a second response indicating that access is permitted to enable the access layer interface to transmit an uplink transmission during the transmission opportunity.

Brief Description of the Drawings

[0005] The foregoing summary, as well as the following detailed description of the invention, will be better understood when read in conjunction with the accompanying drawings. For the purpose of explaining 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 drawings,

[0006]

Figure 1

[0007]

Figure 2

[0008]

Figure 3

[0009]

Figure 4

[0010]

Figure 5

[0011]

Figure 6

[0012]

Figure 7

[0013]

Figure 8

[0014]

Figure 9

[0015]

Figure 10

[0016]

Figure 11

[0017]

Figure 12

[0018]

Figure 13

[0019]

Figure 14

[0020]

Figure 15

[0021]

Figure 16

[0022]

Figure 17

[0023]

Figure 18

[0024]

Figure 19

[0025]

Figure 20

[0026]

Figure 21

[0027]

Figure 22

[0028]

Figure 23

[0029]

Figure 24

[0030]

Figure 25

[0031]

Figure 26

[0032]

Figure 27A

[0033]

Figure 27B

[0034]

Figure 27C

[0035]

Figure 27D

[0036]

Figure 27E

[0037]

Figure 27F

[0038]

Figure 27G

Mode for Carrying Out the Invention

[0039] In this specification, methods and apparatuses are described for multi-subscriber identity module (SIM) connection mode operation.

[0040] The following abbreviations and definitions may be used in this specification. 3GPP 3rd Generation Partnership Project 5G 5th Generation 5GS 5G System 5G-S-TMSI 5G Shortened Temporary Mobile Subscriber Identity AS Access Stratum BWP Bandwidth Part BSR Buffer Status Report CORESET Control Resource Set CN Core Network CM Connection Management CoMAC Common MAC CoNAS Common NAS CoRRC Common 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 Active 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 identification or identifier LCG Logical Channel Group LCP Logical Channel Prioritization LTE Long Term Evolution MAC Media Access Control MAC CE MAC Control Element MNO Mobile Network Operator Msg2 Message 2 of the random access procedure Msg3 Message 3 of the random access procedure NAS Non-AS NB Node B NR New Radio N TA Timing Advance between Downlink and Uplink PDCCH Physical Downlink Control Channel PDCP Packet Data Convergence Protocol PDU Protocol Data Unit PHR Power Headroom PHY Physical Layer PLMN Public Land Mobile Network PRACH Physical Random Access Channel P-RNTI Paging Radio Network Temporary Identifier PTAG Primary Timing Advance Group PUCCH Physical Uplink Control Channel PUSCH Physical Uplink Shared Channel QoS Quality of Service RA-RNTI Random Access Radio Network Temporary Identifier RAR Random Access Response RLC Radio Link Control RRC Radio Resource Control RTT Round Trip Time RXOP Receiver Opportunity SDAP Service Data Adaptation Protocol SDU Service Data Unit SIM Subscriber Identification Module or Service Identification Module SCell Secondary Cell SpCell Special Cell SDAP Service Data Adaptation Protocol SI System Information SPS Semi-Persistent Scheduling SR Scheduling Request SRS Sounding Reference Signal SSB Synchronization Signal Block STAG Secondary Timing Advance Group TAG Timing Advance Group TXOP Transmission Opportunity RACH Random Access Channel RAN Radio Access Network RAT Radio Access Technology Req Request RLC Radio Link Control RNTI Radio Network Temporary Identifier RRC Radio Resource Control Rsp Response RSU Road Side Unit RX Receiver or Reception RXOP RX Opportunity TDM Time Division Multiplexing TX Transmitter or Transmission TXOP TX Opportunity UCI Uplink Control Information UE User Equipment UL Uplink UL-SCH Uplink Shared Channel UMTS Universal Mobile Telecommunications System USIM Universal SIM Uu Interface Connecting UE to RAN V2X Vehicle-to-X Communication

[0041] A multi-SIM UE is a UE that has two or more SIMs. A dual-SIM UE is a UE that has two SIMs. The terms multi-SIM and dual-SIM may be used interchangeably in this specification. Multi-USIM devices are becoming increasingly popular in different countries. A user can have both personal and business subscriptions on one device for different services, or have two personal subscriptions on one device (e.g., use one individual subscription and one "family circle" plan). However, the support for multi-USIM within a device is currently handled in an implementation-specific way that does not include any support from 3GPP specifications, resulting in various implementations and UE behaviors (e.g., passive dual-SIM, dual-SIM single standby, dual-SIM dual standby, dual-SIM dual active, etc.). Such a situation can cause an increase in UE vendor complexity, unexpected UE behavior for network vendors or operators, and degradation of the user experience.

[0042] The following terms are defined in this specification.

[0043] Passive dual-SIM: The device contains two SIMs, but only one can be selected for use at any given time, under the assumption that both SIMs share a single transceiver. This implementation may be attractive with respect to network vendor or operator device complexity or unexpected UE behavior, but it does not meet the expectations of dual-SIM devices in order to enable the user to be reachable or available via two networks at any given time, or to enable the user to perform simultaneous communication via two networks that may belong to the same or different operators.

[0044] 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). This occasional activity on the second system may or may not have any performance impact depending on the UE implementation, i.e., single Rx or dual Rx.

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

[0046] Dual SIM Dual Active (DSDA): Both SIMs can be used in both the idle mode and the connected mode. For example, one communication can be for voice services and another can be for data services. Usually, each SIM is considered to have a dedicated transceiver, which means there is no interdependence in idle mode or connected mode operation at the modem level. However, even in this case, simultaneous communication with two systems presents challenges that can affect UE performance and network performance, some of which include UE power control and capacity adjustment such that the power budget and capacity budget of the multi-SIM device are not exceeded.

[0047] Serving SIM: The SIM selected by the UE for use in either idle mode operation or connection mode operation. Hereinafter, the terms serving SIM and SIM may be used interchangeably.

[0048] Serving RAN: The RAN that provides services to the UE for either idle mode operation or connection mode operation. The serving RAN is associated with the serving SIM.

[0049] Serving PLMN: The PLMN that provides services to the UE for either idle mode operation or connection mode operation. The serving PLMN is associated with the serving SIM.

[0050] Serving network: The network that provides services to the UE for either idle mode operation or connection mode operation. The serving network is associated with the serving SIM. The network can relate to a RAN or a PLMN or a combination thereof.

[0051] The term UE capability time domain multiplexing (TDM) or UE capability multiplexing in the time domain refers to the sharing of the UE capabilities between serving networks in the support of idle mode operations or connection operations within the serving network where the idle mode operation or connection mode operation can be performed simultaneously. Examples of UE capabilities that can be time domain multiplexed can include transmitters, receivers, transmit power budgets, etc.

[0052] Multi-SIM usage cases and deployment scenarios are described in this document. It should be noted that these are provided for illustrative purposes only and do not in any way limit the applicability of the solutions described in this document.

[0053] Use Case 1: The user is traveling overseas from the United States to Asia and has a UE that supports multiple USIM cards. For cost reduction purposes, the UE is implemented with a common radio and baseband component that the USIMs share access to. As a result, only one USIM can be active at any given time. The user purchases a USIM when reaching access to cellular services while traveling within the destination country. The travel USIM card can provide local voice, text, and high-speed data services, and the home USIM card is used mainly to provide voice and text that the user may want to receive while traveling.

[0054] Use Case 2: Another prominent use case involves a user who has both business and personal subscription services and wants to use both services on the same device, leveraging multiple USIM centers around the user. The user has a company-issued UE with a subscription service for USIM1 using Operator 1, while the user has a personal subscription service for USIM2 using Operator 2. The user wants to be able to receive voice calls from either service and access data services according to the subscription to either USIM1 or USIM2, depending on the date and time or the application using the service.

[0055] The multi-SIM deployment scenario may include one of the following deployment scenarios for each of the following subsystems.

[0056] Core network: a) Both SIMs are 5GS, b) Both SIMs are EPS, c) SIM A is 5GS and SIM B is EPS, d) SIM A and SIM B belong to the same operator (in the case of within an MNO), e) SIM A and SIM B belong to two different operators (in the case of between MNOs).

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

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

[0059] 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.

[0060] Figure 1 shows an exemplary UE state machine and state transitions in NR100. The example in Figure 1 shows transitions to / from the NR RRC_CONNECTED state 101 with interruption during resume / release, to / from the NR RRC_INACTIVE state 102, and transitions to / from the NR RRC_CONNECTED state 101 with establishment / release, to / from the NR RRC_IDLE state 103. Transitions to / from the NR RRC_IDLE state 103 during release of the NR RRC_INACTIVE state 102 are also shown.

[0061] Figure 2 shows an exemplary UE state machine and state transitions 200 between NR / 5GC, E-UTRA / EPC, and E-UTRA / 5GC. The example in Figure 2 shows transitions to / from the EUTRA RRC_CONNECTED state 201, to / from the EUTRA RRC_INACTIVE state 202, and transitions being established / released to / from the EUTRA RRC_CONNECTED state 201, to / from the EUTRA RRC_IDLE state 203. Transitions being released to / from the EUTRA RRC_INACTIVE state 202, to / from the EUTRA RRC_IDLE state 203 are also shown.

[0062] Transitions to / from the NR RRC_CONNECTED state 204, to / from the NR RRC_INACTIVE state 205, and transitions being established / released to / from the NR RRC_CONNECTED state 204, to / from the NR RRC_IDLE state 206. Transitions being released to / from the NR RRC_INACTIVE state 205, to / from the NR RRC_IDLE state 206 are also shown.

[0063] Transitions during reselection from the EUTRA RRC_INACTIVE state 202 to the NR RRC_IDLE state 206 are also shown. Transitions during reselection from the NR RRC_INACTIVE state 205 to the EUTRA RRC_IDLE state 206 are also shown. Transitions during reselection to / from the EUTRA RRC_IDLE state 203, to / from the NR RRC_IDLE state 206 are also shown.

[0064] UE Registration Management (RM) is described herein. The UE performs registration when it first registers with the network as a result of a certain mobility event or as a result of expiration of a certain timer (i.e., periodic registration update timer or non-3GPP registration release timer).

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

[0066] In the RM-DEREGISTERED state: The UE is not reachable. The AMF can cache a certain UE context. The UE leaves this state by initiating the initial registration procedure.

[0067] In the RM-REGISTERED state: The UE performs registration updates upon mobility and timer expiration. The UE or the AMF can perform the deregistration procedure at any time. The AMF can perform an implicit deregistration upon timer expiration.

[0068] 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).

[0069] The registration management (CM) states of the UE are CM-IDLE and CM-CONNECTED. The UE and the network maintain separate CM states for each RAT (i.e., 3GPP and non-3GPP).

[0070] In the CM-IDLE state: There is no NAS signaling connection established with an AMF beyond N1.

[0071] In the CM-CONNECTED state: The UE has a NAS connection. This requires an RRC connection in the NG-RAN. The UE can be in RRC-Inactive, in which case reachability is managed by the RAN. The UE can return to the CM-IDLE state when its AN signaling connection is released.

[0072] As described above, if dual SIM or multi-SIM operation is not addressed in the specification, it presents many challenges regarding UE behavior that can negatively impact the user experience and the overall system performance. The method and apparatus described in this specification address the following multi-SIM operation problems:

[0073] Problem 1: Enhancement of the UE AS protocol architecture:

[0074] To minimize processing overhead and power consumption, enhancement of the UE protocol architecture (e.g., AS) and state machine is necessary. For example, most of the idle mode procedures, such as cell (re)selection and camping, will benefit from adjustments to reduce UE processing overhead and power consumption, especially in the case of multi-SIM MNO in-region deployment scenarios.

[0075] Problem 2: Potential collision of UL transmissions from two RATs:

[0076] This problem addresses the impact on the specification of time domain multiplexing (TDM) of UE capabilities such as transmitter chain capabilities to maintain simultaneous uplink communication with two PLMNs. For example, considering a multi-SIM device with single RX and single TX, or dual RX and single TX, procedures are enabled to allow TDM use of the TX chain to enable interruption (or release) and resumption of an ongoing connection in a 3GPP system associated with USIM A so that the UE can temporarily access a 3GPP system associated with USIM B. It is also necessary to investigate the related UE behavior including HARQ timing processing as a result of UL transmission gaps and the processing of UE timers such as MAC timers and RRC timers. This problem should be understood in the context of inter-PLMN operation with multi-SIM deployment scenarios highlighted in this specification, covering the enumerated CN deployment scenarios, the enumerated RAN deployment scenarios, and the enumerated connection mode related AS state combinations.

[0077] Problem 3: Potential collision in DL data reception, e.g., both RATs are in CONNECTED.

[0078] The problem addresses the impact on the receiver chain's time-domain multiplexing (TDM) specification to maintain simultaneous downlink communication with two PLMNs. For example, considering a multi-SIM device with single RX and single TX, or single RX and single TX, procedures are enabled to allow TDM use of the RX chain to enable interruption (or release) and resumption of the continuous connection in the 3GPP system associated with USIM A so that the UE can temporarily access the 3GPP system associated with USIM B. It is also necessary to investigate the related UE behavior, including HARQ timing processing as a result of DL reception gaps and the processing of UE timers such as MAC timers and RRC timers. This problem should be understood in the context of inter-PLMN operation with a multi-SIM deployment scenario, as emphasized in this document, covering the enumerated CN deployment scenarios, enumerated RAN deployment scenarios, and enumerated connection-mode related AS state combinations.

[0079] Figure 3 shows an exemplary Access Stratum (AS) protocol 300. According to one embodiment, the AS protocol of a multi-SIM UE may include an upper AS layer 301, an intermediate AS layer 302, and a lower AS layer 303. In the control plane, the upper AS layer 301 may implement the RRC function. The lower AS layer 303 may implement the functions of the MAC layer and the PHY layer. The lower AS layer 303 may further include a common MAC (CoMAC) for the UE and a dedicated MAC for each serving SIM (DeMAC) (i.e., the serving network associated with each serving SIM). CoMAC can assist DeMAC entities, resolve their actions, and implement logic for efficient coordination via the serving network associated with the serving SIM, e.g., logic for time-domain multiplexing of UE capabilities such as a transceiver or power jet via the serving network associated with the serving SIM of the UE.

[0080] NAS can include an upper NAS and a lower NAS. The upper NAS may include a common NAS (CoNAS) for the UE and a set of dedicated NAS (DeNAS) entities each having a DeNAS for a serving SIM (i.e., the serving network associated with each serving SIM). CoNAS can assist DeNAS entities and adjust their actions, for example, to ensure efficient operation of the UE for minimizing UE processing overhead, power consumption, and for efficient overall system performance.

[0081] For both the RRC layer and the NAS layer, a new UE-level state machine for the SIM-level state machine has also been proposed.

[0082] The AS procedures for enabling TDM sharing of the RX / TX chain are described herein. This document describes a method for performing dynamic sharing of the RX / TX chain based on the creation of requests to the RX / TX chain arbiter, and access may be permitted in first-come, first-served order, USIM identification, or the priority of the service for which access is requested.

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

[0084] This document describes a method for performing random access procedures considering the effect of sharing the RX / TX chain, including the following.

[0085] A mechanism for performing random access resource selection according to the inability to access the RX / TX chain,

[0086] A mechanism for adapting the start of the RAR window, which is conditional on obtaining access to the RX chain, over the duration of the ra-ResponseWindow, and

[0087] A mechanism for adapting the start of the contention resolution window, which is conditional on obtaining access to the RX chain, over the duration of the ra-ContentionResolutionTimer.

[0088] This document describes a method for performing sharing of the RX / TX chain based on adapting MAC counters and timers in response to losing RXOP / TXOP, including the following.

[0089] A mechanism for controlling the setting of a prohibition timer and the increment of a transmission counter in response to the loss of a TXOP, and

[0090] A mechanism for pausing or extending a timer used to control DL monitoring in response to the loss of an RXOP.

[0091] FIG. 4 shows an RRC 400. The RRC can include a set of a common RRC (CoRRC) entity 401 and dedicated RRC (DeRRC) entities 402, where one DeRRC entity is for each serving SIM (i.e., the serving network associated with each serving SIM). The CoRRC 401 can assist the DeRRC 402 entities and can coordinate / resolve their actions, for example, to ensure the efficient operation of the UE for UE processing overhead, minimizing power consumption, and efficient overall system performance including the use of radio resources. The CoRRC 401 can implement logic for efficient coordination via the serving network associated with the serving SIM, e.g., logic for time-domain multiplexing of UE capabilities such as a transceiver or power jet via the serving network associated with the serving SIM of the UE.

[0092] In one embodiment, the CoRRC entity 401 in the UE can implement the multiplexing function or one or more shared capabilities of the UE for, for example, a shared transmitter, a shared receiver, a shared transceiver, a shared power jet, a shared common amplifier, or any other transmission and / or reception common hardware.

[0093] In another embodiment, the CoRRC entity 401 can assist the UE or other entities within the network, such as entities within the lower layer AS, in the multiplexing of one or more capabilities of the UE that are shared between the serving networks associated with the UE's SIM. The DeRRC can implement the RRC protocol architecture according to legacy systems, for example, in the support of carrier aggregation or multi-connectivity within the serving network associated with the same SIM. For example, in the case of multi-connectivity within the serving network of a given SIM, the DeRRC associated with this serving network can be composed of multiple instances, for example, having one instance for each cell group for the master cell group versus the secondary cell group.

[0094] The CoRRC entity 401 can implement one or more functions of the RRC IDLE state, RRC INACTIVE state, or RRC CONNECTED state. Similarly, the DeRRC can implement one or more functions of the RRC IDLE state, RRC INACTIVE state, or RRC CONNECTED state. In one embodiment, the CoRRC can implement the RRC IDLE or RRC INACTIVE functions, while the DeRRC can implement the RRC CONNECTED function. The CoRRC ensures the coordination with the multiplexing of the shared capabilities of the UE via an independent network with the DeRRC entity, for example, to minimize UE processing overhead and power consumption, for example, for the efficient operation of UE operations. The CoRRC can implement logic that reflects the overall RRC state of the UE, in contrast to the states regarding the serving networks associated with each of the UE's SIMs.

[0095] In the user plane, the upper layer may or may not be present. For example, in one embodiment where the AS upper layer is present in the user plane, this upper layer can implement the SDAP function.

[0096] FIG. 5 shows the multi-SIM UE intermediate AS500 in the C plane. The example of FIG. 5 shows that in the control plane, the intermediate AS may implement the functions of the PDCP layer 501 and the RLC layer 502. RLC 502 and PDCP 501 may be dedicated for each serving SIM.

[0097] FIG. 6 shows the multi-SIM UE intermediate AS600 in the U plane. 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. SDAP 601, RLC 602, and PDCP 603 may be dedicated for each serving network associated with each SIM.

[0098] FIG. 7 shows the multi-SIM UE lower AS700. FIG. 7 shows that the lower AS may implement the functions of the MAC layer 701 and the PHY layer 702.

[0099] FIG. 8 shows the multi-SIM MAC800. FIG. 8 shows that the MAC may include a set 802 of dedicated MAC (DeMAC) entities having a common MAC (CoMAC) entity 801 and one DeMAC entity for each serving SIM.

[0100] CoMAC801 can support the DeMAC802 entity, and for example, can adjust their actions to ensure the efficient operation of the UE in order to minimize the overall system performance including UE processing overhead, power consumption, and radio resource usage. In one embodiment, the CoMAC entity in the UE can implement the multiplexing function or one or more shared capabilities of the UE for, for example, a shared transmitter, a shared receiver, a shared transceiver, a shared power jet, a shared common amplifier, or any other transmission and / or reception common hardware. In another embodiment, the CoMAC entity can support the UE or any other entity within the network, for example, an entity within the upper layer AS, in the multiplexing of one or more capabilities of the UE that are shared between the serving network associated with the UE's SIM. DeMAC can implement the MAC protocol architecture according to legacy systems, for example, in the support of carrier aggregation or multi-connectivity within the serving network associated with the same SIM. For example, in the case of multi-connectivity within the serving network of a given SIM, the DeMAC associated with this serving network can be composed of a plurality of instances each having one instance for each cell group for the master cell group versus the secondary cell group.

[0101] Figure 9 shows an exemplary multi-SIM NAS900. Figure 9 shows that the non-access stratum (NAS) protocol of a multi-SIM UE can be modeled to include an upper NAS901 and a lower NAS902.

[0102] Figure 10 shows another exemplary multi-SIM NAS1000. In this example, the NAS can include a common NAS (CoNAS) 1001 and a set 1002 of dedicated NAS (DeNAS) entities each having one DeNAS entity for each serving SIM.

[0103] Figure 11 shows the multi-SIM upper NAS 1100. The upper NAS 1100 includes CoNAS 1101.

[0104] Figure 12 shows the multi-SIM lower NAS 1200. The lower NAS 1200 includes the DeNAS entity 1201.

[0105] CoNAS can support the DeNAS entity. For example, in order to minimize UE processing overhead, power consumption, and efficient overall system performance, it can adjust those actions to ensure the efficient operation of the UE. In one embodiment, the CoNAS entity in the UE can implement the multiplexing function of one or more shared capabilities of the UE, such as the number of simultaneous communication sessions in the UE. In another embodiment, the CoNAS entity can support any other entity in the UE or the network, such as an entity in the lower NAS or AS, in the multiplexing of one or more capabilities of the UE that are shared between the serving networks associated with the SIMs of the UE. DeNAS can implement the NAS protocol architecture according to the legacy system, for example, in the support of each 3GPP AS and non-3GPP access of the serving networks associated with the SIMs of the UE. CoNAS can process or support, for example, the adjustment of the processing of user preferences for the prioritization of services between the serving networks associated with the SIMs in the UE.

[0106] CoNAS can implement or assist in implementing one or more functions in the NAS IDLE state (e.g., CM IDLE or ECM IDLE), or one or more functions in the NAS CONNECTED state (e.g., CM CONNECTED or ECM CONNECTED). Similarly, DeNAS can implement one or more functions in the NAS IDLE state or the NAS CONNECTED state. For example, in one embodiment, CoNAS can implement or assist in implementing functions such as PLMN selection or UE reachability in the NAS IDLE state. Similarly, CoNAS can implement or assist in implementing policy adaptation and UE reachability when the UE is in the NAS CONNECTED state with respect to some of the serving networks associated with the SIM in the UE. CoNAS can implement logic that reflects the overall NAS state of the UE, as opposed to the state with respect to each serving network associated with each SIM of the UE.

[0107] In one embodiment, the DeNAS entity can be associated with each SIM of the UE. The DeNAS entity can maintain one or more registration management (RM) states (e.g., the RM state for 3GPP access and the RM state for non-3GPP access). The DeNAS entity can also maintain one or more connection management (CM) states (e.g., the CM state for 3GPP access and the CM state for non-3GPP access). As described above, CoNAS can implement logic that reflects the overall NAS state of the UE for each available RAT of the UE. Further, the CoNAS state machine can be driven by requests and indications received from the DeNAS entity in the lower NAS. How the CoNAS state machine and its states transition will be further described below. The CoNAS entity can maintain separate states for each available RAT of the UE (i.e., non-3GPP and 3GPP). Note that separate states can be maintained for each transceiver. In other words, if the UE includes two 3GPP transceivers, the UE can maintain the CoNAS state for each transceiver.

[0108] Figure 13 shows a high-level view of the NAS and AS protocol stacks within UE 1300. NAS 1301 may include common NAS 1302 and dedicated NAS 1303. RRC 1304 may include common RRC 1305 and dedicated RRC 1304.

[0109] Figure 14 shows a high-level view of the UE with respect to the network NAS and AS protocol stack 1400. The example of Figure 14 shows that UE 1401 may include a NAS 1410 that includes common NAS 1411 and dedicated NAS 1410. UE 1401 may include an RRC 1420 that includes common RRC 1421 and dedicated RRC 1420.

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

[0111] PLMN B 1403 may include a base station 1450 that includes an RRC 1451 that includes common RRC 1452 and dedicated RRC 1453. PLMN B 1403 may include a CN 1460 that includes a NAS 1461 that includes common NAS 1462 and dedicated NAS 1463.

[0112] Note that the use of a multi-SIM UE control plane architecture as shown in Figure 13 does not require the network to implement a similar architecture that involves, for example, a split of common NAS versus dedicated NAS or a split of common RRC versus dedicated RRC as illustrated in Figure 14.

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

[0114] Figure 15 shows an exemplary RRC state machine 1500. The example of Figure 15 shows the RRC state machine for the entire UE level, and the RRC architecture is as shown in Figure 4. Each of the RRC states captured in Figure 15 can relate to CoRRC or DeRRC as shown in Figure 4. The RRC state machine of a multi-SIM UE can be designed to reduce any increase in power consumption and avoid shortening the UE battery life as a result of the multi-SIM operation mode. It has been proposed to introduce a multi-SIM power-saving mode of operation. A multi-SIM mode UE can be designed to operate in the multi-SIM power-saving mode or can be designed to operate in such a mode based on UE configuration (e.g., via the GUI), UE capabilities, or user preferences. The UE can exchange signaling with the network to determine whether it can operate in the multi-SIM power-saving mode.

[0115] The UE-level RRC state is described as follows.

[0116] FULL RRC IDLE1501: In this state, the UE can be in the SIM-level RRC IDLE state for each SIM within the UE, that is, for each SIM in the UE, or alternatively for each SIM in the UE selected for use. The UE performs PLMN selection and camps on a cell, but does not have an RRC connection in any of the cells on which the UE camps. Hereinafter, the terms "SIM in the UE" or "SIM in the UE selected for use" or "serving SIM" can be used interchangeably. The UE can transition from this state to the MIXED_RRC_IDLE_CONNECTED1506 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 IDLE1501 to the MIXED_RRC_IDLE_CONNECTED1506 state. In the FULL RRC_IDLE state 1501, the UE can perform "reduced power" idle mode operations such as "reduced power" support for PLMN selection, "reduced power" cell reselection, and "reduced power" cell camping. The term "reduced power" and the term "multi-SIM power saving" mode can be used interchangeably in this specification. In addition to the reduced power operation, the FULL_RRC_IDLE state 1501 can be further described as follows.

[0117] SIM-specific DRX can be configured by the upper layer. Further, UE-specific DRX can be configured by the upper layer. In this case, the UE can provide the network with SIM-specific DRX or UE-specific DRX.

[0118] UE control mobility based on network configuration, or reduced power UE control mobility based on UE capabilities, user preferences, and network configuration,

[0119] The UE of each serving SIM can perform the following.

[0120] Maintain at least one P-RNTI for each of the serving networks associated with the SIM in the UE. Further, the UE can maintain a common P-RNTI via the serving network regardless of the SIM associated with the serving network.

[0121] Monitor short messages transmitted with the P-RNTI via DCI.

[0122] Maintain 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.

[0123] Monitor the paging channel for CN paging using the 5G-S-TMSI. The monitoring of paging can be performed using the multi-SIM non-power-saving mode or the multi-SIM power-saving mode.

[0124] Perform adjacent cell measurements and cell (re)selection as necessary, taking into account UE operations and SIM-level states for other SIMs. The cell measurements and cell (re)selection can be performed using the multi-SIM non-power-saving mode or the multi-SIM power-saving mode.

[0125] Obtain system information and can send an SI request (if configured). The acquisition of system information or the transmission of the SI request can be performed using the multi-SIM non-power-saving mode or the multi-SIM power-saving mode.

[0126] FULL RRC INACTIVE1502: In this state, the UE is in the SIM-level RRC INACTIVE state for each of the SIMs in the UE. In the FULL RRC_INACTICE state 1502, the UE can 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 can be further described as follows.

[0127] The SIM-specific DRX can be configured by the upper layer. Further, the UE-specific DRX can be configured by the upper layer. In this case, the UE can provide the SIM-specific DRX or the UE-specific DRX to the network.

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

[0129] The UE stores a dedicated UE inactive AS context and a common UE inactive AS context, i.e., contexts related to both DeRRC and CoRRC.

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

[0131] The UE of each serving SIM can perform the following.

[0132] Maintain at least one P-RNTI for each serving network associated with the SIM in the UE. Further, the UE can maintain a common P-RNTI via the serving network regardless of the SIM with which the serving network is associated, e.g., in the case of RAN sharing.

[0133] Monitor short messages transmitted with the P-RNTI via DCI.

[0134] Maintain at least one 5G-S-TMSI, i.e., at least one 5G-S-TMSI for each serving network associated with the SIM in the UE.

[0135] Using the 5G-S-TMSI, monitor the paging channel for CN paging in either case, and the paging monitoring can be performed using the multi-SIM non-power-saving mode or the multi-SIM power-saving mode.

[0136] Perform neighboring cell measurements and cell (re)selection, and the cell measurements and cell (re)selection can be performed using the multi-SIM non-power-saving mode or the multi-SIM power-saving mode.

[0137] Perform RAN-based notification area updates periodically and when moving outside the configured RAN-based notification area. The RAN-based notification area updates can be performed using the multi-SIM non-power-saving mode or the multi-SIM power-saving mode.

[0138] Obtain system information and send an SI request (if configured). The acquisition of system information or the transmission of the SI request can be performed using the multi-SIM non-power-saving mode or the multi-SIM power-saving mode.

[0139] The UE can transition from this state to MIXED_RRC_INACTIVE_CONNECTED1504 or MIXED_RRC_IDLE_INACTIVE1505. Note that for the rest of this document, the UE-level state transition is described for one SIM-level state transition at a time.

[0140] Transition to MIXED_RRC_INACTIVE_CONNECTED1504: When the UE transitions to SIM-level RRC_CONNECTED for one of the SIMs in the UE, the UE can transition from FULL_RRC_INACTIVE1502 to this state.

[0141] Transition to MIXED_RRC_IDLE_INACTIVE1505: When the UE transitions to SIM-level RRC_IDLE for one of the SIMs in the UE, the UE can transition from FULL_RRC_INACTIVE1502 to this state.

[0142] FULL RRC CONNECTED1503: In this state, the UE is in the SIM-level RRC_CONNECTED state for each of the SIMs within the UE. In this state, the UE stores the dedicated AS context and the common AS context, and the common AS context relates to context information via the serving network associated with the SIM within the UE. The UE can transition from this state to the MIXED RRC_IDLE_CONNECTED state 1506 or the MIXED_RRC_INACTIVE_CONNECTED state 1504.

[0143] 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 can transition from the FULL_RRC_CONNECTED state 1503 to this state. The UE can execute RRC_IDLE mode procedures specific to the multi-SIM power-saving mode or the multi-SIM non-power-saving mode, for example, based on the network configuration or UE preference settings.

[0144] 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 can transition from the FULL_RRC_CONNECTED state 1503 to this state. The UE can execute RRC_INACTIVE mode procedures specific to the multi-SIM power-saving mode or the multi-SIM non-power-saving mode, for example, based on the network configuration or UE preference settings.

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

[0146] Transition to the FULL_RRC_CONNECTED state 1503: When the UE transitions to the SIM-level RRC_CONNECTED for the only SIM that was in the SIM-level RRC_IDLE state, the UE can transition from the MIXED_RRC_IDLE_CONNECTED state 1506 to this state.

[0147] Transition to the FULL_RRC_IDLE state 1501: When the UE transitions to the SIM-level RRC_IDLE for the only SIM that was in the SIM-level RRC_CONNECTED state, the UE can transition from the MIXED_RRC_IDLE_CONNECTED state 1506 to this state.

[0148] Transition to the MIXED RRC_IDLE_INACTIVE state 1505: When the UE transitions to the SIM-level RRC_INACTIVE for the only SIM that was in the SIM-level RRC_CONNECTED state, the UE can transition from the MIXED_RRC_IDLE_CONNECTED state 1506 to this state.

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

[0150] 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 the SIMs are not in the RRC_IDLE state. For the SIMs in the RRC_INACTIVE state, the UE can execute RRC_INACTIVE mode procedures specific to the multi-SIM power-saving mode or the multi-SIM non-power-saving mode, for example, based on the network configuration or UE preference settings 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.

[0151] Transition to FULL_RRC_CONNECTED state 1503: For the only SIM for which the UE was in the SIM-level RRC_INACTIVE state, when the UE transitions to the SIM-level RRC_CONNECTED state, the UE may transition from the MIXED_RRC_INACTIVE_CONNECTED state 1504 to this state.

[0152] Transition to FULL_RRC_INACTIVE state 1502: For the only SIM for which the UE was in the SIM-level RRC_CONNECTED state, when the UE transitions to the SIM-level RRC_INACTIVE state, the UE may transition to this state from the MIXED_RRC_INACTIVE_CONNECTED state 1504.

[0153] Transition to MIXED_RRC_IDLE_INACTIVE state 1505: For the only SIM for which the UE was in the SIM-level RRC_CONNECTED state, when the UE transitions to the SIM-level RRC_INACTIVE state, the UE may transition to this state from the MIXED_RRC_INACTIVE_CONNECTED state 1504.

[0154] Transition to MIXED_RRC_IDLE_CONNECTED state 1506: For the only SIM for which the UE was in the SIM-level RRC_INACTIVE state, when the UE transitions to the SIM-level RRC_IDLE state, the UE may transition to this state from the MIXED_RRC_INACTIVE_CONNECTED state 1504.

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

[0156] MIXED RRC IDLE_INACTIVE1505: In this state, the UE is in the SIM-level RRC_IDLE state for one or more SIMs, in the SIM-level RRC_INACTIVE state for one or more SIMs, and the SIMs are not in the RRC_CONNECTED state. The UE can execute RRC_IDLE mode procedures or RRC_INACTIVE mode procedures specific to the multi-SIM power saving mode or multi-SIM non-power saving mode, for example, based on the network configuration or UE preference settings as described in this document. The UE can transition from this state to the FULL_RRC_IDLE state 1501, MIXED_RRC_IDLE_CONNECTED state 1506, MIXED_RRC_INACTIVE_CONNECTED1507, or MIXED_RRC_IDLE_INACTIVE_CONNECTED state.

[0157] Transition to the FULL_RRC_IDLE state 1501: When the UE transitions to the SIM-level RRC_IDLE state for the only SIM that was in the SIM-level RRC_INACTIVE state, the UE can transition from the MIXED_RRC_IDLE_INACTIVE state 1505 to this state.

[0158] Transition to the MIXED_RRC_IDLE_CONNECTED state 1506: When the UE transitions to the SIM-level RRC_CONNECTED state for the only SIM that was in the SIM-level RRC_INACTIVE state, the UE can transition from the MIXED_RRC_IDLE_INACTIVE state 1505 to this state.

[0159] Transition to the MIXED_RRC_INACTIVE_CONNECTED state 1504: When the UE transitions to the SIM-level RRC_CONNECTED state for the only SIM that was in the SIM-level RRC_IDLE state, the UE can transition from the MIXED_RRC_IDLE_INACTIVE state 1505 to this state.

[0160] Transition to MIXED_RRC_IDLE_INACTIVE_CONNECTED state 1507: When the UE transitions to the SIM-level RRC_CONNECTED state for one of the SIMs for which the UE was in the SIM-level RRC_INACTIVE state or for one of the SIMs for which the UE was in the SIM-level RRC_IDLE state, the UE may transition from the MIXED_RRC_IDLE_INACTIVE state 1505 to this state.

[0161] MIXED_RRC_IDLE_INACTIVE_CONNECTED state 1507: In this state, the UE is in the SIM-level RRC_IDLE state for one or more SIMs, 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. The UE can execute RRC_IDLE mode procedures or RRC_INACTIVE mode procedures specific to the multi-SIM power-saving mode or the multi-SIM non-power-saving mode, for example, based on the network configuration or UE preference settings as described in this document. The UE may transition from this state to one of the above mixed RRC states. For example, the UE may transition from this state to the MIXED RRC_INACTIVE_CONNECTED state 1504, the MIXED RRC_IDLE_CONNECTED state 1506, or the MIXED RRC_IDLE_INACTIVE state 1505.

[0162] Transition to MIXED RRC_INACTIVE_CONNECTED state 1504: When the UE transitions to the SIM-level RRC_CONNECTED state for the only SIM for which the UE was in the SIM-level RRC_IDLE state, the UE may transition from the MIXED_RRC_IDLE_INACTIVE_CONNECTED state 1507 to this state.

[0163] Transition to MIXED RRC_IDLE_CONNECTED state 1506: For the only SIM for which the UE is in the SIM-level RRC_INACTIVE state, when the UE transitions to the SIM-level RRC_CONNECTED state, or for the only SIM for which the UE is in the SIM-level RRC_INACTIVE state, when the UE transitions to the SIM-level RRC_IDLE state, the UE may transition to this state from the MIXED_RRC_IDLE_INACTIVE_CONNECTED state 1507.

[0164] Transition to MIXED RRC_IDLE_INACTIVE state 1505: For the only SIM for which the UE is in the SIM-level RRC_CONNECTED state, when the UE transitions to the SIM-level RRC_INACTIVE state, or for the only SIM for which the UE is in the SIM-level RRC_CONNECTED state, when the UE transitions to the SIM-level RRC_IDLE state, or for the only SIM for which the UE is in the SIM-level RRC_CONNECTED state, when the UE transitions to the SIM-level RRC_IDLE state, the UE may transition to this state from the MIXED_RRC_IDLE_INACTIVE_CONNECTED state 1507.

[0165] Figure 16 shows the UE-level CoNAS state machine 1600. The CoNAS state machine of a multi-SIM UE can be designed to reduce any increase in power consumption and avoid shortening the UE battery life as a result of the multi-SIM operation mode. The CoNAS state machine may have FULL RM-DEREGISTERED 1601, SINGLE RM-REGISTERED 1602, and MULTIPLE RM-REGISTERED states 1603. The states can generally be distinguished or characterized by the amount of arbitration that the CoNAS entity has to perform between DeNAS entities. The arbitration performed by the CoNAS entity is relevant when each DeNAS entity is permitted to use a transceiver to send or receive NAS signaling. One CoNAS state machine can be maintained by the CoNAS of each transceiver.

[0166] The Power Saving Mode (PSM) and Extended Idle Mode DRX parameters can be proposed by the UE to the network in the registration procedure. The DeNAS entity can provide the values to the CoNAS entity before the values are provided to the network, and the CoNAS can propose new values or approve the values. For example, the CoNAS entity can propose a longer periodic registration timer or a shortened active timer to increase the possibility that the DeNAS state can be CM-IDLE for a longer period. Alternatively, the CoNAS entity can propose a timer that is better adjusted with the timers of other DeNAS entities to avoid situations where the DeNAS entities are required to perform functions simultaneously.

[0167] The states of the CoNAS state machine are described below. As described above, these states are related to a single RAT (i.e., non-3GPP or 3GPP).

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

[0169] While in this state, the CoNAS entity can receive requests from any DeNAS entity for permission to send a registration request on the associated RAT. The CoNAS entity can typically grant this request because the RM states of other DeNAS state machines are currently not RM REGISTERED for the associated RAT, and thus, no arbitration of NAS functions is necessary.

[0170] Upon receiving an indication from a DeNAS entity that it is now RM-REGISTERED on the associated RAT, the CoNAS entity can transition to the SINGLE RM-REGISTERED state 1602. This transition is shown in step 1 of Figure 16.

[0171] SINGLE RM-REGISTERED1602: In this state, only the RM state of one DeNAS entity is RM-REGISTERED on the associated RAT (i.e., 3GPP or non-3GPP), and the rest are RM-DEREGISTERED on the associated RAT. In this state, the CoNAS entity does not need to perform any arbitration function until the RM state machine associated with a second DeNAS entity indicates a desire to initiate a registration regarding the associated RAT. The SINGLE RM-REGISTERED state 1602 can be further characterized as follows.

[0172] While in this state, the CoNAS entity can receive requests from the DeNAS entity that is RM-REGISTERED in the associated RAT for permission to send NAS message requests (e.g., mobility registration updates, periodic registration updates, service requests, or UE configuration updates). The CoNAS entity can typically permit this request because the RM states of other DeNAS state machines are currently not RM REGISTERED in the associated RAT, and thus, arbitration of NAS functions is not necessary.

[0173] While in this state, the CoNAS entity can receive requests from the DeNAS entity, whose RM state is RM-DEREGISTERED in the associated RAT for permission to send an initial registration request in the associated RAT. The CoNAS entity can indicate to the DeNAS the time during which the request is permitted, and CoNAS can indicate to other DeNAS entities (which may have RM state machines that are RM-REGISTERED) that they should not simultaneously initiate new NAS activities in the associated RAT.

[0174] Note that if the DeNAS entity can receive a notification that a different DeNAS entity can use the associated RAT at a particular time, the DeNAS can release the AN signaling connection and thus transition the CM state of the DeNAS to CM-IDLE.

[0175] If the DeNAS entity that was RM-REGISTERED in the associated RAT now indicates that it is RM-DEREGISTERED in the associated RAT, the CoNAS entity can transition to the FULL RM-DEREGISTERED state 1601. This transition is shown in step 2 of FIG. 16.

[0176] If a DeNAS entity that was not RM-REGISTERED with an associated RAT now indicates that it is RM-REGISTERED with the associated RAT, the CoNAS entity may transition to the MULTIPLE RM-REGISTERED state 1603. This transition is shown in step 3 of FIG. 16.

[0177] Note that if the CoNAS entity notifies the DeNAS entity that it can perform some operations (e.g., periodic registration updates), the CoNAS entity can also indicate to the DeNAS entity that the DeNAS entity is only permitted to perform certain operations and is not permitted to perform additional activities (e.g., establish a PDU session, transmit UL data, or receive downlink data). Since the DeNAS entity is waiting to perform some higher-priority activities, the CoNAS entity can indicate this to the DeNAS layer. Thus, when performing a periodic registration update, DeNAS can indicate to the network that it is performing a periodic registration update but cannot perform other operations at this time (i.e., receive DL data). The UE can indicate this state by providing a PSM active timer value of 0 during a periodic registration. Thus, it indicates that it immediately enters CM-IDLE again.

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

[0179] While in this state, the CoNAS entity can receive requests from the DeNAS entity that has an RM state machine that is RM-REGISTERED in the associated RAT, for permission to send NAS message requests (e.g., mobility registration update, periodic registration update, service request, or UE configuration update). The CoNAS entity can indicate to the requesting DeNAS entity the time during which it is permissible to send the request in the associated RAT, and can indicate to other DeNAS entities that no new NAS activity should be initiated simultaneously in the associated RAT.

[0180] Note that requests from the DeNAS entity to the CoNAS entity for sending periodic registration updates can be based on the expiration approaching of the periodic registration update timer.

[0181] Note that requests from the DeNAS entity to the CoNAS entity for sending mobility registration updates can be based on mobility events.

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

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

[0184] Note that if the DeNAS entity can receive a notification that a different DeNAS entity can use the associated RAT at a particular time, the DeNAS can release the AN signaling connection and thus transition the CM state of the DeNAS to CM-IDLE.

[0185] While in this state, the CoNAS entity can receive requests from the DeNAS entity, and its RM state is RM-DEREGISTERED in the associated RAT for permission to send a registration request. The CoNAS entity can indicate to the DeNAS the time during which it is allowed to send requests in the associated RAT, and the CoNAS can indicate to other DeNAS entities (which may have an RM state machine that is RM-REGISTERED) that they should not simultaneously initiate a new NAS activity in the associated RAT.

[0186] Note that if the DeNAS entity can receive a notification that a different DeNAS entity can use the associated RAT at a specific time, the DeNAS can release the AN signaling connection and thus transition the CM state of the DeNAS to CM-IDLE.

[0187] If a DeNAS entity with an RM state machine that is RM-REGISTERED in the associated RAT indicates to the CoNAS entity that it is RM-DEREGISTERED in the associated RAT, the CoNAS entity can transition to the SINGLE RM-REGISTERED state 1602 if there is only one DeNAS entity with an RM state machine that is RM-REGISTERED in the associated RAT. This transition is shown in step 4 of FIG. 16.

[0188] When the CoNAS entity notifies the DeNAS entity that it can perform some operations (e.g., periodic registration updates), the CoNAS entity can also indicate to the DeNAS entity that the DeNAS entity is only permitted to perform specific operations and is not permitted to perform additional activities (e.g., establish a PDU session, transmit UL data, or receive downlink data). Note that since the DeNAS entity is waiting to perform some higher-priority activities, the CoNAS entity can indicate this to the DeNAS layer. Therefore, when performing a periodic registration update, DeNAS can indicate to the network that it is performing a periodic registration update but cannot perform other operations at this time (i.e., receive DL data). The UE can indicate this state by providing a PSM active timer value of 0 during a periodic registration. Therefore, it indicates immediately entering CM-IDLE.

[0189] Procedures for enabling TDM sharing of the RX / TX chain are described herein according to another embodiment. To maintain simultaneous UL / DL communication with multiple PLMNs for a multi-SIM device equipped with a single RX and single TX chain or dual RX and single TX chains, AS procedures for enabling sharing of the RX / TX chain in a TDM manner are proposed herein. Signaling at the AS layer inside the UE and / or between the UE and the network is used to coordinate communication with multiple PLMNs. For illustrative purposes, a scenario where the UE is composed of two SIMs, namely SIM1 and SIM2, is considered herein, but the solution described herein can be extended to configurations with more than two SIMs.

[0190] Various classes of solutions can be envisaged, and the type of solution depends on the number of RX / TX chains, the length of the gap required in UL / DL communication using the first PLMN to support UL / DL transmission using the second PLMN, and / or the level of coordination between network nodes of the PLMN.

[0191] In scenarios where short gaps (e.g., 10 - 100 ms) or very short gaps (e.g., <10 ms) in UL / DL transmission using the first PLMN are required to support UL / DL transmission using the second PLMN, classes of solutions enabling dynamic sharing of RX / TX chains can be used. Further optimizations in these solutions can be obtained when coordination between network nodes of multiple PLMNs is possible (e.g., within an MNO or in a RAN sharing deployment).

[0192] In scenarios where long gaps (e.g., >100 ms) in UL / DL transmission using the first PLMN are required to support UL / DL transmission using the second PLMN, classes of solutions enabling quasi - static sharing of RX / TX chains can be used. This class of solution can also be applied to other scenarios such as when UL / DL transmission using the second PLMN has low tolerance or when coordination between network nodes of multiple PLMNs is not possible (e.g., inter - MNO deployment).

[0193] Figure 17 shows the dynamic sharing of the RX / TX chain with the RX / TX chain arbiter 1700. In one class of solutions, the RX / TX chain arbiter 1702 is used to enable TDM access to the shared RX / TX chain. Before an RXOP or TXOP, the AS (e.g., dedicated AS 1701 or dedicated AS 1702) requests the RX / TX chain arbiter 1702 to access the shared RX / TX chain. The RX / TX chain arbiter 1702 can provide the AS with a response indicating whether access to the shared RX / TX chain has been permitted. Hereinafter, the terms "RX / TX chain arbiter" and "arbiter function" may be used interchangeably. In one embodiment, the arbiter function may be implemented by the RRC layer, the MAC layer, or the PHY layer. In another embodiment, the arbiter function may be implemented by the NAS layer.

[0194] Access to the RX / TX chain may be permitted in a first-come, first-served manner by the RX / TX chain arbiter 1702. Alternatively, it may be prioritized based on the USIM identifier, the priority of the service for which access is requested, the MAC procedure for which access is requested, etc.

[0195] The request provided by the AS to the RX / TX chain arbiter 1702 may indicate the time when access to the RX / TX chain is desired and the period for which access is desired, such as start time and duration, start time and end time, etc. The request may also include an indication of the access priority. The AS can determine when an RXOP occurs based on the configured CORESET, search space, SPS configuration, DRX configuration, etc. The AS can determine when a TXOP occurs based on dynamic or configured grants, PUCCH opportunities, RACH opportunities, etc.

[0196] The response provided by the RX / TX chain arbiter 1702 to the AS indicates whether access has been permitted, e.g., a boolean flag where TRUE indicates that access has been permitted and FALSE indicates that access has not been permitted.

[0197] When access to the shared RX / TX chain is permitted, DL is monitored during RXOP or UL is transmitted during TXOP. When access to the shared RX / TX chain is not permitted, the AS procedure can be adapted to take into account the missing RXOP / TXOP.

[0198] In scenarios where access to the RX / TX chain can be pre-determined based on traffic patterns and / or AS configuration, explicit requests / responses may not be provided for each access attempt. Instead, the RX / TX chain arbiter may provide relevant information and when such an event occurs, an indication of the missing RXOP / TXOP can be provided to the dedicated AS that results.

[0199] An indication of the missing RXOP / TXOP can also be provided to the network. The indication is provided to the network during the TXOP that proceeds the occurrence of the missing RXOP / TXOP, enabling the network to take proactive actions to handle the missing RXOP / TXOP. Alternatively, the UE can provide the indication during a subsequent TXOP, enabling the network to take reactive actions to the missing RXOP / TXOP. Also, in another alternative, to reduce the signaling overhead associated with providing an explicit indication of the missing RXOP / TXOP, the UE can provide the network with a schedule for access to the RX / TX chain, such that the network can predict when a missing RXOP / TXOP can occur.

[0200] The RX / TX chain arbiter can support preemption. For example, in a scenario where access is priority-based, the RX / TX chain arbiter may be able to interrupt an access that is pending or in progress by a higher-priority access. When such an interruption occurs, the RX / TX chain arbiter 1702 can provide an indication to the interrupted dedicated AS to handle the interruption accordingly.

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

[0202] FIG. 18 shows an interface 1800 between the AS and the RX / TX chain arbiter. 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, which is implemented within the CoMAC and can request access to the shared RX / TX chain. The internal signaling of the MAC can be used to adapt the behavior of the MAC procedure when an indication of a missing RXOP / TXOP is received from the RX / TX chain arbiter.

[0203] FIG. 19 shows an exemplary interface between the AS and the RX / TX chain arbiter according to another embodiment. In the example of FIG. 19, 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. The PHY can provide the MAC with an indication of a missing RXOP / TXOP 1910 if access to the shared RX / TX chain is not permitted, and the MAC procedure is adapted to take into account the missing RXOP / TXOP. Alternatively, an indication that access to the RX / TX chain has been permitted can be provided instead. In yet another alternative, both types of indications can be provided.

[0204] Figure 20 shows another exemplary interface 2000 between an AS and an RX / TX chain arbiter according to another embodiment. In the example of Figure 20, 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, 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, 2004 to request access to the shared RX chain and the MAC. For example, a HARQ entity interfaces with the RX / TX chain arbiter to request access to the TX chain.

[0205] Figure 21 shows an exemplary signaling diagram 2100 for dynamic sharing of an RX / TX chain using an RX / TX chain arbiter. In the text used to explain the steps of the signaling diagram, the notation 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.

[0206] Referring to Figure 21, AS1 can request access to the RX chain (step 1). The RX / TX chain arbiter can determine that the RX is available during the requested RXOP and can provide a response indicating that access is granted (step 2). AS1 can receive DL transmissions from the gNB during the requested RXOP (step 3). AS1 can request access to the TX chain (step 4). The RX / TX chain arbiter can determine that the TX is available during the requested TXOP and can provide a response indicating that access is granted (step 5). AS1 can transmit UL to the gNB during the requested TXOP A (step 6). AIt can be transmitted to (Step 6). AS2 can request access to the TX chain (Step 7). The RX / TX chain arbiter can determine that the TX may be available during the requested TXOP and can provide a response indicating that access is permitted (Step 8). AS2 can transmit the UL to the gNB during the requested TXOP B It can be transmitted to (Step 9).

[0207] Figure 22 shows an exemplary signaling diagram 2200 for dynamic sharing of the RX / TX chain using the RX / TX chain arbiter, and the PHY layer of each dedicated AS is interfaced with the RX / TX chain arbiter. Referring to Figure 22, the PHY of AS1 can request access to the RX chain (Step 1). The RX / TX chain arbiter can determine that the RX may be available during the requested RXOP and can provide a response indicating that access is permitted (Step 2). The PHY of AS1 can receive the DL transmission from the gNB during the requested RXOP A (Step 3). The PHY of AS1 can transmit the received MAC PDU to the MAC of AS1 (Step 4). The MAC of AS1 can transmit the MAC PDU to the PHY of AS1 (Step 5). The MAC of AS1 can transmit the UL grant to the PHY of AS1 (Step 6). The PHY of AS1 can request access to the TX chain (Step 7). The RX / TX chain arbiter can determine that the TX may be available during the requested TXOP and can provide a response indicating that access is permitted (Step 8). The PHY of AS1 can transmit the UL to the gNB during the requested TXOP AIt can be transmitted to (step 9). The MAC of AS2 can transmit the MAC PDU to the PHY of AS2 (step 10). The MAC of AS2 can transmit the UL grant to the PHY of AS2 (step 11). The PHY of AS2 can request access to the TX chain (step 12). The RX / TX chain arbiter can determine that the TX may be available during the requested TXOP and can provide a response indicating that access is permitted (step 13). The PHY of AS2 can transmit the UL to the gNB B during the requested TXOP (step 14).

[0208] Figure 23 shows a signaling diagram 2300 for dynamic sharing of the RX / TX chain using the RX / TX chain arbiter when missing RXOPs and TXOPs occur. Referring to Figure 23, AS2 can request access to the RX chain (step 1). The RX / TX chain arbiter can determine that the RX may be available during the requested RXOP and can provide a response indicating that access is permitted (step 2). AS1 can request access to the RX chain (step 3). The RX / TX chain arbiter can determine that the RX may not be available during the requested RXOP and can provide a response indicating that access is not permitted (step 4). AS1 adapts the AS procedure to account for the missing RXOP (step 5). AS2 can receive the DL transmission from the gNB B during the requested RXOP (step 6). AS1 can request access to the RX chain (step 7). The RX / TX chain arbiter can determine that the RX may be available during the requested RXOP and can provide a response indicating that access is permitted (step 8). AS1 can receive the gNB AIt can receive DL transmissions from (step 9). AS1 can request access to the TX chain (step 10). The RX / TX chain arbiter can determine that the TX may be available during the requested TXOP and can provide a response indicating that access is permitted (step 11). AS2 can request access to the TX chain (step 12). The RX / TX chain arbiter can determine that the TX may not be available during the requested TXOP and can provide a response indicating that access is not permitted (step 13). AS2 adapts the AS procedure to account for the missing TXOP (step 14). AS1 can transmit the UL to the gNB A during the requested TXOP (step 15). AS2 can request access to the TX chain (step 16). The RX / TX chain arbiter can determine that the TX may be available during the requested TXOP and can provide a response indicating that access is permitted (step 17). AS2 can transmit the UL to the gNB B during the requested TXOP (step 18).

[0209] FIG. 24 shows a signaling diagram 2400 for dynamic sharing of an RX / TX chain using an RX / TX chain arbiter when a missing RXOP and TXOP occur. The PHY layer of each dedicated AS interfaces with the RX / TX chain arbiter. Referring to FIG. 24, the PHY of AS2 can request access to the RX chain (step 1). The RX / TX chain arbiter can determine that the RX may be available during the requested RXOP and can provide a response indicating that access is permitted (step 2). The PHY of AS1 can request access to the RX chain (step 3). The RX / TX chain arbiter can determine that the RX may not be available during the requested RXOP and can provide a response indicating that access is not permitted (step 4). The PHY of AS1 can provide the missing RXOP indicator to the MAC of AS1 (step 5). The MAC of AS1 adapts the MAC procedure to account for the missing RXOP (step 6). The PHY of AS2 can receive DL transmissions from the gNB during the requested RXOP B (step 7). The PHY of AS2 can transmit the received MAC PDU to the MAC of AS2 (step 8). The PHY of AS1 can request access to the RX chain (step 9). The RX / TX chain arbiter can determine that the RX may be available during the requested RXOP and can provide a response indicating that access is permitted (step 10). The PHY of AS1 can receive DL transmissions from the gNB during the requested RXOP AIt can receive DL transmissions from (step 11). The PHY of AS1 can send the received MAC PDU to the MAC of AS1 (step 12). The MAC of AS1 can send the MAC PDU to the PHY of AS1 (step 13). The MAC of AS1 can send a UL grant to the PHY of AS1 (step 14). The PHY of AS1 can request access to the TX chain (step 15). The RX / TX chain arbiter can determine that the TX may be available during the requested TXOP and can provide a response indicating that access is permitted (step 16). The MAC of AS2 can send the MAC PDU to the PHY of AS2 (step 17). The MAC of AS2 can send a UL grant to the PHY of AS2 (step 18). The PHY of AS2 can request access to the TX chain (step 19). The RX / TX chain arbiter can determine that the TX may not be available during the requested TXOP and can provide a response indicating that access is not permitted (step 20). The PHY of AS2 can provide the missing TXOP indicator to the MAC of AS2 (step 21). The MAC of AS2 adapts the MAC procedure to take into account the missing TXOP (step 22). The PHY of AS1 can transmit UL to gNB A during the requested TXOP (step 23). The MAC of AS2 can send the MAC PDU to the PHY of AS2 (step 24). The MAC of AS2 can send a UL grant to the PHY of AS2 (step 25). The PHY of AS2 can request access to the TX chain (step 26). The RX / TX chain arbiter can determine that the TX may be available during the requested TXOP and can provide a response indicating that access is permitted (step 27). The PHY of AS2 can transmit UL to gNB B during the requested TXOP (step 28).

[0210] Semi-static sharing of the RX / TX chain is described herein in another class of solutions. Semi-static sharing of the RX / TX chain can be achieved by interrupting or releasing the RRC connection.

[0211] 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 reason for establishing the RRC configuration request from a higher upper layer, the QoS or priority of the logical channels or radio bearers configured for the AS connection, the procedures currently being executed by the AS connection, for example, random access, beam failure detection and recovery.

[0212] Figure 25 shows the procedure used for the RRC interruption to enable semi-static sharing of the RX / TX chain 2500. Referring to Figure 25, the upper layer (e.g., NAS) can request that an RRC connection be established for SIM1 (step 1). The DeRRC of SIM1 can request to establish a new RRC connection (step 2). The CoRRC can determine that it can establish the RRC connection (step 3). The CoRRC can provide a response indicating that the request has been granted (step 4). The DeRRC of SIM1 can establish an RRC connection with the gNB A (step 5). The DeRRC can establish an RRC connection with the gNB AIt can perform UL / DL communication with (Step 6). The upper layer (e.g., NAS) can request that an RRC connection be established for SIM2 (Step 7). The DeRRC of SIM2 can request to establish a new RRC connection (Step 8). CoRRC can determine that it is necessary to interrupt the RRC connection of SIM1 before the RRC connection of SIM2 can be established (Step 9). CoRRC can provide a response to the DeRRC of SIM1 indicating that the RRC connection needs to be interrupted (Step 10). The dedicated sublayer of SIM1 can interrupt the RRC connection (Step 11). CoRRC can provide a response to the DeRRC of SIM2 indicating that the request to establish a new RRC connection has been permitted (Step 12). The DeRRC of SIM2 establishes an RRC connection with the gNB B (Step 13). The DeRRC can perform UL / DL communication with the gNB B (Step 14).

[0213] Figure 26 shows an exemplary procedure 2600 in which another aspect of solution RRC release can be used to enable semi-static sharing of the RX / TX chain. Referring to Figure 26, the upper layer (e.g., NAS) can request that an RRC connection be established for SIM1 (Step 1). The DeRRC of SIM1 can request to establish a new RRC connection (Step 2). CoRRC can determine that it can establish the RRC connection (Step 3). CoRRC can provide a response indicating that the request has been permitted (Step 4). The DeRRC of SIM1 establishes an RRC connection with the gNB A (Step 5). The DeRRC can perform UL / DL communication with the gNB AUL / DL communication with it can be executed (step 6). The upper layer (e.g., NAS) can request that an RRC connection be established for SIM2 (step 7). The DeRRC of SIM2 can request to establish a new RRC connection (step 8). CoRRC can determine that it is necessary to release the RRC connection of SIM1 before establishing the RRC connection of SIM2 (step 9). CoRRC can provide a response to the DeRRC of SIM1 indicating that it is necessary to release the RRC connection of SIM1 (step 10). The dedicated sublayer of SIM1 can release the RRC connection (step 11). The dedicated sublayer of SIM1 can notify the upper layer that the RRC connection has been released (step 12). CoRRC can provide a response to the DeRRC of SIM2 indicating that the request to establish a new RRC connection has been permitted (step 13). The DeRRC of SIM2 can B establish an RRC connection with gNB (step 14). The DeRRC can B execute UL / DL communication with gNB (step 15).

[0214] The effect of sharing the RX / TX chain on the MAC is described herein. The solutions described herein are applied to the overall MAC operation, specifically, MAC procedures that depend on timers and counters, to control their behavior. Such MAC procedures include, but are not limited to, random access, maintenance of uplink time alignment, UL / DL HARQ operation, scheduling requests, buffer status reports, power headroom reports, discontinuous reception, activation / deactivation of SCell, bandwidth part operation, and beam failure detection and recovery. Missing RXOP / TXOPs can have unwanted and unintended effects on these MAC procedures. With knowledge of the missing RXOP / TXOPs, these MAC procedures can operate in the same manner as their operation when RX / TX chain sharing is not required.

[0215] Regarding the effect on the MAC procedure, the impact of sharing the RX / TX chain is considered for both UL and DL. Depending on the MAC procedure, it is possible to consider both the missing RXOP and TXOP, or only the missing RXOP or TXOP. How access is required for the shared RX chain and TX chain can vary.

[0216] The UE can perform sharing of the TX chain, according to which, if access to the shared TX chain is not permitted, transmission is not performed. When access to the shared TX chain is required before transmission, an indicator regarding whether the access is permitted is provided to the MAC entity. Unless otherwise specified, the MAC entity considers that the transmission has been performed regardless of the access request result. In the case of a transmission where the access request is not performed, the access request is considered to be permitted.

[0217] It is described herein to notify the NW of the missing RXOP / TXOP. In a scenario where pre-determination of the missing RXOP / TXOP is possible, the UE can transmit an indicator to the network to notify the possible missing RXOP / TXOP, thereby enabling the adaptation of the MAC behavior to be adjusted between the network and the UE. The way the MAC behavior is adapted can be predetermined / pre-configured, and the indicator from the UE can be used to trigger when the adaptation can occur. Alternatively, the indicator can be composed of information notifying the network of how the UE can adapt the MAC behavior. In yet another alternative, the way the MAC procedure is adapted can be negotiated between the network and the UE.

[0218] In a scenario where pre-determination of the missing RXOP is not possible, but the TX chain is available when the missing RXOP occurs, if the UL resources scheduled via dynamic permission are not available, the indicator of the missing RXOP can be transmitted using pre-configured UL resources (e.g., via configured permission or PUCCH).

[0219] The effects on the MAC counter and timer are described herein. Sharing the RX / TX chain can result in the loss of RXOP and TXOP, which in turn results in a longer period to achieve successful transmission. The MAC procedure takes into account the number and / or period of opportunities for the procedure to complete before declaring a procedure failure. It is necessary to consider the missing RXOP and TXOP in order to properly execute the procedure when the RX / TX chain is shared.

[0220] For example, procedures such as random access, scheduling requests, and beam failure detection and recovery use counters to control how many unsuccessful attempts should occur before declaring a procedure failure. Incrementing such a counter should take into account the missing RXOP and TXOP to avoid declaring a failure too early.

[0221] Existing MAC procedures assume that UL transmission occurs when the PHY is instructed to perform a UL transmission for a MAC PDU or UCI (e.g., SR). To limit the transmission frequency of MAC CE and UCI using a specific MAC procedure, the prohibit timer is set to prevent retransmission of the MAC CE or UCI until the prohibit timer expires. To properly control the frequency at which the MAC CE or UCI is transmitted and to ensure that transmission occurs as needed, the setting of these prohibit timers needs to take into account the missing TXOP. For example, if the TXOP is missing and transmission did not occur, the timer should not be set.

[0222] The timer can be used to control when the UE monitors the DL for procedures such as random access and DRX. In scenarios where access to the RX chain is not permitted, monitoring the DL can result in unnecessary power consumption and should not be performed. Therefore, when determining whether to monitor the DL while such a timer is running, the missing RXOP should be considered. Further, in some scenarios, it may be appropriate to extend the timer considering the missing RXOP. To ensure that the timers maintained by the UE and the gNB are synchronized, the UE can provide an indication to the gNB that the timer has been extended. Alternatively, the UE can provide an indication requesting that the timer be extended, and then the network can provide an indication in the DL to confirm whether the request has been granted.

[0223] The effects due to lost TXOP are described herein. The MAC procedures should be taken into account when the UL transmission cannot be performed due to the missing TXOP. For example, if access to the shared TX chain is not permitted for the duration corresponding to the uplink grant indicated to the HARQ entity, no MAC PDU should be generated.

[0224] The effects on specific MAC procedures such as random access procedures and random access resource selection are described herein. The following procedures are proposed herein taking into account the effect of sharing the RX / TX chain.

[0225] After selecting a PRACH opportunity, the MAC entity can request access to the TX chain for the duration corresponding to the selected PRACH opportunity. If the access is not permitted, the MAC entity can select the next available PRACH opportunity and request access to the TX chain for the duration corresponding to the next available PRACH opportunity. This process can be repeated until access to the TX chain is permitted for the duration corresponding to one of the selected PRACH opportunities or until access to the TX chain fails for all PRACH opportunities. If access to the TX chain fails for all PRACH opportunities, the random access resource selection procedure is repeated. The MAC entity can delay executing the random access resource selection procedure until after the backoff time, which can be longer than the duration for which the TX chain is considered busy, i.e., the random access resource selection procedure is not executed until the TX chain is idle. Alternatively, a fixed or randomly selected backoff time can be used. The procedure can be defined to count the number of failed RX chain access requests or the number of consecutive failed RX chain access requests. The count can be determined over a configured duration, which can include infinity as a configuration option. If the count of (consecutive) failed RX chain access requests exceeds a configured threshold, the random access procedure is considered not to complete successfully, and the MAC entity can indicate the random access problem to the upper layer.

[0226] To implement this behavior, the procedure can be executed as follows.

[0227] 1) If ra-AssociationPeriodIndex and si-RequestPeriod are configured,

[0228] 2) When it is configured and when access to the TX chain is permitted, in the associated period given by ra-AssociationPeriodIndex of si-RequestPeriod permitted by the restriction given by ra-ssb-OccasionMaskIndex, determine the next available PRACH opportunity from the PRACH opportunities corresponding to the selected SSB (the MAC entity can randomly select a PRACH opportunity with the same probability from among the PRACH opportunities corresponding to the selected SSB).

[0229] 1) Otherwise, when the SSB is selected as above,

[0230] 2) When it is configured or indicated by PDCCH and when access to the TX chain is permitted, determine the next available PRACH opportunity from the PRACH opportunities corresponding to the selected SSB permitted by the restriction given by ra-ssb-OccasionMaskIndex (the MAC entity can randomly select a PRACH opportunity with the same probability from among consecutive PRACH opportunities corresponding to the selected SSB, and the MAC entity can take into account the possible occurrence of measurement gaps when determining the next available PRACH opportunity corresponding to the selected SSB).

[0231] 1) Otherwise, when CSI-RS is selected as above,

[0232] 2) When there is no contention-free random access resource associated with the selected CSI-RS,

[0233] 3) If it is configured corresponding to the SSB in the candidateBeamRSList that is quasi - co - located with the selected CSI - RS and access to the TX chain is permitted, and when determined by the restrictions given by ra - ssb - OccasionMaskIndex, determine the next available PRACH opportunity from the permitted PRACH opportunities (the MAC entity can randomly select a PRACH opportunity with the same probability from among the PRACH opportunities corresponding to the SSB that is quasi - co - located with the selected CSI - RS, and when the MAC entity determines the next available PRACH opportunity corresponding to the selected CSI - RS, it can take into account the possible occurrence of measurement gaps).

[0234] 2) Otherwise,

[0235] 3) Determine the next available PRACH opportunity from the PRACH opportunities in the ra - OccasionList corresponding to the selected CSI - RS and where access to the TX chain is permitted (the MAC entity can randomly select a PRACH opportunity with the same probability from among the PRACH opportunities corresponding to the selected CSI - RS that occur on different but simultaneous sub - carriers, and when the MAC entity determines the next available PRACH opportunity corresponding to the selected CSI - RS, it can take into account the possible occurrence of measurement gaps.

[0236] 1) If a PRACH opportunity is determined,

[0237] 2) Execute the random access preamble transmission procedure.

[0238] 1) Otherwise,

[0239] 2) NUM_FAILED_RX_CHAIN_ACCESS_REQUESTS>MAX_FAILED_TX_CHAIN_ACCESS_REQUESTS,

[0240] 3) If the random access resource selection is for the SpCell,

[0241] 4) Indicate a random access problem to the upper layer.

[0242] 4) If this random access procedure is triggered for an SI request,

[0243] 5) Consider that the random access procedure has not completed successfully.

[0244] 3) Otherwise, if the random access preamble is transmitted on the SCell,

[0245] 4) Consider that the random access procedure has not completed successfully.

[0246] 2) If the random access procedure has not completed,

[0247] 3) Select a backoff time that is longer than the duration for which access to the TX chain is not permitted.

[0248] 3) Execute the random access resource selection procedure after the backoff time.

[0249] To avoid repeated failures of the random access resource selection procedure due to inability to access the TX chain of the selected PRACH opportunity, the SSB or CSI-RS selected during a failed attempt of the random access resource selection procedure may be excluded as an option for selection in 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.

[0250] Random access preamble transmission

[0251] The following procedure is proposed in this specification taking into account the effect of sharing the RX / TX chain.

[0252] As an alternative to creating a request during the random access resource selection procedure, it is possible to request access to the TX chain during the random access preamble transmission procedure. If the access is not permitted, the MAC entity returns to the random access resource selection procedure without incrementing either the PREAMBLE_POWER_RAMPING_COUNTER or the PREAMBLE_TRANSMISSION_COUNTER.

[0253] For each random access preamble, the MAC entity

[0254] 1) If access to the TX chain is permitted for the duration corresponding to the selected PRACH opportunity,

[0255] 2) If the PREAMBLE_TRANSMISSION_COUNTER is greater than 1,

[0256] 2) If no notification to interrupt the power ramping counter has been received from the lower layer,

[0257] 2) If the selected SSB or CSI-RS has not been changed from the selection for the last random access preamble transmission,

[0258] 3) Increment the PREAMBLE_POWER_RAMPING_COUNTER by 1.

[0259] 2) Select the value of DELTA_PREAMBLE,

[0260] 2) Set PREAMBLE_RECEIVED_TARGET_POWER to preambleReceivedTargetPower + DELTA_PREAMBLE + (PREAMBLE_POWER_RAMPING_COUNTER - 1) × PREAMBLE_POWER_RAMPING_STEP,

[0261] 2) Calculate the RA-RNTI associated with the PRACH opportunity on which the random access preamble is transmitted, excluding the contention-free random access preamble for beam failure recovery.

[0262] 2) If available, instruct the physical layer to transmit the random access preamble using the selected PRACH opportunity corresponding to RA-RNTI, PREAMBLE_INDEX, and PREAMBLE_RECEIVED_TARGET_POWER.

[0263] 1) Otherwise,

[0264] 2) Execute the random access resource selection procedure.

[0265] Random access response reception

[0266] The following procedure is proposed in this specification taking into account the effect of sharing the RX / TX chain.

[0267] The start of the RAR window is conditional on obtaining access to the RX chain over the duration of the ra-ResponseWindow. If access is not granted, the random access response reception is considered unsuccessful and the MAC entity executes the random access resource selection procedure. The MAC entity can delay executing the random access resource selection procedure until after the backoff time, which can be longer than the duration for which the RX chain is considered busy, i.e., the random access resource selection procedure is not executed until the RX chain is idle. Alternatively, a fixed or randomly selected backoff time can be used.

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

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

[0270] 2) If access to the RX chain is permitted for a duration corresponding to the ra-ResponseWindow configured by BeamFailureRecoveryConfig starting from the first PDCCH opportunity after the end of the random access preamble transmission,

[0271] 3) Starting from the end of the random access preamble transmission, at the first PDCCH opportunity, start the ra-ResponseWindow configured by BeamFailureRecoveryConfig,

[0272] 3) While the ra-ResponseWindow is being executed, monitor PDCCH transmissions on the search space indicated by the recoverySearchSpaceId of the SpCell identified by the C-RNTI.

[0273] 1) Otherwise,

[0274] 2) If access to the RX chain is permitted for a duration corresponding to the ra-ResponseWindow configured by RACH-ConfigCommon starting from the first PDCCH opportunity after the end of the random access preamble transmission,

[0275] 3) Starting from the end of the random access preamble transmission, at the first PDCCH opportunity, start the ra-ResponseWindow configured by RACH-ConfigCommon,

[0276] 3) While the ra-ResponseWindow is being executed, monitor the PDCCH of the SpCell for random access response identified by the RA-RNTI.

[0277] 1) If the ra-ResponseWindow configured by BeamFailureRecoveryConfig expires and the PDCCH transmission on the search space indicated by the recoverySearchSpaceId addressed to the C-RNTI is not received on the serving cell where the preamble was transmitted, or

[0278] 1) If the ra-ResponseWindow configured by RACH-ConfigCommon expires and a random access response containing a random access preamble identifier that matches the transmitted PREAMBLE_INDEX is not received, or

[0279] 1) If access to the RX chain is not permitted,

[0280] 2) Consider that the random access response reception was not successful,

[0281] 2) Increment the PREAMBLE_TRANSMISSION_COUNTER by 1,

[0282] 2) If PREAMBLE_TRANSMISSION_COUNTER = preambleTransMax + 1,

[0283] 3) If the random access preamble is transmitted on the SpCell,

[0284] 4) Indicate a random access problem to the upper layer,

[0285] 4) If this random access procedure was triggered for an SI request,

[0286] 5) Consider that the random access procedure has not completed successfully.

[0287] 3) Otherwise, if the random access preamble is transmitted on the SCell,

[0288] 4) Consider that the random access procedure has not completed successfully.

[0289] 2) If the random access procedure has not completed,

[0290] 3) If access to the RX chain is permitted,

[0291] 4) Select a random backoff time according to a uniform distribution between 0 and PREAMBLE_BACKOFF,

[0292] 3) Otherwise,

[0293] 4) Select a backoff time corresponding to the duration during which access to the RX chain is not permitted.

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

[0295] 3) The RX chain is considered Idle,

[0296] 4) Execute the random access resource selection procedure,

[0297] 3) Otherwise,

[0298] 4) Execute the random access resource selection procedure after the backoff time.

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

[0300] Collision resolution is described in this specification. The following procedures are proposed in this specification taking into account the effect of sharing the RX / TX chain.

[0301] The start of the collision resolution window is conditioned on obtaining access to the RX chain over the duration of the ra-ContentionResolutionTimer. If access is not permitted, the collision resolution is considered unsuccessful and the MAC entity executes the random access resource selection procedure. The MAC entity can delay executing the random access resource selection procedure until after the backoff time, which can be longer than the duration for which the RX chain is considered busy, i.e., the random access resource selection procedure is not executed until the RX chain is idle. Alternatively, a fixed or randomly selected backoff time can be used.

[0302] Note that HARQ is used for Msg3. Thus, if Msg3 is not received by the gNB before the ra-ContentionResolutionTimer expires, retransmission can be scheduled using DCI. To facilitate the use of HARQ for Msg3 when sharing the TX chain, the start of the ra-ContentionResolutionTimer and the monitoring of the PDCCH while the ContentionResolutionTimer is running are conditioned on obtaining access to the TX chain over the duration corresponding to the retransmission scheduled via the RAR UL grant or DCI.

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

[0304] 1) If access to the RX chain is permitted over the duration corresponding to the ra-ContentionResolutionTimer at the first symbol after the end of the Msg3 (re)transmission,

[0305] 2) Start the ra-ContentionResolutionTimer and restart the ra-ContentionResolutionTimer for each HARQ retransmission in the first symbol after the end of Msg3 transmission.

[0306] 2) While the ra-ContentionResolutionTimer is running, monitor the PDCCH regardless of the possible occurrence of a measurement gap.

[0307] 1) If the ra-ContentionResolutionTimer expires, or

[0308] 1) If access to the RX chain is not permitted,

[0309] 2) Discard the TEMPORARY_C-RNTI.

[0310] 2) Consider that contention resolution has failed.

[0311] 1) If contention resolution is considered to have failed,

[0312] 2) Flush the HARQ buffer used for transmission of the MAC PDU in the Msg3 buffer.

[0313] 2) Increment the PREAMBLE_TRANSMISSION_COUNTER by 1.

[0314] 2) If PREAMBLE_TRANSMISSION_COUNTER = preambleTransMax + 1,

[0315] 3) Indicate a random access problem to the upper layer.

[0316] 3) If this random access procedure is triggered for an SI request,

[0317] 4) Consider that the random access procedure has not completed successfully.

[0318] 2) If the random access procedure is not completed,

[0319] 3) If access to the RX chain is permitted,

[0320] 4) Select a random backoff time according to a uniform distribution between 0 and PREAMBLE_BACKOFF,

[0321] 3) Otherwise,

[0322] 4) Select a backoff time corresponding to the duration during which access to the RX chain is not permitted.

[0323] 3) If the criteria for selecting a contention-free random access resource are satisfied during the backoff time,

[0324] 3) The RX chain is considered Idle,

[0325] 4) Execute the random access resource selection procedure,

[0326] 3) Otherwise,

[0327] 4) Execute the random access resource selection procedure after the backoff time.

[0328] The maintenance of uplink time alignment is described in this specification. The following procedures are proposed in this specification taking into account the effect of sharing the RX / TX chain.

[0329] Missing RXOPs may cause the omission of timing advance command MAC CE and can cause the MAC entity to perform actions associated with the expiration of the timeAlignmentTimer that are unnecessary. For scenarios where the timeAlignmentTimer expires during a missing RXOP, the timeAlignmentTimer can be extended for the duration of the missing RXOP, thereby providing the network with an additional opportunity to transmit the timing advance command MAC CE.

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

[0331] 1) If the timeAlignmentTimer expires,

[0332] 2) If the expiration occurs during a missing RXOP,

[0333] 3) Extend the timeAlignmentTimer for the duration corresponding to the missing RXOP.

[0334] 2) Otherwise,

[0335] 3) If the timeAlignmentTimer is associated with PTAG,

[0336] 4) Flush all HARQ buffers for all serving cells,

[0337] 4) If configured, notify RRC to release the PUCCH for all serving cells,

[0338] 4) If configured, notify RRC to release the SRS for all serving cells,

[0339] 4) Clear any configured downlink assignments and configured uplink grants,

[0340] 4) Clear any PUSCH resources for semi-persistent CSI reports,

[0341] 4) Consider that all running timeAlignmentTimers have expired,

[0342] 4) Maintain the NTA for all TAGs.

[0343] 3) If the timeAlignmentTimer is associated with a STAG, for all serving cells belonging to this TAG,

[0344] 4) Flush all HARQ buffers,

[0345] 4) Notify RRC to release the PUCCH if configured,

[0346] 4) Notify RRC to release the SRS if configured,

[0347] 4) Clear any configured downlink allocations and configured uplink grants,

[0348] 4) Clear any PUSCH resources for semi-persistent CSI reports,

[0349] 4) Maintain the NTA for this TAG.

[0350] HARQ operations and logical channel prioritization are described herein. The following procedures are proposed herein to take into account the effect of sharing the RX / TX chain.

[0351] If access to the TX chain is not permitted for the duration corresponding to the uplink grant indicated by the HARQ entity, no MAC PDU can be generated.

[0352] To implement this behavior, the steps of the HARQ entity procedure may be conditional on accessing the TX chain, and the procedure may be defined as follows.

[0353] For each uplink grant, the HARQ entity

[0354] 1) If access to the TX chain is permitted for the duration corresponding to this grant,

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

[0356] Alternatively, the steps of the HARQ entity procedure may remain unchanged, and the steps of the LCP procedure corresponding to the case where the MAC entity does not generate the MAC PDU of the HARQ entity may be defined as follows.

[0357] If the following conditions are met, the MAC entity may not generate the MAC PDU of the HARQ entity,

[0358] Access to the TX chain is not permitted for the duration corresponding to the uplink grant indicated to the HARQ entity, or

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

[0360] This PUSCH transmission does not require aperiodic CSI, and

[0361] The MAC PDU contains zero MAC SDUs,

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

[0363] Scheduling requests are described herein. The following procedures are proposed herein taking into account the effect of sharing the RX / TX chain.

[0364] The procedure can be defined to count the number of failed TX chain access requests or the number of consecutive failed TX chain access requests. The count can be determined over a configured duration, which can include infinity as a configuration option. When the count of (consecutive) failed TX chain access requests exceeds a configured threshold, a random access procedure is initiated.

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

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

[0367] 1) NUM_FAILED_TX_CHAIN_ACCESS_REQUESTS > MAX_FAILED_TX_CHAIN_ACCESS_REQUESTS,

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

[0369] As a result of not being able to access the TX chain, to avoid unnecessarily delaying subsequent SR transmissions and incorrectly reaching sr-TransMax, SR_COUNTER should only be incremented and sr_ProhibitTimer should only be started when access to the TX chain is permitted.

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

[0371] 2) If the PUCCH resources for the SR transmission opportunity do not overlap with the UL-SCH resources,

[0372] 3) When SR_COUNTER < sr-TransMax,

[0373] 4) Instruct the physical layer to signal the SR on one valid PUCCH resource for the SR,

[0374] 4) If access to the TX chain is permitted,

[0375] 5) Increment SR_COUNTER by 1,

[0376] 5) Start sr-ProhibitTimer.

[0377] Buffer status reports are described herein. The following procedures are proposed herein to take into account the effect of sharing the RX / TX chain.

[0378] When checking whether the UL resource can correspond to the BSR MAC CE, the MAC entity also checks whether access to the TX chain is permitted over the duration corresponding to the UL resource. If the access is not permitted, the BSR MAC CE is not generated and the timers periodicBSR-Timer and retxBSR-Timer are not (re)started. Further, if the access is not permitted when a regular BSR is triggered and the logicalChannelSR-DelayTimer is not running, a scheduling request is triggered.

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

[0380] 1) If the buffer status reporting procedure can determine that at least one BSR has been triggered and not cancelled,

[0381] 2) If the UL-SCH resource is available for a new transmission and the UL-SCH resource can, as a result of the logical channel prioritization, correspond to its sub-header in addition to the BSR MAC CE,

[0382] 2) If access to the TX chain is permitted over the duration corresponding to the UL resource,

[0383] 3) Instruct the multiplexing and assembly procedure to generate a BSR MAC CE,

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

[0385] 3) Start or restart the retxBSR-Timer.

[0386] 2) When a regular BSR is triggered and the logicalChannelSR-DelayTimer is not running,

[0387] 3) If there is no UL-SCH resource available for a new transmission, or

[0388] 3) When the MAC entity is configured with a configured uplink grant and the regular BSR is triggered for a logical channel for which the logicalChannelSR-Mask is set to false, or

[0389] 3) If the UL-SCH resource available for a new transmission does not meet the LCP mapping restrictions configured for the logical channel that triggered the BSR, or

[0390] 3) If access to the TX chain is not permitted over the duration corresponding to the UL resource,

[0391] 4) Trigger a scheduling request.

[0392] A power headroom report is described in this specification. The following procedure is proposed in this specification taking into account the effect of sharing the RX / TX chain.

[0393] When checking whether the UL resource can support the MAC CE of the PHR, the MAC entity also checks whether access to the TX chain is permitted over the duration corresponding to the UL resource. If the access is not permitted, the PHR MAC CE is not generated, the triggered PHR is not cancelled, and the timers, phr-PeriodicTimer and phr-ProhibitTimer are not (re)started.

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

[0395] If the MAC entity has a UL resource allocated for a new transmission, the MAC entity

[0396] 1) If it is the first UL resource allocated for a new transmission since the last MAC reset

[0397] 2) Start the phr-PeriodicTimer

[0398] 1) If it can be determined that at least one PHR has been triggered and not cancelled in the power headroom reporting procedure

[0399] 1) If the allocated UL resource can support the sub-header in addition to the MAC CE of the PHR for which the MAC entity is configured to transmit as a result of the LCP

[0400] 1) If access to the TX chain is permitted over the duration corresponding to the UL resource

[0401] 2) If a multiple PHR with a true value is configured,

[0402] 3) For each activated serving cell having a configured uplink associated with any MAC entity,

[0403] 4) Obtain the value of the power headroom of type 1 or type 3 for the corresponding uplink carrier,

[0404] 4) If this MAC entity has the UL resources allocated for transmission in this serving cell, or

[0405] 4) If another MAC entity has the UL resources allocated for transmission on this serving cell when configured and phr-ModeOtherCG is set to true by the upper layer,

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

[0407] 3) If phr-Type2OtherCell with a true value is configured,

[0408] 4) If another MAC entity is an E-UTRA MAC entity,

[0409] 5) Obtain the value of the type 2 power headroom of the SpCell of the other MAC entity (i.e., the E-UTRA MAC entity),

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

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

[0412] 3) In the multiplexing and assembly procedures, instruct to generate and transmit multiple entry PHR MAC CEs based on the values reported by the physical layer.

[0413] 2) Otherwise (i.e., when a single entry PHR format is used),

[0414] 3) Obtain the value of the type 1 power headroom from the physical layer of the corresponding uplink carrier of the PCell,

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

[0416] 3) In the multiplexing and assembly procedures, instruct to generate and transmit a single entry PHR MAC CE based on the values reported by the physical layer.

[0417] 2) Start or restart the phr-PeriodicTimer,

[0418] 2) Start or restart the phr-ProhibitTimer,

[0419] 2) Cancel all triggered PHRs.

[0420] Discontinuous reception (DRX) is described herein. The following procedures are proposed herein taking into account the effect of sharing the RX / TX chain.

[0421] The MAC entity can request access to the RX chain at the start of a DRX cycle for the duration of the drx-onDurationTimer. If access is granted, normal DRX operation is performed, for example, starting the drx-onDurationTimer and monitoring the PDCCH, etc. If access is not granted, the drx-onDurationTimer is not started and the MAC entity enters DRX. Alternatively, the MAC entity can extend the drx-onDurationTimer for a period corresponding to the missing RXOP.

[0422] The drx-InactivityTimer is the period that the MAC entity waits for the normal decoding of the PDCCH since the last successful decoding of the PDCCH. If the PDCCH is not normally decoded before the drx-InactivityTimer expires, the MAC entity enters DRX. The MAC entity starts or restarts the drx-InactivityTimer after a successful decoding of the PDCCH. When the drx-InactivityTimer is (re)started, the MAC entity can request access to the RX chain for the duration of the drx-InactivityTimer. If access is granted, normal DRX operation is performed. If access is not granted, the drx-InactivityTimer is stopped and the MAC entity enters DRX. Alternatively, the MAC entity can extend or pause the drx-InactivityTimer for a period corresponding to the missing RXOP.

[0423] The drx-HARQ-RTT-TimerDL is started when the PDCCH indicates a DL transmission or when a MAC PDU is received with a configured downlink allocation. When this timer is started, the MAC entity can request access to the RX chain for the duration of the drx-HARQ-RTT-TimerDL. When the drx-HARQ-RTT-TimerDL expires, if the data of the corresponding HARQ process is not successfully decoded regardless of whether access is permitted, the drx-RetransmissionTimerDL is started. When this timer is started, the MAC entity can request access to the RX chain for the duration of the drx-RetransmissionTimerDL. If access is permitted, normal DRX operation is performed. If access is not permitted, the drx-RetransmissionTimerDL is stopped and the MAC entity enters DRX. Alternatively, the MAC entity can extend or suspend the drx-RetransmissionTimerDL for the period corresponding to the missing RXOP.

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

[0425] When the DRX timer is suspended / extended due to a missing RXOP, if the TX chain is available, an indicator can be transmitted to the gNB to notify of the action.

[0426] Activation / deactivation of SCell is described in this specification. The following procedures are proposed in this specification taking into account the effect of sharing the RX / TX chain.

[0427] When being executed, for a serving cell that schedules an SCell, the sCellDeactivationTimer of a given SCell may be paused during a missing RXOP.

[0428] If a MAC PDU is not transmitted with a configured / dynamic uplink grant due to a missing TXOP, the sCellDeactivationTimer associated with the SCell should be resumed.

[0429] Bandwidth part operation is described herein. The following procedures are proposed herein taking into account the effect of sharing RX / TX chains.

[0430] A missing RXOP can cause DL allocations and UL grants to be missing and not reset the bwp-InactivityTimer, which may lead to incorrect BWP switches. In a scenario where the bwp-InactivityTimer expires during a missing RXOP, the bwp-InactivityTimer can be extended for the duration of the missing RXOP, thereby providing the network with an additional opportunity to trigger the resumption of the bwp-InactivityTimer.

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

[0432] 2) When the bwp-InactivityTimer associated with the active DL BWP expires

[0433] 3) If the expiration occurs during a missing RXOP

[0434] 4) Extend the bwp-InactivityTimer by the time corresponding to the missing RXOP.

[0435] 3) Otherwise

[0436] 4) If defaultDownlinkBWP-Id is configured,

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

[0438] 4) Otherwise,

[0439] 5) Perform a BWP switch to initialDownlinkBWP.

[0440] Beam failure detection and recovery are described herein. The following procedures are proposed herein to take into account the effect of sharing the RX / TX chain.

[0441] If executed, beamFailureDetectionTimer may be extended or paused for a period corresponding to the missing RXOP.

[0442] To implement this behavior, the procedure may be defined to include the following.

[0443] 1) If an indication of a missing RXOP is received and beamFailureDetectionTimer is running,

[0444] 2) Extend beamFailureDetectionTimer for the duration of the missing RXOP.

[0445] If it can be assumed that the lower layer may not generate a beam failure instance indication during the missing RXOP, no further modification to the procedure may be required. However, if this cannot be assumed, the procedure can be further modified so that the beam failure instance indication received from the lower layer during the missing RXOP is ignored.

[0446] To implement this behavior, the procedure may be modified as follows.

[0447] 1) When the beam failure instance indicator is received from the lower layer during an RXOP that is not considered missing,

[0448] 2) Start or restart the beamFailureDetectionTimer,

[0449] 2) Increment the BFI_COUNTER by 1,

[0450] 2) If BFI_COUNTER >= beamFailureInstanceMaxCount,

[0451] 3) Start a random access procedure on the SpCell.

[0452] In any of the schemes for TX or RX capability sharing described herein, the TX capabilities of the UE may include one or more of the number of transmitters, transmission power budget, uplink (UpLink, UL) multiple input multiple output (Multiple Input Multiple Output, MIMO) capabilities, UL carrier aggregation (Carrier Aggregation, CA) capabilities, and UL bandwidth part (BandWitdh Part, BWP) operation capabilities. Similarly, the RX capabilities of the UE may include one or more of the number of receivers, downlink (DownLink, DL) MIMO capabilities, DL CA capabilities, and DL bandwidth part (BWP) operation capabilities. The UE can signal one or more of these capabilities to one or more of the multiple networks. Further, the UE can signal changes in these capabilities to one or more of the multiple networks. For example, a UE having two receivers that perform dual connection reception from a network can indicate to the network that its reception capability is limited to one receiver when one of the UE's receivers is reallocated for reception from another network.

[0453] The 3rd Generation Partnership Project (3GPP) develops technical specifications for mobile communication network technologies, including radio access, core transport network, and service capabilities, including service coding, security, and quality work. 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 work on standardizing the next generation of cellular technology called New Radio (NR), also known as "5G". 3GPP NR standard development is expected to include the definition of a next-generation radio access technology (new RAT), which is expected to include the provision of new flexible radio access below 6 GHz and new ultra-mobile broadband radio access above 6 GHz. Flexible radio access is expected to consist of new non-backward compatible radio access in new spectrum below 6 GHz and 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 branching requirements. Ultra-mobile broadband is expected to include centimeter and millimeter wave spectra that can provide opportunities for ultra-mobile broadband access, for example, for indoor use and hotspots. In particular, ultra-mobile broadband is expected to share a common design framework with flexible radio access below 6 GHz, using design optimizations specific to centimeter and millimeter waves.

[0454] 3GPP identifies various use cases that NR is expected to support, resulting in diverse user experience requirements for data transfer speed, latency, and mobility. Use cases include the following general categories: enhanced mobile broadband (e.g., broadband access in dense areas, indoor ultra-high-speed broadband access, broadband access within a cloud, 50 Mbps or more everywhere, ultra-low-cost broadband access, mobile broadband in a vehicle), critical communications, massive machine type communications, network operation (e.g., network slicing, routing, migration and interaction, and energy savings), vehicle-to-vehicle communication (V2V), vehicle-to-infrastructure communication (V2I), vehicle-to-network communication (V2N), vehicle-to-pedestrian communication (V2P), and enhanced vehicle-to-everything (eV2X) communication, which may include vehicle communication with other entities. Specific services and applications in these categories include, for example, monitoring and sensor networks, device remote control, two-way remote control, personal cloud computing, video streaming, wireless cloud-based offices, first responder connectivity, automotive eCall, disaster warnings, real-time gaming, multi-person video calls, autonomous driving, augmented reality, touch internet, and virtual reality. All such use cases are contemplated herein.

[0455] Figure 27A illustrates an exemplary communication system 100 in which the methods and apparatuses described and claimed herein may be embodied. As shown, the exemplary communication system 100 can include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g (which may generally or collectively be referred to as WTRUs 102), radio access networks (RANs) 103 / 104 / 105 / 103b / 104b / 105b, core networks 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 the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d, 102e, 102f, 102g can be any type of device or apparatus configured to operate and / or communicate in a wireless environment. Each WTRU 102a, 102b, 102c, 102d, 102e, 102f, 102g is shown as a mobile wireless communication device in FIGS. 27A - 27E, although a wide variety of use cases are contemplated for 5G wireless communication and each WTRU can include, 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 smartphone, a laptop, a tablet, a netbook, a notebook computer, a personal computer, a wireless sensor, a home appliance, a wearable device such as a smartwatch or smart closing, a medical or e-health device, a robot, an industrial device, a drone, a vehicle such as a car, a truck, a train, an airplane, etc., or can be embodied in any type of device or apparatus configured to transmit and / or receive wireless signals.

[0456] The communication system 100 may also include base station 114a and base station 114b. Base station 114a can be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c to facilitate access to one or more communication networks such as core network 106 / 107 / 109, Internet 110, and / or other network 112. Base station 114b can be any type of device configured to interface, either wired and / or wirelessly, with at least one of RRHs (Remote Radio Heads) 118a, 118b, TRPs (Transmission and Reception Points) 119a, 119b, and / or RSUs (Road Side Units) 120a and 120b to facilitate access to one or more communication networks such as core network 106 / 107 / 109, Internet 110, other network 112, and / or V2X server (or ProSe function and server) 113. RRHs 118a, 118b can be any type of device configured to wirelessly interface with at least one of WTRU 102c to facilitate access to one or more communication networks such as core network 106 / 107 / 109, Internet 110, and / or other network 112. TRPs 119a, 119b can be any type of device configured to wirelessly interface with at least one of WTRU 102d to facilitate access to one or more communication networks such as core network 106 / 107 / 109, Internet 110, and / or other network 112. RSUs 120a, 120b can be any type of device configured to wirelessly interface with at least one of WTRU 102e or 102f to facilitate access to one or more communication networks such as core network 106 / 107 / 109, Internet 110, other network 112, and / or V2X server (ProSe function and server) 113.As an example, the base stations 114a and 114b may be a base transceiver station (BTS), Node B, eNodeB, home Node B, home eNodeB, site controller, access point (AP), wireless router, or the like. Although the base stations 114a and 114b are each shown as a single element, it will be understood that the base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

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

[0458] The base station 114a can communicate with one or more of the WTRUs 102a, 102b, 102c via the air interfaces 115 / 116 / 117, which can 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 interfaces 115 / 116 / 117 can be established using any suitable radio access technology (RAT).

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

[0460] The RRHs 118a, 118b, TRPs 119a, 119b, and / or RSUs 120a, 120b can communicate with one or more of the WTRUs 102c, 102d, 102e, 102f via the air interfaces 115c / 116c / 117c, which can 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 interfaces 115c / 116c / 117c can be established using any suitable radio access technology (RAT).

[0461] WTRUs 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g may communicate with each other via an air interface 115d / 116d / 117d (not shown), 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).

[0462] More specifically, as described above, the communication system 100 may be a plurality of access systems and may use one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base stations 114a of RANs 103 / 104 / 105, and WTRUs 102a, 102b, 102c, or the remote radio heads (RRHs) 118a, 118b, transmit receive points (TRPs) 119a, 119b, and radio signal units (RSUs) 120a, 120b of RANs 103b / 104b / 105b, and WTRUs 102c, 102d, 102e, 102f may implement wireless technologies such as Universal Mobile Telecommunications System (UMTS), Terrestrial Radio Access (UTRA), etc., which may establish air interfaces 115 / 116 / 117 or 115c / 116c / 117c respectively using wideband CDMA (WCDMA). 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).

[0463] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c, or the RRHs 118a, 118b, the TRPs 119a, 119b, and / or the RSUs 120a, 120b of the RANs 103b / 104b / 105b, and the WTRUs 102c, 102d 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 interfaces 115 / 116 / 117 or 115c / 116c / 117c, respectively. In the future, the air interfaces 115 / 116 / 117 may implement 3GPP NR technology. LTE and LTE-A technologies include LTE D2D and V2X technologies and interfaces (such as sidelink communication). 3GPP NR technology includes NR V2X technologies and interfaces (such as sidelink communication).

[0464] In one embodiment, the base station 114a of the RANs 103 / 104 / 105, and the WTRUs 102a, 102b, 102c, or the RRHs 118a, 118b, the TRPs 119a, 119b, and / or the RSUs 120a, 120b of the RANs 103b / 104b / 105b, and the WTRUs 102c, 102d, 102e, 102f may implement radio technologies such as IEEE802.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), GSM Evolution (Enhanced Data rates for GSM Evolution, EDGE), GSM EDGE (GERAN), etc.).

[0465] The base station 114c in FIG. 27A may be, for example, a wireless router, a home Node B, a home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connection in a local area such as an office, a home, a vehicle, a campus, etc. In one embodiment, the base station 114c and the WTRU102e may implement a wireless technology such as IEEE802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114c and the WTRU102d may implement a wireless technology such as IEEE802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114c and the WTRU102e may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a pico cell or a femto cell. As shown in FIG. 27A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114c may not need to access the Internet 110 via the core network 106 / 107 / 109 in some cases.

[0466] RAN103 / 104 / 105 and RAN103b / 104b / 105b may communicate with the core network 106 / 107 / 109, which may be any type of network configured to provide voice, data, application, and / or voice over internet protocol (VoIP) services to one or more of the WTRU102a, 102b, 102c, 102d. For example, the core network 106 / 107 / 109 may provide call control, billing services, mobile location-based services, prepaid originating calls, Internet connectivity, video delivery, etc., and / or may perform high-level security functions such as user authentication.

[0467] Although not shown in FIG. 27A, it will be appreciated that RAN103 / 104 / 105 and / or RAN103b / 104b / 105b and / or core network 106 / 107 / 109 may communicate directly or indirectly with the same RAT as RAN103 / 104 / 105 and / or RAN103b / 104b / 105b, or with other RANs employing different RATs. For example, in addition to being connected to RAN103 / 104 / 105 and / or RAN103b / 104b / 105b which may utilize E-UTRA radio technology, core network 106 / 107 / 109 may also communicate with another RAN (not shown) using GSM radio technology.

[0468] Core network 106 / 107 / 109 may also function as a gateway for WTRU102a, 102b, 102c, 102d, 102e to access PSTN108, Internet 110, and / or other network 112. PSTN108 may include a public switched telephone network providing plain old telephone service (POTS). Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as transmission control protocol (TCP), user datagram protocol (UDP), and internet protocol (IP) of the TCP / IP internet protocol suite. Network 112 may include a wired or wireless communication network owned and / or operated by other service providers. For example, network 112 may include another core network connected to one or more RANs which may employ the same RAT as RAN103 / 104 / 105 and / or RAN103b / 104b / 105b, or a different RAT.

[0469] 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. For example, the WTRU 102e shown in FIG. 27A may be configured to communicate with a base station 114a that can use cellular - based wireless technology and a base station 114c that can use IEEE802 wireless technology.

[0470] FIG. 27B is a block diagram of an exemplary apparatus or device configured for wireless communication, such as a WTRU 102, according to an embodiment illustrated herein. As shown in FIG. 27B, 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 / or other peripheral devices 138. It will be understood that the WTRU 102 may include any partial combination of the foregoing elements while remaining consistent with an embodiment. Also, embodiments contemplate that base stations 114a and 114b, and / or nodes that base stations 114a and 114b may represent, which are not limited to, inter alia, transceiver stations (BTSs), 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, may depict and may include some or all of the elements described herein in FIG. 27B.

[0471] Processor 118 can be a general-purpose processor, a dedicated 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. Processor 118 can perform signal coding, data processing, power control, input / output processing, and / or any other function that enables the WTRU 102 to operate in a wireless environment. Processor 118 can be coupled to a transceiver 120, which can be coupled to the transmit / receive element 122. Although FIG. 27B shows processor 118 and transceiver 120 as separate components, it will be understood that processor 118 and transceiver 120 can be integrated together in an electronic package or chip.

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

[0473] In addition, although the transmit / receive element 122 is depicted in FIG. 27B as a single element, 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 via the air interfaces 115 / 116 / 117.

[0474] The transceiver 120 may be configured to modulate signals transmitted by the transmit / receive element 122 and 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, for example, UTRA and IEEE 802.11.

[0475] The processor 118 of the WTRU 102 may be coupled to the speaker / microphone 124, keypad 126, and / or the 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 therefrom. The processor 118 may also output user data to the speaker / microphone 124, keypad 126, and / or the display / touchpad / indicator 128. Further, the processor 118 may access information from and store data in any suitable type of memory, such as the non-removable memory 130 and / or the removable memory 132. The non-removable memory 130 may include random-access memory (RAM), 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, and the like. In one embodiment, the processor 118 may access information from and store data in a memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

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

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

[0478] Processor 118 may further be coupled to other peripheral devices 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connections. For example, peripheral devices 138 may include various sensors such as an accelerometer, a biometric (e.g., fingerprint authentication) sensor, an electronic compass, a satellite transceiver, a digital camera (for photos or videos), a universal serial bus (USB) port, or other interconnect interfaces, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® module, a frequency modulation (FM) radio unit, a digital music player, a media player, a video game player module, etc.

[0479] WTRU 102 may be embodied in other apparatuses or devices such as sensors, household appliances, wearable devices such as smart watches or smart closures, medical or e-health devices, robots, industrial equipment, drones, vehicles such as cars, trucks, trains, or airplanes. WTRU 102 can 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 includes one of peripheral devices 138.

[0480] Figure 27C is a system diagram of RAN 103 and core network 106 according to one embodiment. As described above, RAN 103 can communicate with WTRUs 102a, 102b, 102c via air interface 115 using UTRA radio technology. RAN 103 can also communicate with core network 106. As shown in Figure 27C, RAN 103 can include Node Bs 140a, 140b, 140c, each of which can include one or more transceivers for communicating with WTRUs 102a, 102b, 102c via air interface 115. Node Bs 140a, 140b, 140c can each be associated with a particular cell (not shown) within RAN 103. RAN 103 can also include RNCs 142a, 142b. It will be appreciated that RAN 103 can include any number of Node Bs and RNCs while maintaining consistency with one embodiment.

[0481] As shown in Figure 27C, Node Bs 140a, 140b can communicate with RNC 142a. Additionally, Node B 140c can communicate with RNC 142b. Node Bs 140a, 140b, 140c can communicate with their respective RNCs 142a, 142b via the Iub interface. RNCs 142a, 142b can communicate with each other via the Iur interface. Each of RNCs 142a, 142b can be configured to control their respective connected Node Bs 140a, 140b, 140c. Additionally, each of RNCs 142a, 142b can be configured to perform or support other functions such as outer loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, data encryption, etc.

[0482] The core network 106 shown in FIG. 27C 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 will be understood that any of these elements may be owned and / or operated by entities other than the core network operator.

[0483] The RNC 142a within the RAN 103 may be connected to the MSC 146 within the core network 106 via the 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 a circuit-switched network, such as the PSTN 108, to facilitate communication between the WTRUs 102a, 102b, 102c and conventional landline communication devices.

[0484] The RNC 142a within the RAN 103 may also be connected to the SGSN 148 within the core network 106 via the 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 a packet-switched network, such as the Internet 110, to facilitate communication between the WTRUs 102a, 102b, 102c and IP-enabled devices.

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

[0486] FIG. 27D is a system diagram of RAN 104 and core network 107 according to one embodiment. As described above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN 104 can also communicate with core network 107.

[0487] RAN 104 can include eNode-Bs 160a, 160b, 160c, although it will be understood that RAN 104 can include any number of eNode-Bs while remaining consistent with one embodiment. Each of eNode-Bs 160a, 160b, 160c can include one or more transceivers for communicating with WTRUs 102a, 102b, 102c via air interface 116. In one embodiment, eNode-Bs 160a, 160b, 160c can implement MIMO technology. Thus, eNode-B 160a, for example, can transmit and receive radio signals to / from WTRU 102a using multiple antennas.

[0488] Each of eNode-Bs 160a, 160b, and 160c can be associated with a particular cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling, etc. in the uplink and / or downlink. As shown in FIG. 27D, eNode-Bs 160a, 160b, 160c can communicate with each other via the X2 interface.

[0489] The core network 107 shown in FIG. 27D can include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. Although each of the foregoing elements is depicted as part of core network 107, it will be understood that any of these elements can be owned and / or operated by an entity other than the core network operator.

[0490] The MME 162 can be connected to each of the eNode-Bs 160a, 160b, and 160c within the RAN 104 via the S1 interface and can function as a control node. For example, the MME 162 can authenticate the WTRUs 102a, 102b, 102c, bearer active / inactive users, and can play a role in selecting a specific serving gateway during the initial attach of the WTRUs 102a, 102b, 102c. The MME 162 can also provide control plane functions for exchanges between the RAN 104 and other RANs (not shown) using other radio technologies such as GSM and / or WCDMA.

[0491] The serving gateway 164 can be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via the S1 interface. The serving gateway 164 can generally route and transfer user data packets to / from the WTRUs 102a, 102b, 102c. The serving gateway 164 can perform other functions such as anchoring the user plane during an eNodeB handover, triggering paging when downlink data is available to the WTRUs 102a, 102b, 102c, and managing and storing the context of the WTRUs 102a, 102b, 102c.

[0492] The serving gateway 164 can be connected to the PDN gateway 166, and the PDN gateway 166 can provide access to a packet switched network such as the Internet 110 to the WTRUs 102a, 102b, 102c and facilitate communication between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0493] The core network 107 can facilitate communication with other networks. For example, the core network 107 can provide access to a circuit-switched network, such as the PSTN 108, to the WTRUs 102a, 102b, 102c to facilitate communication between the WTRUs 102a, 102b, 102c and conventional landline communication devices. For example, the core network 107 can include, or communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that functions as an interface between the core network 107 and the PSTN 108. In addition, the core network 107 can provide access to other networks 112 to the WTRUs 102a, 102b, 102c, and the other networks 112 can include other wired and / or wireless networks owned and / or operated by other service providers.

[0494] Figure 27E is a system diagram of a RAN 105 and a core network 109 according to one embodiment. The RAN 105 can be an access service network (ASN) that employs IEEE 802.16 wireless technology and communicates with the WTRUs 102a, 102b, and 102c via an air interface 117. As will be further described below, communication links between different functional entities of the WTRUs 102a, 102b, 102c, the RAN 105, and the core network 109 can be defined as reference points.

[0495] As shown in FIG. 27E, RAN 105 can include base stations 180a, 180b, 180c, and an ASN gateway 182, although it will be understood that RAN 105 can include any number of base stations and ASN gateways while remaining consistent with the embodiments. Each of base stations 180a, 180b, 180c can be associated with a particular cell within RAN 105 and can include one or more transceivers for communicating with WTRUs 102a, 102b, 102c via air interface 117. In one embodiment, base stations 180a, 180b, 180c can implement MIMO technology. Thus, base station 180a, for example, can transmit and receive radio signals to and from WTRU 102a using multiple antennas. Base stations 180a, 180b, 180c can also provide mobility management functions such as handoff triggers, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, and the like. ASN gateway 182 can function as a traffic aggregation point and can perform roles such as paging, caching of subscriber profiles, routing to core network 109, and the like.

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

[0497] The communication links between each of base stations 180a, 180b, and 180c can be defined as R8 reference points that include protocols for facilitating WTRU handover and data transfer between base stations. The communication links between base stations 180a, 180b, 180c and ASN gateway 182 can be defined as R6 reference points. The R6 reference points can include protocols for facilitating mobility management based on mobility events associated with each of WTRUs 102a, 102b, 102c.

[0498] As shown in FIG. 27E, RAN 105 can be connected to core network 109. The communication link between RAN 105 and core network 109 can be defined as an R3 reference point that includes, for example, protocols for facilitating data transfer and mobility management capabilities. Core network 109 can 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 core network 109, it will be understood that any of these elements can be owned and / or operated by an entity other than the core network operator.

[0499] The MIP-HA can play a role in IP address management and enable the WTRU102a, 102b, and 102c to roam between different ASNs and / or different core networks. The MIP-HA 184 can provide the WTRU102a, 102b, 102c with access to a packet switched network such as the Internet 110 to facilitate communication between the WTRU102a, 102b, 102c and IP-enabled devices. The AAA server 186 can play a role in supporting user authentication and user services. The gateway 188 can facilitate interaction with other networks. For example, the gateway 188 can provide the WTRU102a, 102b, 102c with access to a circuit switched network such as the PSTN 108 to facilitate communication between the WTRU102a, 102b, 102c and conventional landline communication devices. In addition, the gateway 188 can provide the WTRU102a, 102b, 102c with access to other networks 112, which can include other wired and / or wireless networks owned and / or operated by other service providers.

[0500] Although not shown in Figure 27E, it will be understood that the RAN 105 can be connected to other ASNs and the core network 109 can be connected to other core networks. The communication link between the RAN 105 and other ASNs can be defined as an R4 reference point that can include a protocol for coordinating the mobility of the WTRU102a, 102b, 102c between the RAN 105 and other ASNs. The communication link between the core network 109 and other core networks can be defined as an R5 reference that can include a protocol for facilitating interaction between the home core network and the accessed core network.

[0501] The core network entities described in this specification and shown in FIGS. 27A, 27C, 27D, and 27E are identified by the names given to those entities in certain existing 3GPP specifications, but their future entities and functions may be identified by other names, and it is understood that in future specifications published by 3GPP, including future 3GPP NR specifications, certain entities or functions may be combined. Accordingly, the specific network entities and functions described and illustrated in FIGS. 27A, 27B, 27C, 27D, and 27E are provided as an example only, and it is understood that the subject matter disclosed and claimed in this specification may be embodied or implemented in any similar communication system, whether currently defined or to be defined in the future.

[0502] FIG. 27F is a block diagram of an exemplary computing system 90 in which one or more devices of the communication networks illustrated in FIGS. 27A, 27C, 27D, and 27E can be embodied, such as a particular node or functional entity within RAN 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110, or other network 112. Computing system 90 can include a computer or server and can be controlled primarily by computer-readable instructions, which can be in the form of software or any means by which such software is stored or accessed. Such computer-readable instructions can be executed within processor 91 to cause computing system 90 to operate. Processor 91 can be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), multiple 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. Processor 91 can execute signal coding, data processing, power control, input / output processing, and / or any other function that enables computing system 90 to operate in a communication network. Coprocessor 81 is an optional processor different from main processor 91 that can execute additional functions or assist processor 91. Processor 91 and / or coprocessor 81 can receive, generate, and process data related to the methods and apparatuses disclosed herein.

[0503] During operation, the processor 91 fetches, decodes, and executes instructions and transmits information to other resources via the main data transfer path of the computing system, the system bus 80. Such a system bus connects the components within the computing system 90 and defines a medium for data exchange. The system bus 80 typically includes data lines for transmitting data, address lines for transmitting addresses, and control lines for transmitting interrupts and operating the system bus. An example of such a system bus 80 is the PCI (Peripheral Component Interconnect) bus.

[0504] 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 circuits that enable information to be stored and retrieved. The ROM 93 generally includes stored data that cannot be easily modified. The data stored in the RAM 82 can be read or changed by the processor 91 or other hardware devices. Access to the RAM 82 and / or ROM 93 can be controlled by the memory controller 92. The memory controller 92 can provide an address translation function that converts virtual addresses to physical addresses when an instruction is executed. The memory controller 92 can also provide a memory protection function that separates the processes within the system and separates system processes from user processes. Thus, a program executed in the first mode can access only the memory mapped by its own process virtual address space and cannot access the memory within the virtual address space of another process unless memory sharing between processes is set up.

[0505] In addition, the computing system 90 can include a peripheral device controller 83 that serves to communicate instructions from the processor 91 to peripheral devices such as a printer 94, a keyboard 84, a mouse 95, and a disk drive 85.

[0506] 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 may be provided in the form of a graphical user interface (GUI). The display 86 may be implemented as a CRT-based video display, an LCD-based flat panel display, a gas plasma-based flat panel display, or a touch panel. The display controller 96 includes the electronic components necessary to generate the video signal transmitted to the display 86.

[0507] Furthermore, the computing system 90 may include communication circuitry, such as a network adapter 97, that can be used, for example, to connect the computing system 90 to the RAN 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110, or other network 112 of FIGS. 27A, 27B, 27C, 27D, and 27E, enabling the computing system 90 to communicate with other nodes or functional entities of those networks. The communication circuitry may be used, alone or in combination with the processor 91, to perform the transmission and reception steps of the particular apparatuses, nodes, or functional entities described herein.

[0508] FIG. 27G illustrates one embodiment of an exemplary communication system 111 in which the methods and apparatuses described and claimed herein may be embodied. As shown, the exemplary communication system 111 may include wireless transmit / receive units (WTRUs) A, B, C, D, E, F, a base station, a V2X server, and RSUs A and B, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. One or some of the WTRUs A, B, C, D, E may be outside the network (e.g., outside the cell coverage boundary shown as a dashed line in the figure). WTRUs A, B, C form a V2X group, where WTRU A is the group leader and WTRUs B and C are group members. WTRUs A, B, C, D, E, F may communicate via the Uu interface or the sidelink (PC5) interface.

[0509] Any or all of the apparatuses, systems, methods, and processes described in this specification can be embodied 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, cause the processor to execute and / or implement the systems, methods, and processes described in this specification. Specifically, any of the steps, operations, or functions described in this specification can be implemented in the form of such computer-executable instructions that are executed on a processor of an apparatus or computing system configured for wireless and / or wired network communication. A computer-readable storage medium includes volatile and non-volatile, removable and non-removable media for storing information implemented in any non-transitory (e.g., tangible or physical) method or technology, but such a computer-readable storage medium does not include signals. Computer-readable storage media include RAM, ROM, EEPROM, flash memory, or other memory technologies, CD-ROM, digital versatile disks (DVDs) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage devices, or other magnetic storage devices, or any other tangible or physical medium that can be used to store desired information and can be accessed by a computing system.

Claims

1. A wireless communication device including a processor and a memory, wherein when executed by the processor of the wireless communication device, the wireless communication device is caused to determine downlink information, the downlink information indicating one or more of a first reception (RX) opportunity (RXOP), a first RX capability, a second RXOP, or a second RX capability, determine uplink information, the uplink information indicating one or more of a first transmission (TX) opportunity (TXOP), a first TX capability, a second TXOP, or a second TX capability, based on the downlink information or the uplink information, establish one or more of a first connection of a first subscriber identity module (SIM) to a first network or a second connection of a second SIM to a second network, and perform one or more of a first reception from the first network, a first transmission to the first network, a second reception from the second network, or a second transmission to the second network, the wireless communication device further including computer-executable instructions stored in the memory of the wireless communication device.

2. The computer-executable instructions, when executed by the processor of the wireless communication device, further cause the wireless communication device to signal the determined first RXOP or first RX capability to the first network or signal the determined second RXOP or second RX capability to the second network, the wireless communication device according to claim 1.

3. The wireless communication device includes a radio resource control (RRC) layer, a media access control (MAC) layer, and a physical (PHY) layer, and the determination of the uplink information or the determination of the downlink information is performed by an arbiter function, the arbiter function being implemented by the RRC layer, the MAC layer, the PHY layer, the NAS layer, or a combination thereof, the wireless communication device according to claim 1.

4. The first RX capability includes a number or receiver for reception from the first network, downlink (DL) multiple-input multiple-output (MIMO) capability, DL carrier aggregation (CA) capability, or DL bandwidth part (BWP) operation capability, The second RX capability includes several receivers for reception from the second network, DL MIMO capability, DL CA capability, or DL BWP operation capability, The first TX capability includes several transmitters for transmission to the first network, uplink (UL) MIMO capability, UL CA capability, UL BWP operation capability, or a power budget allocated for transmission to the first network, The second TX capability includes several transmitters for transmission to the second network, UL MIMO capability, UL CA capability, UL BWP operation capability, or a power budget allocated for transmission to the second network, the wireless communication device according to claim 1.

5. The receiver chain or transmitter chain shared across the first network and the second network performs the first transmission, the second transmission, the first reception, or the second reception, the wireless communication device according to claim 1.

6. The wireless communication device includes a media access control (MAC) layer, and the sharing of the receiver chain or transmitter chain is based on adapting one or more MAC counters or timers in response to the loss of the RXOP or TXOP, the wireless communication device according to claim 5.

7. The start of the random access contention resolution window is conditioned on access to the receiver chain or transmitter chain, the wireless communication device according to claim 1.

8. The start of the random access response (RAR) window is conditioned on access to the receiver chain or transmission chain, the wireless communication device according to claim 1.

9. The wireless communication device includes a media access control (MAC) layer, and when the computer-executable instructions are executed by the processor of the wireless communication device, the wireless communication device is caused to, The wireless communication device according to claim 1, further causing the first network or the second network to transmit an indication that the first RXOP, the first TXOP, the second RXOP, or the second TXOP is missing, thereby causing adaptation of the behavior of the MAC layer interface.

10. The wireless communication device according to claim 9, wherein the indication provides information indicating a type of adapted MAC behavior.

11. The type of the adapted MAC behavior is adapting one or more MAC counters in response to the loss of the first RXOP, the first TXOP, the second RXOP, or the second TXOP, wherein the adapted one or more MAC counters are incremented to avoid declaring a fault prematurely, the wireless communication device according to claim 10, including adapting.

12. The type of the adapted MAC behavior is adapting one or more MAC timers in response to the loss of the first RXOP, the first TXOP, the second RXOP, or the second TXOP, wherein the adapted one or more MAC timers are extended to avoid declaring a fault prematurely, the wireless communication device according to claim 10, including adapting.

13. The type of the adapted MAC behavior is delaying execution of a random access resource selection procedure until after a backoff time, wherein the backoff time is the same as or greater than the period during which the transmitter chain is busy, the wireless communication device according to claim 10, including delaying.

14. When the computer-executable instructions are executed by the processor of the wireless communication device, the wireless communication device is further caused to transmit an indication of a transmission failure or a reception failure to one or more upper layers when some TXOP or RXOP drops exceed a threshold, the wireless communication device according to claim 9.

15. The wireless communication device includes a Medium Access Control (MAC) layer, the MAC layer includes a common MAC layer interface and a dedicated MAC layer interface, the dedicated MAC layer interface is associated with the first SIM or the second SIM, and the common MAC layer interface is shared across both the first SIM and the second SIM. The wireless communication device according to claim 1.

16. The wireless communication device includes a common Non-Access Stratum (NAS) interface and a dedicated NAS interface, the dedicated NAS interface is associated with the first SIM or the second SIM, and the common NAS interface is shared across both the first SIM and the second SIM. The wireless communication device according to claim 1.

17. The wireless communication device includes a Radio Resource Control (RRC) interface and a dedicated RRC interface, the dedicated RRC interface is associated with the first SIM or the second SIM, and the common RRC interface is shared across both the first SIM and the second SIM. The wireless communication device according to claim 1.

18. When the computer-executable instructions are executed by the processor of the wireless communication device, cause the wireless communication device to disrupt or release the first connection and cause communication to continue the second connection, or further cause the wireless communication device to disrupt or release the second connection and cause communication to continue the first connection. The wireless communication device according to claim 1.

19. A method for use in a wireless communication device, comprising: determining downlink information, the downlink information indicating one or more of a first Receive (RX) Opportunity (RXOP), a first RX capability, a second RXOP, or a second RX capability; determining uplink information, the uplink information indicating one or more of a first Transmission (TX) Opportunity (TXOP), a first TX capability, a second TXOP, or a second TX capability; based on the downlink information or the uplink information, a first connection with a first network of a first Subscriber Identity Module (SIM), or Establishing one or more of the second connections with the second network of the second SIM, and A method comprising performing one or more of a first reception from the first network, a first transmission to the first network, a second reception from the second network, or a second transmission to the second network. **Claim 20** A receiver chain or a transmitter chain shared across the first network and the second network performs the first transmission, the second transmission, the first reception, or the second reception, The wireless communication device includes a media access control (MAC) layer, and the sharing of the receiver chain or the transmitter chain is based on adapting one or more MAC counters or timers in response to a loss of the RXOP or TXOP. The method according to claim 19.

Images