Patent Description:
In other examples (e.g., in a next generation, a new radio (NR), or <NUM> network), a wireless multiple access communication system may include a number of distributed units (DUs) (e.g., edge units (EUs), edge nodes (ENs), radio heads (RHs), smart radio heads (SRHs), transmission reception points (TRPs), etc.) in communication with a number of central units (CUs) (e.g., central nodes (CNs), access node controllers (ANCs), etc.), where a set of one or more DUs, in communication with a CU, may define an access node (e.g., which may be referred to as a BS, next generation NodeB (gNB or gNodeB), TRP, etc.). A BS or DU may communicate with a set of UEs on downlink channels (e.g., for transmissions from a BS or DU to a UE) and uplink channels (e.g., for transmissions from a UE to a BS or DU).

<CIT> discloses a user equipment (UE) that may determine a capability of the UE to support multiple subscriber identity modules (SIMs). The multiple SIMs may enable the UE to communicate with multiple network nodes. The UE may notify at least one network node of the multiple network nodes of the multiple SIM capability of the UE.

<CIT> discloses apparatuses and methods for a wireless communication device having a first Subscriber Identity Module (SIM) and a second SIM to manage communication via the first SIM and the second SIM are disclosed. The method can include, but is not limited to, sending a first message including an indication of an extended signaling capability, receiving a second message including an inquiry regarding the extended signaling capability, and sending a third message including extended capability information, responsive to receiving the second message.

<CIT> discloses techniques that provide network assisted multi-subscription physical layer sharing at a user equipment (UE) by transmitting a multi-subscription coordination capability to a network, establishing a link for a first subscription with the network based on the multi-subscription coordination capability, and establishing a second subscription with the network using the link based on the multi-subscription coordination capability, the first subscription is associated with the second subscription.

The methods and apparatus of the present invention are set out in claims <NUM>, <NUM> and <NUM>. Other aspects of the invention can be found in the dependent claims.

Aspects of the present disclosure provide apparatus, methods, processing systems, and computer readable mediums for communicating information regarding a multi-subscriber identity module (SIM) capability of a UE, such as registering tune-away period configurations and synchronizing configuration states between the UE and the network.

The techniques described herein may be used for various wireless communication technologies, such as 3GPP Long Term Evolution (LTE), LTE-Advanced (LTE-A), code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal frequency division multiple access (OFDMA), single-carrier frequency division multiple access {SC-FDMA), time division synchronous code division multiple access (TD-SCDMA), and other networks.

NR access (e.g., <NUM> NR) may support various wireless communication services, such as enhanced mobile broadband (eMBB) targeting wide bandwidth (e.g., <NUM> or beyond), millimeter wave (mmW) targeting high carrier frequency (e.g., <NUM> or beyond), massive machine type communications MTC (mMTC) targeting non-backward compatible MTC techniques, and/or mission critical targeting ultra-reliable low-latency communications (URLLC).

For example, as shown in <FIG>, the UE 120a has a multi-subscriber identity module (SIM) controller that may be configured for communicating information regarding the MSIM capability of the UE <NUM>, according to aspects described herein. The BS 110a has a multi-subscriber identify module (SIM) controller that may be configured for receive and register information regarding MSIM capability of the UE <NUM>, according to aspects described herein.

As illustrated in <FIG>, the wireless communication network <NUM> may include a number of base stations (BSs) <NUM> and other network entities. A BS may be a station that communicates with user equipments (UEs). Each BS <NUM> may provide communication coverage for a particular geographic area. In some examples, the BSs may be interconnected to one another and/or to one or more other BSs or network nodes (not shown) in wireless communication network <NUM> through various types of backhaul interfaces, such as a direct physical connection, a wireless connection, a virtual network, or the like using any suitable transport network.

A finely dashed line with double arrows indicates potentially interfering transmissions between a UE and a BS.

<FIG> illustrates example components of BS <NUM> and UE <NUM> (e.g., in the wireless communication network <NUM> of <FIG>), which may be used to implement aspects of the present disclosure. For example, antennas <NUM>, processors <NUM>, <NUM>, <NUM>, and/or controller/processor <NUM> of the UE <NUM> and/or antennas <NUM>, processors <NUM>, <NUM>, <NUM>, and/or controller/processor <NUM> of the BS <NUM> may be used to perform the various techniques and methods described herein. For example, as shown in <FIG>, the controller/processor <NUM> of the BS <NUM> has a multi-subscriber identify module (SIM) controller that may be configured for receive and register information regarding MSIM capability of the UE <NUM>, according to aspects described herein. The controller/processor <NUM> of the UE <NUM> also includes an MSIM controller that may be configured for communication information regarding the MSIM capability of the UE <NUM>, according to aspects described herein.

The transmit processor <NUM> may also generate reference symbols, such as for the primary synchronization signal (PSS), secondary synchronization signal (SSS), and cell-specific reference signal (CRS). A transmit (TX) multiple-input multiple-output (MIMO) processor <NUM> may perform spatial processing (e.g., precoding) on the data symbols, the control symbols, and/or the reference symbols, if applicable, and may provide output symbol streams to the modulators (MODs) 232a-232t. Downlink signals from modulators 232a-232t may be transmitted via the antennas 234a-234t, respectively.

