Methods and systems for configuring musim operations

Abstract

Embodiments herein 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 or DU to CU, when the MUSIM UE has two USIMs (i.e. two UEs in same MUSIM device), UE-A and UE-B. Embodiments herein disclose methods and systems for reporting the capability for measurement gap requirement reporting due to MUSIM operations. Embodiments herein disclose methods and systems for handling measurement gap requirements due to MUSIM operations.

Description

METHODS AND SYSTEMS FOR CONFIGURING MUSIM OPERATIONS

[0001] Embodiments disclosed herein relate to Multi-SIM (MUSIM) devices, and more particularly to managing operations of MUSIM devices.

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

[0009] The principal 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, when the MUSIM UE has two USIMs (i.e. two UEs in same MUSIM device), UE-A and UE-B.

[0010] Another object of embodiments herein is to disclose methods and systems for reporting the capability for measurement gap requirement reporting due to MUSIM operations, when the MUSIM UE has two USIMs (i.e. two UEs in same MUSIM device), UE-A and UE-B.

[0011] Another object of embodiments herein is to disclose methods and systems for handling measurement gap requirements due to MUSIM operations, when the MUSIM UE has two USIMs (i.e. two UEs in same MUSIM device), UE-A and UE-B.

[0012] Accordingly, the embodiments herein provide a method performed by a fist node for managing inter-node Radio Resource Control (RRC) messages in a dual connectivity scenario in a wireless communication network. The method comprises verifying whether there is a change in a configuration of at least one first field. The method comprises, in case that there is a change in the configuration of the at least one first field, providing an inter-node RRC message to a second node comprising a full configuration of the at least one first field. The method comprises, in case that there is no change in the configuration of the at least one first field, providing the inter-node RRC message to the second node without the configuration of the at least one first field.

[0013] Accordingly, the embodiments herein provide a method performed by a second node for managing inter-node Radio Resource Control (RRC) messages in a dual connectivity scenario in a wireless communication network. The method comprises receiving, by a second node, an inter-node Radio Resource Control (RRC) message from a first node. The method further comprises updating, by the second node, a configuration of at least one first field, in case that the configuration of the at least one first field is included in the inter-node RRC message; and maintaining, by the second node, a configuration of the at least one first field, in case that the configuration of the at least one first field is not included in the inter-node RRC message.

[0014] Accordingly, the embodiments herein provide a node in a wireless communication network, the node comprising a processing module; a memory; and a transceiver. The processing module is coupled with the memory, and the transceiver, and configured to verify whether there is a change in a configuration of at least one first field. The processing module is configured to, in case that there is a change in the configuration of the at least one first field, providing an inter-node RRC message to a second node comprising a full configuration of the at least one first field. The processing module is configured to, in case that there is no change in the configuration of the at least one first field, providing the inter-node RRC message to the second node without the configuration of the at least one first field.

[0015] Accordingly, the embodiments herein provide a node in a wireless communication network, the node comprising a processing module; a memory; and a transceiver. The processing module is coupled with the memory, and the transceiver, and configured to receive an inter-node Radio Resource Control (RRC) message from a first node. The processing module is further configured to update the configuration of the at least one first field, in case that the configuration of the at least one first field is included in the inter-node RRC message; and maintain a configuration of the at least one first field, if the configuration of the at least one first field is not included in the inter-node RRC message.

[0016] Accordingly, the embodiments herein provide a method for managing handover for a User Equipment (UE) in a wireless communication network. The method comprises including, by a source Next Generation Node B (gNB), at least one measurement gap requirement information of the UE for one or more NR target bands in AS-Context; and providing, by the source gNB, the AS-Context to a target gNB.

[0017] Accordingly, the embodiments herein provide a Next Generation Node B (gNB) in a wireless communication network, the gNB comprising a processing module; a memory; and a transceiver. The processing module is coupled with the memory, and the transceiver, and configured to include at least one measurement gap requirement information of the UE for one or more NR target bands in AS-Context, wherein the UE has last reported the at least one measurement gap requirement. The processing module is further configured to provide the AS-Context to a target gNB.

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

[0019] 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:

[0020] FIG. 1 depicts the NG-RAN Architecture based on 3gpp specification TS 38.401, according to existing arts;

[0021] FIG. 2 depicts the process of handling MUSIM temporary capability restriction at the sender node of CG-Config / CG-ConfigInfo, according to existing arts;

[0022] FIGs. 3A and 3B depict the process of handling MUSIM temporary capability restriction at the receiver node of CG-Config / CG-ConfigInfo, according to existing arts;

[0023] FIG. 4 depicts the process of capability reporting for MSUIM capability restriction, according to existing arts;

[0024] FIGs. 5A, 5B, 5C, and 5D depict examples of the sending node and the receiving node, according to an embodiment of the present disclosure;

[0025] FIG. 6 depicts the process for handling MUSIM Gap configuration at the sender node of CG-Config / CG-ConfigInfo, according to an embodiment of the present disclosure;

[0026] FIG. 7 depicts the process of handling MUSIM Gap configuration at receiver node of CG-Config / CG-ConfigInfo, according to an embodiment of the disclosure;

[0027] FIGs. 8A and 8B are flowcharts depicting the process of managing inter-node Radio Resource Control (RRC) messages in a dual connectivity scenario in a wireless communication network, according to an embodiment of the disclosure;

[0028] FIG. 9 depicts a first node, according to an embodiment of the disclosure;

[0029] FIG. 10 depicts a second node, according to embodiments as disclosed herein;

[0030] FIG. 11 depicts an example handover scenario in a wireless communication network, according to an embodiment of the disclosure;

[0031] FIG. 12 depicts the HandoverPreparationInformation reporting measurement gap requirements, according to an embodiment of the disclosure;

[0032] FIG. 13 is a flowchart depicting the process of managing handover of a UE from a source gNB to a target gNB, according to an embodiment of the disclosure; and

[0033] FIG. 14 depicts the source gNB, according to an embodiment of the disclosure.

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

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

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

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

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

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

