Methods and apparatus to support dynamic vertical key derivation for ltm

Abstract

This disclosure describes methods and apparatus to perform security update for LTM, comprising the steps of: Receiving the information for vertical key derivation from gNB, calculating the NH and security key for target gNB. Sending RRCReconfigurationComplete to target gNB for LTM completion by encryption with the security key of target gNB. The information for vertical key derivation can be indicated as an explicit NCC value or implicit input to calculate NCC value. The container of information for vertical key derivation can be indicated via RRC, MAC-CE or DCI.

Description

METHODS AND APPARATUS TO SUPPORT DYNAMIC VERTICAL KEY DERIVATION FOR LTMFIELD

[0001] The present disclosure relates generally to communication systems, and more particularly, the method to support dynamic vertical security key derivation for LTM.BACKGROUND

[0002] In conventional network of 3rd generation partnership project (3GPP) 5G new radio (NR) , when the UE moves from the coverage area of one cell to another cell, at some point a serving cell change needs to be performed. Currently serving cell change is triggered by L3 measurements and is done by RRC signaling triggered by reconfiguration with synchronization for change of PCell and PSCell, as well as release / add for SCells when applicable. All cases involve complete L2 (and L1) resets, leading to longer latency, larger overhead and longer interruption time than beam switch mobility. In order to reduce the latency, overhead and interruption time during UE mobility, LTM (L1 L2-triggered Mobility) is introduced in Release 18 for different scenarios, including intra-DU / inter-DU inter-cell cell change, FR1 / FR2, intra-frequency / inter-frequency, and source and target cells may be synchronized or non-synchronized.

[0003] In the design of the procedure for LTM, the LTM preparation is performed before the cell switch. When the condition is met, a cell switch command is indicated to UE to trigger the cell switch procedure. During the preparation stage, configurations toward candidate cells is pre-configured by RRC message. However, the security update is not supported in Release 18 LTM and the security information is not included in the pre-configuration message. Therefore, the inter-CU scenario is not supported in Release 18 LTM.

[0004] The generation of session key for target gNB (i.e., KgNB*) is critical for security update procedure. Regarding key derivation, two procedures, horizontal key derivation (hkd) and vertical key derivation (vkd) are introduced as the legacy security update procedure. The KgNB*is calculated by the target cell identifier (target PCI, target ARFCN-DL / EARFCN-DL) , with either the current key from source cell (KgNB) (hkd) , or the NH calculated by NCC indicated via RRC signaling from the network (vkd) .

[0005] In this invention, apparatus and mechanisms are sought to dynamic vertical security key update for LTM.SUMMARY

[0006] The following presents a simplified summary of one or more aspects in order to provide a basic understanding of such aspects. This summary is not an extensive overview of all contemplated  aspects, and is intended to neither identify key or critical elements of all aspects nor delineate the scope of any or all aspects. Its sole purpose is to present some concepts of one or more aspects in a simplified form as a prelude to the more detailed description that is presented later.

[0007] In an aspect of the disclosure, a method, a computer-readable medium, and an apparatus are provided. The apparatus may be a UE. In the LTM preparation stage, UE receives RRCReconfiguration message indicated by network, which contains the configurations for candidate cells. In one embodiment, the network includes the candidate gNBs’ identifier in the RRCReconfiguration message. In LTM execution stage, UE receives the LTM cell switch command MAC CE from the network. In one embodiment, UE receives the indication to perform vertical key update. In one embodiment, UE receives the information used for vertical key derivation from gNB. UE uses the information to calculate the security key of target cell. UE applies the configurations including the security key for the target gNB and sends RRCReconfiguration complete message by encrypting with the security key towards target gNB for LTM completion. In one embodiment, UE performs horizontal key update for target cell if not receive the indication to perform vertical key update.

[0008] In one embodiment, UE is indicated for subsequent LTM by LTM Cell Switch Command MAC CE. In different embodiments, UE performs horizontal or vertical key update procedure according to the indication from network and and performs the same behavior in LTM execution and LTM completion stage as described above.

