WO2019161545A1

WO2019161545A1 - Integrity verification method, network device, terminal device and computer storage medium

Info

Publication number: WO2019161545A1
Application number: PCT/CN2018/077057
Authority: WO
Inventors: 唐海
Original assignee: Oppo广东移动通信有限公司
Priority date: 2018-02-23
Filing date: 2018-02-23
Publication date: 2019-08-29
Also published as: CN110710241A

Abstract

Disclosed are an integrity verification method, a network device, a terminal device, and a computer storage medium. The method comprises: receiving an MSG3 message that comprises a connection resume request (RRC) and that is sent by a terminal device; acquiring a context identifier of the terminal device and/or an identifier of a target network device from within the MSG3 and/or by means of decoding a PUSCH in which the MSG3 is located; and acquiring context of the terminal device from within the target network device.

Description

Integrity verification method, network device, terminal device, and computer storage medium

Technical field

The present invention relates to the field of information processing technologies, and in particular, to an integrity verification method, a network device, a terminal device, and a computer storage medium.

Background technique

In the 5G network environment, in order to reduce air interface signaling and quickly recover wireless connections, and quickly recover data services, a new RRC state, that is, an RRC_INACTIVE state, is defined. When the terminal device is in the RRC_INACTIVE state, the network side configures the paging area of the RAN by using dedicated signaling to the UE, and the RAN paging area may be one cell or multiple cells. When the UE moves within the area, the network side is not notified, and the mobility behavior under the idle, that is, the cell selection reselection principle is followed. When the UE moves out of the paging area configured by the RAN, the UE is triggered to resume the RRC connection and re-acquire the paging area configured by the RAN. When the UE has downlink data, the gNB that keeps the connection between the RAN and the CN for the UE triggers all the cells in the RAN paging area to send a paging message to the UE, so that the UE in the INACTIVCE state can resume the RRC connection and perform data reception.

In the MSG3 of the random access procedure, that is, the RRC ConnectionResumeRequest message carries the AS context id information of the UE and the security information Short MAC-I and the cause value, and the possibility of considering the security attack exists, the fake base station pretends to send the MSG3 message. , or other messages for the UE, the risk of the network being attacked, and the message carrying the UE identification information and the cause value information needs to be secured.

Summary of the invention

To solve the above technical problem, an embodiment of the present invention provides an integrity verification method, a network device, a terminal device, and a computer storage medium.

An embodiment of the present invention provides an integrity protection method, which is applied to a first network device, where the method includes:

Receiving, by the terminal device, an MSG3 message including an RRC connection recovery request;

Obtaining a terminal device context identifier, and/or a target network device identifier from the MSG3 and/or by decoding a PUSCH where the MSG3 is located;

Obtaining the terminal device context from the target network device.

The embodiment of the invention provides an integrity protection method, which is applied to a terminal device, and the method includes:

Sending, to the network side, an MSG3 message including an RRC connection recovery request, where the RRC connection recovery request carries a terminal device context identifier.

An embodiment of the present invention provides a first network device, where the method includes:

The first communication unit receives an MSG3 message that is sent by the terminal device and includes an RRC connection recovery request; and acquires the terminal device context from the target network device;

The first processing unit acquires the terminal device context identifier and/or the target network device identifier from the MSG3 and/or by decoding the PUSCH where the MSG3 is located.

The embodiment of the invention provides a terminal device, where the terminal device includes:

The second communication unit sends an MSG3 message including an RRC connection recovery request to the network side, where the RRC connection recovery request carries the terminal device context identifier.

A first network device provided by an embodiment of the present invention includes: a processor and a memory for storing a computer program capable of running on a processor,

Wherein the processor is configured to perform the steps of the foregoing method when the computer program is run.

A terminal device provided by an embodiment of the present invention includes: a processor and a memory for storing a computer program capable of running on a processor,

A computer storage medium is provided by the embodiment of the present invention. The computer storage medium stores computer executable instructions, and the foregoing method steps are implemented when the computer executable instructions are executed.

The technical solution of the embodiment of the present invention can transmit the terminal device context identifier to the network side by using the MAC CE method or carry the terminal device context identifier by using the scrambling PUSCH, so that the network device can identify the target base station corresponding to the terminal device and obtain the target base station from the target base station. Look for context. Therefore, when the current cell managed by the network device accessed by the terminal device does not have the terminal device context, the context can be obtained from the target base station according to the terminal device context identifier, thereby improving the reliability of the terminal device accessing the network.

