A method and user equipment (UE) for reporting ue capabilities for a multi-subscriber identity module (MUSIM) ue

Abstract

The 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 a User Equipment (104) of reporting User Equipment (UE) capabilities for a Multi-Subscriber Identity Module (MUSIM) UE. The method includes receiving, by a UE (104), a request to transmit UE capabilities, from a network entity (108). 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 the one or more gap requirements is due to MUSIM operations. The method includes transmitting, by the UE (104), the UE capabilities of reporting the one or more gap requirements to the network entity (108).

Description

A METHOD AND USER EQUIPMENT (UE) FOR REPORTING UE CAPABILITIES FOR A MULTI-SUBSCRIBER IDENTITY MODULE (MUSIM) UE

[0001] The present disclosure relates to communication networks. More particularly, the present disclosure relates to a method of reporting UE capabilities for a Multi-Subscriber Identity Module (MUSIM) UE and a UE thereof.

[0002] 5G mobile communication technologies define broad frequency bands such that high transmission rates and new services are possible, and can be implemented not only in "Sub 6GHz" bands such as 3.5GHz, but also in "Above 6GHz" bands referred to as mmWave including 28GHz and 39GHz. In addition, it has been considered to implement 6G mobile communication technologies (referred to as Beyond 5G systems) in terahertz bands (for example, 95GHz to 3THz bands) in order to accomplish transmission rates fifty times faster than 5G mobile communication technologies and ultra-low latencies one-tenth of 5G mobile communication technologies.

[0003] At the beginning of the development of 5G mobile communication technologies, in order to support services and to satisfy performance requirements in connection with enhanced Mobile BroadBand (eMBB), Ultra Reliable Low Latency Communications (URLLC), and massive Machine-Type Communications (mMTC), there has been ongoing standardization regarding beamforming and massive MIMO for mitigating radio-wave path loss and increasing radio-wave transmission distances in mmWave, supporting numerologies (for example, operating multiple subcarrier spacings) for efficiently utilizing mmWave resources and dynamic operation of slot formats, initial access technologies for supporting multi-beam transmission and broadbands, definition and operation of BWP (BandWidth Part), new channel coding methods such as a LDPC (Low Density Parity Check) code for large amount of data transmission and a polar code for highly reliable transmission of control information, L2 pre-processing, and network slicing for providing a dedicated network specialized to a specific service.

[0004] Currently, there are ongoing discussions regarding improvement and performance enhancement of initial 5G mobile communication technologies in view of services to be supported by 5G mobile communication technologies, and there has been physical layer standardization regarding technologies such as V2X (Vehicle-to-everything) for aiding driving determination by autonomous vehicles based on information regarding positions and states of vehicles transmitted by the vehicles and for enhancing user convenience, NR-U (New Radio Unlicensed) aimed at system operations conforming to various regulation-related requirements in unlicensed bands, NR UE Power Saving, Non-Terrestrial Network (NTN) which is UE-satellite direct communication for providing coverage in an area in which communication with terrestrial networks is unavailable, and positioning.

[0005] Moreover, there has been ongoing standardization in air interface architecture / protocol regarding technologies such as Industrial Internet of Things (IIoT) for supporting new services through interworking and convergence with other industries, IAB (Integrated Access and Backhaul) for providing a node for network service area expansion by supporting a wireless backhaul link and an access link in an integrated manner, mobility enhancement including conditional handover and DAPS (Dual Active Protocol Stack) handover, and two-step random access for simplifying random access procedures (2-step RACH for NR). There also has been ongoing standardization in system architecture / service regarding a 5G baseline architecture (for example, service based architecture or service based interface) for combining Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, and Mobile Edge Computing (MEC) for receiving services based on UE positions.

[0006] As 5G mobile communication systems are commercialized, connected devices that have been exponentially increasing will be connected to communication networks, and it is accordingly expected that enhanced functions and performances of 5G mobile communication systems and integrated operations of connected devices will be necessary. To this end, new research is scheduled in connection with eXtended Reality (XR) for efficiently supporting AR (Augmented Reality), VR (Virtual Reality), MR (Mixed Reality) and the like, 5G performance improvement and complexity reduction by utilizing Artificial Intelligence (AI) and Machine Learning (ML), AI service support, metaverse service support, and drone communication.

[0007] Furthermore, such development of 5G mobile communication systems will serve as a basis for developing not only new waveforms for providing coverage in terahertz bands of 6G mobile communication technologies, multi-antenna transmission technologies such as Full Dimensional MIMO (FD-MIMO), array antennas and large-scale antennas, metamaterial-based lenses and antennas for improving coverage of terahertz band signals, high-dimensional space multiplexing technology using OAM (Orbital Angular Momentum), and RIS (Reconfigurable Intelligent Surface), but also full-duplex technology for increasing frequency efficiency of 6G mobile communication technologies and improving system networks, AI-based communication technology for implementing system optimization by utilizing satellites and AI (Artificial Intelligence) from the design stage and internalizing end-to-end AI support functions, and next-generation distributed computing technology for implementing services at levels of complexity exceeding the limit of UE operation capability by utilizing ultra-high-performance communication and computing resources.

[0008] In Multi- Subscriber Identity Module (MUSIM) devices i.e., MUSIM User Equipments (UEs) that host more than one Subscriber Identity Module (SIM) have the facility to connect to two or more different networks. The MUSIM UE connects to two or more different networks in order to avail different data plans, utilize user profiles such as for home and office, increased connectivity, increased reliability with multiple connections, and the like. The multiple SIMs can be engaged in one or more operations (also referred as MUSIM operations) such as paging reception, System Information Block (SIB) acquisition, measurements, data or voice call, Multicast and Broadcast Service (MBS) reception, emergency call, Access Stratum (AS) signaling, Non-Access Stratum (NAS) signaling and the like. Some of the one or more of operations are periodic, for example, paging, and measurements. Some operations are aperiodic and un-deterministic, for example, signaling. The duration required to complete the operation may be fixed or unpredictable.

[0009] UE capabilities comprise information associated with gap requirements of the UE. The gap requirements are essential to perform measurements and thereby mobility. A MUSIM UE reports the gap requirements based on the configuration from the network. When there is a change in the state of any USIM, the gap requirements of other USIM are affected. However, the gap requirements in the UE capability are not known to the network unless the network configures the UE for reporting gap requirements due to MUSIM operations. Therefore, the MUSIM UE is unable to perform measurements and 'Secondary cell addition', 'handover', 'beam failure recovery', 'synchronous reconfiguration', 'Downlink (DL)', 'Uplink (UL)', 'Scheduling Request(SR), etc. Thereby degrading the network connectivity.

[0010] The information disclosed in this background of the disclosure section is only for enhancement of understanding of the general background of the invention and should not be taken as an acknowledgement or any form of suggestion that this information forms the prior art already known to a person skilled in the art.

[0011] The present disclosure provides a method of reporting UE capabilities for a Multi-Subscriber Identity Module (MUSIM) UE and a UE thereof.

[0012] The foregoing summary is illustrative only and is not intended to be in any way limiting. In addition to the illustrative aspects, embodiments, and features described above, further aspects, embodiments, and features will become apparent by reference to the drawings and the following detailed description.

[0013] In an embodiment, a method of reporting User Equipment (UE) capabilities for a Multi-Subscriber Identity Module (MUSIM) UE is disclosed. The method includes receiving, by a UE, a request to transmit UE capabilities, from a network entity. The method includes determining, by the UE, whether the UE is capable of reporting a change in one or more gap requirements. The change in the one or more gap requirements is due to MUSIM operations. The method includes transmitting, by the UE, the UE capabilities of reporting the one or more gap requirements to the network entity.

[0014] In an embodiment, a method of configuring UE capabilities for a MUSIM UE is disclosed. The method includes receiving, by a network entity, UE capabilities comprising information relating to one or more gap requirements due to MUSIM operations, from a UE. The method includes determining, by the network entity, temporary UE capability configurations based on the one or more gap requirements. The method includes transmitting, by the network entity, the temporary UE capability configurations to the UE.

[0015] In an 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 and thereby configured to receive a request to transmit UE capabilities from a network entity. The processor is configured to determine whether the UE is capable of reporting a change in one or more gap requirements. The change in the one or more gap requirements is due to MUSIM operations. The processor is configured to transmit the UE capabilities of reporting the one or more gap requirements to the network entity.

[0016] In an 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 and thereby configured to receive UE capabilities comprising information relating to one or more gap requirements due to MUSIM operations, from a UE. The processor is configured to determine temporary UE capability configurations based on the one or more gap requirements. The processor is configured to transmit the temporary UE capability configurations to the UE.

[0017] In an embodiment, a method of configuring User Equipment (UE) capabilities is disclosed. The method includes receiving, by a Distributed Unit (DU) , temporary UE capability restrictions and one or more band lists from a Centralized Unit (CU). The temporary UE capability restrictions due to Multi-Subscriber Identity Module (MUSIM) operations is received by the CU from a UE. The temporary UE capability restrictions indicate temporary radio frequency capabilities of bands in the one or more band lists configured in the UE. The method includes identifying, by the DU, affected bands and restricted bands due to the MUSIM operations from the temporary UE capability restrictions, based on the one or more band lists. The method includes generating, by the DU, a UE configuration based on the affected bands and restricted bands in the UE, via the CU, based on the identification.

[0018] In an 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 and thereby configured to receive temporary UE capability restrictions and one or more band lists from a CU. The temporary UE capability restrictions due to Multi-Subscriber Identity Module (MUSIM) operations is received by the CU from a UE. The temporary UE capability restrictions indicate temporary radio frequency capabilities of bands in the one or more band lists configured in the UE. The processor is configured to identify affected bands and restricted bands due to the MUSIM operations from the temporary UE capability restrictions, based on the one or more band lists. The processor is configured to generate a UE configuration based on the affected bands and restricted bands in the UE, via the CU, based on the identification.

[0019] In an 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 the instructions stored in the memory and thereby configured to receive temporary UE capability restrictions due to MUSIM operations, from a UE. The temporary UE capability restrictions indicate temporary radio frequency capabilities of bands in the one or more band lists configured in the UE. The processor is configured to transmit the temporary UE capability restrictions and one or more band lists to the DU of the network. The DU includes a processor configured to execute the instructions stored in the memory and thereby configured to receive the temporary UE capability restrictions and one or more band lists from the CU. The processor is configured to identify affected bands and restricted bands due to the MUSIM operations from the temporary UE capability restrictions, based on the one or more band lists. The processor is configured to generate a UE configuration based on the affected bands and restricted bands in the UE, via the CU, based on the identification.

[0020] According to one embodiment of the disclosure, a method of reporting UE capabilities for a Multi-Subscriber Identity Module (MUSIM) UE and a UE thereof are provided.

[0021] 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 numbers are used throughout the figures to reference features and components. Some embodiments of at least one of device and methods in accordance with embodiments of the present subject matter are now described, by way of example only, and with reference to the accompanying figures, in which:

[0022] Fig. 1 illustrates an environment in which some embodiments of the present disclosure may be practiced;

[0023] Fig. 2 illustrates a UE 104 for reporting UE capabilities, in accordance with an embodiment of the present disclosure;

[0024] Fig. 3 illustrates a sequence flow of a method 300 of reporting UE capabilities for a MUSIM UE, in accordance with an embodiment of the present disclosure;

[0025] Fig. 4 illustrates a sequence flow of a method 400 of configuring UE capabilities for the MUSIM UE, in accordance with an embodiment of the present disclosure;

[0026] Fig. 5 illustrates a method 500 of reporting UE capabilities for a MUSIM UE, in accordance with an embodiment of the present disclosure;

[0027] Fig. 6 illustrates a method 600 of configuring UE capabilities for a MUSIM UE, in accordance with an embodiment of the present disclosure;

[0028] Fig. 7 illustrates a block diagram of an exemplary computer system 700 for implementing embodiments consistent with the present disclosure.

[0029] Fig. 8 illustrates a flow diagram representing reporting interruption requirements, in accordance with some embodiments of the present disclosure;

[0030] Fig. 9 illustrates a flow diagram representing temporary capability restriction or interruption requirement update through UAI, in accordance with some embodiments of the present disclosure;

[0031] Fig. 10 illustrates a flow diagram representing handling of RRC Reestablishment withotherconfigfor MUSIM dual Rx / dual Tx operations, in accordance with some embodiments of the present disclosure;

[0032] Fig. 11 illustrates a flow diagram representing handling of RRC Resume andotherconfigfor MUSIM dual Rx / dual Tx operations in accordance with some embodiments of the present disclosure;

[0033] Fig. 12 depicts the process of handling expiry of the MUSIM wait timer, in accordance with an embodiment of the present disclosure;

[0034] Fig. 13 depicts the process of the UE reporting cell reselection measurements after temporary capability restrictions, in accordance with an embodiment of the present disclosure;

[0035] Fig. 14 depicts the process of reporting measurement gap requirements for LTM, in accordance with an embodiment of the present disclosure;

[0036] Fig. 15 illustrates a flow chart of Secondary Node (SN) operation (in DC) for MUSIM wait timer, in accordance with an embodiment of the present disclosure;

[0037] Fig. 16 illustrates a flow chart of Master Node (MN) operation (in DC) for MUSIM wait timer, in accordance with an embodiment of the present disclosure;

[0038] Fig. 17 illustrates a Control Unit (CU) operation for MUSIM wait timer, in accordance with an embodiment of the present disclosure;

[0039] Fig. 18 illustrates a Distributed Unit (DU) operation for MUSIM wait timer, in accordance with an embodiment of the present disclosure;

[0040] Fig. 19 illustrates a User Equipment (UE) operation for MUSIM wait timer, in accordance with an embodiment of the present disclosure;

[0041] Fig. 20 illustrates an environment in which some embodiments of the present disclosure may be practiced;

[0042] Fig. 21 illustrates a sequence flow of a method 2100 of configuring UE capabilities, in accordance with an embodiment of the present disclosure;

[0043] Fig. 22 illustrates a flow chart of a method 2200 of configuring UE capabilities, in accordance with an embodiment of the present disclosure;

[0044] Fig. 23 illustrates overall NG-RAN Architecture based on 3GPP specification TS 38.401, in accordance with existing arts;

[0045] Fig. 24 illustrates CU operation for temporary capability restriction, in accordance with an embodiment of the present disclosure; and

[0046] Fig, 25 illustrates DU operation for temporary capability restriction, in accordance with an embodiment of the present disclosure.

[0047] The figures depict embodiments of the disclosure for purposes of illustration only. One skilled in the art will readily recognize from the following description that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles of the disclosure described herein.

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

[0049] While the disclosure is susceptible to various modifications and alternative forms, specific embodiment thereof has been shown by way of example in the drawings and will be described in detail below. It should be understood, however that it is not intended to limit the disclosure to the particular forms disclosed, but on the contrary, the disclosure is to cover all modifications, equivalents, and alternative falling within the spirit and the scope of the disclosure.

[0050] The terms "comprises", "comprising", or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a setup, device or method that comprises a list of components or steps does not include only those components or steps but may include other components or steps not expressly listed or inherent to such setup or device or method. In other words, one or more elements in a device or system or apparatus proceeded by "comprises... a" does not, without more constraints, preclude the existence of other elements or additional elements in the device or system or apparatus.

[0051] In the following detailed description of the embodiments of the disclosure, reference is made to the accompanying drawings that form a part hereof, and in which are shown by way of illustration specific embodiments in which the disclosure may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the disclosure, and it is to be understood that other embodiments may be utilized and that changes may be made without departing from the scope of the present disclosure. The following description is, therefore, not to be taken in a limiting sense.

[0052] It may be noted that, for convenience of explanation, the disclosure uses terms and names defined in the 3rd Generation Partnership Project Radio Access Network (3GPP RAN) standards. More specifically, the terms gap requirements, measurement gap requirement, Network Controlled Small Gap (NCSG) requirement, interruption requirement and the like are to be interpreted as specified by the relevant 3GPP standards.

[0053] It may be noted that, for convenience of explanation, the disclosure uses terms and names defined in the 3rd Generation Partnership Project Radio Access Network (3GPP RAN) standards. More specifically, the terms 'musim-CapabilityRestriction', , 'RRC_IDLE', 'RRC_Inactive', 'RRC_CONNECTED', 'Secondary cell addition', 'handover', 'beam failure recovery', 'synchronous reconfiguration', 'Downlink (DL)', 'Uplink (UL)', 'Scheduling Request(SR)', 'RSRP', nr-NeedForGap-Reporting, nr-NeedForInterruptionReport and nr-NeedForGapNCSG-Reporting ,'to be interpreted as specified by the 3GPP RAN standards.

[0054] OVERVIEW

[0055] Multi-SIM devices and simultaneous RRC connection support:Multi-SIM (MUSIM) devices that host more than one Subscriber Identity Module (SIM) to have the facility to connect to two or more different Networks (NWs) in order to avail different data plans, have user profiles like home and office, increased connectivity / reliability with multiple connections etc. are becoming very popular. One or more of the multiple SIMs can be engaged in paging reception, System Information Block (SIB) acquisition, measurements, data or voice call, Multicast and Broadcast Service (MBS) reception, emergency call, Access Stratum (AS) signaling, Non-Access Stratum (NAS) signaling and so on. Some of these operations are periodic, for example, paging, and measurements and some are aperiodic and un-deterministic, for example, signaling. Further, duration required to complete the operation may also be fixed or unpredictable.

[0056] Depending upon the number of Rx (Reception) chains and Tx (Transmission) chains multi-SIM devices are classified into different types like Single Rx-Single Tx, Dual Rx-Single Tx, Dual Tx-Single Rx and Dual Rx-Dual Tx. A Rx or Tx chain includes the RF circuitries and associated hardware and software components for reception and transmission, respectively. A Dual Rx-Dual Tx device can normally support simultaneous RRC connections on its multiple subscriptions. These devices are also sometimes called Dual Stack-Dual Active (DSDA) devices. It may also be possible for Single Rx-Single Tx, Dual Rx-Single Tx, Dual Tx-Single Rx devices to support multiple simultaneous RRC connections through some methods for sharing their Rx and Tx chain and switching based on need.

[0057] RRC states: In Near Radio (NR), Radio Resource Control (RRC) is in one of the three states- RRC_IDLE, RRC_INACTIVE or RRC_CONNECTED. An RRC_CONNECTED UE is in Connection Management (CM)-CONNECTED (i.e., connected to 5G core network) and may do unicast and multicast / broadcast traffic with the network. The network stores the UE Access Stratum (AS) context, knows the UE at cell level and controls the UE mobility. The UE performs measurements and reports to the network to provide channel quality, feedback information, etc.