[0009] The security key for source gNB before LTM may also be referred to as a KgNB, a kgNB, a KgNB, a KNG-RAN, or by other terminology used in the art. The security key for target gNB after LTM cell switch may also be referred to as a KgNB*, a kgNB*, a KgNB*, a KNG-RAN*, or by other terminology used in the art. The security keys for the candidate gNBs have the same terminology as target gNB used in the art, as the target gNB is one of the candidates gNBs indicated in LTM Cell Switch Command MAC CE. The security keys of different candidate gNBs may be distinguished by different identifiers (e.g., KgNB1, KgNB2) .

[0010] The LTM Cell Switch Command MAC CE may also be referred to as a cell switch command MAC CE, LTM cell switch MAC CE, LTM cell switch command or by other terminology used in the art. The RRCReconfiguration message used in LTM preparation stage may also be referred to as a pre-configuration message, a LTM configuration message, an LTM pre-configuration message or by other terminology used in the art.

[0011] The NH may also be referred to as a Next Hop parameter or by other terminology; The NCC may also be referred to as a Next Hop Chaining Counter parameter (NCC) or NextHopChainingCount as specified in 3GPP TS 33.501 (Security architecture and procedures for 5G system) and / or TS 38.331 (Radio Resource Control protocol specification) . The candidate gNB’s identifier for one candidate gNB may also be referred to as a CRAN_ID, a candidate gNB identity, or by other terminology used in the art. It has the same information as the target gNB’s identifier. The process of calculating kgNB*from NH and target / candidate gNB’s identifier is also referenced as KDF  function in the above-mentioned specification.

[0012] The invention is not limited to 5G NR, it may also apply to other communication systems, such as 6G or further-generation communication systems. According to some implementations, this invention can be specifically used for inter-CU LTM.

[0013] To the accomplishment of the foregoing and related ends, the one or more aspects comprise the features hereinafter fully described and particularly pointed out in the claims. The following description and the annexed drawings set forth in detail certain illustrative features of the one or more aspects. These features are indicative, however, of but a few of the various ways in which the principles of various aspects may be employed, and this description is intended to include all such aspects and their equivalents.BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Figure 1 illustrates an schematic system diagram illustrating an exemplary 5G new radio network in accordance with embodiments of the current invention.

[0015] Figure 2 illustrates an exemplary NR wireless system with centralization of the upper layers of the NR radio stacks in accordance with embodiments of the current invention.

[0016] Figure 3 illustrates an exemplary deployment scenario for inter-CU LTM in accordance with embodiments of the current invention.

[0017] Figure 4 illustrates an exemplary process for UE to perform dynamic vertical key derivation for target gNBs for LTM in accordance with embodiments of the current invention.

[0018] Figure 5 illustrates an exemplary flowchart for UE to update the security key via vertical key update through interaction with gNB for LTM cell switch in accordance with the embodiments of the current invention.DETAILED DESCRIPTION

[0019] The detailed description set forth below in connection with the appended drawings is intended as a description of various configurations and is not intended to represent the only configurations in which the concepts described herein may be practiced. The detailed description includes specific details for the purpose of providing a thorough understanding of various concepts. However, it will be apparent to those skilled in the art that these concepts may be practiced without these specific details. In some instances, well known structures and components are shown in block diagram form in order to avoid obscuring such concepts.

[0020] Several aspects of telecommunication systems will now be presented with reference to various apparatus and methods. These apparatus and methods will be described in the following detailed description and illustrated in the accompanying drawings by various blocks, components, circuits, processes, algorithms, etc. (collectively referred to as “elements” ) . These elements may be implemented using electronic hardware, computer software, or any combination thereof. Whether such  elements are implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system.

[0021] Aspects of the present disclosure provide methods, apparatus, processing systems, and computer readable mediums for NR (new radio access technology, or 5G technology) , 6G or other radio access technology. NR may support various wireless communication services. These services may have different quality of service (QoS) requirements e.g. latency and reliability requirements.