DRAWINGS

1 is a schematic flowchart of an integrity verification method according to an embodiment of the present invention;

2 is a schematic diagram of a network structure;

3 is a schematic structural diagram of a first network device according to an embodiment of the present invention;

4 is a schematic structural diagram of a terminal device according to an embodiment of the present invention;

FIG. 5 is a schematic diagram of a hardware architecture according to an embodiment of the present invention.

Detailed ways

The embodiments of the present invention are described in detail below with reference to the accompanying drawings.

Embodiment 1

An embodiment of the present invention provides an integrity protection method, which is applied to a first network device. As shown in FIG. 1, the method includes:

Step 101: Receive an MSG3 message that is sent by the terminal device and includes an RRC connection recovery request.

Step 102: Obtain a terminal device context identifier, and/or a target network device identifier from the MSG3 and/or by decoding a PUSCH where the MSG3 is located.

Step 103: Acquire the terminal device context from the target network device.

The first network device in this embodiment can be understood as the current serving base station of the terminal device. For example, as shown in FIG. 2, the terminal device is also a user equipment (UE) in the figure, and the current UE is in the serving base station, that is, the serving gNB. Within the coverage, the target network device can be understood as an anchor gNB that holds the terminal device context.

In the foregoing step 103, the acquiring the terminal device context from the target network device, the packet may specifically include the following two implementation manners:

method one,

Transmitting TB data including the terminal device context identifier to the target network device;

When the target network device determines that the integrity check is successful, acquiring the terminal device context from the target network device, and restoring the terminal device context;

And when the target network device determines that the integrity check fails, obtaining the rejecting the terminal device indication from the target network device, and rejecting the terminal device to restore the context request.

Specifically, the first network device may forward the TB data to the target base station (that is, the target network device) when the terminal device context needs to be acquired; the target base station decodes the TB data, obtains the UE AS context id, and then finds The context of the UE, and recovering SRB1 according to the AS context of the UE, and performing decoding and integrity verification, and/or decryption;

Correspondingly, if the integrity verification of the target network device (ie, the target base station) is successful, the context of the UE is sent to the serving base station. The serving base station recovers the context of the UE; if the integrity protection verification fails, the serving base station is notified to reject the UE.

Method 2,

Acquiring, according to the terminal device context identifier, the terminal device context from the target network device; performing decoding and integrity check on the TB data including the terminal device context identifier; when the integrity check succeeds Determining to restore the terminal device context; when the integrity check fails, determining to reject the terminal device to resume the context request.

Specifically, the first network device (that is, the serving base station) requests the target base station for the UE context by using the UE AS context id; the first network device (that is, the serving base station) restores the context of the UE. The TB data is then decoded and decoded and integrity verified, and/or decrypted.

Correspondingly, the first network device (that is, the serving base station) restores the context of the UE if the integrity verification succeeds; if the integrity protection verification fails, the UE is rejected.

On the basis of the foregoing solution, this embodiment also describes how to obtain the terminal device context identifier in the following scenarios:

Scenario 1. The UE initiates an RRC connection recovery. The UE uses the key of the original AS context for integrity protection and decides to send it to the network side on SRB1. Correspondingly, specific operations on the network side may include:

The receiving, by the receiving terminal device, the MSG3 message that includes the RRC connection recovery request, including:

The RRC connection recovery request is handed over to the MAC layer of SRB0; decoding is performed by the MAC layer to determine that the TB data is data of SRB1.

Obtaining the terminal device context identifier and/or the target network device identifier from the MSG3 and/or by decoding the PUSCH where the MSG3 is located, including:

Receiving an RRC connection recovery request sent by the terminal device in the MSG3, acquiring a MAC CE carrying the terminal device context identifier from the MSG3, acquiring the terminal device context identifier by decoding the MAC CE, and determining the location The identifier of the target network device.

Further, the UE first performs a contention random access procedure, and sends an RRC connection recovery request message to the network side in the MSG3, and adds a MAC CE of the UE AS context id to the MSG3. At this time, the PUSCH is scrambled by using the temporary C-RNTI allocated in the RAR in the MSG2.