[0058] RRC_INACTIVE is a state where a UE remains in CM-CONNECTED and moves within an area configured by Next Generation Radio Access Network (NG-RAN) (5G RAN consisting of gNodeBs (gNB(s))) without notifying the NG-RAN. In RRC_INACTIVE, the last serving gNB node keeps the UE context and the UE-associated NG connection (i.e., the connection to the core network). Since the RRC configurations and the connection to the core network are kept in RRC_INACTIVE, UE transitions immediately to RRC connected state and performs data transfer with the core network or applications. UE initiates transition to RRC_CONNECTED from RRC_INACTIVE by sending RRC resume request.

[0059] In RRC_IDLE, UE or gNB does not store any AS context. UE is in CM_IDLE (i.e., there is no connection to core network). UE sets up a new connection by sending RRC setup request message and gNB sends RRC setup message to transition to RRC_CONNECTED. UE and NW (both the RAN and core network) exchange messages to move the UE to CM_CONNECTED.

[0060] UE Capabilities:In a technology like 5G NR, different UEs may have different hardware and software capabilities. Varying capabilities across devices could be hardware capabilities including radio frequency capabilities like bands or band combinations supported, processing capabilities (e.g., baseband computational capabilities), software capabilities like the support of various features, layer 1 capabilities, layer 2 capabilities, layer 3 capabilities and so on. In general, the UE reports its UE radio access capabilities which are static at least when the network requests the capabilities. To limit signaling overhead, the gNB requests the UE to provide NR capabilities for a restricted set of bands. When responding, the UE can skip a subset of the requested band combinations when the corresponding UE capabilities are the same. If supported by the UE and the network, the UE may provide an ID in NAS signaling that represents its radio capabilities for one or more Radio Access Technologies (RATs) in order to reduce signaling overhead. The ID may be assigned either by the manufacturer or by the serving Public Land Mobile Network (PLMN). The manufacturer-assigned ID corresponds to a pre-provisioned set of capabilities. In the case of the PLMN-assigned ID, assignment takes place in NAS signaling. Detailed list of UE capabilities that are exchanged based on aforementioned methods is specified in 3GPP technical specifications like TS 38.306. A gNB provides a UE with various configurations / features through RRC messages like RRC reconfiguration or RRC resume based on the reported UE capability. Further 5G gNB may comprise of central unit (CU) and distribution unit (DU).

[0061] In a MUSIM device which supports simultaneous RRC Connections on multiple USIMs, UE capabilities of the RRC_CONNECTED USIM in MUSIM device changes when other USIM(s) move from RRC_IDLE or RRC_INACTIVE to RRC_CONNECTED or vice versa, for example, the supported bands may change.

[0062] Measurement Gaps: In wireless technologies like NR and Long Term Evolution (LTE), a Radio Resource Control (RRC) connected UE performs various measurements for Radio Resource Management (RRM) purpose, positioning, etc. For RRM, UE measures the reference signals such as Synchronization Signal / PBCH block (SSB), Channel State Information Reference Signal (CSI-RS), etc. and reports the measurement results to the network.

[0063] According to the NR specification TS 38.300, measurements to be performed by a UE for connected mode mobility are classified in at least four measurement types that include intra-frequency NR measurements, inter-frequency NR measurements, inter-RAT measurements for E-UTRA and inter-RAT measurements for UTRA.

[0064] For each measurement type one or several measurement objects are defined, for example, carrier frequency to be monitored. For each measurement object one or several reporting configurations are defined (a reporting configuration defines the reporting criteria). Three reporting criteria are namely event triggered reporting, periodic reporting and event triggered periodic reporting are used. The association between a measurement object and a reporting configuration is created by a measurement identity (a measurement identity links together one measurement object and one reporting configuration of the same RAT). The measurement identity is used as well when reporting results of the measurements. For positioning, UE may report SSB / CSI-RS measurements and may also report measurements based on additional reference signals like PRS.

[0065] When the UE needs to measure inter frequency NR or inter-RAT measurements or intra frequency measurements outside the active downlink BWP when SSB is not completely contained in the active DL BWP, UE may use measurement gaps. Measurement gaps are configured by the network (for e.g., gNB in NR) and there is no transmission or reception during the gap period. Measurement gap configuration includes a gap offset, gap length, repetition period and measurement gap timing advance. Gap offset specifies the sub- frame where the start of measurement gap occurs. Gap length gives the duration of the gap while the repetition period defines how often the measurement gap occurs.

[0066] NeedForGaps: A NR UE reports NeedForGaps to indicate whether the UE needs gaps for measuring specific NR bands. In Release 17, NeedForGaps has been extended so that UE reports whether it needs gaps or Network Controlled Small Gaps (NCSG) for measuring specific NR bands. Starting from 3GPP Release 17, UE also indicates whether it needs gaps or NCSG for measuring E-UTRA bands.

[0067] The network configures UE to provide the measurement gap requirement information of NR target bands by setting needForGapsConfigNR to setup in RRC Reconfiguration or RRC Resume. In Release 17, the network configures UE to provide the measurement gap and NCSG requirement information of E-UTRA target bands by setting needForNCSG-ConfigEUTRA to setup in RRC Reconfiguration or RRC Resume. Similarly, in R17, the network configures UE to provide the measurement gap and NCSG requirement information of NR target bands by setting needForNCSG-ConfigNR to setup in RRC Reconfiguration or RRC Resume.

[0068] Once configured, UE keeps the configuration until released or modified and informs the network on the gap requirements for NR bands or gap and NCSG requirements for NR and E-UTRA bands. UE includes gap (or gap and NCSG) requirements in RRC Resume Complete and RRC Reconfiguration Complete. If the gap or gap and NCSG requirements change after a reconfiguration, UE reports the changed requirements in RRC Reconfiguration complete. UE reports a set of capabilities for informing the network that it supports needforgaps / needforgas and ncsg or need for interruption.

[0069] UE may also support measurements without gap with interruption for NR SSB-based inter-frequency and intra-frequency. To support this, 3GPP has introduced a set of changes in NR 18 specification.

[0070] <1> Introduce new indication (needForInterruptionInfoNR) for the Rel-18 case where interruption is needed for NR SSB based measurement without gap. The Rel-18 indication can be included in RRCReconfigurationComplete and RRCResumeComplete message.

[0071] <2> The Rel-18 indication is in addition to the legacy NeedForGapsInfoNR information. The UE may report 3 different cases as below:

[0072] If gap is needed, the UE reports "gap" in Rel-16 field and empty field in corresponding R18 IE.

[0073] If gap is NOT needed and there is no interruption, the UE reports "no gap" in Rel-16 field and "no-gap-no-interruption"in Rel-18 field

[0074] If gap is NOT needed but there is interruption, the UE reports "no-gap"in Rel-16 field and "no-gap-with-interruption" in Rel-18 field.

[0075] <3> The UE includes Rel-18 indication (needForInterruptionInfoNR) only if network requests it via a controlling flag (needForInterruptionConfigNR).

[0076] <4> Add UE capability to indicate whether the UE support reporting of interruption requirement in RRC response message.

[0077] Information reported as inneedForInterruptionInfoNRmay be referred to as interruption requirements. A set of example changes in TS 38.331 for the same is given below:

[0078]

[0079]

[0080]

[0081]

[0082]

[0083]

[0084]

[0085] Framework for supporting capability change: Let us consider the case of a MUSIM UE with two USIMs (i.e., two UEs in same MUSIM device), UE-A (USIM-A) and UE-B. The MUSIM UE supports dual transmission and reception, i.e., both the UE-A and UE-B are connected (RRC_CONNECTED) at the same time. Both the UE-A and UE-B may transmit or receive data at the same time. It is possible that the UE-A and UE-B may share some RF / radio / hardware / software resources. The UE capabilities (such as UE radio access capabilities as described in 3GPP specifications like TS 38.306) of UE-A may be different at different times depending on whether the UE-B is in connected (i.e., depending on whether the UE-B uses the RF / radio / hardware / software resources).

[0086] Consider that the UE-A is in RRC-CONNECTED state with NW-A. UE-B(USIM-B) is moving to RRC_CONNECTED or is in transitioning to RRC_CONNECTED. The UE-A provides the information to NW-A to release some resources or update some parameters for the MUSIM operations. This information is pertaining to the change of some of the capabilities in UE-A, release of SCG or SCells in the UE-A, deactivation of SCG or SCells in UE-A, information that SCG or SCells are setup or activated in UE-A, etc., measurement gaps requirements (needforgaps / needforgapsorncsg) related information in UE-A to facilitate MUSIM operations.

[0087] When the UE-A is in RRC_CONNECTED mode and the UE capability changes due to activities in the UE-B, UE-A informs NW-A about the capability change through an RRC message such as UE Assistance Information.

[0088] If the capability of the UE-A has changed due to UE-B's activities when the UE-A was in RRC_IDLE or RRC_INACTIVE mode, a similar approach as in RRC_CONNECTED is used. The UE-A may also indicate that the capability has changed in RRC setup request / RRC resume request, RRC setup complete or RRC resume complete. Capabilities may be retrieved later through UAI (UE Assistance Information) etc.

[0089] The UE-A may report that the capability has changed or may report the changed capabilities based on specific actions in the UE-B. When the UE-B is handed over from a licensed frequency to an unlicensed frequency or from one Frequency Range (FR) to another FR, UE-A may report the capability change to NW-A.

[0090] NW-A may configure the UE-A on whether it can inform changed capabilities, e.g., through "otherConfig" in the RRC Reconfiguration message. In other words, through "otherConfig" network may control whether the UE-A can update the changed capabilities. There may be a single enumerated or some other parameter that may be used to control inotherConfigwhich informs the UE-A to report the changed capabilities. Alternatively, each of these individual capabilities that may be changed may have separate flags inotherConfig. Accordingly, UE can report the updated or changed capabilities with UE assistance information message. The information contents in UAI may pertain to MUSIM assistance information or MUSIM UE capability information. A prohibit timer may be configured to control how frequently the UE can report the capability update. The capability update, for e.g., the scheduling pattern and / or TDD UL / DL config information pertaining to the UE-B as capability limitation (e.g., number of Tx / Rx) to UE-A are not static or fully prohibitive. So, UE can initiate UAI while prohibit timer is not running to handle such updates.

[0091] NW-A may configure the UE-A with a filter and the UE-A reports the change of capabilities based on the filter. For e.g., if a capability included in the filter changes, the UE-A may report the capability change. If none of the capabilities in the filter changes due to UE-B actions, the UE-A may not initiate the messages to indicate UE capability change. An example set of IEs that are included in the filter are requestedFreqBandsNR-MRDC, requestedCapabilityNR, eutra-nr-only flag, requestedCapabilityCommon, and UE-CapabilityRequestFilterNR.

[0092] If the bands supported by the changed capability is different from the older capability, NW-A may reconfigure UE-A to release one or more SCells, SCG or perform handover etc. NW-A may configure UE-A to report any available measurements when the capabilities are changed. Since the changed capability can be different from older capability, NW-A may prefer to change the SCells or SCG rather than releasing them, or in a case perform handover to a different frequency. Measurements from the UE can aid the network to take such decisions.

[0093] The static or dynamic capability signaling reported by UE may include number of Rx links, number of Tx links, maximum number of MIMO layers, support for CA or DC on NW B, processing capability in terms of supportable component carriers or dual connectivity on NW A, request for at least one of configuration, activation, deactivation and release of one or more SCell / SCG on NW A, supported band(s) or band combination(s), UL or DL TDD configuration, scheduling information or configuration, DRX configuration on NW B, measurement configuration on NW B, IDC related configuration or parameters, power control or back-off parameters, frequencies which are supported or the frequencies which are restricted, etc.

[0094] The network utilizes the updated capability received from the UE and reconfigures the UE with updated parameters. Network may update configuration of dual connectivity, carrier aggregation, power control, interference coordination, DAPS configuration, number of layers etc. based on the capability information including supported bands, supported band combination, scheduling pattern and / or TDD UL / DL config information etc.

[0095] Change of UE capabilities, as described can be the restriction in the UE capabilities and the removal of those restrictions. i.e., when it is said that capabilities are changed, it may mean some of the capabilities are restricted or some of the restrictions are removed. UE may report the supported capabilities (e.g., the bands that are supported or band combinations that are supported or the frequencies that are supported, measurement gap requirements after the restrictions are applied, maximum number of MIMO layers supported after the restriction) after the restriction in the UE capabilities for informing the restriction. Alternatively, UE may report the restricted capabilities (e.g., the bands that are not supported or band combinations that are not supported or the frequencies that are not supported). Reporting of changed capabilities or restricted capabilities may mean reporting the restricted capabilities and reporting the supported capabilities after restriction.

[0096] Reporting of changed capabilities or reporting of removal of restricted capabilities may mean reporting the supported capabilities after restriction is removed. The terms temporary capability change, temporary capability restriction etc. may be used to refer to the change of capabilities or restriction in capabilities as explained.

[0097] Reporting of changed capabilities for MUSIM operation or reporting of removal of restricted capabilities for MUSIM operation, temporary capability changes for MUSIM operation, temporary capability restriction for MUSIM operation etc. also may be used to refer to the change of capabilities or restriction in capabilities or removal of restriction in capabilities as explained when the change is for MUSIM operations.

[0098] Capabilities UE-A has, when UE-B is not in RRC_CONNECTED may be referred to as permanent UE capabilities of UE-A. i.e., Capabilities in UE-A when UE-B is in RRC_IDLE or RRC_INACTIVE may be referred to as temporary UE capabilities of UE-A. In other words, capabilities in UE-A when UE-B is not sharing the radio or software or RF or hardware or any other resources for dual Reception and transmission can be referred to as permanent UE capabilities of UE-A within a MUSIM context.

[0099] In the current system, permanent UE capabilities are reported using UE Capability Transfer procedure. gNB requests the UE to report the UE capabilities by sending UECapabilityEnquiry message and the UE reports the capabilities using UECapabilityInformation message. Different radio technologies like 6G may have messages with similar functionalities and the embodiments are equally applicable for them. The reported capabilities are sent to the core network and stored there so that every time the UE moves from RRC_IDLE or RRC_INACTIVE to RRC_CONNECTED, there is no need to send the capabilities over the air. UECapabilityEnquiry message may include a filter such as CapabilityRequestFilter, so that UE reports only the required information for the network.

[0100] A UE reporting temporary capability restrictions may send the list of restricted capabilities or the list of supported capabilities or the list of changed capabilities. UE may also inform the network that the restriction of capabilities due to MUSIM operations are removed once the restrictions are removed.

[0101] UE-A may report temporary capability restrictions proactively or reactively. In proactive approach UE-A may report the restriction in the capabilities irrespective of current RRC configuration of UE-A (i.e., from NW-A). For reactive approach, UE-A may report restriction on a subset of these capabilities to the NW-A at a time based on the current RRC configuration of UE-A.

[0102] v17.5.0 of 3GPP specifications such as TS 38.331, TS 38.300, TS 38.306, TS 38.321 are considered as the relevant background.

[0103] Further, consider a case when a MUSIM device with two USIMs, USIM-A (also known as UE-A) and USIM-B (also known as UE-B), where USIM-A (UE-A) is in RRC_CONNECTED or is moving to RRC_CONNECTED and USIM-B (UE-B) is in RRC_IDLE or RRC_INACTIVE, the device supports multiple RRC connections simultaneously, i.e., it is possible for both USIM-A (UE-A) and USIM-B (UE-B) to be in RRC_CONNECTED at the same time. If UE-B moves from RRC_IDLE or RRC_INACTIVE to RRC_CONNECTED or due to any other trigger in UE-B, interruption requirements of UE-A changes. There are no methods available currently for reporting the changes in interruption requirements to the network due to such MUSIM actions now. Further there needs to be a method by which UE-A informs NW-A of its capability for reporting such gap requirements or gap and interruption requirements.

[0104] The present subject matter proposes methods by which a User Equipment UE-A reports that it is capable for reporting temporary capability restrictions to a network NW-A. Further, the subject matter proposes methods by which the network NW-A configures the UE-A for reporting temporary capability restrictions.

[0105] In various embodiments, the present subject matter proposes methods by which UE-A handles the configuration of temporary capability restrictions during various events such as RRC re-establishment or transition to RRC_INACTIVE.

[0106] The present subject matter describesmethods and systems for the operation of a Dual Rx / Dual Tx Multi-Subscriber Identity Module (MUSIM) User Equipment (UE) in a 5thGeneration (5G) network (NW). Network in this present subject matter mainly means NG-RAN though the core network is not excluded for some of the functionalities.

[0107] For instance, two USIMs, USIM-A or UE-A (technically the radio protocol stack associated with USIM-A) and USIM-B or UE-B (technically the radio protocol stack associated with USIM-B) and their corresponding networks, Network-A (NW-A) and Network-B (NW-B) are considered. Further, UE-A is assumed to be in RRC_CONNECTED mode with NW-A and UE-B is assumed to be in RRC_IDLE or RRC_INACTIVE. Fig. 8 illustrates a flow diagram representing reporting interruption requirements.

[0108] Fig. 9 illustrates a flow diagram representing UE capabilities for temporary capability restrictions and configuration of temporary capability restrictions. In one non-limiting embodiment, the UE-A may communicate to the NW-A that it is capable of reporting the temporary capability restrictions (or the removal of temporary capability restrictions) proactively, i.e., independent of its current RRC configuration (i.e., configured by NW-A). This may be communicated using RRC message UECapabilityInformation in NR. This may be a per-UE capability without any FDD-TDD difference.

[0109] In one non-limiting embodiment, the UE-A may communicate to the NW-A that it is capable of reporting the temporary capability restrictions (or the removal of temporary capability restrictions) reactively, based on its current RRC configuration (i.e., configured by NW-A). This may be communicated using RRC message UECapabilityInformation in NR. This may be a per-UE capability without any FDD-TDD difference.

[0110] In one non-limiting embodiment, UE-A may report the temporary capability restrictions proactively if it is configured by NW-A to do so, for example, throughRRC IE otherConfig, NW-A may configure UE-A to report the temporary capability restrictions or the removal of temporary capability restrictions without considering UE-A's RRC configuration.

[0111] In one non-limiting embodiment, UE-A may report the temporary capability restrictions reactively if it is configured by NW-A to do so, for example, throughRRC IE otherConfig. NW-A may configure UE-A to report the temporary capability restrictions or the removal of temporary capability restrictions based on UE-A's RRC configuration.

[0112] In one non-limiting embodiment, UE-A may report the temporary capability restrictions reactively and may not report temporary capability restrictions proactively if it is configured for both reactive and proactive reporting.

[0113] In one non-limiting embodiment, UE-A may report the temporary capability restrictions proactively and may not report temporary capability restrictions reactively if it is configured for both reactive and proactive reporting. In an embodiment, if UE-A is configured for both reactive and proactive reporting, it will report measurement gap requirements / power related requirements / SRS TX switching related requirements reactively and band / frequency / band combination / maximum MIMO layers proactively.

