Methods and apparatus of security update for inter-CU ltm

Abstract

This disclosure describes methods and apparatus to perform security update for inter-CU LTM, Comprising the steps of: receiving the LTM configuration with candidate gNBs'identifier; calculate security key for candidate gNBs or target gNB; sending RRCReconfigurationComplete to target gNB for LTM completion by encryption with the security key of target gNB. When calculate security key for target gNB, the target gNB is indicated by the LTM cell switch Command MAC CE from the network. When calculate security key for candidate gNBs, the candidate gNBs includes all candidate gNBs which is indicated by RRCReconfiguration message for LTM preparation from the network.

Description

METHODS AND APPARATUS OF SECURITY UPDATE FOR INTER-CU LTMFIELD

[0001] The present disclosure relates generally to communication systems, and more particularly, the method of security update for inter-CU 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] In this invention, apparatus and mechanisms are sought to support security update for inter-CU LTM.SUMMARY

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

[0006] 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 one embodiment, UE calculates security keys for all candidate gNBs provided by the configuration message. UE chooses the security key for the target gNB when UE receives the LTM Cell Switch Command MAC CE. In another embodiment, UE calculates the security key for the target gNB when UE receives the LTM Cell Switch Command MAC CE. In LTM execution stage, UE applies the configurations including the security key for the target gNB. UE send RRCReconfiguration complete message by encrypting with the security key towards target gNB for LTM completion.

[0007] In one embodiment, UE is indicated for subsequent LTM by LTM Cell Switch Command MAC CE. In different embodiments, UE calculates / chooses the security key for target gNB and performs the same behavior in LTM execution and LTM completion stage as described above.

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

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

[0010] The target gNB’s identifier may also be referred to as a TRAN_ID, a target gNB identity, or by other terminology used in the art. It may further contains the physical cell id, length of PCI, ARFCN-DL (the absolute frequency of SSB of the target PCell) , length of ARFCN-DL and related information, as specified in 3GPP TS 33.501 (Security architecture and procedures for 5G system) . 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 kgNB and target / candidate gNB’s identifier is also referenced as KDF function in the above-mentioned specification.

[0011] The invention is not limited to 5G NR, it may also apply to other communication systems, such as 6G or further-generation communication systems.

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

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

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

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

[0016] Figure 4 illustrates an exemplary process for UE to calculate security keys for candidate gNBs based on the configuration for inter-CU LTM in accordance with embodiments of the current invention.

[0017] Figure 5 illustrates an exemplary process for UE to calculate security keys for target gNB based on the configuration and LTM cell switch Command MAC CE for inter-CU LTM in accordance with embodiments of the current invention.

[0018] Figure 6 illustrates an exemplary process for UE to select the security keys for target gNB for subsequent LTM in inter-CU scenario in accordance with embodiments of the current invention.

[0019] Figure 7 illustrates an exemplary process for UE to calculate security keys for target gNB for subsequent LTM in inter-CU scenario in accordance with embodiments of the current invention.

[0020] Figure 8 illustrates an exemplary flowchart for UE to update the security key through interaction with gNB to achieve inter-CU LTM cell switch in accordance with embodiments of the current invention.DETAILED DESCRIPTION

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0038] 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 horizontal key derivation procedure can be used to calculate KgNB*for target gNB. For horizontal key derivation, the KgNB*can be calculated as KDF (KgNB || TRAN_ID) , where the KDF (key derivation function) takes the current key of the source gNB (KgNB) and the target gNB’s identifier (TRAN_ID) as input to derive the new session key KgNB*. 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) .

[0039] Figure 4 illustrates an exemplary process for UE to calculate security keys for candidate gNBs based on the configuration for inter-CU 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 source gNB send handover request to all candidate gNBs. In one embodiment, the source gNB calculates the security keys for all candidate gNBs (i.e., KgNB*) by source gNB security key and candidate gNBs’ identifiers and include them in the handover request message. When UE receives the RRCReconfiguration message from source gNB, in one embodiment, UE calculates security keys for all candidate gNBs (i.e., KgNB*) by the candidate gNBs’ identifier and security key of source gNB. In one embodiment, UE stores all security keys for all candidate gNBs (i.e., KgNB*) until LTM execution.

[0040] 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 selects the kgNB*for the indicated target gNB from the stored security keys for all candidate gNBs. 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 process for UE to calculate security keys for target gNB based on the configuration and LTM cell switch Command MAC CE for inter-CU 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 source gNB send handover request to all candidate gNBs. In one  embodiment, the source gNB calculates the security keys for all candidate gNBs (i.e., KgNB*) by source gNB security key and candidate gNBs’ identifiers and include them in the handover request message. Source gNB sends RRCReconfiguration message to UE for pre-configuration after confirmed by candidate gNBs.

