Patent Description:
When a user equipment (UE) resumes connections with a serving node (e.g. radio access network (RAN) node), the serving node needs to request UE context from the last serving node of the UE, wherein the UE context may comprise a security key configured to the UE in previous connections with the last serving node. If the security key is not used by the last serving node, the security key can be transferred to the serving node and the serving node can use the security key to cipher UL/DL data for the UE. However, if the security key is used by the last serving node when the last serving node receives the request for the UE context, the last serving node cannot send the security key because different nodes cannot use the same security key.

This document relates to methods, systems, and devices for key transfer, and in particular to methods, systems, and devices for key transfer during a resume procedure.

The present disclosure relates to a wireless communication method for use in an anchor node. The method comprises:.

Various embodiments may preferably implement the following features:
Preferably, the third key is an intermediate key used between the of the wireless terminal and the serving node.

Preferably, the third key is determined based on the second key.

Preferably, the first key and the first next hop chaining count are transmitted via a radio resource control connection release message.

Preferably, the context response message further comprises the second key.

Preferably, the wireless communication method further comprises:.

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

Preferably, the first message and the second message are Xn application protocol, XnAP, signaling.

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

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

Preferably, the first key and the first next hop chaining count are transmitted via a radio resource control connection Release message.

Preferably, the wireless communication method further comprises communicating with the wireless terminal by using the third key after transmitting the radio resource control message.

The present disclosure relates to a wireless communication method for use in a wireless terminal, the method comprising:.

Preferably, the first key and the first next hop chaining count are received in a radio resource control connection Release message.

Preferably, the radio resource control message is one of a radio resource control Resume message or a radio resource control Release message.

Preferably, the wireless communication method further comprises communicating with the serving node by using the third key after receiving the radio resource control message.

The present disclosure relates to an anchor node. The anchor node comprises:
a communication unit, configured to:.

Various embodiments may preferably implement the following feature:
Preferably, the anchor node further comprises a processor configured to perform any of the aforementioned wireless communication method.

The present disclosure relates to a serving node. The serving node comprises:
a communication unit, configured to:.

Various embodiments may preferably implement the following feature:
Preferably, the serving node further comprises a processor configured to perform any of the aforementioned wireless communication method.

The present disclosure relates to a wireless terminal. The wireless terminal comprises:
a communication unit, configured to:.

Various embodiments may preferably implement the following feature:
Preferably, the wireless terminal further comprises a processor configured to perform any of the aforementioned wireless communication method.

The present disclosure relates to a computer program product comprising a computer-readable program medium code stored thereupon, the code, when executed by a processor, causing the processor to implement a wireless communication method recited in any one of foregoing methods.

The exemplary embodiments disclosed herein are directed to providing features that will become readily apparent by reference to the following description when taken in conjunction with the accompany drawings. In accordance with various embodiments, exemplary systems, methods, devices and computer program products are disclosed herein. It is understood, however, 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 who read the present disclosure that various modifications to the disclosed embodiments can be made while remaining within the scope of the present disclosure.

<FIG> relates to a radio resource control (RRC) resume procedure with anchor relocation according to an embodiment of the present disclosure. In this embodiment, the UE context is transferred from an anchor gNB (e.g. the last serving gNB) to a current serving gNB (e.g. receiving gNB), a path switch procedure is performed after the UE context is fetched and the serving gNB becomes the new anchor gNB after the anchor relocation (e.g. the relocation of the UE context).

In the present disclosure, the gNB may be equal to a wireless network node, a radio access network (RAN) node, a next generation (NG) RAN node, an evolved Node B (eNB), or an NG-eNB. In addition, the UL/DL data in the following may be data for a small data transmission (SDT). In the present disclosure, the SDT may be a data transmission performed for the UE in an inactive state (e.g. radio resource control (RRC) inactive state (RRC_INACTIVE)) or a connection management (CM) connected (CM-CONNECTED) state. The SDT may be performed in a random access procedure or a(n) (RRC) resume procedure. In an embodiment, fundamental characteristics of the SDT may comprise at least one of:.

Note that, the latency of the SDT is a duration from the packet of the SDT arriving at the buffer until the packet is completely transmitted. According to an embodiment, the small data transmission is further specified in 3GPP TR <NUM> V13.