[0114] In one non-limiting embodiment, once the temporary capability restrictions are removed, UE-A may report the removal of temporary capability restrictions if it is configured for reporting of temporary capability restrictions (or the removal of temporary capability restrictions) either proactively or reactively.

[0115] In one non-limiting embodiment, once the temporary capability restrictions are removed, UE-A may report the removal of temporary capability restrictions if it has already reported the temporary capability restriction to NW-A and if it is configured for reporting of temporary capability restrictions (or the removal of temporary capability restrictions).

[0116] In one non-limiting embodiment, UE-A may report the removal of temporary capability restrictions as a single flag or an enumerated or a single bit of information which informs the NW-A that temporary capability restriction is removed, and the UE is capable of the capabilities previously reported usingUECapabilityInformation. In another embodiment this may mean the UE is capable of permanent UE capabilities.

[0117] In one non-limiting embodiment, the UE-A may report the removal of temporary capability restrictions if it is configured by the NW-A to report the temporary capability restrictions. In one non-limiting embodiment, UE-A reports the removal of temporary capability restrictions if it is configured by the network to report the removal of temporary capability restrictions. For example, if UE-A has moved to a new cell by NW-A through a handover or reestablishment or LTM and the new cell has not configuredotherConfig, UE-A may not report the removal of temporary capability restrictions.

[0118] In one non-limiting embodiment, in a MUSIM device that supports multiple simultaneous RRC Connections, when one USIM (for e.g. USIM-A / UE-A) is in RRC_CONNECTED and the interruption requirements have changed due to MUSIM operations (i.e. actions in UE-B), UE-A may report the change in interruption requirements to its network (NW-A) if it is configured to do so. In an embodiment, UE-A may inform the NW-A that there is a change in interruption requirements using UE Assistance Information (UAI). In an embodiment, UE-A may inform that there is a change in interruption requirements using a single bit of information or an enumerated or a flag or any such information which informs NW-A that there is a change in interruption requirements. In another embodiment, UE-A may inform that there is a change in gap requirements or NCSG requirements or interruption requirements using a single bit of information or a enumerated or a flag or any such information which informs NW-A that there is a change in gap requirements or NCSG requirements or interruption requirements, if there is a change in any of these requirements. In an embodiment, UE-A may inform NW-A of the actual change in the interruption requirements.

[0119] In one non-limiting embodiment, UE-A includes the (updated) interruption requirements in UE Assistance Information message or any other RRC message which is sent by the USIM-A to NW-A, to indicate that its capabilities and interruption requirements have changed, due to MUSIM operations like transition in other UE, from RRC_IDLE or RRC_INACTIVE to RRC_CONNECTED or from RRC_CONNECTED to RRC_IDLE or RRC_INACTIVE.

[0120] In one non-limiting embodiment the UE-A reports (updated) interruption requirements or the information that interruption requirements have changed due to MUSIM actions only if the interruption requirements have changed from the last time the interruption requirements have been reported for MUSIM operations or any other purpose.

[0121] In one non-limiting additional embodiment, UE-A reports the interruption requirements to NW-A due to MUSIM operations even if the interruption requirements have not changed from the last time the interruption requirements have been reported by UE-A to NW-A, when new bands are supported by UE-A due to MUSIM operations or other purposes when existing bands are not supported by UE-A, due to MUSIM operations or other purposes.

[0122] If the UE has been configured with a band filter for reporting interruption requirements (for example,requestedTargetBandFilterNRas in current NR specification), UE reports the interruption requirements for the bands included in the band filter. This means UE reports interruption requirements in UAI only for the bands inrequestedTargetBandFilterNRifrequestedTargetBandFilterNRis configured and interruption requirements in UAI for E-UTRA bands only for the bands in requestedTargetBandFilterNCSG-EUTRA if requestedTargetBandFilterNCSG-EUTRA is configured.

[0123] In one non-limiting embodiment, when the band capability has been changed in UE-A due to MUSIM operations and the band filter has been configured in UE-A, UE-A reports interruption requirements only for the bands supported by UE-A after capability change due to MUSIM operation and is present in band filter. This means, USIM-A reports the interruption requirements for the subset of bands inrequestedTargetBandFilterNRorrequestedTargetBandFilterNCSGorrequestedTargetBandFilterNCSG-EUTRAand the reduced capability of USIM-A due to UE-B's transition. In other words if any of the configuredrequestedTargetBandFilterNRorrequestedTargetBandFilterNCSGorrequestedTargetBandFilterNCSG-EUTRAcontains the bands which are not supported by UE-A after the change in RF capabilities at UE-A due to the transition of UE-B from RRC_IDLE or RRC_INACTIVE to RRC_CONNECTED or other actions, UE-A doesn't report the interruption requirements for those bands.

[0124] If the band filter is not configured at UE-A, UE-A reports the interruption requirements for all the bands that are supported after change in capabilities due to actions in UE-B like the transition in RRC States in UE-B.

[0125] In an alternate embodiment, UE-A may report the interruption requirements for all the bands, or all the bands included in the band filter that are supported before the capability change due to the MUSIM operations such as transition of UE -B from RRC_IDLE or RRC_INACTIVE to RRC_CONNECTED.

[0126] In one non-limiting embodiment, UE-A may report the interruption requirements to NW-A as mentioned in above embodiments before executing the transition of UE-B from RRC_IDLE or RRC_INACTIVE to RRC_CONNECTED or from RRC_INACTIVE or RRC_IDLE to RRC_CONNECTED. i.e., UE sends interruption requirements to NW-A and thus waits for a RRC Reconfiguration before performing transition in USIM-B.

[0127] Alternatively, UE-A may report interruption requirements as mentioned in above embodiments after executing the transition of USIM-B from RRC_IDLE or RRC_INACTIVE to RRC_CONNECTED or from RRC_INACTIVE or RRC_IDLE to RRC_CONNECTED. The change in interruption requirements in UE-A due to MUSIM operations may be informed to NW-A in RRCReconfigurationComplete message or RRCResumeComplete message. In this case UE-A defers any measurements which require gaps as per the changed gap requirements due to MUSIM operations till the RRCReconfigurationComplete message or RRCResumeComplete message are send. UE-A may inform the NW-A in the UAI message that the interruption requirements are changed, and the NW-A may trigger RRCReconfiguration message, and the UE-A may report the changed interruption requirements in RRCReconfigurationComplete message.

[0128] In one non limiting embodiment, NW-A may inform UE-A whether to send interruption requirements when MUSIM capability changes. Network then informs the UE-A whether the UE needs to send updated capability information (changed capabilities like physical layer capabilities, layer2 capabilities, band capabilities and all other capabilities that may be changed due to other USIM changes RRC State). The information may be sent usingotherConfigfor example, using another config IE like MUSIMCapabilityChangeUpdateConfig.

[0129] In one non-limiting embodiment, NW-A informs UE-A whether to send interruption requirements through an RRC message. This could be done in a way by sending an indication inMUSIMCapabilityChangeUpdateConfig. UE sends interruption requirements only if it receivesMUSIMCapabilityChangeUpdateConfig.

[0130] In another embodiment, UE-A sends interruption requirements if it receives the indication to send an updated capability (for e.g., as inMUSIMCapabilityChangeUpdateConfig). In an additional embodiment, UE-A may send interruption requirements or gap and NCSG requirements to NW-A if it receivesMUSIMCapabilityChangeUpdateConfigand one or more ofNeedForGapsInfoNRorNeedForNCSG-InfoNRorNeedForNCSG-InfoEUTRAor needForInterruptionConfigNR from NW-A.

[0131] In an additional embodiment, UE-A may report the interruption requirements when UE-B is configured or released with carrier aggregation or dual connectivity or any such actions in UE-B which may change the interruption requirements. The actions may include removal or addition of second SIM, DSDS / DSDA mode of operation activation or deactivation, mobility across Rel17 and Rel18 cell / network etc.

[0132] In an additional embodiment, UE-A might be configured with a timer which prevents the UE-A to report the change of capabilities or change in interruption requirement to NW-A due to MUSIM operations. The timer starts once UE-A sends the change of capabilities or change in interruption requirements is send to NW-A. UE-A does not report any change of capabilities or change in interruption requirement to NW-A till the timer is stopped or expired. The timer may be restarted if UE-A receives a different configuration (including a different timer value or even other configuration). Additionally, there could be different timers for reporting detailed capability change based on UE-B actions. Timer for detailed reporting may be started when change of capabilities or change in interruption requirements is sent and may be stopped when a different configuration is received.

[0133] In an additional embodiment, NW-A informs UE-A whether to report the change of capabilities or change in interruption requirements separately when the capabilities has increased or capabilities has decreased due to the actions in USIM-B.

[0134] In one non-limiting embodiment, source gNB transfers the interruption requirements received in the UAI due to MUSIM operations to the target gNB during handover.

[0135] In various embodiments, the present subject matter discloses UE Capability for reporting gaps, NCSG and interruption requirements. In one non limiting embodiment, UE-A informs NW-A whether it supports reporting of the NCSG and measurement gap requirement information for SSB based measurement in the UAI. In an embodiment UE-A reports this information if it is capable of reporting temporary capability restrictions / removal of temporary capability restrictions for MUSIM operations. In an embodiment, this may be reported using legacy NR IE, nr-NeedForGapNCSG-Reporting-r17. In an embodiment, this may be reported using a new IE which is an optional per-UE capability without FDD-TDD or FR1-FR2 differentiation.

[0136] An example specification extract from TS 38.306 according to above embodiments is given below in Table 1. An alternative specification extract is provided in Table 2

[0137] Table 1: An example specification extract from TS 38.306

[0138] [Table 1]

[0139]

[0140] In an embodiment, UE-A is capable of reporting of the NCSG and measurement gap requirement information for SSB based measurement in the UAI when it is capable ofnr-NeedForGapNCSG-Reporting-r17and also is capable of reporting temporary capability restrictions / removal of temporary capability restrictions for MUSIM operations. In an embodiment, NW-A configures UE-A for reporting of the NCSG and measurement gap requirement information for SSB based measurement in the UAI when it is informed that UE-A is capable ofnr-NeedForGapNCSG-Reporting-r17and also is informed that UE-A is capable of reporting temporary capability restrictions / removal of temporary capability restrictions for MUSIM operations. In an embodiment, UE-A reports the NCSG and measurement gap requirement information for SSB based measurement in the UAI when it is capable ofnr-NeedForGapNCSG-Reporting-r17and also is capable of reporting temporary capability restrictions / removal of temporary capability restrictions for MUSIM operations.

[0141] Table 2: An example specification extract from TS 38.306

[0142] [Table 2]

[0143]

[0144] In an embodiment, UE-A is capable of indicating that there is a change in the NCSG and measurement gap requirement information for SSB based measurement in the UAI message when it is capable ofnr-NeedForGapNCSG-Reporting-r17and also is capable of reporting temporary capability restrictions / removal of temporary capability restrictions for MUSIM operations. In an embodiment, NW-A configures UE-A for indicating that there is a change in the NCSG and measurement gap requirement information for SSB based measurement in the UAI message when it is informed that UE-A is capable ofnr-NeedForGapNCSG-Reporting-r17and also is informed that UE-A is capable of reporting temporary capability restrictions / removal of temporary capability restrictions for MUSIM operations. In an embodiment, UE-A reports that there is a change in the NCSG and measurement gap requirement information for SSB based measurement in the UAI message when it is capable ofnr-NeedForGapNCSG-Reporting-r17and also is capable of reporting temporary capability restrictions / removal of temporary capability restrictions for MUSIM operations.

[0145] In one non-limiting embodiment, UE-A informs NW-A whether it supports reporting of the measurement gap requirement information for NR target in the UAI. In an embodiment, UE-A reports this information if it is capable of reporting temporary capability restrictions / removal of temporary capability restrictions for MUSIM operations. In an embodiment, this may be reported using legacy NR IE, nr-NeedForGap-Reporting-r16. In an embodiment, this may be reported using a new IE which is an optional per-UE capability without FDD-TDD or FR1-FR2 differentiation.

[0146] In one non-limiting embodiment, UE-A may inform NW-A whether it supports reporting that the measurement gap requirement information for NR target has changed, in the UAI. In an embodiment UE-A reports this information if it is capable of reporting temporary capability restrictions / removal of temporary capability restrictions for MUSIM operations. In an embodiment, this may be reported using legacy NR IE, nr- nr-NeedForGap-Reporting-r16. In an embodiment, this may be reported using a new IE which is an optional per-UE capability without FDD-TDD or FR1-FR2 differentiation. An example specification extract as per above embodiments from TS 38.306 is given in Table. 3. An alternative specification extract is provided in Table. 4.

[0147] Table. 3: An example specification extract from TS 38.306

[0148] [Table 3]

[0149]

[0150] In an embodiment, UE-A is capable of reporting the measurement gap requirement information for NR target in the UAI message when it is capable ofnr-NeedForGap-Reporting-r16and also is capable of reporting temporary capability restrictions / removal of temporary capability restrictions for MUSIM operations. In an embodiment, NW-A configures UE-A for reporting the measurement gap requirement information for NR target in the UAI message when it is informed that UE-A is capable ofnr-NeedForGap-Reporting-r16and also is informed that UE-A is capable of reporting temporary capability restrictions / removal of temporary capability restrictions for MUSIM operations. In an embodiment, UE-A reports the measurement gap requirement information for NR target in the UAI message when it is capable ofnr-NeedForGap-Reporting-r16and also is capable of reporting temporary capability restrictions / removal of temporary capability restrictions for MUSIM operations.

[0151] Table. 4: An alternative specification extract.

[0152] [Table 4]

[0153]

[0154] In an embodiment, UE-A is capable of indicating that there is a change in the measurement gap requirement information for NR target in the UAI message when it is capable of nr-NeedForGap-Reporting-r16 and also is capable of reporting temporary capability restrictions / removal of temporary capability restrictions for MUSIM operations. In an embodiment, NW-A configures UE-A for indicating that there is a change in the measurement gap requirement information for NR target in the UAI message when it is informed that UE-A is capable of nr-NeedForGap-Reporting-r16 and also is informed that UE-A is capable of reporting temporary capability restrictions / removal of temporary capability restrictions for MUSIM operations. In an embodiment, UE-A indicates that there is a change in the measurement gap requirement information for NR target in the UAI message when it is capable of nr-NeedForGap-Reporting-r16 and also is capable of reporting temporary capability restrictions / removal of temporary capability restrictions for MUSIM operations.

[0155] In one non-limiting embodiment, UE-A informs NW-A whether it supports reporting the interruption requirement information for measuring NR target without gap in the UAI message. In an embodiment, UE-A reports this information if it is capable of reporting temporary capability restrictions / removal of temporary capability restrictions for MUSIM operations. In an embodiment, this may be reported using IE such as nr-NeedForInterruptionReport-r18 as indicated in background. In an embodiment, this may be reported using a new IE which is an optional per-UE capability without FDD-TDD or FR1-FR2 differentiation.

[0156] In one non-limiting embodiment, UE-A informs NW-A whether it supports reporting the interruption requirement information for measuring NR target has changed in the UAI message. In an embodiment UE-A reports this information if it is capable of reporting temporary capability restrictions / removal of temporary capability restrictions for MUSIM operations. In an embodiment, this may be reported using IE such as nr-NeedForInterruptionReport-r18 as indicated in background. In an embodiment, this may be reported using a new IE which is an optional per-UE capability without FDD-TDD or FR1-FR2 differentiation. An example specification extract as per above embodiments from TS 38.306 is given in Table 5. An alternate specification extract is given in Table. 6.

[0157] Table. 5: An example specification extract from TS 38.306.

[0158] [Table 5]

[0159]

[0160] In an embodiment, UE-A is capable of reporting the interruption requirement information for measuring NR target without gap in UAI message when it is capable of nr-NeedForInterruptionReport-r18 and also is capable of reporting temporary capability restrictions / removal of temporary capability restrictions for MUSIM operations. In an embodiment, NW-A configures UE-A for reporting the interruption requirement information for measuring NR target without gap in UAI message when it is informed that UE-A is capable of nr-NeedForInterruptionReport-r18 and also is informed that UE-A is capable of reporting temporary capability restrictions / removal of temporary capability restrictions for MUSIM operations. In an embodiment, UE-A reports the interruption requirement information for measuring NR target without gap in UAI message when it is capable of nr-NeedForInterruptionReport-r18 and also is capable of reporting temporary capability restrictions / removal of temporary capability restrictions for MUSIM operations.

[0161] Table. 6: An alternative specification extract.

[0162] [Table 6]

[0163]

[0164] In an embodiment, UE-A is capable of indicating that the interruption requirement information for measuring NR target without gap is changed in UAI message when it is capable of nr-NeedForInterruptionReport-r18 and also is capable of reporting temporary capability restrictions / removal of temporary capability restrictions for MUSIM operations. In an embodiment, NW-A configures UE-A for indicating that the interruption requirement information for measuring NR target without gap is changed in UAI message when it is informed that UE-A is capable of nr-NeedForInterruptionReport-r18 and also is informed that UE-A is capable of reporting temporary capability restrictions / removal of temporary capability restrictions for MUSIM operations. In an embodiment, UE-A indicates that the interruption requirement information for measuring NR target without gap is changed in UAI message when it is capable of nr-NeedForInterruptionReport-r18 and also is capable of reporting temporary capability restrictions / removal of temporary capability restrictions for MUSIM operations.

[0165] Fig. 10 illustrates handling of configuration for reporting temporary capability restrictions during RRCReestablishment or RRCResume.

[0166] In one non-limiting embodiment, UE-A releases the configuration(s) for reporting the temporary capability restrictions during RRC Reestablishment. In an embodiment, upon initiating RRC Reestablishment, UE-A releases the configuration(s) for reporting the temporary capability restriction such as the configuration(s) received inotherconfig. This configuration(s) may be a single configuration received inotherConfigfor reporting all the temporary capability restrictions due to MUSIM operation or different configurations in otherconfig received for reporting the temporary capability restrictions for different capabilities due to MUSIM operation. Example changes based on 3gpp TS 38.331 section 5.3.7.2 is given in Table 7.

[0167] [Table 7]

[0168]

[0169] Fig. 11 illustrates handling of RRC Resume and otherconfig for MUSIM dual Rx / dual Tx operations. In one non-limiting embodiment, upon initiating RRC Resume, UE releases the configuration(s) for reporting the temporary capability restrictions. In an embodiment, during RRC Resume procedure, UE releases the configuration(s) for reporting the temporary capability restrictions such as the configuration received in otherconfig. The configuration(s) may be a single configuration received in OtherConfig for reporting all the temporary capability restrictions due to MUSIM operation or different configurations received in otherconfig for reporting the temporary capability restrictions for different capabilities due to MUSIM operation. Example changes based on 3gpp TS 38.331 section 5.3.13.2 are given in Table 8.

[0170] [Table 8]

[0171]

