A method for key transfer

Abstract

A wireless communication method for use in an anchor node is disclosed. The method includes: receiving, from a serving node, a context request message associated with a wireless terminal, wherein a first key and a first next-hop link count are transmitted to the wireless terminal in a previous connection between the anchor node and the wireless terminal, and wherein a second key determined based on the first key and the first next-hop link count is used by the anchor node, and transmitting, to the serving node, a context response message, the context response message including a third key different from the second key and a second next-hop link count.

Description

Technical Field

[0001] This document generally relates to wireless communication. Background Art

[0002] When a user equipment (UE) resumes connection with a serving node (e.g., a radio access network (RAN) node), the serving node needs to request the UE context from the UE's previous serving node, where the UE context may include a security key configured for the UE in the previous connection with the previous serving node. If the security key has not been used by the previous serving node, the security key can be passed to the serving node, and the serving node can use the security key to perform cryptographic encryption of UL / DL data for the UE. However, if the security key is being used by the previous serving node when the previous serving node receives a request for the UE context, the previous serving node cannot send the security key because different nodes cannot use the same security key. Summary of the Invention

[0003] This document relates to methods, systems, and devices for key transfer, and more particularly to methods, systems, and devices for key transfer during a resume procedure.

[0004] The present disclosure relates to a wireless communication method for use in an anchor node. The method includes:

[0005] Receiving, from a serving node, a context request message associated with a wireless terminal, where a first key and a first next-hop link count were transmitted to the wireless terminal during a previous connection between the anchor node and the wireless terminal, and where a second key determined based on the first key and the first next-hop link count is used by the anchor node, and

[0006] Transmitting, to the serving node, a context response message that includes a third key different from the second key and a second next-hop link count.

[0007] Various embodiments may preferably implement the following features:

[0008] Preferably, the third key is an intermediate key used between the wireless terminal and the serving node.

[0009] Preferably, the third key is determined based on the second key.

[0010] Preferably, the first key and the first next-hop link count are transmitted via a radio resource control connection release message.

[0011] Preferably, the context response message further includes the second key.

[0012] Preferably, the wireless communication method further includes:

[0013] Receive a first message including a radio resource control message associated with a mobile terminal from a serving node, and

[0014] Transmit a second message including a radio resource control message encrypted with a second key to the serving node.

[0015] Preferably, the radio resource control message is one of a radio resource control resume message or a radio resource control release message.

[0016] Preferably, the first message and the second message are Xn Application Protocol (XnAP) signaling.

[0017] The present disclosure relates to a wireless communication method for use in a serving node, the method comprising:

[0018] Receive a resume request message encrypted with a first key from a wireless terminal, wherein the first key and a first next-hop link count are transmitted to the wireless terminal during a previous connection between an anchor node and the wireless terminal,

[0019] Transmit a context request message associated with the wireless terminal to the anchor node,

[0020] Receive a context response message including a third key and a second next-hop link count from the anchor node, wherein the third key is different from a second key determined based on the first key and the first next-hop link count, and

[0021] Transmit a radio resource control message to the wireless terminal, the radio resource control message being encrypted with the second key and including the third key and the second next-hop link count.

[0022] Various embodiments may preferably implement the following features:

[0023] Preferably, the third key is an intermediate key used between the wireless terminal and the serving node.

[0024] Preferably, the third key is determined based on the second key.

[0025] Preferably, the wireless communication method further comprises: receiving at least one signaling message and / or uplink data of the wireless terminal from the wireless terminal not earlier than receiving the resume request message and / or transmitting the radio resource control message, wherein the at least one signaling message and the uplink data of the wireless terminal are encrypted with the second key.

[0026] Preferably, the first key and the first next-hop link count are transmitted through a radio resource control connection release message.

[0027] Preferably, the radio resource control message is one of a radio resource control resume message or a radio resource control release message.

[0028] Preferably, the context response message further includes a second key.

[0029] Preferably, the wireless communication method further includes:

[0030] transmitting a first message including a radio resource control message to an anchor node, and

[0031] receiving a second message including a radio resource control message encrypted by the second key from the anchor node.

[0032] Preferably, the first message and the second message are Xn Application Protocol (XnAP) signaling.

[0033] Preferably, the wireless communication method further includes: after transmitting the radio resource control message, communicating with the wireless terminal by using a third key.

[0034] The present disclosure relates to a wireless communication method for use in a wireless terminal, the method including:

[0035] transmitting a recovery request message encrypted by a first key to a serving node, wherein the first key and the first next-hop link count are received in a previous connection between the wireless terminal and an anchor node different from the serving node, and

[0036] receiving a radio resource control message from the serving node, the radio resource control message being encrypted by a second key determined based on the first key and the first next-hop link count and including a third key different from the second key and a second next-hop link count.

[0037] Various embodiments may preferably implement the following features:

[0038] Preferably, the third key is an intermediate key used between the wireless terminal and the serving node.

[0039] Preferably, the third key is determined based on the second key.

[0040] Preferably, the wireless communication method further includes:

[0041] transmitting at least one signaling message and / or uplink data of the wireless terminal to the serving node no earlier than transmitting the recovery request message and / or before receiving the radio resource control message,

[0042] wherein at least one signaling message and the uplink data of the wireless terminal are encrypted by the second key.

[0043] Preferably, the first key and the first next-hop link count are received in a radio resource control connection release message.

[0044] Preferably, the radio resource control message is one of a radio resource control resume message and a radio resource control release message.

[0045] Preferably, the wireless communication method further includes: after receiving the radio resource control message, communicating with the serving node by using a third key.

[0046] The present disclosure relates to an anchor node. The anchor node includes:

[0047] a communication unit configured to:

[0048] receive, from the serving node, a context request message associated with a wireless terminal, wherein a first key and a first next-hop link count are transmitted to the wireless terminal in a previous connection between the anchor node and the wireless terminal, and wherein a second key determined based on the first key and the first next-hop link count is used by the anchor node, and

[0049] transmit a context response message to the serving node, the context response message including a third key different from the second key and a second next-hop link count.

[0050] Various embodiments may preferably implement the following features:

[0051] Preferably, the anchor node further includes a processor configured to execute any one of the foregoing wireless communication methods.

[0052] The present disclosure relates to a serving node. The serving node includes:

[0053] a communication unit configured to:

[0054] receive, from the wireless terminal, a resume request message encrypted by a first key, wherein the first key and the first next-hop link count are transmitted to the wireless terminal in a previous connection between the anchor node and the wireless terminal,

[0055] transmit a context request message associated with the wireless terminal to the anchor node,

[0056] receive, from the anchor node, a context response message including a third key and a second next-hop link count, wherein the third key is different from a second key determined based on the first key and the first next-hop link count, and