In <FIG>, the UE is in an inactive state (e.g. RRC INACTIVE) and/or in the CM-CONNECTED state. In the beginning of the RRC resume procedure, the UE resumes from the inactive state and sends an RRC resume request (message) to a gNB (e.g. serving gNB or receiving gNB), for providing an inactive identifier (e.g. inactive radio network temporary identifier (I-RNTI)) allocated by the last serving gNB and a cause value. The cause value indicates a cause (e.g. reason, purpose) of sending the RRC resume request. For example, the cause value may indicate an RAN notification area (RNA) update (step <NUM>).

In step <NUM>, the gNB, if able to resolve an identity (e.g. associated with the last serving gNB) contained in the inactive identifier, requests the last serving gNB to provide UE context, e.g. by providing the cause value received in step <NUM>.

In step <NUM>, the last serving gNB provides the UE context in a response message (e.g. RETRIEVE UE CONTEXT RESPONSE).

In step <NUM>, the gNB transmits an RRC Resume message to keep the UE in the inactive state.

In step <NUM>, the UE transmits an RRC Resume complete message to the gNB.

In step <NUM>, if loss of downlink (DL) user data buffered in the last serving gNB shall be prevented, the gNB provides forwarding addresses to the last serving gNB.

In steps <NUM> and <NUM>, the gNB performs a path switch procedure with an access and mobility management function (AMF).

In step <NUM>, the gNB triggers a release of the UE resources at the last serving gNB.

<FIG> relates to an RRC resume procedure without the anchor relocation according to an embodiment of the present disclosure. Note that, the RRC resume procedure without the anchor relocation may only be used for the RNA update.

In detail, the UE resumes from the inactive state (e.g. RRC_INACTIVE) by sending an RRC resume request (message) to the gNB and providing the I-RNTI allocated by the last serving gNB and the appropriate cause value, e.g., indicating the RNA update (step <NUM>).

In step <NUM>, the gNB, if able to determine the gNB identity contained in the I-RNTI, requests the last serving gNB to provide the UE context by providing the cause value received in step <NUM>.

In step <NUM>, the last serving gNB stores the received information to be used in the next resume attempt (e.g. cell RNTI (C-RNTI) and physical cell identifier (PCI) related to a resumption cell), and responds to the gNB with the a failure message (e.g. RETRIEVE UE CONTEXT FAILURE message) including an encapsulated RRC Release message. In an embodiment, the RRC Release message includes a suspend indication.

In step <NUM>, the gNB forwards the RRC Release message to the UE.

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 the context request message (e.g. Retrieve UE Context Request message) to multiple potential anchor gNBs. Considering the context request message can only be verified by the corresponding anchor gNB and only the anchor gNB has the UE context, it is up to the anchor gNB to determine whether the anchor relocation (i.e. the relocation of the UE context) is needed or not.

In the following, the receiving gNB may be equal to a receiving node and/or the gNB shown in <FIG>. The anchor gNB may be equal to an anchor node and/or the last serving gNB shown in <FIG>.

In Rel-<NUM>, a mobile originated early day transmission, MO-EDT, function is introduced. The MO-EDT allows one UL data transmission to be optionally followed by one DL data transmission during the random access procedure.

The MO-EDT for user plane consumer-internet-of-thing (CIoT) optimization (e.g. as defined in TS <NUM>) are characterized by:.

<FIG> shows a schematic diagram of an MO-EDT procedure without anchor relocation for the user plane CIoT optimization according to an embodiment of the present disclosure.

Specifically, upon connection resumption request for mobile originated data from upper layers, the UE initiates the MO-EDT procedure and selects a random access preamble configured for the EDT (step <NUM>).

In step <NUM>, the UE sends an RRC Connection Resume Request message to the gNB, wherein the RRC Connection Resume Request comprises an I-RNTI of the UE, a resume cause and an authentication token. The UE resumes all source radio bearers (SRBs) and data radio bearers (DRBs), derives new security keys using an NCC provided in an RRC Connection Release message of the previous connection and re-establishes the access stratum (AS) security. The UL data are ciphered (e.g. encrypted) and transmitted on the DTCH multiplexed with the RRC Connection Resume Request message on the CCCH.

In step <NUM>, the UL data is delivered to a user plane function (UPF).