[0172] The present subject matter describesmethods and systems for the operation of a Dual Rx / Dual Tx Multi-Subscriber Identity Module (MUSIM) User Equipment (UE) in a 5th Generation (5G) network (NW). The subject matter includes methods by which a user equipment (UE-A) reports that it is capable of reporting temporary capability restrictions to a network (NW-A). Further, the subject matter proposes methods by which the network NW-A configures the UE-A for reporting temporary capability restrictions. Further, the present subject matter proposes methods by which UE-A handles the configuration of temporary capability restrictions during various events such as RRC reestablishment or transition to RRC_INACTIVE.

[0173] Due to the popularity of Multi-SIM (MUSIM) devices that host more than one Subscriber Identity Modules (SIMs) to have the facility to connect to two or more different NWs to avail different data plans, have user profiles like home and office, increased connectivity / reliability with multiple connections etc. MUSIM UEs were operating without network control by creating arbitrary gaps till 3gpp decided to introduce support for MUSIM device operations in Release 17. From Release 17, a connected USIM (USIM, as referred to herein, means a radio protocol stack associated with the UE) in the MUSIM device can notify the connected mode network on network switching for multi-SIM operations. There are two types of networks switching that are supported. In first type of network switching, the connected USIM leaves the connected network and completely switches to the other USIM, i.e. other USIM becomes connected. In a second type of network switching, the connected USIM requests for a gap from its network for the MUSIM operations like listening for paging or performing measurements in the idle USIM.

[0174] In release 17, the MUSIM UE uses RRC UE Assistance Information (UAI) procedure to request for gaps or to notify about leaving. The network (gNB) configures the UE as to whether it can provide assistance information for MUSIM gaps or MUSIM Leave using otherConfig in RRC messages. The Musim-GapAssistanceConfig in otherConfig is used for informing the UE whether it can provide MUSIM assistance information for providing gap information. In release 17, only per-UE gaps are supported for MUSIM operations.

[0175] In a technology like 5G NR, different UEs may have different hardware and software capabilities. Varying capabilities across devices could be hardware capabilities including radio frequency capabilities like bands or band combinations supported, processing capabilities (e.g., baseband computational capabilities), software capabilities like the support of various features, layer 1 capabilities, layer 2 capabilities, layer 3 capabilities and so on. In general, the UE reports its UE radio access capabilities which are static at least when the network requests the capabilities. To limit signaling overhead, the gNB (5G NR base station) can request the UE to provide NR capabilities for a restricted set of bands. When responding, the UE can skip a subset of the requested band combinations when the corresponding UE capabilities are the same.

[0176] A 5G gNB provides a UE with various configurations / features through RRC messages like RRC reconfiguration or RRC resume based on the reported UE capability. Further, the 5G gNB may comprise of CU and DU. Lower layer triggered mobility:

[0177] 3gpp release 18 is considering Lower Layers (L1 / L2 layers) Triggered Mobility, also known as LTM to solve the problem related to latency, signaling overhead etc. associated with layer 3 mobility. As per 3gpp, the goal of LTM is to enable a serving cell to change via L1 / L2 signaling, to reduce the latency, overhead and interruption time. Network (gNB) may configure the UE with multiple candidate cells to allow fast application of configurations for candidate cells. The network may further send MAC CE or L1 signaling to dynamically switch the UE from a source cell to one of the configured candidate cells. Further, LTM can be triggered based on L1 measurements rather than L3 measurements.

[0178] LTM is supported for both intra-frequency and inter-frequency. For inter-frequency LTM measurements may require measurement gaps

[0179] [Table 9]

[0180]

[0181]

[0182]

[0183]

[0184]

[0185]

[0186] v18.0.0 and v18.1.0 of 3gpp specifications such as TS 38.331,TS 38.300,TS 38.306,TS 38.321 as the relevant background.

[0187] Hence, there is a need in the art for solutions which will overcome the above mentioned drawback(s), among others.

[0188] The principal object of embodiments herein is to disclose methods and systems for measuring and handling gaps in NR.

[0189] Another object of embodiments herein is to disclose methods and systems for a User Equipment (UE) to indicate its capabilities for reporting measurement gap requirements, measurement gap and NCSG requirements and NeedForInterruption requirements in UAI.

[0190] Another object of embodiments herein is to disclose methods and systems for the UE to report "cell reselection measurements" if there is temporary capability restriction on some frequencies.

[0191] Another object of embodiments herein is to disclose methods and systems for the UE to handle the measurement gaps and measurement objects if the UE releases serving cell which is part of the configuration due to wait timer expiry.

[0192] Another object of embodiments herein is to disclose methods and systems for the UE to indicate the relation between LTM measurements without a gap and the L3 measurements without the gap.

[0193] These and other aspects of the embodiments herein will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings. It should be understood, however, that the following descriptions, while indicating at least one embodiment and numerous specific details thereof, are given by way of illustration and not of limitation. Many changes and modifications may be made within the scope of the embodiments herein without departing from the spirit thereof, and the embodiments herein include all such modifications.

[0194] Consider the case of a MUSIM UE with two USIMs (i.e., two UEs in the same MUSIM device), UE-A and UE-B. The UE-A informs its network NW-A of temporary capability restrictions for the MUSIM operations.

[0195] In an embodiment herein, the UE indicates to the network if it is capable of reporting measurement gap requirements to the network in UAI (as specified in TS 38.331). In an embodiment herein, the UE sends this indication if it supports nr-NeedForGap-Reporting-r16. In an embodiment herein, this may be sent in a new capability. In an embodiment herein, this indication may be sent in the capability musim-CapabilityRestriction-r18.

[0196] In an embodiment herein, the UE indicates to the network if it is capable of reporting of the NCSG and measurement gap requirement information for SSB based measurement to the network in UAI (as specified in TS 38.331). In an embodiment herein, the UE sends this indication if it supports nr-NeedForGapNCSG-Reporting-r17. In an embodiment herein, this may be sent in a new capability. In an embodiment herein, this indication may be sent in the capability musim-CapabilityRestriction-r18.

[0197] In an embodiment herein, the UE indicates to the network if it is capable of reporting of the reporting the interruption requirement information for SSB based measurement towards NR target without a gap in UAI (as specified in TS 38.331). In an embodiment herein, the UE sends this indication if it supports nr-NeedForGapNCSG-Reporting-r17. In an embodiment herein, this may be sent in a new capability. In an embodiment herein, this indication may be sent in the capability musim-CapabilityRestriction-r18.

[0198] In an embodiment herein, according to TS 38.306,

[0199] [Table 10]

[0200]

[0201] In an embodiment herein, a MUSIM UE having temporary capability restrictions indicates that reselection measurements are available only if at least one frequency listed in measReselectionCarrierListNR in VarMeasReselectionConfig is supported by the UE according to the current temporary capability restrictions. In NR, this applies to RRCSetupComplete,RRCResumeComplete,RRCReconfigurationComplete and other RRC messages where this indication is sent.

[0202] In an embodiment herein, a MUSIM UE having temporary capability restrictions includes the cell reselection measurements (such as measResultReselectionNR) only for the frequencies listed in measReselectionCarrierListNR in VarMeasReselectionConfig supported by the UE according to the current temporary capability restrictions. In NR, this applies to RRCResumeComplete,UEInformationResponse and other RRC messages where this information is sent.

[0203] In an embodiment herein, according to TS 38.331.

[0204] [Table 11]

[0205]

[0206]

[0207] In an embodiment herein, if the UE autonomously releases SCG or serving cell upon MUSIM wait timer (such as NR timer T348) expiry, UE releases any measurement object or measurement gap configuration referring to the released serving cell. For e.g., if the released serving cell is included in or indicated by refServCellIndex, deriveSSB-IndexFromCellInter or refServCellIndicator, UE releases the corresponding measurement configuration such as measurement object configuration or measurement gap configuration. The network may further add the configurations if required.

[0208] [Table 12]

[0209]

[0210]

[0211] In an embodiment herein, if the UE autonomously releases SCG or serving cell upon MUSIM wait timer expiry, the UE keeps the measurement object and measurement gaps which refers to the released serving cell, but does not perform measurements using those measurement objects or measurement gaps till the network reconfigures them. For e.g., if the released serving cell is included in or indicated by refServCellIndex, deriveSSB-IndexFromCellInter or refServCellIndicator, the UE keeps the corresponding measurement configuration such as measurement object configuration or measurement gap configuration but avoids performing any measurements using them.

[0212] In an embodiment herein, if the UE autonomously releases SCG or serving cell upon MUSIM wait timer expiry, the UE keeps the measurement object and measurement gaps which refers to the released serving cell, and performs measurements using those measurement objects or measurement gaps by considering one of the serving cells such as PCell or PSCell as a default cell till the network reconfigures them. For e.g., if the released serving cell is included in or indicated by refServCellIndex, deriveSSB-IndexFromCellInter or refServCellIndicator, the UE keeps the corresponding measurement configuration such as measurement object configuration or measurement gap configuration but avoids performing any measurements using them.

[0213] In an embodiment herein, a UE which reports that it is capable of performing SSB based inter-frequency L1-RSRP measurements without measurement gaps (without interruption on serving cell(s)) for LTM (such as in capability 39-2 in the background), also informs that it is capable of performing SSB based inter-frequency L1-RSRP measurements without measurement gap. In NR, the UE which reports that that it is capable of performing SSB based inter-frequency L1-RSRP measurements without measurement gaps (without interruption on serving cell(s)) for LTM (such as in capability 39-2 in the background), also supports interFrequencyMeas-NoGap-r16 given below. interFrequencyMeas-NoGap-r16:

[0214] The interFrequencyMeas-NoGap-r16 indicates whether the UE can perform inter-frequency SSB based measurements without measurement gaps if the SSB is completely contained in the active BWP of the UE as specified in TS 38.133. If this parameter is indicated for FR1 and FR2 differently, each indication corresponds to the frequency range of cells to be measured.

[0215] If the capability of performing SSB based inter-frequency L1-RSRP measurements without measurement gaps (without interruption on serving cell(s)) for LTM (such as in capability 39-2 in the background) is indicated per band combination, and interFrequencyMeas-NoGap-r16 Is indicated separately for FR1 and FR2, the UE also indicates the support of interFrequencyMeas-NoGap-r16 for all the FRs corresponding to all band combination the capability such as 39-2 is reported.

[0216] In an embedment, a UE, which indicates the capability such as 39-2, also indicates that it supports intra-frequency L3 measurements without measurement gaps. In an embodiment herein, the UE in NR may indicate support of bwpOperationMeasWithoutInterrupt-r18 in this case. In an embodiment herein, the UE in NR may indicate support of bwpOperationMeasWithoutInterrupt-r18 in this case.

[0217] In an embedment, a UE, which indicates the capability such as 39-3-1, also indicates that it supports intra-frequency L3 measurements without measurement gaps.

[0218] Fig. 12 depicts the process of handling expiry of the MUSIM wait timer. Temporary capability restriction(s) for MUSIM operations are sent to the network including a request to release serving cells. Consider that the MUSIM wait timer has expired. The serving cell is released, but the measurement objects and measurement gap referring to the serving cell are retained.

[0219] Fig. 13 depicts the process of the UE reporting cell reselection measurements after temporary capability restrictions. Some bands may be unavailable due to temporary capability restrictions while configured for cell reselection measurements. The availability indication and measurements for cell reselection measurements are reported based on bands available in the restricted capability.

[0220] Fig. 14 depicts the process of reporting measurement gap requirements for LTM. On receiving a UE capability enquiry, a check is made 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 capability for supporting LTM measurements without gaps. If the UE does not support interFrequencyMeas-NoGap-r16, the capability bit is set from 39-2 to 0.

[0221] The embodiments disclosed herein can be implemented through at least one software program running on at least one hardware device and performing network management functions to control the network elements. The elements include blocks which can be at least one of a hardware device, or a combination of hardware device and software module.

[0222] The embodiments disclosed herein describe methods and systems for measuring and handling gaps in NR. Therefore, it is understood that the scope of the protection is extended to such a program and in addition to a computer readable means having a message therein, such computer readable storage means contain program code means for implementation of one or more steps of the method, when the program runs on a server or mobile device or any suitable programmable device. The method is implemented in at least one embodiment through or together with a software program written in e.g., Very high speed integrated circuit Hardware Description Language (VHDL) another programming language or implemented by one or more VHDL or several software modules being 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 which could be e.g., hardware means like e.g., an ASIC, or a combination of hardware and software means, e.g., an ASIC and an FPGA, or at least one microprocessor and at least one memory with software modules located therein. The method embodiments described herein could be implemented partly in hardware and partly in software. Alternatively, the invention may be implemented on different hardware devices, e.g., using a plurality of CPUs.

[0223] Embodiments herein disclose methods and systems for measuring and handling gaps in NR. Embodiments herein disclose methods and systems for a User Equipment (UE) to indicate its capabilities for reporting measurement gap requirements, measurement gap and NCSG requirements and NeedForInterruption requirements in UAI. Embodiments herein disclose methods and systems for the UE to report "cell reselection measurements" if there is temporary capability restriction on some frequencies. Embodiments herein disclose methods and systems for the UE to handle the measurement gaps and measurement objects if the UE releases serving cell which is part of the configuration due to wait timer expiry. Embodiments herein disclose methods and systems for the UE to indicate the relation between LTM measurements without a gap and the L3 measurements without the gap.

[0224] Overall NG-RAN Architecture: Overall NG-RAN Architecture (as illustrated in Fig. 23) is given in Figure 6.1-1 (Overall architecture) of 3gpp specification TS 38.401. From the figure it can be observed that the NG-RAN consists of a set of gNBs connected to the 5GC through the NG interface. The gNBs can be interconnected through the Xn interface. A gNB may consist of a gNB-CU and one or more gNB-DU(s). A gNB-CU and a gNB-DU is connected via F1 interface. CU may send F1AP (F1 Application Protocol) messages to DU such as F1AP UE Context Setup Request, F1AP UE Context Modification Request to setup or modify a UE Context on the DU and the DU will send F1AP UE Context Setup Response or F1AP UE Context Modification Response is successful. CU may send CU to DU RRC Information in the F1AP messages to inform the RRC related information. An example is given below, based on 3gpp specifications. The below Information Element (IE) contains the RRC Information that are sent from gNB-CU to gNB-DU.

[0225] [Table 13]

[0226]

[0227]

[0228]

[0229]

[0230] An example specification for "HandoverPreparationInformation" message is shown below.

[0231] HandoverPreparationInformation.This message is used to transfer the NR RRC information used by the target gNB during handover preparation or UE context retrieval, e.g. in case of resume or re-establishment, including UE capability information. This message is also used for transferring the information between the CU and DU. Direction: source gNB / source RAN to target gNB or CU to DU.

[0232] [Table 14]

[0233]

[0234]

[0235]

[0236]

[0237]

[0238]

[0239]

[0240]

[0241] Framework for supporting capability change:Considering the case of a MUSIM UE with two USIMs (i.e. two UEs in same MUSIM device), UE-A (USIM-A) and UE-B. The MUSIM UE supports dual transmission and reception. i.e., both UE-A and UE-B can be connected (RRC_CONNECTED) at the same time. Both UE-A and UE-B can transmit or receive data at the same time. It is possible that UE-A and UE-B may share some RF / radio / hardware / software resources The UE capabilities (such as UE Radio Access Capabilities as described in 3gpp specifications like TS 38.306) of UE-A may be different at different times depending on whether UE-B is in connected (i.e. depending on whether UE-B uses the RF / radio / hardware / software resources).

[0242] Considering UE-A is in RRC-CONNECTED state with NWK-A. UE-B(USIM-B) is moving to RRC_CONNECTED or is transitioning to RRC_CONNECTED. UE-A provides the information to NWK-A to release some resources or update some parameters for the MUSIM operations. This information is pertaining to the change of some of the capabilities in UE-A, release of SCG or SCells in UE-A, deactivation of SCG or SCells in UE-A, information that SCG or SCells can be setup or activated in UE-A etc., measurement gaps requirements (needforgaps / needforgapsorncsg) related information in UE-A to facilitate MUSIM operations. The change can be temporary capability restrictions or removal of temporary capability restrictions.

[0243] When UE-A is in RRC_CONNECTED mode and the UE capability changes due to activities in UE-B, UE-A informs NW-A about the capability change through a RRC message such as UE Assistance Information.

[0244] If the capability of UE-A has changed due to UE-B's activities when UE-A was in RRC_IDLE or RRC_INACTIVE mode, a similar approach as in RRC_CONNECTED can be used. UE-A may also indicate that the capability has changed in RRC setup request / RRC resume request, RRC setup complete or RRC resume complete. Capabilities may be retrieved later through UAI etc.

[0245] NW-A may configure UE-A on whether it can inform changed capabilities, e.g. through "otherConfig" in the RRC Reconfiguration message. In other words through "otherConfig" network may control whether UE-A can update the changed capabilities. There may be a single enumerated or some other parameter that could be used to control in otherConfig which informs the UE-A to report the changed capabilities. Alternatively, each of these individual capabilities that could be changed may have separate flags in otherConfig. Accordingly, UE can report the updated or changed capabilities with UE assistance information message. The information contents in UAI can pertain to MUSIM assistance information or MUSIM UE capability information.

[0246] CU of NW-A may configure UE-A with a filter and UE-A will report the change of capabilities based on the filter. For e.g. the filter may be a bandfilter. If the UE capability of a band included in the filter changes, UE-A reports the capability change. If none of the capability in the filter changes due to UE-B actions, UE-A may not initiate the messages to indicate UE capability change.

[0247] If the bands supported by the changed capability is different from the older capability, NW-A may reconfigure UE-A to release one or more SCells, SCG or perform handover etc. NW-A may configure UE-A to report any available measurements when the capabilities are changed. Since the changed capability can be different from older capability, NW-A may prefer to change the SCells or SCG rather than releasing them, or in a case perform handover to a different frequency. Measurements from the UE can aid the network to take such decisions.

[0248] The static or dynamic capability signaling reported by UE may include the below and many more.

[0249] · Number of Rx links

[0250] · Number of Tx links

[0251] · Maximum Number of MIMO layers

[0252] · Processing capability in terms of supportable component carriers or dual connectivity on NW A

[0253] · Request for at least one of configuration, activation, deactivation and release of one or more SCell / SCG on NW A

[0254] · UL or DL TDD configuration

[0255] · DRX configuration on NW B

[0256] · Measurement configuration on NW B

[0257] · Frequencies which are supported or the frequencies which are restricted.

[0258] An example specification including the UAI for reporting MUSIM temporary capability restrictions is given below.

[0259] In case of dual connectivity, UE-A may report the change of capabilities such as restriction in capabilities and removal of restriction of capabilities to the MN of NW-A, even when the capabilities are related to SN of NW-A or when they are applicable for both MN and SN of NW-A.