[0057] transmit a radio resource control message to the wireless terminal, the radio resource control message being encrypted by the second key and including the third key and the second next-hop link count.

[0058] Various embodiments may preferably implement the following features:

[0059] Preferably, the serving node further includes a processor configured to execute any one of the foregoing wireless communication methods.

[0060] The present disclosure relates to a wireless terminal. The wireless terminal includes:

[0061] A communication unit configured to:

[0062] Transmit a recovery request message encrypted by a first key to a service node, where the first key and a first next-hop link count are received in a previous connection between the wireless terminal and an anchor node different from the service node, and

[0063] Receive a radio resource control message from the service node, the radio resource control message being encrypted by a second key determined based on the first key and the first next-hop link count and including a third key different from the second key and a second next-hop link count.

[0064] Various embodiments may preferably implement the following features:

[0065] Preferably, the wireless terminal further includes a processor configured to execute any of the foregoing wireless communication methods.

[0066] The present disclosure relates to a computer program product, the computer program product including computer-readable program media code stored thereon, the code causing a processor to implement the wireless communication method described in any of the foregoing methods when executed by the processor.

[0067] The exemplary embodiments disclosed herein are intended to provide features that will become apparent from the following description when taken in conjunction with the accompanying drawings. According to various embodiments, exemplary systems, methods, devices, and computer program products are disclosed herein. However, it should be understood that these embodiments are presented by way of example and not limitation, and it will be apparent to those of ordinary skill in the art reading this disclosure that various modifications may be made to the disclosed embodiments while remaining within the scope of the present disclosure.

[0068] Therefore, the present disclosure is not limited to the exemplary embodiments and applications described and illustrated herein. Additionally, the particular order and / or hierarchy of steps in the methods disclosed herein are merely exemplary. Based on design preferences, the particular order or hierarchy of steps of the disclosed method or process may be rearranged while still remaining within the scope of the present disclosure. Thus, those of ordinary skill in the art will understand that the methods and techniques disclosed herein present various steps or acts in an exemplary order, and the present disclosure is not limited to the particular order or hierarchy presented unless otherwise expressly stated. BRIEF DESCRIPTION OF THE DRAWINGS

[0069] The above and other aspects and their implementations are described in more detail in the drawings, the specification, and the claims.

[0070] Figure 1 Shows a schematic diagram of a radio resource control recovery procedure according to an embodiment of the present disclosure.

[0071] Figure 2 Shows a schematic diagram of a radio resource control recovery procedure according to an embodiment of the present disclosure.

[0072] Figure 3 Shows a schematic diagram of a mobile-originated early transmission procedure without anchor repositioning according to an embodiment of the present disclosure.

[0073] Figure 4 Shows a schematic diagram of a mobile-originated early transmission procedure without anchor repositioning according to an embodiment of the present disclosure.

[0074] Figure 5 Shows a schematic diagram of a procedure associated with security key transfer according to an embodiment of the present disclosure.

[0075] Figure 6 Shows a schematic diagram of a procedure associated with security key transfer according to an embodiment of the present disclosure.

[0076] Figure 7 Shows a flowchart of a procedure according to an embodiment of the present disclosure.

[0077] Figure 8 Shows a flowchart of a procedure according to an embodiment of the present disclosure.

[0078] Figure 9 Shows a flowchart of a procedure according to an embodiment of the present disclosure.

[0079] Figure 10 Shows an example of a schematic diagram of a wireless terminal according to an embodiment of the present disclosure.

[0080] Figure 11 Shows an example of a schematic diagram of a wireless network node according to an embodiment of the present disclosure. Detailed Description

[0081] Figure 1 Relates to a radio resource control (RRC) recovery procedure with anchor repositioning according to an embodiment of the present disclosure. In this embodiment, the UE context is transferred from the anchor gNB (e.g., the previous serving gNB) to the current serving gNB (e.g., the receiving gNB), a path switching procedure is performed after obtaining the UE context, and the serving gNB becomes the new anchor gNB after anchor repositioning (e.g., repositioning of the UE context).

[0082] In the present disclosure, the gNB may be equal to a radio network node, a radio access network (RAN) node, a next generation (NG) RAN node, an evolved Node B (eNB), or an NG-eNB. Additionally, the UL / DL data hereinafter may be data for small data transmission (SDT). In the present disclosure, SDT may be data transmission performed for a UE in an inactive state (e.g., radio resource control (RRC) inactive state (RRC_inactive)) or a connection management (CM) connection (CM-connection) state. SDT may be performed in a random access procedure or an (RRC) resume procedure. In one embodiment, the basic characteristics of SDT may include at least one of the following:

[0083] - The (application) packet size for the uplink (UL) is 100 bytes, and the (application) packet size for the downlink (DL) is 100 bytes;

[0084] - The latency is from 5 seconds to 30 minutes; for a non-mobile scenario, it is 1 hour;

[0085] - The frequency is from once a minute to once a month.

[0086] Note that the latency of SDT refers to the duration from when the SDT packet arrives at the buffer to when the packet is completely transmitted. According to an embodiment, small data transmission is further specified in 3GPP TR 25.705 V13.0.0.

[0087] In Figure 1 , the UE is in an inactive state (e.g., RRC inactive) and / or in a CM connection state. At the start of the RRC resume procedure, the UE resumes from the inactive state and sends an RRC resume request (message) to the gNB (e.g., serving gNB or receiving gNB) to provide an inactive identifier (e.g., inactive radio network temporary identifier (I-RNTI)) and a cause value allocated by the previous serving gNB. The cause value indicates the reason (e.g., rationale, purpose) for sending the RRC resume request. For example, the cause value may indicate a RAN notification area (RNA) update (step 101).

[0088] In step 102, if the gNB can resolve the identifier contained in the inactive identifier (e.g., associated with the previous serving gNB), it requests the previous serving gNB to provide the UE context, e.g., by providing the cause value received in step 101.

[0089] In step 103, the previous serving gNB provides the UE context in a response message (e.g., retrieve UE context response).

[0090] In step 104, the gNB sends an RRC resume message to keep the UE in the inactive state.

[0091] In step 105, the UE sends an RRC Resume Complete message to the gNB.

[0092] In step 106, if the loss of downlink (DL) user data cached at the previous serving gNB should be prevented, the gNB provides a forwarding address to the previous serving gNB.

[0093] In steps 107 and 108, the gNB performs a path switching procedure with the Access and Mobility Management Function (AMF).

[0094] In step 109, the gNB triggers the release of the UE resources at the previous serving gNB.

[0095] Figure 2 It relates to an RRC resume procedure without anchor repositioning according to an embodiment of the present disclosure. Note that the RRC resume procedure without anchor repositioning can only be used for RNA update.