In step <NUM>, the gNB sends a next generation application protocol (NG-AP) Context Resume Request message to an access and mobility management function (AMF) to resume a connection. If the UE includes an AS Release Assistance information indicating No further UL/DL higher layer packet data unit (PDU) in step <NUM>, the gNB may request for an immediate transition to an idle state (RRC IDLE) with suspend.

In step <NUM> (optional), if the AMF does not receive a request for the immediate transition to the idle state with the suspend in step <NUM> or the AMF is aware of that DL data or signaling is pending, the AMF requests a session management function (SMF) to resume the PDU session.

In step <NUM>, the AMF sends an NG-AP Context Resume Response message to the gNB. If the AMF receives a request for the immediate transition to the idle state with the suspend in step <NUM> and there is no pending DL data or signaling, the AMF includes a suspend indication in the NG-AP Context Resume Response message and keeps the UE in the idle state (e.g. connection management (CM) IDLE) with the suspend.

If the AMF includes the suspend indication in the NG-AP Context Resume Response message in step <NUM>, the gNB proceeds to step <NUM>. If the NG-AP Context Resume Response message does not include the suspend indication and the UE includes AS Release Assistance information indicating only a single DL data transmission subsequent to the UL transmission in step <NUM>, the gNB may wait for the DL data to arrive (step <NUM>) and proceeds to step <NUM>.

In step <NUM>, the gNB initiates an NG-AP UE Context Suspend procedure to inform 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 tunnel information for the UE.

In step <NUM>, the gNB sends an RRC Connection Release message to keep the UE in the idle state (e.g. RRC IDLE). This message includes a release cause set to RRC-Suspend, the I-RNTI, the NCC and drb-ContinueROHC which are stored by the UE. If the DL data were received in step <NUM>, the information comprised in the RRC Connection Release message is ciphered and sent on the DTCH multiplexed with the RRC Connection Release message on the DCCH.

In an embodiment, if the AMF or gNB decides that the UE is moved to a connected state (RRC_CONNECTED), an RRC Connection Resume message is sent in step <NUM>, to fall back to the RRC Connection resume procedure. In that case, the RRC Connection Resume message is integrity protected and ciphered with the keys derived in step <NUM> and the UE ignores the NCC included in the RRC Connection Resume message. The DL data may be transmitted on the DTCH multiplexed with the RRC Connection Resume message. In addition, an RRC Connection Setup may also be sent in step <NUM>, to fall back to the RRC Connection establishment procedure.

In an embodiment, if neither the RRC Connection Release message nor, in case of fallback, RRC Connection Resume message is received in response to the RRC Connection Resume Request for the MO-EDT, the UE considers the UL data transmission not successful.

For the MO-EDT for user plane CIoT optimization, an RRC connection can also be resumed in another gNB (e.g. new gNB) different from the one where the connection was suspended (the gNB shown in <FIG>, or old gNB). Inter gNB connection resumption is handled using context fetching, whereby the new gNB retrieves the UE context from the old gNB over Xn interface between gNBs. The new gNB provides the I-RNTI which is used by the old gNB, to identify the UE context. This is illustrated in the following <FIG> for the case of user plane CIoT optimization.

<FIG> shows a schematic diagram of an MO-EDT procedure with anchor relocation for the user plane CIoT optimization according to an embodiment of the present disclosure.

In detail, upon connection resumption request for mobile originated data from upper layers, the UE initiates the MO-EDT procedure and selects a random access preamble configured for the EDT (step <NUM>).

In step <NUM>, the UE sends an RRC Connection Resume Request message to the gNB, wherein the RRC Connection Resume Request comprises an I-RNTI of the UE, a resume cause and an authentication token. The UE resumes all SRBs and DRBs, derives new security keys using an NCC provided in an RRC Connection Release message of the previous connection and re-establishes the AS security. The UL data are ciphered (e.g. encrypted) and transmitted on the DTCH multiplexed with the RRC Connection Resume Request message on the CCCH.

In step <NUM>, 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 <NUM> system (5GS)) Retrieve UE Context procedure. In this embodiment, the new gNB transmits a Retrieve UE Context Request message to the old gNB.

In step <NUM>, the old gNB responds with the UE context associated with the I-RNTI (e.g. for the 5GS) in a Retrieve UE Context Response message.