[0022] Figure 1 illustrates a schematic system diagram illustrating an exemplary wireless network in accordance with embodiments of the current invention. Wireless system includes one or more fixed base infrastructure units forming a network distributed over a geographical region. The base unit may also be referred to as an access point, an access terminal, a base station, a Node-B, an eNode-B, a gNB, or by other terminology used in the art. As an example, base stations serve a number of mobile stations within a serving area, for example, a cell, or within a cell sector. In some systems, one or more base stations are coupled to a controller forming an access network that is coupled to one or more core networks. gNB 1and gNB 2 are base stations in NR, the serving area of which may or may not overlap with each other. As an example, UE1 or mobile station is only in the service area of gNB 1 and connected with gNB1. UE1 is connected with gNB1 only, gNB1 is connected with gNB 1 and 2 via Xn interface. UE2 is in the overlapping service area of gNB1 and gNB2.

[0023] Figure 1 further illustrates simplified block diagrams for UE2 and gNB2, respectively. UE has an antenna, which transmits and receives radio signals. A RF transceiver, coupled with the antenna, receives RF signals from antenna, converts them to baseband signal, and sends them to processor. In one embodiment, the RF transceiver may comprise two RF modules (not shown) . A first RF module is used for transmitting and receiving on one frequency band, and the other RF module is used for different frequency bands transmitting and receiving which is different from the first transmitting and receiving. RF transceiver also converts received baseband signals from processor, converts them to RF signals, and sends out to antenna. Processor processes the received baseband signals and invokes different functional modules to perform features in UE. Memory stores program instructions and data to control the operations of mobile station. UE also includes multiple function modules that carry out different tasks in accordance with embodiments of the current invention.

[0024] An RRC State controller, which controls UE RRC state according to network’s command and UE conditions. RRC supports the following states, RRC_IDLE, RRC_CONNECTED and RRC_INACTIVE.

[0025] A DRB controller, which controls to establish / add, reconfigure / modify and release / remove a DRB based on different sets of conditions for DRB establishment, reconfiguration and release. A protocol stack controller, which manage to add, modify or remove the protocol stack for the DRB. The protocol Stack includes SDAP, PDCP, RLC, MAC and PHY layers.

[0026] In one embodiment, the SDAP layer supports the functions of transfer of data, mapping between a QoS flow and a DRB, marking QoS flow ID, reflective QoS flow to DRB mapping for the  UL SDAP data PDUs, etc.

[0027] In one embodiment, the PDCP layer supports the functions of transfer of data, maintenance of PDCP SN, header compression and decompression using the ROHC protocol, ciphering and deciphering, integrity protection and integrity verification, timer-based SDU discard, routing for split bearer, duplication, re-ordering and in-order delivery; out of order delivery and duplication discarding.

[0028] In one embodiment, the RLC layer supports the functions of error correction through ARQ, segmentation and reassembly, re-segmentation, duplication detection, re-establishment, etc. In one embodiment, a new procedure for RLC reconfiguration is performed, which can reconfigure the RLC entity to be associated to one or two logical channels.

[0029] In one embodiment, the MAC layer supports the following functions: mapping between logical channels and transport channels, multiplexing / demultiplexing, HARQ, radio resource selection, etc.

[0030] In one embodiment, there are two PDCP, RLC and MAC entities for inter-CU LTM. The PDCP, RLC and MAC entities are associated to the first and the second cell respectively. In one embodiment, the first cell is the source cell and the second cell is the target cell. In one embodiment, UE is switched back and forth between the first and second cell. If UE is switched back from the second cell to the first cell, the second cell is considered as source cell and the first cell is considered as the target cell. In one embodiment, different cells belong to different gNBs.