[0096] Specifically, the UE resumes from an inactive state (e.g., RRC_Inactive) by sending an RRC Resume Request (message) to the gNB and providing the I-RNTI allocated by the previous serving gNB and an appropriate cause value (e.g., indicating RNA update) (step 201).

[0097] In step 202, if the gNB can determine the gNB identity included in the I-RNTI, it requests the previous serving gNB to provide the UE context by providing the cause value received in step 201.

[0098] In step 203, the previous serving gNB stores the received information (e.g., Cell RNTI (C-RNTI) and the Physical Cell Identifier (PCI) related to the resumed cell) to be used in the next resume attempt, and responds to the gNB with a failure message (e.g., Retrieve UE Context Failure message) including an encapsulated RRC Release message. In one embodiment, the RRC Release message includes a pending indication.

[0099] In step 204, the gNB forwards the RRC Release message to the UE.

[0100] In the RRC resume procedure, since the serving gNB may not be able to identify the anchor gNB based on the short I-RNTI, the serving gNB may send a context request message (e.g., Retrieve UE Context Request message) to multiple potential anchor gNBs. Considering that the context request message can only be verified by the corresponding anchor gNB and only the anchor gNB has the UE context, it is determined by the anchor gNB whether anchor repositioning (i.e., repositioning of the UE context) is required.

[0101] Below, the receiving gNB can be equal to Figure 1and Figure 2 the receiving node and / or gNB shown in Figure 1 and Figure 2 the anchor node and / or the previous serving gNB shown in

[0102] In Rel-16, the Mobile Originating Early Data Transmission (MO-EDT) function was introduced. MO-EDT allows an optional DL data transmission to follow an UL data transmission during a random access procedure.

[0103] MO-EDT for User Plane Consumer Internet of Things (CIoT) optimization (e.g., as defined in TS 24.501) is characterized by:

[0104] - providing the UE with the Next Hop Link Count (NCC) in the RRC connection release message with a suspend indication;

[0105] - UL user data is transmitted on a dedicated traffic channel (DTCH) multiplexed with the UL RRC connection resume request message on the common control channel (CCCH);

[0106] - DL user data is optionally transmitted on a DTCH multiplexed with the DL RRC connection release message on the DL control channel (DCCH);

[0107] - The short resume message integrity authentication code (MAC-I) is reused as the authentication token for the RRC connection resume request message and is calculated using the integrity key from the previous connection;

[0108] - User data in UL and DL is ciphered (e.g., encrypted). The key is derived by using the NCC provided in the RRC connection release message of the previous RRC connection;

[0109] - The RRC connection release message is integrity protected and ciphered using the newly derived key;

[0110] - There is no transition to the connected state (e.g., RRC connection).

[0111] Figure 3 A schematic diagram of the MO-EDT procedure without anchor repositioning for User Plane CIoT optimization according to an embodiment of the present disclosure is shown.

[0112] Specifically, in response to a connection resume request for mobile originated data from the upper layer, the UE initiates the MO-EDT procedure and selects a random access preamble configured for EDT (step 300).

[0113] In step 301, the UE sends an RRC connection resume request message to the gNB. The RRC connection resume request includes the UE's I-RNTI, resume cause, and authentication token. The UE resumes all source radio bearers (SRBs) and data radio bearers (DRBs), derives a new security key using the NCC provided in the previously connected RRC connection release message, and re-establishes access stratum (AS) security. UL data is cipher-encrypted (e.g., encrypted) and transmitted on the DTCH multiplexed with the RRC connection resume request message on the CCCH.

[0114] In step 302, the UL data is transferred to the user plane function (UPF).

[0115] In step 303, the gNB sends a Next Generation Application Protocol (NG-AP) context resume request message to the Access and Mobility Management Function (AMF) to resume the connection. If the UE includes AS release assistance information indicating no further UL / DL high-layer protocol data units (PDUs) in step 301, the gNB may request an immediate transition to the suspended idle state (RRC idle).

[0116] In step 304 (optional), if the AMF does not receive a request for an immediate transition to the suspended idle state in step 303, or the AMF realizes that DL data or signaling is pending, the AMF requests the Session Management Function (SMF) to resume the PDU session.

[0117] In step 305, the AMF sends an NG-AP context resume response message to the gNB. If the AMF receives a request for an immediate transition to the suspended idle state in step 303 and there is no pending DL data or signaling, the AMF includes a suspension indication in the NG-AP context resume response message and keeps the UE in the suspended idle state (e.g., Connection Management (CM) idle).

[0118] If the AMF includes a suspension indication in the NG-AP context resume response message in step 305, the gNB proceeds to step 308. If the NG-AP context resume response message does not include a suspension indication and the UE includes AS release assistance information indicating only a single DL data transmission after UL transmission in step 301, the gNB may wait for the DL data to arrive (step 306) and proceed to step 307.

[0119] In step 307, the gNB initiates the NG-AP UE context suspension procedure to notify the AMF that the RRC connection is being suspended. The AMF requests the SMF to suspend the PDU session, and the SMF requests the UPF to release the UE's tunnel information.

[0120] In step 308, the gNB sends an RRC connection release message to keep the UE in the idle state (e.g., RRC idle). The message includes the release cause set to RRC - suspended, I - RNTI, NCC, and drb - continue ROHC (drb - ContinueROHC) stored by the UE. If DL data is received in step 306, the information included in the RRC connection release message is cipher - encrypted and sent on the DTCH multiplexed with the RRC connection release message on the DCCH.

[0121] In one embodiment, if the AMF or gNB decides that the UE is to be moved to the connected state (RRC_Connected), an RRC connection resume message is sent in step 307 to fallback to the RRC connection resume procedure. In this case, the RRC connection resume message is integrity - protected and cipher - encrypted using the key derived in step 301, and the UE ignores the NCC included in the RRC connection resume message. DL data can be transmitted on the DTCH multiplexed with the RRC connection resume message. Additionally, an RRC connection setup can also be sent in step 307 to fallback to the RRC connection establishment procedure.

[0122] In one embodiment, if neither an RRC connection release message nor (in the fallback case) an RRC connection resume message is received in response to an RRC connection resume request for MO - EDT, the UE considers the UL data transmission unsuccessful.

[0123] For MO - EDT for user - plane CIoT optimization, the RRC connection can also be resumed in another gNB (e.g., new gNB) different from the gNB ( Figure 3 shown in, or the old gNB) in which the connection was suspended. gNB - to - gNB connection resume is handled using context acquisition, whereby the new gNB obtains the UE context from the old gNB through the Xn interface between the gNBs. The new gNB provides the I - RNTI used by the old gNB to identify the UE context. This is described in Figure 4 the following for the case of user - plane CIoT optimization.

[0124] Figure 4 A schematic diagram of an MO - EDT procedure with anchor re - location for user - plane CIoT optimization according to an embodiment of the present disclosure is shown.