On the basis of the foregoing processing on the terminal device side, the network side may also perform a process of allocating a temporary C-RNTI to the terminal device in a random access response RAR in the MSG2. Correspondingly, the MSG3 message that is sent by the receiving terminal device and includes the RRC connection recovery request further includes: performing descrambling on the RRC connection recovery request sent by the terminal device in the MSG3 on the PUSCH based on the temporary C-RNTI.

That is, the network side descrambles the data on the PUSCH through the temporary C-RNTI, and then delivers the UE to the MAC layer of the SRB0. The MAC decoding finds that the TB data is the data on the SRB1, and decodes the UE AS context id. And find the target network device according to the UE AS context id.

Scene 2

Broadcasting a preamble sequence to the terminal device by a system broadcast, or a protocol specifying a unique preamble sequence of the entire network;

The preamble sequence is used by the MSG3 to send an SRB1 message.

That is to say, the network side allocates a dedicated preamble to the terminal device (that is, the UE), and the preamble may be unique to the entire network, or may be unique within the cell, and broadcast the reserved preamble in the system broadcast. The preamble is used to indicate a UE initiated RRC connection recovery request, sent using SRB1, and/or employ integrity protection, and/or employ encryption or the like.

If the UE resumes the RRC connection and sends with SRB1, and/or employs integrity protection, and/or employs encryption. Then the UE sends the dedicated preamble.

After the UE receives the dedicated preamble, the network side responds to the RAR. Specifically, the network side sends a random access response to the terminal device, and at least the uplink scheduling resource and the temporary C-RNTI are carried in the random access response.

The UE sends an RRC connection recovery request according to the uplink scheduling resource in the RAR; the network side receives the MSG3 message that is sent by the terminal device through the PUSCH and includes the RRC connection recovery request.

Further, the PUSCH that the terminal device (that is, the UE) sends the message may be scrambled by using the gNB id part of the UE as context ID, or the C-RNTI scrambling in the RAR, or the UE context id scrambling, and the like.

Correspondingly, when the PUSCH is scrambled based on the base station identification part of the terminal device context identifier, the identifier of the target network device is obtained by the blind solution, and the terminal device context identifier that is carried in the MSG3 decoding is obtained.

When the PUSCH is scrambled based on the terminal context identifier, obtaining the terminal device context identifier by using a blind solution, and determining an identifier of the target base station (target network device);

That is, the gNB id part of the UE as context ID is scrambled or the UE as context ID is scrambled, and the network side obtains the identity of the target base station by blind solution.

When the PUSCH is scrambled based on the temporary C-RNTI, the terminal device context identifier that is carried in the MSG3 decoding is obtained, and the identifier of the target base station is determined.

That is, the terminal device uses the C-RNTI in the RAR to scramble, and the MSG3 carries the UE context id MAC CE. Find the target base station.

It can be seen that, by using the foregoing solution, the terminal device context identifier can be sent to the network side by using the MAC CE method or the terminal device context identifier can be carried by the scrambling PUSCH, so that the network device can identify the target base station corresponding to the terminal device and search for the target base station. Context. Therefore, when the current cell managed by the network device accessed by the terminal device does not have the terminal device context, the context can be obtained from the target base station according to the terminal device context identifier, which improves the reliability of the terminal device accessing the network and the system processing efficiency.

Embodiment 2

This embodiment provides the following two scenarios for sending an RRC connection recovery request:

scene 1,

Sending, by the network side, an MSG3 message including an RRC connection recovery request, including:

Restore the UE AS context and SRB1;

The RRC Connection Recovery Request message is integrity protected and/or encrypted using a key and security algorithm in the UE AS context;

An RRC connection recovery request is sent in the MSG3, and the MAC CE carrying the terminal device context identifier is obtained in the MSG3.

The terminal device first performs a contention random access procedure, and sends an RRC connection recovery request message to the network side in the MSG3, and adds a MAC CE of the UE AS context id to the MSG3. At this time, the temporary C-RNTI allocated by the network side is obtained from the random access response RAR in the MSG2. Specifically, the RRC connection recovery request sent in the MSG3 on the PUSCH is scrambled based on the temporary C-RNTI. That is, the terminal device scrambles the PUSCH by using the temporary C-RNTI allocated in the RAR in the MSG2.