[0040] Due to popularity of Multi-SIM (MUSIM) devices that host more than one Subscriber Identity Module (SIM), which enables the devices to connect to two or more different Networks (NWs) in order to avail different data plans, have different user profiles (such as, home and office), increased connectivity / reliability with multiple connections, and so on.

[0041] In order to reduce costs, a User Equipment (UE) uses a common RF circuitry for multiple SIMs. This implies that multiple SIMs need to arbitrate and share the common RF resource among themselves to perform their activities and / or avail services. Effectively, only one SIM and its associated protocol stack can be served at a time. Meanwhile, all other SIMs and their associated protocol stacks will be waiting for the RF resource to be available for them. One or more of the multiple SIMs can be engaged in paging reception, system information block (SIB) acquisition, measurement, data or voice call, Multimedia broadcast multicast service (MBMS), emergency call, access stratum (AS) signaling, Non-access stratum (NAS) signaling and so on.

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

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

[0044] UE Capabilities:

[0045] In a technology like 5G NR, different UEs may have different hardware and software capabilities. Varying capabilities across devices could be hardware capabilities including radio frequency capabilities like bands or band combinations supported, processing capabilities (e.g. baseband computational capabilities), software capabilities like the support of various features, layer 1 capabilities, layer 2 capabilities, layer 3 capabilities and so on. In general, the UE reports its UE radio access capabilities which are static at least when the network requests the capabilities. To limit 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 NAS signalling that represents its radio capabilities for one or more RATs in order to reduce signalling overhead. The ID may be assigned either by the manufacturer or by the serving 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. A detailed list of UE capabilities that are exchanged based on aforementioned methods is specified in 3GPP technical specifications like TS 38.306.

[0046] 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 5G gNB may comprise of CU and DU.

[0047] RRC States:

[0048] In NR, RRC can be in one of the three states- RRC_IDLE, RRC_INACTIVE, or RRC_CONNECTED. A RRC_CONNECTED UE is in CM-CONNECTED (i.e., connected to a 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 layer. The Network stores the UE AS context, knows the UE at the cell level and controls the UE mobility. The UE may perform measurements and report to the network, and provides channel quality and feedback information, and so on.

[0049] 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 NG-RAN. In RRC_INACTIVE, the last serving gNB node keeps the UE context and the UE-associated NG connection (i.e., the connection to the core network). Since the RRC configurations and the connection to the core network are kept in RRC_INACTIVE, the UE can transition immediately to the RRC connected state and perform data transfer with the core network / applications. The UE initiates the transition to RRC_CONNECTED from RRC_INACTIVE by sending a RRC resume request.

[0050] In RRC_IDLE, the UE or gNB does not store any Access Stratum (AS) context. The UE is in CM_IDLE (there is no connection to the 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 NW (both radio access network (RAN) and core network) exchange messages to move the UE to CM_CONNECTED. A UE in RRC_CONNECTED state may send power head room to the network according to the TS 38.321 and other relevant 3gpp specs.

[0051] 3gpp also considers LowerLayerTriggered Mobility for performing handover.

[0052] FIG. 1 depicts the NG-RAN Architecture based on 3gpp specification TS 38.401. The NG-RAN comprises one or more gNBs connected to the 5GC through the NG interface. The gNBs can be interconnected through the Xn interface. A gNB may comprise of a gNB-CU and one or more gNB-DU(s). A gNB-CU and a gNB-DU are connected via a F1 interface. The CU may send F1AP (F1 Application Protocol) messages to the DU (such as, a F1AP UE Context Setup Request, a F1AP UE Context Modification Request, and so on) to setup or modify a UE Context on the DU and the DU will send F1AP UE Context Setup Response or F1AP UE Context Modification Response, if successful. The CU may send CU to DU RRC Information in the F1AP messages to inform the RRC related information. An example is given below, based on 3gpp specifications.

[0053] This IE (table 1) contains the RRC Information that are sent from gNB-CU to gNB-DU.

[0054]

[0055]

[0056]

[0057] Table 1

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

[0059] The fields in HandoverPreparationInformation field / message are as follows:

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

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

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

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

[0064] ue-InactiveTime: The duration while 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.

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

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

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

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

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

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

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

[0072] The AS-Context field descriptions are as follows:

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

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

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

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

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

[0078] sidelinkUEInformationNR: This field includes SidelinkUEInformationNR IE.

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

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

[0081] Framework for supporting capability change:

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

[0083] Consider UE-A is in RRC-CONNECTED state with NWK-A, and UE-B (USIM-B) is moving to RRC_CONNECTED or is transitioning to RRC_CONNECTED. UE-A provides the information to NWK-A to release some resources or update some parameters for the MUSIM operations. This information pertains 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. The change can be temporary capability restrictions or removal of temporary capability restrictions.

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

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

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

[0087] 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 bandfilter. If the UE capability of a band included in the filter changes, UE-A reports the capability change. If none of the capabilities in the filter changes due to UE-B actions, UE-A may not initiate the messages to indicate UE capability change.

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

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

[0090] - Number of Rx links

[0091] - Number of Tx links

[0092] - Maximum Number of MIMO layers

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

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

[0095] - UL or DL TDD configuration

[0096] - DRX configuration on NW B

[0097] - Measurement configuration on NW B

[0098] - Frequencies which are supported or the frequencies which are restricted.

[0099] FIG. 2 depicts the process of handling MUSIM temporary capability restriction at sender node of CG-Config / CG-ConfigInfo. FIGs. 3A and 3B depict the process of handling MUSIM temporary capability restriction at receiver node of CG-Config / CG-ConfigInfo.

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

[0101] 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. FIG. 4 depicts the process of capability reporting for MSUIM capability restriction.

[0102] UE behavior for Multisim operations for dual active is captured in TS 38.331.

[0103] Table 2 depicts the T348 and T349 timers.

[0104]

[0105] Table 2

[0106] T348 is the 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 the MUSIM wait timer is applicable for any timer which performs the start or stop or expiry of the functionalities similar to T348.

[0107] Multi-Radio Dual Connectivity:

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

[0109] NG-RAN supports Multi-Radio Dual Connectivity (MR-DC) operation whereby a UE in RRC_CONNECTED is configured to utilize radio resources provided by two distinct schedulers, located in two different NG-RAN nodes connected via a non-ideal backhaul, one NG-RAN node providing NR (New Radio) access and the other NG-RAN node providing either E-UTRA (Evolved UMTS Terrestrial Radio Access) or NR access. One node acts as the master node (MN) and the other node acts as the secondary node (SN). The MN and SN are connected via a network interface and at least the MN is connected to the core network. In an example scenario, the NG-RAN supports NG-RAN E-UTRA-NR Dual Connectivity (NGEN-DC), in which a UE is connected to one ng-eNB (a E-UTRA base station that can connect to 5G core) that acts as a MN and one gNB (5G base station) that acts as a SN. In an example scenario, the 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.

[0110] The primary cell of a master or secondary cell group is called 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 Secondary Cell Group (SCG) in MR-DC, wherein the Frame timing and SFN between the cells in MCG and SCG may not be aligned.

[0111] The MN may inform the received temporary capability restriction and the band filter it has configured to the SN (as disclosed in TS 38.331), wherein 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.

[0112] Capability handling:

[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, as depicted in table 3.

[0114]

[0115] Table 3

[0116] NCSG and Interruption Requirements Reporting:

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

[0118] NeedForGapsConfigNR field descriptions:

[0119] requestedTargetBandFilterNR: Indicates the target NR bands that the UE is requested to report the gap requirement information.

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

[0121] NeedForGapsInfoNR field descriptions:

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

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

[0124] NeedForGapsIntraFreq field descriptions:

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

[0126] 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 whether 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.

[0127] NeedForGapsNR field descriptions:

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

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

[0130] NeedForGapNCSG-ConfigEUTRA

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

[0132] NeedForGapNCSG-ConfigEUTRA field descriptions:

[0133] requestedTargetBandFilterNCSG-EUTRA: Indicates the target E-UTRA bands that the UE is requested to report the measurement gap and NCSG requirement information.

[0134] NeedForGapNCSG-ConfigNR:

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

[0136] NeedForGapNCSG-ConfigNR field descriptions:

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

[0138] NeedForGapNCSG-InfoEUTRA:

[0139] The IE NeedForGapNCSG-InfoEUTRA 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.

[0140] NeedForGapNCSG-InfoEUTRA field descriptions:

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

[0142] NeedForNCSG-EUTRA field descriptions:

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

[0144] 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 neither a measurement gap nor a NCSG is needed. Value nogap-noncsg also indicates interruption is not needed.

[0145] NeedForGapNCSG-InfoNR: The IE NeedForGapNCSG-InfoNR 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.

[0146] NeedForGapNCSG-InfoNR field descriptions:

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

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

[0149] NeedForNCSG-IntraFreq field descriptions:

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

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

[0152] NeedForNCSG-NR field descriptions:

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

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

[0155] NeedForInterruptionInfoNR:

[0156] The IE NeedForInterruptionInfoNR 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.

[0157] NeedForInterruptionInfoNR field descriptions:

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

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

[0160] NeedForInterruptionNR field descriptions:

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

[0162] v17.6.0 of 3gpp specifications such as TS 38.331,TS 38.300,TS 38.306,TS 38.321 and 3gpp CR R2-2313699 can be considered as relevant background.

[0163] Traditionally, for an internode message exchange (such as, but not limited to, CG-Config or CG-ConfigInfo in NR) between a Master Node (MN) and a Secondary Node (SN) or the internode message exchange between the Centralised Unit (CU) and the Distributed Unit (DU) Of either the MN and the SN, the sender will always signal the appropriate value for almost all the fields, even if the same was indicated in the previous inter-node message. This simplifies the design and anyways, all this information is under the control of the same network. But this also means that the received is not required to maintain the received value, by default. However, the MUSIM operations, which depend on an external entity (such as, but not limited to, other USIMs / UEs or the network) different from the network to which temporary capability restrictions or MUSIM gap information is sent. There may be a need to send CG-Config or CG-ConfigInfo; for e.g., during DRX configuration or deconfiguration etc. The MUSIM related information can remain the same value for long periods due to the operations of other UEs / USIMs and the network. Sending the same information between the MN and the SN, or the CU and the DU during all the cases can cause considerable overhead and there is a need to restrict or at least optimize this scenario.

[0164] Currently, the source gNB informs only the measurement gap requirements received through the complete message in HandoverPreparationInformation. This will cause an issue after the handover since the target gNB does not know the measurement gap requirement changes according to the MUSIM operations. Thus, the UE may not be able to perform any measurements which requires gaps due to MUSIM operations after the handover. Moreover, the measurement gap requirements reported in the complete message and the MUSIM measurement gap requirements may be dependent on each other. The target gNB is expected to operate on only one of these during the measurement gap configuration and other operations. So, if it receives both the musim-NeedForGapsInfoNR and NeedForGapsInfoNR, it cannot determine efficiently, the one to be applied after handover. So, a method is needed to transfer the measurement gap requirements that the target gNB can use.

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

[0166] The embodiments herein achieve methods and systems for managing operations of MUSIM devices. Referring now to the drawings, and more particularly to FIGS. 5 through 14, where similar reference characters denote corresponding features consistently throughout the figures, there are shown embodiments.

[0167] In an embodiment herein, if the receiving network node (i.e., a second node) receives InterNode messages (such as, but not limited to, CG-Config or CG-ConfigInfo) without musim-GapConfigInfo-r18, the receiving network node maintains the previously received value. If the sending network node (i.e., a first node) has included MUSIM gap configuration in a CG-ConfigInfo or CG-Config, the first node may skip including the same in a new CG-ConfigInfo or CG-Config if there is no change in the MUSIM gap configuration.

[0168] The sending node and the receiving node are according to 3gpp TS 38.331. In an embodiment herein (as depicted in FIGs. 5A, 5B, 5C, and 5D), the receiving node / second node can be a secondary node (SN) (in dual connectivity) or DU / CU (in single connectivity and dual connectivity). In the example depicted in FIG. 5A, the first node 501 is the sending node, and the second node 502 is the receiving node. In an example scenario (as depicted in FIG. 5B), when the receiving node is the SN, the sending node is the MN. In an example scenario (as depicted in FIG. 5C), when the receiving node is the DU, the sending node is the CU. In an example scenario (as depicted in FIG. 5D), when the receiving node is the CU, the sending node is the DU.

[0169] Embodiments herein use the terms 'first node', 'sending node', 'sender node', 'sending network node', 'MN', 'Main Node', 'CU', 'Centralized Unit', 'Central Unit', 'DU', 'Distributed Unit', and so on, interchangeably to refer to the node 501, that sends the inter-node RRC message.

[0170] Embodiments herein use the terms 'second node', 'receiving node', 'receiver node', 'receiving network node', 'SN', 'secondary node', 'Centralized Unit', 'Central Unit', 'DU', 'Distributed Unit', and so on, interchangeably to refer to the node 502, that receives the inter-node RRC message.

[0171] FIG. 6 depicts the process for handling MUSIM Gap configuration at the sender node of CG-Config / CG-ConfigInfo. In step 601, the first node 501 has to send a MUSIM Gap Configuration in CG-Config or CG-ConfigInfo to the second node. In step 602, the first node 501 checks whether it has to create a new CG-Config or CG-ConfigInfo. In step 603, the first node 501 checks if the MUSIM gap configuration has changed. If the MUSIM gap configuration has changed, in step 604, the first node 501 creates CG-Config or CG-ConfigInfo including MUSIM Gap Configuration and sends the same to the second node. If the MUSIM gap configuration has not changed, in step 605, the first node 501 creates CG-Config or CG-ConfigInfo without including MUSIM gap configuration and sends the same to the second node 502. The various actions in method 600 may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some actions listed in FIG. 6 may be omitted.

[0172] In an embodiment herein, if the receiving node 502 receives InterNode messages (such as CGConfig or CGConfigInfo) without musim-CapRestrictionInfo-r18, the receiving node 502 maintains the previously received value. If the sending node 501 has included MUSIM capability restriction in a CG-ConfigInfo or CG-Config, the sending node 501 may skip including the same in a new CG-ConfigInfo or CG-Config, if there is no change in the MUSIM capability restriction.

[0173] The sending node and the receiving node are according to 3gpp TS 38.331. In an embodiment herein (as depicted in FIGs. 5A, 5B, 5C, and 5D), the receiving node / second node can be a secondary node (SN) (in dual connectivity) or DU / CU (in single connectivity and dual connectivity). In the example depicted in FIG. 5A, the first node 501 is the sending node, and the second node 502 is the receiving node. In an example scenario (as depicted in FIG. 5B), when the receiving node is the SN, the sending node is the MN. In an example scenario (as depicted in FIG. 5C), when the receiving node is the DU, the sending node is the CU. In an example scenario (as depicted in FIG. 5D), when the receiving node is the CU, the sending node is the DU.

[0174] FIG. 7 depicts the process of handling MUSIM Gap configuration at receiver node of CG-Config / CG-ConfigInfo. In step 701, the second node 502 receives CG-Config / CG-ConfigInfo including MUSIM gap configuration from the first node 501. In step 702, the second node 502 checks if the received CG-Config / CG-ConfigInfo includes MUSIM gap configuration. If the received CG-Config / CG-ConfigInfo includes MUSIM gap configuration, in step 703, the second node 502 stores the received MUSIM gap configuration from the CG-Config / CG-ConfigInfo. If the received CG-Config / CG-ConfigInfo does not include MUSIM gap configuration, in step 704, the second node 502 applies the previously received MUSIM gap configuration. The various actions in method 700 may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some actions listed in FIG. 7 may be omitted.

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

[0176] 11.2.3 Mandatory information in inter-node RRC messages

[0177] 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 501 or SN 502 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 field can be omitted:

[0178] - configRestrictInfo;

[0179] - gapPurpose;

[0180] - measGapConfig (for which delta signaling applies);

[0181] - measGapConfigFR2 (for which delta signaling applies);

[0182] - measResultCellListSFTD;

[0183] - measResultSFTD-EUTRA;

[0184] - sftdFrequencyList-EUTRA;

[0185] - sftdFrequencyList-NR;

[0186] - ue-CapabilityInfo;

[0187] - servFrequenciesMN-NR.

[0188] - musim-GapConfigInfo-r18

[0189] - musim-CapRestrictionInfo-r18

[0190] For other fields in CG-Config and CG-ConfigInfo, the sender shall always signal the appropriate value even if the same was indicated in the previous inter-node message, unless explicitly stated otherwise.

[0191] The MN 501 informs the musim-GapConfigInfo in CG-ConfigInfo to the SN 502. If the MN 501 sends a new CG-ConfigInfo to the SN 502, the MN 501 verifies if there is a change in musim-GapConfigInfo. If there is a change in musim-GapConfigInfo, the MN 501 includes musim-GapConfigInfo in CG-ConfigInfo. If there is no change in musim-GapConfigInfo, the MN 501 sends CG-ConfigInfo without including musim-GapConfigInfo and the SN 502 applies the previously received musim-GapConfigInfo.

[0192] The MN 501 informs the musim-CapRestrictionInfo in CG-ConfigInfo to the SN 502. If the MN 501 sends a new CG-ConfigInfo to the SN 502, the MN 501 verifies if there is a change in musim-CapRestrictionInfo. If there is a change in musim-CapRestrictionInfo, the MN 501 includes musim-CapRestrictionInfo in CG-ConfigInfo. If there is no change in musim-CapRestrictionInfo, the MN 501 sends CG-ConfigInfo without including musim-CapRestrictionInfo and the SN 502 applies the previously received musim-CapRestrictionInfo.

[0193] The CU 501 informs the musim-GapConfigInfo in CG-ConfigInfo / CG-Config to the DU 502. If the CU 501 sends a new CG-ConfigInfo / CG-Config to the DU 502, the CU 501 verifies if there is a change in musim-GapConfigInfo. If there is a change in musim-GapConfigInfo, the CU 501 includes musim-GapConfigInfo in CG-ConfigInfo / CG-Config. If there is no change in musim-GapConfigInfo, the CU 501else sends CG-ConfigInfo / CG-Config without including musim-GapConfigInfo and the DU 502 applies the previously received musim-GapConfigInfo.

[0194] The CU 501 informs the musim-CapRestrictionInfo in CG-ConfigInfo / CG-Config to the DU 502. If the CU 501 sends a new CG-ConfigInfo / CG-Config to the DU 502, the CU 501 verifies if there is a change in musim-CapRestrictionInfo. If there is a change in musim-CapRestrictionInfo, the CU 501 includes musim-CapRestrictionInfo in CG-ConfigInfo / CG-Config. If there is a change in musim-CapRestrictionInfo, the CU 501 sends CG-ConfigInfo / CG-Config without including musim-CapRestrictionInfo and the DU 502 applies the previously received musim-CapRestrictionInfo.

[0195] The DU 501 informs the musim-GapConfigInfo in CG-ConfigInfo to the CU 502. If the DU 501 sends a new CG-ConfigInfo to the CU 502, the DU 501 verifies if there is a change in musim-GapConfigInfo. If there is a change in musim-GapConfigInfo, the DU 501 includes musim-GapConfigInfo in CG-ConfigInfo. If there is no change in musim-GapConfigInfo, the DU 501 sends CG-ConfigInfo without including musim-GapConfigInfo and the CU 502 uses the previously received musim-GapConfigInfo.

[0196] FIGs. 8A and 8B are flowcharts depicting the process of managing inter-node Radio Resource Control (RRC) messages in a dual connectivity scenario in a wireless communication network. In step 801, the first node 501 checks if there are one or more changes in the configuration of at least one field of the inter-node RRC message, wherein the inter-node message comprises one of CG-Config, and CG-ConfigInfo. If there are one or more changes in the configuration of at least one field of the inter-node RRC message, in step 802, the first node 501 checks if the change in configuration is for at least one first field of the inter-node RRC message, wherein the at least one first field comprises at least one of musim-GapConfigInfo-r18; and musim-CapRestrictionInfo-r18. If the change in configuration is for the at least one first field of the inter-node RRC message, in step 803, the first node 501 includes a full configuration of at least one first field in the inter-node RRC message, and includes other fields in the inter-node RRC message, wherein there is no change in a configuration of the other fields. If the change in configuration is not for the at least one first field of the inter-node RRC message, in step 804, the first node 501 omits the configuration of the at least one first field in the inter-node RRC message, and includes other fields in the inter-node RRC message, wherein there is no change in a configuration of the other fields. In step 805, the first node 501 provides the inter-node RRC message to the second node 502.

[0197] In step 806, the second node 502 receives the inter-node RRC message from the first node 501. In step 807, the second node 502 checks if the configuration of the at least one first field has been received in the inter-node RRC message. If the configuration of the at least one first field has been received in the inter-node RRC message, in step 808, the second node 502 updates the configuration of the at least one first field. If the configuration of the at least one first field has not been received in the inter-node RRC message, in step 809, the second node 502 maintains the configuration of the first field. In an embodiment herein, the second node 502 releases configuration of other fields in the inter-node RRC message, if the configuration of other fields in the inter-node RRC message are not received in the received inter-node RRC message. 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 FIGs. 8A and 8B may be omitted.

[0198] FIG. 9 depicts a first node. The first node 501 can also be referred to herein interchangeably as 'sending node', 'sender node', 'sending network node', 'MN', 'Main Node', 'CU', 'Centralized Unit', 'Central Unit', 'DU', 'Distributed Unit', and any other node that can send the inter-node RRC message to at least one other node 502. The first node 501, as depicted, comprises a processing module 901, at least one memory 902, and at least one transceiver 903.

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

[0200] In an embodiment herein, the at least one transceiver 903 is configured to enable communication between the first node 501 and at least one external entity (such as, but not limited to, the second node 502, and so on) through a network or cloud. The transceiver 903 through which the first node 501 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), or Worldwide Interoperability for Microwave Access (WiMAX), according to the usage environment.

[0201] In the embodiment shown herein, the 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 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 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 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 memory 902 is non-movable. In certain examples, a non-transitory storage medium may store data that can, over time, change (e.g., in Random Access Memory (RAM) or cache).

[0202] The processing module 901 can check if there are one or more changes in the configuration of at least one field of the inter-node RRC message. The inter-node message can be one of CG-Config, and CG-ConfigInfo. If there are one or more changes in the configuration of at least one field of the inter-node RRC message, the processing module 901 can check if the change in configuration is for at least one first field of the inter-node RRC message. The at least one first field can be at least one of musim-GapConfigInfo-r18; and musim-CapRestrictionInfo-r18. If the change in configuration is for the at least one first field of the inter-node RRC message, the processing module 901 can include a full configuration of at least one first field in the inter-node RRC message, and include other fields in the inter-node RRC message, wherein there is no change in a configuration of the other fields. If the change in configuration is for the at least one first field of the inter-node RRC message, the processing module 901 can omit the configuration of the at least one first field in the inter-node RRC message, and include other fields in the inter-node RRC message, wherein there is no change in a configuration of the other fields. The processing module 901 can provide the inter-node RRC message to the second node 502 via the transceiver 903.

[0203] FIG. 10 depicts a second node. The second node 502 can also be referred to herein interchangeably as, 'receiving node', 'receiver node', 'receiving network node', 'SN', 'secondary node', 'Centralized Unit', 'Central Unit', 'DU', 'Distributed Unit', and any other node that can receive the inter-node RRC message from at least one other node 501. The second node 502, as depicted, comprises a processing module 1001, at least one memory 1002, and at least one transceiver 1003.

[0204] The processing module 1001 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 1001 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).

[0205] In an embodiment herein, the at least one transceiver 1003 is configured to enable communication between the second node 502 and at least one external entity (such as, but not limited to, the first node 501, and so on) through a network or cloud. The transceiver 803 through which the second node 502 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 1003 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), or Worldwide Interoperability for Microwave Access (WiMAX), according to the usage environment.