[0125] Specifically, in response to a connection resume request for mobile - originated data from the upper layer, the UE initiates the MO - EDT procedure and selects a random access preamble configured for EDT (step 400).

[0126] In step 401, the UE sends an RRC connection resume request message to the gNB. Among them, the RRC connection resume request includes the UE's I-RNTI, resume reason, and authentication token. The UE resumes all SRBs and DRBs, uses the NCC provided in the previously connected RRC connection release message to derive a new security key, and re-establishes AS security. UL data is cipher-encrypted (e.g., encrypted) and transmitted on the DTCH multiplexed with the RRC connection resume request message on the CCCH.

[0127] In step 402, the new gNB locates the old gNB using the I-RNTI (for 5GS) and retrieves the UE context by means of the Xn-AP (e.g., for the 5G System (5GS)) UE context retrieval procedure. In this embodiment, the new gNB transmits a UE context retrieval request message to the old gNB.

[0128] In step 403, the old gNB responds with the UE context associated with the I-RNTI (e.g., for 5GS) in the UE context retrieval response message.

[0129] In step 404, the new gNB initiates an (NG AP) path switch procedure to establish an NG UE-associated signaling connection to the serving AMF and requests the AMF to resume the UE context.

[0130] In step 405, the AMF requests the SMF to resume the PDU session, and the SMF requests the UPF to create the UE's tunnel information and update the DL path.

[0131] In step 406, the AMF sends an (NG AP) path switch request acknowledgement (ACK) to the new gNB.

[0132] In step 407, after the (NG-AP) path switch procedure is completed, the new gNB triggers the release of the UE context at the old gNB through the (Xn-AP) UE context release procedure. In this embodiment, the new gNB transmits a UE context release message to the old gNB.

[0133] In step 408, the UL data is transmitted from the new gNB to the UPF.

[0134] Steps 409 to 411 can refer to steps 306 to 308.

[0135] Hereinafter, UL / DL data transmission with / without anchor relocation (e.g., for SDT or EDT) is illustrated with emphasis on the security key.

[0136] Figure 5 A schematic diagram showing the procedures associated with security key transfer with and without anchor relocation according to an embodiment of the present disclosure is shown. InFigure 5 In this case, the UE is in an inactive state (e.g., RRC inactive mode) and stores a key K1 and NCC-1, both of which are obtained from a previous connection (e.g., with the previous serving gNB or the anchor gNB) by receiving an RRC connection release message.

[0137] In step 501, the UE sends an RRC connection resume request message to the receiving gNB (such as a new gNB), where the message is cryptographically encrypted with K1. Optionally, the UE also sends UL data cryptographically encrypted with a key k2, where K2 is derived based on K1 and NCC-1.

[0138] In step 502, the receiving gNB sends a retrieve UE context request message to the anchor gNB (e.g., the previous serving gNB or the old gNB). Additionally, if UL data cryptographically encrypted with K2 is received from the UE, the receiving gNB stores (e.g., buffers) the received UL data.

[0139] In step 503, no UL / DL data is transmitted through the anchor gNB. That is, K2 is not used by the anchor gNB.

[0140] In step 504, the anchor gNB sends a retrieve UE context response message to the receiving gNB, where the retrieve UE context response message includes K2 and NCC-2. In one embodiment, K2 is set as in the information element (IE) "Key NG-RAN Star" defined in TS 33.501.

[0141] According to 3GPP TS 38.423, the IEs "Key NG-RAN Star" and "Next-Hop Link Count" are included in the "UE Context Information - Retrieve UE Context Response" IE contained in the retrieve UE context response message.

[0142] In addition, the IE "AS Security Information" is used to generate key material for the AS security to be used for the UE and includes the IEs "Key NG-RAN Star" and "Next-Hop Link Count".

[0143] In step 505 (optional), if the loss of DL user data cached in the anchor gNB should be prevented, the receiving gNB provides a forwarding address to the anchor gNB.

[0144] In step 506, the receiving gNB establishes the UE context (e.g., stores K2 and NCC-2).

[0145] In step 507, the receiving gNB performs a path switch procedure with the AMF.

[0146] In steps 508 and 509, the UE transmits UL data encrypted (e.g., ciphered) by the K2 cipher and receives DL data by decrypting (e.g., deciphering) the received DL data by the K2 cipher. That is, the receiving gNB cipher-encrypts and cipher-decrypts the UL and DL data by K2, respectively.

[0147] In step 510, the receiving gNB may determine to send the UE to one of a connected state (subsequently performing steps 511 and 512), an inactive state, or an idle state (subsequently performing step 513).

[0148] In step 511, the receiving gNB sends an RRC resume message to the UE, which is encrypted by the K2 cipher. In step 512, the UE transmits an RRC resume complete message to the receiving gNB. After steps 511 and 512, the UE is transferred to the connected state.

[0149] In step 513, the receiving gNB sends an RRC connection release message to the UE, which is encrypted by the K2 cipher and includes NCC-3.

[0150] In one embodiment, NCC-1, NCC-2, and NCC-3 may be the same or different values.

[0151] In one embodiment, after anchor repositioning, the receiving gNB becomes the anchor gNB of the UE. Thus, both the UE and the receiving gNB store the same key and the same NCC (i.e., K2 and NCC-3) for further use (e.g., the UE may send another RRC resume request message to the receiving gNB).

[0152] In Figure 5 , the security key (i.e., K2 stored in both the UE and the anchor gNB) is not used by the anchor gNB. Thus, K2 may be passed to the receiving gNB in step 504, and the receiving gNB may use K2 to cipher-encrypt the UL / DL data in steps 508 and 509.

[0153] However, if K2 is used by the anchor gNB in step 503, the anchor gNB cannot send the K2 included in the IE "Key NG-RAN star" in step 504 because different RAN nodes (e.g., the anchor gNB and the receiving gNB) cannot use the same security key. In the present disclosure, a method of passing a new key (e.g., K3) from the anchor node to the receiving node and the UE for future use is proposed.

[0154] Figure 6 FIG. shows a schematic diagram of a process associated with security key transfer according to an embodiment of the present disclosure. In Figure 6In this case, the UE is in an inactive state (e.g., RRC inactive mode) and stores the key K1 and NCC-1, both of which are obtained from a previous connection (e.g., with the previous serving gNB or the anchor gNB) by receiving an RRC connection release message.

[0155] In step 601, the UE sends an RRC connection resume request message to the receiving gNB (such as a new gNB), where the message is cryptographically encrypted by K1. Optionally, the UE also sends UL data cryptographically encrypted by the key k2, where K2 is derived based on K1 and NCC-1.

[0156] In step 602, the receiving gNB sends a retrieve UE context request message to the anchor gNB (e.g., the previous serving gNB or the old gNB). Additionally, if UL data cryptographically encrypted by K2 is received from the UE, the receiving gNB stores (e.g., buffers) the received UL data.