On the basis of the foregoing processing on the terminal device side, the network side may also perform processing of allocating a temporary C-RNTI to the terminal device in a random access response RAR in the MSG2. Correspondingly, the MSG3 message that is sent by the receiving terminal device and includes the RRC connection recovery request further includes: performing descrambling on the RRC connection recovery request sent by the terminal device in the MSG3 on the PUSCH based on the temporary C-RNTI.

Scene 2

The preamble sequence allocated by the network side is obtained by system broadcast, or the protocol specifies a whole network unique preamble sequence; wherein the preamble sequence is used by the MSG3 to send the SRB1 message.

After receiving the dedicated preamble, the UE receives the random access response sent by the network side, acquires at least the uplink scheduling resource and the temporary C-RNTI in the random access response, and sends an RRC connection recovery based on the PUSCH corresponding to the uplink scheduling resource. request. Specifically, the network side sends a random access response to the terminal device, and at least the uplink scheduling resource and the temporary C-RNTI are carried in the random access response.

The base station identification part based on the terminal device context identifier, or the PUSCH is scrambled based on the terminal context identifier or based on the C-RNTI; correspondingly, the network side receiving terminal equipment sends the RRC connection recovery request by using the PUSCH MSG3 message.

Embodiment 3

An embodiment of the present invention provides a first network device, as shown in FIG. 3, including:

The first communication unit 31 receives an MSG3 message that is sent by the terminal device and includes an RRC connection recovery request, and acquires the terminal device context from the target network device.

The first processing unit 32 obtains the terminal device context identifier and/or the target network device identifier from the MSG3 and/or by decoding the PUSCH where the MSG3 is located.

The obtaining the terminal device context from the target network device, the packet may specifically include the following two implementation manners:

method one,

The first communication unit 31 sends the TB data including the terminal device context identifier to the target network device;

Method 2,

The first communication unit 31 acquires the terminal device context from the target network device based on the terminal device context identifier; the first processing unit 32 decodes and completes the TB data including the terminal device context identifier. Verifying that when the integrity check is successful, determining to restore the terminal device context; when the integrity check fails, determining to reject the terminal device to resume the context request.

The first communication unit 31 hands the RRC connection recovery request to the MAC layer of SRB0, and performs decoding by the MAC layer to determine that the TB data is data of SRB1.

The first processing unit receives an RRC connection recovery request sent by the terminal device in the MSG3, acquires a MAC CE carrying the terminal device context identifier from the MSG3, and acquires the terminal by decoding the MAC CE. A device context identifier and an identification of the target network device.

On the basis of the foregoing processing on the terminal device side, the network side may also perform the following processing: the first communication unit 31 allocates a temporary C-RNTI to the terminal device in the random access response RAR in the MSG2. Correspondingly, the MSG3 message that is sent by the receiving terminal device and includes the RRC connection recovery request further includes: a first processing unit 32, based on the temporary C-RNTI, the RRC connection recovery request sent by the terminal device in the MSG3 on the PUSCH Perform descrambling.

Scene 2

The first communication unit 31 broadcasts a preamble sequence to the terminal device by using a system broadcast, or the protocol specifies a unique preamble sequence of the entire network;

The preamble sequence is used by the MSG3 to send an SRB1 message.

After the UE receives the dedicated preamble, the network side responds to the RAR. Specifically, the first communication unit 31 sends a random access response to the terminal device, and carries at least the uplink scheduling resource and the temporary C- in the random access response. RNTI.

Correspondingly, the first processing unit, when the PUSCH is scrambled based on the base station identification part of the terminal device context identifier, obtains the identifier of the target network device by using a blind solution, and the method is obtained according to the MSG3 decoding. Terminal device context identifier;

Embodiment 4

An embodiment of the present invention provides a terminal device, as shown in FIG. 4, including:

The second communication unit 41 sends an MSG3 message including an RRC connection recovery request to the network side, where the RRC connection recovery request carries the terminal device context identifier.

scene 1,

The terminal device further includes:

The second processing unit 42 restores the UE AS context and SRB1; performs integrity protection and/or encryption on the RRC connection recovery request message by using a key and a security algorithm in the UE AS context;

The second communication unit 41 sends an RRC connection recovery request in the MSG3, and acquires a MAC CE carrying the terminal device context identifier in the MSG3.

Scene 2

The second communication unit 41 acquires a preamble sequence allocated by the network side through system broadcast, or specifies a whole network unique preamble sequence by using a protocol; wherein the preamble sequence is used by the MSG3 to send an SRB1 message.

