Method and user equipment (UE) for reporting UE capabilities of multi-subscriber identity module (MUSIM) UE

Abstract

The present disclosure relates to a 5G or 6G communication system for supporting a higher data transmission rate. Embodiments of the present disclosure disclose a method and user equipment (104) for reporting user equipment (UE) capabilities for a multi-subscriber identity module (MUSIM) UE. The method includes receiving, by the UE (104) from a network entity (108), a request to transmit UE capabilities. The method includes determining, by the UE (104), whether the UE (104) is capable of reporting a change in one or more gap requirements, wherein the change in one or more gap requirements is due to MUSIM operation. The method includes transmitting, by the UE (104), UE capabilities that report one or more gap requirements to a network entity (108).

Description

Technical Field

[0001] This disclosure relates to communication networks. More specifically, this disclosure relates to a method for reporting the capabilities of a Multi Subscriber Identity Module (MUSIM) UE and the UE thereof. Background Technology

[0002] 5G mobile communication technology defines a wide frequency band, enabling high transmission rates and new services. It can be implemented not only in the "sub-6 GHz" band, such as 3.5 GHz, but also in the "above 6 GHz" band (including 28 GHz and 39 GHz), known as millimeter waves. Furthermore, the implementation of 6G mobile communication technology (called "super 5G systems") in terahertz bands (e.g., the 95 GHz to 3 THz band) is being considered to achieve transmission rates fifty times faster than 5G and ultra-low latency one-tenth that of 5G.

[0003] In the early stages of 5G mobile communication technology development, to support services and meet performance requirements for enhanced mobile broadband (eMBB), ultra-reliable and low-latency communication (URLLC), and massive machine-type communication (mMTC), the following technologies have been standardized: beamforming and massive MIMO for reducing radio wave path loss and increasing radio wave transmission distance in millimeter waves; support parameters for dynamic operation (e.g., operating multiple subcarrier spacings) for efficient utilization of millimeter wave resources and time slot formats; initial access technologies to support multi-beam transmission and wideband; definition and operation of BWP (bandwidth portion); new channel coding methods such as LDPC (low-density parity-check) codes for large data transmissions and polar codes for highly reliable transmission of control information; L2 preprocessing; and network slicing for providing dedicated networks for specific services.

[0004] Currently, regarding the services supported by 5G mobile communication technology, the industry is continuously discussing improvements and performance enhancements to the initial 5G mobile communication technology, and physical layer standardization has been completed for technologies such as: V2X (vehicle-to-everything) for assisting driving decisions and improving user convenience based on information sent by the vehicle about its location and status; NR-U (New Radio Unlicensed) designed to comply with various regulatory requirements for system operation in unlicensed frequency bands; NR UE power saving; non-terrestrial networks (NTNs) for direct satellite communication between UEs to ensure coverage in areas where they cannot communicate with terrestrial networks; and positioning.

[0005] Furthermore, standardization of air interface architectures / protocols for technologies such as: Industrial Internet of Things (IIoT) for supporting new services through interoperability and integration with other industries; IAB (Integrated Access and Backhaul) for providing nodes for network service area expansion by supporting wireless backhaul and access links in an integrated manner; mobility enhancements including conditional handover and DAPS (Dual Active Stack) handover; and two-step random access (2-step RACH for NR) for simplifying the random access process. Simultaneously, standardization of system architectures / services for technologies such as: 5G baseline architectures (e.g., service-based architectures or service-based interfaces) for combining Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies; and Mobile Edge Computing (MEC) for receiving services based on UE location.

[0006] With the commercialization of 5G mobile communication systems, an exponential increase in connected devices will be added to communication networks, thus necessitating enhanced functionality and performance of 5G mobile communication systems and the integrated operation of connected devices. To this end, new research is underway on the following technologies: Extended Reality (XR) for efficient support of AR (Augmented Reality), VR (Virtual Reality), MR (Mixed Reality), etc.; 5G performance improvements and complexity reductions through the utilization of Artificial Intelligence (AI) and Machine Learning (ML); AI service support; Metaverse service support; and drone communication.

[0007] Furthermore, this development of 5G mobile communication systems will not only lay the foundation for the development of technologies such as: new waveforms for providing coverage in the terahertz band of 6G mobile communication technology; multi-antenna transmission technologies such as full-dimensional MIMO (FD-MIMO), array antennas, and massive MIMO; metamaterial-based lenses and antennas for improving terahertz band signal coverage; high-dimensional spatial multiplexing technologies using OAM (orbital angular momentum); and RIS (reconfigurable smart surfaces), but will also lay the foundation for the development of technologies such as: full-duplex technologies for improving the frequency efficiency of 6G mobile communication technology and improving system networks; AI-based communication technologies for system optimization from the design stage by leveraging satellites and AI (artificial intelligence) and internalizing end-to-end AI support functions; and next-generation distributed computing technologies for providing services at complexity levels exceeding the operational limits of UEs by utilizing ultra-high-performance communication and computing resources.

[0008] Multiple Subscriber Identity Module (MUSIM) devices (i.e., MUSIM User Equipment (UEs) hosting more than one Subscriber Identity Module (SIM)) are capable of connecting to two or more different networks. MUSIM UEs connect to two or more different networks to utilize different data plans, leverage user profiles (such as for home and office), enhance connectivity, improve the reliability of multiple connections, and so on. Multiple SIMs can participate in one or more operations (also known as MUSIM operations), such as paging reception, System Information Block (SIB) acquisition, measurement, data or voice calls, Multicast and Broadcast Service (MBS) reception, emergency calls, Access Stratum (AS) signaling, Non-Access Stratum (NAS) signaling, etc. Some of these operations are periodic, such as paging and measurement. Some operations are non-periodic and indeterminate, such as signaling. The duration required to complete an operation can also be fixed or unpredictable.

[0009] UE capabilities include information associated with the UE's gap requirements. Gap requirements are crucial for performing measurements and mobility. MUSIM UEs report gap requirements based on configurations from the network. When the state of any USIM changes, the gap requirements of other USIMs are affected. However, unless the network configures the UE to report gap requirements arising from MUSIM operations, the network cannot know the gap requirements in the UE's capabilities. Therefore, MUSIM UEs cannot perform measurements or actions such as "Secondary Cell Addition," "Handover," "Beam Failure Recovery," "Synchronization Reconfiguration," "Downlink (DL)," "Uplink (UL)," and "Schedule Request (SR)," thus reducing network connectivity.

[0010] The information disclosed in the background section of this disclosure is intended only to enhance the understanding of the general background of this disclosure and should not be construed as an admission or in any way an implication that the information constitutes prior art known to those skilled in the art. Summary of the Invention

[0011] Technical issues

[0012] This disclosure provides a method for reporting the capabilities of a UE with a Multiple Subscriber Identity Module (MUSIM) UE, and the UE thereof.

[0013] Problem Solution

[0014] The foregoing overview is merely illustrative and is not intended to be limiting in any way. Further aspects, embodiments, and features, in addition to the illustrative aspects, embodiments, and features described above, will become apparent from the accompanying drawings and the following detailed description.

[0015] In one embodiment, a method for reporting the capabilities of a Multi-Subscriber Identity Module (MUSIM) User Equipment (UE) is disclosed. The method includes the UE receiving a request from a network entity to transmit UE capabilities. The method includes the UE determining whether it is capable of reporting changes to one or more gap requirements. The changes to the one or more gap requirements are caused by MUSIM operation. The method includes the UE transmitting the UE capability to report one or more gap requirements to the network entity.

[0016] In one embodiment, a method for configuring UE capabilities for a MUSIM UE is disclosed. The method includes a network entity receiving UE capabilities from the UE containing information related to one or more gap requirements arising from MUSIM operation. The method includes the network entity determining a temporary UE capability configuration based on the one or more gap requirements. The method includes the network entity sending the temporary UE capability configuration to the UE.

[0017] In one embodiment, a MUSIM UE for reporting UE capabilities is disclosed. The UE includes a memory configured to store instructions. The UE includes a processor configured to execute the instructions stored in the memory, thereby being configured to receive a request from a network entity to transmit UE capabilities. The processor is configured to determine whether the UE is capable of reporting changes to one or more gap requirements. The changes to one or more gap requirements are caused by MUSIM operation. The processor is configured to transmit the UE capability to report one or more gap requirements to the network entity.

[0018] In one embodiment, a network entity for configuring UE capabilities for a MUSIM UE is disclosed. The network entity includes a memory configured to store instructions. The network entity includes a processor configured to execute the instructions stored in the memory, thereby being configured to receive from the UE UE UE equilateral information relating to one or more gap requirements arising from MUSIM operation. The processor is configured to determine a temporary UE capability configuration based on the one or more gap requirements. The processor is configured to send the temporary UE capability configuration to the UE.

[0019] In one embodiment, a method for configuring user equipment (UE) capabilities is disclosed. The method includes receiving temporary UE capability restrictions and one or more frequency band lists from a centralized unit (CU) by a distributed unit (DU). The CU receives temporary UE capability restrictions caused by Multi-Subscriber Identification Module (MUSIM) operation from the UE. The temporary UE capability restrictions indicate temporary radio frequency capabilities of frequency bands in one or more frequency band lists configured in the UE. The method includes identifying, by the DU, affected and restricted frequency bands caused by MUSIM operation from the temporary UE capability restrictions based on the one or more frequency band lists. The method includes generating a UE configuration based on the affected and restricted frequency bands in the UE via the CU based on the identification.

[0020] In one embodiment, a DU for configuring UE capabilities is disclosed. The DU includes a memory configured to store instructions. The DU includes a processor configured to execute the instructions stored in the memory, thereby being configured to receive temporary UE capability restrictions and one or more frequency band lists from a CU. The CU receives temporary UE capability restrictions from the UE caused by Multi-Subscriber Identity Module (MUSIM) operation. The temporary UE capability restrictions indicate temporary radio frequency capabilities of frequency bands in one or more frequency band lists configured in the UE. The processor is configured to identify affected and restricted frequency bands caused by MUSIM operation from the temporary UE capability restrictions based on one or more frequency band lists. The processor is configured to generate a UE configuration based on the affected and restricted frequency bands in the UE via the CU based on this identification.

[0021] In one embodiment, a network for configuring UE capabilities is disclosed. The network includes a CU and a DU. The CU includes a processor configured to execute instructions stored in memory, thereby being configured to receive from the UE temporary UE capability restrictions resulting from MUSIM operation. The temporary UE capability restrictions indicate temporary radio frequency capabilities of frequency bands in one or more frequency band lists configured in the UE. The processor is configured to transmit the temporary UE capability restrictions and one or more frequency band lists to the DU of the network. The DU includes a processor configured to execute instructions stored in memory, thereby being configured to receive the temporary UE capability restrictions and one or more frequency band lists from the CU. The processor is configured to identify affected and restricted frequency bands caused by MUSIM operation from the temporary UE capability restrictions based on one or more frequency band lists. The processor is configured to generate a UE configuration based on the affected and restricted frequency bands in the UE via the CU based on this identification.

[0022] Advantages of the invention

[0023] According to one embodiment of this disclosure, a method for reporting the capabilities of a UE with a Multiple Subscriber Identity Module (MUSIM) UE and the UE thereof are provided. Attached Figure Description

[0024] The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate exemplary embodiments and, together with the description, serve to explain the disclosed principles. The same reference numerals are used throughout the drawings to designate features and components. Some embodiments of at least one apparatus and method according to the subject matter of this disclosure will now be described by way of example only and with reference to the accompanying drawings, wherein: Figure 1 The following are examples of environments in which some embodiments of this disclosure may be practiced; Figure 2 A UE 104 for reporting UE capabilities according to an embodiment of this disclosure is shown; Figure 3 A sequence flow of a method 300 for reporting UE capabilities for a MUSIM UE according to an embodiment of this disclosure is shown; Figure 4 A sequence flow of a method 400 for configuring UE capabilities for a MUSIM UE according to an embodiment of the present disclosure is shown; Figure 5 A method 500 for reporting UE capabilities for a MUSIM UE according to an embodiment of this disclosure is illustrated; Figure 6 A method 600 for configuring UE capabilities for a MUSIM UE according to embodiments of the present disclosure is illustrated; Figure 7 A block diagram is shown for implementing an exemplary computer system 700 consistent with embodiments of the present disclosure; Figure 8 A flowchart illustrating a report interruption request according to some embodiments of this disclosure is shown; Figure 9 A flowchart illustrating the updating of temporary capability limitation or interruption request via UAI according to some embodiments of this disclosure is shown; Figure 10 The illustration shows representations of MUSIM dual Rx / dual Tx operation according to some embodiments of this disclosure. otherconfig A flowchart for the RRC reconstruction process; Figure 11 The illustration shows representations of MUSIM dual Rx / dual Tx operation according to some embodiments of this disclosure. otherconfig A flowchart for the RRC recovery process; Figure 12 The process of handling the expiration of the MUSIM wait timer according to embodiments of the present disclosure is described; Figure 13 The process of a UE reporting cell reselection measurements after a temporary capability limitation is described according to embodiments of the present disclosure; Figure 14 The process of reporting measurement gap requirements for LTM according to embodiments of this disclosure is described; Figure 15 A flowchart is shown of the operation (in DC) of the secondary node (SN) of the MUSIM wait timer according to an embodiment of the present disclosure; Figure 16 A flowchart illustrating the operation (in DC) of the MUSIM wait timer according to an embodiment of this disclosure is shown; Figure 17 The operation of the control unit (CU) of the MUSIM wait timer according to an embodiment of the present disclosure is illustrated; Figure 18 The distributed unit (DU) operation of the MUSIM wait timer according to an embodiment of the present disclosure is illustrated; Figure 19 User equipment (UE) operation of the MUSIM wait timer according to an embodiment of the present disclosure is illustrated; Figure 20 The following are examples of environments in which certain embodiments of this disclosure may be practiced; Figure 21 A sequence flow of a method 2100 for configuring UE capabilities according to an embodiment of the present disclosure is shown; Figure 22 A flowchart of a method 2200 for configuring UE capabilities according to an embodiment of the present disclosure is shown; Figure 23 The overall NG-RAN architecture based on the 3GPP specification TS 38.401, according to existing technology, is shown; Figure 24 The CU operation for temporary capability limitations is illustrated according to embodiments of the present disclosure; and Figure 25 The DU operation for temporary capability limitations is illustrated according to an embodiment of this disclosure.

[0025] The accompanying drawings illustrate embodiments of the present disclosure for illustrative purposes only. Those skilled in the art will readily recognize from the following description that alternative embodiments of the structures and methods shown herein can be employed without departing from the principles of the present disclosure described herein. Detailed Implementation

[0026] In this document, the word "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any embodiment or implementation of the subject matter of this disclosure described herein as "exemplary" is not necessarily to be construed as preferred or advantageous relative to other embodiments.

[0027] While this disclosure is susceptible to various modifications and alternatives, specific embodiments of this disclosure have been illustrated by way of example in the accompanying drawings and will be described in detail below. However, it should be understood that this disclosure is not intended to be limited to the specific forms disclosed, but rather, this disclosure is intended to cover all modifications, equivalents, and alternatives falling within the spirit and scope of this disclosure.

[0028] The terms “comprises,” “comprising,” or any other variations thereof are intended to cover non-exclusive inclusion, such that an arrangement, apparatus, or method that includes a list of components or steps includes not only those components or steps but may also include other components or steps not expressly listed or inherent to such arrangement, apparatus, or method. In other words, without further constraints, the inclusion of one or more elements in an apparatus, system, or device that begins with “comprises…” does not exclude the presence of other elements or additional elements in that apparatus, system, or device.

[0029] In the following detailed description of embodiments of this disclosure, reference is made to the accompanying drawings, which form a part of the detailed description, and specific embodiments in which this disclosure may be practiced are illustrated by way of example. These embodiments are described in sufficient detail to enable those skilled in the art to practice this disclosure, and it should be understood that other embodiments may be utilized and changes may be made without departing from the scope of this disclosure. Therefore, the following description should not be considered limiting.

[0030] It should be noted that, for ease of explanation, this disclosure uses the terms and names defined in the 3GPP Radio Access Network (3GPP RAN) standard. More specifically, the terms “gap requirement,” “measurement gap requirement,” “Network Control Small Gap (NCSG) requirement,” “interruption requirement,” etc., should be interpreted in accordance with the relevant 3GPP standards.

[0031] It should be noted that, for ease of explanation, this disclosure uses the terms and names defined in the 3GPP RAN standard. More specifically, the terms “musim-capacity-limited,” “RRC_IDLE,” “RRC_Inactive,” “RRC_CONNECTED,” “secondary cell addition,” “handover,” “beam fault recovery,” “synchronization reconfiguration,” “downlink (DL),” “uplink (UL),” “scheduling request (SR),” “RSRP,” “nr-NeedForGap-Reporting,” “nr-NeedForInterruptionReport,” and “nr-NeedForGapNCSG-Reporting” should be interpreted in accordance with the 3GPP RAN standard.

[0032] Overview

[0033] Multi-SIM Devices and Simultaneous RRC Connection Support: Multi-SIM (MUSIM) devices host more than one Subscriber Identity Module (SIM), enabling them to connect to two or more different networks (NWs) to utilize different data plans, have user profiles (such as home and office), and improve connectivity / reliability through multiple connections. These devices are becoming increasingly popular. One or more of the multiple SIMs can participate in paging reception, System Information Block (SIB) acquisition, measurement, data or voice calls, Multicast and Broadcast Service (MBS) reception, emergency calls, Access Stratum (AS) signaling, Non-Access Stratum (NAS) signaling, etc. Some of these operations are periodic, such as paging and measurement, while others are non-periodic and / or indeterminate, such as signaling. Furthermore, the duration required to complete an operation can be fixed or unpredictable.

[0034] Multi-SIM devices are categorized into different types based on the number of Rx (receive) and Tx (transmit) chains, such as single Rx single Tx, dual Rx single Tx, dual Tx single Rx, and dual Rx dual Tx. An Rx or Tx link includes RF circuitry and associated hardware and software components for receiving and transmitting, respectively. Dual Rx dual Tx devices can typically support simultaneous RRC connections across multiple subscribers. These devices are sometimes also referred to as dual-stack dual-active (DSDA) devices. Single Rx single Tx, dual Rx single Tx, and dual Tx single Rx devices can also support multiple simultaneous RRC connections through methods that share their Rx and Tx links and switch them as needed.

[0035] RRC Status: In Near Field Radio (NR), Radio Resource Control (RRC) is in one of three states: RRC Idle, RRC Inactive, or RRC Connected. A UE with RRC Connected is in Connection Management (CM)-Connected (i.e., connected to the 5G core network) and can communicate with the network via unicast and multicast / broadcast traffic. The network stores the UE Access Layer (AS) context, understands the UE at the cell level, and controls UE mobility. The UE performs measurements and reports them to the network to provide channel quality, feedback information, etc.