[0157] In step 603, the anchor gNB determines that K2 is being used.

[0158] In step 604, the anchor gNB transmits a retrieve UE context response message including a new key K3 and NCC-2, where NCC-2 can be different from or the same as NCC-1. Additionally, K2 can also be included in the retrieve UE context response message. In one embodiment, K3 can be determined based on K2. For example, K3 can be derived based on K2 and one of NCC-1, NCC-2.

[0159] In step 605 (optional), if the loss of DL user data cached in the anchor gNB should be prevented, the receiving gNB provides a forwarding address to the anchor gNB.

[0160] In step 606, the receiving gNB establishes a UE context (e.g., stores K3 and NCC-2).

[0161] In step 607, the receiving gNB performs a path switching procedure with the AMF.

[0162] In step 608, the receiving gNB can determine to send the UE to one of a connected state (subsequently performing steps 609a, 609b or steps 609b to 612b), an inactive state or an idle state (subsequently performing step 613 or steps 609b, 610b, 613).

[0163] Specifically, if K2 is received in step 604, the receiving gNB itself can use K2 to encrypt the RRC resume message or RRC release message including K3 and NCC-2. In this case, when it is determined to send the UE to the connected state, the receiving gNB transmits the RRC resume message encrypted by K2 to the UE and receives the RRC resume complete message from the UE (steps 609a and 610a). Alternatively, when it is determined to send the UE to the inactive state or idle state, the receiving gNB sends the RRC release message encrypted by K2 to the UE (step 613).

[0164] In an embodiment where K2 is not included in the retrieved UE context response message in step 604, the receiving gNB itself cannot encrypt the RRC resume message or RRC release message by K2. Therefore, when it is determined to send the UE to the connected state, the receiving gNB transmits a relocation request to the anchor gNB, where the relocation request includes the RRC resume message containing K3 and NCC-2 (step 609b). The anchor gNB encrypts the RRC resume message by K2 and transmits the encrypted RRC resume message to the receiving gNB (step 610b). Next, the receiving gNB transmits the encrypted RRC resume message including K3 and NCC-2 to the UE and receives the RRC resume complete message from the UE. When it is determined to send the UE to the inactive state or idle state, the receiving gNB transmits a relocation request to the anchor gNB, where the relocation request includes the RRC release message containing K3 and NCC-2 (step 609b). The anchor gNB encrypts the RRC release message by K2 and transmits the encrypted RRC resume message to the receiving gNB (step 610b). Therefore, the receiving gNB can transmit the encrypted RRC release message including K3 and NCC-2 to the UE (step 613).

[0165] Hereinafter, the actions of the UE, receiving gNB, and anchor gNB in Figure 6 are described separately.

[0166] According to one embodiment, the actions of the anchor gNB in the Figure 6 shown process include:

[0167] 1) Receive a retrieved UE context request message for the UE from the receiving gNB;

[0168] 2) Determine (e.g., ascertain) whether the security key stored for the UE is being used. (That is, K2 stored in the previous connection with the UE and sent to the UE via RRC signaling (e.g., RRC resume message and RRC release message));

[0169] 3) If K2 is used, set a new key (i.e., K3) and NCC, and send a Retrieve UE Context Response message including K3 and NCC-2, with the new key set within the IE "Key NG-RAN star". Optionally, K2 can also be included in this message;

[0170] 4) Optionally, if a message M1 including an RRC Resume or RRC Release message is received from the receiving gNB, send a message M2 including the RRC Resume or RRC Release message to the receiving gNB, where the RRC Resume or RRC Release message in message M2 is encrypted with the K2 cipher.

[0171] In one embodiment, messages M1 and M2 are XnAP signaling between the receiving gNB and the anchor gNB. For example, message M1 is named the Relocation Request message and message M2 is named the Relocation Response message.

[0172] According to one embodiment, the actions of the receiving gNB in Figure 6 the shown process include:

[0173] 1) Receive an RRC Resume Request message from the UE;

[0174] 2) Send a Retrieve UE Context Request message to the anchor gNB;

[0175] 3) Receive a Retrieve UE Context Response message from the anchor gNB, and store the K3 and NCC included in the message, and, if K2 is included in the message, optionally store K2.

[0176] 4) Decide to send the UE to one of RRC Connected mode, RRC Inactive mode, or Idle mode; if K2 is included in the Retrieve UE Context Response message, perform action 5); otherwise, perform actions 6) to 8):

[0177] 5) If K2 is included in the Retrieve UE Context Response message, send an RRC Resume message including K3 (optionally including NCC-2) to the UE, or send an RRC Resume message including K3 and NCC-2 to the UE, where both the RRC Resume message and the RRC Release message are encrypted with the K2 cipher;

[0178] 6) If K2 is not included in the Retrieve UE Context Response message, send a message M1 including an RRC Resume / RRC Release message, where both the RRC Resume and RRC Release messages include K3 and NCC-2;

[0179] 7) Receive message M2, which includes an RRC Resume / RRC Release message encrypted with the key K2, where both messages include K3 and NCC-2;

[0180] 8) Send a cipher - encrypted RRC Resume / RRC Release message including K3 and NCC - 2, where both of these two RRC messages are cipher - encrypted by K2 at the anchor gNB.

[0181] According to one embodiment, the actions of the UE in Figure 6 the process shown include:

[0182] 1) Store K1 and NCC obtained by receiving an RRC message (such as an RRC Resume or RRC Release message) in the previous connection (with the anchor node).

[0183] 2) Send an RRC Resume Request message to the receiving gNB, which is cipher - encrypted by K1.

[0184] 3) Optionally, transmit UL data and receive DL data cipher - encrypted by K2 derived from K1 and NCC.

[0185] 4) Receive an RRC Resume message cipher - encrypted by K2 or an RRC Release message cipher - encrypted by K2, where the RRC Resume message and RRC Release message including K3 (and optionally NCC - 2) include K3 and NCC - 2.

[0186] 5) Store K3 and NCC, and enter the RRC Inactive mode or Idle mode.

[0187] 6) When sending another RRC Resume Request message to the receiving gNB, cipher - encrypt (encrypt) the message using K3.

[0188] In summary:

[0189] Both the UE and the receiving gNB store K3 and NCC.

[0190] The receiving gNB sends an RRC Resume / RRC Release message including K3 and NCC to the UE in two ways:

[0191] Method 1: If the receiving gNB obtains K2 for cipher - encrypting the RRC message, the receiving gNB cipher - encrypts the RRC message.

[0192] Method 2: If the receiving gNB transmits the RRC message to the anchor gNB for cipher - encrypting the RRC message, the anchor gNB cipher - encrypts the RRC message.

