Methods and systems for managing musim operations in wireless networks

Abstract

The disclosure relates to a 5G or 6G communication system and method for supporting a higher data transmission rate. The method comprises receiving, from a user equipment (UE), Multi University Subscriber Identity Module (MUSIM) measurement gap requirement information of a target band for the MUSIM and requirement information, and based on the reception of the measurement gap requirement information and the requirement information, determining whether to transmit a handover preparation message including the requirement information to the target base station.

Description

METHODS AND SYSTEMS FOR MANAGING MUSIM OPERATIONS IN WIRELESS NETWORKS

[0001] Embodiments disclosed herein relate to wireless communication networks, and more particularly to managing operation of Multi - Subscriber Identity Module (SIM) (MUSIM) devices in wireless communication networks.

[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] The present invention has been made to address at least the above problems and / or disadvantages and to provide at least the advantages described below. Accordingly, an aspect of the present invention provides a method and systems for managing MUSIM operations in wireless networks.

[0009] Accordingly, the embodiments herein provide a method for managing Multi - Subscriber Identity Module (SIM) (MUSIM) operations. The method comprises receiving, by a source Next Generation Node B (gNB), MUSIM NeedForGap requirements, and a first requirement. The method further comprises informing, by the source gNB, the first requirement to a target gNB, during handover preparation, if the MUSIM NeedForGap requirements have been received before the first requirement; and avoiding to inform, by the source gNB, the first requirement to the target gNB, during handover preparation, if the MUSIM NeedForGap requirements have been received after the first requirement.

[0010] Accordingly, the embodiments herein provide a Next Generation Node B (gNB) comprising a processing module; a memory; and a transceiver. The processing module is coupled with the memory, and the transceiver, and configured to receive MUSIM NeedForGap requirements, and a first requirement. The processor is further configured to inform the first requirement to a target gNB, during handover preparation, if the MUSIM NeedForGap requirements have been received before the first requirement; and avoid to inform the first requirement to the target gNB, during handover preparation, if the MUSIM NeedForGap requirements have been received after the first requirement.

[0011] Accordingly, the embodiments herein provide a method for managing Multi - Subscriber Identity Module (SIM) (MUSIM) operations. The method comprises receiving, by a first node, temporary capability restrictions from a User Equipment (UE); and informing, by the first node, the temporary capability restrictions to at least one second node, on expiry of a MUSIM wait timer.

[0012] Accordingly, the embodiments herein provide a node in a wireless communication network comprising a processing module; a memory; and a transceiver. The processing module is coupled with the memory, and the transceiver, and configured to receive temporary capability restrictions from a User Equipment (UE); and inform the temporary capability restrictions to at least one second node, on expiry of a MUSIM wait timer.

[0013] Accordingly, the embodiments herein provide a method performed by a source base station supporting a Multi Universal Subscriber Identity Module (MUSIM) in a communication system. The method comprising: receiving, from a user equipment (UE), MUSIM measurement gap requirement information of a target band for the MUSIM and requirement information, based on the reception of the measurement gap requirement information and the requirement information, determining whether to transmit a handover preparation message including the requirement information to the target base station.

[0014] Accordingly, the embodiments herein provide a method performed by a user equipment (UE) supporting a Multi Universal Subscriber Identity Module (MUSIM) in a communication system. The method comprising: generating MUSIM measurement gap requirement information of a target band for the MUSIM and requirement information; transmitting, to a source base station, the MUSIM measurement gap requirement information and the requirement information, wherein whether to transmit a handover preparation message including the requirement information from the source base station to the target base station is determined based on the reception of the measurement gap requirement information and the requirement information.

[0015] Accordingly, the embodiments herein provide a source base station supporting a Multi Universal Subscriber Identity Module (MUSIM) in a communication system. The source base station comprising: a transceiver; and a controller coupled with the transceiver, and configured to: receive, from a user equipment (UE), MUSIM measurement gap requirement information of a target band for the MUSIM and requirement information, based on the reception of the measurement gap requirement information and the requirement information, determine whether to transmit a handover preparation message including the requirement information to the target base station.

[0016] Accordingly, the embodiments herein provide a user equipment (UE) supporting a Multi Universal Subscriber Identity Module (MUSIM) in a communication system. The method comprising: generating MUSIM measurement gap requirement information of a target band for the MUSIM and requirement information; transmitting, to a source base station, the MUSIM measurement gap requirement information and the requirement information, wherein whether to transmit a handover preparation message including the requirement information from the source base station to the target base station is determined based on the reception of the measurement gap requirement information and the requirement information.

[0017] Advantages, and salient features of the invention will become apparent to those skilled in the art from the following detailed description, which, taken in conjunction with the annexed drawings, discloses exemplary embodiments of the invention. For more enhanced communication system, there is a need for method and systems for managing MUSIM operations in wireless networks.

[0018] Embodiments herein are illustrated in the accompanying drawings, throughout which like reference letters indicate corresponding parts in the various figures. The embodiments herein will be better understood from the following description with reference to the following illustratory drawings. Embodiments herein are illustrated by way of examples in the accompanying drawings, and in which:

[0019] FIG. 1 depicts a network, according to embodiments as disclosed herein;

[0020] FIG. 2 depicts a process for Temporary Capability restriction handling at network node after early indication, according to embodiments as disclosed herein;

[0021] FIG. 3 depicts a network, comprising of a source gNB, a target gNB, and one or more UEs, according to embodiments as disclosed herein;

[0022] FIG. 4 depicts a process for managing MUSIM operations during handover preparation, according to embodiments as disclosed herein;

[0023] FIG. 5 depicts the source gNB, according to embodiments as disclosed herein;

[0024] FIG. 6 depicts a network comprising at least one first node, and at least one second node, according to embodiments as disclosed herein;

[0025] FIG. 7A depicts example nodes, according to embodiments as disclosed herein;

[0026] FIG 7B depicts example nodes, according to embodiments as disclosed herein;

[0027] FIG. 8 is a flowchart depicting the process of managing Multi - Subscriber Identity Module (SIM) (MUSIM) operations in a dual connectivity scenario, according to embodiments as disclosed herein;

[0028] FIG. 9 depicts the node in a wireless communication network, according to embodiments as disclosed herein;

[0029] FIG. 10 is a flowchart depicting the process of performing RRCReestablishment, while the MUSIM wait timer is running, according to embodiments as disclosed herein;

[0030] FIG. 11 is a flowchart depicting the process of performing Inter-RAT handover, while the MUSIM wait timer is running, according to embodiments as disclosed herein; and

[0031] FIG. 12 is a flowchart depicting the process of performing one or more network operations for WaitTimer in dual connectivity, according to embodiments as disclosed herein.

[0032] Further, skilled artisans will appreciate that elements in the drawings are illustrated for simplicity and may not have necessarily been drawn to scale. For example, the flow charts illustrate the method in terms of the most prominent steps to improve understanding of aspects of the present invention. Furthermore, in terms of the construction of the device, one or more components of the device may have been represented in the drawings by conventional symbols, and the drawings may show only those specific details that are pertinent to understanding the embodiments of the present invention so as not to obscure the drawings with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.

[0033] For the purpose of promoting an understanding of the principles of the invention, reference will now be made to the embodiment illustrated in the drawings and specific language will be used to describe the same. It will nevertheless be understood that no limitation of the scope of the invention is thereby intended, such alterations and further modifications in the illustrated system, and such further applications of the principles of the invention as illustrated therein being contemplated as would normally occur to one skilled in the art to which the invention relates.

[0034] It will be understood by those skilled in the art that the foregoing general description and the following detailed description are explanatory of the invention and are not intended to be restrictive thereof.

[0035] Reference throughout this specification to "an aspect", "another aspect" or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrase "in an embodiment", "in another embodiment" and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment.

[0036] The terms "comprises", "comprising", or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a process or method that comprises a list of steps does not include only those steps but may include other steps not expressly listed or inherent to such process or method. Similarly, one or more devices or sub-systems or elements or structures or components preceded by "comprises... a" does not, without more constraints, preclude the existence of other devices or other sub-systems or other elements or other structures or other components or additional devices or additional sub-systems or additional elements or additional structures or additional components.

[0037] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skilled in the art to which this invention belongs. The system, methods, and examples provided herein are illustrative only and not intended to be limiting.

[0038] Due to popularity of Multi - Subscriber Identity Module (SIM) (MUSIM) devices that host more than one 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, and so on. The MUSIM User Equipments (UEs) were operating without network control by creating arbitrary gaps till 3rd Generation Partnership Project (3GPP) decided to introduce support for MUSIM device operations in Release 17.

[0039] From Release 17, a connected Universal SIM (USIM) (USIM as referred to herein means a radio protocol stack associated with the UE) in a MUSIM device can notify the connected mode network on network switching for MUSIM operations. There are two types of network switching that is supported. In a first type of network switching, a 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 the gap measurements from its network for the MUSIM operations like listening for paging or performing measurements in the idle USIM.