[0036] RRC inactivity is a state in which the UE remains in a CM-connected state and moves within an area configured by a Next Generation Radio Access Network (NG-RAN) (a 5G RAN consisting of gNodeBs (gNBs)) without notifying the NG-RAN. In RRC inactivity, the last serving gNB node preserves the UE context and the NG connection associated with the UE (i.e., the connection to the core network). Because the RRC configuration and the connection to the core network are still preserved in RRC inactivity, the UE immediately transitions to an RRC-connected state and transmits data with the core network or applications. The UE initiates the transition from RRC inactivity to RRC connection by sending an RRC recovery request.

[0037] In RRC Idle mode, neither the UE nor the gNB stores any AS context. The UE is in CM_IDLE (i.e., no connection to the core network). The UE establishes a new connection by sending an RRC Establish Request message, and the gNB sends an RRC Establish Message to transition to an RRC connection. The UE and the NW (both the RAN and the core network) exchange messages to move the UE to CM_CONNECTED.

[0038] UE Capabilities: In technologies such as 5G NR, different UEs can have different hardware and software capabilities. These different capabilities can be hardware capabilities, including radio frequency capabilities (such as supported frequency bands or combinations of frequency bands), processing capabilities (such as baseband computing capabilities), software capabilities (such as support for various features), Layer 1 capabilities, Layer 2 capabilities, Layer 3 capabilities, and so on. Typically, the UE reports its UE radio access capabilities, which are static at least when the network requests these capabilities. To limit signaling overhead, the gNB requests the UE to provide NR capabilities for a restricted set of frequency bands. In response, if the corresponding UE capabilities are the same, the UE can skip a subset of the requested frequency band combinations. If supported by both the UE and the network, the UE can provide an ID in NAS signaling to reduce signaling overhead; this ID represents its radio capabilities for one or more radio access technologies (RATs). This ID can be assigned by the manufacturer or the serving Public Land Mobile Network (PLMN). Manufacturer-assigned IDs correspond to a pre-supplied set of capabilities. In the case of PLMN-assigned IDs, the assignment is done in NAS signaling. A detailed list of UE capabilities exchanged using the methods described above is specified in 3GPP technical specifications (such as TS 38.306). The gNB provides various configurations / features to the UE based on the reported UE capabilities via RRC messages (such as RRC reconfiguration or RRC recovery). Furthermore, a 5G gNB may contain a Central Unit (CU) and a Distributed Unit (DU).

[0039] In a MUSIM device that supports multiple simultaneous RRC connections on multiple USIMs, the UE capabilities of the USIMs connected to the RRC connection in the MUSIM device change when other USIMs move from RRC idle or RRC inactive to RRC connection (or vice versa). For example, the supported frequency bands may change.

[0040] Measurement Intervals: In wireless technologies such as NR and LTE, UEs connected via Radio Resource Control (RRC) perform various measurements for Radio Resource Management (RRM) purposes, positioning, etc. For RRM, the UE measures reference signals such as synchronization signals / PBCH blocks (SSB), Channel State Information Reference Signals (CSI-RS), etc., and reports the measurement results to the network.

[0041] According to NR specification TS 38.300, measurements performed by the UE for connected mode mobility are divided into at least four types, including intra-frequency NR measurements, inter-frequency NR measurements, E-UTRA inter-RAT measurements, and UTRA inter-RAT measurements.

[0042] One or more measurement objects are defined for each measurement type, such as the carrier frequency to be monitored. One or more reporting configurations are defined for each measurement object (the reporting configuration defines the reporting criteria). Three reporting criteria are used: event-triggered reporting, periodic reporting, and event-triggered periodic reporting. The association between a measurement object and a reporting configuration is created by a measurement identifier (the measurement identifier links a measurement object and a reporting configuration within the same RAT). The measurement identifier is also used when reporting measurement results. For positioning, the UE can report SSB / CSI-RS measurements and can also report measurements based on additional reference signals (such as PRS).

[0043] When the SSB is not fully included in the active DL BWP and the UE needs to measure inter-frequency NR, perform inter-RAT measurements, or perform intra-frequency measurements outside the active downlink BWP, the UE can use measurement gaps. Measurement gaps are configured by the network (e.g., the gNB in ​​the NR) and no transmissions or receptions occur during the gap period. Measurement gap configurations include gap offset, gap length, repetition period, and measurement gap timing advance. The gap offset specifies the subframe in which the measurement gap begins. The gap length gives the duration of the gap, while the repetition period defines the frequency at which the measurement gap occurs.

[0044] NeedForGaps: NR UEs report NeedForGaps to indicate whether they need a gap to measure a specific NR band. In Release 17, NeedForGaps was expanded to allow UEs to report whether they need a gap or Network Control Small Gap (NCSG) to measure a specific NR band. Starting with 3GPP Release 17, UEs also indicate whether they need a gap or NCSG to measure E-UTRA bands.

[0045] The network configures the UE to provide measurement gap requirement information for the NR target band by setting needForGapsConfigNR to established during RRC reconfiguration or RRC recovery. In Release 17, the network configures the UE to provide measurement gap and NCSG requirement information for the E-UTRA target band by setting needForNCSG-ConfigEUTRA to established during RRC reconfiguration or RRC recovery. Similarly, in Release 17, the network configures the UE to provide measurement gap and NCSG requirement information for the NR target band by setting needForNCSG-ConfigNR to established during RRC reconfiguration or RRC recovery.

[0046] Once configured, the UE retains this configuration until it is released or modified, and notifies the network of the gap requirements for the NR band, or the gap and NCSG requirements for the NR and E-UTRA bands. The UE includes gap (or gap and NCSG) requirements in both RRC recovery completion and RRC reconfiguration completion. If the gap or gap and NCSG requirements change after reconfiguration, the UE will report the changed requirements in the RRC reconfiguration completion. The UE reports a set of capabilities to inform the network that it supports needforgaps / needforgas and ncsg or requires interruption.

[0047] The UE can also support inter-frequency and intra-frequency measurements based on NR SSB, with interrupts that can be performed without gaps. To support this, 3GPP introduced a set of changes in the NR 18 specification.

[0048] <1> A new indicator (needForInterruptionInfoNR) is introduced for the Rel-18 case, where for seamless... Gap-based measurements using NR SSB require interruption. The Rel-18 indication can be included in RRCReconfigurationComplete and... In the RRCResumeComplete message.

[0049] <2> Rel-18 indication is a supplement to the traditional NeedForGapsInfoNR information. The UE can report the following three types of... Same situation: If a gap is required, the UE reports "gap" in the Rel-16 field and "empty" in the corresponding R18 IE. Field.

[0050] If no gap is required and there is no interruption, the UE reports "no gap" in the Rel-16 field, and The Rel-18 field reports "no gaps, no interruptions".

[0051] If no gap is required but an interruption exists, the UE reports "no gap" in the Rel-16 field, and in the Rel- The report in field 18 states "No gaps, but interruptions".

[0052] <3> The UE will only include this information when requested by the network via the control flag (needForInterruptionConfigNR). Rel-18 directive (needForInterruptionInfoNR).

[0053] <4> Add UE capability to indicate whether the UE supports reporting interruption requests in RRC response messages.

[0054] As in needForInterruptionInfoNR The information reported in the report can be referred to as an interruption request. The following is a set of exemplary changes in TS 38.331 for this situation:

[0055] Framework for Supporting Capability Variation: Let's consider a MUSIM UE with two USIMs (i.e., two UEs within the same MUSIM device), UE-A (USIM-A) and UE-B. This MUSIM UE supports dual transmit and receive, meaning both UE-A and UE-B are connected simultaneously (RRC connection). Both UE-A and UE-B can transmit or receive data concurrently. UE-A and UE-B can share some RF / radio / hardware / software resources. UE-A's UE capabilities (such as the UE radio access capabilities described in 3GPP specifications (e.g., TS 38.306)) can vary at different times depending on whether UE-B is connected (i.e., depending on whether UE-B uses RF / radio / hardware / software resources).

[0056] Considering that UE-A and NW-A are in an RRC connection state, and UE-B (USIM-B) is entering or transitioning to an RRC connection, UE-A provides information to NW-A to release certain resources or update some parameters for MUSIM operation. This information involves changes to some capabilities in UE-A, the release of SCGs or SCells in UE-A, the deactivation of SCGs or SCells in UE-A, information on establishing or activating SCGs or SCells in UE-A, and information related to measurement gap requirements (needforgaps / needforgapsorncsg) in UE-A to facilitate MUSIM operation.

[0057] When UE-A is in RRC connection mode and its capabilities change due to activity in UE-B, UE-A notifies NW-A of the capability change via RRC messages (such as UE assistance information).

[0058] If UE-A's capabilities change due to UE-B's activity while UE-A is in RRC idle or RRC inactive mode, a method similar to that used for RRC connection is used. UE-A can also indicate a capability change in RRC establishment request / RRC recovery request, RRC establishment completion, or RRC recovery completion. Capabilities can then be retrieved via UAI (UE Assistance Information), etc.

[0059] UE-A can report a change in capabilities, or it can report a changed capability based on a specific action in UE-B. When UE-B switches from a licensed frequency to an unlicensed frequency or from one frequency range (FR) to another FR, UE-A can report the capability change to NW-A.

[0060] NW-A can configure the UE-A regarding its ability to notify of changes, for example, via RRC reconfiguration messages. otherConfigIn other words, the network can be accessed through " otherConfig "Controls whether the UE-A can update its changed capabilities." otherConfig There may be a single enumerated parameter or several other parameters that can be used for control, which notify the UE-A of the ability to report changes. Alternatively, each of these individual capabilities that can change can be configured in... otherConfig The UAI contains a separate identifier. Therefore, the UE can report updated or changed capabilities via UE Assistance Information messages. The information content in the UAI can involve MUSIM Assistance Information or MUSIM UE Capability Information. A disable timer can be configured to control the frequency at which the UE can report capability updates. Capability updates (e.g., those involving the scheduling mode and / or TDD UL / DL configuration information of UE-B, which act as a capability constraint on UE-A (e.g., the number of Tx / Rx)) are not static or completely disabled. Therefore, the UE can initiate a UAI to handle such updates when the disable timer is not running.

[0061] NW-A can configure filters for UE-A, and UE-A reports capability changes based on these filters. For example, if a capability included in the filter changes, UE-A can report that capability change. If no capability in the filter changes due to UE-B's action, UE-A may not initiate a message to indicate a UE capability change. An exemplary set of IEs included in the filter is requestedFreqBandsNR-MRDC, requestedCapabilityNR, the eutra-nr-only flag, requestedCapabilityCommon, and UE-CapabilityRequestFilterNR.

[0062] If the frequency band supported by the changed capabilities differs from the old capabilities, the NW-A can reconfigure the UE-A to release one or more SCells, SCGs, or perform a handover. The NW-A can also configure the UE-A to report any available measurements when capabilities have changed. Because the changed capabilities may differ from the old capabilities, the NW-A may be more inclined to modify SCells or SCGs rather than release them, or in some cases, perform a handover to a different frequency. Measurements from the UE can help the network make such decisions.

[0063] Static or dynamic capability signaling reported by the UE may include: the number of Rx links, the number of Tx links, the maximum number of MIMO layers, support for CA or DC on the NW B, the processing capability for supported component carriers or dual connectivity on the NW A, the configuration of one or more SCells / SCGs on the NW A, requests for activation, deactivation, and release of at least one of them, supported frequency bands or combinations of frequency bands, UL or DL ​​TDD configuration, scheduling information or configuration, DRX configuration on the NW B, measurement configuration on the NW B, IDC-related configuration or parameters, power control or backoff parameters, supported frequencies or restricted frequencies, etc.

[0064] The network utilizes the updated capabilities received from the UE and reconfigures the UE using the updated parameters. The network can update the configurations of dual connectivity, carrier aggregation, power control, interference coordination, DAPS configuration, number of layers, etc., based on capability information (including supported frequency bands, supported frequency band combinations, scheduling modes, and / or TDD UL / DL configuration information, etc.).

[0065] As mentioned above, changes to UE capabilities can be either restrictions on UE capabilities or the removal of those restrictions. That is, when a capability change is mentioned, it can mean that some capabilities are restricted, or some restrictions are removed. The UE can report supported capabilities (e.g., supported frequency bands or combinations of supported frequency bands or supported frequencies, measurement gap requirements after applying the restriction, maximum number of MIMO layers supported after the restriction) to notify of the restriction. Alternatively, the UE can report restricted capabilities (e.g., unsupported frequency bands or combinations of unsupported frequency bands or unsupported frequencies). Reporting changed or restricted capabilities can mean reporting both restricted and supported capabilities after the restriction.

[0066] Reporting changes to capabilities or the removal of restricted capabilities can mean reporting the capabilities that are supported after the restriction is removed. As mentioned earlier, the terms "temporary capability change," "temporary capability restriction," etc., can be used to refer to changes in capabilities or restrictions on capabilities.

[0067] As mentioned earlier, when the change is applied to a MUSIM operation, terms such as "report of changed capabilities of a MUSIM operation", "report of removal of restricted capabilities of a MUSIM operation", "temporary capability change of a MUSIM operation", and "temporary capability restriction of a MUSIM operation" can also be used to refer to the capability change, capability restriction, or removal of capability restriction.

[0068] When UE-B is not in an RRC connection, the capabilities possessed by UE-A can be referred to as permanent UE capabilities of UE-A. That is, when UE-B is in an RRC idle or RRC inactive state, the capabilities in UE-A can be referred to as temporary UE capabilities of UE-A. In other words, when UE-B does not share radio, software, RF, hardware, or any other resources for dual receive and transmit, the capabilities in UE-A can be referred to as permanent UE capabilities of UE-A in the context of MUSIM.

[0069] In the current system, permanent UE capabilities are reported using the UE capability transfer procedure. The gNB requests the UE to report its capabilities by sending a UECapabilityEnquiry message, and the UE reports its capabilities using a UECapabilityInformation message. Different radio technologies (such as 6G) may have messages with similar functionality, and these embodiments apply equally to them. The reported capabilities are sent to the core network and stored there, so that these capabilities do not need to be sent over the air whenever the UE moves from RRC idle or RRC inactive to RRC connected. The UECapabilityEnquiry message may contain filters, such as CapabilityRequestFilter, so that the UE reports only the information required by the network.

[0070] A UE reporting temporary capability restrictions can send a list of restricted capabilities, a list of supported capabilities, or a list of changed capabilities. The UE can also notify the network that once the restriction is removed, the capability restrictions caused by MUSIM operation are also removed.

[0071] UE-A can report temporary capability limitations either proactively or passively. In proactive mode, UE-A can report capability limitations without considering UE-A's current RRC configuration (i.e., from NW-A). In passive mode, UE-A can report a subset of these capability limitations to NW-A at a time, based on UE-A's current RRC configuration.

[0072] Consider 3GPP specifications v17.5.0 (such as TS 38.331, TS 38.300, TS 38.306 and TS 38.321) as relevant background.

[0073] Furthermore, consider a scenario where a MUSIM device has two USIMs, USIM-A (also known as UE-A) and USIM-B (also known as UE-B), where USIM-A (UE-A) is in an RRC connection or is moving to an RRC connection, and USIM-B (UE-B) is in an RRC idle or RRC inactive state. This device simultaneously supports multiple RRC connections; that is, both USIM-A (UE-A) and USIM-B (UE-B) can be in an RRC connection simultaneously. If UE-B moves from an RRC idle or RRC inactive state to an RRC connection, or due to any other trigger in UE-B, the interruption requirement of UE-A will change. Currently, there is no available method to report changes in interruption requirements caused by such current MUSIM actions to the network. Furthermore, a method is needed that enables UE-A to notify the NW-A of its ability to report such gap requirements or gap and interruption requirements.

[0074] This topic proposes a method for User Equipment (UE-A) to report its ability to report temporary capability limitations to Network NW-A. Furthermore, this topic also proposes a method for Network NW-A to configure UE-A to report temporary capability limitations.

[0075] In various embodiments, this topic proposes a method for configuring the UE-A to handle temporary capability limitations during various events such as RRC reconstruction or transition to RRC inactivity.

[0076] This topic describes methods and systems for operating a Dual Rx / Dual Tx Multi-Subscriber Identity Module (MUSIM) User Equipment (UE) in a fifth-generation (5G) network (NW). The network in this topic primarily refers to NG-RAN, although the core network is not excluded for some functions.

[0077] For example, consider two USIMs, USIM-A or UE-A (the radio protocol stack technically associated with USIM-A) and USIM-B or UE-B (the radio protocol stack technically associated with USIM-B), and their corresponding networks, Network A (NW-A) and Network B (NW-B). Furthermore, assume that UE-A and NW-A are in RRC connected mode, and assume that UE-B is in RRC idle or RRC inactive mode. Figure 8 The flowchart shown represents a request to report an interruption.

[0078] Figure 9A flowchart illustrating UE capabilities and their configuration for temporary capability restrictions is shown. In a non-limiting embodiment, UE-A may proactively notify NW-A of its ability to report (or remove) temporary capability restrictions, independent of its current RRC configuration (i.e., configured by NW-A). This notification can be made using the RRC message UECapabilityInformation in the NR. This can be based on the UE's capabilities without any FDD-TDD differences.

[0079] In a non-limiting embodiment, UE-A may passively notify NW-A of its ability to report temporary capability limitations (or remove temporary capability limitations) based on its current RRC configuration (i.e., configured by NW-A). This notification can be made using the RRC message UECapabilityInformation in the NR. This can be based on the UE's capabilities without any FDD-TDD differences.

[0080] In a non-limiting embodiment, if this is configured by the NW-A, the UE-A can proactively report temporary capability limitations, for example, through... RRC IE otherConfig NW-A can be configured to allow UE-A to report temporary capability restrictions or report the removal of temporary capability restrictions without considering the UE-A's RRC configuration.

[0081] In a non-limiting embodiment, if this is configured by the NW-A, the UE-A can passively report temporary capability limitations, for example, through... RRC IE otherConfig The NW-A can be configured to report temporary capability restrictions or report the removal of temporary capability restrictions based on the UE-A's RRC configuration.

[0082] In a non-limiting embodiment, if the UE-A is configured to report both passively and actively, the UE-A may passively report temporary capability limitations and may not actively report temporary capability limitations.

[0083] In a non-limiting embodiment, if UE-A is configured to report both passively and actively, UE-A may actively report temporary capability limitations and may not passively report temporary capability limitations. In this embodiment, if UE-A is configured to report both passively and actively, it will passively report measurement gap requirements / power-related requirements / SRS TX handover-related requirements and actively report frequency band / frequency / band combination / maximum MIMO layer.

[0084] In a non-limiting embodiment, once a temporary capability restriction is removed, if the UE-A is configured to actively or passively report the removal of the temporary capability restriction (or the removal of the temporary capability restriction), the UE-A may report the removal of the temporary capability restriction.

[0085] In a non-limiting embodiment, once the temporary capability restriction is removed, if the UE-A has reported the temporary capability restriction to the NW-A and if it is configured to report the temporary capability restriction (or the removal of the temporary capability restriction), the UE-A may report the removal of the temporary capability restriction.

[0086] In a non-limiting embodiment, the UE-A may report the removal of the temporary capability restriction as a single flag, enumeration information, or a single bit of information to notify the NW-A that the temporary capability restriction has been removed and that the UE has previously used... UECapabilityInformation The ability to report. In another embodiment, this could mean that the UE has permanent UE capability.

