Method and system for preventing de-synchronization of secondary node key in wireless communication system

Abstract

The disclosure relates to a 5G or 6G communication system for supporting a higher data transmission rate. The method performed by a secondary node (SN) in a wireless communication system includes receiving, from a user equipment (UE), a user plane (UP) traffic; receiving, from the UE, a SN reconfiguration complete message through a master node (MN) after receiving the UP traffic, wherein the SN reconfiguration complete message includes a first SN counter value associated with a first security key; identifying a second security key corresponding to a second SN counter value associated with the SN; determining a mismatch of the first security key based on the second security key; and in case that there is no mismatch of the first security key, deleting the second security key and the second SN counter value.

Description

METHOD AND SYSTEM FOR PREVENTING DE-SYNCHRONIZATION OF SECONDARY NODE KEY IN WIRELESS COMMUNICATION SYSTEM

[0001] Embodiments disclosed herein relate to wireless communication networks, and more particularly to methods and systems for preventing a de-synchronization of a secondary node key in the wireless communication networks.

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

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

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

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

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

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

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

[0009] Accordingly, the embodiments herein provide a method for preventing de-synchronization of a secondary node key in a wireless network. The method performed by a secondary node (SN) in a wireless communication system includes receiving, from a user equipment (UE), a user plane (UP) traffic; receiving, from the UE, a SN reconfiguration complete message through a master node (MN) after receiving the UP traffic, wherein the SN reconfiguration complete message includes a first SN counter value associated with a first security key; identifying a second security key corresponding to a second SN counter value associated with the SN; determining a mismatch of the first security key based on the second security key; and in case that there is no mismatch of the first security key, deleting the second security key and the second SN counter value.

[0010] Accordingly, the embodiments herein provide an SN for preventing de-synchronization of a secondary node key in a wireless network. The SN A secondary node (SN) in a wireless communication system includes a transceiver; and one or more processors coupled to the transceiver and configured to: receive, from a user equipment (UE), a user plane (UP) traffic, receive, from the UE, a SN reconfiguration complete message through a master node (MN) after receiving the UP traffic, wherein the SN reconfiguration complete message includes a first SN counter value associated with a first security key, identify a second security key corresponding to a second SN counter value associated with the SN, determine a mismatch of the first security key based on the second security key; and in case that there is no mismatch of the first security key, delete the second security key and the second SN counter value.

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

[0012] FIG. 1 illustrates a scenario of selective CPAC in a wireless communication system;

[0013] FIG. 2a and FIG. 2b illustrate a source MN initiated procedure for SCG selective activation in a wireless communication system;

[0014] FIG. 3 illustrates a security mechanism and procedures for SCPAC in a wireless communication system;

[0015] FIG. 4a and FIG. 4b illustrate a security gap in procedure for SCPAC in a wireless communication system;

[0016] FIG. 5 illustrates security mechanisms and procedures for SCPAC, according to an embodiment of the disclosure;

[0017] FIG. 6 illustrates various hardware components of a secondary node (SN) entity, for selecting the security key associated with the SN counter value, according to an embodiment of the disclosure;

[0018] FIG. 7 illustrates a flow chart illustrating a preventing de-synchronization of secondary node key by a secondary node (SN), according to an embodiment of the disclosure; and

[0019] FIG. 8 illustrates a flow chart illustrating a preventing de-synchronization of secondary node key by the SN, according to an embodiment of the disclosure.

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

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

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

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

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

[0025] Any of the functions or operations described herein can be processed by one processor or a combination of processors. The one processor or the combination of processors is circuitry performing processing and includes circuitry like an application processor (AP, e.g. a central processing unit (CPU)), a communication processor (CP, e.g., a modem), a graphics processing unit (GPU), a neural processing unit (NPU) (e.g., an artificial intelligence (AI) chip), a Wi-Fi chip, a Bluetooth® chip, a global positioning system (GPS) chip, a near field communication (NFC) chip, connectivity chips, a sensor controller, a touch controller, a finger-print sensor controller, a display driver integrated circuit (IC), an audio CODEC chip, a universal serial bus (USB) controller, a camera controller, an image processing IC, a microprocessor unit (MPU), a system on chip (SoC), an IC, or the like.

[0026] The embodiments herein achieve a method for preventing de-synchronization of a secondary node key in a wireless network. The method includes receiving, by a secondary node (SN), a secondary node (SN) reconfiguration complete message from a User Equipment (UE) through a master node (MN). The SN reconfiguration complete message includes a security key associated with a SN counter value. Further, the method includes selecting, by the secondary node, the security key associated with the SN counter value received in SN reconfiguration complete message. Further, the method includes activating, by the secondary node, a User Plane (UP) protection after computing a required UP key. Further, the method includes determining, by the secondary node, that the security key matches with the UP key. Further, the method includes deleting, by the secondary node, the security key associated with the SN counter value based on the determination.

[0027] The embodiments herein achieve methods and systems for preventing the de-synchronization of the KSNkey in wireless communication networks. The SN shall receive RRC Reconfiguration Complete message prior to successful Random Access procedure towards the SCG. The SN shall maintain the configured KSNand corresponding SN counter value until KgNBre-keying is triggered and / or KSNupdate is triggered due to Packet Data Convergence Protocol　(PDCP) COUNT wrap around. The SN shall delete the configured KSNand corresponding SN counter value only after determining that the UE is also using the same key (verifying the key mismatch). The SN shall delete the configured KSNand corresponding SN counter value only after determining there is no key mismatch. The SN shall initiate a timer (e.g., discard timer or the like) upon completing RACH procedure, for receiving the RRC Reconfiguration Complete message from the UE via MN. Upon receiving the RRC Reconfiguration Complete message from the UE via the MN, the SN stops the timer. If the timer runs out, then the SN may initiate an error message to the UE and / or terminate the connection.

[0028] For selective SCG activation with one or more candidate PScells (including from one or more SNs), the following solution can be considered. The RACH is performed after successful RRC reconfiguration complete message.