[0040] In release 17, the MUSIM UE uses a Radio Resource Control (RRC) UE Assistance Information (UAI) procedure to request for gaps or to notify about leaving. The network (i.e., gNB) configures the UE, as to whether it can provide the assistance information for MUSIM gaps or MUSIM Leave using otherConfig in RRC messages. 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.

[0041] UE Capabilities:

[0042] In a technology like 5G New Radio (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 (for example, 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 signalling 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. If supported by the UE and the network, the UE may provide an ID in Non-Access Stratum (NAS) signalling that represents its radio capabilities for one or more Radio Access Technologies (RATs) in order to reduce signalling 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.

[0043] 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 a Centralized Unit (CU), and a Distributed Unit (DU).

[0044] In NR, Radio Resource Control (RRC) can be in one of the three states; RRC_IDLE, RRC_INACTIVE or RRC_CONNECTED. An RRC_CONNECTED UE is in CM-CONNECTED (i.e., connected to 5G Core network) and can do unicast and multicast / broadcast traffic with the network. In the NR control plane protocol stack, lower layers for RRC include PDCP, RLC, MAC, and physical layers. The network stores the UE Access Stratum (AS) context, knows the UE at cell level, and controls the UE mobility. The UE may perform measurements and report to the network, provides channel quality and feedback information, and so on.

[0045] RRC_INACTIVE is a state where a UE remains in CM-CONNECTED and can move within an area configured by NG-RAN (5G RAN comprising of gNB(s)) without notifying Next Generation Radio Access Network (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 core network is kept in RRC_INACTIVE, the UE can transition immediately to RRC connected state and perform data transfer with the core network / applications. The UE initiates a transition to RRC_CONNECTED from RRC_INACTIVE by sending RRC resume request.

[0046] In RRC_IDLE, the UE or the gNB does not store any AS context. The UE is in CM_IDLE (there is no connection to core network). The UE sets up a new connection by sending a RRC Setup Request message and the gNB sends a RRC setup message to transition to RRC connected. The UE and the NW (both the RAN and the core network) exchange messages to move the UE to CM_CONNECTED. A UE in RRC_CONNECTED may send a power head room to the network according to the TS 38.321 and other relevant 3GPP specs.

[0047] 3GPP may also consider LowerLayerTriggered Mobility for performing handover.

[0048] A HandoverPreparationInformation message is used to transfer the NR RRC information used by the target gNB during handover preparation or UE context retrieval, for example, in case of resume or re-establishment, including UE capability information. This message is also used for transferring the information between the CU and the DU. The HandoverPreparationInformation field descriptions are as follows:

[0049] as-Context: Local RAN context required by the target gNB or DU.

[0050] rrm-Config: Local RAN context used mainly for RRM purposes.

[0051] sourceConfig: The radio resource configuration as used in the source cell.

[0052] ue-CapabilityRAT-List: The UE radio access related capabilities concerning RATs supported by the UE. A gNB that retrieves MRDC related capability containers ensures that the set of included MRDC containers is consistent with respect to the feature set related information.

[0053] ue-InactiveTime: A duration during which the UE has not received or transmitted any user data. Thus, the timer is still running in case; for example, the UE measures the neighbour cells for the HO purpose. Value s1 corresponds to 1 second, s2 corresponds to 2 seconds and so on. Value min1 corresponds to 1 minute, value min1s20 corresponds to 1 minute and 20 seconds, value min1s40 corresponds to 1 minute and 40 seconds and so on. Value hr1 corresponds to 1 hour, hr1min30 corresponds to 1 hour and 30 minutes and so on.

[0054] The AS-Config field descriptions are as follows:

[0055] rrcReconfiguration: Contains the RRCReconfiguration configuration as generated entirely by the MN. If the TMGI-r17 is included in the MRB-ToAddMod-r17 in the RadioBearerConfig, the plmn-Index is replaced by the PLMN ID, if needed.

[0056] sdt-Config: Contains the IE SDT-Config as generated entirely by the last serving gNB. This field is only used during the SDT procedure with UE context relocation as defined in TS 38.300, clause 18.2.

[0057] sourceRB-SN-Config: Contains the IE RadioBearerConfig as generated entirely by the SN. This field is only used when the UE is configured with SN terminated RB(s).

[0058] sourceSCG-Configured: Value true indicates that the UE is configured with NR or EUTRA SCG in source configuration. The field is only used in NR-DC and NE-DC and is included only if the fields sourceSCG-NR-Config and sourceSCG-EUTRA-Config are absent.

[0059] sourceSCG-EUTRA-Config: Contains the current dedicated SCG configuration in RRCConnectionReconfiguration message as specified in TS 36.331, and generated entirely by the SN. In this version of the specification, the E-UTRA RRCConnectionReconfiguration message can only include the field scg-Configuration . This field is only used in NE-DC.

[0060] sourceSCG-NR-Config: Contains the current dedicated SCG configuration in RRCReconfiguration message as generated entirely by the SN. In this version of the specification, the RRCReconfiguration message can only include fields secondaryCellGroup and measConfig. This field is only used in NR-DC.

[0061] The AS-Config field descriptions are as follows:

[0062] configRestrictInfoDAPS: Includes fields for which source cell explicitly indicates the restriction to be observed by target cell during DAPS handover.

[0063] mbsInterestIndication: Includes the information last reported by the UE in the NR MBSInterestIndication message, where the plmn-Index (if included by the UE in tmgi) is replaced by the PLMN ID, if needed. A TMGI for which the plmn-Index points to a non-serving SNPN is removed from the NR MBSInterestIndication message.

[0064] needForGapsInfoNR: Includes measurement gap requirement information of the UE for NR target bands.

[0065] selectedBandCombinationSN: Indicates the band combination selected by SN in (NG)EN-DC, NE-DC, and NR-DC.

[0066] sidelinkUEInformationEUTRA: This field includes SidelinkUEInformation IE as specified in TS 36.331.

[0067] sidelinkUEInformationNR: This field includes SidelinkUEInformationNR IE.

[0068] ueAssistanceInformation: Includes for each UE assistance feature the information last reported by the UE, if any.

[0069] ueAssistanceInformationSCG: Includes for each UE assistance feature associated with the SCG, the information last reported by the UE in the NR UEAssistanceInformation message for the SCG, if any.

[0070] Framework for supporting capability change:

[0071] 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 UE-A and UE-B can be connected (RRC_CONNECTED) at the same time. Both the 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 (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).

[0072] Consider 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. The 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, measurement gaps requirements (needforgaps / needforgapsorncsg) related information in UE-A to facilitate MUSIM operations, and so on. Measurement gap requirements (such as MUSIM-NeedForGaps in NR) reported due to MUSIM operations is referred to as MUSIM NeedForGap requirements herein. The change can be temporary capability restrictions or removal of temporary capability restrictions.

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

[0074] If the capability of 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 can be 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 etc.

[0075] The NW-A may configure UE-A on whether it can inform changed capabilities; for example, through "otherConfig" in the RRC Reconfiguration message. In other words, through "otherConfig", the 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, the 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.

[0076] The 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 example, the filter may be a band filter. 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.

[0077] 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, and so on. 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.

[0078] The static or dynamic capability signaling reported by UE may include the following: number of Rx links; number of Tx links, maximum number of Multiple-input, multiple-output (MIMO)　layers, 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, UL or DL TDD configuration, DRX configuration on NW B, measurement configuration on NW-B, frequencies which are supported or the frequencies which are restricted, and so on.

[0079] In case of dual connectivity, the 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.

[0080] The network utilizes the updated capability received from the UE and reconfigures the UE with updated parameters. The 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.

[0081] The temporary capability restriction field descriptions are as follows:

[0082] maxCandidateBandIndex: Indicate the maximum number of band entry index for MUSIM capability restriction reporting.

[0083] minSchedulingOffsetPreference: Indicates the UE's preferences on minimumSchedulingOffset of cross-slot scheduling for power saving.

[0084] minSchedulingOffsetPreferenceExt: Indicates the UE's preferences on minimumSchedulingOffset of cross-slot scheduling for power saving for SCS 480 kHz and / or 960 kHz.

[0085] musim-Cell-SCG-ToReleasedList: Indicates the UE's preference on serving cell(s) and / or SCG to be released for MUSIM operation.

[0086] musim-CellToAffectList-r18: Indicates the UE's preference on the temporary capability restriction on the serving cell(s) for MUSIM operation.

[0087] musim-AffectedBandsList: Indicates the UE's preference on the band(s) and / or combination(s) of bands with restricted capability for MUSIM operation.

[0088] musim-capabilityRestricted: Indicates the UE's preference on the temporary capability restriction on the band(s) and / or combination(s) of bands for MUSIM operation.

[0089] musim-AvoidedBandsList: Indicates the UE's preference on band(s) and / or combination(s) of bands to be avoided or MUSIM purpose.

[0090] musim-GapPreferenceList: Indicates the UE's MUSIM gap preference and related MUSIM gap configuration, as defined in TS 38.133 clause 9.1.10.

[0091] musim-GapKeepPreference: Indicates the UE's preference to keep all collided gaps for requested MUSIM gap(s). If the field is absent, the collided MUSIM gaps with lower priority shall be dropped.

[0092] musim-GapPriorityPreferenceList: Indicates the UE's MUSIM gap priority preference for periodic MUSIM gaps as specified in TS 38.133. If the UE includes musim-GapPriorityPreferenceList-r18, it includes the same number of entries, and listed in the same order for periodic gaps, as in musim-GapPreferenceList-r17.

[0093] musim-MaxCC: Indicates the UE maximum number of CCs per DL / UL.

[0094] musim-NeedForGapsInfoNR: This field is used to indicate the measurement gap requirement information of the UE for NR target bands when in MUSIM operation. The field is not included in NR-DC.

[0095] musim-CandidateBandList: A list of bands for which the UE is requested to provide information on temporary restricted capabilities for MUSIM operation

[0096] musim-GapAssistanceConfig: Configuration for the UE to report assistance information for gap preference.

[0097] musim-GapPriorityAssistanceConfig: Indicates the UE is allowed to provide MUSIM assistance information for gap(s) priority or MUSIM gaps keep preference.

[0098] musim-GapProhibitTimer: Prohibit timer for MUSIM assistance information reporting for gap preference.

[0099] musim-LeaveAssistanceConfig: Configuration for the UE to report assistance information for leaving RRC_CONNECTED for MUSIM purpose.

[0100] musim-LeaveWithoutResponseTimer: Indicates the timer for the UE to enter RRC_IDLE for MUSIM purpose as defined in clause 5.3.8.6.

[0101] musim-ProhibitTimer: Indicates the prohibit timer for UE temporary restricted capabilities for MUSIM operation. Value in milliseconds. Value ms0 means prohibit timer is set to 0 milliseconds, value ms10 means prohibit timer is set to 10 milliseconds and so on.

[0102] musim-WaitTimer: Indicates the wait timer for UE temporary restricted capabilities for MUSIM operation. Value in milliseconds. Value ms10 means wait timer is set to 10 milliseconds, value ms20 means wait timer is set to 20 milliseconds and so on.

[0103] The UE behavior for Multi sim operations for dual active is captured in TS 38.331.

[0104] The UE shall further set the contents of the UEAssistanceInformation message.

[0105] The UE can apply the temporary UE capability restriction in accordance with the UE capability restriction indicated in the last transmission of the UEAssistanceInformation message including musim-CapRestriction, as specified in 5.7.4.3.

[0106]

[0107] Table 1

[0108] T348 is a 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.

[0109] Dual connectivity or more technically multi-radio dual connectivity is specified by 3GPP in specifications such as TS 37.340. NG-RAN supports Multi-Radio Dual Connectivity (MR-DC) operation whereby a UE in RRC_CONNECTED state 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 access and the other one providing either E-UTRA (Evolved UMTS Terrestrial Radio Access) or NR access. One node acts as a master node (MN) and at least one other node acts as a 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 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. The primary cell of a master or secondary cell group is referred to herein as a SpCell. The SpCell of a master cell group is called PCell, while the 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 the Secondary Cell Group (SCG). In MR-DC, the frame timing and SFN between the cells in MCG and SCG may not be aligned.

[0110] The MN may inform the received temporary capability restriction and the band filter it has configured to the SN.

[0111] The field descriptions of the ASN.1 structure for informing the same from TS 38.331 are as follows:

[0112] musim-CapRestrictionInfo: Indicates the UE's preference on SCell(s) to be released, band(s) or combination(s) of bands with restricted capability, or band(s) or band combination(s) to be avoided for UE temporary capabilities restriction purpose with the musim-candidateBandList-r18 only for musim-AffectedBandsList-r18 and musim-AvoidedBandsList -r18.

[0113] The UE informs the network whether it supports temporary capability restrictions (providing MUSIM assistance information with temporary capability restriction) using an optional per-UE capability bit without any FDD-TDD differentiation or FR1-FR2 differentiation (table 2).

[0114]

[0115] Table 2

[0116] The NeedForGapsConfigNR IE contains configuration related to the reporting of measurement gap requirement information.

[0117] The NeedForGapsInfoNR field descriptions are as follows:

[0118] intraFreq-needForGap: Indicates the measurement gap requirement information for NR intra-frequency measurement.

[0119] interFreq-needForGap: Indicates the measurement gap requirement information for NR inter-frequency measurement.

[0120] The NeedForGapsInfoNR field descriptions are as follows:

[0121] servCellId: Indicates the serving cell which contains the target SSB (associated with the initial DL BWP) to be measured.

[0122] gapIndicationIntra: Indicates whether measurement gap is required for the UE to perform intra-frequency SSB based measurements on the concerned serving cell. Value gap indicates that a measurement gap is needed if any of the UE configured BWPs (except the BWP(s) configured with servingCellMO associated with NCD-SSB) do not contain the frequency domain resources of the SSB associated to the initial DL BWP (CD-SSB). Value no-gap indicates a measurement gap is not needed to measure the SSB associated to the initial DL BWP (CD-SSB) for all configured BWPs (except the BWP(s) configured with servingCellMO associated with NCD-SSB), no matter the SSB is within the configured BWP or not. This field shall be set to 'no-gap' for the corresponding band(s) where bwpOperationMeasWithoutInterrupt-r18 is supported by the UE.

[0123] The NeedForGapsNR field descriptions are as follows:

[0124] bandNR: Indicates the NR target band to be measured.

[0125] gapIndication: Indicates whether measurement gap is required for the UE to perform SSB based measurements on the concerned NR target band while NR-DC or NE-DC is not configured. The UE determines this information based on the resultant configuration of the RRCReconfiguration or RRCResume message that triggers this response. Value gap indicates that a measurement gap is needed, value no-gap indicates a measurement gap is not needed.

[0126] The NeedForGapNCSG-ConfigEUTRA IE contains configuration related to the reporting of measurement gap and NCSG requirement information.

[0127] The NeedForGapNCSG-ConfigNR field descriptions are as follows:

[0128] requestedTargetBandFilterNCSG-NR: Indicates the target NR bands that the UE is requested to report the measurement gap and NCSG requirement information.

[0129] The NeedForGapNCSG-InfoEUTRA IE indicates whether measurement gap or NCSG is required for the UE to perform measurements on an E UTRA target band while NR-DC or NE-DC is not configured.

[0130] The NeedForGapNCSG-InfoEUTRA field descriptions are as follows:

[0131] needForNCSG-EUTRA: Indicates the measurement gap and NCSG requirement information for E-UTRA measurement.

[0132] The NeedForNCSG-EUTRA field descriptions are as follows:

[0133] bandEUTRA: Indicates the E UTRA target band to be measured.

[0134] gapIndication: Indicates whether measurement gap or NCSG is required for the UE to perform measurements on the concerned E UTRA target band while NR-DC or NE-DC is not configured. The UE determines this information based on the resultant configuration of the RRCReconfiguration message or RRCResume message that triggers this response. Value gap indicates that a measurement gap is needed, value 'ncsg' indicates that NCSG is needed, value 'nogap-noncsg' indicates that a measurement gap, or a NCSG is not needed. Value 'nogap-noncsg' also indicates that interruption is not needed.

[0135] The NeedForGapNCSG-InfoNR IE indicates whether measurement gap or NCSG is required for the UE to perform SSB based measurements on an NR target band while NR-DC or NE-DC is not configured.

[0136] The NeedForGapNCSG-InfoNR field descriptions are as follows:

[0137] intraFreq-needForNCSG: Indicates the measurement gap and NCSG requirement information for NR intra-frequency measurement.

[0138] interFreq-needForNCSG: Indicates the measurement gap and NCSG requirement information for NR inter-frequency measurement.

[0139] The NeedForNCSG-IntraFreq field descriptions are as follows:

[0140] servCellId: Indicates the serving cell which contains the target SSB (associated with the initial DL BWP) to be measured.

[0141] gapIndicationIntra: Indicates whether measurement gap or NCSG is required for the UE to perform intra-frequency SSB based measurements on the concerned serving cell. Value gap indicates that a measurement gap is needed if any of the UE configured BWPs (except the BWP(s) configured with servingCellMO associated with NCD-SSB) do not contain the frequency domain resources of the SSB associated to the initial DL BWP (CD-SSB). Value ncsg indicates that a NCSG is needed if any of the UE configured BWPs do not contain the frequency domain resources of the SSB associated to the initial DL BWP. Value nogap-noncsg indicates that neither a measurement gap nor a NCSG is needed to measure the SSB associated to the initial DL BWP (CD-SSB) for all configured BWPs (except the BWP(s) configured with servingCellMO associated with NCD-SSB), no matter the SSB is within the configured BWP or not. This field shall be set to 'nogap-noncsg' for the corresponding band(s) where bwpOperationMeasWithoutInterrupt-r18 is supported by the UE. Value nogap-noncsg also indicates interruption is not needed.

[0142] The NeedForNCSG-NR field descriptions are as follows:

[0143] bandNR: Indicates the NR target band to be measured.

[0144] gapIndication: Indicates whether measurement gap or NCSG is required for the UE to perform SSB based measurements on the concerned NR target band while NR-DC or NE-DC is not configured. The UE determines this information based on the resultant configuration of the RRCReconfiguration or RRCResume message that triggers this response. Value gap indicates that a measurement gap is needed, value ncsg indicates that a NCSG is needed, and value nogap-noncsg indicates neither a measurement gap nor a NCSG is needed. Value nogap-noncsg also indicates interruption is not needed.

[0145] The NeedForInterruptionInfoNR IE indicates whether interruption is needed for the UE to perform SSB based measurements on an NR target band without measurement gap while NR-DC or NE-DC is not configured.

[0146] The NeedForInterruptionInfoNR field descriptions are as follows:

[0147] intraFreq-needForInterruption: Indicates the interruption requirement information for NR intra-frequency measurement. Each entry in the list is associated to the entry in list intraFreq-needForGap-r16 with the same index. This field shall be set to no-gap-no-interruption for the corresponding band(s) where bwpOperationMeasWithoutInterrupt-r18 is supported by the UE.

[0148] interFreq-needForInterruption: Indicates the interruption requirement information for NR inter-frequency measurement. Each entry in the list is associated to the entry in list interFreq-needForGap-r16 with the same index.

[0149] The NeedForInterruptionNR field descriptions are as follows:

[0150] interruptionIndication: Indicates whether interruption is needed for the UE to perform SSB based measurements without measurement gap. Value no-gap-with-interruption indicates that interruption is needed. Value no-gap-no-interruption indicates interruption is not needed.

[0151] v18.0.0 of 3gpp specifications such as TS 38.331,TS 38.300,TS 38.306,TS 38.321 can be considered as the relevant background.

[0152] Consider the case of a MUSIM UE with two USIMs (i.e., two UEs in same MUSIM device). UE-A (USIM-A) is moving from RRC_IDLE or RRC_INACTIVE state RRC-CONNECTED state with NW-A. If the UE capability (UE capability refers to the UE radio access capabilities such as, but not limited to, maximum number of MIMO layers, supported bands or band combinations or frequencies, and so on, which may be changed, and whose restriction or removal of restriction which may be reported for the MUSIM purpose) of UE-A is (temporarily) restricted due to MUSIM purpose, the UE-A informs NW-A that its capability is (temporarily) restricted due to MUSIM purpose in messages (such as, but not limited to, RRCSetupComplete or RRCResumeComplete) or by using a separate logical channel identifier while sending RRCResumeRequest or RRCResumeRequest1. The UE-A further reports the (temporary) restrictions in capabilities using messages like UAI, after being configured by the network. The UE-A can report UAI only after the security is activated and only after the network has configured the UE-A to do so through other RRC messages (such as, but not limited to,RRCReconfiguration). Further, there may be a filter (which can be referred to herein as musim-CapRestrictionFilter) configured by the NW-A, and the UE-A will report the (temporary) capability restriction according to the filter. For example, UE-A may report the restricted bands or restricted frequencies or restricted band combinations, or other information if those bands / frequencies / band combinations are included in the musim-CapRestrictionFilter.

[0153] According to the current system, the UE indicates (temporary) restriction in capabilities or removal of (temporary) restriction in capabilities only when there is a change in (temporary) restrictions after sending UAI or if there is a (temporary) restriction in capabilities after the configuration, before reporting the (temporary) restrictions even once.

[0154] In a scenario for UE-A (which has indicated to the network that there is a temporary capability restriction while moving to RRC_CONNECTED), the restriction in capabilities may be removed by the time, the UE-A sends UAI to report temporary capability restrictions. In another scenario, the UE-A may not be required to report its restricted capabilities according to the configured filter by NW-A.

[0155] The NW-A may not be able to configure UE-A with any advanced capabilities like carrier aggregation, dual connectivity, conditional handover, lower layer triggered mobility (LTM) inter-frequency measurements or measurement gaps etc.in these scenarios according to the current system.

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

[0157] The principal object of embodiments herein is to disclose methods and systems for configuring a UE (which has indicated to the network that there is a temporary capability restriction while moving to RRC_CONNECTED) with advanced capabilities (such as, but not limited to, carrier aggregation, dual connectivity, conditional handover, lower layer triggered mobility (LTM) inter-frequency measurements measurement gaps, and so on).

[0158] Another object of embodiments herein is to disclose methods and systems for communicating MUSIM gap configuration and temporary capability restrictions in CG-Config / CG-ConfigInfo from MN to SN or CU to DU.

[0159] Another object of embodiments herein is to disclose methods and systems for handling measurement gap requirements due to MUSIM operations.

[0160] Accordingly, the embodiments herein provide a method for managing Multi - Subscriber Identity Module (SIM) (MUSIM) operations. The method comprises receiving, by a source Next Generation Node B (gNB), MUSIM NeedForGap requirements, and a first requirement. The method further comprises informing, by the source gNB, the first requirement to a target gNB, during handover preparation, if the MUSIM NeedForGap requirements have been received before the first requirement; and avoiding to inform, by the source gNB, the first requirement to the target gNB, during handover preparation, if the MUSIM NeedForGap requirements have been received after the first requirement.

[0161] Accordingly, the embodiments herein provide a Next Generation Node B (gNB) comprising a processing module; a memory; and a transceiver. The processing module is coupled with the memory, and the transceiver, and configured to receive MUSIM NeedForGap requirements, and a first requirement. The processor is further configured to inform the first requirement to a target gNB, during handover preparation, if the MUSIM NeedForGap requirements have been received before the first requirement; and avoid to inform the first requirement to the target gNB, during handover preparation, if the MUSIM NeedForGap requirements have been received after the first requirement.

[0162] Accordingly, the embodiments herein provide a method for managing Multi - Subscriber Identity Module (SIM) (MUSIM) operations. The method comprises receiving, by a first node, temporary capability restrictions from a User Equipment (UE); and informing, by the first node, the temporary capability restrictions to at least one second node, on expiry of a MUSIM wait timer.

[0163] Accordingly, the embodiments herein provide a node in a wireless communication network comprising a processing module; a memory; and a transceiver. The processing module is coupled with the memory, and the transceiver, and configured to receive temporary capability restrictions from a User Equipment (UE); and inform the temporary capability restrictions to at least one second node, on expiry of a MUSIM wait timer.

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

[0165] The embodiments herein and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein may be practiced and to further enable those of skill in the art to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.

[0166] For the purposes of interpreting this specification, the definitions (as defined herein) will apply and whenever appropriate the terms used in singular will also include the plural and vice versa. It is to be understood that the terminology used herein is for the purposes of describing particular embodiments only and is not intended to be limiting. The terms "comprising", "having" and "including" are to be construed as open-ended terms unless otherwise noted.

[0167] The words / phrases "exemplary", "example", "illustration", "in an instance", "and the like", "and so on", "etc.", "etcetera", "e.g.," , "i.e.," are merely used herein to mean "serving as an example, instance, or illustration." Any embodiment or implementation of the present subject matter described herein using the words / phrases "exemplary", "example", "illustration", "in an instance", "and the like", "and so on", "etc.", "etcetera", "e.g.," , "i.e.," is not necessarily to be construed as preferred or advantageous over other embodiments.

[0168] Embodiments herein may be described and illustrated in terms of blocks which carry out a described function or functions.　These blocks, which may be referred to herein as managers, units, modules, hardware components or the like, are physically implemented by analog and / or digital circuits such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuits and the like, and may optionally be driven by a firmware. The circuits may, for example, be embodied in one or more semiconductor chips, or on substrate supports such as printed circuit boards and the like.　The circuits constituting a block may be implemented by dedicated hardware, or by a processor (e.g., one or more programmed microprocessors and associated circuitry), or by a combination of dedicated hardware to perform some functions of the block and a processor to perform other functions of the block.　Each block of the embodiments may be physically separated into two or more interacting and discrete blocks without departing from the scope of the disclosure.　Likewise, the blocks of the embodiments may be physically combined into more complex blocks without departing from the scope of the disclosure.

[0169] It should be noted that elements in the drawings are illustrated for the purposes of this description and ease of understanding and may not have necessarily been drawn to scale. For example, the flowcharts / sequence diagrams illustrate the method in terms of the steps required for understanding of aspects of the embodiments as disclosed herein. Furthermore, in terms of the construction of the device, one or more components of the device may have been represented in the drawings by conventional symbols, and the drawings may show only those specific details that are pertinent to understanding the present embodiments so as not to obscure the drawings with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein. Furthermore, in terms of the system, one or more components / modules which comprise the system may have been represented in the drawings by conventional symbols, and the drawings may show only those specific details that are pertinent to understanding the present embodiments so as not to obscure the drawings with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.

[0170] The accompanying drawings are used to help easily understand various technical features and it should be understood that the embodiments presented herein are not limited by the accompanying drawings. As such, the present disclosure should be construed to extend to any modifications, equivalents, and substitutes in addition to those which are particularly set out in the accompanying drawings and the corresponding description. Usage of words such as first, second, third etc., to describe components / elements / steps is for the purposes of this description and should not be construed as sequential ordering / placement / occurrence unless specified otherwise.

[0171] The embodiments herein achieve methods and systems for configuring a UE (which has indicated to the network that there is a temporary capability restriction while moving to RRC_CONNECTED) with advanced capabilities (such as, but not limited to, carrier aggregation, dual connectivity, conditional handover, lower layer triggered mobility (LTM) inter-frequency measurements measurement gaps, and so on). Referring now to the drawings, and more particularly to FIGS. 1 through 12, where similar reference characters denote corresponding features consistently throughout the figures, there are shown embodiments.

[0172] In an embodiment herein, consider a network NW-A 101 connected to at least one UE; for example, UE-A 102 (as depicted in FIG. 1). If the UE-A 102 has informed the NW-A 101 that it has a (temporary) capability restriction (such as, but not limited to, MUSIM capability restriction while transitioning to RRC_CONNECTED (through RRC Setup or RRC Resume procedures)), the NW-A 101 configures the UE 102 with configuration for reporting the temporary capability restrictions (such as, but not limited to, otherConfig including the musim-CapabilityRestrictionConfig in NR)), and waits for the UE 102 to report the restricted capabilities before configuring SCells, SCG, higher order MIMO, or the number of Rx / Tx layers, wherein such configurations which may be restricted by temporary capability restrictions, for a certain duration. The NW-A 101 may also start a timer (an internal timer), wherein the timer may be stopped once the NW-A receives a User Equipment (UE) Assistance Information (UAI) requesting for temporary capability restrictions. In an example herein, the timer may be 1 second. In another example herein, the timer value can be 2 seconds, 3 seconds 5 seconds, a few milli seconds, and so on. Once the timer expires, the NW-A 101 may stop waiting for temporary capability restrictions and configure the UE 102 with configurations according to the full capabilities (i.e., the UE capabilities received using UE Capability reporting procedure such as, but not limited to, UECapabilityInformation). The NW-A 101 can configure the UE-A 102 with the configuration corresponding to the full capabilities, if it does not receive temporary capability restriction (UAI containing temporary capability restriction) after a certain duration of configuring the UE to report temporary capability restriction; i.e., the NW-A 101 does not consider an early indication for the temporary capability restriction if UAI containing temporary capability restriction is not received within a certain duration (such as 1 second or a few seconds or a few milliseconds as per the NW-A implementation).

[0173] FIG. 2 depicts a process for Temporary Capability restriction handling at network node after early indication. In step 201, the NW-A 101 receives an early indication of MUSIM temporary capability restrictions from a UE 102 in one of a RRCSetupComplete or RRCResumeComplete message. In step 202, the NW-A 101 configures the UE 102 to report MUSIM temporary capability restriction, and avoids configuring the UE 102 with configurations which may be reported as restricted. In step 203, the NW-A 101 waits for a message with request for temporary capability restrictions for a specific duration, T. In step 204, the NW-A 101 configures the UE 102 with configurations which may be reported as restricted if the request for temporary capability restriction is not received within the duration, T. The various actions in method 200 may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some actions listed in FIG. 2 may be omitted.

[0174] FIG. 3 depicts a network, comprising of a source gNB, a target gNB, and one or more UEs. Consider that a source gNB 301 has received measurement gap requirements from the UE 102 through NeedForGapsInfoNR (or such IE) in the RRCSetupComplete / RRCReconfigurationComplete / RRCResumeComplete / HandoverPreparationInformation, and musim-NeedForGapsInfoNR (or such IE) in UE Assistance Information includes both the measurement gap requirements in the HandoverPreparationInformation. The source gNB 301 also informs a target gNB 302 which of these is received first / last. The source gNB 301 may include a flag in HandoverPreparationInformation which indicates whether NeedForGapsInfoNR, or musim-NeedForGapsInfoNR has been received first. The source gNB 301 may include a flag in HandoverPreparationInformation which indicates whether NeedForGapsInfoNR, or musim-NeedForGapsInfoNR has been received last.

[0175] The source gNB 301 may include an IE (an enum) in HandoverPreparationInformation which indicates that the included NeedForGapsInfoNR is received before the included musim-NeedForGapsInfoNR.

[0176] The source gNB 301 may include an IE (an enum) in HandoverPreparationInformation which indicates that the included NeedForGapsInfoNR is received after the included musim-NeedForGapsInfoNR.

[0177] In an embodiment herein, if the source gNB 301 has received needForGapsInfoNR (in RRCReconfigurationComplete, or RRCResumeComplete, or HandoverPreparationInformation) before receiving musim-NeedForGapsInfoNR in Ue Assistance Information, the source gNB 301 can include the musim-NeedForGapsInfoNR in HandoverPreparationInformation message, and exclude needForGapsInfoNR received in RRCResumeComplete, or RRCReconfigurationComplete, or HandoverPreparationInformation.

[0178] In an embodiment herein, if the source gNB 301 has received NeedForGapNCSG-InfoNR (in RRCReconfigurationComplete, or RRCResumeComplete, or HandoverPreparationInformation) before receiving musim-NeedForGapsInfoNR in Ue Assistance Information, the source gNB 301 can exclude NeedForGapNCSG-InfoNR (received in RRCResumeComplete, or RRCReconfigurationComplete, or HandoverPreparationInformation) in the HandoverPreparationInformation send to the target gNB 302.

[0179] In an embodiment herein, if the source gNB 301 has received NeedForGapNCSG-InfoNR (in RRCReconfigurationComplete, or RRCResumeComplete, or HandoverPreparationInformation) after receiving musim-NeedForGapsInfoNR in Ue Assistance Information, the source gNB 301 can include NeedForGapNCSG-InfoNR (received in RRCResumeComplete, or RRCReconfigurationComplete, or HandoverPreparationInformation) in the HandoverPreparationInformation send to the target gNB 302.

[0180] In an embodiment herein, if the source gNB 301 has received needForInterruptionInfoNR (in RRCReconfigurationComplete, or RRCResumeComplete, or HandoverPreparationInformation) before receiving musim-NeedForGapsInfoNR in Ue Assistance Information, the source gNB 301 can exclude the needForInterruptionInfoNR (received in RRCResumeComplete, or RRCReconfigurationComplete, or HandoverPreparationInformation) in the HandoverPreparationInformation send to the target gNB 302.

[0181] In an embodiment herein, if the source gNB 301 has received needForInterruptionInfoNR (in RRCReconfigurationComplete, or RRCResumeComplete, or HandoverPreparationInformation) after receiving musim-NeedForGapsInfoNR in Ue Assistance Information, the source gNB 301 can include needForInterruptionInfoNR (received in RRCResumeComplete, or RRCReconfigurationComplete, or HandoverPreparationInformation) in the HandoverPreparationInformation send to the target gNB 302.

[0182] In an embodiment herein, if the UE 102 requires NCSG (network controlled small gaps) for performing interfrequency measurements (due to MUSIM operations), and the UE 102 has not informed the network previously that the UE 102 requires NCSG for performing those interfrequency measurements, the UE 102 can avoid informing the network that it needs gaps for performing those measurements using musim-needForGapsInfoNR and inform the network that the UE 102 requires NCSG later in a RRCReconfigurationComplete. The source gNB 301 may not configure the UE with gaps or NCSG for performing those interfrequency measurements till it receives the RRCReconfigurationComplete, and the UE 102 may skip performing these measurements during this interval.

[0183] In an embodiment herein, if the UE 102 requires NCSG (network controlled small gaps) for performing interfrequency measurements due to MUSIM operations and the UE 102 has not informed the network previously that the UE 102 requires NCSG for performing those intrafrequency measurements, the UE 102 can avoid informing the network that it needs gaps for performing those measurements using musim-needForGapsInfoNR and inform the network that UE 102 requires NCSG later in a RRCReconfigurationComplete. The source gNB 301 may not configure the UE 102 with gaps or NCSG for performing those intrafrequency measurements till it receives the RRCReconfigurationComplete, and the UE 102 may skip performing these measurements during this interval.

[0184] In an embodiment herein, if the UE 102 requires interruptions for performing interfrequency measurements due to MUSIM operations and the UE 102 has already informed the network previously that the UE 102 requires interruptions for performing those interfrequency measurements, the UE 102 can inform the network that it needs gaps for performing those measurements using musim-NeedForGapsInfoNR-r18 in the UAI. The source gNB 301 may configure the UE 102 with measurement gaps for those frequencies.

[0185] In an embodiment herein, if the UE 102 requires interruptions for performing interfrequency measurements due to MUSIM operations and the UE 102 has already informed the network previously that the UE requires interruptions for performing those interfrequency measurements, the UE can inform the network that it needs gaps for performing those measurements using musim-NeedForGapsInfoNR-r18 in the UAI. The source gNB 301 can configure the UE 102 with measurement gaps for those frequencies.

[0186] In an embodiment herein, if the UE 102 requires interruptions for performing interfrequency measurements due to MUSIM operations and the UE 102 has not informed the network previously that UE 102 requires interruptions for performing those interfrequency measurements, the UE 102 can avoid informing the network that it needs gaps for performing those measurements using musim-needForGapsInfoNR and inform the network that the UE 102 requires NCSG later in a RRCReconfigurationComplete. The source gNB 301 may not configure the UE 102 with gaps or interruptions for performing those interfrequency measurements till it receives the RRCReconfigurationComplete, and the UE 102 may skip performing these measurements during this interval.

[0187] In an embodiment herein, if the UE 102 requires interruptions for performing interfrequency measurements due to MUSIM operations and the UE has not informed the network previously that the UE 102 requires NCSG for performing those intrafrequency measurements, the UE 102 can avoid informing the network that it needs interruptions for performing those measurements using musim-needForGapsInfoNR and inform the network that the UE requires NCSG later in a RRCReconfigurationComplete. The source gNB 301 may not configure the UE 102 with gaps or interruptions for performing those intrafrequency measurements till it receives the RRCReconfigurationComplete, and the UE 102 may skip performing these measurements during this interval.

[0188] FIG. 4 depicts a process for managing MUSIM operations during handover preparation. Consider a handover scenario, wherein the UE 102 is being prepared for handover from the source gNB 301 to the target gNB 302. In step 401, the source gNB 301 receives MUSIM NeedForGap requirements, and a first requirement from the UE 102. In an embodiment herein, the MUSIM NeedforGap requirements are received in at least one of User Equipment (UE) Assistance Information (UAI), and HandoverPreparationInformation. In an embodiment herein, the first requirement is one of interruption requirements; and Network Controller Small Gap (NCSG) requirements. In an embodiment herein, the first requirement is received in at least one of RRCReconfigurationComplete, RRCResumeComplete, and HandoverPreparationInformation. In step 402, the source gNB 301 checks if the MUSIM NeedforGap requirements have been received before the first requirement. If the MUSIM NeedforGap requirements have been received before the first requirement, in step 403, the source gNB 301 informs the first requirement to the target gNB 302. If the MUSIM NeedforGap requirements have not been received before the first requirement (i.e., the MUSIM gap requirements have been received after the first requirement), in step 404, the source gNB 301 avoids informing the first requirement to the target gNB 302. This ensures that the target gNB 302 can configure the UE 102 with measurement gaps, or NCSG or interruptions, according to the latest requirements of the UE in the RRC message send for handing over the UE to the target cell. The various actions in method 400 may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some actions listed in FIG. 4 may be omitted.

[0189] FIG. 5 depicts the source gNB. The source gNB 301, as depicted, comprises a processing module 501, at least one memory 502, and at least one transceiver 503. The processing module 501 can be at least one of a single processor, a plurality of processors, multiple homogeneous or heterogeneous cores, multiple Central Processing Units (CPUs) of different kinds, microcontrollers, special media, and other accelerators. The processing module 501 may be an Application Processor (AP), a graphics-only processing unit such as a Graphics Processing Unit (GPU), a Visual Processing Unit (VPU), and / or an Artificial Intelligence (AI)-dedicated processor such as a Neural Processing Unit (NPU).

[0190] In an embodiment herein, the at least one transceiver 503 is configured to enable communication between the source gNB 301, and at least one external entity (such as, but not limited to, UE 102, the target gNB 302, and so on) through a network or cloud. The transceiver 503 through which the source gNB 301 and the at least one external entity communicate may include wired and / or wireless communication medium compatible with one or more different communication protocols. The transceiver 503 may be configured for communication through a network. The network may comprise, but are not limited to, Global Positioning System (GPS), Global System for Mobile Communications (GSM), Local Area Network (LAN), Wireless Fidelity (Wi-Fi) compatibility, Bluetooth Low Energy (BLE), Near-field Communication (NFC), and so on. The wireless communication may further comprise one or more of Bluetooth, Zonal Intercommunication Global Standard (ZigBee), short-range wireless communication such as Ultra-wideband (UWB), medium-range wireless communication such as Wi-Fi, or long-range wireless communication such as Third Generation (3G), Fourth Generation (4G), Fifth Generation (5G), Sixth Generation (6G), or Worldwide Interoperability for Microwave Access (WiMAX), according to the usage environment.

[0191] In the embodiment shown herein, the at least one memory 502 may comprise one or more volatile and non-volatile memory components that are capable of storing data and instructions to be executed. Examples of the at least one memory 502 can be, but are not limited to, NAND, embedded Multimedia Card (eMMC), Secure Digital (SD) cards, Universal Serial Bus (USB), Serial Advanced Technology Attachment (SATA), solid-state drive (SSD), and so on. The at least one memory 502 may also include one or more computer-readable storage media. Examples of non-volatile storage elements may include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. In addition, the at least one memory 502 may, in some examples, be considered a non-transitory storage medium. The term "non-transitory" may indicate that the storage medium is not embodied in a carrier wave or a propagated signal. However, the term "non-transitory" should not be interpreted to mean that the at least one memory 502 is non-movable. In certain examples, a non-transitory storage medium may store data that can, over time, change (for example, in Random Access Memory (RAM) or cache).

[0192] Consider a handover scenario, wherein the UE 102 is being prepared for handover from the source gNB 301 to the target gNB 302. the processing module 501 can receive MUSIM NeedforGap requirements, and a first requirement from the UE 102 via the transceiver 503. In an embodiment herein, the processing module 501 can receive the MUSIM NeedforGap requirements in at least one of User Equipment (UE) Assistance Information (UAI), and HandoverPreparationInformation. In an embodiment herein, the first requirement is one of interruption requirements; and Network Controller Small Gap (NCSG) requirements. In an embodiment herein, the processing module 501 can receive the first requirement in at least one of RRCReconfigurationComplete, RRCResumeComplete, and HandoverPreparationInformation. The processing module 501 can check if the MUSIM NeedforGap requirements have been received before the first requirement. If the MUSIM NeedforGap requirements have been received before the first requirement, the processing module 501 can inform the first requirement to the target gNB 302, via the transceiver 503. If the MUSIM NeedforGap requirements have not been received before the first requirement (i.e., the MUSIM NeedforGap requirements have been received after the first requirement), the processing module 501 avoids informing the first requirement to the target gNB 302.

[0193] FIG. 6 depicts a network comprising at least one first node, and at least one second node. The network can comprise of at least one first node 601, and at least one second node 602, wherein the first node 102 can be in communication with at least one UE 102. In an example embodiment herein, the first node can be one of a Master Node (MN), and a Central Unit (CU) (as depicted in FIGs. 7A and 7B). In an example embodiment herein, the second node can be one of a Secondary Node (SN), and a Distributed Unit (DU) (as depicted in FIGs. 7A and 7B).

[0194] The first node 601 can receive temporary capability restrictions (such as, but not limited to, musim-Cell-SCG-ToRelease and / or musim-CellToAffectList) from the UE 102. On receiving the temporary capability restrictions from the UE 102, the first node 601 can start the MUSIM wait timer (for example, T348) in the background with a configured timer value (for example, the timer value of musim-WaitTimer-r18). On expiry of the MUSIM wait timer, the first node 601 can inform the temporary capability restrictions to the second node 602. In an embodiment herein, the first node 601 can inform the temporary capability restrictions to the second node 602 using an Information Element (IE), wherein the IE is one of sent in at last one Xn procedure, and embedded in at least one Radio Resource Control (RRC) InterNodeMessage.

[0195] In an example embodiment herein, in dual connectivity, the MN starts the MUSIM wait timer (for example, T348) in the background with a configured value of musim-WaitTimer-r18 upon reception of temporary capability restrictions (such as, but not limited to, musim-Cell-SCG-ToRelease and / or musim-CellToAffectList) from the UE 102. Upon expiry of the timer, the MN informs the SN that the MUSIM wait timer has expired, and the UE 102 will autonomously apply temporary capability restrictions. In an embodiment herein, the MN sends an IE to inform the SN to also apply the temporary capability restrictions. In an embodiment herein, this IE may be sent in Xn procedures (such as, but not limited to, SN Modification Request). In an embodiment herein, this IE may be embedded in RRC InterNodeMessages (such as, but not limited to, CG-ConfigInfo). In an embodiment herein, the SN may confirm to the MN that the temporary capability restrictions as requested by the UE 102 have been applied. In an embodiment herein, the MN stops the MUSIM wait timer upon sending the RRCReconfiguration with the restricted capabilities according to the temporary capability restrictions.

[0196] In an example embodiment herein, the CU starts the MUSIM wait timer (for example, T348) in the background with the configured value of musim-WaitTimer-r18 upon reception of temporary capability restrictions (such as, but not limited to, musim-Cell-SCG-ToRelease and / or musim-CellToAffectList). On expiry of the timer, the CU informs DU that the MUSIM wait timer has expired and the UE 102 will autonomously apply temporary capability restrictions. In an embodiment herein, the CU sends an IE to inform the DU to also apply the temporary capability restrictions. In an embodiment herein, this IE may be sent in F1AP procedures (such as, but not limited to, UE Context Modification procedure, messages such as UEContextModificationRequest, and so on). In an embodiment herein, the DU may confirm to the CU that the temporary capability restrictions as requested by the UE 102 have been applied. In an embodiment herein, the CU stops the MUSIM wait timer upon sending the RRCReconfiguration with the restricted capabilities according to the temporary capability restrictions.

[0197] In an example embodiment herein, the MN informs the MUSIM capability restriction configuration to the SN (such as, but not limited to, musim-CapabilityRestrictionConfig-r18). In an embodiment herein, the MUSIM capability restriction configuration may be included in RRC InterNodeMessages (INM) (such as, but not limited to, CG-Config).

[0198] In an example embodiment herein, the CU informs the MUSIM capability restriction configuration (such as, but not limited to, musim-CapabilityRestrictionConfig-r18) to the DU. In an embodiment herein, this may be included in RRC InterNodeMessages (INM) (such as, but not limited to, CG-Config). In an embodiment herein, this may be included in the CU to DU Information IE. The IE may be sent during F1AP UEContext Setup procedure, and / or F1AP UE context modification procedure. The IE may be sent during F1AP UEContext Setup message, and / or F1AP UE context modification message.

[0199] In an example embodiment herein, the MN informs the MUSIM prohibit timer to SN (such as, but not limited to, musim-ProhibitTimer-r18). In an embodiment herein, the CU informs the MUSIM prohibit timer to DU (such as, but not limited to, musim-ProhibitTimer-r18).

[0200] 9.3.1.25 CU to DU RRC Information:

[0201] The IE (as depicted in table 3) contains the RRC Information that are sent from the gNB-CU to the gNB-DU.

[0202]

[0203]

[0204] FIG. 8 is a flowchart depicting the process of managing Multi - Subscriber Identity Module (SIM) (MUSIM) operations in a dual connectivity scenario. In step 801, the first node 601 receives temporary capability restrictions (such as, but not limited to, musim-Cell-SCG-ToRelease and / or musim-CellToAffectList) from the UE 102. On receiving the temporary capability restrictions from the UE 102, in step 802, the first node 601 starts the MUSIM wait timer (for example, T348) in the background with a configured timer value (for example, the timer value of musim-WaitTimer-r18). On expiry of the MUSIM wait timer (step 803), in step 804, the first node 601 informs the temporary capability restrictions to the second node 602 using an Information Element (IE), wherein the IE is one of sent in at last one Xn procedure, and embedded in at least one Radio Resource Control (RRC) InterNodeMessage. The various actions in method 800 may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some actions listed in FIG. 8 may be omitted.

[0205] FIG. 9 depicts the node in a wireless communication network. The node 601, as depicted, comprises a processing module 901, at least one memory 902, and at least one transceiver 903. In an example embodiment herein, the first node 601 can be one of a Master Node (MN), and a Central Unit (CU) (as depicted in FIGs. 7A and 7B). The processing module 901 can be at least one of a single processor, a plurality of processors, multiple homogeneous or heterogeneous cores, multiple Central Processing Units (CPUs) of different kinds, microcontrollers, special media, and other accelerators. The processing module 901 may be an Application Processor (AP), a graphics-only processing unit such as a Graphics Processing Unit (GPU), a Visual Processing Unit (VPU), and / or an Artificial Intelligence (AI)-dedicated processor such as a Neural Processing Unit (NPU).

[0206] In an embodiment herein, the at least one transceiver 903 is configured to enable communication between the node 601, and at least one external entity (such as, but not limited to, the UE 102, the second node 602, and so on) through a network or cloud. The transceiver 903 through which the node 601 and the at least one external entity communicate may include wired and / or wireless communication medium compatible with one or more different communication protocols. The transceiver 903 may be configured for communication through a network. The network may comprise, but are not limited to, Global Positioning System (GPS), Global System for Mobile Communications (GSM), Local Area Network (LAN), Wireless Fidelity (Wi-Fi) compatibility, Bluetooth Low Energy (BLE), Near-field Communication (NFC), and so on. The wireless communication may further comprise one or more of Bluetooth, Zonal Intercommunication Global Standard (ZigBee), short-range wireless communication such as Ultra-wideband (UWB), medium-range wireless communication such as Wi-Fi, or long-range wireless communication such as Third Generation (3G), Fourth Generation (4G), Fifth Generation (5G), Sixth Generation (6G), or Worldwide Interoperability for Microwave Access (WiMAX), according to the usage environment.

[0207] In the embodiment shown herein, the at least one memory 902 may comprise one or more volatile and non-volatile memory components that are capable of storing data and instructions to be executed. Examples of the at least one memory 902 can be, but are not limited to, NAND, embedded Multimedia Card (eMMC), Secure Digital (SD) cards, Universal Serial Bus (USB), Serial Advanced Technology Attachment (SATA), solid-state drive (SSD), and so on. The at least one memory 902 may also include one or more computer-readable storage media. Examples of non-volatile storage elements may include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. In addition, the at least one memory 902 may, in some examples, be considered a non-transitory storage medium. The term "non-transitory" may indicate that the storage medium is not embodied in a carrier wave or a propagated signal. However, the term "non-transitory" should not be interpreted to mean that the at least one memory 902 is non-movable. In certain examples, a non-transitory storage medium may store data that can, over time, change (for example, in Random Access Memory (RAM) or cache).

[0208] The processing module 901 can receive temporary capability restrictions (such as, but not limited to, musim-Cell-SCG-ToRelease and / or musim-CellToAffectList) from the UE 102, via the transceiver 903. On receiving the temporary capability restrictions from the UE 102, the processing module 901 can start the MUSIM wait timer (for example, T348) in the background with a configured timer value (for example, the timer value of musim-WaitTimer-r18). On expiry of the MUSIM wait timer, the processing module 901 can inform the temporary capability restrictions to the second node 602, via the transceiver 903. In an embodiment herein, the processing module 901 can inform the temporary capability restrictions to the second node 602 using an Information Element (IE), wherein the IE is one of sent in at last one Xn procedure, and embedded in at least one Radio Resource Control (RRC) InterNodeMessage.

[0209] In an embodiment herein, if a receiving network node receives InterNode messages (such as, but not limited to, CG-Config or CG-ConfigInfo) without MUSIM gap configuration, or part of the MUSIM gap configuration, the receiving network node maintains the previously received value. If the sending network node has included MUSIM gap configuration or part of MUSIM gap configuration in a CG-ConfigInfo or CG-Config, the sending network node may skip including the same in a new CG-ConfigInfo or CG-Config, if there is no change in the MUSIM gap configuration. The sending node and receiving node are according to the 3gpp TS 38.331. In an embodiment herein, the receiving node can be a SN (in dual connectivity) or a DU / CU (in single connectivity and dual connectivity. In an embodiment herein, when the receiving node is a SN, the sending node is the MN. In an embodiment herein, when the receiving node is the DU, the sending node is the CU. In an embodiment herein, when the receiving node is the CU, the sending node is the DU.

[0210] In an embodiment herein, if the receiving network node receives InterNode messages (such as, but not limited to, CGConfig or CGConfigInfo) without MUSIM capability restrictions, or part of MUSIM capability restrictions, or MUSIM capability restriction configuration, or part of MUSIM capability restriction configuration, the receiving network node maintains the previously received value. If the sending network node has included MUSIM capability restriction, or part of MUSIM capability restriction, or MUSIM capability restriction configuration, or part of MUSIM capability restriction configuration in a CG-ConfigInfo or CG-Config, the sending network node may skip including the same in a new CG-ConfigInfo or CG-Config if there is no change in the MUSIM gap configuration. The sending node and receiving node are according to the 3gpp TS 38.331. In an embodiment herein, the receiving node can be a SN (in dual connectivity) or a DU / CU (in single connectivity and dual connectivity. In an embodiment herein, when the receiving node is the SN, the sending node is the MN. In an embodiment herein, when the receiving node is the DU, the sending node is the CU. In an embodiment herein, when the receiving node is the CU, the sending node is the DU.

[0211] In an embodiment herein, based on TS 38.331,

[0212] 11.2.3 Mandatory information in inter-node RRC messages:

[0213] For fields in　CG-Config　and　CG-ConfigInfo　listed below, absence of the field means that the receiver maintains the values informed via the previous message. Note that every time there is a change in the configuration covered by a listed field, the MN or SN shall include the field, and it shall provide the full configuration provided by that field unless stated otherwise. Otherwise, if there is no change, the following fields can be omitted: configRestrictInfo; gapPurpose; measGapConfig　(for which delta signaling applies); measGapConfigFR2　(for which delta signaling applies); measResultCellListSFTD; measResultSFTD-EUTRA; sftdFrequencyList-EUTRA; sftdFrequencyList-NR; ue-CapabilityInfo; servFrequenciesMN-NR; musim-GapConfigInfo-r18; musim-CapRestrictionInfo-r18; and MUSIM-CapabilityRestrictionConfig-r18.

[0214] T348 and RRC Reestablishment:

[0215] In an embodiment herein, the UE 102 stops T348 during RRCReestablishment. In an embodiment herein, the UE 102 stops T348 upon initiation of RRC Reestablishment procedure. In an embodiment herein, this may be represented in TS 38.331 (with reference to version V18.0.0).

[0216] FIG. 10 is a flowchart depicting the process of performing RRCReestablishment, while the MUSIM wait timer is running. In step 1001, the UE 102 sends a UAI for requesting temporary capability restrictions, and starts the T348 timer. In step 1002, the UE 102 initiates the RRC reestablishment procedure. In step 1003, the UE 102 stops the T348 timer, on the RRC reestablishment procedure being initiated. The various actions in method 1000 may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some actions listed in FIG. 10 may be omitted.

[0217] In an embodiment herein, when the UE 102 is not configured with attemptCondReconfig, or when the UE 102 is not configured with attemptLTM-Switch, the UE 102 stops the T348 timer, on initiation of the RRC Reestablishment procedure. If the UE 102 is configured with attemptCondReconfig or if the UE 102 is not configured with attemptLTM-Switch, the UE 102 keeps the timer running. In this case, upon selecting a suitable NR cell after initiating the RRC Reestablishment procedure, the UE 102 may stop the T348 timer, if the selected cell is not an MCG LTM candidate cell when attemptLTM-Switch is configured, or if the selected cell is not an MCG Candidate cell for conditional reconfiguration when the UE is configured with attemptCondReconfig.

[0218] T348 and Mobility from NR:

[0219] In an embodiment herein, during Inter-RAT handover from NR, the UE 102 stops the timer T348, if the timer T348 is running. In an embodiment herein, upon reception of MobilityFromNRCommand by the UE, the UE 102 stops timer T348.

[0220] FIG. 11 is a flowchart depicting the process of performing Inter-RAT handover, while the MUSIM wait timer is running. In step 1101, the UE 102 sends a UAI for requesting temporary capability restrictions, and starts the T348 timer. In step 1102, the UE 102 receives the MobilityFromNRCommand. In step 1103, the UE 102 stops the T348 timer, on the MobilityFromNRCommand being received. The various actions in method 1100 may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some actions listed in FIG. 11 may be omitted.

[0221] FIG. 12 is a flowchart depicting the process of performing one or more network operations for WaitTimer in dual connectivity. In step 1201, the MN receives a request for Temporary capability restriction; and the MN further starts a wait timer. In step 1202, the MN waits for the wait timer to expire. On the wait timer expiring, in step 1203, the MN informs the SN that the wait timer has expired, and the UE 102 has applied temporary capability restriction autonomously. The various actions in method 1200 may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some actions listed in FIG. 12 may be omitted.

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

[0223] The embodiments disclosed herein describe methods and systems for configuring a UE (which has indicated to the network that there is a temporary capability restriction while moving to RRC_CONNECTED) with advanced capabilities (such as, but not limited to, carrier aggregation, dual connectivity, conditional handover, lower layer triggered mobility (LTM) inter-frequency measurements measurement gaps, and so on). 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.

[0224] 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 and examples, those skilled in the art will recognize that the embodiments and examples disclosed herein can be practised with modification within the scope of the embodiments as described herein.

Claims

1.A method performed by a source base station supporting a Multi Universal Subscriber Identity Module (MUSIM) in a communication system, the method comprising:receiving, from a user equipment (UE), MUSIM measurement gap requirement information of a target band for the MUSIM and requirement information,based on the reception of the measurement gap requirement information and the requirement information, determining whether to transmit a handover preparation message including the requirement information to the target base station.2.The method of claim 1,wherein the requirement information is at least one of first information indicating a measurement gap and Non-Coordinated Silent Gap (NCSG) requirement information or second information indicating whether an interruption is needed while performing a measurement without the measurement gap.3.The method of claim 2,wherein the MUSIM measurement gap requirement information is received via a UE assistance information (UAI) message, andwherein the requirement information is received via a radio resource control (RRC) reconfiguration complete message or an RRC Resume Complete message.4.The method of claim 2,wherein the source base station determines to transmit the requirement information to the target base station, in case that the MUSIM measurement gap requirement information has been received before the requirement information, andwherein the source base station determines not to transmit the requirement information to the target base station, in case that the MUSIM measurement gap requirement information has been received after the requirement information.5.A method performed by a user equipment (UE) supporting a Multi Universal Subscriber Identity Module (MUSIM) in a communication system, the method comprising:generating MUSIM measurement gap requirement information of a target band for the MUSIM and requirement information;transmitting, to a source base station, the MUSIM measurement gap requirement information and the requirement information,wherein whether to transmit a handover preparation message including the requirement information from the source base station to the target base station is determined based on the reception of the measurement gap requirement information and the requirement information.6.The method of claim 5,wherein the requirement information is at least one of first information indicating a measurement gap and Non-Coordinated Silent Gap (NCSG) requirement information or second information indicating whether an interruption is needed while performing a measurement without the measurement gap.7.The method of claim 6,wherein the MUSIM measurement gap requirement information is transmitted via a UE assistance information (UAI) message, andwherein the requirement information is transmitted via a radio resource control (RRC) reconfiguration complete message or an RRC Resume Complete message.8.The method of claim 6,wherein the source base station determines to transmit the requirement information to the target base station, in case that the MUSIM measurement gap requirement information has been received before the requirement information, andwherein the source base station determines not to transmit the requirement information to the target base station, in case that the MUSIM measurement gap requirement information has been received after the requirement information.9.A source base station supporting a Multi Universal Subscriber Identity Module (MUSIM) in a communication system, the source base station comprising:a transceiver; anda controller coupled with the transceiver, and configured to:receive, from a user equipment (UE), MUSIM measurement gap requirement information of a target band for the MUSIM and requirement information,based on the reception of the measurement gap requirement information and the requirement information, determine whether to transmit a handover preparation message including the requirement information to the target base station.10.The source base station of claim 9,wherein the requirement information is at least one of first information indicating a measurement gap and Non-Coordinated Silent Gap (NCSG) requirement information or second information indicating whether an interruption is needed while performing a measurement without the measurement gap.11.The source base station of claim 10,wherein the MUSIM measurement gap requirement information is received via a UE assistance information (UAI) message, andwherein the requirement information is received via a radio resource control (RRC) reconfiguration complete message or an RRC Resume Complete message.12.The source base station of claim 10,wherein the source base station determines to transmit the requirement information to the target base station, in case that the MUSIM measurement gap requirement information has been received before the requirement information, andwherein the source base station determines not to transmit the requirement information to the target base station, in case that the MUSIM measurement gap requirement information has been received after the requirement information.13.A user equipment (UE) supporting a Multi Universal Subscriber Identity Module (MUSIM) in a communication system, the method comprising:generating MUSIM measurement gap requirement information of a target band for the MUSIM and requirement information;transmitting, to a source base station, the MUSIM measurement gap requirement information and the requirement information,wherein whether to transmit a handover preparation message including the requirement information from the source base station to the target base station is determined based on the reception of the measurement gap requirement information and the requirement information.14.The UE of claim 13,wherein the requirement information is at least one of first information indicating a measurement gap and Non-Coordinated Silent Gap (NCSG) requirement information or second information indicating whether an interruption is needed while performing a measurement without the measurement gap.15.The UE of claim 14,wherein the MUSIM measurement gap requirement information is transmitted via a UE assistance information (UAI) message,wherein the requirement information is transmitted via a radio resource control (RRC) reconfiguration complete message or an RRC Resume Complete message, andwherein the source base station determines to transmit the requirement information to the target base station, in case that the MUSIM measurement gap requirement information has been received before the requirement information, andwherein the source base station determines not to transmit the requirement information to the target base station, in case that the MUSIM measurement gap requirement information has been received after the requirement information.

Images