[0087] In one non-limiting embodiment, if the NW-A is configured to report temporary capability limitations, the UE-A can report the removal of temporary capability limitations. In another non-limiting embodiment, if the network configures the UE-A to report the removal of temporary capability limitations, the UE-A reports the removal of temporary capability limitations. For example, if the UE-A is moved from the NW-A to a new cell via handover, rebuild, or LTM, and the new cell is not configured... otherConfig In this case, UE-A may not report the removal of temporary capability restrictions.

[0088] In a non-limiting embodiment, in a MUSIM device supporting multiple simultaneous RRC connections, when a USIM (e.g., USIM-A / UE-A) is in an RRC connection and an interruption requirement changes due to MUSIM operation (i.e., an action in UE-B), UE-A can report the change in interruption requirement to its network (NW-A) (if UE-A is configured to do so). In this embodiment, UE-A can use UE Assistance Information (UAI) to notify NW-A of the change in interruption requirement. In this embodiment, UE-A can use a single bit of information, enumeration, flags, or any such information to notify NW-A of the change in interruption requirement. In another embodiment, if any of the gap requirement, NCSG requirement, or interruption requirement changes, UE-A can use a single bit of information, enumeration, flags, or any such information to notify NW-A of the change in gap requirement, NCSG requirement, or interruption requirement. In this embodiment, UE-A can notify NW-A of the actual change in interruption requirement.

[0089] In a non-limiting embodiment, UE-A includes the (updated) interruption request in a UE Auxiliary Information message or any other RRC message sent by USIM-A to NW-A to indicate that its capabilities and interruption request have changed due to MUSIM operations such as another UE switching from RRC idle or RRC inactive to RRC connected, or from RRC connected to RRC idle or RRC inactive.

[0090] In a non-limiting embodiment, the UE-A reports an (updated) interruption request or information indicating a change in the interruption request due to MUSIM action only if the interruption request has changed compared to the last interruption request reported due to MUSIM operation or any other purpose.

[0091] In a non-limiting additional embodiment, when UE-A supports a new frequency band due to MUSIM operation or other purposes, and when UE-A does not support an existing frequency band due to MUSIM operation or other purposes, UE-A will report an interruption request to NW-A due to MUSIM operation, even if the interruption request has not changed compared to the last time UE-A reported an interruption request to NW-A.

[0092] If the UE has been configured with a band filter for reporting interruption requests (e.g., in the current NR specification) requestedTargetBandFilterNR If the UE reports an interruption request for the frequency band included in that frequency band filter, then the UE will report the interruption request for that frequency band. This means that if configured... requestedTargetBandFilterNR Then UE in UAI only targets requestedTargetBandFilterNR The frequency band reporting interruption requirement in the UAI, and if requestedTargetBandFilterNCSG-EUTRA is configured, the UE will only request the interruption of the frequency band reporting E-UTRA frequency band in requestedTargetBandFilterNCSG-EUTRA.

[0093] In a non-limiting embodiment, when the band capability in UE-A changes due to MUSIM operation and a band filter is configured in UE-A, UE-A only reports an interruption request for bands supported by UE-A and present in the band filter after the capability change caused by MUSIM operation. This means that USIM-A reports... requestedTargetBandFilterNR or requestedTargetBandFilterNCSG or requestedTargetBandFilterNCSG-EUTRA The interruption requirements of a subset of the frequency bands, and the reduced USIM-A capability due to the UE-B transition. In other words, if the configuration... requestedTargetBandFilterNR or requestedTargetBandFilterNCSG or requestedTargetBandFilterNCSG-EUTRAIf any of these bands are included in the frequency bands that are no longer supported by UE-A after UE-A is in a band where RF capability changes (caused by UE-B transitioning from RRC idle or RRC inactive to RRC connected or other actions), then UE-A will not report interruption requests for these frequency bands.

[0094] If a band filter is not configured at UE-A, UE-A reports a disruption requirement for all supported bands following a capability change caused by an action in UE-B (such as a change in RRC state in UE-B).

[0095] In an alternative embodiment, UE-A may report interruption requests for all frequency bands or all frequency bands included in the frequency band filters supported prior to capability changes due to MUSIM operations (such as UE-B transitioning from RRC idle or RRC inactive to RRC connected).

[0096] In a non-limiting embodiment, before performing a transition from RRC idle or RRC inactive to RRC connected in UE-B, or before performing a transition from RRC inactive or RRC idle to RRC connected in UE-B, UE-A may report an interruption request to NW-A as described in the above embodiments. That is, the UE sends an interruption request to NW-A to wait for RRC reconfiguration before performing the transition in USIM-B.

[0097] Alternatively, UE-A may report the interruption request as described in the above embodiments after performing USIM-B transition from RRC idle or RRC inactive to RRC connected or from RRC inactive or RRC idle to RRC connected. Changes in UE-A's interruption request due to MUSIM operation may be notified to NW-A in an RRCReconfigurationComplete message or an RRCResumeComplete message. In this case, UE-A postpones any measurement requiring a gap based on the changed gap requirement due to MUSIM operation until the RRCReconfigurationComplete message or RRCResumeComplete message is sent. UE-A may notify NW-A of the changed interruption request in a UAI message, and NW-A may trigger an RRCReconfiguration message, and UE-A may report the changed interruption request in the RRCReconfigurationComplete message.

[0098] In a non-limiting embodiment, when MUSIM capabilities change, NW-A can notify UE-A whether to send an interruption request. The network then notifies UE-A whether the UE needs to send updated capability information (changed capabilities, such as physical layer capabilities, layer 2 capabilities, band capabilities, and all other capabilities that may change due to other USIMs changing their RRC states). This information can be used... otherConfig Send, for example, using another Config IE, such as MUSIMCapabilityChangeUpdateConfig.

[0099] In a non-limiting embodiment, the NW-A notifies the UE-A whether to send an interruption request via an RRC message. This can be achieved by... MUSIMCapabilityChangeUpdateConfig This is accomplished by sending an instruction. The UE only does so when it receives... MUSIMCapabilityChangeUpdateConfig An interrupt request is sent only when necessary.

[0100] In another embodiment, if an indication to send updated capabilities is received (e.g., as in...) MUSIMCapabi lityChangeUpdateConfig If (in the middle), then UE-A sends an interrupt request. In an additional embodiment, if it receives from NW-A MUSIMCapabilityChangeUpdateConfig ,as well as NeedForGapsInfoNR or NeedForNCSG-InfoNR or NeedForNCSG-InfoEUTRA If either needForInterruptionConfigNR or one or more of these are selected, then UE-A can send an interruption request or gap and NCSG request to NW-A.

[0101] In an additional embodiment, when UE-B is configured or released using carrier aggregation or dual connectivity, or any such action in UE-B that may change the interruption requirement, UE-A may report an interruption request. These actions may include removing or adding a second SIM, activating or deactivating DSDS / DSDA operating modes, mobility between Rel17 and Rel18 cells / networks, etc.

[0102] In an additional embodiment, UE-A may be configured with a timer that prevents UE-A from reporting changes in capability or interruption requests to NW-A due to MUSIM operations. The timer starts once UE-A sends a capability or interruption request change to NW-A. UE-A will not report any capability or interruption request changes to NW-A until the timer stops or expires. If UE-A receives a different configuration (including a different timer value or even other configurations), the timer can be restarted. Furthermore, different timers may exist for reporting detailed capability changes based on UE-B actions. The timer for detailed reporting can start when a capability or interruption request change is sent and can stop when a different configuration is received.

[0103] In an additional embodiment, when an action in the USIM-B results in an increase or decrease in capability, the NW-A notifies the UE-A whether to report the change in capability or the change in interruption request separately.

[0104] In a non-limiting embodiment, the source gNB transmits an interrupt request received in the UAI due to MUSIM operation to the target gNB during handover.

[0105] In various embodiments, this subject matter discloses UE capabilities for reporting gaps, NCSG, and interruption requests. In one non-limiting embodiment, UE-A informs NW-A whether it supports reporting NCSG and measurement gap request information for SSB-based measurements in the UAI. In an embodiment, UE-A reports this information if it is able to report temporary capability restrictions / removal of temporary capability restrictions for MUSIM operation. In an embodiment, this information can be reported using a conventional NR IE, namely nr-NeedForGapNCSG-Reporting-r17. In an embodiment, a new IE can be used to report this information, which is optional (depending on UE capabilities without distinguishing between FDD-TDD or FR1-FR2).

[0106] Table 1 below provides exemplary specifications derived from TS 38.306 based on the embodiments described above. Table 2 provides alternative specification excerpts.

[0107] Table 1: Exemplary Specifications Excerpted from TS 38.306

[0108] [Table 1]

[0109] In the embodiment, when UE-A has nr-NeedForGapNCSG-Reporting-r17The UE-A is capable of reporting temporary capability limitations / removal of temporary capability limitations during MUSIM operation, and can also report NCSG and measurement gap requirement information for SSB-based measurements in the UAI. In an embodiment, when the UE-A is notified that it has the capability... nr-NeedForGapNCSG- Reporting-r17 When the NW-A notifies the UE-A of the ability to report temporary capability restrictions / removal of temporary capability restrictions on MUSIM operation, the NW-A configures the UE-A to report NCSG and measurement gap requirement information for SSB-based measurements in the UAI. In an embodiment, when the UE-A has the capability to report temporary capability restrictions / removal of temporary capability restrictions on MUSIM operation, the NW-A configures the UE-A to report NCSG and measurement gap requirement information for SSB-based measurements in the UAI. nr-NeedForGapNCSG-Reporting-r17 In addition to reporting temporary capability restrictions / removal of temporary capability restrictions during MUSIM operation, the UE-A reports NCSG and measurement gap requirement information for SSB-based measurements in the UAI.

[0110] Table 2: Exemplary Specifications from TS 38.306

[0111] [Table 2]

[0112] In the embodiment, when UE-A has nr-NeedForGapNCSG-Reporting-r17 When the UE-A is notified that it has the capability to report temporary capability restrictions / removal of temporary capability restrictions in MUSIM operation, it can indicate in the UAI message that there are changes in the NCSG and measurement gap requirement information for SSB-based measurements. In an embodiment, when the UE-A is notified that it has the capability to report temporary capability restrictions / removal of temporary capability restrictions in MUSIM operation, it can indicate in the UAI message that there are changes in the NCSG and measurement gap requirement information for SSB-based measurements. nr- NeedForGapNCSG-Reporting-r17 When the NW-A has the capability and also notifies the UE-A that it can report temporary capability restrictions / removal of temporary capability restrictions for MUSIM operation, the NW-A configures the UE-A to indicate in the UAI message that there is a change in the NCSG and measurement gap requirement information for SSB-based measurements. In an embodiment, when the UE-A has nr-NeedForGapNCSG-Reporting-r17 When the UE-A is able to report temporary capability restrictions / removal of MUSIM operations, it reports in the UAI message that there are changes to the NCSG and measurement gap requirement information for SSB-based measurements.

[0113] In a non-limiting embodiment, UE-A notifies NW-A whether it supports reporting NR target measurement gap requirement information in the UAI. In this embodiment, UE-A reports this information if it is able to report temporary capability limitations / removal of temporary capability limitations for MUSIM operation. In this embodiment, this information can be reported using a conventional NR IE, namely nr-NeedForGap-Reporting-r16. In this embodiment, a new IE can be used to report this information; this new IE is optional (depending on UE capabilities without distinguishing between FDD-TDD or FR1-FR2).

[0114] In a non-limiting embodiment, UE-A may notify NW-A whether it supports reporting changes in NR target measurement gap requirement information in the UAI. In this embodiment, UE-A reports this information if it is able to report temporary capability restrictions / removal of temporary capability restrictions in MUSIM operation. In this embodiment, this information can be reported using a conventional NR IE, i.e., nr-nr-NeedForGap-Reporting-r16. In this embodiment, a new IE can be used to report this information; this new IE is optional (depending on UE capabilities without distinguishing between FDD-TDD or FR1-FR2). Exemplary specification excerpts from TS 38.306 based on the above embodiments are given in Table 3. Alternative specification excerpts are provided in Table 4.

[0115] Table 3: Exemplary Specifications from TS 38.306

[0116] [Table 3]

[0117] In the embodiment, when UE-A has nr-NeedForGap-Reporting-r16 It is capable of reporting temporary capability limitations / removal of temporary capability limitations during MUSIM operation, and can also report NR target measurement gap requirement information in the UAI message. In an embodiment, when notifying UE-A that it has... nr-NeedForGap-Reporting-r16 When the NW-A is capable of reporting temporary capability restrictions / removal of temporary capability restrictions for MUSIM operation, and also notifies the UE-A that it can report such restrictions, the NW-A configures the UE-A to report the measurement gap requirement information for the NR target in the UAI message. In an embodiment, when the UE-A has the capability to report temporary capability restrictions / removal of temporary capability restrictions for MUSIM operation, the NW-A configures the UE-A to report the measurement gap requirement information for the NR target in the UAI message. nr-NeedForGap- Reporting-r16 In addition to reporting temporary capability restrictions / removal of temporary capability restrictions during MUSIM operation, the UE-A reports the measurement gap requirement information for the NR target in the UAI message.

[0118] Table 4: Excerpt of alternative specifications.

[0119] [Table 4]

[0120] In this embodiment, when UE-A has the nr-NeedForGap-Reporting-r16 capability and is also able to report temporary capability restrictions / removal of temporary capability restrictions for MUSIM operation, UE-A can indicate a change in the measurement gap requirement information for the NR target in the UAI message. In this embodiment, when UE-A is notified of having the nr-NeedForGap-Reporting-r16 capability and is also notified of its ability to report temporary capability restrictions / removal of temporary capability restrictions for MUSIM operation, NW-A configures UE-A to indicate a change in the measurement gap requirement information for the NR target in the UAI message. In this embodiment, when UE-A has the nr-NeedForGap-Reporting-r16 capability and is also able to report temporary capability restrictions / removal of temporary capability restrictions for MUSIM operation, UE-A indicates a change in the measurement gap requirement information for the NR target in the UAI message.

[0121] In a non-limiting embodiment, UE-A notifies NW-A whether it supports reporting interruption request information for gapless NR measurement targets in a UAI message. In this embodiment, UE-A reports this information if it can report temporary capability restrictions / removal of temporary capability restrictions for MUSIM operation. In this embodiment, this information can be reported using an IE such as nr-NeedForInterruptionReport-r18, as shown in the background. In this embodiment, a new IE can be used to report this information; this new IE is optional (depending on UE capabilities without distinguishing between FDD-TDD or FR1-FR2).

[0122] In a non-limiting embodiment, UE-A notifies NW-A whether it supports reporting changes to interruption requirement information for measuring NR targets in the UAI message. In this embodiment, UE-A reports this information if it can report temporary capability restrictions / removals of temporary capability restrictions for MUSIM operation. In this embodiment, this information can be reported using an IE such as nr-NeedForInterruptionReport-r18, as shown in the background. In this embodiment, a new IE can be used to report this information; this new IE is optional (depending on UE capabilities without distinguishing between FDD-TDD or FR1-FR2). Exemplary specifications extracted from TS 38.306 according to the above embodiments are given in Table 5. Alternative specification excerpts are given in Table 6.

[0123] Table 5: Exemplary specifications taken from TS 38.306.

[0124] [Table 5]

[0125] In this embodiment, when UE-A has the nr-NeedForInterruptionReport-r18 capability and is also able to report temporary capability restrictions / removal of temporary capability restrictions for MUSIM operation, UE-A can report interruption request information for gapless NR measurement targets in the UAI message. In this embodiment, when UE-A is notified of having the nr-NeedForInterruptionReport-r18 capability and is also notified of its ability to report temporary capability restrictions / removal of temporary capability restrictions for MUSIM operation, NW-A configures UE-A to report interruption request information for gapless NR measurement targets in the UAI message. In this embodiment, when UE-A has the nr-NeedForInterruptionReport-r18 capability and is also able to report temporary capability restrictions / removal of temporary capability restrictions for MUSIM operation, UE-A reports interruption request information for gapless NR measurement targets in the UAI message.

[0126] Table 6: Excerpt of alternative specifications.

[0127] [Table 6]

[0128] In this embodiment, when UE-A has the nr-NeedForInterruptionReport-r18 capability and is also able to report temporary capability restrictions / removal of temporary capability restrictions for MUSIM operation, UE-A can indicate in the UAI message that the interruption requirement information for gapless NR measurement targets has changed. In this embodiment, when UE-A is notified of having the nr-NeedForInterruptionReport-r18 capability and is also notified of being able to report temporary capability restrictions / removal of temporary capability restrictions for MUSIM operation, NW-A configures UE-A to indicate in the UAI message that the interruption requirement information for gapless NR measurement targets has changed. In this embodiment, when UE-A has the nr-NeedForInterruptionReport-r18 capability and is also able to report temporary capability restrictions / removal of temporary capability restrictions for MUSIM operation, UE-A indicates in the UAI message that the interruption requirement information for gapless NR measurement targets has changed.

[0129] Figure 10 The process for configuring and reporting temporary capacity limitations during RRC rebuild or RRC recovery is shown.

[0130] In one non-limiting embodiment, UE-A releases the configuration used to report temporary capability limitations during RRC re-establishment. In this embodiment, when initiating RRC re-establishment, UE-A releases the configuration used to report temporary capability limitations, such as when... otherconfig The configuration received in [the context]. This configuration can be [from / in / the context]. otherConfig The single configuration received in the MUSIM configuration for reporting all temporary capability limitations caused by MUSIM operations can also be a different configuration received in the otherconfig configuration for reporting temporary capability limitations of different capabilities caused by MUSIM operations. Exemplary variations based on Section 5.3.7.2 of 3GPP TS 38.331 are given in Table 7.

[0131] [Table 7]

[0132] Figure 11 The processing of RRC recovery and otherconfig for MUSIM dual Rx / dual Tx operation is illustrated. In a non-limiting embodiment, after initiating RRC recovery, the UE releases the configuration used to report temporary capability limitations. In the embodiment, during the RRC recovery process, the UE releases the configuration used to report temporary capability limitations, such as the configuration received in otherconfig. This configuration can be a single configuration received in otherconfig for reporting all temporary capability limitations caused by MUSIM operation, or different configurations received in otherconfig for reporting temporary capability limitations of different capabilities caused by MUSIM operation. Exemplary variations based on Section 5.3.13.2 of 3GPP TS 38.331 are given in Table 8.

[0133] [Table 8]

[0134] This topic describes methods and systems for operating a Dual Rx / Dual Tx Multi-Subscriber Identity Module (MUSIM) User Equipment (UE) in a fifth-generation (5G) network (NW). This topic includes methods for the UE-A to report its ability to report temporary capability limitations to the network (NW-A). Furthermore, this topic proposes methods for the network NW-A to configure the UE-A to report temporary capability limitations. Additionally, this topic proposes methods for configuring the UE-A to handle temporary capability limitations during various events such as RRC reconstruction or transition to RRC inactivity.