[0206] In the embodiment shown herein, the at least one memory 1002 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 1002 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 1002 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 1002 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 1002 is non-movable. In certain examples, a non-transitory storage medium may store data that can, over time, change (e.g., in Random Access Memory (RAM) or cache).

[0207] Consider that the processing module 1001 can receive the inter-node RRC message from the first node 501, via the transceiver 1003. The processing module 1001 can then check if the configuration of the first field has been received in the inter-node RRC message. If the configuration of the first field has been received in the inter-node RRC message, the processing module 1001 can update the configuration of the at least one first field. If the configuration of the first field has not been received in the inter-node RRC message, the processing module 1001 can maintain the configuration of the first field.

[0208] Capability handling:

[0209] In an embodiment herein, consider a UE 1103 which supports MUSIM temporary capability restrictions, also supports NeedForGaps Reporting (such as nr-NeedForGap-Reporting-r16). The UE 1103 sends a capability bit to indicate the support of temporary capability restrictions, only if the UE 1103 supports NeedForGaps Reporting. Consider that the UE 1103 is undergoing a handover from a source Next Generation Node B (gNB) 1101 to a target Next Generation Node B (gNB) 1102 (as depicted in FIG. 11).

[0210] In an embodiment herein, in TS 38.306 (as in table 4):