[0029] In an embodiment, the SN shall delete the configured KSN and corresponding SN counter value only after determining that the UE is also using the same key (verifying the key mismatch) i.e., after ensuring there is no key mismatch. In another embodiment, if there is no reception of RRC Reconfiguration Complete message from the UE via MN, but there is reception of UP traffic from the UE (after RACH procedure), then the SN may initiate an error message to the UE and / or terminate the UE connection.

[0030] The proposed method uses the secondary node (SN) stores a sequence of SN counter values with corresponding security keys and allocates data radio bearers (DRBs) compatible with the UE's security capability. Moreover, the SN confirms resource availability to the master node (MN) and ensures key consistency by receiving the used SN counter in the reconfiguration complete message. Additionally, the SN retains the security key until a successful RRC Reconfiguration Complete message, preventing premature key deletion and enhancing security. If the message isn't received, an error response terminates the connection, ensuring network integrity.

[0031] The embodiments herein achieve a method and system for preventing the de-synchronization of the KSNkey in wireless communication networks, by ensuring secure key management and synchronization between the User Equipment (UE), Master Node (MN), and Secondary Node (SN). By storing a sequence of SN counter values and corresponding security keys, the SN can maintain security continuity during node transitions. The method ensures that allocated Data Radio Bearers (DRBs) are compatible with UE security capabilities, preventing mismatches in encryption and integrity protection. Additionally, by transmitting an Addition / Modification Acknowledge message to the MN, the SN ensures resource availability and synchronization of DRB identifiers.

[0032] The principal object of embodiments herein is to disclose methods and systems for preventing the de-synchronization of a secondary node key in a wireless communication network.

[0033] Another object of embodiment herein is to disclose select the security key associated with the SN counter value received in a SN reconfiguration complete message.

[0034] Another object of embodiment herein is to disclose an activated User Plane (UP) protection after computing a required UP key.

[0035] Another object of embodiments herein is to delete the security key associated with the SN counter value upon determining the security key matches with the UP key.

[0036] Another object of embodiments herein is to perform at least one of: initiating an error message to the UE (300) and terminating a UE (300) connection based on the determination, when the secondary node does not receive a RRC reconfiguration complete message from the User Equipment (UE) through a master node (MN), and the secondary node does not receive a user plane (UP) traffic from the UE.

[0037] Another object of embodiments herein is to define SN behavior on maintenance of stored KSNkey and associated SN counter value.

[0038] Yet another object of embodiments herein is to mandate the order of procedure for receiving successful RRC reconfiguration complete message before initiating and / or accepting Random access request.

[0039] Yet another object of embodiments herein is to buffer the uplink User plane traffic until the RRC reconfiguration complete is received with an SN counter value and key mismatch is verified.

[0040] Another object of embodiments herein is to define a discard timer associated with the KSNand SN Counter value for the deletion of the stored security context.

[0041] Referring now to the drawings, and more particularly to FIGS. 1 through 8, where similar reference characters denote corresponding features consistently throughout the figures, there are shown embodiments.