[0135] The proliferation of multi-SIM (MUSIM) devices (hosting more than one Subscriber Identity Module (SIM)) has enabled the ability to connect to two or more different network networks (NWs) to utilize different data plans, have user profiles (such as home and office), and improve connectivity / reliability through multiple connections. Prior to 3GPP's decision to introduce support for MUSIM device operation in Release 17, MUSIM UEs operated without network control by creating arbitrary gaps. Starting with Release 17, the USIM (USIM referred to in this document as the radio protocol stack associated with the UE) connected to a MUSIM device can notify the connected mode network to perform a network handover for multi-SIM operation. Currently, two types of network handover are supported. In the first type, the connected USIM leaves its current network and completely switches to another USIM, i.e., the other USIM becomes connected. In the second type, the connected USIM requests a gap from its network to perform MUSIM operations, such as listening to paging or performing measurements in an idle USIM.

[0136] In Release 17, MUSIM UEs use the RRC UE Assistance Information (UAI) procedure to request gaps or notify departure. The network (gNB) uses the otherConfig in the RRC message to configure the UE to determine whether it can provide MUSIM gap or MUSIM departure assistance information. The Musim-GapAssistanceConfig in otherConfig is used to inform the UE whether it can provide MUSIM assistance information for providing gap information. In Release 17, MUSIM operation is only supported based on the UE's gap.

[0137] In technologies such as 5G NR, different UEs can have different hardware and software capabilities. These different capabilities can be hardware capabilities, including radio frequency capabilities (such as supported frequency bands or combinations thereof), processing capabilities (such as baseband computing capabilities), software capabilities (such as support for various features), Layer 1 capabilities, Layer 2 capabilities, Layer 3 capabilities, and so on. Typically, a UE reports its UE radio access capabilities, which are static, at least when the network requests these capabilities. To limit signaling overhead, a gNB (5G NR base station) can request the UE to provide NR capabilities for a restricted set of frequency bands. In response, if the corresponding UE capabilities are the same, the UE can skip a subset of the requested frequency band combinations.

[0138] The 5G gNB provides various configurations / features to the UE based on the reported UE capabilities via RRC messages (such as RRC reconfiguration or RRC recovery). Furthermore, the 5G gNB can include a CU and a DU. Lower-layer mobility triggering: 3GPP Release 18 is considering lower-layer (L1 / L2) triggered mobility (also known as LTM) to address issues related to latency, signaling overhead, and other problems associated with Layer 3 mobility. According to 3GPP, the goal of LTM is to achieve serving cell change via L1 / L2 signaling to reduce latency, overhead, and downtime. The network (gNB) can configure multiple candidate cells for the UE to allow for rapid application of candidate cell configurations. The network can also send MAC CE or L1 signaling to dynamically switch the UE from the source cell to one of the configured candidate cells. Furthermore, LTM can be triggered based on L1 measurements rather than L3 measurements.

[0139] LTM supports both same-frequency and different-frequency measurements. For different-frequency LTM measurements, a measurement gap may be required.

[0140] [Table 9]

[0141] The relevant background is the 3GPP specifications v18.0.0 and v18.1.0 (such as TS 38.331, TS 38.300, TS 38.306, TS38.321).

[0142] Therefore, there is a need in the field for solutions to overcome the above-mentioned shortcomings (as well as other shortcomings).

[0143] The primary objective of the embodiments described herein is to disclose methods and systems for measuring and processing gaps in NR.

[0144] Another objective of embodiments of this document is to disclose methods and systems for a user equipment (UE) to instruct its ability to report measurement gap requirements, measurement gap and NCSG requirements, and NeedForInterruption requirements in a UAI.

[0145] Another objective of embodiments of this document is to disclose a method and system for a UE to report “cell reselection measurements” if temporary capability limitations exist on certain frequencies.

[0146] Another objective of embodiments of this document is to disclose a method and system for a UE to handle measurement gaps and measurement objects if the UE releases the serving cell as part of its configuration due to the expiration of a waiting timer.

[0147] Another objective of embodiments of this document is to disclose a method and system for a UE to indicate the relationship between gapless LTM measurements and gapless L3 measurements.

[0148] These and other aspects of the embodiments herein will be better understood and appreciated when considered in conjunction with the following description and accompanying drawings. However, it should be understood that the following description is given as illustrative rather than limiting, although it indicates at least one embodiment and its many specific details. Many changes and modifications may be made within the scope of the embodiments herein without departing from their spirit, and the embodiments herein include all such modifications.

[0149] Consider the case of two MUSIM UEs with two USIMs (i.e., two UEs in the same MUSIM device), namely UE-A and UE-B. UE-A notifies its network NW-A of temporary limitations on MUSIM operation capabilities.

[0150] In the embodiments described herein, the UE indicates to the network whether it can report measurement gap requirements to the network in the UAI (as specified in TS 38.331). In the embodiments described herein, the UE sends this indication if nr-NeedForGap-Reporting-r16 is supported. In the embodiments described herein, this can be sent as a new capability. In the embodiments described herein, the indication can be sent as the capability musim-CapabilityRestriction-r18.

[0151] In the embodiments described herein, the UE indicates to the network whether it can report NCSG and measurement gap requirement information for SSB-based measurements to the network in the UAI (as specified in TS 38.331). In the embodiments described herein, the UE sends this indication if nr-NeedForGapNCSG-Reporting-r17 is supported. In the embodiments described herein, this can be sent as a new capability. In the embodiments described herein, the indication can be sent as the capability musim-CapabilityRestriction-r18.

[0152] In the embodiments described herein, the UE indicates to the network whether it can report gapless SSB-based measurement interruption request information toward the NR target in the UAI (as specified in TS 38.331). In the embodiments described herein, the UE sends this indication if nr-NeedForGapNCSG-Reporting-r17 is supported. In the embodiments described herein, this can be sent as a new capability. In the embodiments described herein, the indication can be sent as the capability musim-CapabilityRestriction-r18.

[0153] In the embodiments described herein, according to TS 38.306, [Table 10]

[0154] In the embodiments described herein, a MUSIM UE with temporary capability limitations indicates that reselection measurements are only available if the UE supports at least one frequency listed in measReselectionCarrierListNR in VarMeasReselectionConfig according to the current temporary capability limitations. In the NR, this applies to RRCSetupComplete, RRCResumeComplete, RRCReconfigurationComplete, and other RRC messages that send this indication.

[0155] In the embodiments described herein, a MUSIM UE with temporary capability limitations includes cell reselection measurements (such as measResultReselectionNR) performed only for frequencies listed in measReselectionCarrierListNR in VarMeasReselectionConfig supported by the UE according to the current temporary capability limitations. In the NR, this applies to RRCResumeComplete, UEInformationResponse, and other RRC messages that send this information.

[0156] In the embodiments described herein, TS 38.331 is used.

[0157] [Table 11]

[0158] In the embodiments described herein, if the UE voluntarily releases an SCG or serving cell when a MUSIM wait timer (such as NR timer T348) expires, the UE releases any measurement object or measurement gap configuration associated with the released serving cell. For example, if the released serving cell is included in or indicated by refServCellIndex, deriveSSB-IndexFromCellInter, or refServCellIndicator, the UE releases the corresponding measurement configuration, such as a measurement object configuration or a measurement gap configuration. The network may further add these configurations (if needed).

[0159] [Table 12]

[0160] In the embodiments described herein, if the UE voluntarily releases an SCG or serving cell after the MUSIM wait timer expires, the UE retains the measurement objects and measurement gaps referred to as the released serving cell, but does not use these measurement objects or measurement gaps to perform measurements until they are reconfigured by the network. For example, if the released serving cell is included in or indicated by refServCellIndex, deriveSSB-IndexFromCellInter, or refServCellIndicator, the UE retains the corresponding measurement configurations, such as measurement object configurations or measurement gap configurations, but avoids using them to perform any measurements.

[0161] In the embodiments described herein, if the UE voluntarily releases an SCG or serving cell after the MUSIM wait timer expires, the UE retains the measurement objects and measurement gaps referred to as the released serving cell, and performs measurements using these measurement objects or measurement gaps by treating one of the serving cells (such as PCell or PSCell) as the default cell until the network reconfigures them. For example, if the released serving cell is included in or indicated by refServCellIndex, deriveSSB-IndexFromCellInter, or refServCellIndicator, the UE retains the corresponding measurement configuration, such as the measurement object configuration or measurement gap configuration, but avoids using them to perform any measurements.

[0162] In the embodiments described herein, UEs reporting their ability to perform gapless, SSB-based inter-frequency L1-RSRP measurements (serving cell uninterrupted) for LTM (such as capability 39-2 in the background art) are also notified of their ability to perform SSB-based inter-frequency L1-RSRP measurements (without measurement gaps). In NR, UEs reporting their ability to perform gapless, SSB-based inter-frequency L1-RSRP measurements (serving cell uninterrupted) for LTM (such as capability 39-2 in the background art) also support interFrequencyMeas-NoGap-r16 as described below. interFrequencyMeas-NoGap-r16: interFrequencyMeas-NoGap-r16 indicates whether the UE can perform inter-frequency SSB-based measurements without measurement gaps when the SSB is fully contained within the UE's active BWP (as specified in TS 38.133). If this parameter is indicated differently for FR1 and FR2, each indication corresponds to the frequency range of the cell to be measured.

[0163] If the capability to perform inter-frequency L1-RSRP measurements (serving cell uninterrupted) based on SSB without measurement gaps for LTM (such as capability 39-2 in the background art) has been indicated according to the frequency band combination, and interFrequencyMeas-NoGap-r16 has been indicated for FR1 and FR2 respectively, then the UE also indicates support for interFrequencyMeas-NoGap-r16 for all FRs corresponding to all frequency band combinations, reporting capabilities such as 39-2.

[0164] In embodiments, a UE indicating capability (such as 39-2) also indicates its support for in-frequency L3 measurements without measurement gaps. In embodiments herein, a UE in the NR may indicate support for bwpOperationMeasWithoutInterrupt-r18 in this case. In embodiments herein, a UE in the NR may indicate support for bwpOperationMeasWithoutInterrupt-r18 in this case.

[0165] In an embodiment, the UE indicating capability (such as 39-3-1) also indicates that it supports in-frequency L3 measurements without measurement gaps.

[0166] Figure 12 The process for handling the expiration of the MUSIM wait timer is described. A temporary capability restriction for MUSIM operations is sent to the network, including a request to release the serving cell. The MUSIM wait timer has expired. The serving cell is released, but the measurement objects and measurement intervals related to the serving cell are retained.

[0167] Figure 13 This describes the process by which a UE reports cell reselection measurements after temporary capability limitations. When configuring for cell reselection measurements, some frequency bands may be unavailable due to temporary capability limitations. Availability indications and measurements for cell reselection are reported based on the frequency bands available within the limited capabilities.

[0168] Figure 14 The process for reporting measurement gap requirements for LTM is described. Upon receiving a UE capability query, a check is performed to see if the UE supports interFrequencyMeas-NoGap-r16. If the UE supports interFrequencyMeas-NoGap-r16, the capability bit is set from 39-2 to 1, based on the capability to support gapless LTM measurements. If the UE does not support interFrequencyMeas-NoGap-r16, the capability bit is set from 39-2 to 0.

[0169] The embodiments disclosed herein can be implemented by at least one software program that runs on at least one hardware device and performs network management functions to control network elements. Elements include blocks, which may be at least one of hardware devices or a combination of hardware devices and software modules.

[0170] The embodiments disclosed herein describe methods and systems for measuring and processing gaps in NR (Negative Radio Frequency). Therefore, it should be understood that the scope of protection extends to programs containing, in addition to computer-readable means having messages therein, program code means for implementing one or more steps of the method when the program is run on a server, mobile device, or any suitable programmable device. In at least one embodiment, the method is implemented by or in conjunction with a software program written in, for example, Very High Speed ​​Integrated Circuit Hardware Description Language (VHDL) or another programming language, or by one or more VHDL or several software modules executed on at least one hardware device. The hardware device can be any kind of portable device that can be programmed. The device may also include means that can be, for example, a hardware device (e.g., an ASIC), or a combination of hardware and software devices (e.g., an ASIC and an FPGA), or at least one microprocessor and at least one memory having software modules located therein. The method embodiments described herein can be implemented partly in hardware and partly in software. Alternatively, this disclosure can be implemented on different hardware devices, for example, using multiple CPUs.

[0171] Embodiments of this document disclose methods and systems for measuring and processing gaps in NR. Embodiments of this document disclose methods and systems for a User Equipment (UE) to indicate its ability to report measurement gap requests, measurement gaps and NCSG requests, and NeedForInterruption requests in the UAI. Embodiments of this document disclose methods and systems for a UE to report "cell reselection measurements" when temporary capability limitations exist on certain frequencies. Embodiments of this document disclose methods and systems for a UE to process measurement gaps and measurement objects when a serving cell, as part of its configuration, is released due to a waiting timer expiring. Embodiments of this document disclose methods and systems for a UE to indicate the relationship between gapless LTM measurements and gapless L3 measurements.

[0172] Overall NG-RAN architecture: Overall NG-RAN architecture (such as...) Figure 23 (As shown) in the 3GPP specification TS 38.401 Figure 6As shown in .1-1 (Overall Architecture), the NG-RAN consists of a group of gNBs connected to the 5GC via the NG interface. gNBs can interconnect via the Xn interface. A gNB can consist of a gNB-CU and one or more gNB-DUs. The gNB-CU and gNB-DU are connected via the F1 interface. The CU can send F1AP (F1 Application Protocol) messages to the DU, such as F1AP UE Context Establishment Request and F1AP UE Context Modification Request, to establish or modify the UE context on the DU. The DU will then send an F1AP UE Context Establishment Response or an F1AP UE Context Modification Response indicating success. The CU can also send RRC information from the CU to the DU in the F1AP message to notify of RRC-related information. An example based on the 3GPP specification is given below. The following Information Elements (IEs) contain RRC information sent from the gNB-CU to the gNB-DU.

[0173] [Table 13]

[0174] The following shows an exemplary specification for the "HandoverPreparationInformation" message.

[0175] HandoverPreparationInformation. This message is used to transmit NR RRC information used by the target gNB during handover preparation or UE context retrieval, such as in the case of recovery or re-establishment, including UE capability information. This message is also used to transmit information between the CU and DU. Direction: source gNB / source RAN to target gNB, or CU to DU.

[0176] [Table 14]

[0177] Framework for supporting capability changes:Consider a MUSIM UE with two USIMs (i.e., two UEs within the same MUSIM device), namely UE-A (USIM-A) and UE-B. The MUSIM UE supports dual transmit and receive, meaning UE-A and UE-B can be connected simultaneously (RRC connection). Both UE-A and UE-B can transmit or receive data concurrently. UE-A and UE-B can share some RF / radio / hardware / software resources. UE-A's UE capabilities (such as the UE radio access capabilities described in 3GPP specifications (e.g., TS 38.306)) may vary at different times depending on whether UE-B is connected (i.e., depending on whether UE-B uses RF / radio / hardware / software resources).

[0178] Consider UE-A and NWK-A in an RRC connection state. UE-B (USIM-B) is entering or transitioning to an RRC connection. UE-A provides information to NWK-A to release certain resources or update some parameters for MUSIM operation. This information involves changes to certain capabilities in UE-A, the release or deactivation of SCGs or SCells in UE-A, information on establishing or activating SCGs or SCells in UE-A, and information related to measurement gap requirements (needforgaps / needforgapsorncsg) in UE-A to facilitate MUSIM operation. This change can be a temporary capability restriction or its removal.

[0179] When UE-A is in RRC connection mode and its capabilities change due to activity in UE-B, UE-A notifies NW-A of the capability change via RRC messages (such as UE assistance information).

[0180] If UE-A's capabilities change due to UE-B's activity while UE-A is in RRC idle or RRC inactive mode, a method similar to that used for RRC connection can be used. UE-A can also indicate a capability change in RRC establishment request / RRC recovery request, RRC establishment complete, or RRC recovery complete. The capability can then be retrieved via UAI, etc.

[0181] NW-A can be configured to allow UE-A to notify of changed capabilities, such as via RRC reconfiguration of the "..." message. otherConfigIn other words, the network can control whether the UE-A can update changed capabilities through the "otherConfig" parameter. OtherConfig can contain a single enumerated parameter or several other parameters that can be used to control and notify the UE-A to report changed capabilities. Alternatively, each of these individual capabilities that can change can have a separate flag in otherConfig. Therefore, the UE can report updated or changed capabilities through UE Assistance Information messages. The information content in the UAI can involve MUSIM Assistance Information or MUSIM UE Capability Information.

[0182] The CU of NW-A can configure a filter for UE-A, and UE-A will report capability changes based on that filter. For example, the filter can be a band filter. If the UE capability of a band included in the filter changes, UE-A reports that capability change. If no capability in the filter changes due to UE-B's action, UE-A may not initiate a message to indicate a UE capability change.

[0183] If the frequency band supported by the changed capabilities differs from the old capabilities, the NW-A can reconfigure the UE-A to release one or more SCells, SCGs, or perform a handover. The NW-A can also configure the UE-A to report any available measurements when capabilities have changed. Because the changed capabilities may differ from the old capabilities, the NW-A may be more inclined to modify SCells or SCGs rather than release them, or in some cases, perform a handover to a different frequency. Measurements from the UE can help the network make such decisions.

[0184] The static or dynamic capability signaling reported by the UE may include the following and more.

[0185] • Number of Rx links

[0186] • Number of Tx links

[0187] • Maximum number of MIMO layers

[0188] • Regarding the component carrier or dual-connectivity processing capabilities supported on NW A

[0189] • Requests for at least one of the following: configuration, activation, deactivation, and release of one or more SCells / SCGs on NW A.

[0190] • UL or DL ​​TDD configuration

[0191] DRX configuration on NW B

[0192] Measurement configuration on NW B

[0193] • Supported frequencies or restricted frequencies.

[0194] The following is an example specification that includes a UAI for reporting temporary MUSIM capability limitations.

[0195] In the case of dual connectivity, UE-A can report capability changes, such as capability restrictions and the removal of capability restrictions, to NW-A's MN, even if these capabilities are related to NW-A's SN or if they apply to both NW-A's MN and SN.

[0196] The network utilizes the updated capabilities received from the UE and reconfigures the UE using the updated parameters. The network can update configurations such as dual connectivity, carrier aggregation, power control, interference coordination, DAPS configuration, and the number of layers based on capability information, including supported frequency bands, supported frequency band combinations, scheduling modes, and / or TDD UL / DL configuration information. A sample set for reporting changes in temporary capability limitations is given below.

[0197] [Table 15]

[0198] The UE behavior for multi-SIM operation for dual-activity is as follows, as obtained in TS 38.331 (only the relevant sections are included).

[0199] [Table 16]

[0200] T348 is the MUSIM wait timer, and any embodiment that mentions T348 is applicable to any other timer that implements similar functionality to the MUSIM wait timer. Similarly, any embodiment that mentions the MUSIM wait timer is applicable to any timer that performs start, stop, or expiration functions similar to those of T348 described above. In this disclosure, the MUSIM wait timer and T348 are used interchangeably. musim-WaitTimer is the value of the MUSIM wait timer, for example, the value configured as in NR RRC CR R2-2313699. Any other IE can be used to implement the same functionality as musim-WaitTimer, and all embodiments that mention musim-WaitTimer are equally applicable.