[0031] Similarly, gNB2 has an antenna, which transmits and receives radio signals. A RF transceiver, coupled with the antenna, receives RF signals from antenna, converts them to baseband signals, and sends them to the processor. RF transceiver also converts received baseband signals from the processor, converts them to RF signals, and sends out to antenna. The processor processes the received baseband signals and invokes different functional modules to perform features in gNB2. Memory stores program instructions and data to control the operations of gNB2. gNB2 also includes multiple function modules that carry out different tasks in accordance with embodiments of the current invention.

[0032] A RRC State controller, which performs access control for the UE.

[0033] A DRB controller, which controls to establish / add, reconfigure / modify and release / remove a DRB based on different sets of conditions for DRB establishment, reconfiguration and release. A protocol stack controller, which manage to add, modify or remove the protocol stack for the DRB. The protocol Stack includes PDCP, RLC, MAC and PHY layers..

[0034] Figure 2 illustrates an exemplary NR wireless system with centralization of the upper layers of the NR radio stacks in accordance with embodiments of the current invention. Different protocol split options between Central Unit and lower layers of gNB nodes may be possible. The functional split between the Central Unit and lower layers of gNB nodes may depend on the transport layer. Low performance transport between the Central Unit and lower layers of gNB nodes can enable  the higher protocol layers of the NR radio stacks to be supported in the Central Unit, since the higher protocol layers have lower performance requirements on the transport layer in terms of bandwidth, delay, synchronization and jitter. In one embodiment, SDAP and PDCP layer are located in the central unit, while RLC, MAC and PHY layers are located in the distributed unit.

[0035] Figure 3 illustrates an exemplary deployment scenario for inter-CU LTM in accordance with embodiments of the current invention. Two CUs (Central Unit) are connected to one core network through NG interface. Two CUs are connected to each other through Xn interface. One CU is connected to two DUs (Distributed Unit) through the F1 interface, and two DUs are connected to multiple RUs respectively. A cell may consist of a range covered by one or more RUs under the same DU. In this scenario, a UE is moving from the edge of one cell to another cell, which two belong to different CU. The protocol stack including PDCP, RLC, MAC are different in two CUs and corresponding DUs. Inter-CU LTM can be used in this scenario to replace the legacy handover process to reduce the interruption and improve the throughput of UE. In one embodiment, security update procedure is introduced in inter-CU LTM.

[0036] In the design of the security update procedure for handover procedure in NR, the source gNB initiates a handover request message to the target gNB. The handover request consists of the newly derived session key for target gNB (KgNB*) . If the target gNB accepts the handover request, a handover command message will be transmitted to UE, containing the information of target gNB (e.g., target gNB ID, target gNB’s identifer ) . UE recomputes the same session key KgNB*and updates the signaling with the target gNB through the RRC Reconfiguration complete message by encryption with the KgNB*. The vertical key derivation procedure can be used to calculate KgNB*for target gNB. For vertical key derivation, the KgNB*can be calculated as KDF (NH || TRAN_ID) , where the KDF takes the current key of the NH parameter transferred from AMF and the target gNB’s identifier (TRAN_ID) as input to derive the new session key KgNB*. The target gNB’s identifier may further contain the target physical cell ID, length of PCI, ARFCN-DL (the absolute frequency of SSB of the target PCell) and related information, as specified in 3GPP TS 33.501 (Security architecture and procedures for 5G system) .

[0037] Figure 4 illustrates an exemplary process for UE to perform dynamic vertical key derivation for target gNBs for LTM in accordance with embodiments of the current invention. The gNBs described above and shown in the figure may be different gNBs, or different cells of the same CU / DU. The candidate gNBs in the pre-configuration message may come from either of these two, or a combination of both. In LTM preparation stage, the RRCReconfiguration message from source gNB contains the identifier for all candidate gNB. The candidate gNB’s identifier further contain the target physical cell ID, length of PCI and ARFCN-DL (the absolute frequency of SSB of the target PCell) .