[0193] Figure 7 shows a flowchart of a process according to an embodiment of the present disclosure. Figure 7 The process shown in can be used in an anchor node (e.g., an anchor gNB) and includes the following steps:

[0194] Step 701: Receive a context request message associated with a wireless terminal from a serving node;

[0195] Step 702: Transmit a context response message to the serving node, the context response message including a third key different from the second key and a second next-hop link count.

[0196] In Figure 7 the anchor node receives a context request message associated with a wireless terminal, for example, for requesting context information of the wireless terminal. In this embodiment, a first key and a first NCC are transmitted to the wireless terminal in a previous connection between the anchor node and the wireless terminal, and a second key determined based on the first key and the first next-hop link count is used by the anchor node. In this case, the anchor node transmits a context response message to the serving node, the context response message including a third key different from the second key and a second NCC. It should be noted that the second NCC may be different from the first NCC or the same as the first NCC.

[0197] In one embodiment, the third key is an intermediate key used between the wireless terminal and the serving node. For example, the third key can be used for UL / DL data transmission between the serving node or the wireless terminal.

[0198] In one embodiment, the third key is determined based on the second key.

[0199] In one embodiment, the first key and the first next-hop link count are transmitted to the wireless terminal via an RRC connection release message.

[0200] In one embodiment, the context response message further includes the second key.

[0201] In one embodiment, the anchor node receives a first message including an RRC message associated with a mobile terminal from the serving node and transmits a second message including a radio resource control message encrypted by the second key to the serving node. In this embodiment, the RRC message can be an RRC resume message or an RRC release message. Additionally, the first message and the second message are XnAP signaling.

[0202] Figure 8 shows a flowchart of a process according to an embodiment of the present disclosure. Figure 8 The illustrated process can be used in a serving node (e.g., serving gNB) and includes the following steps:

[0203] Step 801: Receive a resume request message encrypted by a first key from a wireless terminal;

[0204] Step 802: Transmit a context request message associated with the wireless terminal to the anchor node;

[0205] Step 803: Receive a context response message including a third key and a second next-hop link count from the anchor node;

[0206] Step 804: Transmit a radio resource control message to the wireless terminal, the radio resource control message being encrypted by a second key and including the third key and the second next-hop link count.

[0207] In Figure 8 the serving node receives a resume request message from the wireless terminal (e.g., in an inactive state), where the resume request message is encrypted by a first key. The first key and the first NCC are transmitted to the wireless terminal in a previous connection between the anchor node and the wireless terminal. For example, the first key and the first NCC are included in an RRC release message. In response to the resume request message, the serving node transmits a context request message associated with the wireless terminal to the anchor node, e.g., for requesting context information of the wireless terminal (e.g., UE context). In this embodiment, the serving node receives a context response message including a third key and a second NCC, where the third key is different from the second key determined based on the first key and the first NCC. The serving node transmits an RRC message to the wireless terminal, the message being encrypted by the second key and including the third key and the second next-hop link count.

[0208] In one embodiment, the second NCC is the same as or different from the first NCC.

[0209] In one embodiment, the third key is an intermediate key used between the wireless terminal and the serving node.

[0210] In one embodiment, the third key is determined based on the second key.

[0211] In one embodiment, the serving node does not receive at least one signaling message and / or uplink data of the wireless terminal from the wireless terminal earlier than (at that time or later) receiving the resume request message and / or transmitting the radio resource control message. It should be noted that at least one signaling message and the uplink data of the wireless terminal are encrypted by the second key.

[0212] In one embodiment, the first key and the first NCC are transmitted through an RRC connection release message in the previous connection.

[0213] In one embodiment, the radio resource control message is one of a radio resource control resume message or a radio resource control release message.

[0214] In one embodiment, the context response message further includes the second key.

[0215] In one embodiment, the serving node transmits a first message including a radio resource control message to the anchor node and receives a second message including the radio resource control message encrypted by a second key from the anchor node.

[0216] In one embodiment, the first message and the second message are XnAP signaling.

[0217] Figure 9 A flowchart of a process according to an embodiment of the present disclosure is shown. Figure 9 The process shown can be used in a wireless terminal (e.g., a UE) and includes the following steps:

[0218] Step 901: Transmit a recovery request message encrypted by a first key to the serving node;

[0219] Step 902: Receive a radio resource control message from the serving node, where the radio resource control message is encrypted by a second key determined based on the first key and the first next-hop link count and includes a third key different from the second key and a second next-hop link count.

[0220] In Figure 9 a wireless terminal transmits a recovery request message encrypted by a first key to the serving node, where the first key and the first NCC are received in a previous connection between the wireless terminal and an anchor node different from the serving node. Next, the wireless terminal receives an RRC message from the serving node, where the RRC message is encrypted by a second key determined based on the first key and the first NCC. In this embodiment, the RRC message includes a third key different from the second key and a second NCC that may be different from or the same as the first NCC.

[0221] In one embodiment, the third key is an intermediate key used between the wireless terminal and the serving node. For example, the wireless terminal can communicate with the serving node (e.g., UL / DL data transmission) by using the third key after receiving the RRC message.

[0222] In one embodiment, the third key is determined based on the second key.

[0223] In one embodiment, the wireless terminal does not transmit at least one signaling message and / or uplink data of the wireless terminal to the serving node earlier than (at that time or later) receiving the recovery request message and / or transmitting the radio resource control message. It should be noted that at least one signaling message and the uplink data of the wireless terminal are encrypted by the second key.

[0224] In one embodiment, the first key and the first NCC are transmitted through an RRC connection release message.

[0225] In one embodiment, the radio resource control message is one of an RRC resume message or an RRC release message.

[0226] In one embodiment, the context response message further includes a second key.

[0227] Figure 10 Schematic diagram of a wireless terminal 100 according to an embodiment of the present disclosure. The wireless terminal 100 may be a user equipment (UE), a mobile phone, a laptop computer, a tablet computer, an e-book, or a portable computer system, and is not limited thereto. The wireless terminal 100 may include a processor 1000 (such as a microprocessor or an application specific integrated circuit (ASIC)), a storage unit 1010, and a communication unit 1020. The storage unit 1010 may be any data storage device that stores program code 1012 accessed and executed by the processor 1000. Embodiments of the storage unit 1010 include, but are not limited to, a subscriber identity module (SIM), a read-only memory (ROM), a flash memory, a random access memory (RAM), a hard disk, and an optical data storage device. The communication unit 1020 may be a transceiver and is used to transmit and receive signals (e.g., messages or data packets) according to the processing result of the processor 1000. In one embodiment, the communication unit 1020 transmits and receives signals via Figure 10 at least one antenna 1022 as shown.

[0228] In one embodiment, the storage unit 1010 and the program code 1012 may be omitted, and the processor 1000 may include a storage unit having the stored program code.