At the UE <NUM>, the antennas 252a-252r may receive the downlink signals from the BS <NUM> and may provide received signals to the demodulators (DEMODs) in transceivers 254a-254r, respectively. A MIMO detector <NUM> may obtain received symbols from all the demodulators 254a-254r, perform MIMO detection on the received symbols if applicable, and provide detected symbols.

The symbols from the transmit processor <NUM> may be precoded by a TX MIMO processor <NUM> if applicable, further processed by the demodulators in transceivers 254a-254r (e.g., for SC-FDM, etc.), and transmitted to the base station <NUM>.

The controllers/processors <NUM> and <NUM> may direct the operation at the BS <NUM> and the UE <NUM>, respectively. The controller/processor <NUM> and/or other processors and modules at the BS <NUM> may perform or direct the execution of processes for the techniques described herein.

New radio (NR) concurrent radio-access technology (RAT) operation generally refers to operating multiple simultaneous active connections with at least one connection being on NR. For example, the two connections may involve LTE and NR connections, or both NR connections. Multi-subscriber identify module (SIM) devices are able to connect to multiple networks independently without network awareness. Different UE behaviors may occur based on different implementations like dual-SIM dual active (DSDA) or dual-SIM dual standby (DSDS). DSDS generally refers to a dual-SIM deployment where the two SIM cards of the UE may be unable to simultaneously generate traffic. DSDA on the other hand refers to a dual-SIM deployment where both SIM cards of the UE may be active at the same time. As used herein, a SIM generally refers to both virtual and hardware implementations of a SIM. In otherwords, each SIM may be implemented using hardware (e.g., a physical SIM card) on the multi-SIM device, or implemented virtually using a remote database.

For a UE with DSDS deployment, two technologies may share the same set of RF components. Therefore, performance degradation may be experienced on one SIM due to various issues related to UE and network mismatch when the UE engages in activities for another SIM. For example, the receiver (Rx) and transmitter (Tx) chain in multi-SIM (MSIM) UEs may only be able to tune to a single network at a time, and therefore the two or more network interfaces cannot operate simultaneously. Instead, the UE may monitor multiple interfaces in a standby mode by tuning to one network (e.g., corresponding to a first radio access technology (RAT), such as NR) and then to the other network (e.g., corresponding to a second RAT, such as NR or LTE). For example, the radio may connect to a first network and periodically tune-away to other networks on standby to maintain service. In this tune-away procedure, the radio tunes to the standby network for a relatively short time and then tunes back to the first network to continue a voice or data call. This tune-away procedure allows the mobile device to monitor for pages (e.g., pages associated with maintaining connections to a network and indicating incoming calls) received on the standby network(s). If a page is received, a UE may automatically switch networks to answer an incoming telephone call.

The multiple SIMs of the multi-SIM deployment of the UE may belong to different network carriers. For example, for a first SIM and a corresponding NW carrier, the network may be unaware of information regarding a second SIM of the UE (e.g., subscriber identifier (ID)/security key). The first SIM may inform the network when the first SIM is to be deactivated or if the first SIM is requesting a special adjustment/release, as described in more detail herein. From the network perspective, the first and second SIMs of the UE may be operated in an independent manner, allowing the first and second SIMs to belong to different network carriers.

Certain aspects of the present disclosure provide a signaling extension for MSIM UEs for communicating information regarding the MSIM configuration to the network. For example, certain aspects provide techniques for UE UE MSIM capability reporting and updating (e.g., whether the UE supports dual receive (DR)-DSDS, single receive (SR)-DSDS, the RAT combination of the SIMs (e.g., NR/NR, or LTE/NR)), and UE capability update of a state of a second SIM such as deactivation of a second SIM or update to a discontinuous reception (DRX) cycle, or change of the RAT associated with the second SIM.

Certain aspects also provide techniques for requesting UE configuration adjustment. For example, requesting UE configuration adjustment may involve a UE specific DRX cycle or paging position change, UE radio resource control (RRC) connection suspension request, UE tune-away event reporting, informing the network of the pattern, timing, and duration of periodic or aperiodic tune-away events, and resource allocation prescheduling, as described in more detail herein. Certain aspects also provide a recovery mechanism from abnormal states that may be detected, and in some cases, caused by the tune-away periods described herein. For example, the recover mechanism may involve downlink (DL) and uplink (UL) link efficiency recovery, secondary cell (SCELL) state synchronization, UL timing synchronization, or bandwidth part (BWP) synchronization with the network.

Certain aspects provide discovery techniques for an extended signaling protocol which may be used for communicating capability information associated with the MSIM deployment. For example, the UE and network entity may exchange information regarding whether each of the UE and network entity support the extended signaling protocol.

<FIG> is a flow diagram illustrating example operations <NUM> for wireless communication, in accordance with certain aspects of the present disclosure. The operations <NUM> may be performed, for example, by a UE (e.g., such as the UE <NUM> in the wireless communication network <NUM>).