[0042] 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 calculates security keys (i.e., KgNB*) for indicated target gNB by the target gNB’s identifier and security key of source gNB. UE send RRCReconfiguration complete message to the target gNB by encrypting with the security key of target gNB for LTM completion.

[0043] For Figure 4 and 5, in one embodiment, UE also receives the NH parameter from the RRCReconfiguration message in LTM preparation stage. In one embodiment, NW indicates the NH parameter transferred from AMF and and indicates UE to do the vertical key derivation. For vertical key derivation, the UE calculates the kgNB*for candidate gNBs (in figure 4) or target gNB (in figure 5) by the NH parameter indicated by the network and candidate / target gNB’s identifier.

[0044] Figure 6 illustrates an exemplary process for UE to select the security keys for target gNB for subsequent LTM in inter-CU scenario in accordance with embodiments of the current invention. The first four steps of the process (initial LTM) described in this figure align with those in Figure 4 and will not be reiterated here. The description will commence from the fifth step. When UE receives the LTM Cell Switch Command MAC CE for subsequent LTM, UE is indicated with the target gNB by the information in LTM Cell switch Command MAC CE and pre-configuration message. In one embodiment, UE selects the kgNB*for the indicated target gNB from the stored security keys for all candidate gNBs. UE send RRCReconfiguration complete message to the target gNB by encrypting with the security key of target gNB for LTM completion.

[0045] Figure 7 illustrates an exemplary process for UE to calculate security keys for target gNB for subsequent LTM in inter-CU scenario in accordance with embodiments of the current invention. The first three steps of the process (initial LTM) described in this figure align with those in Figure 5 and will not be reiterated here. The description will commence from the fourth step. When UE receives the LTM Cell Switch Command MAC CE for subsequent LTM, UE is indicated with the target gNB by the information in LTM Cell switch Command MAC CE and pre-configuration message. In one embodiment, UE calculates security keys (i.e., KgNB*) for indicated target gNB by the target gNB’s identifier and security key of source gNB. UE send RRCReconfiguration complete message to the target gNB by encrypting with the security key of target gNB for LTM completion.

[0046] Figure 8 illustrates an exemplary flowchart for UE to update the security key through  interaction with gNB to achieve inter-CU 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, the LTM candidate preparation further contains the source gNB sends a handover request to all candidate gNBs. In one embodiment, the source gNB calculates the security keys for all candidate gNBs (i.e., KgNB*) by source gNB security key and candidate gNBs’ identifiers and includes them in the handover request message. 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 calculates security keys for all candidate gNBs (i.e., KgNB*) by the candidate gNBs’ identifier and security key of source gNB. In one embodiment, UE stores all security keys for all candidate gNBs (i.e., KgNB*) until LTM execution. In another embodiment, UE does not calculate the security keys until it is indicated for the target gNB for LTM execution.

[0047] In early sync stage, in one embodiment, the behavior of UE is consistent with the flowchart for R18 LTM, without additional behaviors.

[0048] 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 selects the kgNB*for the indicated target gNB from security keys for all candidate gNBs. In one embodiment, UE store the security key for other candidate gNB for subsequent LTM. In another embodiment, UE calculates security keys (i.e., KgNB*) for indicated target gNB by the target gNB’s identifier and security key of source gNB.

[0049] In LTM execution stage, 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 stores the security key for other candidate gNB for subsequent LTM.

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

[0051] 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. ”

[0052] 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 security update for inter-CU LTM, comprising the steps of:Receiving the LTM configuration with candidate gNBs' identifiers;Calculating security key for candidate gNBs or target gNB;Sending RRCReconfigurationComplete to target gNB for LTM completion by encryption with the security key of target gNB.2.The method of claim 1, wherein the calculation of security key is performed by the horizontal key derivation method as specified in 3GPP.3.The method of claim 1, wherein the calculation of security key is performed by the vertical key derivation method as specified in 3GPP.4.The method of claim 1, when calculate security key for target gNB, the target gNB is indicated by the LTM cell switch Command MAC CE from the network.5.The method of claim 1, when calculate security key for candidate gNBs, the candidate gNBs includes all candidate gNBs which is indicated by RRCReconfiguration message for LTM preparation from the network.6.The method of claim 5, further comprising UE store the calculated security keys for candidate gNBs.7.The method of claim 5, further comprising UE selects the security key for target gNB as indicated by the LTM cell switch Command MAC CE from the network.8.The method of claim 5, further comprising UE stores the calculated security keys for other candidate gNBs for subsequent LTM.9.The method of claim 1, wherein the identifier of gNB contains the physical cell id, length of PCI, ARFCN-DL, length of ARFCN-DL and other related information used by the KDF function.

Images