In step <NUM>, the new gNB initiates a(n) (NG AP) path switch procedure to establish an NG UE associated signaling connection to a serving AMF and to request the AMF to resume the UE context.

In step <NUM>, the AMF requests the SMF to resume the PDU session and the SMF requests the UPF to create the tunnel information for the UE and update the DL path.

In step <NUM>, the AMF transmits a(n) (NG AP) path switch request acknowledgement (ACK) to the new gNB.

In step <NUM>, after the (NG-AP) path switch procedure completes, the new gNB triggers a release of the UE context at the old gNB by means of a(n) (Xn-AP) UE Context Release procedure. In this embodiment, the new gNB transmits a UE Context Release message to the old gNB.

In step <NUM>, the UL data is delivered to the UPF from the new gNB.

Steps <NUM> to <NUM> may be referred to steps <NUM> to <NUM>.

In the following, UL/DL data transmissions (e.g., for SDT or EDT) with/without anchor relocation are illustrated with focuses on security Key.

<FIG> shows a schematic diagram of a procedure associated with security key transfer with and without anchor relocation according to an embodiment of the present disclosure. In <FIG>, the UE is in an inactive state (e.g. RRC INACTIVE mode) and stores a key K1 and an NCC-<NUM> which are acquired from a previous connection (e.g. with the last serving gNB or anchor gNB) via receiving an RRC Connection Release message.

In step <NUM>, the UE sends an RRC Connection Resume Request message to a receiving gNB (e.g. new gNB), wherein this message is ciphered by K1. Optionally, the UE also transmits UL data ciphered by a key K2, wherein K2 is derived based on K1 and NCC-<NUM>.

In step <NUM>, the receiving gNB sends a Retrieve UE Context Request message to the anchor gNB (e.g. the last serving gNB or old gNB). In addition, if receiving the UL data ciphered by the K2 from the UE, the receiving gNB stores (e.g. buffers) the received UL data.

In step <NUM>, no UL/DL data is transmitted through the anchor gNB. That is, K2 is not used by the anchor gNB.

In step <NUM>, the anchor gNB sends a Retrieve UE Context Response message to the receiving gNB, wherein the Retrieve UE Context Response message includes K2 and an NCC-<NUM>. In an embodiment, the K2 is set as in an information element (IE) "Key NG-RAN Star" defined in TS <NUM>.

According to 3GPP TS <NUM>, IEs "Key NG-RAN Star" and "Next Hop Chaining Count" are included in "UE Context Information - Retrieve UE Context Response" IE contained in the Retrieve UE Context Response message.

In addition, an IE "AS Security Information" is used to generate the key material to be used for AS security with the UE and comprises the IEs "Key NG-RAN Star" and "Next Hop Chaining Count".

In step <NUM> (optional), if loss of DL user data buffered in the anchor gNB shall be prevented, the receiving gNB provides forwarding addresses to the anchor gNB.

In step <NUM>, the receiving gNB established the UE context (e.g. stores the K2 and the NCC-<NUM>).

In step <NUM>, the receiving gNB perform the path switch procedure with the AMF.

In steps <NUM> and <NUM>, the UE sends UL data ciphered (e.g. encrypted) by the K2 and receives DL data by deciphering (e.g. decrypting) the received DL data by the K2. That is, the receiving gNB ciphers and deciphers the UL and DL data, respectively, by the K2.

In step <NUM>, the receiving gNB may determine send the UE to one of connected state (steps <NUM> and <NUM> are subsequently performed), inactive state or an idle state (step <NUM> is subsequently performed).

In step <NUM>, the receiving gNB sends an RRC Resume message to UE, this message is ciphered by the K2. In step <NUM>, the UE transmits an RRC Resume complete message to the receiving gNB. After steps <NUM> and <NUM>, the UE is transferred to the connected state.

In step <NUM>, the receiving gNB sends an RRC Connection Release message to the UE, this message is ciphered by the K2 and includes an NCC-<NUM>.

In an embodiment, the NCC-<NUM>, NCC-<NUM> and NCC-<NUM> may be the same or different values.

In an embodiment, the receiving gNB becomes the anchor gNB for this UE after the anchor relocation. Thus, both the UE and the receiving gNB store the same key and the same NCC (i.e., K2 and NCC-<NUM>) for further usage (e.g. the UE may send another RRC Resume request message to the receiving gNB).