[0038] In one embodiment, UE receives an indication which request UE to perform vertical key update in the next LTM cell switch. In one embodiment, UE receives the information for vertical key derivation from gNB. In one embodiment, the information and / or indication for vertical key derivation is indicated via LTM cell switch command MAC CE. In another embodiment, the information and / or  indication for vertical key derivation is indicated via a new MAC CE or DCI before UE receives the LTM cell switch command. In one embodiment, the information for vertical key derivation is the NCC value. In other different embodiments, the information for vertical key derivation is not the explicit NCC value, but an NCC increment indicator, or the difference between the new NCC and the previous NCC maintained by UE, or the input to calculate the new NCC from previous NCC through a specific formula. In one embodiment, the formula is maintained by UE and AMF.

[0039] In one embodiment, UE calculates the new NCC by the information for vertical key derivation from network if UE is indicated for vertical key derivation. In different embodiments, the new NCC is equal to the previous NCC incremented by one, or the new NCC is equal to the previous NCC plus the difference between the new NCC and the previous NCC, or the new NCC is calculated using a specific formula that takes an input (indicated from network) and the previous NCC as parameters. In one embodiment, UE receives the new NCC from network directly and no need to perform this step.

[0040] In one embodiment, UE calculates the new NH value by the previous NH value, the new calculated NCC and the security key of AMF maintained by UE. In one embodiment, UE calculates the security key for target gNB from the target gNB’s identifier and the new calculated NH value. In one embodiment, UE send RRCReconfiguration complete message to the target gNB by encrypting with the security key of target gNB for LTM completion.

[0041] Figure 5 illustrates an exemplary flowchart for UE to update the security key via vertical key update through interaction with gNB for LTM cell switch in accordance with the embodiments of the current invention. In one embodiment, the gNB described in the figure refers to different CUs, including source gNB and target gNB as mentioned in the art. In LTM preparation stage, in one embodiment, the RRCReconfiguration contains the identifiers for all candidate gNBs. When UE receives the RRCReconfiguration message from source gNB, in one embodiment, UE stores the candidate gNBs’ identifier for all candidate gNBs for future security key update.

[0042] In early sync stage, in one embodiment, the behavior of UE is consistent with the flowchart for R18 LTM, without additional behaviors. In one embodiment, UE receives a vertical key update indicator within a new MAC CE or DCI.

[0043] In LTM execution stage, UE is indicated with the target gNB by LTM Cell switch Command MAC CE and the information in pre-configuration message. In one embodiment, UE receives a vertical key update indicator via the LTM Cell switch Command MAC CE. In another embodiment, UE receives a vertical key update indicator via a new MAC CE or DCI before the LTM Cell switch Command MAC CE.

[0044] In one embodiment, UE receives the information for vertical key derivation from gNB. In different embodiments, the information is the explicit NCC value, or an NCC increment indicator, or the difference between the new NCC and the previous NCC maintained by UE, or the input to calculate the new NCC from previous NCC through a specific formula. In one embodiment, UE calculate the new  NCC value if it is not provided to UE explicitly.

[0045] In one embodiment, UE calculates the NH value by the new NCC value, and calculates the security key for target gNB by the new calculated NH value as specified in 3GPP TS 33.501. UE send RRCReconfiguration complete message to the target gNB by encrypting it with the security key of target gNB for LTM completion. In one embodiment, UE store the new calculated NCC value and / or NH value and / or security keys for target gNB.

[0046] In one embodiment, UE receives the LTM Cell switch Command MAC CE for subsequent LTM and UE performs the same behavior in LTM execution and LTM completion stage as described above.

[0047] In one embodiment, the NCC value is included in the RRCReconfiguration message for LTM preparation, and UE performs vertical key derivation for security update in the next LTM cell switch. In one embodiment, UE calculates the target gNB’s security key according to the indicated NCC value and the candidate gNB’s identifiers from RRCReconfiguration message, and the target gNB index from LTM cell switch command MAC CE, which received in the LTM execution stage. UE derives the target gNB identifier from the candidate gNB’s identifiers and the target gNB index. UE calculates the new NH value from the indicate NCC value, previous NH value and AMF security key. UE calculates security key for target gNB by the new NH value and the target gNB identifier.