Operations <NUM> may be implemented as software components that are executed and run on one or more processors (e.g., controller/processor <NUM> of <FIG>). Further, the transmission and reception of signals by the UE in operations <NUM> may be enabled, for example, by one or more antennas (e.g., antennas <NUM> of <FIG>). In certain aspects, the transmission and/or reception of signals by the UE may be implemented via a bus interface of one or more processors (e.g., controller/processor <NUM>) obtaining and/or outputting signals.

The operations <NUM> begin, at block <NUM>, by the UE receiving a first message from a network entity enquiring regarding information associated with a MSIM capability of the UE, and at block <NUM>, the UE determining the information associated with the MSIM capability of the UE in response to the inquiry from the network entity. At block <NUM>, the UE communicates one or more messages to indicate the information regarding the multi-SIM capability to the network entity.

<FIG> is a flow diagram illustrating example operations <NUM> for wireless communication, in accordance with certain aspects of the present disclosure. The operations <NUM> may be performed, for example, by a network entity (e.g., such as a BS <NUM> in the wireless communication network <NUM>). The operations <NUM> may be complimentary operations by the network entity to the operations <NUM> performed by the UE.

Operations <NUM> may be implemented as software components that are executed and run on one or more processors (e.g., controller/processor <NUM> of <FIG>). Further, the transmission and reception of signals by the BS in operations <NUM> may be enabled, for example, by one or more antennas (e.g., antennas <NUM> of <FIG>). In certain aspects, the transmission and/or reception of signals by the BS may be implemented via a bus interface of one or more processors (e.g., controller/processor <NUM>) obtaining and/or outputting signals.

The operations <NUM> begin, at block <NUM>, by the network entity generating a first message enquiring regarding information associated with a MSIM capability of a UE, and at block <NUM>, by the network entity transmitting the first message to the UE. At block <NUM>, the network entity communicates one or more messages to obtain the information regarding the MSIM capability.

Certain aspects may also involve the UE receiving a system information block (SIB) indicating that the network entity supports a signaling protocol (e.g., referred to herein as an extended NR signaling (ENS) protocol), the one or more messages being communicated in response to the indication that the network entity supports the signaling protocol. In other words, the extended NR signaling discovery may involve the network broadcasting a system information block (e.g., SIB1) having padding (e.g., reserve bits) used to identify the network entity as an ENS capable network. In certain aspects, the UE may also transmit an extended signaling message identifying the UE as an ENS capable UE. After this discovery procedure, the operations <NUM> and <NUM> may begin for communicating the one or more messages indicating the MSIM capability of the UE. In certain aspects, the UE may indicate to the network entity a change of capability, such as a tag change of standard capabilities, or tag change of ENS capabilities.

<FIG> is a call flow diagram <NUM> illustrating example operations for discovery of ENS protocol support and capability transfer, in accordance with certain aspects of the present disclosure. As illustrated, at step <NUM> of the call flow diagram <NUM>, the UE <NUM> may optionally transmit an indication to the network entity that the UE is ENS capable. At step <NUM> of the call flow diagram <NUM>, the network entity <NUM> (e.g., gNB) may transmit a message enquiring about the UE capability associated with the MSIM capability, and at step <NUM>, the UE <NUM> may transmit an ENS capability report indicating the UE capability.

The ENS capability report may indicate the capability of the UE <NUM> with respect to MSIM, such as whether the UE <NUM> supports DSDA, SR-DSDS, or DR-DSDS. The UE may also indicate the type of a RAT associated with a second SIM of the UE (e.g., NR, long-term evolution (LTE), universal mobile telecommunications service (UMTS), global system for mobile communications (GSM)) in addition to the RAT (NR) of the first SIM of the UE <NUM>.

Certain aspects also provide techniques for providing a capability update with regards to the second SIM, a RAT change, or deactivation of the second SIM in a similar manner, but with the second SIM information updated or removed. In certain aspects, the capability exchange may include indications of a supported media access control (MAC) control element (MCE) set, a logical channel identifier (LCID), and multiple gap pattern capability, as described in more detail herein.

In certain aspects, the UE <NUM> may transmit a UE <NUM> configuration adjustment request to the network entity, which may involve a UE specific DRX cycle or paging position change, and UE RRC connection suspend or RRC connection release with resource block (RB) suspend (e.g., replaced by NR RRC connection resume). For example, the UE configuration adjustment request may request that an adjustment be made to UE specific DRX cycle during an idle mode of operation at the UE. For example, the UE may negotiate a preferred DRX with the network entity to adjust the DRX cycle, as described in more detail with respect to <FIG>.

<FIG> is a flow diagram illustrating example operations <NUM> for wireless communication, in accordance with certain aspects of the present disclosure. The operations <NUM> may be performed by a UE (e.g., UE <NUM>).

The operations <NUM> begin, at block <NUM>, by generating a first message indicating a preferred discontinuous reception (DRX) cycle of a user-equipment (UE) for reception via a radio-access technology (RAT) associated with a subscriber identify module (SIM) of a multi- SIM deployment of the UE, at block <NUM>, transmitting the first message to a network entity, and at block <NUM>, receiving a second message indicating another DRX cycle to be applied for reception via the RAT after transmitting the first message.

<FIG> is a flow diagram illustrating example operations <NUM> for wireless communication, in accordance with certain aspects of the present disclosure. The operations <NUM> may be performed by a network entity.