In <FIG>, the security key (i.e. K2 stored within both UE and anchor gNB) is not used by the anchor gNB. Thus, the K2 can be transferred to the receiving gNB at the step <NUM> and the receiving gNB can use the K2 to cipher the UL/DL data at the steps <NUM> and <NUM>.

However, if the K2 is used by the anchor gNB at step <NUM>, the anchor gNB cannot at step <NUM> send the K2 included in IE "Key NG-RAN Star" because different RAN nodes (e.g., anchor gNB and receiving gNB) cannot use the same security Key. In the present disclosure, a method is proposed to transfer a new key (e.g. K3) from the anchor node to the receiving node and the UE for the future usage.

<FIG> shows a schematic diagram of procedure associated with a security key transfer according to an embodiment of the present disclosure. In <FIG>, the UE is in the inactive state (e.g. RRC INACTIVE mode) and stores a key K1 and an NCC-<NUM> which are acquired from a previous connection (e.g. with the last serving gNB or anchor gNB) via receiving an RRC Connection Release message.

In step <NUM>, the UE sends an RRC Connection Resume Request message to a receiving gNB (e.g. new gNB), wherein this message is ciphered by the K1. Optionally, the UE also transmits UL data ciphered by a key K2, wherein K2 is derived based on K1 and NCC-<NUM>.

In step <NUM>, the anchor gNB determines that the K2 is used.

In step <NUM>, the anchor gNB transmits Retrieve UE Context response message comprising a new key K3 and an NCC-<NUM>, wherein the NCC-<NUM> may be different from or the same with the NCC-<NUM>. In addition, the K2 may be further included in this Retrieve UE Context response message. In an embodiment, the K3 may be determine based on the K2. For example, the K3 may be derived based on K2 and one of the NCC-<NUM>, NCC-<NUM>.

In step <NUM>, the receiving gNB established the UE context (e.g. stores the K3 and the NCC-<NUM>).

In step <NUM>, the receiving gNB may determine send the UE to one of connected state (steps 609a, 609b or steps 609b to 612b are subsequently performed), inactive state or an idle state (step <NUM> or steps 609b, 610b, <NUM> are subsequently performed).

Specifically, if receiving the K2 at step <NUM>, the receiving gNB itself can use the K2 to encrypt the RRC Resume message or the RRC Release message, which comprises the K3 and NCC-<NUM>. Under such conditions, when determining sending the UE to the connected state, the receiving gNB transmits the RRC Resume message encrypted by the K2 to the UE and receives the RRC Resume complete message from the UE (steps 609a and 610a). Or, when determining sending the UE to the inactive state or the idle state, the receiving gNB transmits the RRC Release message encrypted by the K2 to the UE (step <NUM>).

In an embodiment of the K2 not included in the Retrieve UE Context Response message at step <NUM>, the receiving gNB itself cannot encrypt the RRC Resume message or the RRC Release message by the K2. Thus, when determining sending the UE to the connected state, the receiving gNB transmits a relocation request to the anchor gNB, wherein the relocation request comprises the RRC Resume message including the K3 and NCC-<NUM> (step 609b). The anchor gNB encrypts the RRC Resume message by the K2 and transmits the encrypted RRC Resume message to the receiving gNB (step 610b). Next, the receiving gNB transmits the encrypted RRC Resume message comprising the K3 and NCC-<NUM> to the UE and receives the RRC Resume complete message from the UE. When determining sending the UE to the inactive state or the idle state, the receiving gNB transmits the relocation request to the anchor gNB, wherein this relocation request comprises the RRC Release message including the K3 and NCC-<NUM> (step 609b). The anchor gNB encrypts the RRC Release message by the K2 and transmits the encrypted RRC Resume message to the receiving gNB (step 610b). The receiving gNB therefore can transmit the encrypted RRC Release message comprising the K3 and NCC-<NUM> to the UE (step <NUM>).

In the following, actions of the UE, the receiving gNB and the anchor gNB in <FIG> are separately illustrated.

According to an embodiment, actions of the anchor gNB in the procedure shown <FIG> comprises:.

In an embodiment, the messages M1 and M2 are XnAP signaling between the receiving gNB and the anchor gNB. For instance, the message M1 is named Relocation request message and the message M2 is named Relocation response message.