[0211]

[0212] Table 4

[0213] Handover Preparation:

[0214] Embodiments herein disclose methods and systems for transferring the measurement gap requirements that the target gNB can use.

[0215] In an embodiment herein, the source gNB 1101 which has received measurement gap requirements from the UE through NeedForGapsInfoNR in the RRCSetupComplete / RRCReconfigurationComplete / RRCResumeComplete / HandoverPreparationInformation and musim-NeedForGapsInfoNR in UE Assistance Information includes the last received measurement gap requirements (i.e., last received among NeedForGapsInfoNR or musim-NeedForGapsInfoNR) in the HandoverPreparationInformation.

[0216] FIG. 12 depicts the HandoverPreparationInformation reporting measurement gap requirements. In step 1201, the source gNB 1101 receives measurement gap requirements in a RRC complete message or the measurement gap requirements due to MUSIM operations. In step 1202, the source gNB 1101 checks to which measurement gap requirements have been received last; i.e., MUSIM measurement gap requirements, or measurement gap requirements in complete message. If the MUSIM measurement gap requirements have been received last, in step 1203, the source gNB 1101 includes measurement gap requirements received through musim-NeedForGapNR in the HandoverPreparationInformation. If the Measurement gap requirements have been received last in a complete message, in step 1204, the source gNB 1101 includes measurement gap requirements received through NeedForGapNR in the HandoverPreparationInformation. 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.