The operations <NUM> begin, at block <NUM>, by receiving a first message indicating a preferred discontinuous reception (DRX) cycle of a user-equipment (UE) for reception via a radio-access technology (RAT) associated with a subscriber identify module (SIM) of a multi- SIM deployment of the UE, at block <NUM>, generating a second message indicating another DRX cycle to be applied for the reception via the RAT after receiving the first message, and at block <NUM>, transmitting the second message.

<FIG> is a call flow diagram illustrating example operations <NUM> for negotiating a DRX cycle (e.g., paging cycle), in accordance with certain aspects of the present disclosure. As illustrated, the UE may transmit a tracking area update (TAU) message indicating a DRX change request. For example, there may be a scenario where two sub paging occasions collide with each other when using a certain DRX cycle. Therefore, certain aspects of the present disclosure allow a UE <NUM> to indicate a preferred DRX cycle to the network entity, reducing the likelihood of paging collision.

The DRX change request may indicate a preferred DRX cycle of the UE <NUM>. The preferred DRX cycle may be indicated using an offset value with reference to a reference DRX cycle. The network entity <NUM> (e.g., gNB) may then response with a TAU accept message. The TAU accept message may either accept the preferred DRX cycle of the UE <NUM>, or indicate a different DRX cycle to be used. For example, the network entity <NUM> may indicate an offset value with reference to the preferred DRX cycle indicated by the UE <NUM>. The network entity <NUM> may then apply the negotiated DRX cycle (e.g., changed DRX cycle and offset) for the UE <NUM> while the UE <NUM> is in RRC idle mode. By allowing for the negotiation of the DRX cycle, page collision between the different sub paging occasions (e.g. used for gaming) may be reduced.

Certain aspects of the present disclosure are generally directed to a UE specific connected-mode DRX (CDRX) cycle and offset adjustment request. Certain aspects, provide a protocol to allow the UE to negotiate with the network regarding a preferred CDRX configuration including CDRX length and offset. This protocol for negotiating a CDRX configuration may increase power savings by allowing a UE to request a longer CDRX length (e.g., for both single SIM or multi-SIM configurations), while also allowing for the avoidance of collision between one CDRX subsystem and another CDRX or DRX page occasion (e.g., for DSDS MSIM specific configuration). The protocol also allows for the avoidance of transmit and receive interference between two subsystems (e.g., for DSDA MSIM).

<FIG> is a call flow diagram illustrating example operations <NUM> for negotiating a CDRX cycle, in accordance with certain aspects of the present disclosure. As illustrated, the UE <NUM> may be in RRC connected mode and may transmit a CDRX change request to the network entity <NUM>, indicating a preferred CDRX and offset value. The network entity <NUM> may then respond with an RRC reconfiguration message including the network agreed CDRX and offset, which may be the same or different than the preferred CDRX cycle indicated by the UE <NUM>. The UE <NUM> may then transmit an RRC reconfiguration completely message, after which the negotiated CDRX and offset may be applied for communication.

The negotiation of the CDRX cycle and offset value allows for power saving and reduction of CDRX collision with other sub paging occasions for a DSDS system. Negotiating the CDRX cycle and offset value may also reduce CDRX receive interference during transmissions of the other subsystem (e.g., transmission for a RAT of a second SIM) assuming a DSDA system is implemented.

The operations <NUM> begin, at block <NUM>, by generating a radio resource control (RRC) request, the RRC request comprising an indication of whether the RRC request is requesting an RRC release or an RRC suspension with respect to a subscriber identify module (SIM) of a multi-SIM deployment of the UE, at block <NUM>, transmitting the RRC request to a network entity, and at block <NUM>, receiving an RRC message from the network entity confirming the RRC request.

The operations <NUM> begin, at block <NUM>, by receiving a radio resource control (RRC) request from a user-equipment (UE), the RRC request comprising an indication of whether the RRC request is requesting an RRC release or an RRC suspension with respect to a subscriber identify module (SIM) of a multi-SIM deployment of the UE, at block <NUM>, generating an RRC message confirming the RRC request, and at block <NUM>, transmitting the RRC message to the UE.

<FIG> is a call flow diagram illustrating example operations <NUM> for requesting RRC release of the UE, in accordance with certain aspects of the present disclosure. For example, the UE <NUM> may send an ENS-RRC connection release request to the network entity <NUM> having an indication (e.g., rrcReleaseType field) that indicates whether the request is for RRC release or suspension. As illustrated in <FIG>, the UE may send an RRC release request with an indication (e.g., rrcReleaseType field) that the request is for an RRC release of the UE <NUM>. The network entity <NUM> then sends an RRC release message. The network entity <NUM> then assumes that the UE will enter an RRC idle mode and removes the RRC context of the UE, as illustrated. The UE may later send an RRC setup request, receive an RRC setup message, and transmit an RRC setup complete message to reenter RRC connected mode, after which ENS context configuration may be communicated between the UE <NUM> and the network entity <NUM>, as described herein.