[0260] Network utilizes the updated capability received from the UE and reconfigures the UE with updated parameters. Network may update configuration of dual connectivity, carrier aggregation, power control, interference coordination, DAPS configuration, number of layers, etc. based on the capability information including supported bands, supported band combination, scheduling pattern and / or TDD UL / DL config information etc. A sample set of changes for reporting the temporary capability restrictions is given below.

[0261] [Table 15]

[0262]

[0263]

[0264]

[0265]

[0266]

[0267]

[0268]

[0269]

[0270]

[0271] UE behavior for Multi SIM operations for dual active is captured in TS 38.331 as below (only the relevant sections included).

[0272] [Table 16]

[0273]

[0274]

[0275]

[0276]

[0277]

[0278]

[0279] T348 is MUSIM wait timer, and any embodiment referring to T348 is applicable to any other timer which does similar functionality of MUSIM wait timer. Similarly any embodiment referring to MUSIM wait timer is applicable for any timer which perform the start or stop or expiry of the functionalities similar to T348 like described above. We use MUSIM wait timer and T348 interchangeably in this invention. musim-WaitTimer is the value of the MUSIM wait timer, for e.g. as configured in NR RRC CR R2-2313699. Any other IE may be used for the same functionality of musim-WaitTimer and all the embodiments referring to musim-WaitTimer are equally applicable.

[0280] Consider v17.6.0 of 3gpp specifications such as, but not limited to, TS 38.331,TS 38.300,TS 38.306,TS 38.321 as the relevant background.

[0281] Consider the case of a MUSIM UE with two USIMs (i.e. two UEs in same MUSIM device), UE-A and UE-B. UE-A informs the capability restrictions or the removal of capability restrictions to CU of NW-A through RRC messages such as, but not limited to, UE Assistance Information

[0282] Multi-Radio Dual Connectivity: Dual connectivity or more technically multi-radio dual connectivity is specified by 3gpp in specifications such as TS 37.340. A summary of the details on dual connectivity are given below.

[0283] NG-RAN supports Multi-Radio Dual Connectivity (MR-DC) operation whereby a user equipment (UE) in RRC_CONNECTED is configured to utilize radio resources provided by two distinct schedulers, located in two different NG-RAN nodes connected via a non-ideal backhaul, one providing NR (New Radio) access and the other one providing either E-UTRA (Evolved UMTS Terrestrial Radio Access) or NR access. One node acts as the master 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), in which a UE is connected to one ng-eNB (a E-UTRA base station that can connect to 5G core) that acts as a MN and one gNB (5G base station) that acts as a SN. NG-RAN also supports NR-E-UTRA Dual Connectivity (NE-DC), in which a UE is connected to one gNB that acts as a MN and one ng-eNB that acts as a SN. Primary cell of a master or secondary cell group is called SpCell. SpCell of a master cell group is called PCell while SpCell of a secondary cell group is called PSCell. In MR-DC, a group of serving cells associated with the Master Node, comprising of the SpCell (PCell) and optionally one or more SCells is called MCG or Master Cell Group. A group of serving cells associated with the Secondary Node, comprising of the SpCell (PSCell) and optionally one or more SCells. is known as Secondary Cell Group (SCG) in MR-DC the Frame timing and SFN between the cells in MCG and SCG may not be aligned.

[0284] MN may inform the received temporary capability restriction and the band filter it has configured to the SN. An example ASN.1 structure for informing the same from TS 38.331 is given in Table 17.

[0285] [Table 17]

[0286]

[0287]

[0288]

[0289]

[0290] v17.7.0 of 3gpp specifications 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 are considered as the relevant background.

[0291] In case of a MUSIM UE with two USIMs (i.e. two UEs in same MUSIM device), UE-A and UE-B., following scenarios for MUSIM UE may be considered:

[0292] a. UE-A is configured with OtherConfig by gNB CU of NW-A, including musim-WaitTimer. On the expiry of musim-WaitTimer, UE-A applies the temporary capability restrictions on its own.

[0293] b. UE-A is configured with dual connectivity and is also configured with OtherConfig by gNB CU of MN of NW-A, including musim-WaitTimer. On the expiry of musim-WaitTimer, UE-A applies the temporary capability restrictions on its own.

[0294] Thus, it is desired to address the following challenges about the reporting of capability restrictions:

[0295] a. CU to DU communication for handling the temporary capability restriction application at the expiry of MUSIM Wait Timer.

[0296] b. DU behavior upon the expiry of MUSIM Wait Timer.

[0297] c. MN to SN communication for handling the temporary capability restrictions at the expiry of MUSIM Wait Timer.

[0298] d. MN behavior upon the expiry of MUSIM Wait Timer.

[0299] e. UE behavior upon the expiry of MUSIM Wait Timer.

[0300] f. SN behavior upon the expiry of MUSIM Wait Timer.

[0301] The present invention relates generally to the field of mobile communication comprising Multi-SIM, and more particularly, to method and system for handling wait timer in MUSIM. Method disclosed herein addresses the temporary capability restriction upon the expiry of MUSIM-WaitTime. Further, the discloses method takes care of CU to DU communication for handling the temporary capability restriction application at the expiry of MUSIM Wait Timer. Further, the method disclosed herein addresses DU, MN,SN and UE behaviours upon the expiry of MUSIM Wait Timer. The method also addresses the scenario of MN to SN communication for handling the temporary capability restrictions for handling the temporary capability restriction application at the expiry of MUSIM Wait Timer.

[0302] In an embodiment, MN informs the musim-WaitTimer ( such as, but not limited to t348 value in NR) to SN. The musim-WaitTimer could be the the musim-WaitTimer configured by MN (CU of the MN) to the UE for reporting the temporary capability restrictions. i.e. CU of MN informs the CU of SN the musim-WaitTimer (t348 value). CU of MN may be the same MN CU which configured the UE with musim-WaitTimer or could be a different MN CU than the one that has configured the musim-WaitTimer. When it is a different MN CU than the one that has configured the musim-WaitTimer, it would have received the musim-WaitTimer from another CU during handover, RRC Reestablishment etc.

[0303] In an embodiment, MN informs SN the musim-WaitTimer (t348 value) during Xn procedures.

[0304] In an embodiment, MN informs SN the musim-WaitTimer (t348 value) in Xn messages such as, but not limited to S-NODE ADDITION REQUEST, S-NODE MODIFICATION REQUEST, S-NODE CHANGE REQUIRED etc.

[0305] In an embodiment, MN informs SN the musim-WaitTimer (t348 value) using RRC Inter Node messages (INM).

[0306] In an embodiment, MN informs SN the musim-WaitTimer (t348 value) using RRC INM CG-ConfigInfo.

[0307] In an embodiment, MN informs SN the musim-WaitTimer (t348 value) using RRC IEs such as musim-CapRestrictionInfo-r18 in CG-ConfigInfo.

[0308] In an embodiment, musim-WaitTimer is an optional IE in CG-ConfigInfo and SN avoids applying the temporary capability restrictions upon the expiry of wait timer if the musim-WaitTimer is not included in CG-ConfigInfo by MN. An example specification change is given in Table 18:

[0309] [Table 18]

[0310]

[0311] SN which has received musim-WaitTimer-r18 from MN starts the MUSIM wait timer with the received value of musim-WaitTimer-r18 upon reception of temporary capability restrictions, and upon expiry of the timer, applies the temporary capability restriction as requested by the UE for the SCG,the cells in SCG etc. SN stops the timer upon receiving SN RRCReconfigurationComplete for the RRCReconfiguration (send by the SN) with the restricted capabilities according to the temporary capability restrictions.

[0312] In an embodiment, MN also starts the MUSIM wait timer with the configured value of musim-WaitTimer-r18 upon reception of temporary capability restrictions, and upon expiry of the timer, applies the temporary capability restriction as requested by the UE for the MCG, the cells in MCG etc. MN stops the timer upon receiving RRCReconfigurationComplete for the RRCReconfiguration (send by the MN) with the restricted capabilities according to the temporary capability restrictions.

[0313] In an alternative embodiment, MN releases SCG upon the expiry of MUSIM wait timer even if the UE has not requested for SCG release in the UAI informing the temporary capability restrictions. In an embodiment, if any of the temporary capability restrictions requested by the UE such as (but not limited to) SCells to be released or the affected Cells are for the SCG cells, MN releases SCG upon the expiry of MUSIM wait timer.

[0314] In an embodiment, a UE which has started T348 upon sending UAI requesting for temporary capability restrictions, releases SCG upon the expiry of T348.

[0315] In an embodiment, a UE which has started T348 upon sending UAI requesting for temporary capability restrictions, releases SCG upon the expiry of T348, even when the requested temporary capability restrictions doesn't include the release of SCG.

[0316] In an embodiment, a UE which has started T348 upon sending UAI requesting for temporary capability restrictions, releases SCG upon the expiry of T348, even when the requested temporary capability restrictions doesn't include the release of SCG, if any of those capabilities are related to SCG (for e.g. SCells to be released or the affected Cells are for the SCG cells).

[0317] In an embodiment, UE informs the network (such as MN CU) its preferred action upon the expiry of T348, i.e. whether it will reduce the capabilities as requested in requested temporary capability restrictions, upon the expiry of T348 or will operate with the existing capabilities without reducing the capabilities according to the requested temporary capability restrictions. This may be informed in UAI in an IE like musim-Assistance, for e.g. the preferred action may be included in musim-CapRestriction.

[0318] In an embodiment, MN may inform the SN the received preferred action of the UE, upon expiry of MUSIM wait timer. This may be included in RRC INM CG-ConfigInfo and included in Xn procedures. If the preferred action is not to apply the temporary capability restrictions (i.e. operate with the existing capabilities without reducing the capabilities according to the requested temporary capability restrictions), SN may not reduce the capabilities for the affected Cells or may not release the SCells upon the expiry of the MUSIM wait timer.

[0319] In an embodiment, UE sends temporary capability restriction for the release of SCells or for reducing the capability of SCells, only for MCG SCells. Cells in musim-CellToAffectList-r18 and musim-Cell-SCG-ToReleasedList are applicable for MCG cells alone. If the UE needs a temporary capability restriction for any of the SCG SCells (i.e. any of the SCG SCells are affected due to MUSIM operations) or needs to release a SCG SCell for MUSIM operations, it requests to release SCG, for e.g. by including scg-ReleasePreference-r18 and setting it as scgReleasePreferred.

[0320] CU-DU interaction with respect to musim-WaitTimer

[0321] In an embodiment gNB CU informs the musim-WaitTimer ( such as, but not limited to t348 value in NR) to gNB DU. The musim-WaitTimer could be the musim-WaitTimer configured by CU to the UE for reporting the temporary capability restrictions. i.e. CU informs the DU the musim-WaitTimer (t348 value).

[0322] In an embodiment, gNB CU informs the temporary capability restrictions to gNB DU.

[0323] In an embodiment gNB CU informs the musim-WaitTimer (t348 value) configured to the UE for reporting the temporary capability restrictions to gNB DU. i.e. if the UE was configured for reporting temporary capability restrictions and a musim-WaitTimer was included in the configuration, gNB CU informs the musim-WaitTimer to gNB DU.

[0324] In an embodiment, gNB CU informs the musim-WaitTimer along with the temporary capability restrictions received from the UE to gNB DU.

[0325] In an embodiment, in NR, gNB CU informs gNB DU the musim-WaitTimer using "CU to DU RRC Information" IE in F1AP messages such as F1AP UE Context Setup Request and F1AP UE Context Modification Request. gNB DU also may receive temporary capability restrictions from gNB CU.

[0326] In an embodiment, upon receiving the temporary capability restrictions, gNB DU starts the musim-WaitTimer. Upon expiry of the musim-WaitTimer, gNB DU applies the temporary capability restrictions, for e.g. by releasing the SCell configuration, updating the MIMO layers in Downlink (DL), the MIMO layers in Uplink (UL), supportedBandwidth in DL, supportedBandwidth in UL etc. according to the received temporary capability restrictions from CU .

[0327] In an embodiment, the musim-WaitTimer informed by gNB CU to gNB DU is configured by the same gNB CU to the UE. i.e. CU includes musim-WaitTimer in the OtherConfig send to the UE and also may receive temporary capability restrictions from the UE. The gNB CU further sends the musim-WaitTimer and / or temporary capability restrictions to the gNB DU.

[0328] In an embodiment, DU is target gNB DU and the CU is target gNB CU during handover / reconfigurationWithSync preparation or LTM / conditional handover / conditional PSCellChange preparation.

[0329] In an embodiment, a source gNB CU informs target gNB CU musim-WaitTimer during handover using NR RRC INM IEs such as HandoverPreparationInformation and the target gNB CU informs the musim-WaitTimer to target gNB DU. Target gNB CU also may receive temporary capability restrictions from source gNB CU and inform the same to target gNB DU.

[0330] In an embodiment, DU is new gNB DU and the CU is new gNB CU during RRCReestablishment.

[0331] In an embodiment, old gNB CU informs new gNB CU musim-WaitTimer during RRCReestablishment and the new gNB CU informs musim-WaitTimer, new gNB DU using NR RRC INM IEs such as HandoverPreparationInformation. New gNB CU also may receive temporary capability restrictions from old gNB CU and inform the same to new gNB DU.

[0332] In an embodiment, DU is SN DU in dual connectivity and the CU is SN CU. In an embodiment, SN CU receives the musim-WaitTimer from MN CU and the SN CU informs SN DU musim-WaitTimer. SN CU also may receive temporary capability restrictions from MN CU and inform the same to SN DU.

[0333] In an embodiment, gNB CU informs gNB DU the MUSIM Wait timer such as musim-WaitTimer using RRC Inter-Node Message CG-Config.

[0334] In an embodiment, gNB CU informs gNB DU the musim-WaitTimer using RRC Inter-Node Message CG-ConfigInfo.

[0335] In an embodiment, if a gNB DU receives CU to DU RRC Information including musim-WaitTimer and is not able to decode the musim-WaitTimer or receives ASN.1 protocol errors while attempting to decode the musim-WaitTimer,Gnb DU ignores the received musim-WaitTimer.

[0336] In an embodiment, musim-WaitTimer send by gNB CU to gNB DU is encoded as an OCTET STRING according to NR RRC format.

[0337] Example changes in TS 37.340 according to the embodiments of the invention are given in Table 19 and Table 20.

[0338] [Table 19]

[0339]

[0340] [Table 20]

[0341]

[0342] In an embodiment, if gNB DU is not able to decode the musim-WaitTimer, it doesn't apply the temporary capability restrictions upon the expiry of the MUSIM Wait timer.

[0343] In an embodiment, there is no assigned criticality for musim-WaitTimer in CU to DU RRC Information IE. In an embodiment, there is no criticality for musim-WaitTimer in CU to DU RRC Information IE.

[0344] In an embodiment, gNB CU may inform the gNB DU the received preferred action of the UE, upon expiry of MUSIM wait timer. This may be included in CU to DU RRC Information and may be included in F1AP messages such as F1AP UE Context Setup Request or F1AP UE Context Modification Request. If the preferred action is not to apply the temporary capability restrictions, DU may not reduce the capabilities such as Max MiMO layers (in DL and / or UL) or the Max Rx bandwidth(in DL and UL) for the affected Cells or may not release the SCells upon the expiry of the MUSIM wait timer.

[0345] In this manner, the present disclosure provides techniques to address the different scenarios about the reporting of capability restriction applied by a MUSIM UE on the expiry of musim-WaitTimer. The method disclosed herein provides techniques for handling wait timer in MUSIM for efficient switching from one USIM to the other USIM.

[0346] [Table 21]

[0347]

[0348]

[0349]

[0350]

[0351] The principal object of embodiments herein is to disclose methods and systems for reporting of capability restrictions in Centralized Unit (CU) - Distributed Unit (DU) operations in wireless communication networks.

[0352] Another object of embodiments herein is to disclose CU to DU communication for handling the temporary capability restrictions or removal of temporary capability restrictions.

[0353] Another object of embodiments herein is to disclose DU behavior upon receiving temporary capability restrictions.

[0354] Another object of embodiments herein is to disclose DU to CU communication for handling the temporary capability restrictions

[0355] The embodiments herein achieve methods and systems for reporting of capability restrictions in Centralized Unit (CU) - Distributed Unit (DU) operations in wireless communication networks. Referring now to the drawings, and more particularly to FIGS. 2 through 3, where similar reference characters denote corresponding features consistently throughout the figures, there are shown embodiments.

[0356] In an embodiment herein, the gNB CU informs the temporary capability restrictions to the gNB DU (as depicted in FIGs. 2 and 3). In an embodiment herein, the gNB CU informs the filter configured to the UE for reporting the temporary capability restrictions to gNB DU; i.e., if the UE was configured for reporting temporary capability restrictions and a filter such as, but not limited to, band list (such as, but not limited to, musim-CandidateBandList) was included in the configuration, the gNB CU informs the same to the gNB DU. In an embodiment herein, the gNB CU informs the filter such as, but not limited to, band list (such as, but not limited to, musim-CandidateBandList) along with the temporary capability restrictions received from the UE to the gNB DU.

[0357] In an embodiment herein, in NR, the gNB CU informs the gNB DU the filter such as, but not limited to, band list (such as, but not limited to, musim-CandidateBandList) using the CU to DU RRC Information IE in F1AP messages (such as, but not limited to, F1AP UE Context Setup Request and F1AP UE Context Modification Request). The gNB DU also may receive temporary capability restrictions from the gNB CU; for e.g., the gNB DU identifies the affected bands or bands to be avoided a through UAI IE in the CU to DU RRC Information. In an embodiment herein, the DU identifies the bands which are affected due to MUSIM operations by mapping the band entry index (such as, but not limited to, bandEntryIndex in the MUSIM-AffectedBandsList received in the UAI within CU to DU RRC information) to the bandEntryIndex in musim-CandidateBandList and identifies the MIMO layers in Downlink (DL), the MIMO layers in Uplink (UL), supportedBandwidth in DL, supportedBandwidth in UL for each of the bands and band combinations and generates DU to CU RRC Information IEs (such as, but not limited to, CellGroupConfig) and informs the gNB CU in F1AP UE Context Setup Response or F1AP UE Context Modification Response. In an embodiment herein, DU identifies the bands which needs to be avoided due to mUSIM operations by mapping the band entry index (such as, but not limited to, bandEntryIndex in the musim-AvoidedBandsList received in the UAI within CU to DU RRC information) to the bandEntryIndex in musim-CandidateBandList and generates DU to CU RRC Information IEs such as, but not limited to, Requested BandCombinationIndex or Selected BandCombinationIndex excluding any bands in musim-AvoidedBandsList and informs the same to the UE in F1AP UE Context Setup Response or F1AP UE Context Modification Response. The DU also generates the UE configuration using MUSIM-AffectedBandsList, musim-AvoidedBandsList based on musim-CandidateBandList.