[0048] It is understood that the specific order or hierarchy of blocks in the processes  / flowcharts disclosed is an illustration of exemplary approaches. Based upon design preferences, it is understood that the specific order or hierarchy of blocks in the processes  / flowcharts may be rearranged. Further, some blocks may be combined or omitted. The accompanying method claims present elements of the various blocks in a sample order, and are not meant to be limited to the specific order or hierarchy presented.

[0049] The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects. Thus, the claims are not intended to be limited to the aspects shown herein, but is to be accorded the full scope consistent with the language claims, wherein reference to an element in the singular is not intended to mean “one and only one” unless specifically so stated, but rather “one or more. ” The word “exemplary” is used herein to mean “serving as an example, instance, or illustration. ” Any aspect described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects. Unless specifically stated otherwise, the term “some” refers to one or more. Combinations such as “at least one of A, B, or C, ” “one or more of A, B, or C, ” “at least one of A, B, and C, ” “one or more of A, B, and C, ” and “A, B, C, or any combination thereof” include any combination of A, B, and / or C, and may include multiples of A, multiples of B, or multiples of C. Specifically, combinations such as “at least one of A, B, or C, ” “one or more of A, B, or C, ” “at least one of A, B, and C, ” “one or more of A, B, and C, ” and “A, B, C, or any combination thereof” may be A only, B only, C only, A and B, A and C,  B and C, or A and B and C, where any such combinations may contain one or more member or members of A, B, or C. All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims. The words “module, ” “mechanism, ” “element, ” “device, ” and the like may not be a substitute for the word “means. ” As such, no claim element is to be construed as a means plus function unless the element is expressly recited using the phrase “means for. ”

[0050] While aspects of the present disclosure have been described in conjunction with the specific embodiments thereof that are proposed as examples, alternatives, modifications, and variations to the examples may be made. Accordingly, embodiments as set forth herein are intended to be illustrative and not limiting. There are changes that may be made without departing from the scope of the claims set forth below.

Claims

1.A method for UE to support dynamic vertical key derivation for security update for inter-CU LTM, comprising the steps of:Receiving the information for vertical key derivation from gNBCalculating the NH and security key for target gNBSending RRCReconfigurationComplete to target gNB for LTM completion by encryption with the security key of target gNB.2.The method of claim 1, wherein the information for vertical key derivation is received in RRCReconfiguration message during LTM preparation stage.3.The method of claim 1, wherein the information for vertical key derivation is received by LTM cell switch command MAC-CE.4.The method of claim 1, wherein the information for vertical key derivation is received before UE receiving LTM cell switch command.5.The method of claim 4, wherein the information for vertical key derivation is received by a new MAC-CE.6.The method of claim 4, wherein the information for vertical key derivation is indicated by a DCI.7.The method of claim 1, wherein the information for vertical key derivation contains an indication for UE to perform vertical key derivation for security update of the next LTM cell switch.8.The method of claim 1, wherein the information for vertical key derivation contains a NCC value.9.The method of claim 1, wherein the information for vertical key derivation contains an NCC value increment indicator.10.The method of claim 1, wherein the information for vertical key derivation contains the difference between the new NCC and the previous NCC maintained by UE.11.The method of claim 1, wherein the information for vertical key derivation contains information which used as input to calculate the new NCC from previous NCC through a specific formula.12.The method of claim 11, wherein the formula is maintained by the UE and AMF.13.The method of claim 1, further comprising UE calculates new NCC value from the previous NCC and the information received for vertical key derivation from gNB.14.The method of claim 1, further comprising UE calculates NH value by the new NCC, the maintained NH value and the key of AMF.15.The method of claim 1, further comprising UE store the new calculated NCC value and / or NH value and / or security keys for target gNB.16.The method of claim 1, further comprising UE performs horizontal key derivation if UE doesn't receive the information for vertical key derivation from gNB.

Images