When a UE decides to respond to a page in a second system corresponding to a second SIM of the UE, or when the UE needs to perform some signaling activity in the second system, the UE may stop the current activity in the first system corresponding to a first SIM of the UE. Without the ability to suspend any ongoing activity for the first system, the UE may autonomously release the RRC connection with the first system, which may be interpreted as an error case by the first system and has the potential to distort the statistics in the first system, and misguide the algorithms that rely on them. Moreover, during the UE's absence, the first system may continue paging the UE which may result in waste of paging resources. Certain aspects of the present disclosure are directed to RRC suspension techniques that allow a UE to temporarily leave and return to the first system in a network-controlled manner.

<FIG> is a call flow diagram illustrating example operations <NUM> for requesting RRC suspension of the UE, in accordance with certain aspects of the present disclosure. In this case, the RRC connection release request may indicate (e.g., via the rrcReleaseType field) that the RRC connection release request is requesting a suspension of the RRC connection (e.g., as opposed to a release of the RRC connection). The network entity <NUM> may then send an RRC release message. In this case, the RRC release message may include an indication (e.g., via an RRCRelease information element(s) (IE)) indicating an RRC suspension configuration (e.g., a paging cycle during the suspension period). The network entity <NUM> then assumes the UE <NUM> is in RRC inactive state and keeps the UE's ENS context.

The UE <NUM> may then resume the RRC connected mode by transmitting an RRC connection resume message, which may be followed by an RRC resume message transmitted by the network entity <NUM>, and a transmission of an RRC resume complete message from the UE <NUM>. In certain aspects, the network entity <NUM> may optionally send an RRC reconfiguration to reconfigure the ENS setup after RRC resume is complete.

Certain aspects of the present disclosure are generally directed to an ENS protocol implemented using a specific logical channel identifier (LCID), as described in more detail herein. An ENS protocol supported network entity may be able to handle a MAC control element (MCE) with a specified LCID.

<FIG> illustrate MCEs <NUM>, <NUM> having LCID fields, in accordance with certain aspects of the present disclosure. The LCID of the MCE may be used to indicate that the MCE is for a purpose such as for a UE periodic/aperiodic tune-away gap registration and update, UE periodic gap deregistration, UE tune-back indication, UE physical uplink shared channel (PUSCH) prescheduling, SCELL state synchronization, downlink (DL)/uplink (UL) spectrum efficiency recovery, UL timing synchronization, and bandwidth part (BWP) synchronization, as described in more detail herein. The length of ENS MAC CE may be variable when reporting different MSIM events, as illustrated in <FIG>. In certain aspects, an MCE may be piggybacked on data payloads on an UL-shared channel (SCH). The ENS MCE may be identified by a MAC protocol data unit (PDU) subheader with the LCID specified by an ENS network entity in the ENS configuration for UL and DL separately. For example, different ENS MCEs may be indicated by a type field of the MCE.

Operations <NUM> may be implemented as software components that are executed and run on one or more processors (e.g., controller/processor <NUM> of <FIG>). Further, the transmission and reception of signals by the UE in operations <NUM> may be enabled, for example, by one or more antennas (e.g., antennas <NUM> of <FIG>). In certain aspects, the transmission and/or reception of signals by the UE may be implemented via a bus interface of one or more processors (e.g., controller/processor <NUM>) obtaining and/or outputting signals. The operations <NUM> begin, at block <NUM>, by the UE <NUM> generating at least one control element (CE) (e.g., MAC CE (MCE)) having information indicating at least one tune-away period of a RAT associated with a multi-SIM capability of the UE. At block <NUM>, the UE transmits the at least one CE indicating the at least one tune-away period to a network entity.

The operations <NUM> begin, at block <NUM>, by the network entity <NUM> receiving at least one control element (CE) having information indicating at least one tune-away period of a RAT associated with a multi-SIM capability of the UE, and at block <NUM>, communicating with the UE in accordance with the indication of the at least one tune-away period.

<FIG> is a call flow diagram illustrating example operations <NUM> for registering or updating a periodic tune-away gap configuration, in accordance with certain aspects of the present disclosure. An MCE for UE periodic tune--away gap registration and update may be used to register/update periodic tune-away gaps of a RAT (e.g., of a second SIM of the UE) with the network entity. The UE informs the network entity about the periodic gap pattern (e.g., the upcoming start time and the DRX cycle), tune-away type and UE Tx/Rx capability during the tune-away duration via a periodic gap registration MCE, as illustrated. Upon successful UE periodical tune-away gap registration, the network entity <NUM> is expected to derive ongoing UE periodical gap pattern based on the UE tune-away gap registration for further processing and send an acknowledgement MCE to the UE within a certain time period (e.g., a DSDS-MCE-ACK-Timer). Otherwise, the UE may resend the periodic registration MCE, as illustrated in <FIG> until an acknowledge MCE is sent by the network entity.

In certain aspects, the UE may send another periodic gap registration MCE to update the periodic gap information previously registered. The UE may register multiple periodic gap patterns which may be indicated by different pattern indices.