[0358] In an embodiment herein, the filter such as, but not limited to, band list (such as, but not limited to, musim-CandidateBandList) informed by the gNB CU to the gNB DU is configured by the same gNB CU to the UE; i.e., the CU includes musim-CandidateBandList in the OtherConfig send to the UE and also may receive temporary capability restrictions from the UE based on the musim-CandidateBandList. The gNB CU further sends the musim-CandidateBandList and / or temporary capability restrictions to the gNB DU.

[0359] In an embodiment herein, the DU is a target gNB DU and the CU is a target gNB CU during handover / reconfigurationWithSync preparation or LTM / conditional handover / conditional PSCellChange preparation or any other mobility procedure. In an embodiment herein, a source gNB CU informs the target gNB CU the filter such as, but not limited to, band list (such as, but not limited to, musim-CandidateBandList) during handover using NR RRC INM IEs; such as, but not limited to, HandoverPreparationInformation, and the target gNB CU informs the musim-CandidateBandList to the target gNB DU. The Target gNB CU also may receive temporary capability restrictions from the source gNB CU and inform the same to the target gNB DU.

[0360] In an embodiment herein, the DU is a new gNB DU and the CU is a new gNB CU during RRCReestablishment. In an embodiment herein, the old gNB CU informs the new gNB CU the filter (such as, but not limited to, band list (such as, but not limited to, musim-CandidateBandList)) during RRCReestablishment and the new gNB CU informs the filter (such as, but not limited to, musim-CandidateBandList) new gNB DU using NR RRC INM IEs (such as, but not limited to, HandoverPreparationInformation). The New gNB CU also may receive temporary capability restrictions from the old gNB CU and new Gnb CU may inform the same to the new gNB DU.

[0361] In an embodiment herein, the DU is SN DU in dual connectivity and the CU is SN CU. In an embodiment herein, the SN CU receives the filter such as, but not limited to, band list (such as, but not limited to, musim-CandidateBandList) from MN CU and the SN CU informs the SN DU the filter (such as, but not limited to, musim-CandidateBandList). The SN CU also may receive temporary capability restrictions from the SN CU and SN CU informs the same to the target gNB DU.

[0362] In an embodiment herein, the gNB CU informs the gNB DU the filter such as, but not limited to, band list (such as, but not limited to, musim-CandidateBandList) using RRC Inter-Node Message CG-Config. In an embodiment herein, the gNB CU informs the gNB DU the filter such as, but not limited to, band list (such as, but not limited to, musim-CandidateBandList) using RRC Inter-Node Message CG-ConfigInfo.

[0363] In an embodiment herein, if a gNB DU receives CU to DU RRC Information including musim-CandidateBandList and is not able to decode the musim-CandidateBandList or receives ASN.1 protocol errors while attempting to decode the musim-CandidateBandList, the gNB DU ignores musim-CandidateBandList and generates DU to CU RRC Information without considering musim-CandidateBandList or MUSIM-AffectedBandsList and musim-AvoidedBandsList.

[0364] In an embodiment herein, musim-CandidateBandList send by the gNB CU to the gNB DU is encoded as an OCTET STRING according to NR RRC format.

[0365] Example changes in TS 37.340 according to embodiments as disclosed herein, is given in Table 22.

[0366] [Table 22]

[0367]

[0368]

[0369]

[0370]

[0371] 8.3.1 UE Context Setup:

[0372] 8.3.1.2 Successful Operation:

[0373] If the musim-CandidateBandList IE is included in the UE CONTEXT SETUP REQUEST, the gNB-DU shall use this for identifying the restrictions due to MUSIM operations in UE Assistance Information and take this information into account for UE specific configurations.

[0374] OR

[0375] If the musim-CandidateBandList IE is included in the UE CONTEXT SETUP REQUEST, the gNB-DU shall take this information into account for UE specific configurations.

[0376] 8.3.4 UE Context Modification (gNB-CU initiated):

[0377] 8.3.4.2 Successful Operation:

[0378] If the musim-CandidateBandList IE is included in the UE CONTEXT MODIFICATION REQUEST, the gNB-DU shall use this for identifying the restrictions due to MUSIM operations in UE Assistance Information and take this information into account for UE specific configurations.

[0379] OR

[0380] If the musim-CandidateBandList IE is included in the UE CONTEXT MODIFICATION REQUEST, the gNB-DU shall take this information into account for UE specific configurations.

[0381] In an embodiment herein, if the gNB DU is not able to decode the musim-CandidateBandList, it doesn't apply the MUSIM-AffectedBandsList or musim-AvoidedBandsList fields in UE AssistanceInformation, while generating the configuration for UE, or while generating the DU to CU RRC Information.

[0382] In an embodiment herein, there is no assigned criticality for musim-CandidateBandList in CU to DU RRC Information IE. In an embodiment herein, there is no criticality for musim-CandidateBandList in CU to DU RRC Information IE.

[0383] The embodiments disclosed herein can be implemented through at least one software program running on at least one hardware device and performing network management functions to control the network elements. The elements include blocks which can be at least one of a hardware device, or a combination of hardware device and software module.

[0384] The embodiment disclosed herein describes methods and systems for reporting of capability restrictions in Centralized Unit (CU) - Distributed Unit (DU) operations in wireless communication networks. Therefore, it is understood that the scope of the protection is extended to such a program and in addition to a computer readable means having a message therein, such computer readable storage means contain program code means for implementation of one or more steps of the method, when the program runs on a server or mobile device or any suitable programmable device. The method is implemented in at least one embodiment through or together with a software program written in e.g., Very high speed integrated circuit Hardware Description Language (VHDL) another programming language, or implemented by one or more VHDL or several software modules being 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 which could be e.g., hardware means like e.g., an ASIC, or a combination of hardware and software means, e.g. an ASIC and an FPGA, or at least one microprocessor and at least one memory with software modules located therein. The method embodiments described herein could be implemented partly in hardware and partly in software. Alternatively, the invention may be implemented on different hardware devices, e.g., using a plurality of CPUs.

[0385] The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and / or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments herein have been described in terms of embodiments, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the scope of the embodiments as described herein.

[0386] Various embodiments of the present disclosure are hereinafter explained with reference to Figs. 1-24.

[0387] The term "UE capability" used herein refers to hardware and software capabilities of the UE. Varying capabilities across devices may be hardware capabilities including radio frequency capabilities like bands or band combinations supported, processing capabilities (e.g., baseband computational capabilities), software capabilities like the support of various features, layer 1 capabilities, layer 2 capabilities, layer 3 capabilities and so on. In general, the UE reports its UE radio access capabilities which are static at least when the network requests the capabilities. To limit signaling overhead, the gNB requests the UE to provide NR capabilities for a restricted set of bands. When responding, the UE can skip a subset of the requested band combinations when the corresponding UE capabilities are the same. If supported by the UE and the network, the UE may provide an ID in NAS signaling that represents its radio capabilities for one or more Radio Access Technologies (RATs) in order to reduce signaling overhead. The ID may be assigned either by the manufacturer or by the serving Public Land Mobile Network (PLMN). The manufacturer-assigned ID corresponds to a pre-provisioned set of capabilities. In the case of the PLMN-assigned ID, assignment takes place in NAS signaling. Detailed list of UE capabilities that are exchanged based on aforementioned methods is specified in 3GPP technical specifications like TS 38.306. A gNB provides a UE with various configurations / features through RRC messages like RRC reconfiguration or RRC resume based on the reported UE capability. In a MUSIM device which supports simultaneous RRC Connections on multiple USIMs, UE capabilities of the RRC_CONNECTED USIM in MUSIM device changes when other USIM(s) move from RRC_IDLE or RRC_INACTIVE to RRC_CONNECTED or vice versa, for example, the supported bands may change.

[0388] Fig. 1 illustrates an environment 100 in which some embodiments of the present disclosure may be practiced. The environment 100 exemplarily depicts a user 102 associated with a User Equipment (UE) 104. Some examples of the UE 104 may include, but not limited to, electronic devices such as, a smartphone, a laptop, a desktop, a personal computer, or any spatial computing device capable of performing wireless communication. For example, the UE 104 may work on multiple platforms and / or Operating Systems to perform different operations related to wireless communication. In an embodiment, the UE 104 may host more than one Subscriber Identity Module (SIM) i.e., the UE 104 is a MUSIM (Multi SIM) UE. In an example scenario, the UE 104 may initiate a connection with a network entity 108 for a plurality of conditions. For example, the plurality of conditions related to the UE 104 may be initial access of the network entity 108 from RRC_IDLE, transition from RRC_Inactive to RRC_CONNECTED, RRC connection re-establishment, handover, beam failure recovery, synchronous reconfiguration, timing alignment during Secondary cell (Scell) addition, Downlink (DL) out of sync, Uplink (UL) out of sync, Scheduling Request(SR) max transmission reached, UL data arrival and on demand system information. It shall be noted that the plurality of conditions mentioned hereinabove are for exemplary purposes and the UE 104 may establish connection with the network entity 108 based on other conditions. In an embodiment, the UE 104 establishes connection with the network entity 108 to configure UE capabilities based on the MUSIM operations. The MUSIM operations indicate network state transitions associated with one of a Universal Subscriber Identity Module (USIM) of the UE 104.

[0389] The UE 104 may establish connection with the network entity 108 via a communication network 106. It is understood that the UE 104 may be in operative communication with the communication network 106, such as the Internet, enabled by a network provider, also known as an Internet Service Provider (ISP). The UE 104 may be connected to the communication network 106 using a wireless network. Some non-limiting examples of wireless networks may include the Wireless LAN (WLAN), cellular networks, Bluetooth or ZigBee networks, and the like.

[0390] Various embodiments of the present disclosure disclose a method performed by the UE 104 for reporting UE capabilities for a MUSIM UE to the network entity 108. The UE capabilities comprise one or more gap requirements. The UE 104 determines whether it is capable to report the UE capabilities comprising the one or more gap requirements and reports the UE capabilities once configured by the network entity 108. The operations performed by the UE 104 are explained in detail next with reference to Fig. 2.

[0391] The term "gap requirements" used herein refers to one of: a measurement gap requirement, a Network Controlled Small Gap (NCSG) requirement, and an interruption requirement. In wireless technologies like New Radio (NR) and Long Term Evolution (LTE), a Radio Resource Control (RRC) connected to the UE performs various measurements for Radio Resource Management (RRM) purpose, positioning, etc. For RRM, UE measures reference signals such as Synchronization Signal / PBCH block (SSB), Channel State Information Reference Signal (CSI-RS), etc. and reports the measurement results to the network. According to the NR specification TS 38.300, measurements to be performed by a UE for connected mode mobility are classified in at least four measurement types that include intra-frequency NR measurements, inter-frequency NR measurements, inter-Radio Access Technology (RAT) measurements for Evolved-Universal Terrestrial Radio Access Network (E-UTRA) and inter-RAT measurements for UTRA. For each measurement type one or several measurement objects are defined, for example, carrier frequency to be monitored. For each measurement object one or several reporting configurations are defined (a reporting configuration defines the reporting criteria). Three reporting criteria are namely event triggered reporting, periodic reporting and event triggered periodic reporting are used. The association between a measurement object and a reporting configuration is created by a measurement identity (a measurement identity links together one measurement object and one reporting configuration of the same RAT). The measurement identity is used as well when reporting results of the measurements. For positioning, the UE may report SSB / CSI-RS measurements and may also report measurements based on additional reference signals like Positioning Reference Signals (PRS).

[0392] When the UE needs to measure inter frequency NR or inter-RAT measurements or intra frequency measurements outside the active downlink Bandwidth Part (BWP) when SSB is not completely contained in the active DL BWP, the UE may use measurement gaps. Measurement gaps are configured by the network (for e.g., gNB in NR) and there is no transmission or reception during the gap period. Measurement gap configuration includes a gap offset, gap length, repetition period and measurement gap timing advance. Gap offset specifies the sub- frame where the start of measurement gap occurs. Gap length gives the duration of the gap while the repetition period defines how often the measurement gap occurs. In wireless technologies like NR, Long Term Evolution (LTE) and the like, a RRC connected the UE performs various measurements for RRM, positioning, and the like. For RRM, the UE measures one or more reference signals such as, but not limited to Synchronization Signal / Physical Broadcast Channel (PBCH) Block (SSB), CSI-RS, and the like. and reports the measurement results to the network. According to the NR specification TS 38.300, the measurements to be performed by the UE for connected mode mobility are classified in at least four measurement types. The measurement types are intra-frequency NR measurements, inter-frequency NR measurements, inter-RAT measurements for E-UTRA and inter-RAT measurements for UTRA.

[0393] Fig. 2 illustrates the UE 104 for reporting UE capabilities, in accordance with an embodiment of the present disclosure. As already explained, the UE 104 may establish a connection with the network entity 108 for transmitting UE capabilities.

[0394] In an embodiment, the UE 104 may comprise two SIMs in same UE 104, USIM-A and USIM-B. The UE 104 supports dual transmission and reception, i.e., both the USIM-A and USIM-B may be connected (RRC_CONNECTED) at the same time. Both the UE-A and UE-B may transmit or receive data at the same time. In an embodiment, the USIM-A and USIM-B may share one or more RF, radio, hardware, and software resources. The UE capabilities (such as UE radio access capabilities as described in 3GPP specifications such as TS 38.306) of USIM-A may be different at different times depending on whether the USIM-B is in connected (i.e., depending on whether the USIM-B uses the RF, radio, hardware, and software resources).

[0395] Consider the USIM-A is in RRC-CONNECTED state with a network entity A (NW-A). USIM-B is moving to RRC_CONNECTED and / or is in transitioning to RRC_CONNECTED. The USIM-A provides the information to NW-A to release some resources or update some parameters for the MUSIM operations. This information is pertaining to a change of the UE capabilities in USIM-A, release of a Secondary Cell Group (SCG) or SCells in the UE-A, deactivation of SCG or SCells in UE-A, information that SCG or SCells are setup or activated in UE-A, and the like. The UE capabilities comprise measurement gaps requirements (needforgaps / needforgapsorncsg) related information in UE-A to facilitate MUSIM operations.

[0396] When the USIM-A is in RRC_CONNECTED mode and the UE capabilities changes due to change in the network state of USIM-B, USIM-A informs NW-A about the capability change through a RRC message such as UE Assistance Information (UAI) message. If the UE capabilities of the USIM-A have changed due to USIM-B's activities when the USIM-A was in RRC_IDLE or RRC_INACTIVE mode, a similar approach as in RRC_CONNECTED is used. The USIM-A may also indicate that the capability has changed in RRC setup request / RRC resume request, RRC setup complete or RRC resume complete. Capabilities may be retrieved later through UAI message and the like. The USIM-A may report that the capability has changed or may report the changed capabilities based on specific actions in the USIM-B. When the USIM-B is handed over from a licensed frequency to an unlicensed frequency or from one Frequency Range (FR) to another FR, USIM-A may report the capability change to NW-A.

[0397] In an embodiment, the UE 104 comprises a processor 202, a memory 204, an input / output module 206 and a communication interface 208. It shall be noted that, in some embodiments, the UE 104 may include more or fewer components than those depicted herein. The various components of the UE 104 may be implemented using hardware, software, firmware, or any combinations thereof. Further, the various components of the UE 104 may be operably coupled with each other. More specifically, various components of the UE 104 may be capable of communicating with each other using communication channel media (such as buses, interconnects, etc.).

[0398] In one embodiment, the processor 202 may be embodied as 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, the processor 202 may be embodied as one or more of various processing devices, such as a coprocessor, a microprocessor, a controller, a digital signal processor (DSP), a processing circuitry with or without an accompanying DSP, or various other processing devices including, a microcontroller unit (MCU), a hardware accelerator, a special-purpose computer chip, or the like.

[0399] In an embodiment, the processor 202 is configured to: (1) receive a request to transmit UE capabilities from the network entity 108, (2) determine whether the UE 104 is capable of reporting a change in one or more gap requirements. The change in the one or more gap requirements is due to MUSIM operations, and (3) transmit the UE capabilities of reporting the one or more gap requirements to the network entity 108.

[0400] In one embodiment, the memory 204 is capable of storing machine executable instructions, referred to herein as instructions 205. In an embodiment, the processor 202 is embodied as an executor of software instructions. As such, the processor 202 is capable of executing the instructions 205 stored in the memory 204 to perform one or more operations described herein.

[0401] Further, the memory 204 is also capable of storing UE capability information, historical reports, network configuration information, information related to network entities previously connected to, previous temporary UE capabilities for different MUSIM operations, and the like. The memory　204　can be any type of storage accessible to the processor 202 to perform respective functionalities. For example, the memory　204　may include one or more volatile or non-volatile memories, or a combination thereof. For example, the memory 204 may be embodied as semiconductor memories, such as flash memory, mask ROM, PROM (programmable ROM), EPROM (erasable PROM), RAM (random access memory), etc. and the like.

[0402] In an embodiment, the I / O module 206 may include mechanisms configured to receive inputs from and provide outputs to operator of the UE 104, the user 102. To enable reception of inputs and provide outputs from the UE 104, the I / O module 206 may include at least one input interface and / or at least one output interface. Some examples of the input interface may include, but are not limited to, a keyboard, a mouse, a joystick, a keypad, a touch screen, soft keys, a microphone, and the like. Examples of the output interface may include, but are not limited to, a display such as a light emitting diode display, a thin-film transistor (TFT) display, a liquid crystal display, an active-matrix organic light-emitting diode (AMOLED) display, a microphone, a speaker, a ringer, and the like.

[0403] In an embodiment, the communication interface 208 may include mechanisms configured to communicate with other entities in the environment 100, for example, the network entity 108. In an embodiment, the UE 104 may initiate establishing a connection with the network entity 108 via the communication interface 208. The processor 202 is configured to determine if the UE 104 is capable of reporting a change in one or more gap requirements. The change in the one or more gap requirements is due to MUSIM operations. The UE capabilities of reporting the one or more gap requirements to the network entity 108 is transmitted by the processor 202 to the network entity 108 via the communication interface 208. The network entity transmits the temporary UE capabilities on receiving the UE capabilities of reporting the one or more gap requirements.

[0404] In an embodiment, the one or more gap requirements and the temporary UE capability configurations may be stored in a database 210. The UE 104 is depicted to be in operative communication with a database 210. In one embodiment, the database 210 is configured to store one or more temporary UE capability configurations generated by the network entity 108 over a period of time.

[0405] The database 210 may include multiple storage units such as hard disks and / or solid-state disks in a redundant array of inexpensive disks (RAID) configuration. In some embodiments, the database 210 may include a storage area network (SAN) and / or a network attached storage (NAS) system. In one embodiment, the database 210 may correspond to a distributed storage system, wherein individual databases are configured to store custom information, such as one or more gap requirements, temporary UE capability configurations and the like.