[0201] Consider 3GPP specification v17.6.0 (e.g., but not limited to TS 38.331, TS 38.300, TS 38.306, TS38.321) as the relevant background.

[0202] Consider the scenario where a MUSIM UE has two USIMs (i.e., two UEs within the same MUSIM device), namely UE-A and UE-B. UE-A notifies the CU of NW-A of capability limitations or the removal of capability limitations via RRC messages (e.g., but not limited to UE assistance information).

[0203] Dual-connectivity with multiple radios: 3GPP specifies dual connectivity, or more professionally, "dual-connectivity with multiple radios," in specifications such as TS 37.340. A detailed overview of dual connectivity is given below.

[0204] NG-RAN supports Multi-Radio Dual Connectivity (MR-DC) operation, whereby a User Equipment (UE) in an RRC connection is configured to utilize radio resources provided by two different schedulers located in two distinct NG-RAN nodes via a non-ideal backhaul connection. One node provides NR (New Radio) access, and the other provides E-UTRA (Evolved UMTS Terrestrial Radio Access) or NR access. One node acts as the primary node (MN), and the other as the secondary node (SN). The MN and SN are connected via a network interface, and at least the MN is connected to the core network. NG-RAN supports NG-RAN E-UTRA-NR Dual Connectivity (NGEN-DC), where the UE connects to an ng-eNB (which can connect to an E-UTRA base station in the 5G core) acting as the MN and a gNB (5G base station) acting as the SN. NG-RAN also supports NR-E-UTRA Dual Connectivity (NE-DC), where the UE connects to a gNB acting as the MN and an ng-eNB acting as the SN. The primary cell of a primary or secondary cell group is called a SpCell. The SpCell of the primary cell group is called the PCCell, while the SpCell of the secondary cell group is called the PSCell. In MR-DC, a group of serving cells associated with the primary node, including the SpCell (PCCell) and one or more optional SCells, is called the MCG or primary cell group. A group of serving cells associated with the secondary node, including the SpCell (PSCell) and one or more optional SCells, is called the secondary cell group (SCG). In MR-DC, frame timing and SFN between cells in the MCG and SCG may not be aligned.

[0205] The MN can notify the SN of temporary limitations on received capabilities and its configured band filters. An exemplary ASN.1 structure for notification from TS 38.331 is given in Table 17.

[0206] [Table 17]

[0207] Consider 3GPP specifications v17.7.0 (such as TS 38.331, TS 38.300, TS 38.306, TS 38.321) and 3GPP t-doc R2-2313699 which introduces R18 MUSIM enhancements to TS 38.331 as relevant background.

[0208] When a MUSIM UE has two USIMs (i.e., two UEs in the same MUSIM device), namely UE-A and UE-B, the following MUSIM UE scenarios can be considered: a. UE-A is configured with OtherConfig by the gNB CU of NW-A, including musim-WaitTimer. After musim-WaitTimer expires, UE-A automatically applies temporary capability restrictions.

[0209] b. UE-A is configured with dual connectivity and is also configured with OtherConfig by the gNB CU of the MN of NW-A, including musim-WaitTimer. After the musim-WaitTimer expires, UE-A automatically applies temporary capability restrictions.

[0210] Therefore, the following challenges regarding reporting on capability limitations are expected to be addressed: a. Communication from CU to DU for handling temporary capability-limited applications after the MUSIM wait timer expires.

[0211] b. DU behavior after MUSIM waits for the timer to expire.

[0212] c. Communication from MN to SN to handle temporary capability limitations after the MUSIM wait timer expires.

[0213] d. MN behavior after the MUSIM wait timer expires.

[0214] e. UE behavior after the MUSIM wait timer expires.

[0215] f. SN behavior after MUSIM waits for the timer to expire.

[0216] This disclosure generally relates to the field of mobile communications involving multiple SIMs, and more specifically, to methods and systems for handling wait timers in MUSIM. The methods disclosed herein address temporary capability limitations upon the expiration of the MUSIM-WaitTime. Furthermore, the disclosed methods handle CU-DU communication for handling temporary capability limitation applications after the MUSIM wait timer expires. Additionally, the methods disclosed herein address the behavior of the DU, MN, SN, and UE after the MUSIM wait timer expires. The method also addresses MN-SN communication scenarios for handling temporary capability limitations for handling temporary capability limitation applications after the MUSIM wait timer expires.

[0217] In this embodiment, the MN notifies the SN of the musim-WaitTimer (e.g., but not limited to the t348 value in the NR). The musim-WaitTimer can be a musim-WaitTimer configured by the MN (the CU of the MN) for the UE to report temporary capability limitations; that is, the CU of the MN notifies the SN of the musim-WaitTimer (t348 value). The CU of the MN can be the same MN CU that configured the musim-WaitTimer for the UE, or it can be a different MN CU than the one that configured the musim-WaitTimer. When it is a different MN CU than the one that configured the musim-WaitTimer, it can receive the musim-WaitTimer from another CU during handover, RRC reconstruction, etc.

[0218] In this embodiment, MN notifies SN of the musim-WaitTimer (t348 value) during the Xn process.

[0219] In an embodiment, MN notifies SN of the musim-WaitTimer (t348 value) in an Xn message (e.g., but not limited to S-NODE ADDITION REQUEST, S-NODEMODIFICATION REQUEST, S-NODE CHANGE REQUIRED, etc.).

[0220] In this embodiment, the MN uses an RRC inter-node message (INM) to notify the SN of the musim-WaitTimer (t348 value).

[0221] In this embodiment, the MN uses RRC INM CG-ConfigInfo to notify the SN of the musim-WaitTimer (t348 value).

[0222] In an embodiment, the MN uses an RRC IE (such as musim-CapRestrictionInfo-r18) in CG-ConfigInfo to notify the SN of the musim-WaitTimer (t348 value).

[0223] In this embodiment, musim-WaitTimer is an optional IE in CG-ConfigInfo, and if MN does not include musim-WaitTimer in CG-ConfigInfo, SN avoids applying temporary capability limitations after the wait timer expires. Exemplary specification changes are given in Table 18: [Table 18]

[0224] Upon receiving the musim-WaitTimer-r18 from the MN, the SN starts a MUSIM wait timer with the received musim-WaitTimer-r18 value after receiving the temporary capability restriction. After the timer expires, the SN applies the temporary capability restriction to the SCG, cells within the SCG, etc., according to the UE's request. After receiving the SN RRCReconfigurationComplete message (sent by the SN) for RRCReconfiguration with restricted capabilities, the SN stops the timer according to the temporary capability restriction.

[0225] In this embodiment, after receiving a temporary capability restriction, the MN also starts a MUSIM wait timer with a configured value of musim-WaitTimer-r18, and after the timer expires, applies temporary capability restrictions to the MCG, cells within the MCG, etc., according to the UE's request. After receiving an RRCReconfigurationComplete message with restricted capabilities for RRCReconfiguration (sent by the MN), the MN stops the timer according to the temporary capability restriction.

[0226] In an alternative embodiment, even if the UE does not request SCG release in the UAI that notifies of temporary capability restrictions, the MN releases the SCG after the MUSIM wait timer expires. In this embodiment, if any temporary capability restriction requested by the UE (e.g., but not limited to the SCell to be released or the affected cell) is for the SCG cell, the MN releases the SCG after the MUSIM wait timer expires.

[0227] In this embodiment, a UE that has initiated T348 after sending a UAI requesting temporary capability limitation releases the SCG after T348 expires.

[0228] In the embodiment, even if the requested temporary capability restriction does not include the release of the SCG, the UE that has initiated T348 after sending the UAI requesting the temporary capability restriction will release the SCG after T348 expires.

[0229] In an embodiment, if any of these capabilities are related to an SCG (e.g., the SCell to be released or the affected cell is for an SCG cell), even if the requested temporary capability restriction does not include the release of the SCG, a UE that has initiated T348 after sending the UAI requesting the temporary capability restriction will release the SCG after T348 expires.

[0230] In this embodiment, after T348 expires, the UE notifies the network (such as the MN CU) of its preferred action: whether, after T348 expires, the UE will reduce its capabilities according to the requested temporary capability restrictions, or will operate with its existing capabilities without reducing its capabilities according to the requested temporary capability restrictions. This notification can be made in the UAI within an IE (such as musim-Assistance), for example, the preferred action can be included in musim-CapRestriction.

[0231] In an embodiment, the MN can notify the SN of the preferred action received from the UE after the MUSIM wait timer expires. This can be included in the RRC INM CG-ConfigInfo and in the Xn procedure. If the preferred action is not to apply temporary capability restrictions (i.e., to operate using existing capabilities without reducing capabilities according to the requested temporary capability restrictions), the SN may not reduce the capabilities of the affected cell, or may not release the SCell after the MUSIM wait timer expires.

[0232] In this embodiment, the UE sends temporary capability restrictions only for MCG SCells to release or reduce their capabilities. Cells in musim-CellToAffectList-r18 and musim-Cell-SCG-ToReleasedList apply only to MCG cells. If the UE needs temporary capability restrictions for any SCG SCell (i.e., any SCGS Cell affected by MUSIM operation), or needs to release an SCGS Cell for MUSIM operation, it requests the release of the SCG, for example, by including scg-ReleasePreference-r18 and setting it to scgReleasePreferred.

[0233] Regarding CU-DU interaction with musim-WaitTimer

[0234] In an embodiment, the gNB CU notifies the gNBDU of the musim-WaitTimer (e.g., but not limited to the t348 value in the NR). The musim-WaitTimer can be a musim-WaitTimer configured by the CU for the UE to report temporary capability limitations; that is, the CU notifies the DU of the musim-WaitTimer (t348 value).

[0235] In this embodiment, the gNB CU notifies the gNB DU of temporary capability limitations.

[0236] In this embodiment, the gNB CU notifies the gNB DU of the musim-WaitTimer (t348 value) configured for the UE to report temporary capability limitations. That is, if the UE is configured to report temporary capability limitations and the configuration includes musim-WaitTimer, the gNB CU notifies the gNB DU of the musim-WaitTimer.

[0237] In this embodiment, the gNB CU notifies the gNB DU of the musim-WaitTimer along with the temporary capability limitations received from the UE.

[0238] In an embodiment, within the NR, the gNB CU uses the "CU to DU RRC information" IE in F1AP messages (such as F1AP UE context establishment request and F1AP UE context modification request) to notify the gNB DU of the musim-WaitTimer. The gNB DU can also receive temporary capability limitations from the gNB CU.

[0239] In this embodiment, upon receiving a temporary capability limitation, the gNB DU initiates a musim-WaitTimer. After the musim-WaitTimer expires, the gNB DU applies the temporary capability limitation based on the one received from the CU, for example, by releasing the SCell configuration, updating the MIMO layer in the downlink (DL), the MIMO layer in the uplink (UL), the supportedBandwidth in the DL, and the supportedBandwidth in the UL.

[0240] In this embodiment, the musim-WaitTimer notified to the gNB DU by the gNB CU is configured to the UE by the same gNB CU. That is, the CU includes the musim-WaitTimer in the OtherConfig sent to the UE and can also receive temporary capability restrictions from the UE. The gNB CU further sends the musim-WaitTimer and / or temporary capability restrictions to the gNB DU.

[0241] In the embodiment, during the switch / reconfigurationWithSync preparation or LTM / conditional switch / conditional PSCellChange preparation process, DU is the target gNB DU, and CU is the target gNB CU.

[0242] In this embodiment, the source gNB CU notifies the target gNB CU of the musim-WaitTimer using NR RRC INMI (such as HandoverPreparationInformation) during the handover process, and the target gNB CU notifies the target gNB DU of the musim-WaitTimer. The target gNB CU may also receive temporary capability limitations from the source gNB CU and notify the target gNB DU of them.

[0243] In the embodiment, during RRCReestablishment, DU is the new gNB DU, and CU is the new gNBCU.

[0244] In an embodiment, during RRC Reestablishment, the old gNB CU notifies the new gNB CU of the musim-WaitTimer, and the new gNB CU notifies the new gNB DU of the musim-WaitTimer using NR RRC INMI (such as HandoverPreparationInformation). The new gNB CU may also receive temporary capability limitations from the old gNB CU and notify the new gNB DU of them.

[0245] In this embodiment, DU is the SN DU in the dual connection, and CU is the SN CU. In this embodiment, the SN CU receives the musim-WaitTimer from the MN CU, and the SN CU notifies the SN DU of the musim-WaitTimer. The SN CU may also receive temporary capability limitations from the MN CU and notify the SN DU of them.

[0246] In this embodiment, the gNB CU uses the RRC inter-node message CG-Config to notify the gNB DU of MUSIM wait timers (such as musim-WaitTimer).

[0247] In this embodiment, the gNB CU uses the RRC inter-node message CG-ConfigInfo to notify the gNB DU of the musim-WaitTimer.

[0248] In an embodiment, if the gNB DU receives CU-DU RRC information containing musim-WaitTimer and is unable to decode musim-WaitTimer, or receives an ASN.1 protocol error while attempting to decode musim-WaitTimer, the gnb DU ignores the received musim-WaitTimer.

[0249] In this embodiment, the musim-WaitTimer sent from the gNB CU to the gNB DU is encoded as an octet string according to the NR RRC format.

[0250] Exemplary variations of TS 37.340 according to embodiments of this disclosure are given in Tables 19 and 20.

[0251] [Table 19]

[0252] [Table 20]

[0253] In an embodiment, if the gNB DU cannot decode the musim-WaitTimer, it will not apply temporary capability limitations after the MUSIM wait timer expires.

[0254] In this embodiment, there is no critical state for the allocation of the musim-WaitTimer in the CU to DU RRC information IE.

[0255] In an embodiment, the gNB CU can notify the gNB DU of the preferred action received from the UE after the MUSIM wait timer expires. This can be included in the CU-DU RRC information and in F1AP messages, such as F1AP UE context establishment requests or F1AP UE context modification requests. If the preferred action is not to apply temporary capability limitations, the DU may not degrade the capabilities of the affected cell, such as the maximum number of MIMO layers (in DL and / or UL) or the maximum Rx bandwidth (in DL and / or UL), or may not release the SCell after the MUSIM wait timer expires.

[0256] In this way, this disclosure provides techniques for handling different scenarios regarding reporting capability limitations applied by the MUSIM UE when the musim-WaitTimer expires. The methods disclosed herein provide techniques for handling wait timers in MUSIM to efficiently switch from one USIM to another.

[0257] [Table 21]

[0258] The primary objective of the embodiments herein is to disclose methods and systems for reporting capability limitations in centralized unit (CU)-distributed unit (DU) operation in wireless communication networks.

[0259] Another objective of the embodiments herein is to disclose CU-DU communication for handling temporary capability restrictions or removing temporary capability restrictions.

[0260] Another objective of the embodiments described herein is to disclose the DU behavior upon receiving a temporary capability limitation.

[0261] Another objective of the embodiments herein is to disclose DU-CU communication for handling temporary capability limitations.

[0262] The embodiments described herein implement methods and systems for reporting capability limitations in centralized unit (CU) - distributed unit (DU) operation in wireless communication networks. Reference is now made to the accompanying drawings, and more specifically to... Figures 2 to 3 The embodiments are shown, wherein similar reference numerals are consistently used to denote corresponding features throughout all the figures.