<FIG> illustrates fields of a periodic tune-away gap MCE <NUM>, in accordance with certain aspects of the present disclosure. As illustrated, the periodic tune-away gap MCE <NUM> may include an MCE type indication to indicate whether the MCE <NUM> is for a periodic or aperiodic tune away registration or update. The MCE <NUM> may also include a tune-away type indication. For example, the tune-away type indication may indicate a full tune-away (e.g., that no Rx/Tx capability is available during tune-away periods on all carriers), or a partial tune-away (e.g., that a limited Rx/Tx capability is available during tune-away periods). The MCE <NUM> may also indicate a tune-away start time, which may be indicated in sub-frame or in sub-frame plus an offset within <NUM>. The resolution for indicating the start time may higher than conventional implementations, such as <NUM> or <NUM> to accommodate various NR slots. The MCE may also include a value tag that may uniquely identify the MCE <NUM> and indicate whether network acknowledgement is required.

In certain aspects, the MCE <NUM> also includes a periodic timing advance (TA) pattern index, as well as indicate a periodic tune-away pattern, DRX cycle length index, DRX index for the periodic tune-away pattern, a typical tune-away duration for the periodic tune-away periods, and Rx/Tx capability during the tune-away periods. The indications of the MCE <NUM> may be reported for each of the active carriers at the UE.

<FIG> is a call flow diagram illustrating example operations <NUM> for registering an aperiodic tune-away gap, in accordance with certain aspects of the present disclosure. As illustrated, an MCE may be used by the UE <NUM> to inform the network entity <NUM> about the aperiodic gap information and supported Tx/Rx capability during the tune-away gap. Network acknowledgement may not be expected by the UE <NUM> for the aperiodic gap registration MCE. In some cases, the network entity <NUM> may respond to the UE with a scheduling request (SR) probe to restore DL/UL scheduling accordingly. In certain aspects, when the aperiodic tune-away gap overlaps with a periodic tune-away gap, the network entity <NUM> may override the periodic tune-away gap temporarily.

In certain aspects, the MCE may indicate a maximum aperiodic tune-away gap duration. When the actual aperiodic tune-away gap duration is longer than the maximum tune-away gap duration reported via the MCE, the network entity <NUM> may remove the ENS context of the UE <NUM> and send an RRC release message to the UE <NUM>, assuming that the UE <NUM> has entered RRC idle mode, as illustrated.

<FIG> illustrates an MCE <NUM> for registering an aperiodic tune-away gap, in accordance with certain aspects of the present disclosure. As illustrated, the MCE <NUM> for UE aperiodic tune-away gap registration and update may include an MCE type indication, periodic/aperiodic tune-away indicator, tune-away type (e.g., full tune-away or partial tune-away), tune-away start time, and a value tag similar to the MCE <NUM> described for the periodic tune-away gap registration. The MCE <NUM> may also include a maximum aperiodic gap length indicator, as described herein.

<FIG> illustrates an acknowledgement MCE <NUM> (e.g., for acknowledging the MCE <NUM> for the periodic tune-away gap registration), in accordance with certain aspects of the present disclosure. For example, the network entity may acknowledge the MCE <NUM> by sending the acknowledge MCE <NUM> within the DSDS-MCE-ACK-Timer as described with respect to <FIG>, or otherwise, the UE may resend the MCE. The acknowledgment MCE <NUM> may include MCE type indication and a value tag uniquely identifying the MCE, as illustrated.

<FIG> is a call flow diagram illustrating example operations <NUM> for periodic tune-away gap deregistration, in accordance with certain aspects of the present disclosure. For example, an MCE may be used to cancel an originally registered periodical tune-away registration identified by a given periodic tune-away pattern. As illustrated, an acknowledgement timer may also be set for the periodic tune-away gap deregistration, during which the network entity is to send an acknowledgement of the MCE for periodic tune-away gap deregistration. Otherwise, the UE may retransmit the periodic tune-away gap deregistration MCE, as illustrated.

<FIG> illustrates an MCE <NUM> for periodic tune-away gap deregistration, in accordance witch certain aspects of the present disclosure. As illustrated, the MCE <NUM> transmitted by the UE used for deregistration may include MCE type indication and a periodic TA pattern index to indicate the periodic tune-away pattern index that is to be deregistered. The MCE <NUM> may also include a value tag as described herein.

Certain aspects provide techniques for a UE to transmit a UE tune-back indication to a network entity. For example, the UE <NUM> may send a tune-back indication MCE to inform the network entity that the UE's Tx/Rx capability has been restored when the aperiodic tune-away gap ends.

<FIG> is a timing diagram illustrating an example periodic tune-away gap, in accordance with certain aspects of the present disclosure. As illustrated, the indicated duration <NUM> (e.g., the tune-away duration indicated via MCE <NUM>) for the periodic tune-away gaps may be less than an actual duration of the periodic tune-away gap <NUM>. In this case, the UE <NUM> may send a tune-back indication MCE <NUM> to the network entity <NUM> indicating that the UE's Tx/Rx capability has been restored, as illustrated.

<FIG> illustrates a tune-back indication MCE <NUM>, in accordance with certain aspects of the present disclosure. As illustrated, the MCE <NUM> may include an MCE type indication, a tune-away type to indicate the tune-away gap type (e.g., periodic or aperiodic) of the tune-back MCE, and a value tag as described herein.