[0406] In some embodiments, the database 210 is integrated within the UE 104. For example, the UE 104 may include one or more hard disk drives like database 210. In other embodiments, the database 210 is external to the UE 104 and may be accessed by the UE 104 using a storage interface (not shown in Fig. 2). The storage interface is any component capable of providing the processor 202 with access to the database 210. The 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 providing the processor 202 with access to the database 210.

[0407] Fig. 3 illustrates a sequence flow of a method 300 of reporting UE capabilities for a MUSIM UE, in accordance with an embodiment of the present disclosure.

[0408] At 302, the network entity sends a request to transmit UE capabilities. In an embodiment, the network entity 108 sends the request to transmit UE capabilities while UE registers to the network. In another embodiment, the network entity 108 sends the request when it needs additional capabilities from the network. In an embodiment of the present disclosure, the UE capabilities may comprise the one or more gap requirements.

[0409] At 304, the UE 104 determines if it is capable of reporting the change in one or more gap requirements. The one or more gap requirements may be, but not limited to: the measurement gap requirement, the NCSG requirement, the interruption requirement and the like. In an embodiment, due to MUSIM operations, there is a change in the one or more gap requirements. For example, consider a UE 104 with two USIMs i.e., USIM-A and USIM-B. The USIM-A is in RRC_CONNECTED state and the USIM-B is in RRC_IDLE state. The one or more gap requirements for the current MUSIM operation is determined and stored in the UE 104. However, when the state of the USIM-B changes from RRC_IDLE to RRC_CONNECTED, there is a change in the one or more gap requirements. In another example, consider the USIM-B is handed over from a licensed frequency to an unlicensed frequency or from one Frequency Range (FR) to another FR. Due to the change in the FR, there is a change the measurement gap requirements and NCSG requirements. In another example, consider there is no change in the FR. There may be a change in the interruption requirements due to a change in the network state. Based on the change in the one or more gap requirements, the UE capabilities need to be reconfigured.

[0410] At 306, the UE 104 transmits the UE capabilities of reporting the one or more gap requirements to the network entity 108. In an embodiment, the one or more gap requirements are transmitted to the network entity 108 as part of a UE Assistance Information (UAI) message or UECapabilityInformation. In another embodiment, the one or more gap requirements are transmitted to the network entity 108 as part of a new Information Element (IE). The UE capabilities of reporting the one or more gap requirements are indicated as, but not limited to, flags, different fields, attributes of the UAI / IE message.

[0411] In an embodiment, the UE 104 receives the temporary UE capabilities configuration based on the UE capabilities of reporting the one or more gap requirements from the network entity 108. The temporary UE capabilities configuration is explained in detail with respect to Fig. 4.

[0412] The method 300 with reference to　Fig. 3, may 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 media discs, volatile memory components (e.g., DRAM or SRAM), or non-volatile memory or storage components (e.g., hard 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, net book, Web book, tablet computing device, smart phone, or other mobile computing device). Such software may be executed, for example, on a single local computer.

[0413] Fig. 4 illustrates a sequence flow of a method 400 of configuring UE capabilities for the MUSIM UE.

[0414] At 402, the network entity 108 receives the UE capabilities. In an embodiment, the UE capabilities are indicated as a musim-CapabilityRestriction in the UAI message. The UE capabilities comprise the capability of the UE 104 to report the change in the one or more gap requirements. In an embodiment, the UE capabilities are transmitted as an RRC message that UE 104 transmits to the network entity 108 to inform the network entity 108 on details of its capabilities. For example, the UE capabilities may comprise one or more gap requirements. The one or more gap requirements may be, but not limited to: the measurement gap requirement, the NCSG requirement, the interruption requirement. In an embodiment, due to MUSIM operations, there is a change in the one or more gap requirements. For example, consider a UE 104 with two USIMs i.e., USIM-A and USIM-B, the USIM-A is in RRC_CONNECTED state and the UAIM-B is in RRC_IDLE state. The state of the USIM-B changes from RRC_IDLE to RRC_CONNECTED, due to the change in the network state of USIM-B, there is a change in the one or more gap requirements. For example, consider the USIM-B is handed over from a licensed frequency to an unlicensed frequency or from one Frequency Range (FR) to another FR. Due to the change in the FR, there is a change the measurement gap requirements and NCSG requirements. In another example, if there is no change in the FR, there is a change in the interruption requirements due to a change in the network state. On receiving the UE capabilities, the network entity 108 determines the one or more gap requirements (i.e., the temporary UE capability configurations) based on the received UE capabilities. The one or more gap requirements i.e., the temporary UE capability configurations are the configurations for the UE based on the change in the MUSIM operations. The temporary UE capabilities ensure a faster communication and improve the network connectivity. In an embodiment, the network entity 108 transmits the temporary UE capability configurations to a target network during handover of the UE 104. In an embodiment, the UE 104 sends a request to update the one or more gap requirements due to MUSIM operations 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 a UE 104 with two USIMs i.e., USIM-A and USIM-B, the USIM-A is in RRC_CONNECTED state and the UAIM-B is in RRC_IDLE state. Consider the state of the USIM-B changes from RRC_IDLE to RRC_CONNECTED. Due to the change in the state, there is the change in the one or more gap requirements. Therefore, the network entity 108 determines the temporary UE capability configurations. However, when the MUSIM configurations go back to the initial operations i.e., the USIM-A is in RRC_CONNECTED state and the USIM-B is in RRC_IDLE state, the temporary UE capability configurations need to be removed from the UE 104. Thus, the network entity 108 updates the temporary UE capability configurations to initial UE capabilities configuration.

[0415] At 404, the network entity 108 transmits the temporary UE capability configurations i.e., a one or more gap requirements configurations to the UE 104. In an embodiment, the network entity 108 transmits the temporary UE capability configurations to the target network. The target network may be a network that is identified for handover of the UE 104. In another embodiment, the UE 104 requests the network entity 108 for the temporary UE capability configurations.

[0416] The method 400 with reference to　Fig. 4, may 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 media discs, volatile memory components (e.g., DRAM or SRAM), or non-volatile memory or storage components (e.g., hard 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, net book, Web book, tablet computing device, smart phone, or other mobile computing device). Such software may be executed, for example, on a single local computer.

[0417] Fig. 5 illustrates a method 500 of reporting UE capabilities for a MUSIM UE comprising, in accordance with an embodiment of the present disclosure.

[0418] At 502, the network entity sends a request to transmit UE capabilities. In an embodiment, the UE capabilities are transmitted as an RRC message that UE 104 transmits to the network entity 108 to inform the network entity 108 on details of its capabilities. For example, the UE capabilities may comprise one or more gap requirements. The one or more gap requirements may be, but not limited to: a measurement gap requirement, a Network Controlled Small Gap (NCSG) requirement, an interruption requirement, and the like. In an embodiment, due to MUSIM operations, there is a change in the one or more gap requirements. The MUSIM operations indicate network state transitions associated with one of a Universal Subscriber Identity Module (USIM) of the UE 104. For example, consider a UE 104 with two USIMs i.e., USIM-A and USIM-B, the USIM-A is in RRC_CONNECTED state and the USIM-B is in RRC_IDLE state. Due to the change in the state of the USIM-B i.e., from RRC_IDLE to RRC_CONNECTED, there is a change in the one or more gap requirements. Based on the change in the one or more gap requirements, the UE capabilities need to be changed. For example, consider the USIM-B is handed over from a licensed frequency to an unlicensed frequency or from one Frequency Range (FR) to another FR. Due to the change in the FR, there is a change the measurement gap requirements and NCSG requirements. In another example, if there is no change in the FR, there is a change in the interruption requirements due to change in the network state.

[0419] At 502, the UE 104 determines if it is capable of reporting the change in one or more gap requirements. The UE capabilities of reporting the one or more gap requirements are determined based on one or more attribute. The one or more attributes are: musim-CapabilityRestriction, nr-NeedForGap-Reporting, nr-NeedForInterruptionReport and nr-NeedForGapNCSG-Reporting. The one or more gap requirements are: the measurement gap requirement, the Network Controlled Small Gap (NCSG) requirement, and the interruption requirement.

[0420] At 506, the UE 104 transmits the UE capabilities of reporting the one or more gap requirements to the network entity 108. In an embodiment, the one or more gap requirements are transmitted to the network entity 108 as part of the UAI message or UECapabilityInformation. In an embodiment, the UE capabilities of reporting the one or more gap requirements are indicated as, but not limited to flags, different fields, attributes in the UAI message. In an embodiment, the UE 104 requests the network entity 108 for the temporary UE capability configurations based on the UE capabilities. In another embodiment, the UE 104 reports the one or more gap requirements to the network entity 108. The determination of the temporary UE capability configurations by the network entity 108 is explained in detail with respect to Fig. 6.

[0421] The method 500 with reference to　Fig. 5, may 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 media discs, volatile memory components (e.g., DRAM or SRAM), or non-volatile memory or storage components (e.g., hard 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, net book, Web book, tablet computing device, smart phone, or other mobile computing device). Such software may be executed, for example, on a single local computer.

[0422] Fig. 6 illustrates a method 600 of configuring UE capabilities for a MUSIM UE, in accordance with an embodiment of the present disclosure.

[0423] At 602, the network entity 108 receives the UE capabilities. The UE capabilities comprise the capability of the UE 104 to report the change in the one or more gap requirements. In an embodiment, the UE capabilities are transmitted as an RRC message that UE 104 transmits to the network entity 108 to inform the network entity 108 on details of its capabilities. For example, the UE capabilities may comprise one or more gap requirements. The one or more gap requirements may be, but not limited to: the measurement gap requirement, the Network Controlled Small Gap (NCSG) requirement, the interruption requirement, and the like. In an embodiment, due to MUSIM operations, there is a change in the one or more gap requirements. For example, consider a UE 104 with two USIMs i.e., USIM-A and USIM-B, the USIM-A is in RRC_CONNECTED state and the UAIM-B is in RRC_IDLE state, the one or more gap requirements for the current MUSIM operation are fixed. However, when the state of the USIM-B changes from RRC_IDLE to RRC_CONNECTED, there is a change in the one or more gap requirements. Based on the change in the one or more gap requirements, the UE capabilities need to be changed. For example, consider the USIM-B is handed over from a licensed frequency to an unlicensed frequency or from one Frequency Range (FR) to another FR. Due to the change in the FR, there is a change the measurement gap requirements and NCSG requirements. In another example, if there is no change in the FR, there is a change in the interruption requirements due to change in the network state.

[0424] At 604, the network entity 108 determines the temporary UE capability configurations based on the received UE capabilities. The temporary UE capability configurations are the configurations for the UE based on the change in the MUSIM operations. The temporary UE capabilities ensure a faster communication and improve the network connectivity. In an embodiment, the network entity 108 transmits the temporary UE capability configurations to a target network. In an embodiment the UE 104 sends a request to update the one or more gap requirements due to MUSIM operations i.e., the temporary UE capability configurations. 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, the USIM-A is in RRC_CONNECTED state and the USIM-B is in RRC_IDLE state, the one or more gap requirements for the current MUSIM operation are fixed. However, when the state of the USIM-B changes from RRC_IDLE to RRC_CONNECTED, there is a change in the one or more gap requirements therefore, the network entity 108 determines the temporary UE capability configurations. However, when the MUSIM configurations go back to the initial operations i.e., the USIM-A is in RRC_CONNECTED state and the UAIM-B is in RRC_IDLE state, the temporary UE capability configurations need to be removed from the UE 104. Thus, the one or more gap requirements i.e., the temporary UE capability configurations are updated. The network entity 108 reconfigures updated one or more gap requirements.

[0425] At 606, the network entity 108 transmits the temporary UE capability configurations to the UE 104. In an embodiment, the network entity 108 transmits the temporary UE capability configurations to the target network. The target network may be a network that the UE 104 is handed over. In another embodiment, the UE 104 requests the network entity 108 for the temporary UE configurations.

[0426] In an embodiment, the UE 104 may request the network entity to remove the temporary UE capability configurations. For example, consider a UE 104 with two USIMs i.e., USIM-A and USIM-B, the USIM-A is in RRC_CONNECTED state and the UAIM-B is in RRC_IDLE state, the one or more gap requirements for the current MUSIM operation are fixed. However, when the state of the USIM-B changes from RRC_IDLE to RRC_CONNECTED, there is a change in the one or more gap requirements therefore, the network entity 108 determines the temporary UE capability configurations. However, when the MUSIM configurations go back to the initial operations i.e., the USIM-A is in RRC_CONNECTED state and the USIM-B is in RRC_IDLE state, the temporary UE capability configurations need to be removed from the UE 104.

[0427] The method 600 with reference to　Fig. 6, may 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 media discs, volatile memory components (e.g., DRAM or SRAM), or non-volatile memory or storage components (e.g., hard 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, net book, Web book, tablet computing device, smart phone, or other mobile computing device). Such software may be executed, for example, on a single local computer.

[0428] The sequence of operations of the method 300, the method 400, the method 500 and the method 600 need not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped together and performed in form of a single step, or one operation may have several sub-steps that may be performed in parallel or in sequential manner.

[0429] Fig. 7 illustrates a block diagram of an exemplary computer system 700, for implementing embodiments consistent with the present disclosure. The computer system 700 may be, without limitation to, the UE 104 and the network entity 108. The computer system 700 may include a central processing unit ("CPU" or "processor") 701. The processor 701 may include at least one data processor for executing processes. The processor 701 may include specialized processing units such as, integrated system (bus) controllers, memory management control units, floating point units, graphics processing units, digital signal processing units, etc.

[0430] The processor 701 may be disposed in communication with one or more input / output (I / O) devices 708 and 709 via I / O interface 707. The I / O interface 707 may employ communication protocols / methods such as, without limitation, audio, analog, digital, monaural, RCA, stereo, IEEE-1394, serial bus, universal serial bus (USB), infrared, PS / 2, BNC, coaxial, component, composite, digital visual interface (DVI), high-definition multimedia interface (HDMI), RF antennas, 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, or the like), etc.

[0431] Using the I / O interface 707, the computer system 700 may communicate with one or more I / O devices 708 and 709. For example, the input devices 708 may be an antenna, keyboard, mouse, joystick, (infrared) remote control, camera, card reader, fax machine, dongle, biometric reader, microphone, touch screen, touchpad, trackball, stylus, scanner, storage device, transceiver, video device / source, etc. The output devices 709 may 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) or the like), audio speaker, etc.

[0432] In some embodiments, the processor 701 may be disposed in communication with external elements such as external computer systems, servers, network elements. The network interface 710 may employ connection protocols including, without limitation, direct connect, 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.

[0433] In some embodiments, the processor 701 may be disposed in communication with a memory 703 (e.g., RAM, ROM, etc.) via a storage interface 702. The storage interface 702 may connect to memory 703 including, without limitation, memory drives, removable disc drives, etc., employing connection protocols such as, serial advanced technology attachment (SATA), Integrated Drive Electronics (IDE), IEEE-1394, Universal Serial Bus (USB), fibre channel, Small Computer Systems Interface (SCSI), etc. The memory drives may further include a drum, magnetic disc drive, magneto-optical drive, optical drive, Redundant Array of Independent Discs (RAID), solid-state memory devices, solid-state drives, etc.

[0434] The memory 703 may store a collection of program or database components, including, without limitation, user interface 704, an operating system 705, a web browser 706 etc. In some embodiments, computer system 700 may store user / application data, such as, the data, variables, records, etc., as described in this disclosure. Such databases may be implemented as fault-tolerant, relational, scalable, secure databases such as Oracle ® or Sybase®.

[0435] The operating system 705 may facilitate resource management and operation of the computer system 700. Examples of operating systems include, without limitation, APPLE MACINTOSH® OS X, UNIX®, UNIX-like system distributions (E.G., BERKELEY SOFTWARE DISTRIBUTIONTM(BSD), FREEBSDTM, NETBSDTM, OPENBSDTM, etc.), LINUX DISTRIBUTIONSTM(E.G., RED HATTM, UBUNTUTM, KUBUNTUTM, etc.), IBMTMOS / 2, MICROSOFTTMWINDOWSTM(XPTM, VISTATM / 7 / 8, 10 etc.), APPLE® IOSTM, GOOGLE® ANDROIDTM, BLACKBERRY® OS, or the like.

[0436] In some embodiments, the computer system 700 may implement the web browser 706 stored program components. The web browser 706 may be a hypertext viewing application, such as MICROSOFT®INTERNET EXPLORER®, GOOGLETMCHROMETM, MOZILLA®FIREFOX®, APPLE®SAFARI®, etc. Secure web browsing may be provided using Secure Hypertext Transport Protocol (HTTPS), Secure Sockets Layer (SSL), Transport Layer Security (TLS), etc. Web browsers 706 may utilize facilities such as AJAX, DHTML, ADOBE®FLASH®, JAVASCRIPT®, JAVA®, Application Programming Interfaces (APIs), etc. In some embodiments, the computer system 700 may implement a mail server stored program component. The mail server may be an Internet mail server such as Microsoft Exchange, or the like. The mail server may utilize facilities such as Active Server Pages (ASP), ACTIVEX®, ANSI®C++ / C#, MICROSOFT®, .NET, CGI SCRIPTS, JAVA®, JAVASCRIPT®, PERL®, PHP, PYTHON®, WEBOBJECTS®, etc. The mail server may utilize communication protocols such as Internet Message Access Protocol (IMAP), Messaging Application Programming Interface (MAPI), MICROSOFT®exchange, Post Office Protocol (POP), Simple Mail Transfer Protocol (SMTP), or the like. In some embodiments, the computer system 700 may implement a mail client stored program component. The mail client may be a mail viewing application, such as APPLE®MAIL, MICROSOFT®ENTOURAGE®, MICROSOFT®OUTLOOK®, MOZILLA®THUNDERBIRD®, etc.

[0437] Fig. 15 illustrates a flow chart of Secondary Node (SN) operation (in DC) for MUSIM wait timer, in accordance with an embodiment of the present disclosure.

[0438] The SN may receive temporary capability restriction such as musim-CelltoAffectList-r18 or musim-CellToRelease-r18 and MUSIM Wait timer from MN. The MUSIM Wait timer expiry. The SN may apply the received temporary capability restrictions, such as reducing the DL / UL MIMO layers, DL / UL Rxlayers in musim-CellToAffectList or release Scells in musim-CellToReleasesList for SCG.

[0439] Fig. 16 illustrates a flow chart of Master Node (MN) operation (in DC) for MUSIM wait timer, in accordance with an embodiment of the present disclosure.

[0440] The MN may configure the UE with MUSIM Wait timer, and inform MUSIM Wait timer to SN. The MN may receive temporary capability restrictions such as musim-CellToAffectList-R18 or musim-CellToRelease-r18 and inform at least SCG restrictions to the SN. MUSIM Wait timer expiry. The MN may apply the received temporary capability restrictions, such as reducing the DL / UL MIMO layers, DL / UL Rxlayers in musim-CellToAffectList or release SCells in musim-CellToReleaseList for MCG.