[0263] In the embodiments described herein, the gNB CU notifies the gNB DU of temporary capability limitations (e.g., Figure 2 and Figure 3 (As depicted in the text). In embodiments herein, the gNB CU notifies the gNB DU of filters configured for the UE to report temporary capability limitations; that is, if the UE is configured to report temporary capability limitations and the configuration includes filters such as, but not limited to, a band list (e.g., but not limited to, musim-CandidateBandList), the gNB CU notifies the gNB DU of those filters. In embodiments herein, the gNB CU notifies the gNB DU of filters such as, but not limited to, a band list (e.g., but not limited to, musim-CandidateBandList), along with temporary capability limitations received from the UE.

[0264] In the embodiments described herein, in the NR, the gNB CU uses the CU-DU RRC information IE in F1AP messages (e.g., but not limited to F1AP UE Context Establishment Request and F1AP UE Context Modification Request) to notify the gNB DU of filters, such as, but not limited to, a list of frequency bands (e.g., but not limited to musim-CandidateBandList). The gNB DU can also receive temporary capability restrictions from the gNB CU; for example, the gNB DU identifies affected or avoided frequency bands via the UAI IE in the CU-DU RRC information. In the embodiments described herein, the DU identifies frequency bands affected by MUSIM operation by mapping band entry indexes (e.g., but not limited to bandEntryIndex in the MUSIM-AffectedBandsList received in the UAI within the CU-DU RRC information) to bandEntryIndex in the musim-CandidateBandList, and identifies the MIMO layer in the downlink (DL), the MIMO layer in the uplink (UL), the supportedBandwidth in the DL, and the supportedBandwidth in the UL for each frequency band and band combination, and generates DU-CU RRC information IE (e.g., but not limited to CellGroupConfig), and notifies the gNB CU in the F1AP UE context establishment response or F1AP UE context modification response. In the embodiments described herein, the DU identifies frequency bands that need to be avoided due to mUSIM operations by mapping band entry indices (e.g., but not limited to bandEntryIndex in the musim-AvoidedBandsList received in the UAI within the CU-DU RRC information) to bandEntryIndex in the musim-CandidateBandList, and generates DU-CU RRC information IE, such as, but not limited to, the requested BandCombinationIndex or the selected BandCombinationIndex (excluding any frequency bands in the musim-AvoidedBandsList), and notifies the UE of this information in the F1AP UE context establishment response or F1AP UE context modification response. The DU also generates UE configuration based on the musim-CandidateBandList using the musim-AffectedBandsList and the musim-AvoidedBandsList.

[0265] In the embodiments described herein, filters, such as but not limited to a band list (e.g., but not limited to musim-CandidateBandList), notified to the gNB DU by the gNB CU are configured to the UE by the same gNB CU; that is, the CU includes musim-CandidateBandList in the OtherConfig sent to the UE, and can also receive temporary capability restrictions from the UE based on musim-CandidateBandList. The gNB CU further sends musim-CandidateBandList and / or temporary capability restrictions to the gNB DU.

[0266] In the embodiments described herein, during handover / reconfigurationWithSync preparation, LTM / conditional handover / conditional PSCellChange preparation, or any other mobility procedure, the DU is the target gNB DU, and the CU is the target gNB CU. In the embodiments described herein, the source gNB CU informs the target gNB CU of filters, such as, but not limited to, a band list (e.g., but not limited to, musim-CandidateBandList), using NR RRC INMI (e.g., but not limited to HandoverPreparationInformation) during the handover process, and the target gNB CU informs the target gNB DU of the musim-CandidateBandList. The target gNB CU may also receive temporary capability limitations from the source gNB CU and inform the target gNB DU of them.

[0267] In the embodiments described herein, during RRCReestablishment, the DU is the new gNB DU, and the CU is the new gNB CU. In these embodiments, the old gNB CU informs the new gNB CU of filters, such as, but not limited to, a band list (e.g., but not limited to, musim-CandidateBandList), during RRCReestablishment, and the new gNB CU informs the new gNB DU of filters, such as, but not limited to, musim-CandidateBandList, using NR RRC INMI (e.g., but not limited to HandoverPreparationInformation). The new gNB CU may also receive temporary capability limitations from the old gNB CU, and the new gNB CU may inform the new gNB DU of temporary capability limitations.

[0268] In the embodiments described herein, DU is the SN DU in a dual-connectivity configuration, and CU is the SN CU. In the embodiments described herein, the SN CU receives filters from the MN CU, such as, but not limited to, a list of frequency bands (e.g., but not limited to, musim-CandidateBandList), and the SN CU informs the SN DU of the filters (e.g., but not limited to, musim-CandidateBandList). The SN CU may also receive temporary capability limitations from the SN CU, and the SN CU informs the target gNB DU of the temporary capability limitations.

[0269] In the embodiments described herein, the gNB CU uses the RRC inter-node message CG-Config to notify the gNB DU of filters, including but not limited to a list of frequency bands (e.g., but not limited to musim-CandidateBandList). In the embodiments described herein, the gNB CU uses the RRC inter-node message CG-ConfigInfo to notify the gNB DU of filters, including but not limited to a list of frequency bands (e.g., but not limited to musim-CandidateBandList).

[0270] In the embodiments described herein, if the gNB DU receives CU to DURRC information containing musim-CandidateBandList and is unable to decode musim-CandidateBandList, or receives an ASN.1 protocol error while attempting to decode musim-CandidateBandList, then the gNB DU ignores musim-CandidateBandList and generates DU to CU RRC information without considering musim-CandidateBandList or MUSIM-AffectedBandsList and musim-AvoidedBandsList.

[0271] In the embodiments described herein, the musim-CandidateBandList sent by the gNB CU to the gNB DU is encoded as an OCTET STRING according to the NRRRC format.

[0272] Table 22 provides exemplary variations of TS 37.340 based on embodiments disclosed herein.

[0273] [Table 22]

[0274] 8.3.1 UE Context Establishment: 8.3.1.2 Successful operation: If the musim-CandidateBandList IE is included in the UE CONTEXT SETUP REQUEST, then the gNB-DU should use this information to identify limitations in the UE auxiliary information resulting from MUSIM operation and take this information into account for UE-specific configurations.

[0275] or

[0276] If the musim-CandidateBandList IE is included in the UE CONTEXT SETUP REQUEST, then the gNB-DU should consider using this information for UE-specific configurations.

[0277] 8.3.4 UE Context Modification (Initiated by gNB-CU): 8.3.4.2 Successful operation: If the musim-CandidateBandList IE is included in the UE CONTEXT MODIFICATION REQUEST, then the gNB-DU should use this information to identify limitations in the UE auxiliary information resulting from MUSIM operation and take this information into account for UE-specific configurations.

[0278] or

[0279] If the musim-CandidateBandList IE is included in the UE CONTEXT MODIFICATION REQUEST, then the gNB-DU should consider using this information for UE-specific configurations.

[0280] In the embodiments described herein, if the gNB DU cannot decode musim-CandidateBandList, the MUSIM-AffectedBandsList or musim-AvoidedBandsList fields in the UE AssistanceInformation are not applied when generating the UE configuration or when generating DU-to-CU RRC information.

[0281] In the embodiments described herein, there is no critical state for the allocation of musim-CandidateBandList in the CU to DU RRC information IE.

[0282] The embodiments disclosed herein can be implemented by at least one software program that runs on at least one hardware device and performs network management functions to control network elements. Elements include blocks, which may be at least one of hardware devices or a combination of hardware devices and software modules.

[0283] The embodiments disclosed herein describe methods and systems for reporting capability limitations in centralized unit (CU) - distributed unit (DU) operation in wireless communication networks. Therefore, it should be understood that the scope of protection extends to programs, and such computer-readable storage devices, in addition to computer-readable means containing messages, include program code means for implementing one or more steps of the method when the program is run on a server, mobile device, or any suitable programmable device. In at least one embodiment, the method is implemented by or in conjunction with a software program written in, for example, Very High Speed ​​Integrated Circuit Hardware Description Language (VHDL) or another programming language, or by one or more VHDL or several software modules executed on at least one hardware device. The hardware device can be any kind of portable device that can be programmed. The device may also include means that can be, for example, a hardware device (e.g., an ASIC), or a combination of hardware and software devices (e.g., an ASIC and an FPGA), or at least one microprocessor and at least one memory having software modules located therein. The method embodiments described herein can be implemented partly in hardware and partly in software. Alternatively, this disclosure can be implemented on different hardware devices, for example, using multiple CPUs.

[0284] The foregoing description of specific embodiments will fully reveal the general nature of the embodiments herein, enabling others to readily modify and / or adapt such specific embodiments to various applications by applying present knowledge without departing from the general conception, and therefore, such adaptations and modifications should and are intended to be understood as falling within the equivalent meaning and scope of the disclosed embodiments. It should be understood that the wording or terminology used herein is for descriptive purposes and not for limitation. Therefore, although embodiments herein have been described with reference to examples, those skilled in the art will recognize that the embodiments herein can be practiced with modifications within the scope of the embodiments described herein.

[0285] The following text is for reference only. Figures 1 to 24 Various embodiments of this disclosure are explained.

[0286] As used in this document, the term "UE capability" refers to the hardware and software capabilities of a UE. Different capabilities between devices can be hardware capabilities, including radio frequency capabilities (such as supported frequency bands or combinations thereof), processing capabilities (such as baseband computing capabilities), software capabilities (such as support for various features), Layer 1 capabilities, Layer 2 capabilities, Layer 3 capabilities, and so on. Typically, a UE reports its UE radio access capabilities, which are static at least when the network requests these capabilities. To limit signaling overhead, the gNB requests the UE to provide NR capabilities for a restricted set of frequency bands. In response, if the corresponding UE capabilities are the same, the UE can skip a subset of the requested frequency band combinations. If supported by both the UE and the network, the UE can provide an ID in NAS signaling to reduce signaling overhead; this ID represents its radio capabilities for one or more radio access technologies (RATs). This ID can be assigned by the manufacturer or the serving Public Land Mobile Network (PLMN). Manufacturer-assigned IDs correspond to a set of pre-supplied capabilities. In the case of PLMN-assigned IDs, the assignment is performed in NAS signaling. A detailed list of UE capabilities exchanged using the methods described above is specified in 3GPP technical specifications (such as TS 38.306). The gNB provides various configurations / features to the UE based on the reported UE capabilities via RRC messages (such as RRC reconfiguration or RRC recovery). In MUSIM devices that support multiple simultaneous RRC connections on multiple USIMs, the UE capabilities of the RRC-connected USIMs in the MUSIM device change when other USIMs move from RRC idle or RRC inactive to an RRC connection (or vice versa), for example, the supported frequency bands may change.

[0287] Figure 1An environment 100 is illustrated in which certain embodiments of this disclosure may be practiced. Environment 100 exemplarily depicts a user 102 associated with a user equipment (UE) 104. Some examples of UE 104 may include, but are not limited to, electronic devices such as smartphones, laptops, desktops, personal computers, or any spatial computing device capable of performing wireless communications. For example, UE 104 may run on multiple platforms and / or operating systems to perform different operations related to wireless communications. In embodiments, UE 104 may host more than one Subscriber Identity Module (SIM), i.e., UE 104 is a MUSIM (Multi-SIM) UE. In the exemplary scenario, UE 104 may initiate a connection with network entity 108 for various conditions. For example, several conditions associated with UE 104 may include: initial access from RRC idle by network entity 108, transition from RRC inactivity to RRC connection, RRC connection reconstruction, handover, beam fault recovery, synchronization reconfiguration, timing alignment during the addition of a secondary cell (Scell), downlink (DL) asynchrony, uplink (UL) asynchrony, the maximum amount of scheduling request (SR) transmissions reached, UL data arrival, and on-demand system information. It should be noted that the above conditions are for illustrative purposes only, and UE 104 may establish a connection with network entity 108 based on other conditions. In this embodiment, UE 104 establishes a connection with network entity 108 to configure UE capabilities based on MUSIM operation. MUSIM operation indicates network state transitions associated with one of UE 104's Universal Subscriber Identity Modules (USIMs).

[0288] UE 104 can establish a connection with network entity 108 via communication network 106. It is understood that UE 104 can communicate operationally with communication network 106 (such as the Internet), which is implemented by a network provider (also known as an Internet Service Provider (ISP)). UE 104 can connect to communication network 106 using a wireless network. Some non-limiting examples of wireless networks may include wireless LAN (WLAN), cellular networks, Bluetooth, or ZigBee networks, etc.

[0289] Various embodiments of this disclosure disclose a method performed by UE 104 for reporting UE capabilities for a MUSIM UE to network entity 108. The UE capabilities include one or more gap requirements. UE 104 determines whether it is capable of reporting UE capabilities containing one or more gap requirements, and reports the UE capabilities once configured by network entity 108. Reference is made next to... Figure 2 A detailed explanation of the operations performed by UE 104.

[0290] As used in this document, the term "gap requirement" refers to one of the following: measurement gap requirement, network control gap (NCSG) requirement, and interruption requirement. In wireless technologies such as New Radio (NR) and Long Term Evolution (LTE), the Radio Resource Control (RRC) connected to the UE performs various measurements for Radio Resource Management (RRM) purposes, positioning, etc. For RRM, the UE measures reference signals, such as synchronization signals / PBCH blocks (SSBs), Channel State Information Reference Signals (CSI-RS), etc., and reports the measurement results to the network. According to the NR specification TS 38.300, measurements performed by the UE for connected-mode mobility are categorized into at least four types: intra-frequency NR measurements, inter-frequency NR measurements, inter-frequency radio access technology (RAT) measurements for Evolved-Universal Terrestrial Radio Access Network (E-UTRA), and inter-RAT measurements for UTRA. One or more measurement objects, such as the carrier frequency to be monitored, are defined for each measurement type. One or more reporting configurations (which define the reporting criteria) are defined for each measurement object. Three reporting criteria are used: event-triggered reporting, periodic reporting, and event-triggered periodic reporting. The association between a measurement object and a reporting configuration is established by a measurement identifier (which links a measurement object and a reporting configuration within the same RAT). The measurement identifier is also used when reporting measurement results. For positioning, the UE can report SSB / CSI-RS measurements and can also report measurements based on additional reference signals, such as the Positioning Reference Signal (PRS).

[0291] When the SSB is not fully included in the active DL BWP and the UE needs to measure inter-frequency NR, perform inter-RAT measurements, or perform intra-frequency measurements outside the active downlink bandwidth portion (BWP), the UE can use measurement gaps. Measurement gaps are configured by the network (e.g., gNB in ​​NR) and no transmissions or receptions occur during the gap period. Measurement gap configurations include gap offset, gap length, repetition period, and measurement gap timing advance. The gap offset specifies the subframe in which the measurement gap begins. The gap length gives the duration of the gap, while the repetition period defines the frequency at which the measurement gap occurs. In radio technologies such as NR and LTE, the RRC connected to the UE performs various measurements for RRM, positioning, etc. For RRM, the UE measures one or more reference signals, such as, but not limited to, the Synchronization Signal / Physical Broadcast Channel (PBCH) block (SSB), CSI-RS, etc., and reports the measurement results to the network. According to the NR specification TS 38.300, measurements performed by the UE for connected-mode mobility are classified into at least four types. These measurement types include same-frequency NR measurement, different-frequency NR measurement, E-UTRA RAT-to-RAT measurement, and UTRA RAT-to-RAT measurement.

[0292] Figure 2 A UE 104 for reporting UE capabilities is illustrated according to an embodiment of this disclosure. As previously described, UE 104 can establish a connection with network entity 108 to transmit UE capabilities.

[0293] In this embodiment, UE 104 may include two SIMs, USIM-A and USIM-B, within the same UE 104. UE 104 supports dual transmit and receive, meaning that both USIM-A and USIM-B can be connected simultaneously (RRC connection). Both UE-A and UE-B can transmit or receive data simultaneously. In this embodiment, USIM-A and USIM-B may share one or more RF, radio, hardware, and software resources. The UE capabilities of USIM-A (such as the UE radio access capabilities described in 3GPP specifications (e.g., TS 38.306)) may vary at different times depending on whether USIM-B is connected (i.e., depending on whether USIM-B uses RF, radio, hardware, and software resources).

[0294] Consider USIM-A and Network Entity A (NW-A) in an RRC connection state. USIM-B is entering and / or transitioning to an RRC connection. USIM-A provides information to NW-A to release certain resources or update some parameters for MUSIM operation. This information involves changes to UE capabilities in USIM-A, the release of secondary cell groups (SCGs) or SCells in UE-A, the deactivation of SCGs or SCells in UE-A, and information on the establishment or activation of SCGs or SCells in UE-A. UE capabilities include measurement gap requirements (needforgaps / needforgapsorncsg) in UE-A to facilitate MUSIM operation.

[0295] When USIM-A is in RRC connected mode and UE capabilities change due to changes in the network status of USIM-B, USIM-A notifies NW-A of the capability change via RRC messages (such as UE Assistance Information (UAI) messages). If USIM-A's UE capabilities have changed due to USIM-B's activity while USIM-A is in RRC idle or RRC inactive mode, a method similar to that used in RRC connected mode is used. USIM-A can also indicate a capability change in RRC establishment request / RRC recovery request, RRC establishment completion, or RRC recovery completion. Capabilities can be retrieved later via UAI messages, etc. USIM-A can report a capability change, or it can report a changed capability based on a specific action in USIM-B. USIM-A can report a capability change to NW-A when USIM-B switches from a licensed frequency to an unlicensed frequency or from one frequency range (FR) to another FR.

[0296] In this embodiment, UE 104 includes a processor 202, a memory 204, an input / output module 206, and a communication interface 208. It should be noted that in some embodiments, UE 104 may contain more or fewer components than those depicted herein. The various components of UE 104 may be implemented using hardware, software, firmware, or any combination thereof. Furthermore, the various components of UE 104 may be operatively connected to each other. More specifically, the various components of UE 104 may be able to communicate with each other using a communication channel medium (such as a bus, interconnect, etc.).

[0297] In embodiments, processor 202 may be a multi-core processor, a single-core processor, or a combination of one or more multi-core processors and one or more single-core processors. For example, processor 202 may be one or more of the following: various processing devices, such as coprocessors, microprocessors, controllers, digital signal processors (DSPs), processing circuitry with or without accompanying DSPs, or various other processing devices, including microcontroller units (MCUs), hardware accelerators, dedicated computer chips, etc.

[0298] In this embodiment, processor 202 is configured to: (1) receive a request from network entity 108 for the ability to transmit UE; (2) determine whether UE 104 is able to report changes in one or more gap requirements. The changes in one or more gap requirements are caused by MUSIM operation, and (3) transmit the ability of the UE to report one or more gap requirements to network entity 108.

[0299] In this embodiment, memory 204 is capable of storing machine-executable instructions, referred to herein as instruction 205. In this embodiment, processor 202 is embodied as an executor of software instructions. Therefore, processor 202 is capable of executing instruction 205 stored in memory 204 to perform one or more operations as described herein.

[0300] In addition, memory 204 can also store UE capability information, historical reports, network configuration information, information related to previously connected network entities, and previous temporary UE capabilities for different MUSIM operations. Memory 204 can be any type of storage device that processor 202 can access to perform corresponding functions. For example, memory 204 may include one or more volatile or non-volatile memories, or combinations thereof. For example, memory 204 can be embodied as semiconductor memory, such as flash memory, mask ROM, PROM (programmable ROM), EPROM (erasable PROM), RAM (random access memory), etc.

[0301] In an embodiment, I / O module 206 may include a mechanism configured to receive input from an operator (i.e., user 102) of UE 104 and provide output thereto. To receive input from UE 104 and provide output, I / O module 206 may include at least one input interface and / or at least one output interface. Examples of input interfaces may include, but are not limited to, a keyboard, mouse, joystick, keypad, touchscreen, softkeys, microphone, etc. Examples of output interfaces include, but are not limited to, displays (such as light-emitting diode displays, thin-film transistor (TFT) displays, liquid crystal displays, active-matrix organic light-emitting diode (AMOLED) displays), microphones, speakers, ringtones, etc.

[0302] In an embodiment, communication interface 208 may include a mechanism configured to communicate with other entities in environment 100, such as network entity 108. In an embodiment, UE 104 may initiate connection establishment with network entity 108 via communication interface 208. Processor 202 is configured to determine whether UE 104 is capable of reporting changes to one or more gap requirements. The changes to one or more gap requirements are caused by MUSIM operation. Processor 202 sends the UE capability to report one or more gap requirements to network entity 108 via communication interface 208. Upon receiving the UE capability to report one or more gap requirements, the network entity sends a temporary UE capability.

[0303] In one embodiment, one or more gap requirements and temporary UE capability configurations may be stored in database 210. UE 104 is depicted as communicating with database 210. In another embodiment, database 210 is configured to store one or more temporary UE capability configurations generated by network entity 108 over a period of time.

[0304] Database 210 may include multiple storage units, such as hard disks and / or solid-state drives, in the form of a Redundant Array of Inexpensive Disks (RAID) configuration. In some embodiments, database 210 may include a storage area network (SAN) and / or network attached storage (NAS) system. In embodiments, database 210 may correspond to a distributed storage system, wherein each database is configured to store custom information, such as one or more gap requirements, temporary UE capability configurations, etc.

[0305] In some embodiments, database 210 is integrated within UE 104. For example, UE 104 may include one or more hard drives, such as database 210. In other embodiments, database 210 is located external to UE 104 and can be accessed by UE 104 via a storage interface (…). Figure 2 (Not shown in the image) accesses the database. A storage interface is any component that provides access to the database 210 for the processor 202. A storage interface may include, for example, an Advanced Technology Attachment (ATA) adapter, a Serial ATA (SATA) adapter, a Small Computer System Interface (SCSI) adapter, a RAID controller, a SAN adapter, a network adapter, and / or any component that provides access to the database 210 for the processor 202.

[0306] Figure 3 A sequence flow of a method 300 for reporting UE capabilities for a MUSIM UE according to an embodiment of this disclosure is shown.

[0307] At position 302, the network entity sends a request for transmitting UE capabilities. In one embodiment, network entity 108 sends the request for transmitting UE capabilities when the UE registers with the network. In another embodiment, network entity 108 sends the request when it needs to obtain additional capabilities from the network. In embodiments of this disclosure, UE capabilities may include one or more gap requests.

[0308] At 304, UE 104 determines whether it can report changes to one or more gap requirements. One or more gap requirements can be, but are not limited to, measurement gap requirements, NCSG requirements, interruption requirements, etc. In an embodiment, one or more gap requirements change due to MUSIM operation. For example, consider UE 104 with two USIMs (i.e., USIM-A and USIM-B). USIM-A is in an RRC connected state, and USIM-B is in an RRC idle state. One or more gap requirements for the current MUSIM operation are determined and stored in UE 104. However, when the state of USIM-B changes from RRC idle to RRC connected, one or more gap requirements change. In another example, consider USIM-B switching from a licensed frequency to an unlicensed frequency, or from one frequency range (FR) to another FR. Due to the change in FR, measurement gap requirements and NCSG requirements change. In another example, consider no change in FR. Interruption requirements may change due to changes in network state. Based on changes to one or more gap requirements, UE capabilities need to be reconfigured.

[0309] At 306, UE 104 sends a UE capability reporting one or more gap requests to network entity 108. In one embodiment, the one or more gap requests are sent to network entity 108 as part of a UE Assistance Information (UAI) message or a UE Capability Information. In another embodiment, the one or more gap requests are sent to network entity 108 as part of a New Information Element (IE). The UE capability reporting one or more gap requests is indicated, but is not limited to, flags, different fields, and attributes in the UAI / IE message.

[0310] In this embodiment, UE 104 receives a temporary UE capability configuration from network entity 108 based on the UE capability to report one or more gap requirements. (See reference...) Figure 4 A detailed explanation of temporary UE capability configuration.

[0311] refer to Figure 3 Method 300 can be implemented using software including computer-executable instructions stored on one or more computer-readable media (e.g., non-transitory computer-readable media, such as one or more optical discs, volatile memory components (e.g., DRAM or SRAM), or non-volatile memory or storage components (e.g., hard disk drives or solid-state non-volatile memory components, such as flash memory components)) and executed on a computer (e.g., any suitable computer, such as a laptop computer, netbook, webbook, tablet computing device, smartphone, or other mobile computing device). Such software can, for example, execute on a single local computer.

[0312] Figure 4 The sequence flow of method 400 for configuring UE capabilities for MUSIM UE is shown.

[0313] At 402, network entity 108 receives UE capabilities. In an embodiment, the UE capability is indicated as musim-CapabilityRestriction in the UAI message. The UE capability includes the ability of UE 104 to report changes in one or more gap requirements. In an embodiment, the UE capability is sent as an RRC message from UE 104 to network entity 108 to inform network entity 108 of the details of its capability. For example, the UE capability may include one or more gap requirements. These one or more gap requirements may be, but are not limited to: measurement gap requirements, NCSG requirements, and interruption requirements. In an embodiment, one or more gap requirements change due to MUSIM operation. For example, consider UE 104 with two USIMs (i.e., USIM-A and USIM-B), USIM-A is in an RRC connected state, and USIM-B is in an RRC idle state. Due to a change in the network state of USIM-B, the state of USIM-B changes from RRC idle to RRC connected, and one or more gap requirements change. For example, consider USIM-B switching from a licensed frequency to an unlicensed frequency, or switching from one frequency range (FR) to another FR. Due to changes in FR (Frequency Response), measurement gap requirements and NCSG (Non-Committed Service Requirement) change. In another example, if FR does not change, interruption requirements change due to changes in network state. Upon receiving UE capabilities, network entity 108 determines one or more gap requirements (i.e., temporary UE capability configurations) based on the received UE capabilities. One or more gap requirements (i.e., temporary UE capability configurations) are configured for the UE based on changes in MUSIM operation. Temporary UE capabilities ensure faster communication and improve network connectivity. In an embodiment, network entity 108 sends the temporary UE capability configuration to the target network during the handover of UE 104. In an embodiment, UE 104 sends a request to update one or more gap requirements arising from MUSIM operation (i.e., temporary UE capability configurations). In an embodiment, the request to update the temporary UE capability configuration is indicated by MUSIMCapabilityChangeUpdateConfig. For example, consider UE 104 with two USIMs (i.e., USIM-A and USIM-B), USIM-A in RRC connected state and USIM-B in RRC idle state. Consider USIM-B's state changing from RRC idle to RRC connected. Due to the change in state, one or more gap requirements change. Therefore, network entity 108 determines the temporary UE capability configuration. However, when the MUSIM configuration returns to its initial state (i.e., USIM-A is in RRC connected state and USIM-B is in RRC idle state), the temporary UE capability configuration needs to be removed from UE 104. Therefore, network entity 108 updates the temporary UE capability configuration to the initial UE capability configuration.

[0314] At position 404, network entity 108 sends a temporary UE capability configuration (i.e., one or more gap request configurations) to UE 104. In one embodiment, network entity 108 sends the temporary UE capability configuration to a target network. The target network may be a network already identified for the handover of UE 104. In another embodiment, UE 104 requests a temporary UE capability configuration from network entity 108.

[0315] refer to Figure 4 Method 400 can be implemented using software including computer-executable instructions, which are stored on one or more computer-readable media (e.g., non-transitory computer-readable media, such as one or more optical discs, volatile memory components (e.g., DRAM or SRAM) or non-volatile memory or storage components (e.g., hard disk drives or solid-state non-volatile memory components, such as flash memory components)) and executed on a computer (e.g., any suitable computer, such as a laptop computer, netbook, webbook, tablet computing device, smartphone, or other mobile computing device). Such software can, for example, execute on a single local computer.

[0316] Figure 5 A method 500 for reporting UE capabilities included in a MUSIM UE according to an embodiment of this disclosure is illustrated.

[0317] At 502, the network entity sends a request to transmit UE capabilities. In an embodiment, the UE capabilities are transmitted as an RRC message from UE 104 to network entity 108 to inform network entity 108 of the details of its capabilities. For example, UE capabilities may include one or more gap requirements. One or more gap requirements may be, but are not limited to, measurement gap requirements, Network Control Small Gap (NCSG) requirements, interruption requirements, etc. In an embodiment, one or more gap requirements change due to MUSIM operation. MUSIM operation indicates a network state transition associated with one of UE 104's Universal Subscriber Identity Modules (USIMs). For example, consider UE 104 with two USIMs (i.e., USIM-A and USIM-B), USIM-A being in an RRC connected state and USIM-B being in an RRC idle state. Due to a change in the state of USIM-B (i.e., from RRC idle to RRC connected), one or more gap requirements change. Based on the change in one or more gap requirements, the UE capabilities need to be changed. For example, consider USIM-B switching from a licensed frequency to an unlicensed frequency, or switching from one frequency range (FR) to another FR. Due to changes in FR, measurement gap requirements and NCSG requirements may change. In another example, if FR does not change, interruption requirements may change due to changes in network status.

[0318] At 502, UE 104 determines whether it is able to report changes to one or more gap requirements. The UE's ability to report one or more gap requirements is determined based on one or more attributes. These attributes are: musim-CapabilityRestriction, nr-NeedForGap-Reporting, nr-NeedForInterruptionReport, and nr-NeedForGapNCSG-Reporting. The one or more gap requirements are: measurement gap requirements, Network Control Small Gap (NCSG) requirements, and interruption requirements.

[0319] At 506, UE 104 sends a UE capability reporting one or more gap requests to network entity 108. In one embodiment, the one or more gap requests are sent to network entity 108 as part of a UAI message or UECapabilityInformation. In one embodiment, the UE capability reporting one or more gap requests is indicated as, but not limited to, flags, different fields, or attributes in the UAI message. In one embodiment, UE 104 requests a temporary UE capability configuration based on the UE capability from network entity 108. In another embodiment, UE 104 reports one or more gap requests to network entity 108. (See reference...) Figure 6A detailed explanation of how network entity 108 determines the temporary UE capability configuration.

[0320] refer to Figure 5 Method 500 can be implemented using software including computer-executable instructions, which are stored on one or more computer-readable media (e.g., non-transitory computer-readable media, such as one or more optical discs, volatile memory components (e.g., DRAM or SRAM), or non-volatile memory or storage components (e.g., hard disk drives or solid-state non-volatile memory components, such as flash memory components)) and executed on a computer (e.g., any suitable computer, such as a laptop computer, netbook, webbook, tablet computing device, smartphone, or other mobile computing device). Such software can, for example, execute on a single local computer.

[0321] Figure 6 A method 600 for configuring UE capabilities for a MUSIM UE according to an embodiment of the present disclosure is shown.

[0322] At 602, network entity 108 receives UE capabilities. UE capabilities include the ability of UE 104 to report changes in one or more gap requirements. In an embodiment, UE capabilities are sent as an RRC message from UE 104 to network entity 108 to inform network entity 108 of the details of its capabilities. For example, UE capabilities may include one or more gap requirements. One or more gap requirements may be, but are not limited to: measurement gap requirements, network control small gap (NCSG) requirements, interruption requirements, etc. In an embodiment, one or more gap requirements change due to MUSIM operation. For example, consider UE 104 with two USIMs (i.e., USIM-A and USIM-B), USIM-A is in an RRC connected state, and USIM-B is in an RRC idle state. One or more gap requirements for the current MUSIM operation are fixed. However, when the state of USIM-B changes from RRC idle to RRC connected, one or more gap requirements change. Based on the change in one or more gap requirements, the UE capabilities need to be changed. For example, consider USIM-B switching from a licensed frequency to an unlicensed frequency, or switching from one frequency range (FR) to another FR. Due to the change in FR, the measurement gap requirements and NCSG requirements change. In another example, if FR does not change, the interruption requirements change due to changes in network status.

[0323] At 604, network entity 108 determines a temporary UE capability configuration based on the received UE capabilities. The temporary UE capability configuration is a configuration of the UE based on changes in MUSIM operation. Temporary UE capabilities ensure faster communication and improve network connectivity. In an embodiment, network entity 108 sends the temporary UE capability configuration to the target network. In an embodiment, UE 104 sends a request to update one or more gap requirements (i.e., the temporary UE capability configuration) resulting from MUSIM operation. In an embodiment, the request to update the temporary UE capability configuration is indicated by MUSIMCapabilityChangeUpdateConfig. For example, consider a UE 104 with two USIMs (i.e., USIM-A and USIM-B), USIM-A in an RRC connected state and USIM-B in an RRC idle state, where one or more gap requirements of the current MUSIM operation are fixed. However, when the state of USIM-B changes from RRC idle to RRC connected, one or more gap requirements change, therefore, network entity 108 determines the temporary UE capability configuration. However, when the MUSIM configuration returns to its initial state (i.e., USIM-A is in RRC connected state and UAIM-B is in RRC idle state), the temporary UE capability configuration needs to be removed from UE 104. Therefore, one or more gap requirements (i.e., temporary UE capability configurations) are updated. Network entity 108 reconfigures the updated one or more gap requirements.

[0324] At position 606, network entity 108 sends a temporary UE capability configuration to UE 104. In one embodiment, network entity 108 sends the temporary UE capability configuration to a target network. The target network may be the network to which UE 104 is handed over. In another embodiment, UE 104 requests a temporary UE configuration from network entity 108.

[0325] In this embodiment, UE 104 may request a network entity to remove a temporary UE capability configuration. For example, consider UE 104 with two USIMs (USIM-A and USIM-B), where USIM-A is in an RRC connected state and USIM-B is in an RRC idle state. One or more gap requirements for the current MUSIM operation are fixed. However, when the state of USIM-B changes from RRC idle to RRC connected, one or more gap requirements change, therefore, network entity 108 determines a temporary UE capability configuration. However, when the MUSIM configuration returns to its initial operation (i.e., USIM-A is in an RRC connected state and USIM-B is in an RRC idle state), the temporary UE capability configuration needs to be removed from UE 104.

[0326] refer to Figure 6Method 600 can be implemented using software including computer-executable instructions, which are stored on one or more computer-readable media (e.g., non-transitory computer-readable media, such as one or more optical discs, volatile memory components (e.g., DRAM or SRAM), or non-volatile memory or storage components (e.g., hard disk drives or solid-state non-volatile memory components, such as flash memory components)) and executed on a computer (e.g., any suitable computer, such as a laptop computer, netbook, webbook, tablet computing device, smartphone, or other mobile computing device). Such software can, for example, execute on a single local computer.

[0327] The operations of methods 300, 400, 500, and 600 need not be performed in the same order as presented. Furthermore, one or more operations can be combined and performed as a single step, or an operation can contain multiple sub-steps that can be performed in parallel or sequentially.

[0328] Figure 7 A block diagram of an exemplary computer system 700 for implementing embodiments consistent with this disclosure is shown. Computer system 700 may be, but is not limited to, UE 104 and network entity 108. Computer system 700 may include a central processing unit (“CPU” or “processor”) 701. Processor 701 may include at least one data processor for performing processes. Processor 701 may include dedicated processing units such as an integrated system (bus) controller, a memory management control unit, a floating-point unit, a graphics processing unit, a digital signal processing unit, etc.

[0329] The processor 701 can be configured to communicate with one or more input / output (I / O) devices 708 and 709 via I / O interface 707. I / O interface 707 can employ communication protocols / methods such as, but not limited to, audio, analog, digital, mono, RCA, stereo, IEEE-1394, serial bus, Universal Serial Bus (USB), infrared, PS / 2, BNC, coaxial, component, composite, digital video interface (DVI), high-definition multimedia interface (HDMI), RF antenna, S-Video, VGA, IEEE 902.n / b / g / n / x, Bluetooth, cellular (e.g., Code Division Multiple Access (CDMA), High Speed ​​Packet Access (HSPA+), Global System for Mobile Communications (GSM), Long Term Evolution (LTE), WiMax, etc.).

[0330] Using I / O interface 707, computer system 700 can communicate with one or more I / O devices 708 and 709. For example, input device 708 can be an antenna, keyboard, mouse, joystick, (infrared) remote control, camera, card reader, fax machine, dongle, biometric reader, microphone, touchscreen, touchpad, trackball, stylus, scanner, storage device, transceiver, video device / source, etc. Output device 709 can be a printer, fax machine, video display (e.g., cathode ray tube (CRT), liquid crystal display (LCD), light-emitting diode (LED), plasma, plasma display panel (PDP), organic light-emitting diode display (OLED), etc.), audio speaker, etc.

[0331] In some embodiments, processor 701 may be configured to communicate with external components, such as external computer systems, servers, or network components. The network interface 710 may employ connection protocols including, but not limited to, direct connection, Ethernet (e.g., twisted pair 10 / 100 / 1000 Base T), Transmission Control Protocol / Internet Protocol (TCP / IP), Token Ring, IEEE 802.11a / b / g / n / x, etc.

[0332] In some embodiments, the processor 701 may be configured to communicate with the memory 703 (e.g., RAM, ROM, etc.) via a storage interface 702. The storage interface 702 may be connected to the memory 703, including but not limited to memory drives, removable disk drives, etc., using connection protocols such as Serial Advanced Technology Attachment (SATA), Integrated Drive Electronics (IDE), IEEE-1394, Universal Serial Bus (USB), Fibre Channel, Small Computer System Interface (SCSI), etc. The memory drive may also include magnetic drums, disk drives, magneto-optical drives, optical disc drives, redundant arrays of independent disks (RAID), solid-state memory devices, solid-state drives, etc.

[0333] Memory 703 may store a collection of program or database components, including but not limited to user interface 704, operating system 705, web browser 706, etc. In some embodiments, computer system 700 may store user / application data, such as data, variables, records, etc., as described in this disclosure. Such a database may be implemented as a fault-tolerant, relational, scalable, and secure database, such as Oracle® or Sybase®.

[0334] Operating system 705 facilitates resource management and operation of computer system 700. Examples of operating systems include, but are not limited to: APPLE MACINTOSH® OS X, UNIX®, and UNIX-like system distributions (e.g., BERKELEY SOFTWARE EDISTRIBUTION).TM (BSD), FREEBSD™, NETBSD™, OPENBSD™, etc.), LINUX DISTRIBUTIONS TM (For example, RED HAT) TM UBUNTU TM KUBUNTU TM etc.), IBM TM OS / 2, Microsoft TM WINDOWS TM (XP) TM VISTA TM / 7 / 8, 10, etc.), APPLE® IOS TM Google® Android TM BLACKBERRY® OS, etc.