Certain aspects provide techniques for a UE PUSCH prescheduling. In some cases, the UE periodic gap pattern, including the reference gap start, gap duration, and Tx/Rx capability of a carrier (e.g., LTE carrier), changes frequently. Therefore, it is important for the UE to be able to update the periodic gap registration in time to keep the UE and the network entity in sync. In certain aspects, the network entity <NUM> may preschedule resources for the UE to transmit the updated tune-away configurations before the periodic tune-away gap begins in order to reduce the potential gap update delay. In otherwords, without prescheduling resources for the UE, the UE may have to send a scheduling request (SR) to receive a grant of resources to transmit the updated configuration. By receiving a prescheduled resource pattern, which may be indicated in a PUSCH prescheduling MCE, the UE may transmit the updated configuration with reduced overhead after a periodic tune-away gap has ended.

The operations <NUM> begin, at block <NUM>, by negotiating a prescheduled resource allocation with a network entity prior to a start of periodic tune-away periods, at block <NUM>, generating a message indicating an update to a periodic tune-away gap configuration associated with the periodic tune-away periods, and at block <NUM>, transmitting the message via the prescheduled resource allocation.

The operations <NUM> begin, at block <NUM>, by negotiating a prescheduled resource allocation with a user-equipment (UE) prior to a start of periodic tune-away periods, and at block <NUM>, receiving a message indicating an update to a periodic tune-away gap configuration associated with the periodic tune-away periods.

<FIG> illustrates an MCE <NUM> for PUSCH prescheduling, in accordance with certain aspects of the present disclosure. As illustrated, the MCE <NUM> may include an MCE type indication, periodic TA pattern index (e.g., indicate the periodic tune-away pattern index for the PUSCH prescheduling), a schedule advance (e.g., the preferred schedule advance in milliseconds (ms) or <NUM>/N milliseconds before the start time of the periodical gap, N being an integer greater than <NUM>), the schedule grant size (e.g., the preferred UL grant size in bytes), and a value tag, as illustrated.

<FIG> is a call flow diagram illustrating example operations <NUM> for secondary cell (SCELL) synchronization, in accordance with certain aspects of the present disclosure. As illustrated, an MCE may be transmitted by a UE to synchronize the SCELL state when the UE detects that a certain SCELL state mismatch occurs. For example, there may be a mismatch with the network with regards to the number of active carriers used for communication at the UE. For instance, prior to a time-away period, a UE may be configured with multiple carriers, however, during the tune-away period, the network may have adjusted the number of active carriers such that the UE is assigned a single carrier for communication. Thus, the UE may continue to monitor multiple carriers (primary carrier of a primary cell (PCELL) and one or more secondary carriers of one or more SCELLs) after the tune-away period, when only a single carrier (primary carrier) is registered for the UE by the network. In this case, the UE may send an acknowledgment for multiple carriers, based on which the network may determine that the number of carriers configured at the UE is mismatched with the network, and indicate this mismatch to the UE.

The network entity may send an activation/deactivation MCE to the UE if the network finds that a certain SCELL state is out of sync with the UE, as described herein. The UE may then follow the activation/deactivation MCE with the synchronized SCELL state. The MCE for the SCELL synchronization may include an MCE type indication and SCELL state indication where a '<NUM>' (e.g., logic low state of a bit) indicates that the SCELL with SCell index i is in deactivated state and where a '<NUM>' (e.g., logic high state of a bit) indicates that the SCELL is activated.

<FIG> illustrates an MCE <NUM> for SCELL synchronization, in accordance with certain aspects of the present disclosure. As illustrated, the MCE <NUM> includes an MCE type indication and an indication of the SCELL state, as described herein.

<FIG> illustrates an MCE <NUM> for DL/UL link efficiency recovery, in accordance with certain aspects of the present disclosure. For example, when a UE detects that DL/UL link efficiency recovery on any carrier is required, the UE may send a DL/UL link efficiency recovery MCE to the network including an indication of the expected DL CSI (e.g., rank, channel quality indicator (CQI)) or UL CSI (e.g., pathloss, power headroom (PHR)) on a per carrier basis. The network is then able to reset the DL/UL rate control loop bias on a per carrier basis. The MCE for link efficiency recovery may include an MCE type indication, DL CSI (e.g., indicating the DL carrier RI and CQI per carrier), and UL CSI (e.g., indicating the UL pathloss and PHR per carrier), as described herein.

<FIG> is a call flow diagram illustrating example operations <NUM> for UL timing synchronization, in accordance with certain aspects of the present disclosure. As illustrated, when a UE detects abnormal UL timing information from a specific timing advance group (TAG), the UE transmits an UL timing synchronization MCE to the network entity. The network entity then triggers an UL synchronization procedure. For example, the network may send DCI with a physical downlink control channel (PDCCH) order to the UE. PDCCH Order is a mechanism by which the network entity may force the UE to initiate a random access channel (RACH) procedure. The UE then initiates the RACH procedure by transmitting a random access preamble. The network sends timing advance (TA) command in a random access response (RAR) message of the RACH procedure, allowing the UE to adjust the timing advance for communication according to the TA value. The network may also transmit an RRC connection reconfiguration message, which may be followed by the UE transmitting an RRC connection reconfiguration complete message, as illustrated.