[0217] In an embodiment herein, if the source gNB 1101 has received needForGapsInfoNR in RRCSetupComplete / RRCReconfigurationComplete / RRCResumeComplete / HandoverPreparationInformation before musim-NeedForGapsInfoNR in UAI, the source gNB 1101 includes the received needForGapsInfoNR as needForGapsInfoNR in HandoverPreparationInformation message.

[0218] In an embodiment herein, if the source gNB 1101 has received needForGapsInfoNR in RRCSetupComplete / RRCReconfigurationComplete / RRCResumeComplete / HandoverPreparationInformation after musim-NeedForGapsInfoNR in UAI, the source gNB 1101 includes the received musim-NeedForGapsInfoNR as needForGapsInfoNR in the HandoverPreparationInformation message.

[0219] In an embodiment herein, TS 38.331 includes the following, as depicted in table 5.

[0220]

[0221] Table 5

[0222] In an embodiment herein, if the source gNB 1101 has received needForGapsInfoNRneedForGapsInfoNR in RRCSetupComplete / RRCReconfigurationComplete / RRCResumeComplete / HandoverPreparationInformation before musim-NeedForGapsInfoNR in UAI, the source gNB 1101 excludes musim-NeedForGapsInfoNR in the UE Assistance Information (i.e., ueAssistanceInformation field in HandoverPreparationInformation) in HandoverPreparationInformation message and includes needForGapsInfoNR field with the needForGapsInfoNR value received in RRCSetupComplete / RRCReconfigurationComplete / RRCResumeComplete / HandoverPreparationInformation in the HandoverPreparationInformation message.

[0223] In an embodiment herein, if the source gNB 1101 has received needForGapsInfoNR in RRCSetupComplete / RRCReconfigurationComplete / RRCResumeComplete / HandoverPreparationInformation after musim-NeedForGapsInfoNR in UAI, the source gNB 1101 includes musim-NeedForGapsInfoNR in the UE Assistance Information (i.e., ueAssistanceInformation field in HandoverPreparationInformation) in HandoverPreparationInformation message. In yet another embodiment herein, the source gNB 1101 may also exclude needForGapsInfoNR field in HandoverPreparationInformation message.

[0224] In an embodiment herein, if the target gNB 1102 has received information that measurement gaps are required for measuring one or more frequencies (for example, needForGapsInfoNR in HandoverPreprationInformation or musim-NeedForGapsInfoNR in the UEAssistanceInformation in the HandoverPreprationInformation message) due to MUSIM operations and information that the NCSG is required for the measurements of same frequencies from the source gNB 1101 (for example, NeedForGapNCSG-InfoNR) through HandoverPreparationInformation message, the target gNB 1102 configures measurement gaps for the measurements for those frequencies.

[0225] In an embodiment herein, if the target gNB 1102 has received information that measurement gaps are required for the measurements for one or more serving cells (for example, needForGapsInfoNR in HandoverPreprationInformation or musim-NeedForGapsInfoNR in the UE Assistance Information) due to MUSIM operations and that the interruption is required for the same serving cells (for example, NeedForInterruptionInfoNR) through the HandoverPreparationInformation message, the target gNB 1102 configures measurement gaps for the measurements for those serving cells.