After receiving the dedicated preamble, the second communication unit 41 receives a random access response sent by the network side, and acquires at least an uplink scheduling resource and a temporary C-RNTI in the random access response; The corresponding PUSCH transmits an RRC connection recovery request. Specifically, the network side sends a random access response to the terminal device, and at least the uplink scheduling resource and the temporary C-RNTI are carried in the random access response.

a second processing unit, based on the base station identification part of the terminal device context identifier, or the PUSCH is scrambled based on the terminal context identifier or based on the C-RNTI; correspondingly, the network side receiving terminal device sends the content by using the PUSCH The RRC connection recovers the requested MSG3 message.

The embodiment of the present invention further provides a hardware component architecture of a network device or a terminal device. As shown in FIG. 5, the system includes at least one processor 51, a memory 52, and at least one network interface 53. The various components are coupled together by a bus system 54. It will be appreciated that bus system 54 is used to implement connection communication between these components. The bus system 54 includes, in addition to the data bus, a power bus, a control bus, and a status signal bus. However, for clarity of description, various buses are labeled as bus system 54 in FIG.

It is to be understood that the memory 52 in the embodiments of the present invention may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memory.

In some embodiments, memory 52 stores elements, executable modules or data structures, or a subset thereof, or their extension set:

Operating system 521 and application 522.

The processor 51 is configured to be able to process the method steps of the first embodiment or the second embodiment, and details are not described herein.

A computer storage medium is provided by the embodiment of the present invention. The computer storage medium stores computer executable instructions. When the computer executable instructions are executed, the method steps of the first embodiment or the second embodiment are implemented.

Embodiments of the Invention The above apparatus may be stored in a computer readable storage medium if it is implemented in the form of a software function module and sold or used as a standalone product. Based on such understanding, the technical solution of the embodiments of the present invention may be embodied in the form of a software product in essence or in the form of a software product stored in a storage medium, including a plurality of instructions. A computer device (which may be a personal computer, server, or network device, etc.) is caused to perform all or part of the methods described in various embodiments of the present invention. The foregoing storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read only memory (ROM), a magnetic disk, or an optical disk. Thus, embodiments of the invention are not limited to any specific combination of hardware and software.

Correspondingly, an embodiment of the present invention further provides a computer storage medium, wherein a computer program is configured, and the computer program is configured to execute a data scheduling method according to an embodiment of the present invention.

While the preferred embodiments of the present invention have been disclosed for purposes of illustration, those skilled in the art will recognize that various modifications, additions and substitutions are possible, and the scope of the invention should not be limited to the embodiments described above.

Claims

An integrity protection method is applied to a first network device, and the method includes:

Receiving, by the terminal device, an MSG3 message including an RRC connection recovery request;

Obtaining a terminal device context identifier, and/or a target network device identifier from the MSG3 and/or by decoding a PUSCH where the MSG3 is located;

Obtaining the terminal device context from the target network device.
The method of claim 1, wherein the obtaining the terminal device context from the target network device comprises:

Transmitting TB data including the terminal device context identifier to the target network device;

And when the target network device determines that the integrity check is successful, acquiring the terminal device context from the target network device, and restoring the terminal device context.
The method of claim 2, wherein the method further comprises:

And when the target network device determines that the integrity check fails, obtaining the rejecting the terminal device indication from the target network device, and rejecting the terminal device to restore the context request.
The method of claim 1, wherein the obtaining the terminal device context from the target network device comprises:

Obtaining the terminal device context from the target network device based on the terminal device context identifier;

Decoding and integrity check for TB data including the terminal device context identifier;

When the integrity check is successful, it is determined to restore the terminal device context.
The method of claim 4 wherein the method further comprises:

When the integrity check fails, it is determined that the terminal device is denied to restore the context request.
The method according to any one of claims 1-5, wherein the receiving, by the receiving terminal device, the MSG3 message including the RRC connection recovery request includes:

Handing the RRC connection recovery request to the MAC layer of SRB0;

Decoding is performed by the MAC layer to determine that the TB data is the data of SRB1.
The method according to claim 6, wherein the obtaining the terminal device context identifier and/or the target network device identifier from the MSG3 and/or by decoding the PUSCH where the MSG3 is located includes:

Receiving an RRC connection recovery request sent by the terminal device in the MSG3, and acquiring, from the MSG3, a MAC CE carrying the terminal device context identifier;

Obtaining the terminal device context identifier by decoding the MAC CE, and determining an identifier of the target network device.
The method of claim 7 wherein the method further comprises:

A temporary C-RNTI is allocated to the terminal device in a random access response RAR in MSG2.
The method of claim 8, wherein the receiving, by the receiving terminal device, the MSG3 message that includes the RRC connection recovery request further comprises:

The RRC connection recovery request sent by the terminal device in the MSG3 on the PUSCH is descrambled based on the temporary C-RNTI.
The method of any of claims 1-5, wherein the method further comprises:

Broadcasting a preamble sequence to the terminal device by a system broadcast, or a protocol specifying a unique preamble sequence of the entire network;

The preamble sequence is used by the MSG3 to send an SRB1 message.
The method of claim 10, wherein the method further comprises:

Sending a random access response to the terminal device, and carrying at least an uplink scheduling resource and a temporary C-RNTI in the random access response.
The method of claim 10, wherein the receiving, by the receiving terminal device, the MSG3 message that includes the RRC connection recovery request comprises:

Receiving an MSG3 message that is sent by the terminal device through the PUSCH and includes an RRC connection recovery request.
The method of claim 12 wherein said base method further comprises:

When the PUSCH is scrambled based on the base station identification part of the terminal device context identifier, the identifier of the target network device is obtained by the blind solution, and the terminal device context identifier that is carried in the MSG3 decoding is obtained;

When the PUSCH is scrambled based on the terminal context identifier, obtaining the terminal device context identifier by using a blind solution, and determining an identifier of the target network device;

When the PUSCH is scrambled based on the temporary C-RNTI, the terminal device context identifier that is carried in the MSG3 decoding is obtained, and the identifier of the target network device is determined; the MSG3 carries the terminal device context identifier. MAC CE.
An integrity protection method is applied to a terminal device, and the method includes:

Sending, to the network side, an MSG3 message including an RRC connection recovery request, where the RRC connection recovery request carries a terminal device context identifier.
The method of claim 14, wherein the transmitting the MSG3 message including the RRC connection recovery request to the network side comprises:

Restore the UE AS context and SRB1;

The RRC Connection Recovery Request message is integrity protected and/or encrypted using a key and security algorithm in the UE AS context;

An RRC connection recovery request is sent in the MSG3, and the MAC CE carrying the terminal device context identifier is obtained in the MSG3.
The method of claim 15 wherein the method further comprises:

The temporary C-RNTI allocated by the network side is obtained from the random access response RAR in the MSG2.
The method of claim 16 wherein the method further comprises:

The RRC connection recovery request transmitted in the MSG3 on the PUSCH is scrambled based on the temporary C-RNTI.
The method of claim 14, wherein the method further comprises:

Obtaining a preamble sequence allocated by the network side through system broadcast, or a protocol specifying a unique preamble sequence of the entire network;

The preamble sequence is used by the MSG3 to send an SRB1 message.
The method of claim 18, wherein the method further comprises:

Receiving a random access response sent by the network side;

Obtaining at least an uplink scheduling resource and a temporary C-RNTI in the random access response;

And transmitting an RRC connection recovery request according to the PUSCH corresponding to the uplink scheduling resource.
The method of claim 19, wherein the method further comprises:

The base station identification part based on the terminal device context identifier, or the PUSCH is scrambled based on the terminal context identifier or based on the C-RNTI.
A first network device, the method comprising:

The first communication unit receives an MSG3 message that is sent by the terminal device and includes an RRC connection recovery request; and acquires the terminal device context from the target network device;

The first processing unit acquires the terminal device context identifier and/or the target network device identifier from the MSG3 and/or by decoding the PUSCH where the MSG3 is located.
The first network device according to claim 21, wherein said first communication unit transmits TB data including said terminal device context identifier to said target network device; when said target network device determines integrity When the verification is successful, the terminal device context is obtained from the target network device, and the terminal device context is restored.
The first network device according to claim 22, wherein the first communication unit acquires a rejection of the terminal device indication from the target network device when the target network device determines that the integrity check fails, and The terminal device is rejected from restoring the context request.
The first network device according to claim 21, wherein the first communication unit acquires the terminal device context from the target network device based on the terminal device context identifier;