<FIG> illustrates an MCE <NUM> for UL timing synchronization, in accordance with certain aspects of the present disclosure. The MCE <NUM> for UL timing synchronization may include an MCE type indication and UL timing synchronization indication (e.g., where '<NUM>' indicates that synchronization on TAG i is needed). Certain aspects are generally directed to a BWP synchronization MCE to implement a signaling agreement regarding a BWP to be used for transmission if there is a BWP mismatch detected. The signaling agreement allows for the UE to indicate a preferred BWP. BWP synchronization as described herein allows for a more efficient synchronization of BWP when the mismatch is detected between the UE and the network. For example, the UE may inform the network of the preferred BWP based on channel conditions, which may more effective from UE's perspective.

The operations <NUM> begin, at block <NUM>, by detecting that a bandwidth part (BWP) setting at a user-equipment (UE) is out of sync with a network entity, at block <NUM>, generating a control element (CE) indicating that the BWP setting is out of sync, the CE indicating a preferred BWP of the UE, at block <NUM>, transmitting the CE to the network entity, and at block <NUM>, receiving downlink control information (DCI) indicating a new BWP to use for communication with the network entity.

The operations <NUM> begin, at block <NUM>, by receiving a control element (CE) indicating that a bandwidth part (BWP) setting at a user-equipment (UE) is out of sync with the network entity, the CE indicating a preferred BWP of the UE, at block <NUM>, generating downlink control information (DCI) indicating a new BWP to use for communication with the network entity based on the CE, and at block <NUM>, transmitting the DCI to the UE.

<FIG> illustrates an MCE <NUM> for bandwidth part (BWP) synchronization, in accordance with certain aspects of the present disclosure. When a UE detects that a BWP is out-of-sync with the network, the UE may send a BWP synchronization MCE <NUM> on a default BWP with a preferred BWP index set. The BWP used for communication may be out of sync with the network after a tune-away period during which the network may have reconfigured the BWP for the UE. The network triggers a BWP switch by scheduling a DCI, the DCI indicating a BWP to be used by the UE. The UE then follows the BWP indicated in the DCI for communication. The MCE <NUM> for the BWP synchronization may include an MCE type indication, and BWP sync required indication, as illustrated.

<FIG> illustrate wireless communication systems <NUM>, <NUM> for coexistence with extended LTE signaling (ELS) in a non-standalone (NSA) deployment, in accordance with certain aspects of the present disclosure. NSA deployment allows for <NUM> networks to be supported by existing <NUM> infrastructure. For NSA with and an ELS capable eNB configured as an MeNB and a none enhanced network selection (ENS) capable gNB configured as an SgNB <NUM> as illustrated in <FIG>, an NSA UE may establish an ELS context (e.g., periodic/aperiodic gap information as described herein) with the ELS capable MeNB. The MeNB then informs the SgNB <NUM> of the periodic/aperiodic gap information to synchronize the scheduling on both the MeNB and SgNB <NUM>. For NSA with LTE ELS capable eNB configured as MeNB and an ENS capable gNB configured as SgNB <NUM> as illustrated in <FIG>, the UE establishes ELS context with the ELS capable MeNB (e.g., via RRC) and establishes the ENS context with ENS capable SgNB (e.g., via RRC). In other words, the UE registers LTE MSIM events and NR MSIM events on the MeNB and SgNB <NUM> independently (e.g., via L2 layer signaling).

<FIG> illustrates a communications device <NUM> that may include various components (e.g., corresponding to means-plus-function components) configured to perform operations for the techniques disclosed herein.

The processing system <NUM> includes a processor <NUM> coupled to a computer-readable medium/memory <NUM> via a bus <NUM>. In certain aspects, the computer-readable medium/memory <NUM> is configured to store instructions (e.g., computer-executable code) that when executed by the processor <NUM>, cause the processor <NUM> to perform the operations described herein, or other operations for performing the various techniques discussed herein In certain aspects, computer-readable mediam/memory <NUM> stores code <NUM> for receiving a message (e.g., one of various MCEs described herein, or message enquiring about UE capability), code <NUM> for generating (e.g., for transmission via bus <NUM>) a message (e.g., one of various MCEs described herein, or message enquiring about UE capability), and code <NUM> for determining capability information. In certain aspects, the processor <NUM> has circuitry configured to implement the code stored in the computer-readable medium/memory <NUM>. The processor <NUM> includes circuitry <NUM> for receiving a message (e.g., MCE), code <NUM> for generating a message (e.g., MCE), and code <NUM> for determining capability information.

For example, instructions for performing the operations described herein.

Claim 1:
A method for wireless communication by a user-equipment, UE (<NUM>), comprising:
receiving (<NUM>) a first message from a network entity enquiring regarding information associated with a multi-subscriber identify module, SIM, capability of the UE (<NUM>);
determining (<NUM>) the information associated with the multi-SIM capability of the UE (<NUM>) in response to the enquiry from the network entity; and
communicating (<NUM>) one or more messages to indicate the information regarding the multi-SIM capability to the network entity; wherein communicating the one or more messages comprises:
transmitting a radio resource control, RRC, request to the network entity, the RRC request comprising an indication of whether the RRC request is requesting an RRC release or an RRC suspension of the UE; and
receiving an RRC message from the network entity confirming the RRC request.