According to an embodiment, actions of the receiving gNB in the procedure shown in <FIG> comprises:.

According to an embodiment, actions of the UE in the procedure shown in <FIG> comprises:.

Both the UE and the receiving gNB store the K3 and NCC.

The receiving gNB sends the RRC resume/RRC Release message including the K3 and NCC to the UE through two methods:.

<FIG> shows a flowchart of a process according to an embodiment of the present disclosure. The process shown in <FIG> may be used in an anchor node (e.g. anchor gNB) and comprises the following steps:.

In <FIG>, the anchor node receives context request message associated with a wireless terminal, e.g., 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 chaining count is used by the anchor node. Under such conditions, the anchor node transmits a context response message comprising a third key which is different from the second key and a second NCC to the serving node. Note that, the second NCC may be different from or the same with the first NCC.

In an embodiment, the third key is an intermediate key used between the of the wireless terminal and the serving node. For example, the third key may be used for UL/DL data transmissions between the serving node or the wireless terminal.

In an embodiment, the third key is determined based on the second key.

In an embodiment, the first key and the first next hop chaining count are transmitted to the wireless terminal via an RRC connection release message.

In an embodiment, the context response message further comprises the second key.

In an embodiment, the anchor node receives a first message comprising an RRC message associated with the mobile terminal from the serving node and transmits a second message comprising the radio resource control message encrypted by the second key the serving node. In this embodiment, this RRC message may be an RRC Resume message or an RRC Release message. In addition, the first message and the second message are XnAP signaling.

<FIG> shows a flowchart of a process according to an embodiment of the present disclosure. The process shown in <FIG> may be used in a serving node (e.g. serving gNB) and comprises the following steps:.

In <FIG>, the serving node receives a resume request message from a wireless terminal (e.g. in the inactive state), wherein the resume request message is encrypted by a first key. The first key and a first NCC are transmitted to the wireless terminal in a previous connection between an 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 context request message associated with the wireless terminal to an 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 comprising a third key and a second NCC, wherein the third key is different from a second key determined based on the first key and the first NCC. The serving node transmits an RRC message which is encrypted by the second key and comprises the third key and the second next hop chaining count to the wireless terminal.

In an embodiment, the second NCC is the same with or different from the first NCC.

In an embodiment, the third key is an intermediate key used between the of the wireless terminal and the serving node.

In an embodiment, the serving node receives, from the wireless terminal, at least one signaling message of the wireless terminal and/or uplink data no earlier than (when or after) receiving the resume request message and/or transmitting the radio resource control message. Note that, the at least one signaling message of the wireless terminal and the uplink data are encrypted by the second key.

In an embodiment, the first key and the first NCC are transmitted via an RRC connection Release message in the previous connection.

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

In an embodiment, the serving node transmits a first message comprising the radio resource control message to the anchor node and receives a second message comprising the radio resource control message encrypted by the second key from the anchor node.

In an embodiment, the first message and the second message are XnAP signaling.

<FIG> shows a flowchart of a process according to an embodiment of the present disclosure. The process shown in <FIG> may be used in a wireless terminal (e.g. UE) and comprises the following steps:.

In <FIG>, the wireless terminal transmits a resume request message which is encrypted by a first key to the serving node, wherein the first key and a 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, wherein 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 comprises a third key which is different from the second key and a second NCC which may be different from or the same with the first NCC.

In an embodiment, the third key is an intermediate key used between the of the wireless terminal and the serving node. For example, the wireless terminal may communicate with the serving node (e.g. UL/DL data transmissions) by using the third key after receiving the RRC message.

In an embodiment, the wireless terminal transmits, to the serving node, at least one signaling message of the wireless terminal and/or uplink data no earlier than (when or after) receiving the resume request message and/or transmitting the radio resource control message. Note that, the at least one signaling message of the wireless terminal and the uplink data are encrypted by the second key.

In an embodiment, the first key and the first NCC are transmitted via an RRC connection Release message.

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