The first processing unit performs decoding and integrity check on the TB data including the terminal device context identifier; when the integrity check succeeds, it is determined to restore the terminal device context.
The first network device according to claim 24, wherein said first processing unit determines to reject said terminal device to resume a context request when said integrity check fails.
The first network device according to any one of claims 21-25, wherein the first communication unit hands the RRC connection recovery request to a MAC layer of SRB0;

Decoding is performed by the MAC layer to determine that the TB data is the data of SRB1.
The first network device according to claim 26, wherein the first processing unit receives an RRC connection recovery request sent by the terminal device in the MSG3, and acquires the terminal device context identifier from the MSG3. The MAC CE obtains the terminal device context identifier by decoding the MAC CE, and determines the identifier of the target network device.
The first network device according to claim 27, wherein said first communication unit allocates a temporary C-RNTI to said terminal device in a random access response RAR in MSG2.
The first network device according to claim 28, wherein the first processing unit descrambles an RRC connection recovery request sent by the terminal device in the MSG3 on the PUSCH based on the temporary C-RNTI.
The first network device according to any one of claims 21-25, wherein the first communication unit broadcasts a preamble sequence to the terminal device through a system broadcast, or specifies a unique preamble sequence of the entire network;

The preamble sequence is used by the MSG3 to send an SRB1 message.
The first network device according to claim 30, wherein the first communication unit sends a random access response to the terminal device, and carries at least an uplink scheduling resource and a temporary C-RNTI in the random access response. .
The first network device according to claim 30, wherein the first communication unit receives an MSG3 message including an RRC connection recovery request sent by the terminal device through the PUSCH.
The first network device according to claim 32, wherein said first processing unit,

When the PUSCH is scrambled based on the base station identification part of the terminal device context identifier, the identifier of the target network device is obtained by the blind solution, and the terminal device context identifier that is carried in the MSG3 decoding is obtained;

When the PUSCH is scrambled based on the terminal context identifier, obtaining the terminal device context identifier by using a blind solution, and determining an identifier of the target network device;

When the PUSCH is scrambled based on the temporary C-RNTI, the terminal device context identifier that is carried in the MSG3 decoding is obtained, and the identifier of the target network device is determined.

The MAC address of the terminal device context identifier is carried in the MSG3;
A terminal device, the terminal device comprising:

The second communication unit sends an MSG3 message including an RRC connection recovery request to the network side, where the RRC connection recovery request carries the terminal device context identifier.
The terminal device according to claim 34, wherein the terminal device further comprises:

a second processing unit, recovering the UE AS context and SRB1; performing integrity protection and/or encryption on the RRC connection recovery request message using a key and a security algorithm in the UE AS context;

The second communication unit sends an RRC connection recovery request in the MSG3, and acquires, in the MSG3, a MAC CE carrying the terminal device context identifier.
The terminal device according to claim 35, wherein the second communication unit acquires a temporary C-RNTI allocated by the network side from a random access response RAR in the MSG2.
The terminal device according to claim 36, wherein said second communication unit scrambles an RRC connection recovery request transmitted in MSG3 on the PUSCH based on the temporary C-RNTI.
The terminal device according to claim 34, wherein the second communication unit acquires a preamble sequence allocated by the network side through system broadcast, or specifies a unique preamble sequence of the entire network by using a protocol;

The preamble sequence is used by the MSG3 to send an SRB1 message.
The terminal device according to claim 38, wherein the second communication unit receives a random access response sent by the network side;

Obtaining at least an uplink scheduling resource and a temporary C-RNTI in the random access response;

And transmitting an RRC connection recovery request according to the PUSCH corresponding to the uplink scheduling resource.
The terminal device according to claim 39, wherein the terminal device further comprises:

The second processing unit performs scrambling based on the base station identification part of the terminal device context identifier, or the PUSCH is based on the terminal context identifier, or based on the C-RNTI.
A first network device comprising: a processor and a memory for storing a computer program executable on the processor,

Wherein the processor is operative to perform the steps of the method of any of claims 1-13 when the computer program is run.
A terminal device includes: a processor and a memory for storing a computer program executable on the processor,

Wherein the processor is operative to perform the steps of the method of any one of claims 14-20 when the computer program is run.
A computer storage medium storing computer executable instructions that, when executed, implement the steps of the method of any of claims 1-20.