[0229] The processor 1000 may implement any step in the exemplary embodiments on the wireless terminal 100, for example, by executing the program code 1012.

[0230] The communication unit 1020 may be a transceiver. As an alternative or in addition, the communication unit 1020 may combine a transmitting unit and a receiving unit, and the transmitting unit and the receiving unit are configured to transmit signals to and receive signals from a wireless network node (e.g., a base station), respectively.

[0231] Figure 11Schematic diagram of a wireless network node 110 according to an embodiment of the present disclosure. The wireless network node 110 may be a satellite, a base station (BS), a network entity, a mobility management entity (MME), a serving gateway (S-GW), a packet data network (PDN) gateway (P-GW), a radio access network (RAN), a next-generation RAN (NG-RAN), a gNB, an eNB, an NG-eNB, a data network, a core network, or a radio network controller (RNC), and is not limited thereto. Additionally, the wireless network node 110 may include (perform) at least one network function, such as an access and mobility management function (AMF), a session management function (SMF), a user plane function (UPF), a policy control function (PCF), an application function (AF), etc. The wireless network node 110 may include a processor 1100, such as a microprocessor or an ASIC, a storage unit 1110, and a communication unit 1120. The storage unit 1110 may be any data storage device that stores program code 1112 accessed and executed by the processor 1100. Examples of the storage unit 1110 include, but are not limited to, a SIM, a ROM, a flash memory, a RAM, a hard disk, and an optical data storage device. The communication unit 1120 may be a transceiver and is used to transmit and receive signals (e.g., messages or data packets) according to the processing result of the processor 1100. In one example, the communication unit 1120 transmits and receives signals via Figure 11 at least one antenna 1122 shown.

[0232] In one embodiment, the storage unit 1110 and the program code 1112 may be omitted. The processor 1100 may include a storage unit with stored program code.

[0233] The processor 1100 may implement any of the steps described in the exemplary embodiments on the wireless network node 110, for example, by executing the program code 1112.

[0234] The communication unit 1120 may be a transceiver. As an alternative or in addition, the communication unit 1120 may combine a transmitting unit and a receiving unit, which are configured to transmit signals to and receive signals from a wireless terminal (e.g., a user equipment), respectively.

[0235] Although various embodiments of the present disclosure have been described above, it should be understood that they are presented by way of example and not limitation. Similarly, the various figures may depict exemplary architectures or configurations that are provided to enable those of ordinary skill in the art to understand the exemplary features and functions of the present disclosure. However, those skilled in the art will understand that the present disclosure is not limited to the exemplary architectures or configurations shown, but rather can be implemented using a variety of alternative architectures and configurations. In addition, as will be understood by those of ordinary skill in the art, one or more features of one embodiment may be combined with one or more features of another embodiment described herein. Accordingly, the breadth and scope of the present disclosure should not be limited by any of the above-described exemplary embodiments.

[0236] It should also be understood that any reference to elements using designations such as “first,” “second,” etc. generally does not limit the number or order of these elements. Rather, these designations may herein be used as a convenient means of distinguishing between two or more elements or between multiple instances of an element. Thus, a reference to first and second elements does not mean that only two elements may be used or that the first element must precede the second element in some manner.

[0237] In addition, those of ordinary skill in the art will understand that any of a variety of different techniques may be used to represent information and signals. For example, data, instructions, commands, information, signals, bits, and symbols that may be referred to in the above description may be represented, for example, by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

[0238] Those skilled in the art will further understand that any of the various illustrative logical blocks, units, processors, devices, circuits, methods, and functions described in connection with the aspects disclosed herein may be implemented by electronic hardware (e.g., digital implementation, analog implementation, or a combination of both), firmware, various forms of programs or design code incorporating instructions (for convenience, referred to herein as “software” or “software units”), or any combination of these techniques.

[0239] To clearly illustrate this interchangeability of hardware, firmware, and software, various illustrative components, blocks, units, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware, firmware, or software, or as a combination of these techniques, depends upon the particular application and design constraints imposed on the overall system. Those skilled in the art can implement the described functionality in various ways for each particular application, but such implementation decisions do not result in a departure from the scope of the present disclosure. According to various embodiments, a processor, device, component, circuit, structure, machine, unit, etc. may be configured to perform one or more of the functions described herein. As used herein, the terms "configured to" or "configured for" with respect to a specified operation or function refer to a processor, device, component, circuit, structure, machine, unit, etc. that is physically constructed, programmed, and / or arranged to perform the specified operation or function.

[0240] In addition, those skilled in the art will understand that the various illustrative logical blocks, units, devices, components, and circuits described herein may be implemented within or performed by an integrated circuit (IC), which may include a general-purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, or any combination thereof. The logical blocks, units, and circuits may also include antennas and / or transceivers to communicate with various components within a network or within a device. A general-purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, or state machine. The processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in combination with a DSP core, or any other suitable configuration to perform the functions described herein. If implemented in software, these functions may be stored as one or more instructions or code on a computer-readable medium. Accordingly, the steps of the methods or algorithms disclosed herein may be implemented as software stored on a computer-readable medium.

[0241] Computer-readable media includes computer storage media and communication media, and communication media includes any medium that can transfer a computer program or code from one place to another. Storage media may be any available medium that can be accessed by a computer. By way of example and not limitation, such computer-readable media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired program code in the form of instructions or data structures and that can be accessed by a computer.

[0242] In this document, the term "unit" as used herein refers to software, firmware, hardware, and any combination of these elements for performing the associated functions described herein. Additionally, for purposes of discussion, the various units are described as discrete units; however, as will be apparent to one of ordinary skill in the art, in accordance with embodiments of the present disclosure, two or more units may be combined to form a single unit that performs the associated functions.

[0243] Additionally, a memory or other storage device and communication components may be used in embodiments of the present disclosure. It should be understood that, for clarity, the above description has described embodiments of the present disclosure with reference to different functional units and processors. However, it will be apparent that any suitable distribution of functionality may be applied between different functional units, processing logic elements, or domains without departing from the present disclosure. For example, functions shown to be performed by separate processing logic elements or controllers may be performed by the same processing logic element or controller. Thus, the reference to specific functional units is merely a reference to the appropriate means for providing the recited functionality and not an indication of a strict logical or physical structure or organization.

[0244] Various modifications to the implementations described in this disclosure will be apparent to those skilled in the art, and the general principles defined herein may be applied to other implementations without departing from the scope of the disclosure. Thus, the disclosure is not limited to the implementations shown herein but is to be accorded the widest scope consistent with the novel features and principles disclosed herein as set forth in the following claims.

Claims