<FIG> relates to a schematic diagram of a wireless terminal <NUM> according to an embodiment of the present disclosure. The wireless terminal <NUM> may be a user equipment (UE), a mobile phone, a laptop, a tablet computer, an electronic book or a portable computer system and is not limited herein. The wireless terminal <NUM> may include a processor <NUM> such as a microprocessor or Application Specific Integrated Circuit (ASIC), a storage unit <NUM> and a communication unit <NUM>. The storage unit <NUM> may be any data storage device that stores a program code <NUM>, which is accessed and executed by the processor <NUM>. Embodiments of the storage unit <NUM> include but are not limited to a subscriber identity module (SIM), read-only memory (ROM), flash memory, random-access memory (RAM), hard-disk, and optical data storage device. The communication unit <NUM> may a transceiver and is used to transmit and receive signals (e.g. messages or packets) according to processing results of the processor <NUM>. In an embodiment, the communication unit <NUM> transmits and receives the signals via at least one antenna <NUM> shown in <FIG>.

In an embodiment, the storage unit <NUM> and the program code <NUM> may be omitted and the processor <NUM> may include a storage unit with stored program code.

The processor <NUM> may implement any one of the steps in exemplified embodiments on the wireless terminal <NUM>, e.g., by executing the program code <NUM>.

The communication unit <NUM> may be a transceiver. The communication unit <NUM> may as an alternative or in addition be combining a transmitting unit and a receiving unit configured to transmit and to receive, respectively, signals to and from a wireless network node (e.g. a base station).

<FIG> relates to a schematic diagram of a wireless network node <NUM> according to an embodiment of the present disclosure. The wireless network node <NUM> may be a satellite, a base station (BS), a network entity, a Mobility Management Entity (MME), Serving Gateway (S-GW), 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 herein. In addition, the wireless network node <NUM> may comprise (perform) at least one network function such as an access and mobility management function (AMF), a session management function (SMF), a user place function (UPF), a policy control function (PCF), an application function (AF), etc. The wireless network node <NUM> may include a processor <NUM> such as a microprocessor or ASIC, a storage unit <NUM> and a communication unit <NUM>. The storage unit <NUM> may be any data storage device that stores a program code <NUM>, which is accessed and executed by the processor <NUM>. Examples of the storage unit <NUM> include but are not limited to a SIM, ROM, flash memory, RAM, hard-disk, and optical data storage device. The communication unit <NUM> may be a transceiver and is used to transmit and receive signals (e.g. messages or packets) according to processing results of the processor <NUM>. In an example, the communication unit <NUM> transmits and receives the signals via at least one antenna <NUM> shown in <FIG>.

In an embodiment, the storage unit <NUM> and the program code <NUM> may be omitted. The processor <NUM> may include a storage unit with stored program code.

The processor <NUM> may implement any steps described in exemplified embodiments on the wireless network node <NUM>, e.g., via executing the program code <NUM>.

The communication unit <NUM> may be a transceiver. The communication unit <NUM> may as an alternative or in addition be combining a transmitting unit and a receiving unit configured to transmit and to receive, respectively, signals to and from a wireless terminal (e.g. a user equipment).

Thus, the breadth and scope of the present disclosure should not be limited by any one of the above-described exemplary embodiments.

Additionally, a person having ordinary skill in the art would understand that information and signals can be represented using any one of a variety of different technologies and techniques.

A skilled person would further appreciate that any one of the various illustrative logical blocks, units, processors, means, circuits, methods and functions described in connection with the aspects disclosed herein can be implemented by electronic hardware (e.g., a digital implementation, an analog implementation, or a combination of the two), firmware, various forms of program or design code incorporating instructions (which can be referred to herein, for convenience, as "software" or a "software unit"), or any combination of these techniques.

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. In accordance with various embodiments, a processor, device, component, circuit, structure, machine, unit, etc. can be configured to perform one or more of the functions described herein. The term "configured to" or "configured for" as used herein with respect to a specified operation or function refers 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.

Furthermore, a skilled person would understand that various illustrative logical blocks, units, devices, components and circuits described herein can be implemented within or performed by an integrated circuit (IC) that can 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 can further include antennas and/or transceivers to communicate with various components within the network or within the device.

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 purpose of discussion, the various units are described as discrete units; however, as would be apparent to one of ordinary skill in the art, two or more units may be combined to form a single unit that performs the associated functions according embodiments of the present disclosure.

Claim 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 chaining 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 chaining count is used by the anchor node, and
transmitting, to the serving node, a context response message comprising a third key which is different from the second key and a second next hop chaining count.