[0226] FIG. 13 is a flowchart depicting the process of managing handover for a UE from a source gNB to a target gNB. In step 1301, the source gNB 1101 prepares a handover request for the UE 1103. In step 1302, the source gNB 1101 includes at least one measurement gap requirement information of the UE for one or more NR target bands in an AS-Context, wherein the AS-Context is a HandoverPreparationInformation message. The at least one measurement gap requirement information comprises last received of one of a NeedForGapsInfoNR, or musim-NeedForGapsInfoNR from the UE 1103. The measurement gap requirement information is one of needForGapsInfoNR in RRCReconfigurationComplete message, needForGapsInfoNR in RRCResumeComplete message or musim-needForGapsInfoNR in UEAssistanceInformation message that is last reported by the UE. In step 1303, the source gNB 1101 provides the AS-Context to the target gNB 1102. The various actions in method 1300 may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some actions listed in FIG. 13 may be omitted.

[0227] FIG. 14 depicts the source gNB. The source gNB 1101, as depicted, comprises a processing module 1401, at least one memory 1402, and at least one transceiver 1403.

[0228] The processing module 1401 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 1401 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).

[0229] In an embodiment herein, the at least one transceiver 1403 is configured to enable communication between the source gNB 1101, and at least one external entity (such as, but not limited to, the target gNB 1102, the UE 1103, and so on) through a network or cloud. The transceiver 1403 through which the source gNB 1101 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 1403 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), or Worldwide Interoperability for Microwave Access (WiMAX), according to the usage environment.

[0230] In the embodiment shown herein, the at least one memory 1402 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 1402 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 1402 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 1402 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 1402 is non-movable. In certain examples, a non-transitory storage medium may store data that can, over time, change (e.g., in Random Access Memory (RAM) or cache).

[0231] The processing module 1401 can prepare a handover request for the UE 1103, via the transceiver 1403. The processing module 1401 can include at least one measurement gap requirement information of the UE for one or more NR target bands in an AS-Context, wherein the AS-Context is a HandoverPreparationInformation message, wherein the at least one measurement gap requirement information comprises last received of one of a NeedForGapsInfoNR, or musim-NeedForGapsInfoNR from the UE 1103. The measurement gap requirement information is one of needForGapsInfoNR in RRCReconfigurationComplete message, needForGapsInfoNR in RRCResumeComplete message or musim-needForGapsInfoNR in UEAssistanceInformation message that is last reported by the UE. The processing module 1401 can provide the AS-Context to the target gNB 1102.

[0232] Need For NCSG reporting:

[0233] In an embodiment herein, if the UE 1103 requires NCSG (network controlled small gaps) for performing interfrequency measurements due to MUSIM operations and the UE 1103 has not informed the network previously that the UE 1103 requires NCSG for performing those interfrequency measurements, the UE 1103 informs the network that it needs gaps for performing those measurements using musim-needForGapsInfoNR. A current serving gNB configures the UE 1103 with measurement gaps for performing those interfrequency measurements.

[0234] In an embodiment herein, if the UE 1103 requires NCSG (network controlled small gaps) for performing interfrequency measurements due to MUSIM operations and the UE 1103has already informed the network previously that the UE 1103 requires NCSG for performing those interfrequency measurements, the UE 1103 avoids informing the network that it needs gaps for performing those measurements using musim-NeedForGapsInfoNR-r18 in the UAI. The serving gNB configures the UE 1103 with NCSG for performing those inter-frequency measurements.

[0235] In an embodiment herein, if the UE 1103 requires NCSG (network controlled small gaps) for performing intrafrequency measurements due to MUSIM operations and the UE 1103has not informed the network previously that the UE 1103 requires NCSG for performing those intrafrequency measurements, the UE 1103 informs the network that it needs gaps for performing those measurements using musim-needForGapsInfoNR. The serving gNB configures the UE 1103 with measurement gaps for performing those intrafrequency measurements.

[0236] In an embodiment herein, if the UE 1103 requires NCSG (network controlled small gaps) for performing intrafrequency measurements due to MUSIM operations and the UE 1103 has already informed the network previously that the UE 1103 requires NCSG for performing those intrafrequency measurements, the UE 1103 avoids informing the network that it needs gaps for performing those measurements using musim-NeedForGapsInfoNR-r18 in the UAI. The serving gNB configures the UE 1103 with NCSG for performing those intrafrequency measurements.

[0237] Need For Interruption reporting:

[0238] In an embodiment herein, if the UE 1103 requires interruption for performing interfrequency measurements due to MUSIM operations and the UE 1103 has not informed the network previously that the UE 1103 requires interruptions for performing those interfrequency measurements, the UE 1103 informs the network that it needs gaps for performing those measurements using musim-needForGapsInfoNR. The serving gNB configures the UE 1103 with measurement gaps for performing those interfrequency measurements.

[0239] In an embodiment herein, if the UE 1103 requires interruptions for performing interfrequency measurements due to MUSIM operations and the UE 1103 has already informed the network previously that the UE 1103 requires interruptions for performing those interfrequency measurements, the UE 1103 avoids informing the network that it needs gaps for performing those measurements using musim-NeedForGapsInfoNR-r18 in the UAI. The serving gNB configures the UE 1103 with interruptions for those frequencies.

[0240] In an embodiment herein, if the UE 1103 requires interruption for performing interfrequency measurements due to MUSIM operations and the UE 1103has not informed the network previously that the UE 1103 requires interruptions for performing those interfrequency measurements, the UE 1103 informs the network that it needs gaps for performing those measurements using musim-needForGapsInfoNR. The serving gNB configures the UE 1103 with measurement gaps for performing those interfrequency measurements.

[0241] In an embodiment herein, if the UE 1103 requires interruptions for performing inter-frequency measurements due to MUSIM operations and the UE 1103 has already informed the network previously that the UE 1103requires interruptions for performing those interfrequency measurements, the UE 1103 avoids informing the network that it needs gaps for performing those measurements using musim-NeedForGapsInfoNR-r18 in the UAI. The gNB configures the UE 1103 with interruptions for those frequencies.