1. A wireless communication method for use in an anchor node, the method comprising: Receiving, from a serving node, a context request message associated with a wireless terminal, wherein a first key and a first next-hop link count are transmitted to the wireless terminal in a previous connection between the anchor node and the wireless terminal, and wherein a second key determined based on the first key and the first next-hop link count is used by the anchor node; Transmitting a context response message to the serving node, the context response message including a third key different from the second key and a second next-hop link count; Receiving, from the serving node, a first message including a radio resource control message associated with the wireless terminal; and Transmitting a second message including the radio resource control message encrypted by the second key to the serving node.

2. The wireless communication method according to claim 1, wherein, The third key is an intermediate key used between the wireless terminal and the serving node.

3. The wireless communication method according to claim 1 or 2, wherein The third key is determined based on the second key.

4. The wireless communication method according to any one of claims 1 to 3, wherein, The first key and the first next-hop link count are transmitted via a radio resource control connection release message.

5. The wireless communication method according to any one of claims 1 to 4, wherein, The context response message further includes the second key.

6. The wireless communication method according to claim 1, wherein, The radio resource control message is one of a radio resource control resume message or a radio resource control release message.

7. The wireless communication method according to claim 1 or 6, wherein The first message and the second message are Xn Application Protocol (XnAP) signaling.

8. A wireless communication method for use in a serving node, the method comprising: Receiving, from a wireless terminal, a resume request message encrypted by a first key, wherein the first key and a first next-hop link count are transmitted to the wireless terminal in a previous connection between an anchor node and the wireless terminal; Transmitting a context request message associated with the wireless terminal to the anchor node; Receiving, from the anchor node, a context response message including a third key and a second next-hop link count, wherein the third key is different from a second key determined based on the first key and the first next-hop link count; Transmitting a radio resource control message to the wireless terminal, the radio resource control message being encrypted by the second key and including the third key and the second next-hop link count; Transmitting a first message including the radio resource control message to the anchor node; and Receiving, from the anchor node, a second message including the radio resource control message encrypted by the second key.

9. The wireless communication method according to claim 8, wherein, The third key is an intermediate key used between the wireless terminal and the serving node.

10. The wireless communication method according to claim 8 or 9, wherein, The third key is determined based on the second key.

11. The wireless communication method according to any one of claims 8 to 10, further comprising: Receiving, from the wireless terminal, at least one signaling message and / or uplink data of the wireless terminal not earlier than receiving the resume request message and / or transmitting the radio resource control message, wherein the at least one signaling message and the uplink data of the wireless terminal are encrypted by the second key.

12. The wireless communication method according to any one of claims 8 to 11, wherein, The first key and the first next-hop link count are transmitted via a radio resource control connection release message.

13. The wireless communication method according to any one of claims 8 to 12, wherein, The radio resource control message is one of a radio resource control resume message or a radio resource control release message.

14. The wireless communication method according to any one of claims 8 to 13, wherein, The context response message further includes the second key.

15. The wireless communication method according to claim 8, wherein, The first message and the second message are Xn application protocol XnAP signaling.

16. The wireless communication method according to any one of claims 8 to 15, further comprising: After transmitting the radio resource control message, communicating with the wireless terminal by using the third key.

17. A wireless communication method for use in a wireless terminal, the method comprising: Transmitting a resume request message encrypted with a first key to a serving node, wherein the first key and a first next-hop link count are received in a previous connection between the wireless terminal and an anchor node different from the serving node, Receiving a radio resource control message from the serving node, the radio resource control message being encrypted with a second key determined based on the first key and the first next-hop link count, and including a third key different from the second key and a second next-hop link count, and Transmitting at least one signaling message and / or uplink data of the wireless terminal to the serving node not earlier than transmitting the resume request message and / or before receiving the radio resource control message, wherein the at least one signaling message and the uplink data of the wireless terminal are encrypted with the second key.

18. The wireless communication method according to claim 17, wherein, The third key is an intermediate key used between the wireless terminal and the serving node.

19. The wireless communication method according to claim 17 or 18, wherein, The third key is determined based on the second key.

20. The wireless communication method according to any one of claims 17 to 19, wherein, The first key and the first next-hop link count are received in a radio resource control connection release message.

21. The wireless communication method according to any one of claims 17 to 20, wherein, The radio resource control message is one of a radio resource control resume message or a radio resource control release message.

22. The wireless communication method according to any one of claims 17 to 21, further comprising: After receiving the radio resource control message, communicating with the serving node by using the third key.

23. An anchor node, comprising: A communication unit configured to: Receive a context request message associated with a wireless terminal from a serving node, wherein a first key and a first next-hop link count are transmitted to the wireless terminal in a previous connection between the anchor node and the wireless terminal, and wherein a second key determined based on the first key and the first next-hop link count is used by the anchor node, Transmit a context response message to the serving node, the context response message including a third key different from the second key and a second next-hop link count, Receive a first message including a radio resource control message associated with the wireless terminal from the serving node, and Transmit a second message including the radio resource control message encrypted with the second key to the serving node.

24. The anchor node according to claim 23, further comprising a processor configured to execute the wireless communication method according to any one of claims 2 to 7.

25. A serving node, comprising: A communication unit, configured to: Receive, from a wireless terminal, a recovery request message encrypted with a first key, wherein the first key and a first next-hop link count are transmitted to the wireless terminal during a previous connection between an anchor node and the wireless terminal; Transmit, to the anchor node, a context request message associated with the wireless terminal; Receive, from the anchor node, a context response message including a third key and a second next-hop link count, wherein the third key is different from a second key determined based on the first key and the first next-hop link count; Transmit, to the wireless terminal, a radio resource control message encrypted with the second key and including the third key and the second next-hop link count; Transmit, to the anchor node, a first message including the radio resource control message; and Receive, from the anchor node, a second message including the radio resource control message encrypted with the second key.

26. The serving node according to claim 25, further comprising a processor configured to execute the wireless communication method according to any one of claims 9 to 16.

27. A wireless terminal, comprising: A communication unit, configured to: Transmit, to a serving node, a recovery request message encrypted with a first key, wherein the first key and a first next-hop link count are received during a previous connection between the wireless terminal and an anchor node different from the serving node; and Receive, from the serving node, a radio resource control message encrypted with a second key determined based on the first key and the first next-hop link count and including a third key different from the second key and a second next-hop link count; and Transmit, to the serving node, at least one signaling message and / or uplink data of the wireless terminal not earlier than transmitting the recovery request message and / or before receiving the radio resource control message, wherein the at least one signaling message and the uplink data of the wireless terminal are encrypted with the second key.

28. The wireless terminal according to claim 27, further comprising a processor configured to execute the wireless communication method according to any one of claims 18 to 22.

29. A computer program product, comprising computer-readable program medium code stored thereon, the code causing a processor to implement the wireless communication method according to any one of claims 1 to 22 when executed by the processor.

Images