[0335] In some embodiments, the computer system 700 may implement the program components stored in the web browser 706. The web browser 706 may be a hypertext viewing application, such as Microsoft. ® INTERNET EXPLORER ® Google TM CHROME TM MOZILLA ® FIREFOX ® APPLE ® SAFARI ® Secure web browsing can be provided using protocols such as Secure Hypertext Transfer Protocol (HTTPS), Secure Sockets Layer (SSL), and Transport Layer Security (TLS). Web browser 706 can utilize facilities such as AJAX, DHTML, Adobe® Flash®, JavaScript®, Java®, and Application Programming Interfaces (APIs). In some embodiments, computer system 700 can implement program components stored on a mail server. The mail server can be an Internet mail server, such as Microsoft Exchange. The mail server can utilize technologies such as Dynamic Server Pages (ASP), ActiveX, etc. ® ANSI ® C++ / C#, Microsoft ® .NET, CGI SCRIPTS, JAVA ® JAVASCRIPT ® PERL ® PHP, Python ® WEBOBJECTS® Facilities such as Internet Message Access Protocol (IMAP), Message Passing Application Programming Interface (MAPI), and Microsoft... ® Communication protocols such as email exchange, Post Office Protocol (POP), and Simple Mail Transfer Protocol (SMTP) are used. In some embodiments, the computer system 700 may implement a program component storing an email client. The email client may be an email viewing application, such as Apple... ® MAIL, MICROSOFT ® ENTOURAGE ® MICROSOFT ® OUTLOOK ® MOZILLA ® THUNDERBIRD ® wait.

[0336] Figure 15 A flowchart is shown of the operation (in DC) of a secondary node (SN) for a MUSIM wait timer according to an embodiment of the present disclosure.

[0337] The SN can receive temporary capability restrictions from the MN, such as musim-CelltoAffectList-r18 or musim-CellToRelease-r18, as well as the MUSIM wait timer. The MUSIM wait timer expires. The SN can apply received temporary capability restrictions, such as reducing the DL / UL MIMO layer or DL / UL Rx layer in musim-CellToAffectList, or releasing the Scell ​​in musim-CellToReleasesList for the SCG.

[0338] Figure 16 A flowchart is shown of the master node (MN) operation (in DC) of the MUSIM wait timer according to an embodiment of the present disclosure.

[0339] The MN can configure a MUSIM wait timer for the UE and notify the SN of the MUSIM wait timer. The MN can receive temporary capability restrictions, such as musim-CellToAffectList-R18 or musim-CellToRelease-r18, and at least notify the SN of the SCG restrictions. The MUSIM wait timer expires. The MN can apply the received temporary capability restrictions, such as reducing the DL / UL MIMO layer or DL / UL Rx layer in musim-CellToAffectList, or releasing the SCell in musim-CellToReleaseList for MCG.

[0340] Figure 17 Operation of a control unit (CU) for a MUSIM wait timer according to an embodiment of this disclosure is illustrated. The CU can configure a MUSIM wait timer (such as musim-WaitTimer) for the UE. The CU can receive a muim-WaitTimer from another CU for handover / re-establishment / dual connectivity. The CU can notify the DU of the MUSIM wait timer. The MUSIM wait timer expires. The CU can release the Scell, SCG, etc. (if received in a temporary capability restriction request from the UE).