[0042] In the present landscape of the 3rd Generation Partnership Project　(3GPP) Release-18, Conditional PSCell Addition and Change (CPAC) is a key enhancement aimed at improving the flexibility and efficiency of Secondary Cell Group (SCG) management in dual connectivity scenarios. The CPAC enables a User Equipment (UE) to pre-configure candidate secondary cells, allowing for faster and more seamless transitions when a network determines a need for an SCG change. This mechanism reduces signaling overhead and enhances mobility performance, especially in scenarios with frequent handovers. A scenario of the selective CPAC is considered in the 3GPP, where the UE initially operates in single connectivity with a Master Node (MN). In legacy procedures, once the Conditional PSCell Addition (CPA) towards a Secondary Node (SN#1, Cell B) is completed, the initially configured CPA settings, including all candidate cells, are released, as shown in FIG. 1.

[0043] FIG. 1 illustrates a scenario of selective CPAC in a wireless communication system.

[0044] If the network later needs the UE to perform the CPA or Conditional PSCell Change (CPC) towards another secondary node (SN#2, Cell C), the network must reconfigure the CPA / CPC settings again. In Release-18, similar to the legacy approach, Cell A and Cell B can be pre-configured in the UE's CPA configuration, but the UE may retain the SCG CPC pre-configuration for each candidate SCG even after executing CPA, enabling a more efficient and streamlined handover process.

[0045] The UE continuously monitors whether any Conditional Primary Cell (CPC) conditions are met for selecting a subsequent CPC among the pre-configured candidate Secondary Cell Groups (SCGs). When the UE moves into the coverage of Cell B, it can be added as the Primary Secondary Cell (PSCell) while retaining the Conditional PSCell Addition (CPA) and CPC configurations related to SN#2 of Cell C. After adding Cell B as the PSCell, the CPA / CPC configuration remains active, ensuring seamless transition and flexibility in SCG management. Similarly, when the UE later activates SN#2 of Cell C, it does so without releasing the configuration of SN#1 of Cell B, so as to allow efficient multi-node connectivity and reduce unnecessary reconfiguration overhead. This mechanism enhances mobility robustness and optimizes network performance.

[0046] After executing a conditional reconfiguration, the UE retains stored conditional reconfigurations for other candidate PSCells, allowing it to switch between these cells multiple times, including returning to a previously selected PSCell, without requiring a new reconfiguration from the network. In this process, the UE derives the KSN(Secondary Node Key) from the SN counter included in the executed conditional reconfiguration. This ensures that the UE uses the same KSNwhenever it reconnects to a specific cell (e.g., Cell C), even after moving to another secondary node (SN#2). If the same SN counter value is included in the conditional reconfiguration for multiple cells (e.g., Cell C and Cell B), the UE maintains the same KSNbefore and after transitioning to SN#2 (for example: steps 12-13, FIG. 2), ensuring seamless security continuity during mobility. The MN (200) configures UE (300) with candidate SCG configuration(s) for one or multiple candidate SN(s) i.e., the UE (300) is configured with 'N' conditional configuration for N PSCell change.

[0047] FIG. 2 illustrates a source MN initiated procedure for SCG selective activation in a wireless communication system.

[0048] In step 201a-201b, MN (200) initiates the addition of SN by sending an SN Addition request to the SN (i.e., first target SN 102a, and second target SN 102b, respectively). The request can be directed to either the first target SN (102a) or the second target SN (102b).

[0049] In step 202a-202b, the MN (200) receives the SN addition request acknowledgement from the SN (i.e., first target SN 102a or second target SN 102b). This acknowledgment includes the confirmation of selected techniques, User Plane (UP) integrity protection, and encryption settings.

[0050] In step 203, the MN (200) sends a RRC reconfiguration to the UE (300). After receiving the acknowledgment, the MN (200) transmits an RRC Reconfiguration message to the UE (300), instructing it to apply the necessary configuration changes.

[0051] In step 204, UE (300) sends a RRC reconfiguration complete message to the MN (200). The UE (300) processes the received RRC Reconfiguration message and sends an RRC Reconfiguration Complete message back to the MN (200), confirming successful application of the reconfiguration.

[0052] In step 205, the UE (300) performs the CPC evaluation. The UE (300) performs a Conditional PSCell Change (CPC) evaluation to determine if the PSCell change is needed based on predefined conditions.

[0053] In step 206, the UE (300) sends the RRC reconfiguration complete message to the MN (200) for each candidate target PSCell ID of SN (for example first target SN 102a).

[0054] In step 207, the MN (200) sends the SN reconfiguration complete message to the SN (for example first target SN 102a). In step 8, the UE (300) performs the CPC evaluation to assess whether additional changes are required.

[0055] Instep 209, the UE (300) sends the RRC reconfiguration complete message to the MN (200) confirming the updated configuration based on the CPC evaluation. In step 210, the MN (200) sends SN reconfiguration complete message to the SN (for example first target SN 102a).

[0056] In step 211, the UE (300) performs another CPC evaluation to verify whether further adjustments are necessary. In step 212, Following the CPC evaluation, the UE (300) sends another RRC reconfiguration complete message to the MN (200), confirming the final reconfiguration. In step 213, the MN (200) sends the final SN reconfiguration complete message to SN (for example first target SN 102a) indicating that the configuration process is successfully completed.

[0057] However, using the same KSNis against the existing security procedure defined for PSCell change. Further, as described in technical specification (TS) 37.340, the order the UE sends the MN RRC Reconfiguration Complete message and performs the Random Access procedure towards the SCG is not defined. The successful RA procedure towards the SCG is not required for successful completion of the RRC Reconfiguration procedure. But when there is a mismatch of the SN counter value used at the UE (300) and the SN (102), and suppose the UE (300) sends the next unused SN counter but at the SN (102) the previous SN counter value was not utilized, then the SN (102) will use the wrong key on the user plane traffic, unless it receives the SN counter value in the RRC Connection Reconfiguration to identify the mismatch of the Key in use and rectify it. If the UP traffic is encrypted and not integrity protected, then the SN (102) can identify the key mismatch only after receiving the RRC Reconfiguration Complete message.

[0058] It is possible for a malicious UE to initiate the RACH procedure using the assigned C-RNTI of a victim UE and start User Plane traffic exchange with the SN (102), as to delete the security information / parameters (SN Counter values and corresponding KSN keys) of the victim UE in the SN (102). Once the SN (102) uses the security information / parameters (SN Counter values and corresponding KSN keys) of the victim UE for the fake UP traffic generated by the malicious UE (300), the SN (102) might delete the security information / parameters (SN Counter values and corresponding KSN keys) of the victim UE. If the victim UE initiate connection with the SN then security parameters are not available with the SN to establish a successful connection establishment, which leads to out-of-service or the UE cannot establish connection with the SN (102).

[0059] FIG. 3 illustrates the sequence diagram for the security mechanism and procedures for SCPAC to address the aforementioned issue of key re-use discussed in FIG. 2.

[0060] Upon successfully evaluating the CPAC configuration, the UE (300) selects a target SN (102) and derives the KSNkey using the first unused SN counter value from the sequence configured by a MN (200) in the RRC Reconfiguration message. Further, the UE (300) then transmits the used SN counter value to the MN (200) as part of the RRC Reconfiguration process and performs the Random Access (RACH) procedure with the selected SN (102). Following this, the UE (300) sends an RRC Reconfiguration Complete message to the MN (200), while also attempting the Random Access procedure towards the SCG. However, the successful completion of the RA procedure towards the SCG is not a prerequisite for the successful completion of the overall RRC Reconfiguration procedure.

[0061] As shown in FIG. 3, In step 301, the UE (300) and the MN (200) establishes the RRC.

[0062] In steps 302a-302b, the MN (200) sends a SN Addition / Modification Request to each candidate target SN (102a or 102b) over the Xn-C to negotiate the available resources, configuration, and techniques at each candidate target SN (for example first target SN 102a or second target SN 102b), respectively. This request is used to negotiate the availability of resources, configuration parameters, and processing mechanisms at each candidate target SN, ensuring compatibility with the UE's requirements.

[0063] In steps 303a-303b, the SNs (102) store the received sequence of SN Counter values and corresponding KSNkeys of the UE (300) and allocates the necessary resources. The target first SN (102) and the target second SN chooses the first unused KSN, the capability negotiation, the selection, and the UP protection activation.

[0064] In steps 304a and 304b, the SN (102) sends the SN Addition / Modification Acknowledge to the MN (200) indicating availability of requested resources and the identifiers. The SN Addition / Modification Acknowledge indicates the availability of the requested resources and provides the relevant identifiers required for further configuration.

[0065] In step 305, the MN (200) sends the RRC connection Reconfiguration Request to the UE (300), instructing it to configure the new DRBs for the selected SN (102). The MN (200) also includes all candidate SCG configuration(s) for one or multiple candidate SN(s) (102) in the same RRC Reconfiguration Request message as the one that activates the new KNG-RANto the UE (300). This message instructs the UE (300) to configure the new Data Radio Bearers (DRBs) for the selected SN (102). The MN (200) also includes configuration details for all candidate Secondary Cell Group (SCG) setups corresponding to one or more candidate SNs (102) within the same RRC Reconfiguration Request message. Additionally, this message activates the new Key for Next Generation RAN (KNG-RAN) at the UE (300).

[0066] In step 306, the UE (300) accepts the RRC connection Reconfiguration Request after validating its integrity using the KRRCintof the MN (200). If the integrity check is successful, the UE (300) accepts the reconfiguration.

[0067] In step 307, the UE (300) selects a target-SN (for example fisrt target SN 102a), the UE (300) shall choose the first unused SN Counter value in the SN Counter values sequence in the SCG configuration for the selected candidate target-SN (102) and compute the KSN.

[0068] In step 308, UE (300) sends the RRC connection Reconfiguration Complete to the MN (200), including the SN Counter value used in the derivation of the KSN. This message confirms the successful reconfiguration and includes the SN Counter value that was used in deriving the KSNkey.

[0069] In step 309, the MN (200) shall send the SN Reconfiguration Complete, including the SN Counter value received in step 308, to the target SN (102) over the Xn-C to inform the target SN (102) of the configuration result.

[0070] In step 310, The SN (102) shall activate encryption / decryption and integrity protection / verification with the UE (300) upon receiving the SNReconfiguration Complete message or the Random Access request from the UE (300). Specifically, it enables encryption, decryption, integrity protection, and integrity verification for secure communication with the UE (300).

[0071] In step 311, SN (102) activates the UP protection upon receiving the Random Access request from the UE (300), then the target SN (102) shall select the first unused KSNkey of the UE (300) in the sequence and computing the needed UP keys.

[0072] The MN (200) configures UE (300) with candidate SCG configuration(s) for one or multiple candidate SN(s) (102) i.e., the UE (300) is configured with 'N' conditional configuration for N PSCell change. When UE accesses to SN#1 (switching back from SN#2, step 312 in Fig.1) based on the CPC evaluation, the UE (300) selects an unused counter and generates KSNusing it. The UE sends the used SN counter (used for generating KSN) to the MN in RRC Connection Reconfiguration and performs RACH with the target SN.

[0073] But when there is a mismatch of the SN counter value used at the UE (300) and the SN (102), and suppose UE (300) sends the next unused SN counter but at the SN (102) the previous SN counter value was not utilized, then the SN (102) will use the wrong key on the user plane traffic, unless the SN (102) receives the SN counter value in the RRC Connection Reconfiguration as shown in FIG. 3 to identify the mismatch of the Key in use and rectify it. If the UP traffic is encrypted and not integrity protected, then the SN (102) can identify the key mismatch only after receiving the RRC Reconfiguration Complete message.

[0074] Further, a malicious UE can exploit the Random Access Channel (RACH) procedure by using the allocated C-RNTI of a victim UE (300) to initiate User Plane (UP) traffic exchange with the Secondary Node (SN) (102). This unauthorized activity can lead to the deletion of the victim UE's security parameters, including SN Counter values and corresponding KSNkeys, stored at the SN (102). When the SN processes the fake UP traffic generated by the malicious UE (300), it may overwrite or remove the security information associated with the victim UE (300). Consequently, if the victim UE (300) later attempts to establish a connection with the SN (102), the necessary security parameters will no longer be available, preventing a successful connection and potentially causing service unavailability for the victim UE.

[0075] FIG. 4 illustrates a security gap in procedure for SCPAC in a wireless communication system.

[0076] As shown in FIG. 4, In step 401, the UE (300) and the MN (200) establishes the RRC connection.

[0077] In steps 402a and 402b, the MN (200) sends the SN Addition / Modification Request to each candidate target SN over the Xn-C to negotiate the available resources, configuration, and modules at each candidate target SN (for example, first target SN 102a). The MN (200) assigns a sequence of distinct SN Counter values per candidate target SN during the SCPAC procedure. The MN (200) derives the KSNkeys corresponding to the sequence of SN Counter values from the KNG-RANof the UE (300). The MN (200) delivers the sequence of SN Counter values and corresponding KSNkeys of the UE (300) to the respective candidate target SN (for example, first target SN 102a). The UE (300) security capabilities and the UP security policy received from the SMF shall also be sent to SN (102).

[0078] In steps 403a-403b, the candidate target SNs (for example first target SN 102a) store the received sequence of SN Counter values and corresponding KSNkeys of the UE (300) and allocates the necessary resources and chooses the ciphering techniques and integrity techniques which has the highest priority from its configured list and is also present in the UE (300) security capability.

[0079] In steps 404a and 404b, the respective target SN (first target SN 102 or second target SN 102b) sends SN Addition / Modification Acknowledge to the MN (200) indicating availability of requested resources and the identifiers for the selected technique(s) for the requested DRBs for the UE (300). The UP integrity protection and encryption indications sent to the MN (200).

[0080] In step 405, the MN (200) sends the RRC connection Reconfiguration Request to the UE (300), instructing it to configure the new DRBs for the selected target SNs (102). The MN (200) also includes all candidate SCG configuration(s) for one or multiple candidate SN(s) in the same RRC Reconfiguration Request message as the one that activates the new KNG-RANto the UE.

[0081] In step 406, the UE (300) accepts the RRC connection Reconfiguration Request after validating its integrity using the KRRCintof the MN (200).

[0082] In step 407, the UE (300) selects a target SN (for example first target SN 102a), the UE (300) chooses the first unused SN Counter value in the SN Counter values sequence in the SCG configuration for the selected candidate target SN (102) and computes the KSN. The UE (300) also compute the UP keys and activate the UP protection per the indications received for the associated DRBs.

[0083] In step 408, the UE (300) sends the RRC connection Reconfiguration Complete to the MN (200), including the SN Counter value used in the derivation of the KSN.

[0084] In step 409, MN (200) transmits the SN Reconfiguration Complete, including the SN Counter value received in step 408, to the target SN (102) over the Xn-C to inform the target SN (102) of the configuration result.

[0085] In step 410, the SN (102) activates encryption / decryption and integrity protection / verification with the UE (300) upon receiving the SN Reconfiguration Complete message or the Random Access request from the UE. If the SN (102) activates the UP protection upon receiving the SN Reconfiguration Complete message, then the SN chooses the KSNkey of the UE (300) corresponding to the SN Counter value received in SN Reconfiguration Complete message and activates the UP protection after computing the needed UP keys.

[0086] In step 411, the UE (300) generates KSNusing next unused SN counter value (second SN counter).

[0087] In step 412, the SN activates the UP protection upon receiving the Random Access request from the UE (300), then the target SN (102) shall select the first unused KSNkey of the UE (300) in the sequence and computing the needed UP keys.

[0088] In an embodiment herein, if the UE (300) and SN completes the RACH procedure and starts exchanging the UP traffic (only confidentiality protected (encrypted) and integrity protection is not applied) before receiving the RRC Reconfiguration Complete message, then the SN buffers the received UP traffic, till it receives the RRC Reconfiguration Complete message. Upon determining the appropriate KSN, based on the received SN Counter value in the RRC Reconfiguration Complete message from the UE (300) via MN (200), the SN starts processing the buffered UP traffic using the selected KSNand deletes the selected KSNand related SN counter in the stored configuration.

[0089] In step 413, upon receiving the SN Reconfiguration Complete message, the SN (102) shall determine the KSNmismatch.

[0090] In step 414, The SN (102) shall delete the configured KSNand corresponding SN counter value only after determining that there is no KSNkey mismatch. In case of KSNmismatch, the target SN chooses the KSN key of the UE corresponding to the SN Counter value received in SN Reconfiguration Complete message and activates the UP protection after computing the needed UP keys.

[0091] In an embodiment herein, the UE (300) shall always maintain the unused SN counter value. In an embodiment, the SN shall not delete the KSNand corresponding SN Counter value before the successful RRC Reconfiguration Complete message.

[0092] In an embodiment herein, the SN (102) shall maintain the configured KSNand its corresponding SN counter until the uplink and / or downlink PDCP COUNTs are about to wrap around for any of the SCG DRBs and the Target SN requests the MN to update the KSNkeys over the Xn-C and / or the MN re-keys the KgNB on PDCP COUNTs wrap around.

[0093] In step 415, the SN (102) shall terminate the connection with the UE (300) if the SN (102) does not receive the SN Reconfiguration Complete message. If there is no reception of RRC Reconfiguration Complete message from the UE (300) via MN (200), then the SN (102) may initiate an error message to the UE (300) and / or terminate the UE (300) connection.

[0094] FIG. 5 illustrates security mechanisms and procedures for SCPAC, according to an embodiment of the disclosure.

[0095] The User Equipment (UE) (300) and the Master Node (MN) (200) establish an RRC connection. The MN (200) then negotiates resources with candidate Secondary Nodes (SNs) (102), assigning unique SN Counter values and deriving KSNkeys for each candidate SN. (for example, first target SN 102a) These keys and counters are securely delivered to SNs, enabling them to allocate resources and select encryption and integrity techniques. The MN (200) instructs the UE (300) to configure new Data Radio Bearers (DRBs) while protecting configuration integrity using KRRCint. The UE (300) and SN (for example first target SN 102a or second target SN 102b, as depicted in figure 5) then establish secure communication using derived encryption and integrity protection keys.

[0096] In step 501, the UE (300) and master node (MN) (200) establishes RRC Connection.

[0097] In steps 502a-502b, the MN (200) sends SN Addition / Modification Request message to each candidate SN (example first target SN and second target SN) over the Xn-C to negotiate the available resources, configuration, and techniques at each candidate SN (example first target SN and second target SN). The MN (200) assigns a sequence of distinct SN Counter values per candidate SN during the SCPAC procedure. The MN (200) derives the KSNkeys corresponding to the sequence of SN Counter values from the KNG-RANof the UE (300). The MN (200) delivers the sequence of SN Counter values and corresponding KSNkeys of the UE (300) to the respective candidate SN. The UE (300) security capabilities and the UP security policy received from the SMF shall also be sent to SN. In case of PDU split, UP integrity protection and / or ciphering activation decision from MN may be also included.

[0098] In step 503, the candidate SNs (first target SN 102a and second target SN 102b) stores the received sequence of SN Counter values and corresponding KSNkeys of the UE (300) and allocates the necessary resources and chooses the ciphering technique and integrity technique which has the highest priority from its configured list and is also present in the UE (300) security capability

[0099] In steps 504a-504b, the respective SN (for example first target SN 102a) sends SN Addition / Modification Acknowledge message to the MN (200) indicating availability of requested resources and the identifiers for the selected technique(s) for the requested DRBs for the UE (300). The UP integrity protection and encryption indications shall be send to the MN (200).

[0100] In step 505, the MN (200) sends the RRC connection Reconfiguration Request message to the UE (300), instructing it to configure the new DRBs for the selected SNs. The MN (200) also includes all candidate SCG configuration(s) for one or multiple candidate SN(s) in the same RRC Reconfiguration Request message as the one that activates the new KNG-RANto the UE (300). Since the RRC Reconfiguration Request message is sent over the RRC connection between the MN (200) and the UE (300), it is integrity-protected. Hence, the candidate SCG configuration(s) for one or multiple candidate SN(s) cannot be tampered with.

[0101] In step 506, the UE (300) accepts the RRC connection Reconfiguration Request message after validating its integrity using the KRRCintof the MN (200).

[0102] In step 507, the UE (300) selects a SN (for example first target SN 102a or, second target SN 102b), wherein the UE (300) shall choose the first unused SN Counter value in the SN Counter values sequence in the SCG configuration for the selected candidate SN and compute the KSN. The UE (300) also compute the needed UP keys and activate the UP protection per the indications received for the associated DRBs.

[0103] In step 508, the UE (300) sends the RRC connection Reconfiguration Complete message to the MN (200), including the SN Counter value used in the derivation of the KSN.

[0104] In step 509, the MN (200) shall send the SN Reconfiguration Complete message, including the SN Counter value received in step 508, to the SN over the Xn-C to inform the SN of the configuration result.

[0105] In step 510, the SN shall activate encryption / decryption and integrity protection / verification with the UE (300) upon receiving the SN Reconfiguration Complete message or the Random Access request from the UE. If the SN activates the UP protection upon receiving the SN Reconfiguration Complete message, then the SN chooses the KSNkey of the UE corresponding to the SN Counter value received in SN Reconfiguration Complete message and activates the UP protection after computing the needed UP keys.

[0106] In step 511, the SN chooses the KSNkey of the UE (300) corresponding to the SN Counter value received in SN Reconfiguration Complete message and activates the UP protection after computing the needed UP keys, in case of KSNmismatch. The SN shall delete the configured KSNand corresponding SN counter value only after determining that there is no KSNkey mismatch. The SN (102) shall terminate the connection with the UE (300) if the SN (102) does not receive the SN Reconfiguration Complete message. In case the SN (102) activates the UP protection upon receiving the Random Access request from the UE (300), then the SN (102) shall select the first unused KSNkey of the UE (300) in the sequence and computing the needed UP keys. Further, upon receiving the SN Reconfiguration Complete message, the SN (102) shall determine the KSNmismatch.

[0107] In an embodiment herein, if the UE (300) and SN (102) completes the RACH procedure and starts exchanging the UP traffic (only confidentiality protected (encrypted) and integrity protection is not applied) before receiving the RRC Reconfiguration Complete message, then the SN buffers the received UP traffic, till it receives the RRC Reconfiguration Complete message. Upon determining the appropriate KSN, based on the received SN Counter value in the RRC Reconfiguration Complete message from the UE (300) via MN (200), the SN (102) starts processing the buffered UP traffic using the selected KSNand deletes the selected KSNand related SN counter in the stored configuration.

[0108] In an embodiment herein, when the SN (102) receives the Random Access request from the UE (300) before successful RRC Reconfiguration Complete, the SN (102) shall reject the Random Access request from the UE (300).

[0109] In an embodiment herein, when the SN (for example first target SN 102a and / or second target SN 102b) receives the Random Access request from the UE (300) before the RRC Reconfiguration Complete (from the UE (300) via MN (200)), then the SN (example first target SN 102a and / or second target SN 102b) delay / hold the processing of the Random Access request / procedure from the UE (300). Upon receiving the RRC Reconfiguration Complete message (from the UE (300) via MN (200)), the SN determines the appropriate KSNbased on the received SN Count Value and then continues the RACH procedure initiated by the UE (300). If the RACH procedure is timed out, then the UE (300) will initiate the RACH procedure again.

[0110] In an embodiment herein, the SN (102) shall not delete the KSNand corresponding SN Counter value before the successful RRC Reconfiguration Complete message. The UE shall always maintain the unused SN counter value.

[0111] In an embodiment herein, the SN shall maintain the configured KSNand its corresponding SN counter until the uplink and / or downlink PDCP COUNTs are about to wrap around for any of the SCG DRBs and the SN requests the MN to update the KSNkeys over the Xn-C and / or the MN re-keys the KgNBon PDCP COUNTs wrap around.

[0112] In an embodiment herein, the SN (102) maintains a timer (Tdiscard_timer) corresponding to the configured KSNand related SN counter. The timer is assigned for the validity of the stored KSNand related SN counter, when UE (300) generates a first KSNusing the first SN Counter, the UE (300) sends the first SN Counter in the RRC reconfiguration complete message to the MN (200). Here, the timer is assigned and maintained for SN counter value maintenance. The MN (200) forwards the RRC reconfiguration complete message in SN reconfiguration complete message. It is likely that the UE (300) might initiate the RACH procedure with the SN along (simultaneously) or before sending the RRC reconfiguration complete. In such scenario, the SN (300) shall hold the uplink and / or downlink User plane packets until the Tdiscard_timerexpires for the first unused KSNand corresponding SN counter.

[0113] In an embodiment herein, the Tdiscard_timeris associated with receiving successful RRC reconfiguration complete message. When the timer expires (and / or on successful reception of the RRC reconfiguration complete), the SN deletes / discards the first used / unused KSNand SN counter value.

[0114] In an embodiment herein, the SN (102) shall initiate a timer upon completing the RACH procedure with the UE (300), for receiving the RRC Reconfiguration Complete message from the UE (300) via MN (200). Upon receiving the RRC Reconfiguration Complete message from the UE (300) via MN (200), the SN (102) stops the timer. If the timer runs out (if there is no reception of RRC Reconfiguration Complete message from the UE (300) via MN (200)), then the SN (102) may initiate an error message to the UE (300) and / or terminate the UE (300) connection. Further, the SN (102) shall not delete the selected KSNand related SN counter, suspecting the connection might be from a malicious UE (300) and / or might be issue in the connection between the UE (300) and the SN (102) via the MN (200).

[0115] Alternatively, if the timer runs out (if there is no reception of RRC Reconfiguration Complete message from the UE (300) via MN (200)) in the SN (102), then the SN (102) may initiate signalling with the UE (300) via MN (200) to determine the status and SN (102) counter value in use in the UE (300). Upon receiving the message from the SN (102) via MN (200), the UE (300) sends the RRC Reconfiguration Complete message to the SN (102) via MN (200). The SN (102) may restart the timer upon sending the signalling message to the UE (300) via MN (200) for receiving the RRC Reconfiguration Complete message from the UE (300) via MN (200).

[0116] In an embodiment herein, in case of mismatch, the SN (102) shall report the mismatch to the MN (200), the MN (200) shall re-allocate an SN counter (incrementing from the latest SN counter) and configure it to the UE (300) and generate a KSNusing the SN counter and forwards both KSNand corresponding SN counter to the SN (102). The UE (300) uses the new SN counter and indicates the SN counter in the RRC reconfiguration complete to the SN (102). The SN (102) awaits for the RRC reconfiguration complete before activating encryption / integrity protection.

[0117] In an embodiment herein, if integrity protection is enabled for the UP traffic, then the SN (102) can determine the key mismatch when performing the integrity protection check. In case the integrity protection check fails continuously (for example, for a configured number of PDCP PDUs / packets), then the SN (102) can determine the key mismatch. In this case, the SN (102) shall not delete the configured KSNand corresponding SN counter value. In case, if the integrity protection check is successful on the UE's (300) UP traffic, then the SN shall delete the configured KSNand corresponding SN counter value. Alternatively, if the integrity protection check fails continuously in the SN, then the SN may initiate signaling with the UE (300) via MN (200) to determine the status and SN counter value in use in the UE (300). Upon receiving the message from the SN (102) via MN (200), the UE (300) sends the RRC Reconfiguration Complete message to the SN (102) via MN (200).

[0118] In an embodiment herein, if the SN (102) determines that the key mismatch and the configured KSNand corresponding SN counter value are not deleted, then the SN stores the last used PDCP count in the downlink direction and avoid reusing the PDCP count for the KSNand corresponding SN counter value.

[0119] FIG. 6 illustrates various hardware components of the SN (102), according to the embodiments as disclosed herein.

[0120] In an embodiment, the SN (102) includes a processor (110), a memory (120),a SN controller (130), and a transceiver (140). The processor (110) is coupled with the memory (120), the SN controller (130), and the transceiver (140).

[0121] The SN controller (130) configured to receive a secondary node (SN) reconfiguration complete message from the UE (300) through the master node (MN) (200). The SN reconfiguration complete message includes a security key associated with a SN counter value.

[0122] Further, the SN controller (130) selects the security key associated with the SN counter value received in SN reconfiguration complete message. Further, the SN controller (130) is configured to activate the UP protection after computing the required UP key. Further, the SN controller (130) is configured to determine that the security key matches with the UP key. Based on the determination, the SN controller (130) deletes the security key associated with the SN counter value.

[0123] In an embodiment, the SN controller (130) deletes the security key and corresponding SN counter value after determining there is no key mismatch. In an embodiment, the SN controller (130) chooses the security key corresponding to the SN counter value received in the SN reconfiguration complete message.

[0124] In another embodiment, the secondary node controller (230) determines that the secondary node does not receive the SN reconfiguration complete message from the UE (300) through the MN (200), and the secondary node does not receive the UP traffic from the UE (300). In an embodiment, based on the determination, the secondary node controller (230) initiates the error message to the UE (300). In another embodiment, based on the determination, the secondary node controller (230) terminates the UE connection.

[0125] The processor (110) may include one or a plurality of processors. The one or the plurality of processors may be a general-purpose processor, such as a central processing unit (CPU), an application processor (AP), or the like, a graphics-only processing unit such as a graphics processing unit (GPU), a visual processing unit (VPU), and / or an AI-dedicated processor such as a neural processing unit (NPU). The processor (110) may include multiple cores and is configured to execute the instructions stored in the memory (120).

[0126] Further, the processor (110) is configured to execute instructions stored in the memory (120) and to perform various processes. The memory (120) also stores instructions to be executed by the processor (110). The memory (120) may include non-volatile storage elements. Examples of such 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 (120) 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 that the memory (120) 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).

[0127] FIG. 7 is a flow chart (S700) illustrating a method for, preventing de-synchronization of secondary node key (KSN), according to the embodiments as disclosed herein; The operations (S702-S716) are handled by a secondary node (SN) (102).

[0128] At S702, the method includes storing a sequence of secondary node (SN) counter values and corresponding security key. At S704, method includes allocating resources for a data radio bearer (DRBs), wherein the allocated DRBs are compatible with a user equipment (UE) security capability.

[0129] At S706, method includes transmitting an Addition / Modification Acknowledge message to a master node (MN), wherein the Addition / Modification Acknowledge message indicates availability of the allocated resources and the identifiers for the requested DRBs for the UE.

[0130] At S708, method includes receiving a secondary node (SN) reconfiguration complete message from the MN, wherein the SN reconfiguration complete message includes a used SN Counter value associated with a security key. At S710, method includes selecting the security key associated with the SN counter value received in SN reconfiguration complete message

[0131] At S712, method includes activating a User Plane (UP) protection after computing a required UP key. At S714, method includes determining that the security key matches with the UP key.

[0132] At S716, method includes the security key associated with the SN counter value based on the determination. In an embodiment herein, the security key includes secondary node (KSN) key.

[0133] In an embodiment herein, initiates a Random Access request message from the UE, wherein the UE use the user plane encryption key and user plane integrity protection key with a secondary node (SN) for the associated DRBs, wherein the SN shall not delete the security key and corresponding SN Counter value before the successful radio resource control (RRC) Reconfiguration Complete message.

[0134] In an embodiment herein, send an error message to the UE to terminate the UE connection if the RRC Reconfiguration Complete message is not received from the UE via MN within a predetermined period.

[0135] In another embodiment herein, the secondary node (102) does not delete the security key and corresponding SN counter value before a successful RRC reconfiguration complete message.

[0136] In another embodiment herein, a sequence of the counter value and corresponding secondary node key received from the master node (MN) (200) over an Xn-Control plane interface (Xn-C), wherein the MN (200) derives the node key from a next-generation Radio Access Network key (KNG-RAN) and assigns a sequence of SN counter values to candidate SNs during an 'subsequent conditional Primary-Secondary Cell Addition or Change' (SCPAC) procedure.

[0137] In another embodiment herein, the sequence of secondary node (SN) counter values and corresponding secondary node key (KSN) received from a master node (MN) over an Xn-Control plane interface (Xn-C), wherein the MN derives the KSNkeys from a next-generation Radio Access Network key (KNG-RAN) and assigns the sequence of SN counter values to candidate SNs during an 'subsequent conditional Primary-Secondary Cell Addition or Change' (SCPAC) procedure.

[0138] In another embodiment herein, the used SN counter value generated by the UE during RRC reconfiguration.

[0139] In another embodiment herein, the SN shall not delete the KSNand corresponding SN Counter value before the successful RRC Reconfiguration Complete message; if there is no reception of RRC Reconfiguration Complete message from the UE via MN, then the SN may initiate an error message to the UE and / or terminate the UE connection.

[0140] In another embodiment herein, the method comprising, receiving, by the SN, SN Reconfiguration Complete message, wherein the SN chooses the KSNkey corresponding to the received used SN Counter value to establish the security association with the UE.

[0141] FIG. 8 is a flow chart (S800) illustrating a method for preventing de-synchronization of a secondary key in a wireless network, according to the embodiments as disclosed herein. The operations (S802-S804) are handled by a secondary node (SN) (102).

[0142] At 802, method includes determining that the secondary node does not receive the SN reconfiguration complete message from a User Equipment (UE) (300) through a master node (MN) (200), and the secondary node (102) does not receive a user plane (UP) traffic from the UE (300).

[0143] At 804, method includes performing at least one of: initiating an error message to the UE (300) and terminating a UE (300) connection based on the determination.

[0144] In an embodiment herein, the UP traffic is received from the UE (300) after a Random-Access Channel (RACH) procedure. In an embodiment herein, the SN (102) does not delete the security key and corresponding SN Counter value before the successful RRC reconfiguration complete message.

[0145] In an embodiment herein, the security key includes secondary node (KSN) key. In an embodiment herein, the Xn-interface includes Xn-control plane interface.

[0146] In an embodiment herein, the MN (200) includes all candidate secondary cell group (SCG) configuration(s) for at least one candidate SN(s) in the same RRC Reconfiguration Request message, wherein the SN(s) activates a next-generation Radio Access Network key (KNG-RAN) to the UE (300).

[0147] In an embodiment herein, the RRC Reconfiguration Request message is sent over the RRC connection between the MN (200) and the UE (300). In an embodiment herein, the MN (200) assigns a sequence of distinct SN Counter values to each candidate SN (102) to deliver the sequence of SN Counter values and corresponding KSNkeys to each candidate SN (102).

[0148] In an embodiment herein, the MN (200) derives KSNkeys corresponding to the sequence of SN Counter values from the KNG-RANto transmit the UE (300) security capabilities and User Plane (UP) security received from a Session Management Function (SMF) to each candidate SN (102).

[0149] In an embodiment herein, the RRC Request includes candidate Secondary Cell Group (SCG) configurations for one or more candidate SNs (102) and an activation of the KNG-RAN, wherein the RRC Reconfiguration Request message is integrity protected using a KRRCintkey of the MN (200).

[0150] In an embodiment herein, the selected SN (for example first target SN 102a) derives a user plane encryption key and a user plane integrity key, when configured, from the KSNkey to activate UP protection for communications with the UE.

[0151] In an embodiment herein, the UE (300) validates the integrity of the RRC Reconfiguration Request received from the MN (200) using the KRRCintof the MN (200) before accepting the request.

[0152] In an embodiment herein, the upon selecting a SN (102) for the first time or a subsequent time, the UE (300) derives the KSNby taking an unused SN Counter value from the SCG configuration for the selected SN.

[0153] In an embodiment herein, the UE (300) computes the user plane encryption key and user plane integrity key based on the indications received for the associated DRBs from the MN (200).

[0154] In an embodiment herein, the UE (300) activates the user plane encryption and integrity protection for the associated DRBs based on the computed keys and indications received from the MN (200).

[0155] In an embodiment herein, the UE (300) sends an RRC Reconfiguration Complete message to the MN (200), the message including the SN Counter value used by the UE to generate the KSN.

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

[0157] The embodiment disclosed herein describes systems and methods for preventing the de-synchronization of the KSNkey in wireless communication networks, by ensuring secure key management and synchronization between the User Equipment (UE), Master Node (MN), and Secondary Node (SN). 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 deviceor 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.

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

Claims

1.A method performed by a secondary node (SN) in a wireless communication system, the method comprising:receiving, from a user equipment (UE), a user plane (UP) traffic;receiving, from the UE, a SN reconfiguration complete message through a master node (MN) after receiving the UP traffic, wherein the SN reconfiguration complete message includes a first SN counter value associated with a first security key;identifying a second security key corresponding to a second SN counter value associated with the SN;determining a mismatch of the first security key based on the second security key; andin case that there is no mismatch of the first security key, deleting the second securitykey and the second SN counter value.2.The method of claim 1, further comprising:in case that there is no mismatch of the first security key, activating a UP protection related to the UP traffic after computing a required UP key.3.The method of claim 1, further comprising:in case of the mismatch of the first security key, maintaining the second security key and the second SN counter value.4.The method of claim 1, wherein determining the mismatch of the first security key based on the second security key comprises:determining whether the first security key corresponds to the second security key; andin case that the first security key corresponds to the second security key, determining that there is no mismatch of the first security key.5.The method of claim 1, wherein the second security key and the second SN counter value are not deleted, before receiving a successful RRC reconfiguration complete message.6.The method of claim 1, wherein the second security key and the second SN counter value are deleted after determining that there is no key mismatch.7.The method of claim 1, further comprising:in case of the mismatch of the first security key, selecting the first security key corresponding to the first SN counter value received in the SN reconfiguration complete message.8.The method of claim 1, wherein the second security key corresponding to the second SN counter value is identified based on a sequence of SN counter values and corresponding security keys received from the MN.9.The method of claim 8, wherein the sequence of the SN counter values and corresponding secondary node key are received from the MN over an Xn-Control plane interface (Xn-C).10.The method of claim 1, further comprising:determining that an SN reconfiguration complete message is not received from the UE through the MN, and that a UP traffic is not received from the UE; andperforming at least one of: initiating an error message to the UE and terminating a UE connection based on the determination.11.The method of claim 1, wherein the UP traffic is received from the UE (300) after a random-access channel　(RACH) procedure.12.A secondary node (SN) in a wireless communication system, the SN comprising:a transceiver; andone or more processors coupled to the transceiver and configured to:receive, from a user equipment (UE), a user plane (UP) traffic,receive, from the UE, a SN reconfiguration complete message through a master node (MN) after receiving the UP traffic, wherein the SN reconfiguration complete message includes a first SN counter value associated with a first security key,identify a second security key corresponding to a second SN counter value associated with the SN,determine a mismatch of the first security key based on the second security key, andin case that there is no mismatch of the first security key, delete the second securitykey and the second SN counter value.13.The SN of claim 12, wherein the one or more processors are further configured to:in case that there is no mismatch of the first security key, activate a UP protection related to the UP traffic after computing a required UP key.14.The SN of claim 12, wherein the one or more processors are further configured to:in case of the mismatch of the first security key, maintain the second security key and the second SN counter value.15.The SN of claim 12, wherein the one or more processors are further configured to:determine whether the first security key corresponds to the second security key, andin case that the first security key corresponds to the second security key, determine that there is no mismatch of the first security key.

Images