[0242] Any embodiments pertaining to CG-Config / CG-ConfigInfo / HandoverPreparationInformation / musim-GapConfigInfo / musim-CapRestrictionInfo / nr-NeedForGap-Reporting-r16 / NeedForGapsInfoNR / musim-NeedForGapsInfoNR / UEAsistanceInformation etc. are applicable to any information elements with a similar functionality used in any technology (such as, but not limited to, 6G).

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

[0244] The embodiments disclosed herein describe methods and systems for managing operations of MUSIM devices. 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.

[0245] Accordingly, the embodiments herein provide a method performed by a fist node for managing inter-node Radio Resource Control (RRC) messages in a dual connectivity scenario in a wireless communication network. The method comprises verifying whether there is a change in a configuration of at least one first field. The method comprises, in case that there is a change in the configuration of the at least one first field, providing an inter-node RRC message to a second node comprising a full configuration of the at least one first field. The method comprises, in case that there is no change in the configuration of the at least one first field, providing the inter-node RRC message to the second node without the configuration of the at least one first field.

[0246] In an embodiment, the inter-node RRC message comprises at least one of CG-Config or CG-ConfigInfo.

[0247] In an embodiment, the at least one first field comprises at least one of musim-GapConfigInfo-r18 or musim-CapRestrcitionInfo-r18.

[0248] In an embodiment, the inter-node RRC message comprises other fields in case that there is no change in a configuration of the other fields or in case that there is a change in a configuration of the other fields.

[0249] Accordingly, the embodiments herein provide a method performed by a second node for managing inter-node Radio Resource Control (RRC) messages in a dual connectivity scenario in a wireless communication network. The method comprises receiving, by a second node, an inter-node Radio Resource Control (RRC) message from a first node. The method further comprises updating, by the second node, a configuration of at least one first field, in case that the configuration of the at least one first field is included in the inter-node RRC message; and maintaining, by the second node, a configuration of the at least one first field, in case that the configuration of the at least one first field is not included in the inter-node RRC message.

[0250] Accordingly, the embodiments herein provide a node in a wireless communication network, the node comprising a processing module; a memory; and a transceiver. The processing module is coupled with the memory, and the transceiver, and configured to verify whether there is a change in a configuration of at least one first field. The processing module is configured to, in case that there is a change in the configuration of the at least one first field, providing an inter-node RRC message to a second node comprising a full configuration of the at least one first field. The processing module is configured to, in case that there is no change in the configuration of the at least one first field, providing the inter-node RRC message to the second node without the configuration of the at least one first field.

[0251] Accordingly, the embodiments herein provide a node in a wireless communication network, the node comprising a processing module; a memory; and a transceiver. The processing module is coupled with the memory, and the transceiver, and configured to receive an inter-node Radio Resource Control (RRC) message from a first node. The processing module is further configured to update the configuration of the at least one first field, in case that the configuration of the at least one first field is included in the inter-node RRC message; and maintain a configuration of the at least one first field, if the configuration of the at least one first field is not included in the inter-node RRC message.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 (800) performed by a first node (501) for managing inter-node Radio Resource Control (RRC) messages in a dual connectivity scenario in a wireless communication network, the method comprising:verifying whether there is a change in a configuration of at least one first field;in case that there is a change in the configuration of the at least one first field, providing (805) an inter-node RRC message to a second node (502) comprising a full configuration of the at least one first field (803), andin case that there is no change in the configuration of the at least one first field, providing (805), the inter-node RRC message to the second node (502) without the configuration of the at least one first field.2.The method, as claimed in claim 1, wherein the inter-node RRC message comprises at least one of CG-Config or CG-ConfigInfo.3.The method, as claimed in claim 1, wherein the at least one first field comprises at least one of musim-GapConfigInfo-r18 or musim-CapRestrictionInfo-r18.4.The method, as claimed in claim 1,wherein the inter-node RRC message comprises other fields in case that there is no change in a configuration of the other fields or in case that there is a change in a configuration of the other fields.5.A method (800) performed by a second node (502) for managing inter-node Radio Resource Control (RRC) messages in a dual connectivity scenario in a wireless communication network, the method comprising:receiving (806) an inter-node RRC message from a first node (501);updating (808) a configuration of at least one first field, in case that the configuration of the at least one first field is included in the inter-node RRC message; andmaintaining (809) the configuration of the at least one first field, in case that the configuration of the at least one first field is not included in the inter-node RRC message.6.The method, as claimed in claim 5, wherein the inter-node RRC message comprises at least one of CG-Config or CG-ConfigInfo.7.The method, as claimed in claim 5, wherein the at least one field comprises at least one of musim-GapConfigInfo-r18 or musim-CapRestrictionInfo-r18.8.The method, as claimed in claim 5, wherein the method comprises releasing configuration of other fields in the inter-node RRC message, if the configuration of other fields in the inter-node RRC message are not included in the received inter-node RRC message.9.The method, as claimed in claim 5,in case that the configuration of the at least one first field is not included in the inter-node RRC message, applying the maintained configuration of the at least one first field.10.A node (502) in a wireless communication network, the node (502) comprising:a processing module (1001);a memory (1002); anda transceiver (1003),wherein the processing module (1001) is coupled with the memory (1002), and the transceiver (1003), and configured to:receive an inter-node Radio Resource Control (RRC) message from a first node (501);update a configuration of at least one first field, in case that the configuration of the at least one first field is included in the inter-node RRC message; andmaintain the configuration of the at least one first field, in case that the configuration of the at least one first field is not included in the inter-node RRC message.11.The node, as claimed in claim 10, wherein the inter-node RRC message comprises at least one of CG-Config or CG-ConfigInfo.12.The node, as claimed in claim 10, wherein the at least one field comprises at least one of musim-GapConfigInfo-r18 or musim-CapRestrictionInfo-r18.13.The node, as claimed in claim 10, wherein the processing module (1001) is configured to release configuration of other fields in the inter-node RRC message, if the configuration of other fields in the inter-node RRC message are not included in the received inter-node RRC message.14.The node, as claimed in claim 10, wherein the processing module (1001) is configured to release apply the maintained configuration of the at least one first field in case that the configuration of the at least one first field is not included in the inter-node RRC message.

Images