[0341] Figure 18 Distributed unit (DU) operation for a MUSIM wait timer according to an embodiment of this disclosure is illustrated. The DU can receive temporary capability constraints, such as musim-CellToAffectList-r18 or musim-CellToRelease-r18, and the MUSIM wait timer from the CU. The MUSIM wait timer expires. The DU can apply temporary capability constraints, such as reducing DL / UL MIMO layers, DL / UL Rx layers, etc., based on the musim-CellToAffectList received from the CU, and release Scells in the musim-CellToReleaseList received from the CU.

[0342] Figure 19 User equipment (UE) operation with respect to a MUSIM wait timer according to embodiments of this disclosure is illustrated. The UE may be configured with a MUSIM wait timer. The UE may notify the network of temporary capability restrictions without requesting the release of the SCG. The MUSIM wait timer expires. The UE may apply temporary capability restrictions to the MCG and release the SCG.

[0343] Figure 20An environment 2000 is illustrated in which certain embodiments of this disclosure can be practiced. Environment 100 exemplarily depicts a UE 104, some examples of which may include, but are not limited to, electronic devices such as smartphones, laptops, desktops, personal computers, or any spatial computing device capable of performing wireless communication. For example, UE 104 may run on multiple platforms and / or operating systems to perform different operations related to wireless communication. In embodiments, UE 104 may host more than one Subscriber Identity Module (SIM), i.e., UE 104 is a MUSIM (Multi-SIM) UE. In the exemplary scenario, UE 104 may initiate a connection with a centralized unit (CU) 2002 under various conditions. Furthermore, CU 2002 may establish a connection with a distributed unit (DU) under various conditions. For example, several conditions associated with UE 104 may include: initial access of CU 2002 from RRC idle, transition from RRC inactivity to RRC connection, RRC connection reconstruction, handover, beam fault recovery, synchronization reconfiguration, timing alignment during the addition of a secondary cell (Scell), downlink (DL) asynchrony, uplink (UL) asynchrony, the maximum amount of scheduling requests (SRs) reached, UL data arrival, and on-demand system information. It should be noted that the above conditions are for illustrative purposes only, and UE 104 may establish a connection with CU 2002 based on other conditions. In this embodiment, UE 104 establishes a connection with CU 2002 to configure UE capabilities based on MUSIM operation. In this embodiment, CU 2002 may communicate with DU 2004 to configure UE capabilities. MUSIM operation indicates network state transitions associated with one of UE 104's Universal Subscriber Identity Modules (USIMs).

[0344] The CU used in this paper is part of the O-RAN architecture, which provides support for higher layers of the protocol stack, such as, but not limited to, the Serving Data Adaptation Protocol (SDAP), RRC, and Packet Data Convergence Protocol (PDCP) layers. In this embodiment, a 5G protocol stack and a 5G hardware acceleration card are used to process the protocols.

[0345] The DU used in this document processes the lower layers of the protocol stack, including but not limited to the upper physical layer, MAC layer, and RLC layer. The functions of the DU may include, but are not limited to: data organization and management, interaction with the Radio Unit (RU), and latency reduction and efficiency. The DU is responsible for preparing the data to be transmitted, structuring the data to ensure that the data is formatted correctly for efficient radio transmission. The DU directly manages data communication with the RU, converting structured data into radio waves for transmission and vice versa. The DU is located close to the RU and manages the lower protocol layers, ensuring minimal latency, which is particularly important for real-time data exchange applications. It is understood that UE 104 can communicate with CU 2002 (such as the Internet, implemented by a network provider (also known as an Internet Service Provider (ISP))). UE 104 can connect to CU 2002 using a wireless network. Some non-limiting examples of wireless networks may include wireless LAN (WLAN), cellular networks, Bluetooth, or ZigBee networks.

[0346] In this embodiment, CU 2002 can establish a connection with DU 2002 via a communication network. It is understood that CU 2002 can communicate with DU 2004 (such as the Internet, provided by a network provider (also known as an Internet Service Provider (ISP))). CU 2002 can connect to DU 2004 using a wireless network. Some non-limiting examples of wireless networks may include wireless LAN (WLAN), cellular networks, Bluetooth, or ZigBee networks, etc. In this embodiment, CU 2002 is coupled to DU 2004. In another embodiment, CU 2002 may be located in a different location.

[0347] Various embodiments of this disclosure disclose a method for configuring UE capabilities via CU 2002 using DU 2004. UE capabilities include one or more gap requirements. DU 2004 identifies affected and restricted frequency bands caused by MUSIM operation from temporary UE capability restrictions and generates a UE configuration. Modules of DU 2004 are... Figure 2 The modules described herein are similar; to avoid privacy breaches, further explanation is unnecessary. Further details regarding... Figure 21 This section will explain in detail the communication between UE 104, CU 2002 and DU 2004.

[0348] Figure 21A sequence flow of a method 2100 for configuring UE capabilities according to an embodiment of this disclosure is shown. At 2102, UE 104 sends temporary UE capability restrictions to CU 2002. Temporary UE capability restrictions may include, but are not limited to, frequencies that the UE is temporarily unable to support due to MUSIM operation, i.e., which of its supported capabilities are temporarily restricted. MUSIM operation indicates a network state transition associated with one of the UE's USIMs, where network states include: idle state, connected state, and inactive state. For example, considering that USIM-A transitions from an idle state to a connected state, and USIM-B is in a connected state, the MUSIM operation changes. Therefore, some capabilities are restricted.

[0349] At 2104, CU 2002 sends temporary UE capability restrictions and one or more frequency band lists to DU 2004. The one or more frequency band lists can be sent in an F1 Application Protocol (AP) Information Element (IE) associated with one of the following messages: UE Context Establishment Request Message, UE Context Modification Request Message, and Inter-Node RRC Message CG-Config. In one embodiment, the one or more frequency band lists are frequency band lists configured by the CU to the UE. In another embodiment, another CU configures one or more frequency band lists, and these are received by CU 2002 in HandoverPreparationInformation. In yet another embodiment, the one or more frequency band lists are frequency band lists configured by the primary node, and when the CU is a secondary node in dual connectivity, these are received by the CU in CG-Config. The one or more frequency band lists are sent as an octet string (OCTETSTRING) encoded in RRC ASN.1 format in the CU-DU RRC information, with critical states ignored.

[0350] At 2106, DU 2004 identifies the affected and restricted frequency bands caused by MUSIM operation from the temporary UE capability restrictions based on one or more frequency band lists. For example, consider USIM-A in a connected state using frequency band A and USIM-B in an idle state using frequency band B. Consider that due to this change in MUSIM operation, the state of USIM-B changes from idle to connected, frequency band A is affected and frequency band B is restricted. In this example, DU 2004 identifies that frequency bands A and B are unusable. DU 2004 identifies that frequency bands C and D can be used based on one or more frequency band lists received by CU 2002. DU 2106 generates a UE configuration based on this identification. In this embodiment, the UE configuration is a temporary UE capability.

[0351] At 2108, DU 2004 sends the UE configuration to CU 2002. At 2110, CU 2002 sends the UE configuration to UE 104. DU 2004 must send the UE configuration via CU 2002.

[0352] refer to Figure 21 Method 2100 can be implemented using software including computer-executable instructions, which are stored on one or more computer-readable media (e.g., non-transitory computer-readable media, such as one or more optical discs, volatile memory components (e.g., DRAM or SRAM) or non-volatile memory or storage components (e.g., hard disk drives or solid-state non-volatile memory components, such as flash memory components)) and executed on a computer (e.g., any suitable computer, such as a laptop computer, netbook, webbook, tablet computing device, smartphone, or other mobile computing device). Such software can, for example, execute on a single local computer.

[0353] The order of operations in method 2100 need not be performed in the same order as presented. Furthermore, one or more operations can be combined and performed as a single step, or an operation can contain multiple sub-steps that can be performed in parallel or sequentially.

[0354] Figure 22 A flowchart of a method 2200 for configuring UE capabilities according to an embodiment of the present disclosure is shown.

[0355] At 2202, DU 2004 receives temporary UE capability restrictions and one or more frequency band lists from CU 2002. CU 2002 receives temporary UE capability restrictions caused by MUSIM operation from UE 104. The temporary UE capability restrictions indicate the temporary radio frequency capabilities of frequency bands in one or more frequency band lists configured in UE 104. Temporary UE capability restrictions may include, but are not limited to, frequencies that the UE is temporarily unable to support due to MUSIM operation, i.e., which of its supported capabilities are temporarily restricted. MUSIM operation indicates a network state transition associated with one of the UE's USIMs, where network states include: idle state, connected state, and inactive state. One or more frequency band lists may be received by DU 2004 in an F1 AP IE associated with one of the following messages: UE Context Establishment Request message, UE Context Modification Request message, and inter-node RRC message CG-Config. In one embodiment, the one or more frequency band lists are frequency band lists configured to the UE by the CU. In another embodiment, another CU configures one or more frequency band lists, and CU 2002 receives them in HandoverPreparationInformation. In yet another embodiment, one or more frequency band lists are frequency band lists configured by the master node and received by the CU in CG-Config when the CU is the secondary node in a dual connection. One or more frequency band lists are transmitted as an octet string encoded in RRC ASN.1 format in the CU-DU RRC information, with critical states ignored.

[0356] At 2204, DU 2004 identifies affected and restricted frequency bands caused by MUSIM operations from temporary UE capability limitations based on one or more frequency band lists. For example, consider USIM-A in a connected state using frequency band A and USIM-B in an idle state using frequency band B. Consider that due to this change in MUSIM operations, USIM-B's state changes from idle to connected, resulting in frequency band A being affected and frequency band B being restricted. In this example, DU 2004 identifies that frequency bands A and B are unusable. DU 2004 identifies usable frequency bands C and D based on one or more frequency band lists received by CU 2002. DU 2106 generates a UE configuration based on this identification. In an embodiment, to identify affected and restricted frequency bands, DU 2004 identifies the MIMO layer in the downlink (DL), the MIMO layer in the uplink (UL), the supportedBandwidth in the DL, and the supportedBandwidth in the UL for each frequency band and frequency band combination in one or more frequency band lists.

[0357] At 2206, DU 2004 generates a UE configuration based on the affected and restricted frequency bands in the UE via the CU based on this identification. For example, consider that DU 2004 identifies from temporary UE capability limitations that frequency bands A and B are affected and restricted frequency bands due to MUSIM operation, and that frequency bands C and D are available frequency bands for MUSIM operation. DU 2004 sends the UE configuration with available frequency bands to UE 104 via CU 2002.

[0358] refer to Figure 22 Method 2200 can be implemented using software including computer-executable instructions stored on one or more computer-readable media (e.g., non-transitory computer-readable media, such as one or more optical discs, volatile memory components (e.g., DRAM or SRAM) or non-volatile memory or storage components (e.g., hard disk drives or solid-state non-volatile memory components, such as flash memory components)) and executed on a computer (e.g., any suitable computer, such as a laptop computer, netbook, webbook, tablet computing device, smartphone, or other mobile computing device). Such software can, for example, execute on a single local computer.

[0359] The order of operations in Method 2200 need not be performed in the same order as presented. Furthermore, one or more operations can be combined and performed as a single step, or an operation can contain multiple sub-steps that can be performed in parallel or sequentially.

[0360] This disclosure discloses a method and a UE for reporting UE capabilities for a MUSIM UE. This disclosure enables the transmission of changes in gap requirements due to variations in MUSIM operation, thereby receiving temporary configurations supporting various MUSIM operations. Furthermore, temporary UE capability configurations improve resource allocation for the MUSIM UE. This disclosure also contributes to improved communication and seamless handover.

[0361] Figure 24 The following describes CU operation for temporary capability restrictions according to embodiments of the present disclosure. The CU can configure band filters (such as musim-CandidateBandList) for the UE and receive band filters (such as musim-CandidateBandList) for handover / re-establishment / dual connectivity from another CU. The CU can receive temporary capability restrictions, such as MUSIM-AffectedBandList or musim-AvoidedBandsList. The CU can notify the DU of the band filters and temporary capability restrictions.

[0362] Figure 25The following describes DU operation for temporary capability restrictions according to embodiments of the present disclosure. The DU may receive temporary capability restrictions, such as MUSIM-AffectedBandsList or MUSIM-AvoidedBandsList, and band filters (such as MUSIM-CandidateBandList). The DU may identify the maximum number of MIMO layers in the DL and UL for each band based on the received temporary capability restrictions and band filters. The DU may generate UE configuration and DU-CU RRC information based on the identified parameters.

[0363] Using standard programming and / or engineering techniques, the operations can be implemented as methods, systems, or articles of art to generate software, firmware, hardware, or any combination thereof. The operations can be implemented as code stored in a "non-transitory computer-readable medium," from which a processor can read and execute the code. The processor is at least one of a microprocessor and a processor capable of processing and executing queries. Non-transitory computer-readable media can include media such as magnetic storage media (e.g., hard disk drives, floppy disks, magnetic tapes, etc.), optical storage devices (CD-ROMs, DVDs, optical discs, etc.), and volatile and non-volatile storage devices (e.g., EEPROMs, ROMs, PROMs, RAMs, DRAMs, SRAMs, flash memory, firmware, programmable logic, etc.). Furthermore, non-transitory computer-readable media can include all computer-readable media other than transient media. The code implementing the operations can also be implemented in hardware logic (e.g., integrated circuit chips, programmable gate arrays (PGAs), application-specific integrated circuits (ASICs), etc.).

[0364] The steps shown are intended to explain the exemplary embodiments illustrated, and it should be anticipated that ongoing technological developments will change how certain functions are performed. The examples presented herein are for illustrative purposes only and not for limiting purposes. Furthermore, for ease of description, the boundaries of functional building blocks have been arbitrarily defined herein. Alternative boundaries can be defined as long as the specific functions and their relationships are properly performed. Based on the teachings contained herein, alternatives (including equivalents, extensions, variations, deviations, etc., of the solutions described herein) will be apparent to those skilled in the art. Such alternatives all fall within the scope and spirit of the disclosed embodiments. Furthermore, words such as “comprising,” “having,” “containing,” and “including,” as well as other similar forms, are intended to be equivalent in meaning and should be open-ended, as one or more items following any of these words are not intended to be an exhaustive list of those items, nor are they limited to the listed items. It must also be noted that, unless the context explicitly states otherwise, the singular forms “a,” “an,” and “the” include plural indicators.

[0365] Furthermore, in embodiments consistent with this disclosure, one or more computer-readable storage media may be utilized. A computer-readable storage medium refers to any type of physical memory capable of storing processor-readable information or data. Therefore, a computer-readable storage medium may store instructions executable by one or more processors, including instructions for causing the processor to perform steps or stages consistent with the embodiments described herein. The term "computer-readable medium" should be understood to include tangible objects and exclude carrier waves and transient signals, i.e., non-transient signals. Examples include random access memory (RAM), read-only memory (ROM), volatile memory, non-volatile memory, hard disk drives, CD-ROMs, DVDs, flash drives, magnetic disks, and any other known physical storage media.

[0366] Finally, the language used in this specification has been chosen primarily for readability and guidance purposes, and may not have been chosen to define or limit the subject matter of this disclosure. Therefore, the disclosure of embodiments of this disclosure is intended to be illustrative and not to limit the scope of this disclosure.

[0367] Regarding the use of virtually any plural and / or singular terms in this document, those skilled in the art can convert plural to singular and / or singular to plural as appropriate to the context and / or application. For clarity, various singular / plural permutations may be explicitly described herein.

Claims

1. A method performed by a terminal supporting a Multiple Subscriber Identity Module (MUSIM), the method comprising: Receive requests from network entities regarding the capabilities of the transmitting user equipment (UE); Determine whether the terminal is able to report changes in one or more gap requirements, wherein the changes in one or more gap requirements are based on MUSIM operation; as well as The UE capability that reports the one or more gap requirements is sent to the network entity.

2. The method of claim 1, wherein the MUSIM operation includes a network state transition associated with one of the Universal Subscriber Identity Modules (USIM) of the terminal.

3. The method of claim 1, further comprising: Receive temporary UE capability configuration based on the UE capabilities from the network entity; as well as The one or more gap requests are reported to the network entity in the UE Assistance Information (UAI) message.

4. The method of claim 1, wherein the UE capability reporting the one or more gap requirements is determined based on one or more attributes, the attributes including: musim-CapabilityRestriction, nr-NeedForGap-Reporting, nr-NeedForInterruptionReport and nr-NeedForGapNCSG-Reporting.

5. A method performed by a network entity, the method comprising: Send a request to the terminal for the transmission capabilities of the User Equipment (UE); as well as Upon determining whether the terminal is capable of reporting changes to one or more gap requirements, the UE capability is received from the terminal to report the one or more gap requirements to the network entity, wherein the changes to the one or more gap requirements are based on MUSIM operation.

6. The method of claim 5, wherein the MUSIM operation includes a network state transition associated with one of the Universal Subscriber Identity Modules (USIM) of the terminal.

7. The method of claim 5, further comprising: Send a temporary UE capability configuration based on the UE capabilities to the terminal; as well as The terminal receives one or more gap requests from the UE Assistance Information (UAI) message to the network entity.

8. A terminal supporting a Multiple Subscriber Identity Module (MUSIM), the terminal comprising: transceiver; as well as At least one processor is configured as follows: The transceiver receives requests for the capabilities of the transmitting user equipment (UE) from the network entity. Determine whether the terminal is able to report changes in one or more gap requirements, wherein the changes in the one or more gap requirements are based on MUSIM operation, and The UE capability to report the one or more gap requirements is transmitted to the network entity via the transceiver.

9. The terminal of claim 8, wherein the MUSIM operation includes a network state transition associated with one of the terminal's Universal Subscriber Identity Modules (USIM).

10. The terminal of claim 8, wherein the at least one processor is further configured to: Receive temporary UE capability configuration based on the UE capabilities from the network entity, and The one or more gap requests are reported to the network entity in the UE Assistance Information (UAI) message.

11. The terminal of claim 8, wherein the one or more gap requirements include at least one of a measurement gap requirement, a network control small gap (NCSG) requirement, or an interruption requirement.

12. The terminal of claim 8, wherein the UE capability reporting the one or more gap requirements is determined based on one or more attributes, the attributes including: musim-CapabilityRestriction, nr-NeedForGap-Reporting, nr-NeedForInterruptionReport and nr-NeedForGapNCSG-Reporting.

13. A network entity, comprising: transceiver; as well as At least one processor is configured as follows: The transceiver sends a request for the capabilities of the transmitting user equipment (UE) to the terminal. Upon determining whether the terminal is capable of reporting changes to one or more gap requirements, the UE capability to report the one or more gap requirements to the network entity is received from the terminal via the transceiver, wherein the changes to the one or more gap requirements are based on MUSIM operation.

14. The network entity of claim 13, wherein the MUSIM operation includes a network state transition associated with one of the Universal Subscriber Identity Modules (USIM) of the terminal.

15. The network entity of claim 13, wherein the at least one processor is further configured to: Sending a temporary UE capability configuration based on the UE capabilities to the terminal via the transceiver; and The transceiver receives from the terminal one or more gap requests to the network entity in the UE Assistance Information (UAI) message.

Images