[0441] Fig. 17 illustrates a Control Unit (CU) operation for MUSIM wait timer, in accordance with an embodiment of the present disclosure. The CU may configure the UE with MUSIM Wait timer (such as musim-WaitTimer). The CU may receive muim-WaitTimer from another CU for handover / Reestablishment / dual connectivity. The CU may informs MUSIM wait timer to DU. The MUSIM wait timer is expired. The CU may release Scells, SCG etc, if received in temporary capability restrictions request form the UE.

[0442] Fig. 18 illustrates a Distributed Unit (DU) operation for MUSIM wait timer, in accordance with an embodiment of the present disclosure. The DU may receive temporary capability restrictions such as musim-CellToAffectList-r18 or musim-CellToRelease-r18 and MUSIM Wait timer from CU. The MUSIM wait timer is expired. The DU may apply the temporary capability restricions such as redcing the DL / UL MIMO layers, DL / UL Rxlayer etc. based on musim-CellToAffectList etc. received from CU, release Scells in musim-CellToReleaseList received from CU.

[0443] Fig. 19 illustrates a User Equipment (UE) operation for MUSIM wait timer, in accordance with an embodiment of the present disclosure. The UE may be configured with MUSIM wait timer. The UE may inform temporary capability restrictions to the network without requesting to release SCG. MUSIM wait timer is expired. The UE may apply the temporary capability restrictions for MCG and release SCG.

[0444] Fig. 20 illustrates an environment 2000 in which some embodiments of the present disclosure may be practiced. The environment 100 exemplarily depicts the UE 104, some examples of the UE 104 may include, but not limited to, electronic devices such as, a smartphone, a laptop, a desktop, a personal computer, or any spatial computing device capable of performing wireless communication. For example, the UE 104 may work on multiple platforms and / or Operating Systems to perform different operations related to wireless communication. In an embodiment, the UE 104 may host more than one Subscriber Identity Module (SIM) i.e., the UE 104 is a MUSIM (Multi SIM) UE. In an example scenario, the UE 104 may initiate a connection with the Centralized Unit (CU) 2002 for a plurality of conditions. Further, the CU 2002 may establish connection with a Distributed Unit (DU) for the plurality of conditions. For example, the plurality of conditions related to the UE 104 may be initial access of the CU 2002 from RRC_IDLE, transition from RRC_Inactive to RRC_CONNECTED, RRC connection re-establishment, handover, beam failure recovery, synchronous reconfiguration, timing alignment during Secondary cell (Scell) addition, Downlink (DL) out of sync, Uplink (UL) out of sync, Scheduling Request(SR) max transmission reached, UL data arrival and on demand system information. It shall be noted that the plurality of conditions mentioned hereinabove are for exemplary purposes and the UE 104 may establish connection with the CU 2002 based on other conditions. In an embodiment, the UE 104 establishes connection with the CU 2002 to configure UE capabilities based on the MUSIM operations. In this embodiment, the CU 2002 may establish communication with the DU 2004 to configure the UE capabilities. The MUSIM operations indicate network state transitions associated with one of a Universal Subscriber Identity Module (USIM) of the UE 104.

[0445] The CU as used herein is　the part of O-RAN architecture which provides support for higher layers of the protocol stack such as, but not limited to, Service Data Adaptation Protocol　(SDAP), RRC and Packet Data Convergence Protocol　(PDCP)　layers. In an embodiment, 5G protocol stack along with 5G hardware acceleration card is used to process the protocols.

[0446] The DU as used herein handles lower layers of the protocol stack, which includes, but is not limited to, the Upper Physical, MAC, and RLC layers. Functionalities of the DU may include, but are not limited to: data organization and management, interaction with a Radio Unit (RU), and latency reduction and efficiency. The DU is tasked with preparing data for transmission, it structures the data, ensuring it is in the right format for efficient radio transmission. The DU directly manages data communication with the RU, translating the organized data into radio waves for transmission and vice versa. Being in close proximity to the RU and managing the lower protocol layers, the DU assures minimal latency, especially crucial for real-time data exchange applications. It is understood that the UE 104 may be in operative communication with the CU 2002, such as the Internet, enabled by a network provider, also known as an Internet Service Provider (ISP). The UE 104 may be connected to the CU 2002 using a wireless network. Some non-limiting examples of wireless networks may include the Wireless LAN (WLAN), cellular networks, Bluetooth or ZigBee networks, and the like.

[0447] In an embodiment, the CU 2002 may establish connection with the DU 2002 via a communication network. It is understood that the CU 2002 may be in operative communication with the DU 2004, such as the Internet, enabled by a network provider, also known as an Internet Service Provider (ISP). The CU 2002 may be connected to the DU 2004 using a wireless network. Some non-limiting examples of wireless networks may include the Wireless LAN (WLAN), cellular networks, Bluetooth or ZigBee networks, and the like. In an embodiment, the CU 2002 is coupled with the DU 2004. In another embodiment, the CU 2002 may be at a different location.

[0448] Various embodiments of the present disclosure disclose a method performed by the DU 2004 for configuring UE capabilities via the CU 2002. The UE capabilities comprise one or more gap requirements. The DU 2004 identifies the affected bands and restricted bands due to the MUSIM operations from the temporary UE capability restrictions and generates a UE configuration. The modules of DU 2004 is similar to modules as given in Fig. 2 which are nor explained again for the sake of privity. The communication between the UE 104, the CU 2002 and the DU 2004 is further explained in detail with respect to Fig. 21.

[0449] Fig. 21 illustrates a sequence flow of a method 2100 of configuring UE capabilities, according to the embodiments of the present disclosure. At 2102, the UE 104 transmits the temporary UE capability restrictions to the CU 2002. The temporary UE capability restrictions may include, but are not limited to, frequencies that cannot be temporarily supported by the UE due to MUSIM operations i.e., the UE transmits which of its supported capabilities are temporary restricted. The MUSIM operations indicate network state transitions associated with one of the USIM of the UE, wherein the network state comprises: the idle state, the connected state and the inactive state. For example, consider the USIM-A transitioning from IDLE state to CONNECTED state, and the USIM-B in CONNECTED state, there is a change in MUSIM operations. Therefore, some capabilities are restricted.

[0450] At 2104, the CU 2002 transmits the temporary UE capability restrictions and one or more band lists to the DU 2004. The one or more band lists may be transmitted in a F1 Application Protocol (AP) Information Element (IE) associated with one of: a UE Context Setup Request message, a UE Context Modification Request message and a Inter Node RRC message CG-Config. In an embodiment, the one or more band lists is a band list configured by the CU to the UE. In another embodiment, another CU configures the one or more band lists and is received by the CU 2002 in HandoverPreparationInformation. In yet another embodiment, the one or more band lists is a band list configured by a master node and received by the CU in CG-Config when the CU is a secondary node in dual connectivity. The one or more band lists is transmitted as an OCTETSTRING encoded in a RRC ASN.1 format in the CU to DU RRC Information with criticality as ignore.

[0451] At 2106, the DU 2004 identifies affected bands and restricted bands due to the MUSIM operations from the temporary UE capability restrictions, based on the one or more band lists. For example, consider the USIM-A is in CONNECTED state using band-A and USIM-B in IDLE state using band-B. Consider the state of USIM-B changes from IDLE state to CONNECTED state, due to this change in the MUSIM operations, band-A is affected and band-B is restricted. In this example, the DU 2004 identifies that band-A and band-B cannot be used. The DU 2004 identifies that band-C and band-D may be used based on the one or more band lists received by the CU 2002. The DU 2106 generates a UE configuration based on the identification. In an embodiment, the UE configuration is the temporary UE capabilities.

[0452] At 2108, the DU 2004 transmits the UE configuration to the CU 2002. At 2110, the CU 2002 transmits the UE configuration to the UE 104. The DU 2004 has to transmit the UE configurations via the CU 2002.

[0453] The method 2100 with reference to　Fig. 21, may 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 media discs, volatile memory components (e.g., DRAM or SRAM), or non-volatile memory or storage components (e.g., hard 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, net book, Web book, tablet computing device, smart phone, or other mobile computing device). Such software may be executed, for example, on a single local computer.

[0454] The sequence of operations of the method 2100 need not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped together and performed in form of a single step, or one operation may have several sub-steps that may be performed in parallel or in sequential manner.

[0455] Fig. 22 illustrates a flow chart of method 2200 of configuring UE capabilities, in accordance with an embodiment of the present disclosure.

[0456] At 2202, the DU 2004 receives the temporary UE capability restrictions and one or more band lists from CU 2002. The temporary UE capability restrictions due MUSIM operations is received by the CU 2002 from the UE 104. The temporary UE capability restrictions indicate temporary radio frequency capabilities of bands in the one or more band lists configured in the UE 104. The temporary UE capability restrictions may include, but are not limited to, frequencies that cannot be temporarily supported by the UE due to MUSIM operations i.e., the UE transmits which of its supported capabilities are temporary restricted. The MUSIM operations indicate network state transitions associated with one of the USIM of the UE, wherein the network state comprises: the idle state, the connected state and the inactive state. The one or more band lists may be received by the DU 2004 in a F1 AP IE associated with one of: a UE Context Setup Request message, a UE Context Modification Request message and a Inter Node RRC message CG-Config. In an embodiment, the one or more band lists is a band list configured by the CU to the UE. In another embodiment, another CU configures the one or more band lists and is received by the CU 2002 in HandoverPreparationInformation. In yet another embodiment, the one or more band lists is a band list configured by a master node and received by the CU in CG-Config when the CU is a secondary node in dual connectivity. The one or more band lists is transmitted as an OCTETSTRING encoded in a RRC ASN.1 format in the CU to DU RRC Information with criticality as ignore.

[0457] At 2204, the DU 2004 identifies the affected bands and the restricted bands due to the MUSIM operations from the temporary UE capability restrictions, based on the one or more band lists. For example, consider the USIM-A is in CONNECTED state using band-A and USIM-B in IDLE state using band-B. Consider the state of USIM-B changes from IDLE state to CONNECTED state, due to this change in the MUSIM operations, band-A is affected and band-B is restricted. In this example, the DU 2004 identifies that band-A and band-B cannot be used. The DU 2004 identifies that band-C and band-D may be used based on the one or more band lists received by the CU 2002. The DU 2106 generates a UE configuration based on the identification. In an embodiment, to identify the affected bands and restricted bands the DU 2004 identifies the MIMO layers in Downlink (DL), the MIMO layers in Uplink (UL), a supportedBandwidth in DL, a supportedBandwidth in UL for each of the bands and band combinations in the one or more band lists.

[0458] At 2206, the DU 2004 generates the UE configuration based on the affected bands and restricted bands in the UE, via the CU, based on the identification. For example, consider the DU 2004 identifies band-A and band-B as affected bands and restricted bands due to the MUSIM operations from the temporary UE capability restrictions, and band-C and band-D as available band for the MUSIM operation. The DU 2004 transmits the UE configuration with the available bands to the UE 104, via the CU 2002.

[0459] The method 2200 with reference to　Fig. 22, may 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 media discs, volatile memory components (e.g., DRAM or SRAM), or non-volatile memory or storage components (e.g., hard 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, net book, Web book, tablet computing device, smart phone, or other mobile computing device). Such software may be executed, for example, on a single local computer.

[0460] The sequence of operations of the method 2200 need not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped together and performed in form of a single step, or one operation may have several sub-steps that may be performed in parallel or in sequential manner.

[0461] The present disclosure discloses a method and a UE for reporting UE capabilities for a MUSIM UE. The present disclosure enables transmission of change in gap requirements due to change in the MUSIM operations thereby receiving temporary configurations to support the various MUSIM operations. Further, the temporary UE capability configurations improve the resource allocation is the MUSIM UE. The present disclosure also facilitates improved communication and seamless handover.

[0462] Fig. 24 illustrates CU operation for temporary capability restriction, in accordance with an embodiment of the present disclosure. The CU may configure the UE with band filter (such as musim-CandidateBandList) and receive band filter (such as musim-CandidateBandList) from another CU for handover / Reestablishment / dual connectivity. The CU may receive temporary capability restrictions such as MUSIM-AffectedBandList or musim-AvoidedBandsList. The CU may inform the band filter and temporary capability restrictions to the DU.

[0463] Fig, 25 illustrates DU operation for temporary capability restriction, in accordance with an embodiment of the present disclosure. The DU may receive temporary capability restrictions such as MUSIM-AffectedBandsList or musim-AvoidedBandsList and ban filter (such as musim-CandidateBandList). The DU may identify the max MIMO layers in DL and UL, max bandwidth in DL and UL for each of the bands base on received temporary capability restrictions and band filter. The DU may generate UE configuration and DU to CU RRC information based on identified parameters.

[0464] The described operations may be implemented as a method, system or article of manufacture using standard programming and / or engineering techniques to produce software, firmware, hardware, or any combination thereof.　The described operations may be implemented as code maintained in a "non-transitory computer readable medium", where a processor may read and execute the code from the computer readable medium. The processor is at least one of a microprocessor and a processor capable of processing and executing the queries. A non-transitory computer readable medium may include media such as magnetic storage medium (e.g., hard disk drives, floppy disks, tape, etc.), optical storage (CD-ROMs, DVDs, optical disks, etc.), volatile and non-volatile memory devices (e.g., EEPROMs, ROMs, PROMs, RAMs, DRAMs, SRAMs, Flash Memory, firmware, programmable logic, etc.), etc. Further, non-transitory computer-readable media may include all computer-readable media except for a transitory. The code implementing the described operations may further be implemented in hardware logic (e.g., an integrated circuit chip, Programmable Gate Array (PGA), Application Specific Integrated Circuit (ASIC), etc.).

[0465] The illustrated steps are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments. Also, the words "comprising," "having," "containing," and "including," and other similar forms are intended to be equivalent in meaning and be open ended in that an item or items following any one of these words is not meant to be an exhaustive listing of such item or items or meant to be limited to only the listed item or items. It must also be noted that as used herein, the singular forms "a," "an," and "the" include plural references unless the context clearly dictates otherwise.

[0466] Furthermore, one or more computer-readable storage media may be utilized in implementing embodiments consistent with the present disclosure. A computer readable storage medium refers to any type of physical memory on which information or data readable by a processor may be stored. Thus, a computer readable storage medium may store instructions for execution by one or more processors, including instructions for causing the processor(s) to perform steps or stages consistent with the embodiments described herein. The term "computer readable medium" should be understood to include tangible items and exclude carrier waves and transient signals, i.e., are non-transitory. Examples include random access memory (RAM), read-only memory (ROM), volatile memory, non-volatile memory, hard drives, CD ROMs, DVDs, flash drives, disks, and any other known physical storage media.

[0467] Finally, the language used in the specification has been principally selected for readability and instructional purposes, and it may not have been selected to delineate or circumscribe the inventive subject matter. Accordingly, the disclosure of the embodiments of the disclosure is intended to be illustrative, but not limiting, of the scope of the disclosure.

[0468] With respect to the use of substantially any plural and / or singular terms herein, those having skill in the art can translate from the plural to the singular and / or from the singular to the plural as is appropriate to the context and / or application. The various singular / plural permutations may be expressly set forth herein for sake of clarity.

Claims

1.A method performed by a terminal supporting a multi-subscriber identity module (MUSIM), the method comprising:receiving a request to transmit a user equipment (UE) capability, from a network entity;determining whether the terminal is capable of reporting a change in one or more gap requirements, wherein the change in the one or more gap requirements is based on a MUSIM operation; andtransmitting the UE capability of reporting the one or more gap requirements to the network entity.2.The method of claim 1, wherein the MUSIM operation includes a network state transition associated with one of a universal subscriber identity module (USIM) of the terminal.3.The method of claim 1, further comprising:receiving, from the network entity, a temporary UE capability configuration based on the UE capability; andreporting the one or more gap requirements to the network entity in an UE assistance information (UAI) message.4.The method of claim 1, wherein the UE capability of reporting the one or more gap requirements is determined based on one or more attributes comprising: musim-CapabilityRestriction, nr-NeedForGap-Reporting, nr-NeedForInterruptionReport and nr-NeedForGapNCSG-Reporting.5.A method performed by a network entity, the method comprising:transmitting, to a terminal, a request to transmit a user equipment (UE) capability; andreceiving, from the terminal, the UE capability of reporting the one or more gap requirements to the network entity, in case that whether the terminal is capable of reporting a change in one or more gap requirements is determined, wherein the change in the one or more gap requirements is based on a MUSIM operation.6.The method of claim 5, wherein the MUSIM operation includes a network state transition associated with one of a universal subscriber identity module (USIM) of the terminal.7.The method of claim 5, further comprising:transmitting, to the terminal, a temporary UE capability configuration based on the UE capability; andreceiving, from the terminal, the one or more gap requirements to the network entity in an UE assistance information (UAI) message.8.A terminal supporting a multi-subscriber identity module (MUSIM), the terminal comprising:a transceiver; andat least one processor configured to:receive, via the transceiver, a request to transmit a user equipment (UE) capability, from a network entity,determine whether the terminal is capable of reporting a change in one or more gap requirements, wherein the change in the one or more gap requirements is based on a MUSIM operation, andtransmit, via the transceiver, the UE capability of reporting the one or more gap requirements to the network entity.9.The terminal of claim 8, wherein the MUSIM operation includes a network state transition associated with one of a universal subscriber identity module (USIM) of the terminal.10.The terminal of claim 8, wherein the at least one processor is further configured to:receive, from the network entity, a temporary UE capability configuration based on the UE capability, andreport the one or more gap requirements to the network entity in an UE assistance information (UAI) message.11.The terminal of claim 8, wherein the one or more gap requirements comprise at least one of a measurement gap requirement, a Network Controlled Small Gap (NCSG) requirement, or an interruption requirement.12.The terminal of claim 8, wherein the UE capability of reporting the one or more gap requirements is determined based on one or more attributes comprising: musim-CapabilityRestriction, nr-NeedForGap-Reporting, nr-NeedForInterruptionReport and nr-NeedForGapNCSG-Reporting.13.A network entity, comprising:a transceiver; andat least one processor configured to:transmit, to a terminal via the transceiver, a request to transmit a user equipment (UE) capability, andreceive, from the terminal via the transceiver, the UE capability of reporting the one or more gap requirements to the network entity, in case that whether the terminal is capable of reporting a change in one or more gap requirements is determined, wherein the change in the one or more gap requirements is based on a MUSIM operation.14.The network entity of claim 13, wherein the MUSIM operation includes a network state transition associated with one of a universal subscriber identity module (USIM) of the terminal.15.The network entity of claim 13, wherein the at least one processor is further configured to:transmit, to the terminal via the transceiver, a temporary UE capability configuration based on the UE capability; andreceive, from the terminal via the transceiver, the one or more gap requirements to the network entity in an UE assistance information (UAI) message.

Images