CN116419234A

CN116419234A - Communication method and device

Info

Publication number: CN116419234A
Application number: CN202111676731.4A
Authority: CN
Inventors: 胡力; 韩锋; 吴�荣
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2021-12-31
Filing date: 2021-12-31
Publication date: 2023-07-11
Also published as: WO2023125576A1

Abstract

The application provides a communication method and a communication device, which belong to the technical field of communication and are used for avoiding security risks and ensuring the communication security of a user plane under the condition that an UP IP strategy is forcedly opened, but access network equipment cannot open the UP IP for the forcedly opened UP IP session. The method comprises the following steps: the mobile management entity receives the user plane integrity protection UP IP acknowledgement message from the access network device and triggers the release of the E-RAB. Wherein, the UP IP acknowledgement message may indicate whether the RAN device starts UP IP corresponding to the E-RAB. Under the condition that the UP IP corresponding to the E-RAB is forced to be opened and the RAN equipment does not open the UP IP corresponding to the E-RAB, the MME can determine that the UP IP corresponding to the E-RAB is not opened according to the UP IP confirmation message so as to trigger the access network equipment to release the E-RAB, thereby avoiding the occurrence of safety risk and ensuring the communication safety of a user plane.

Description

Communication method and device

Technical Field

The present disclosure relates to the field of communications, and in particular, to a communication method and apparatus.

Background

A user plane integrity protection (user plane integrity protection, UP IP) policy is introduced in the 5th generation (5th generation,5G) mobile communication system to protect User Plane (UP) communication contents of a User Equipment (UE) from tampering. The UP IP policy generally includes: forced on (required), recommended on (preferred), and not on (non-required). Wherein forced opening may be for a session with higher security requirements. In case the UP IP policy of a certain session is forced to open, if the radio access network (radio access network, RAN) device cannot open UP IP, the session should be refused to be established, avoiding security risks.

Currently, the 4th generation (4th generation,4G) mobile communication system also introduces a 5G-like UP IP policy. However, since 4G does not initially design the relevant flow of UP IP, introducing UP IP policies may occur when some RAN devices support UP IP and some RAN devices do not support UP IP. For RAN devices that do not support UP IP, the RAN device may not recognize the UP IP policy because UP IP is not supported. At this time, if the UP IP policy is forced to be opened, and the RAN device cannot open the UP IP for the session in which the UP IP is forced to be opened, security of the session may be affected, and there is a security risk.

Disclosure of Invention

The embodiment of the application provides a communication method and a communication device, which are used for guaranteeing the communication safety of a user plane.

The application adopts the following technical scheme:

in a first aspect, a communication method is provided. The method comprises the following steps: the mobile management entity receives the user plane integrity protection UP IP acknowledgement message from the access network device. The UP IP confirmation message indicates whether the access network equipment starts the UP IP corresponding to the E-UTRAN radio access bearer E-RAB. If the UP IP strategy corresponding to the E-RAB is forced to be started, and the UP IP confirmation message indicates that the access network equipment does not start the UP IP corresponding to the E-RAB, the mobile management entity triggers the release of the E-RAB.

Based on the method of the first aspect, it is known that, since the UP IP acknowledgement message may indicate whether the RAN device starts UP IP corresponding to the E-RAB. Under the condition that the UP IP corresponding to the E-RAB is forced to be opened and the RAN equipment does not open the UP IP corresponding to the E-RAB, the MME can determine that the UP IP corresponding to the E-RAB is not opened according to the UP IP confirmation message so as to trigger the access network equipment to release the E-RAB, thereby avoiding the occurrence of safety risk and ensuring the communication safety of a user plane.

In one possible implementation manner, the method of the first aspect may further include: the mobile management entity determines that the UP IP strategy corresponding to the E-RAB is forced to be opened, and determines that the UP IP result information corresponding to the E-RAB is not available in the UP IP confirmation message, or that the UP IP result information corresponding to the E-RAB is available in the UP IP confirmation message, and the value of the UP IP result information corresponding to the E-RAB is UP IP closing. The UP IP result information corresponding to the E-RAB is used for indicating whether the UP IP corresponding to the E-RAB is opened or closed. It may be appreciated that, in the case where the access network device supports UP IP, the access network device may identify an UP IP policy corresponding to the E-RAB, and the access network device may carry UP IP result information corresponding to the E-RAB in the UP IP acknowledgement message, so as to display an indication that the UP IP corresponding to the-RAB is turned off. Or under the condition that the access network equipment does not support UP IP, the access network equipment cannot identify the UP IP strategy corresponding to the E-RAB, and cannot carry UP IP result information corresponding to the E-RAB in the UP IP confirmation message; it may be appreciated that the UP IP result information corresponding to the E-RAB is not carried in the UP IP acknowledgement message, which may implicitly indicate that the UP IP corresponding to the RAB is turned off. That is, no matter whether the access network device supports the UP IP, when the access network device does not start the UP IP, the MME can trigger the access network device to release the corresponding E-RAB according to the UP IP confirmation message, so as to further reduce the security risk and further ensure the communication security of the user plane.

In one possible implementation manner, the method of the first aspect may further include: the mobile management entity determines whether the UP IP result information corresponding to the E-RAB exists in the UP IP confirmation message. At this time, if the UP IP acknowledgement message has UP IP result information corresponding to the E-RAB, the mobility management entity determines whether the value of the UP IP result information corresponding to the E-RAB matches the UP IP policy corresponding to the E-RAB. .

In one possible implementation manner, the method of the first aspect may further include: the mobile management entity determines whether the UP IP policy corresponding to the E-RAB is forced on. Under the condition that the UP IP strategy corresponding to the E-RAB is forced to be opened, the mobile management entity determines whether the value of UP IP result information corresponding to the E-RAB in the UP IP confirmation message is matched with the UP IP strategy corresponding to the E-RAB. That is, the mobile management entity only analyzes the E-RAB with the UP IP policy being forced to be opened to determine whether the value of the UP IP result information corresponding to the E-RAB is matched with the UP IP policy corresponding to the E-RAB, so that the operation cost of the mobile management entity can be effectively saved, and the operation efficiency is improved.

Whether the value of the UP IP result information corresponding to the E-RAB is matched with the UP IP policy corresponding to the E-RAB may be, for example: if the UP IP strategy corresponding to the E-RAB is forced to be started and the value of the UP IP result information corresponding to the E-RAB is UP IP to be closed, the value of the UP IP result information corresponding to the E-RAB is not matched with the UP IP strategy corresponding to the E-RAB; if the UP IP strategy corresponding to the E-RAB is not started and the value of the UP IP result information corresponding to the E-RAB is UP IP closed, the value of the UP IP result information corresponding to the E-RAB is considered to be matched with the UP IP strategy corresponding to the E-RAB; if the UP IP strategy corresponding to the E-RAB is forced to be started and the value of the UP IP result information corresponding to the E-RAB is UP IP to be started, the value of the UP IP result information corresponding to the E-RAB is considered to be matched with the UP IP strategy corresponding to the E-RAB. If the UP IP strategy corresponding to the E-RAB is recommended to be started, the value of the UP IP result information corresponding to the E-RAB is considered to be matched with the UP IP strategy corresponding to the E-RAB no matter the UP IP is closed or opened.

Alternatively, in another possible design, the method of the first aspect may further include: the mobile management entity determines whether the UP IP policy corresponding to the E-RAB is forced on. And under the condition that the UP IP strategy corresponding to the E-RAB is forced to be opened, the mobile management entity further determines whether UP IP result information corresponding to the E-RAB does not exist in the UP IP confirmation message. It can be seen that the mobility management entity only analyzes and judges the E-RAB with the UP IP policy being forced to be opened, so that the operation cost of the mobility management entity can be effectively saved, and the operation efficiency is improved.

In a possible design, before the release of the E-RAB is triggered by the mobility management entity, the method of the first aspect may further include: the mobility management entity determines that the terminal supports UP IP. That is, the mobile management entity only analyzes and judges whether the UP IP corresponding to the E-RAB should be started or not under the condition that the terminal supports the UP IP, so that the operation cost of the mobile management entity can be effectively saved, and the operation efficiency is improved.

In one possible design, the UP IP acknowledgement message may include at least one of the following: an initial context setup response message, an E-RAB setup/modification response message, a path switch request message, a switch request acknowledgement message, or an E-RAB modification indication message, to implement signaling multiplexing and improve communication efficiency.

In one possible design, the mobile management entity triggering release of the E-RAB may include: the mobile management entity sends a release message for the E-RAB to the access network equipment to trigger the access network equipment to release the E-RAB so as to avoid the occurrence of safety risk and ensure the communication safety of the user plane.

Optionally, the release message may include at least one of the following: E-RAB release instruction message or path switching request confirmation message to realize signaling multiplexing and improve communication efficiency.

In a possible design, the UP IP acknowledgement message includes a context identifier of the terminal, and the method in the first aspect may further include: and the mobile management entity acquires the UP IP strategy corresponding to the E-RAB from the context corresponding to the context identifier of the terminal according to the context identifier of the terminal. That is, the UP IP policy corresponding to the E-RAB may be acquired by the management entity by multiplexing the UP IP acknowledgement message to carry the context identifier of the terminal. In this way, the access network device does not need to send the context identifier of the terminal separately, so that the communication efficiency can be improved.

In a second aspect, a communication method is provided. The method comprises the following steps: and the access network equipment sends a user plane integrity protection UP IP confirmation message to the mobile management entity under the condition that the UP IP strategy corresponding to the E-UTRAN wireless access bearer E-RAB is forced to be opened. The UP IP confirmation message is used for indicating whether the access network equipment starts the UP IP corresponding to the E-RAB. In this way, the access network device receives a release message for the E-RAB from the mobility management entity to release the context corresponding to the E-RAB in response to the release message.

Based on the method of the second aspect, it can be known that, in the case that the UP IP corresponding to the E-RAB is forced to be turned on, if the access network device does not turn on the UP IP corresponding to the E-RAB, the access network device may still send an UP IP acknowledgement message to the mobility management entity to indicate that the UP IP corresponding to the E-RAB is turned off. Thus, the mobile management entity can trigger the access network equipment to release the E-RAB, so that the safety risk is avoided, and the communication safety of the user plane is ensured.

In one possible design, the UP IP acknowledgement message may include at least one of the following: an initial context setup response message, an E-RAB setup/modification response message, a path switch request message, a switch request acknowledgement message, or an E-RAB modification indication message.

In one possible design, the release message may include at least one of the following: an E-RAB release order message, or a path switch request acknowledgement message.

Further, the technical effects of the method described in the second aspect may refer to the technical effects of the method described in the first aspect, and are not described herein.

In a third aspect, a communication device is provided. The device comprises: means for performing the method of the first aspect. Examples include: a transceiver module and a processing module.

The receiving and transmitting module is used for receiving the UP IP confirmation message from the user plane integrity protection of the access network equipment. The UP IP confirmation message indicates whether the access network equipment starts the UP IP corresponding to the E-UTRAN radio access bearer E-RAB. And the processing module is used for triggering the release of the E-RAB if the UP IP strategy corresponding to the E-RAB is forced to be started and the UP IP confirmation message indicates that the access network equipment does not start the UP IP corresponding to the E-RAB.

In one possible design, the processing module is further configured to determine that the UP IP policy corresponding to the E-RAB is forced on, and determine that no UP IP result information corresponding to the E-RAB is in the UP IP acknowledgement message, or that UP IP result information corresponding to the E-RAB is in the UP IP acknowledgement message, and the value of the UP IP result information corresponding to the E-RAB is UP IP off. The UP IP result information corresponding to the E-RAB is used for indicating whether the UP IP corresponding to the E-RAB is opened or closed.

In one possible design, the processing module is further configured to determine whether the UP IP result information corresponding to the E-RAB exists in the UP IP acknowledgement message. And the processing module is further used for determining whether the value of the UP IP result information corresponding to the E-RAB is matched with the UP IP strategy corresponding to the E-RAB if the UP IP confirmation message has the UP IP result information corresponding to the E-RAB.

In one possible design, the processing module is further configured to determine whether the UP IP policy corresponding to the E-RAB is forced on. And the processing module is further used for determining whether the value of the UP IP result information corresponding to the E-RAB in the UP IP confirmation message is matched with the UP IP strategy corresponding to the E-RAB under the condition that the UP IP strategy corresponding to the E-RAB is forcedly started.

Or in another possible design, the processing module is further configured to determine whether the UP IP policy corresponding to the E-RAB is forced on, and further determine that no UP IP result information corresponding to the E-RAB is in the UP IP acknowledgement message if the UP IP policy corresponding to the E-RAB is forced on.

In a possible design, the processing module is further configured to determine that the terminal supports UP IP before triggering release of the E-RAB.

In a possible design, the processing module is further configured to control the transceiver module to send a release message for the E-RAB to the access network device.

Optionally, the release message may include at least one of the following: an E-RAB release order message, or a path switch request acknowledgement message.

In one possible design, the UP IP acknowledgement message includes a context identifier of the terminal. And the processing module is also used for acquiring the UP IP strategy corresponding to the E-RAB from the context corresponding to the context identifier of the terminal according to the context identifier of the terminal.

Optionally, the transceiver module may also include a transmitting module and a receiving module. The sending module is used for realizing the sending function of the device in the third aspect, and the receiving module is used for realizing the receiving function of the device in the third aspect.

Optionally, the apparatus according to the third aspect may further include a storage module, where the storage module stores a program or instructions. The program or instructions, when executed by a processing module, enable the apparatus to perform the method of the first aspect.

It should be noted that, the apparatus described in the third aspect may be a network device, for example, a mobility management entity, or may be a chip (system) or other components or assemblies that may be disposed in the network device, or may be an apparatus including the network device, which is not limited in this application.

In addition, the technical effects of the apparatus described in the third aspect may refer to the technical effects of the method described in the first aspect, which are not described herein.

In a fourth aspect, a communication device is provided. The device comprises: means for performing the method of the second aspect. Examples include: a transceiver module and a processing module.

The receiving and transmitting module is used for sending a user plane integrity protection UP IP confirmation message to the mobile management entity under the condition that the UP IP strategy corresponding to the E-UTRAN wireless access bearer E-RAB is forced to be opened. The UP IP confirmation message is used for indicating whether the access network equipment starts the UP IP corresponding to the E-RAB. And the transceiver module is also used for receiving the release message for the E-RAB from the mobile management entity. And the processing module is used for responding to the release message and releasing the context corresponding to the E-RAB.

Optionally, the transceiver module may also include a transmitting module and a receiving module. The sending module is used for realizing the sending function of the device according to the fourth aspect, and the receiving module is used for realizing the receiving function of the device according to the fourth aspect.

Optionally, the apparatus according to the fourth aspect may further include a storage module, where the storage module stores a program or instructions. The program or instructions, when executed by a processing module, enable the apparatus to perform the method of the second aspect.

The apparatus according to the fourth aspect may be a network device, for example, an access network device, or may be a chip (system) or other parts or components that may be disposed in the network device, or may be an apparatus including the network device, which is not limited in this application.

In addition, the technical effects of the apparatus according to the fourth aspect may refer to the technical effects of the method according to the second aspect, which are not described herein.

In a fifth aspect, a communication device is provided. The device comprises: a processor. Wherein the processor is configured to perform the method according to the first or second aspect.

In a possible implementation manner, the apparatus according to the fifth aspect may further include a transceiver. The transceiver may be a transceiver circuit or an interface circuit. The transceiver may be used for the device to communicate with other devices.

In a possible embodiment, the device according to the fifth aspect may further comprise a memory. The memory may be integral with the processor or may be separate. The memory may be used to store computer programs and/or data related to the method of the first or second aspect.

In this application, the apparatus of the fifth aspect may be a network device in the first aspect or the second aspect, such as a mobility management entity or an access network device, or a chip (system) or other part or component that may be provided in a network device, or an apparatus that includes the network device.

Further, the technical effects of the apparatus according to the fifth aspect may refer to the technical effects of the method according to the first aspect or the second aspect, and are not described herein.

In a sixth aspect, a communication device is provided. The device comprises: a processor and a memory. Wherein the memory is for storing computer instructions which, when executed by the processor, cause the apparatus to perform the method according to the first or second aspect.

In a possible implementation manner, the apparatus according to the sixth aspect may further include a transceiver. The transceiver may be a transceiver circuit or an interface circuit. The transceiver may be used for the device to communicate with other devices.

In this application, the apparatus of the sixth aspect may be a network device in the first or second aspect, such as a mobility management entity or an access network device, or a chip (system) or other part or component that may be provided in the network device, or an apparatus comprising the network device.

In addition, the technical effects of the apparatus described in the sixth aspect may refer to the technical effects of the method described in the first aspect or the second aspect, which are not described herein.

In a seventh aspect, a communication device is provided. The device comprises: logic circuitry and input-output interfaces. The input/output interface is used for receiving the code instruction and transmitting the code instruction to the logic circuit. Logic circuitry is to execute code instructions to perform the method as described in the first or second aspect.

In this application, the apparatus of the seventh aspect may be a network device in the first aspect or the second aspect, such as a mobility management entity or an access network device, or a chip (system) or other part or component that may be provided in the network device, or an apparatus that includes the network device.

In addition, the technical effects of the apparatus described in the seventh aspect may refer to the technical effects of the method described in the first aspect or the second aspect, which are not described herein.

In an eighth aspect, a communication device is provided. The device comprises: a processor and a transceiver. Wherein the transceiver is for information interaction between the communication device and the other device, and the processor executes program instructions for performing the method according to the first or second aspect.

In a possible embodiment, the device according to the eighth aspect may further comprise a memory. The memory may be integral with the processor or may be separate. The memory may be used to store computer programs and/or data related to the method of the first or second aspect.

In this application, the apparatus of the eighth aspect may be a network device in the first aspect or the second aspect, such as a mobility management entity or an access network device, or a chip (system) or other part or component that may be provided in the network device, or an apparatus that includes the network device.

Further, the technical effects of the apparatus according to the eighth aspect may refer to the technical effects of the method according to the first aspect or the second aspect, and will not be described herein.

In a ninth aspect, a communication system is provided. The system comprises: a mobility management entity and an access network device.

The mobile management entity is used for receiving a user plane integrity protection UP IP confirmation message from the access network equipment, wherein the UP IP confirmation message indicates whether the access network equipment starts UP UP IP corresponding to E-UTRAN wireless access bearer E-RAB; and the method is also used for triggering the release of the E-RAB if the UP IP strategy corresponding to the E-RAB is forced to be started and the UP IP confirmation message indicates that the access network equipment does not start the UP IP corresponding to the E-RAB. An access network device, configured to receive a release message for the E-RAB from the mobility management entity, and further configured to release a context corresponding to the E-RAB according to the release message.

In one possible design, the mobility management entity is further configured to determine that the UP IP policy corresponding to the E-RAB is forced on, and determine that no UP IP result information corresponding to the E-RAB exists in the UP IP acknowledgement message, or that UP IP result information corresponding to the E-RAB exists in the UP IP acknowledgement message, and that the value of the UP IP result information corresponding to the E-RAB is UP IP off. The UP IP result information corresponding to the E-RAB is used for indicating whether the UP IP corresponding to the E-RAB is opened or closed.

In one possible design, the mobility management entity is further configured to determine whether the UP IP result information corresponding to the E-RAB exists in the UP IP acknowledgement message. And the mobile management entity is further used for determining whether the value of the UP IP result information corresponding to the E-RAB is matched with the UP IP strategy corresponding to the E-RAB if the UP IP confirmation message has the UP IP result information corresponding to the E-RAB.

In one possible design, the mobility management entity is further configured to determine whether an UP IP policy corresponding to the E-RAB is forced on; and the mobile management entity is also used for determining whether the value of the UP IP result information corresponding to the E-RAB in the UP IP confirmation message is matched with the UP IP strategy corresponding to the E-RAB under the condition that the UP IP strategy corresponding to the E-RAB is forcedly opened.

Or in another possible design, the mobility management entity is further configured to determine whether the UP IP policy corresponding to the E-RAB is forced on, and further determine that no UP IP result information corresponding to the E-RAB is in the UP IP acknowledgement message if the UP IP policy corresponding to the E-RAB is forced on.

In one possible design, the access network device is further configured to send an UP IP acknowledgement message to the mobility management entity when the UP IP policy corresponding to the E-RAB is forced on.

In a possible design, the mobility management entity is further configured to determine that the terminal supports UP IP before triggering release of the E-RAB.

In one possible design, the UP IP acknowledgement message may include a context identification of the terminal. And the mobile management entity is also used for acquiring the UP IP strategy corresponding to the E-RAB from the context corresponding to the context identifier of the terminal according to the context identifier of the terminal.

Further, the technical effects of the apparatus according to the ninth aspect may refer to the technical effects of the method according to the first or second aspect, and are not described herein.

In a tenth aspect, there is provided a computer readable storage medium comprising: computer programs or instructions; the computer program or instructions, when run on a computer, cause the computer to perform the method of the first or second aspect.

In an eleventh aspect, there is provided a computer program product comprising a computer program or instructions which, when run on a computer, cause the computer to perform the method of the first or second aspect.

Drawings

FIG. 1 is a diagram of an exemplary architecture of a 4G;

FIG. 2 is a diagram of an example of a 4G-5G fusion architecture;

FIG. 3 is a diagram of an example dual connection architecture;

fig. 4 is a schematic flow diagram of UP IP in a 5gs > eps HO scenario;

fig. 5 is a schematic architecture diagram of a communication system according to an embodiment of the present application;

fig. 6 is a schematic flow chart of a communication method according to an embodiment of the present application;

fig. 7 is a second flow chart of a communication method according to an embodiment of the present application;

fig. 8 is a flowchart of a communication method according to an embodiment of the present application;

fig. 9 is a flow chart diagram of a communication method according to an embodiment of the present application;

fig. 10 is a flowchart fifth of a communication method according to an embodiment of the present application;

fig. 11 is a flowchart sixth of a communication method provided in the embodiment of the present application;

fig. 12 is a schematic structural diagram of a communication device according to an embodiment of the present application;

fig. 13 is a second schematic structural diagram of a communication device according to an embodiment of the present application;

fig. 14 is a schematic structural diagram III of a communication device according to an embodiment of the present application.

Detailed Description

It is convenient to understand that technical terms related to the embodiments of the present application are first described below.

1. Disregard (ignore) or reject (reject):

for a cell, the network side (e.g., core Network (CN)) may configure the cell's attributes (characteristics) to be ignored or rejected.

In the case where the attribute of a cell is configured to reject, if a device obtains signaling carrying the cell and cannot identify the cell, the device may choose to reject the response signaling, i.e., the request or indication of all cells in the signaling cannot be responded to. Alternatively, in the case where the attribute of a cell is configured to be ignored, if a device obtains signaling carrying the cell and cannot identify the cell, the device may choose to ignore the cell in response to a request or indication of other identifiable cells in the signaling than the cell.

2. Architecture of 4th generation (4th generation,4G) mobile communication system:

fig. 1 is an exemplary diagram of a 4G architecture provided in the present application, where, as shown in fig. 1, the 4G architecture mainly includes: a terminal, an evolved node B (eNB), a mobility management entity (mobility management entity, MME).

The terminal may be a terminal having a wireless transmitting/receiving function, or may be a chip or a chip system provided in the terminal. The terminal may also be referred to as a User Equipment (UE), an access terminal, a subscriber unit (subscriber unit), a subscriber station, a Mobile Station (MS), a remote station, a remote terminal, a mobile device, a user terminal, a wireless communication device, a user agent, or a user device. The terminals in embodiments of the present application may be mobile phones (mobile phones), cellular phones (cellular phones), smart phones (smart phones), tablet computers (pads), wireless data cards, personal digital assistants (personal digital assistant, PDAs), wireless modems (modems), handheld devices (handsets), laptop computers (lap computers), machine type communication (machine type communication, MTC) terminals, computers with wireless transceiving functions, virtual Reality (VR) terminals, augmented reality (augmented reality, AR) terminals, wireless terminals in industrial control (industrial control), wireless terminals in unmanned aerial vehicle (self driving), wireless terminals in smart grid (smart grid), wireless terminals in transportation security (transportation safety), wireless terminals in smart city (smart city), wireless terminals in smart home (smart home), roadside units with functions, RSU, etc. The terminal of the present application may also be an in-vehicle module, an in-vehicle component, an in-vehicle chip, or an in-vehicle unit built into a vehicle as one or more components or units.

The above enbs may also be referred to as enodebs, or as evolved universal mobile telecommunications system (universal mobile telecommunications system, UMTS) terrestrial radio access network (Evolved UMTS terrestrial radio access network, E-UTRAN) devices. The eNB is mainly used to provide a network access function for terminals in a specific area, such as a network signal coverage area of the eNB, so that the terminals can be accessed and attached to the 4G network through the eNB.

The MME is mainly responsible for mobility management of a terminal (e.g., a terminal accessing an eNB), storing a context of the terminal (e.g., an identity of the terminal, a mobility management state, a user security parameter, etc.), bearer (bearer) management, etc. And, the MME may also be responsible for processing non-access stratum (NAS) signaling, such as attach request (attach request) message, location update request (update location request) message, service request (service request) message, and packet data network connection request (PDN connectivity request) message, etc., to ensure NAS signaling security.

3. Fusion architecture of 4G-5 th generation (5th generation,5G) mobile communication system:

fig. 2 is an exemplary diagram of a 4G-5G fusion architecture provided in the present application, where, as shown in fig. 2, the 4G-5G fusion architecture mainly includes: terminal, eNB, MME, next generation node B (next generation node B, gNB), and access and mobility management function (access and mobility management function, AMF) network elements.

The specific functions of the terminal, the eNB, and the MME may be described with reference to the related description in the 4G architecture, which is not described herein.

The above-mentioned gNB may also be referred to as gNodeB or as a next generation radio access network (next generation radio access network, NG-RAN) device. Similar to enbs, the gNB is typically mainly used to provide network access functions for terminals in a specific area, such as the network signal coverage area of the gNB, so that the terminals can access and attach to the 5G network through the gNB.

The AMF network element is mainly responsible for access and mobility management of the terminal, such as registration management, reachability management and mobility management of the terminal, paging management, access authentication, encryption and integrity protection of authorized non-access layer signaling, and the like.

It should be noted that in the 4G-5G convergence architecture, the terminal may access and attach to the 4G network through the eNB and switch to the 5G network, or may access and attach to the 5G network through the gNB and switch to the 4G network. In addition, the enbs or gnbs may also be collectively referred to as radio access network (radio access network, RAN) devices, or access network devices. Of course, the RAN device may also include other forms of devices, such as Access Points (APs) in a wireless fidelity (wireless fidelity, wiFi) system, wireless relay nodes, wireless backhaul nodes, various forms of macro base stations, micro base stations (also referred to as small stations), relay stations, access points, wearable devices, vehicle devices, and so on. It is convenient to understand that the RAN devices mentioned below are generally referred to as enbs unless specifically indicated.

4. Dual connection architecture:

fig. 3 is a schematic diagram of an exemplary dual-connection architecture provided in the present application, and as shown in fig. 3, the dual-connection architecture is a typical architecture in a 4G-5G fusion architecture, and mainly includes: a terminal, a Master Node (MN), a Slave Node (SN), and a Core Network (CN).

In one possible approach, the MN may be an eNB, the SN may be a gNB, and the CN may include an MME. Alternatively, in another possible manner, the MN may be an eNB, the SN may be an eNB, and the CN may include an MME. The MN and the SN can communicate through an X2 interface, and the MN and the CN can communicate through an S1 interface. The terminal may be connected to the MN and the SN through Uu interfaces, respectively, to access the CN through the MN and the SN. In addition, the specific functions of the terminal, the eNB, the gNB, and the MME may refer to the relevant descriptions in the 4G architecture and the 4G-5G convergence architecture, which are not described herein.

5. Handover (handover):

the handover refers to that the RAN device can actively handover the terminal to a cell of a RAN device with better signal strength (e.g., a neighbor RAN device) under the condition that the RAN device perceives that the signal strength of the terminal in its own cell is gradually weakened. There are several ways of switching in general, including: x2 interface handover (X2 HO), S1 interface handover (S1 HO), and handover of 5G system (system) to evolved packet system (evolved packet system, EPS) (5 gs > EPS HO).

Wherein, X2 HO means that the RAN equipment directly switches the terminal through an X2 interface without a CN. For example, eNB1 switches the UE from eNB1 to eNB2 through an X2 interface with eNB2. S1 HO refers to the RAN device switching the terminal to other RAN devices via the CN through the S1 interface. For example, eNB1 switches the UE from eNB1 to eNB2 via the CN through an S1 interface with the CN. 5GS > EPS HO means that the 5G RAN device switches the terminal to the 4G RAN device through 5G CN (5 GC) and 4G CN (4 GC). For example, the gNB switches the UE from the gNB to the eNB through the MME and the AMF.

6. User plane integrity protection (user plane integrity protection, UP IP):

the UP IP policy is a security policy introduced in 5G, and is used for protecting User Plane (UP) communication content of the UE from being tampered, so as to ensure communication security. The UP IP policy generally includes: forced on (required), recommended on (preferred), and not on (non-required). Wherein forced opening is for sessions with high security requirements. For example, in case the UP IP policy of a certain session of the UE is forced to be turned on, the base station, i.e. the RAN device (e.g. the gNB), should turn on UP IP. If the base station cannot start UP the UPIP, the session should be refused to be established, so that security risks are avoided. Recommended to open and not open are sessions that are generic to security requirements. For example, in the case that the UP IP policy of a certain session of the UE is recommended to be turned on, the base station may choose to turn on or not to turn on the UP IP according to its own situation (e.g. load size). Alternatively, the base station may not turn on the UP IP in case the UP IP policy of a certain session of the UE is not turned on.

Currently, some scenarios in 4G also introduce a 5G-like UP IP policy. For example, in a handover scenario, after a terminal is handed over to a new base station, the new base station may provide UP IP to the terminal to ensure the security of communication. However, since 4G does not design related flows of UP IP at first, introducing UP IP policies may occur when some devices support UP IP and another device does not support UP IP. For convenient understanding, the following description will take 5gs > eps HO as an example, and reference is made to understanding for X2 HO and S1HO, and no further description is given.

Fig. 4 is a schematic flow diagram of UP IP in a 5gs > eps HO scenario provided in the present application, as shown in fig. 4, where the flow includes:

s401, the UE connects to 5GC through the gNB.

The UE may access the gNB through the initial access, thereby completing the attachment through the access of the gNB to the 5GC.

S402, the gNB determines that the UE needs to be handed over to the eNB.

As the UE moves, for example, the UE gradually moves away from the gNB, the gNB may perceive that the signal strength of the UE gradually decreases. When the signal strength of the UE is reduced to a certain extent, the gNB determines that the UE needs to be switched to a base station with better signal strength, so that a base station with better signal strength, for example, an eNB, can be selected from the candidate base stations.

S403, the gNB sends a handover required (handover required) message to the AMF network element. Accordingly, the AMF network element receives the handover required message from the gNB.

The handover required message is used to request handover of the UE to the corresponding eNB. The handover required message may include: tracking area codes (tracking area code, TAC) are used to indicate that the handover required message needs to be sent to the corresponding AMF network element. Optionally, the handover required message may further include: UP IP policy. The UP IP policy may include: forced on, recommended on, and not on.

S404, the AMF network element sends a relocation request (relocation request) message to the MME. Correspondingly, the MME receives a relocation request message from the AMF network element.

The AMF network element may determine, according to the TAC in the handover required message, an MME to which the eNB is connected to be handed over.

The AMF network element may determine the relocation request message based on the handover required message. The relocation request message is used to request handover of the UE to the corresponding eNB. The handover required message may include: the identification of the eNB may optionally further include: UP IP policy.

S405, the MME sends a handover request (handover request) message to the eNB. Accordingly, the eNB receives the handover request message from the MME.

The MME may determine the eNB to be handed over according to the identity of the eNB in the relocation request message. The handover request message is used to request handover of the UE to the eNB. Optionally, the handover request message may further include: UP IP policy.

S406, the eNB sends a handover request confirm (handover request ACK) message to the MME. Correspondingly, the MME receives a handover request confirm message from the eNB.

The eNB may determine a handover request confirm message according to the handover request message. The handover request confirm message is used to indicate that the UE may be handed over to the eNB or that the UE may not be handed over to the eNB. Optionally, the handover request acknowledgement message may carry capability indication information that the eNB supports UP IP.

In a possible manner, the eNB is an eNB supporting UP IP, and the eNB may acquire an UP IP policy, or may carry the capability indication information to a handover request acknowledgement message, or may start UP IP for a UE that is about to handover. The eNB may obtain the UP IP policy from the handover request acknowledgement message, or may obtain the UP IP policy from the gNB or MME alone, or may also obtain the UP IP policy from a policy locally preconfigured by the eNB, which is not specifically limited in this application.

In another possible manner, the eNB is an eNB that does not support UP IP, and the eNB cannot identify UP IP policy, and cannot carry capability indication information to the handover request acknowledgement message, and further cannot turn on UP IP for the UE that is about to handover.

S407, the MME sends a relocation response (relocation response) message to the AMF network element. Accordingly, the AMF network element receives the relocation response message from the MME.

The MME may determine the relocation response message from the handover request confirm message. The relocation response message is used to indicate that the UE may or may not be handed over to the eNB. Optionally, the relocation response message may carry capability indication information of UP IP supported by the eNB.

S408, the AMF network element sends a handover command (handover command) message to the gNB. Correspondingly, the gNB receives the handover instruction message from the AMF network element.

The AMF network element may determine the handover instruction message based on the relocation response message. The handover instruction message is used to indicate that the UE may be handed over to the eNB or that the UE cannot be handed over to the eNB. Optionally, the handover instruction message may carry capability indication information of UP IP supported by the eNB.

S409, the gNB sends a radio resource control (radio resource control, RRC) reconfiguration (RRC reconfiguration) message to the UE. Accordingly, the UE receives an RRC reconfiguration message from the gNB.

And the UE is successfully switched to the eNB according to the RRC reconfiguration message.

S410, the gNB sends a cancel handover (handover cancel) message to the MME. Correspondingly, the MME receives a cancel handover message from the gNB.

Wherein S409 and S410 are optional steps. If the handover instruction message carries capability indication information of UPIP supported by eNB, the gNB determines that the eNB selected for handover is the eNB supporting UPIP. In this way, the gNB may perform S409 to send an RRC reconfiguration message to the UE to instruct the UE to switch to the eNB. However, if the handover instruction message does not carry capability indication information of UP IP supported by the eNB, the gNB determines that the eNB that is selected for handover at this time is an eNB that does not support UP IP. In this way, the gNB may perform S410 to send a cancel handover message to the MME to indicate that the present handover is cancelled. At this time, the gNB may continue to select a new base station from the candidate base stations, and iteratively perform the above-described steps S403 to S408 until the UE is handed over to an eNB supporting UP IP.

It can be seen that, since the gNB does not know in advance whether the selected eNB supports UP IP, this results in that the gNB needs to repeatedly perform the handover procedure one or more times in the case of not supporting UP IP until the selected eNB supporting UP IP, which results in long time delay of handover and low handover efficiency. For certain service scenarios with high delay requirements, such as unmanned or telemedicine service scenarios, the above switching manner obviously cannot meet the service requirements. In addition, the UP IP of the above 4G is only suitable for a handover scenario, and is not suitable for other service scenarios of the 4G, such as initial access, session establishment, dual connectivity scenario, etc., so that the security of user plane communication in other service scenarios is not guaranteed.

In summary, aiming at the technical problems, the embodiments of the present application propose the following technical solutions to ensure the security of user plane communication in various service scenarios of 4G.

The technical solution of the embodiments of the present application may be applied to various communication systems, such as 4G, e.g. long term evolution (long term evolution, LTE) system, 4G-5G converged communication system, and future communication systems, e.g. generation 6 (6th generation,6G), etc., although other naming manners of future communication systems are also possible, which are still covered in the scope of the present application, and the present application is not limited in this regard.

The present application will present various aspects, embodiments, or features about a system that may include multiple devices, components, modules, etc. It is to be understood and appreciated that the various systems may include additional devices, components, modules, etc. and/or may not include all of the devices, components, modules etc. discussed in connection with the figures. Furthermore, combinations of these schemes may also be used.

In addition, in the embodiments of the present application, words such as "exemplary," "for example," and the like are used to indicate an example, instance, or illustration. Any embodiment or design described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments or designs. Rather, the term use of an example is intended to present concepts in a concrete fashion.

In the embodiment of the present application, "information", "signal", "message", "channel", and "signaling" may be used in a mixed manner, and it should be noted that the meaning of the expression is matched when the distinction is not emphasized. "of", "corresponding" and "corresponding" are sometimes used in combination, and it should be noted that the meanings to be expressed are matched when the distinction is not emphasized. Furthermore, references to "/" herein may be used to indicate a relationship of "or".

The network architecture and the service scenario described in the embodiments of the present application are for more clearly describing the technical solution of the embodiments of the present application, and do not constitute a limitation on the technical solution provided in the embodiments of the present application, and those skilled in the art can know that, with the evolution of the network architecture and the appearance of the new service scenario, the technical solution provided in the embodiments of the present application is also applicable to similar technical problems.

To facilitate understanding of the embodiments of the present application, a communication system suitable for the embodiments of the present application will be described in detail first with reference to the communication system shown in fig. 5 as an example. Fig. 5 is a schematic diagram of an architecture of a communication system to which the communication method according to the embodiment of the present application is applicable.

As shown in fig. 5, the communication system may be applied to the above-mentioned 4G architecture, 4G-5G fusion architecture or dual connectivity architecture, and mainly includes: RAN device and MME. The RAN device may be an eNB in the above-mentioned 4G architecture or 4G-5G convergence architecture, or an SN in the above-mentioned dual-connection architecture, which is not specifically limited in this application. The related functions of the RAN device and MME may refer to related descriptions in the above-mentioned 4G architecture, 4G-5G convergence architecture, and dual connectivity architecture, which are not described herein. In the communication system of the embodiment of the application, the RAN device and the MME can perform signaling interaction. For example, the RAN apparatus may send a message to the MME to indicate whether the RAN apparatus has an UP IP to turn on a corresponding UP IP, e.g., an E-UTRAN radio access bearer (E-UTRAN radio access bearer, E-RAB) corresponding to a session of the terminal. Thus, in case the UP IP of the E-RAB needs to be turned on, if the RAN device does not turn on the UP IP of the E-RAB, the MME instructs the RAN device to release the E-RAB to avoid security risk.

It is convenient to understand that the above-mentioned interaction procedure between the RAN device and the MME will be specifically described below by way of method embodiments in connection with fig. 6-11.

The communication method provided by the embodiment of the application can be applied to the communication system and applied to various communication scenes. For example, the communication method can be applied to the scenarios of initial access, location area update, service request, bearer activation, or bearer modification in the 4G architecture. For another example, the communication method can also be applied to the scenes such as X2 HO or S1 HO in the 4G architecture. For another example, the communication method can also be applied to a 5GS > EPS HO scene in a 4G-5G fusion architecture. For example, the communication method may also be applied to SN configuration scenarios in a dual connectivity architecture, as described below.

Scene 1:

fig. 6 is a schematic flow chart of a communication method according to an embodiment of the present application. The communication method can be suitable for communication among the UE, the eNB and the MME in the scenes of initial access, tracking area update, service request and the like in the 4G architecture. As shown in fig. 6, the flow of the communication method is as follows:

s601, the UE sends an attach/tracking area update/service request (attach/(tracking area update, TAU)/service request) message to the MME. Accordingly, the MME receives an attach/tracking area update/service request message from the UE.

The attach request message is used for the UE to request an attach procedure, the tracking area update is used for updating the tracking area of the UE, and the service request message is used for requesting to establish a non-access stratum (NAS) signaling connection. For example, an attach request message is used to request an attach procedure to access the CN. Or the tracking area update request message is used for requesting the CN to update the tracking area of the UE so as to realize mobility management. Alternatively, the service request message is used to request the CN to connect the NAS signaling connection to provide services thereto.

The attach/tracking area update/service request message includes: an Identity (ID) of the UE, e.g., an international mobile subscriber identity (international mobile subscriber identity, IMSI) of the UE, or a globally unique temporary UE identity (globally unique temporary UE identity, GUTI). And, the attach/tracking area update/service request message further includes: UP IP indication information of the UE. The UP IP indication information of the UE may be any possible cell in the attach/tracking area update/service request message, for example, an EPS integrity protection algorithm (evolved packet system integrity algorithm, EIA) 7 cell in EPS security capability, to indicate whether the UE supports UP IP with EPS or does not support UP IP. For example, if EIA7 is 1, it represents that the UE supports UP IP, and if EIA7 bit 0, it represents that the UE does not support UP IP. It is understood that displaying the UP IP indication information by the UE indicates that the UE supports UP IP or does not support UP IP is only one example and is not limiting. For example, the attach/tracking area update/service request message does not carry UP IP indication information for the UE to implicitly indicate that the UE does not support UP IP.

S602, the MME sends an initial context setup request (initial context setup request) message to the eNB. Accordingly, the eNB receives an initial context setup request message from the MME.

Wherein the MME may determine the initial context setup request message based on the attach/tracking area update/service request message. The initial context setup request message is used to request the eNB to establish the context of the UE. The initial context setup request message includes: the UE context identifier (e.g., MME UE S1 application identifier (MME UE S1AP ID), denoted as context identifier 1), and the UP IP indication information of the UE may optionally further include: UP IP policy. The UE's context identity 1 and UP IP policy are: the MME locally determines or modifies the information determined when the UE's context.

Wherein the MME may locally establish or modify the UE's context according to the attach/tracking area update/service request message. Specifically, the MME may configure a corresponding context identifier 1 for the UE according to the attach/tracking area update/service request message, and configure an E-RAB corresponding to the UE for the eNB. The E-RAB is a bearer between the MME and the eNB for carrying data transmitted between the MME and the eNB, such as traffic data of the UE. The MME may also determine whether the UE supports UP IP based on the attach/tracking area update/service request message. If the UE does not support UP IP, the MME does not need to determine the UP IP policy. If the UE supports UPIP, the MME may determine the UPIP policy. For example, the MME may determine a corresponding one of the UP IP policies for each E-RAB. That is, the UP IP policy is an E-RAB granularity policy to indicate whether the UP IP of each E-RAB is forced on, recommended on, or not on. The MME may obtain an UP IP policy corresponding to each E-RAB from other network elements or locally, which is not specifically limited in this application. On this basis, the UP IP policy carried in the initial context setup request message may be an UP IP policy corresponding to the E-RAB, including, for example: the identity of each E-RAB, and the UP IP policy corresponding to the identity of the E-RAB.

Assume that 1, e-RAB includes: E-RAB1-E-RAB5, UP IP policy 1-UP IP policy 5. Each E-RAB is configured with a corresponding one of the UP IP policies, which may be shown in table 1 in the initial context setup request message.

TABLE 1

Suppose that the 2, e-RAB includes: E-RAB1-E-RAB5, UP IP policy 1-UP IP policy 2. Each of the plurality of E-RABs is configured with a corresponding one of the UP IP policies, and the UP IP policies corresponding to the E-RABs in the initial context setup request message may be as shown in table 2.

TABLE 2

Suppose that the 3, e-RAB includes: E-RAB1-E-RAB5, UP IP policy 1-UP IP policy 3. Each one or more E-RABs are configured with a corresponding one of the UP IP policies, which may be shown in table 3 in the initial context setup request message.

TABLE 3 Table 3

S603, the eNB sends an RRC reconfiguration (RRC reconfig) message to the UE. Accordingly, the UE receives an RRC reconfiguration message from the eNB.

The eNB network element may determine the RRC reconfiguration message according to the initial context setup request message. The RRC reconfiguration message is used to reconfigure corresponding radio resources for the RRC connection between the UE and the eNB. Optionally, the RRC reconfiguration message may further include: UP IP activation indication information. The UP IP activation indication information may be information determined according to the UP IP policy when the eNB locally determines or modifies the context of the UE.

Specifically, the eNB may locally establish the context of the UE according to the initial context establishment request message. For example, the eNB may configure a corresponding context identity for the UE (e.g., eNB UE S1 application identity eNB UE S1AP ID, denoted as context identity 2) according to the initial context setup request message, and configure a corresponding data radio bearer (data radio bearer, DRB) for the UE. The DRB is a bearer between the UE and the eNB for carrying data transmitted between the UE and the eNB, for example, traffic data of the UE. Optionally, the DRBs are in one-to-one correspondence with the E-RABs described above. In the case where the eNB supports UP IP (e.g., an eNB supporting UP IP after an eNB upgrade), the eNB may also determine whether the UE supports UP IP according to the initial context setup request message. If the UE does not support UPIP, the eNB does not need to determine UPIP activation indication information, and the RRC reconfiguration message does not carry the UPIP activation indication information. If the UE supports UPIP, the eNB can acquire the UPIP strategy, determine the UPIP activation indication information according to the UPIP strategy, and carry the UPIP activation indication information into the RRC reconfiguration message.

There may be 2 ways in which the eNB obtains the UP IP policy. In one mode, if the UP IP policy is carried in the initial context setup request message, the eNB acquires the UP IP policy in the initial context setup request message, so as to determine UP IP activation indication information according to the UP IP policy. Or in another way, if the UP IP policy is not carried in the initial context establishment request message, but the UE supports UP IP, the eNB acquires a locally preconfigured UP IP policy to determine the UP IP activation indication information according to the UP IP policy.

Wherein, the MME determines the UP IP activation indication information according to the UP IP strategy means that: if the UP IP policy is forced on, the UP IP activation indication information is determined to be on. If the UP IP policy is recommended to be opened, the UP IP activation indication information is determined to be opened or closed. If the UP IP policy is not on, the UP IP activation indication information is determined to be off. That is, the eNB may determine 2 states (on or off) of the UP IP according to 3 policies (forced on, recommended on, or off) of the UP IP.

It can be appreciated that, since the DRBs and the E-RABs can be in one-to-one correspondence, the UP IP activation indication information can be information of the DRB granularity on the basis of the policy that the UP IP policy is of the E-RAB granularity. That is, the eNB may determine the UP IP activation indication information of the DRB corresponding to the E-RAB, i.e., whether the UP IP of the DRB is on or off, according to whether the UP IP policy of each E-RAB is forced to be on, recommended to be on, or not to be on. On this basis, the activation indication information carried in the RRC reconfiguration message may be UP IP activation indication information corresponding to the DRB, for example, including: the identification of each DRB and the UP IP activation indication information corresponding to the DRB. The UP IP activation indication information corresponding to each DRB may have two values, which respectively indicate whether the UP IP corresponding to the DRB is turned on or off. For example, the UP IP activation indication information corresponding to each DRB is one bit (bit), and includes two values of 0 or 1. The value of 1 is used for indicating that the UPIP corresponding to the DRB is opened, or the value of UPIP activation indication information corresponding to the DRB is opened. The value of 0 is used for indicating that the UPIP corresponding to the DRB is closed, or the value of UPIP activation indication information corresponding to the DRB is UPIP closed. Or vice versa.

Continuing with assumption 1 above, E-RAB1-E-RAB5 corresponds one-to-one with DRB1-DRB 5. On the basis that the UP IP policy is shown in table 1, the UP IP activation indication information corresponding to the DRB in the RRC reconfiguration message may be: each DRB may correspond to one UP IP activation indication information as shown in table 4.

TABLE 4 Table 4

DRB identification	UP IP activation indication information
		DRB1	UP IP opening
DRB2	UP IP opening
		DRB3	UP IP shutdown
DRB4	UP IP opening
		DRB5	UP IP shutdown

Continuing with assumption 2 above, E-RAB1-E-RAB5 corresponds one-to-one with DRB1-DRB 5. On the basis that the UP IP policy is shown in table 2, the UP IP activation indication information corresponding to the DRB in the RRC reconfiguration message may be: each of the plurality of DRBs may correspond to one UP IP activation indication information as shown in table 5.

TABLE 5

Continuing with assumption 3 above, E-RAB1-E-RAB5 corresponds one-to-one with DRB1-DRB 5. On the basis that the UP IP policy is shown in table 3, the UP IP activation indication information corresponding to the DRB in the RRC reconfiguration message may be: each of the one or more DRBs may correspond to one UP IP activation indication information as shown in table 6.

TABLE 6

It should be noted that, in the case that the UP IP activation indication information corresponding to all DRBs of the UE is turned off, the eNB may still carry the UP IP activation indication information into the RRC reconfiguration message to display an indication that UP IPs corresponding to the DRBs are turned off. Alternatively, the eNB may not carry the UP IP activation indication information into the RRC reconfiguration message, so as to implicitly indicate that UP IPs corresponding to the DRBs are all turned off through the RRC reconfiguration message not carrying the UP IP activation indication information.

In addition, in the case where the eNB does not support UP IP (for example, the eNB is an unequalized eNB), the eNB cannot determine whether the UE supports UP IP according to the initial context setup request message, cannot determine UP IP activation indication information, and cannot further carry the UP IP activation indication information in the RRC reconfiguration message.

S604, the UE sends an RRC reconfiguration complete (RRC reconfig complete) message to the eNB. Accordingly, the eNB receives the RRC reconfiguration complete message from the UE.

The UE may reconfigure the RRC connection between the UE and the eNB according to the RRC reconfiguration message, thereby sending an RRC reconfiguration complete message to the eNB to indicate that the UE has completed the reconfiguration of the RRC connection. If the RRC reconfiguration message carries the UP IP activation indication information, the UE may also correspondingly turn on or off the UP IP of each DRB according to the UP IP activation indication information.

S605, the eNB sends an initial context setup response (initial context setup response) message to the MME. Accordingly, the MME receives an initial context setup response message from the eNB.

The initial context establishment response message is used for indicating that the establishment of the context of the UE is completed. The initial context setup response message includes: the context identification (e.g., context identification 1 and/or context identification 2) of the UE may optionally further include: UP IP result information.

The UP IP result information may be information determined by the eNB according to the UP IP activation indication information on the basis that the eNB supports UP IP. Because the DRB and the E-RAB are in one-to-one correspondence, the UP IP result information can be the E-RAB granularity information on the basis that the UP IP activation indication information is the DRB granularity information. That is, the eNB may determine whether the UP IP of each DRB is turned off or turned on, and the UP IP result information of one E-RAB corresponding to the DRB, that is, whether the UP IP of the E-RAB is turned on or off. On this basis, the UP IP result information carried in the initial context setup response message may be UP IP result information corresponding to the E-RAB, including, for example: the identification of each E-RAB and the corresponding UP IP result information of the E-RAB. The UP IP result information corresponding to each E-RAB may have two values, which respectively indicate whether the UP IP corresponding to the E-RAB is on or off. For example, the UP IP result information corresponding to each E-RAB is a bit, including two values of 0 or 1. The value of 1 is used for indicating that the UPIP corresponding to the E-RAB is opened, or the value of UPIP result information corresponding to the E-RAB is opened. And the value of 0 is used for indicating that the UPIP corresponding to the E-RAB is closed, or the value of UPIP result information corresponding to the E-RAB is UPIP closed. Or vice versa.

Continuing with assumption 1 above, E-RAB1-E-RAB5 corresponds one-to-one with DRB1-DRB 5. On the basis that the UP IP activation indication information is shown in table 4, UP IP result information corresponding to the E-RAB in the initial context setup response message may be: each E-RAB may correspond to one UP IP result information as shown in table 7.

TABLE 7

E-RAB identification	UP IP result information
		E-RAB1	UP IP opening
E-RAB2	UP IP opening
		E-RAB3	UP IP shutdown
E-RAB4	UP IP opening
		E-RAB5	UP IP shutdown

Continuing with assumption 2 above, E-RAB1-E-RAB5 corresponds one-to-one with DRB1-DRB 5. On the basis that the UP IP activation indication information is shown in table 5, UP IP result information corresponding to the E-RAB in the initial context setup response message may be: each of the plurality of E-RABs may correspond to one UP IP result information as shown in table 8.

TABLE 8

Continuing with assumption 3 above, E-RAB1-E-RAB5 corresponds one-to-one with DRB1-DRB 5. On the basis that the UP IP activation indication information is shown in table 6, UP IP result information corresponding to the E-RAB in the initial context setup response message may be: each one or more E-RABs may correspond to one UP IP result information as shown in table 9.

TABLE 9

It can be appreciated that, for each E-RAB, the eNB feeds back the UP IP result information corresponding to the E-RAB to the MME, regardless of whether the UP IP policy of the E-RAB is forced or recommended to be turned on or not. Therefore, if the eNB supports UP IP, the MME receives UP IP result information. Therefore, on one hand, the MME can judge whether the eNB supports the UPIP or not through whether UPIP result information is received or not, and on the other hand, the MME can know the actual situation of the UPIP of each E-RAB, and avoid the situation of misclosing or missed opening of the UPIP so as to further ensure the communication safety of a user plane.

In addition, on the basis that the eNB does not support UP IP, the eNB cannot determine whether the UE supports UP IP according to the initial context establishment request message, cannot start the UP IP corresponding to the E-RAB, and cannot carry the UP IP result information in the initial context establishment response message. That is, the initial context setup response message may correspondingly indicate whether the eNB starts UP IP corresponding to the E-RAB by carrying UP IP result information corresponding to the E-RAB. If the initial context establishment response message carries UP IP result information corresponding to the E-RAB, the initial context establishment response message is used for displaying UP IP corresponding to the E-RAB, which indicates that the eNB has started. Or if the initial context establishment response message does not carry the UP IP result information corresponding to the E-RAB, the initial context establishment response message is used for implicitly indicating that the eNB does not start the UP IP corresponding to the E-RAB.

S606, if the UP IP strategy corresponding to the E-RAB in the context of the UE is forced to be opened, and the initial context establishment response message indicates that the eNB does not open the UP IP corresponding to the E-RAB, the MME triggers the release of the E-RAB.

The MME may determine whether the UP IP on state in the context of the UE matches the UP IP on state indicated by the initial context setup response message. In this case, the UP IP policy corresponding to the E-RAB in the UE context is forced on, and the initial context setup response message instructs the eNB to turn on the UP IP corresponding to the E-RAB, that is, indicates that the two are matched. Otherwise, the UP IP strategy corresponding to the E-RAB in the context of the UE is forced to be opened, and the initial context establishment response message indicates that the eNB does not open the UP IP corresponding to the E-RAB, namely that the UE and the eNB are not matched. In this embodiment of the present application, the manner in which the MME determines whether the MME and the MME are matched may be various, which is described in detail below.

Mode a:

after receiving the initial context establishment response message, the MME can obtain the context of the UE locally from the MME according to the context identifier of the UE in the initial context establishment response message, for example, the context identifier 1, and obtain all UP IP policies corresponding to the E-RAB from the context of the UE. Then, the MME may traverse the UP IP policy corresponding to each E-RAB to determine whether the UP IP policy corresponding to the E-RAB is forced to be turned on. If the UP IP policy corresponding to the E-RAB is not forced to be turned on, for example, recommended to be turned on or not turned on, the MME stores UP IP result information corresponding to the E-RAB, and does not need to execute subsequent judgment. If the UP IP strategy corresponding to the E-RAB is forced to be started, the MME judges whether the value of the UP IP result information corresponding to the E-RAB in the initial context establishment response message is matched with the UP IP strategy corresponding to the E-RAB. If the MME determines that the UP IP policy corresponding to a certain E-RAB (marked as a first E-RAB) is forced to be turned on, but the initial context establishment response message does not have UP IP result information corresponding to the first E-RAB (in the case that the eNB does not support UP IP), the two are not matched. The eNB does not open the UPIP corresponding to the first E-RAB, and needs to release the first E-RAB so as to avoid the occurrence of safety risks. The releasing the E-RAB refers to releasing the context related to the E-RAB in the UE and the network side (e.g., MME and eNB), and the specific implementation principle may also refer to the following description related to S607, which is not repeated herein. Or if the MME determines that the UP IP strategy corresponding to a certain E-RAB (marked as a second E-RAB) is forced to be turned on, but the initial context establishment response message contains UP IP result information corresponding to the second E-RAB, and the value of the UP IP result information is UP IP turn-off (the case that the eNB turns off the UP IP by mistake), the UP IP result information and the UP IP result information are not matched. The eNB does not open the UPIP corresponding to the second E-RAB, and also needs to release the second E-RAB so as to avoid the occurrence of security risks. Or if the MME determines that the UP IP strategy corresponding to a certain E-RAB (marked as a third E-RAB) is forced to be started, but the initial context establishment response message has UP IP result information corresponding to the third E-RAB, and the value of the UP IP result information is UP IP start, the UP IP result information and the initial context establishment response message are matched. The eNB starts the UP IP corresponding to the third E-RAB, so that UP IP result information corresponding to the third E-RAB can be stored without triggering the release of the third E-RAB.

It can be understood that, because the MME only analyzes and judges the E-RAB with the UP IP strategy being forced to be opened, the running cost of the MME can be effectively saved, and the running efficiency is improved.

Optionally, after acquiring the context of the UE from the MME locally, and before acquiring the UP IP policy corresponding to the E-RAB from the context of the UE, the MME may first acquire the UP IP indication information of the UE from the context of the UE. If the UP IP indication information of the UE indicates that the UE supports UP IP, the MME acquires the UP IP strategy corresponding to the E-RAB from the context of the UE, and executes the judging flow aiming at the UP IP strategy and the UP IP result information. Otherwise, if the UP IP indication information of the UE indicates that the UE does not support UP IP, the MME does not need to consider UP IP result information or acquire the UP IP strategy corresponding to the E-RAB from the context of the UE, so that the running overhead of the MME is saved and the running efficiency is improved.

Mode B:

before receiving the initial context establishment response message, the MME can determine whether the UP IP policy corresponding to the E-RAB is forced to be opened. Optionally, the MME may determine whether the UP IP policy corresponding to the E-RAB is forced on during the process of executing S602. If the UP IP policy corresponding to the E-RAB (denoted as sixth E-RAB) is forced to be turned on, the MME may determine whether the initial context setup response message carries UP IP result information corresponding to the sixth E-RAB after receiving the initial context setup response message. If the initial context establishment response message does not carry the UP IP result information corresponding to the sixth E-RAB, it indicates that the eNB does not start UP the UP IP corresponding to the sixth E-RAB (the eNB does not support UP IP), and the sixth E-RAB needs to be released to avoid the security risk. If the initial context establishment response message carries UP IP result information corresponding to the sixth E-RAB, the MME may determine whether the value of the UP IP result information corresponding to the sixth E-RAB is UP IP on. At this time, if the value of the UP IP result information corresponding to the sixth E-RAB is turned off, it indicates that the eNB does not turn on the UP IP corresponding to the sixth E-RAB (eNB turns off the UP IP by mistake), and the sixth E-RAB needs to be released to avoid the security risk. Or if the value of the UP IP result information corresponding to the sixth E-RAB is UP IP opening, the eNB is indicated to open the UP IP corresponding to the sixth E-RAB. In this case, the MME may save UP IP result information corresponding to the sixth E-RAB without triggering release of the sixth E-RAB.

Mode C:

after receiving the initial context establishment response message, the MME can determine whether the initial context establishment response message carries UP IP result information corresponding to the E-RAB.

If the initial context setup response message does not carry the UP IP result information corresponding to the E-RAB, the MME may obtain the UE context locally from the MME and obtain the UP IP policy corresponding to the E-RAB from the UE context according to the UE context identifier in the initial context setup response message. In this way, the MME can determine whether the UP IP policy corresponding to the E-RAB is forced to be turned on. If the UP IP policy corresponding to a certain E-RAB (denoted as a fourth E-RAB) is forced to be turned on, it indicates that the eNB does not turn on the UP IP corresponding to the fourth E-RAB (in the case that the eNB does not support UP IP), and the fourth E-RAB needs to be released to avoid the security risk. However, if no UP IP policy corresponding to the E-RAB is forced to be turned on, i.e. the UP IP policy corresponding to each E-RAB is recommended to be turned on or not turned on, it means that the eNB will not have a security risk even if the UP IP corresponding to the E-RAB is not turned on. In this case, the MME may save UP IP result information corresponding to the E-RAB without triggering release of the E-RAB.

Optionally, after acquiring the context of the UE from the MME locally, and before acquiring the UP IP policy corresponding to the E-RAB from the context of the UE, the MME may first acquire the UP IP indication information of the UE from the context of the UE. If the UP IP indication information of the UE indicates that the UE supports UP IP, the MME acquires the UP IP strategy corresponding to the E-RAB from the context of the UE, and executes the process of judging whether the UP IP strategy corresponding to the E-RAB is forcedly opened. Otherwise, if the UP IP indication information of the UE indicates that the UE does not support UP IP, the MME does not need to consider UP IP result information or acquire the UP IP strategy corresponding to the E-RAB from the context of the UE, so that the running overhead of the MME is further saved, and the running efficiency is further improved.

Or, in another possible case, if the initial context setup response message carries UP IP result information corresponding to the E-RAB, the MME may determine whether the value of the UP IP result information corresponding to the E-RAB is UP IP off. If the value of the UP IP result information corresponding to the E-RAB (denoted as the fifth E-RAB) is UP IP closed, the MME may locally obtain the context of the UE from the MME according to the context identifier of the UE in the initial context setup response message, and obtain the UP IP policy corresponding to the fifth E-RAB from the context of the UE. At this time, if the UP IP policy corresponding to the fifth E-RAB is forced to be turned on, it indicates that the eNB does not turn on the UP IP corresponding to the fifth E-RAB (the case that the eNB turns off the UP IP by mistake), and the fifth E-RAB needs to be released to avoid the security risk. Or if the UP IP policy corresponding to the fifth E-RAB is recommended to be turned on or not, the eNB does not need to turn on the UP IP corresponding to the fifth E-RAB. In this case, the MME may save UP IP result information corresponding to the fifth E-RAB without triggering release of the fifth E-RAB. In addition, if the initial context establishment response message carries UP IP result information corresponding to the E-RAB and the value of the UP IP result information corresponding to each E-RAB is UP IP on, the MME can directly store the UP IP result information corresponding to each E-RAB, without analyzing and judging the UP IP result information corresponding to the E-RAB and without triggering release of the E-RAB.

It can be understood that the MME only analyzes and judges the E-RAB with the UP IP result information being UP IP closed, so that the running cost of the MME can be effectively saved, and the running efficiency is improved.

S607, the MME sends an E-RAB release instruction (E-RAB release command) message to the eNB. Accordingly, the eNB receives an E-RAB release order message from the MME.

The E-RAB release instruction message is used for indicating the eNB to release the context corresponding to the E-RAB without opening the UPIP. For example, the E-RAB release instruction message carries the identifiers of the E-RABs, such as { E-RAB1, E-RAB3, E-RAB4}, so that the eNB may release the contexts corresponding to the E-RABs according to the identifiers of the E-RABs. Optionally, the released context includes: and the resources of the air interface and the S1 interface corresponding to the E-RAB. Optionally, the eNB may send an RRC reconfiguration message to the UE according to the E-RAB release instruction message, where the RRC reconfiguration message includes a DRB identifier that needs to be released, so that the UE releases an air interface resource corresponding to the DRB identifier. The DRB identifiers and the E-RAB identifiers carried in the E-RAB release instruction message may be in one-to-one correspondence, for example { DRB1, DRB3, DRB4}. Optionally, the E-RAB release instruction message also carries NAS signaling. For example, NAS signaling is a deactivate EPS bearer context request (deactivate EPS bearer context request) message. The de-activate EPS bearer context request message may include an EPS bearer identifier corresponding to the E-RAB. After receiving the E-RAB release instruction message, the eNB may transparently transmit the context deactivation request message to the UE, so that the UE releases the context of the corresponding EPS bearer according to the EPS bearer identifier in the context deactivation request message.

S608, the eNB sends an E-RAB release response (E-RAB release response) message to the MME. Accordingly, the MME receives an E-RAB release response message from the eNB.

After releasing the context corresponding to the E-RAB according to the E-RAB release instruction message, the eNB may send an E-RAB release response message to the MME to indicate that the release is completed.

S609, the MME sends an attach/tracking area update/service response (attach/TAU/service response) message to the UE. Accordingly, the UE receives an attach/tracking area update/service response message from the MME.

The attach/tracking area update/service response message is used to respond to the attach/tracking area update/service request message in S601 to indicate that the procedure corresponding to the attach/tracking area update/service request message is completed.

According to the technical solution introduced in scenario 1, it can be known that, since the initial context establishment response message may indicate whether the eNB starts UP IP corresponding to the E-RAB by carrying UP IP result information corresponding to the E-RAB. Under the condition that the UP IP corresponding to the E-RAB is forced to be opened, but the eNB does not actually open the UP IP corresponding to the E-RAB, the MME can establish a response message according to the initial context to determine that the UP IP corresponding to the E-RAB is not opened, so that the eNB can be instructed to release the E-RAB, the safety risk is avoided, and the communication safety of a user plane is ensured. In addition, since the initial context establishment response message only needs to use one cell to indicate whether the eNB starts the UPIP corresponding to the E-RAB (and also implicitly indicates whether the eNB supports the UPIP), the writing of the protocol is more friendly, a new cell is not required to be defined, and the situation of redundant cells is avoided. Furthermore, in the case that the UP IP corresponding to the E-RAB is not turned on, the eNB may release the E-RAB according to the indication of the MME, regardless of whether the eNB supports the UP IP, thereby solving the problem. Therefore, the technical scheme has low requirements on eNB configuration, and can be flexibly applied to various scenes, such as a scene of dynamic addition of the eNB or a scene of static configuration of the eNB.

Scene 2:

fig. 7 is a schematic flow chart of a communication method according to an embodiment of the present application. The communication method can be suitable for communication among the UE, the eNB and the MME under the scenes of bearing activation or bearing modification in the 4G architecture and the like. As shown in fig. 7, the flow of the communication method is as follows:

s701, the MME sends an E-RAB setup/modification request (E-RAB setup/modification request) message to the eNB. Accordingly, the eNB receives an E-RAB setup/modification request message from the MME.

The E-RAB establishment request message is used for the MME to request the eNB to establish the bearer, and the E-RAB modification request message is used for the MME to request the eNB to modify the bearer. For example, the E-RAB setup request message is used for the MME to request to set up and activate a new E-RAB, such as allocating resources of the air interface and S1 interface for the new E-RAB. Or, the E-RAB modification request message is used for the MME to request the eNB to modify the existing E-RAB, such as modifying the resources of the existing E-RAB allocation air interface and S1 interface.

It may be appreciated that, the MME may pre-store the context of the UE, and the MME may carry in the E-RAB establishment/modification request message according to the context of the UE: the UE's context identity (e.g., context identity 1 and/or context identity 2), and the UP IP policy, i.e., the UP IP policy corresponding to the E-RAB. The specific implementation principle of the UE context identifier may refer to the related description in S602-S603, and the specific implementation principle of the UP IP policy may refer to the related description in S602, which is not repeated.

S702, the eNB sends an RRC reconfiguration message to the UE. Accordingly, the UE receives an RRC reconfiguration message from the eNB.

The eNB network element may determine the RRC reconfiguration message according to the E-RAB establishment/modification request message. The RRC reconfiguration message is used to reconfigure corresponding radio resources for the RRC connection between the UE and the eNB. Optionally, the RRC reconfiguration message may further include: the specific implementation principle of the UP IP activation indication information may refer to the description related to S603, and will not be described again.

S703, the UE sends an RRC reconfiguration complete message to the eNB. Accordingly, the eNB receives the RRC reconfiguration complete message from the UE.

The specific implementation principle of S703 may refer to the related description in S604, and will not be described again.

S704, the eNB sends an E-RAB setup/modification response (E-RAB setup/modification) message to the MME. Accordingly, the MME receives an E-RAB setup/modification response message from the eNB.

Wherein the E-RAB establishment/modification response message is used for notifying completion of the E-RAB establishment/modification. The E-RAB setup/modification response message includes: the UE's context identity (e.g., context identity 1 and/or context identity 2). Optionally, the E-RAB setup/modification response message may further include: UP IP result information, i.e., UP IP result information corresponding to E-RAB. In addition, the specific implementation principle of the context identifier of the UE may refer to the related description in S602-S603, and the specific implementation principle of the UP IP result information may refer to the related description in S605, which is not repeated.

It is understood that, similar to S605 described above, the E-RAB setup/modification response message may also correspondingly indicate whether the eNB turns on the UP IP corresponding to the E-RAB by carrying UP IP result information corresponding to the E-RAB. If the E-RAB establishment/modification response message carries UP IP result information corresponding to the E-RAB, the E-RAB establishment/modification response message is used for displaying UP IP corresponding to the E-RAB, which indicates that the eNB has started. Or if the E-RAB establishment/modification response message does not carry the UP IP result information corresponding to the E-RAB, the E-RAB establishment/modification response message is used for implicitly indicating that the eNB does not start the UP IP corresponding to the E-RAB.

S705, if the UP IP policy corresponding to the E-RAB is forced on in the context of the UE, and the E-RAB setup/modification response message indicates that the eNB does not start the UP IP corresponding to the E-RAB, the MME triggers the E-RAB release.

S706, the MME sends an E-RAB release instruction message to the eNB. Accordingly, the eNB receives an E-RAB release order message from the MME.

S707, the eNB sends an E-RAB release response message to the MME. Accordingly, the MME receives an E-RAB release response message from the eNB.

The specific implementation principles of S705 to S707 may refer to the related descriptions in S606 to S608, and will not be described in detail.

In addition, the technical effects of the technical solutions of the above scenario 2 may refer to the technical effects of the technical solutions of the above scenario 1, which are not described herein.

Scene 3:

fig. 8 is a schematic flow chart of a communication method according to an embodiment of the present application. The communication method can be suitable for communication among the UE, the source eNB, the target eNB and the MME in an X2 HO scene in a 4G architecture. As shown in fig. 8, the flow of the communication method is as follows:

s801, the source eNB sends a handover request message to the target eNB. Accordingly, the target eNB receives a handover request message from the source eNB.

The handover request message is used for the source eNB to request handover of the UE to the target eNB. For example, the source eNB finds that the UE has reduced to some extent the signal strength in its own cell. The source eNB can select a base station with better signal strength from the base stations to be selected as a target eNB according to the signal measurement result of the UE, so as to send a switching request message to the target eNB.

It may be appreciated that the source eNB may store the context of the UE in advance, and the source eNB may carry the UP IP indication information of the UE in the handover request message according to the context of the UE. The specific implementation principle of the UP IP indication information of the UE may refer to the description related to S601, and will not be described again. Optionally, the source eNB may also carry an UP IP policy in the handover request message, that is, an UP IP policy corresponding to the E-RAB. The specific implementation principle of the UP IP policy corresponding to the E-RAB may refer to the description related to S602, which is not repeated.

S802, the target eNB sends a handover request confirm message to the source eNB. Accordingly, the source eNB receives the handover request confirm message from the target eNB.

The target eNB may determine the handover request acknowledgement message according to the handover request message. The handover request confirm message is used to instruct the target eNB to confirm that the UE can handover to its own cell.

The handover request confirm message may include, on the basis that the target eNB supports UP IP: UP IP activation indication information, that is, UP IP activation indication information corresponding to DRB. The UP IP activation indication information may be information determined by the target eNB according to an UP IP policy. There may be 2 ways for the target eNB to acquire the UP IP policy. In one mode, if the UP IP policy is carried in the handover request message, the eNB acquires the UP IP policy in the handover request message, so as to determine UP IP activation indication information according to the UP IP policy. Or in another mode, if the UP IP policy is not carried in the handover request message, but the UE supports UP IP, the target eNB acquires a locally preconfigured UP IP policy to determine the UP IP activation indication information according to the UP IP policy. In addition, the specific implementation principle of the UP IP activation indication information may refer to the description related to S603, which is not repeated.

Optionally, the eNB may also construct an RRC reconfiguration message and encapsulate the RRC reconfiguration message in the handover request confirm message, i.e. the handover request confirm message also includes the RRC reconfiguration message. In this way, the UP IP activation indication information may be directly encapsulated in the RRC reconfiguration message to facilitate transparent transmission.

On the basis that the target eNB does not support UPIP, the target eNB cannot determine UPIP activation indication information and cannot carry the UPIP activation indication information in a handover request confirmation message.

S803, the source eNB sends an RRC reconfiguration message to the UE. Accordingly, the UE receives an RRC reconfiguration message from the source eNB.

The source eNB can transparently transmit an RRC reconfiguration message to the UE according to the handover request confirm message to instruct the UE to reconfigure the RRC connection for handover to the target eNB. Optionally, the RRC reconfiguration message may further include: the specific implementation principle of the UP IP activation indication information may refer to the related description in S603, which is not repeated.

S804, the UE transmits an RRC reconfiguration complete message to the target eNB. Accordingly, the target eNB receives the RRC reconfiguration complete message from the UE.

The UE may determine an RRC reconfiguration complete message according to the RRC reconfiguration message and send the RRC reconfiguration complete message to the target eNB to switch to the target eNB when the UE has completed the reconfiguration of the RRC connection. In addition, if the RRC reconfiguration message carries UP IP activation indication information, that is, UP IP activation indication information corresponding to the DRBs, the UE may also correspondingly turn on or turn off UP IP of each DRB according to the UP IP activation indication information. In addition, the specific implementation principle of the UP IP activation indication information may refer to the description related to S603, which is not repeated.

S805, the target eNB sends a path switch request (path switch request) message to the MME. Correspondingly, the MME receives a path switch request message from the target eNB.

The target eNB may determine a path switch request message from the RRC reconfiguration complete message to instruct the MME to change the path of the UE, e.g., from the UE-source eNB to the UE-target eNB.

The path switch request message may include: the context identification of the UE (e.g., context identification 1 and/or context identification 2), optionally, may further include: UP IP result information, i.e., UP IP result information corresponding to E-RAB. The context identity of the UE may be an identity obtained by the target eNB from the source eNB. The specific implementation principle of the context identifier of the UE may refer to the related description in S602-S603, and the specific implementation principle of the UP IP result information may refer to the related description in S605, which is not repeated.

It is understood that, similar to S605 described above, the path switch request message may also correspondingly indicate whether the target eNB starts UP IP corresponding to the E-RAB by carrying UP IP result information corresponding to the E-RAB. If the path switching request message carries UP IP result information corresponding to the E-RAB, the path switching request message is used for displaying and indicating that the target eNB starts UP IP corresponding to the E-RAB. Or if the path switching request message does not carry the UP IP result information corresponding to the E-RAB, the path switching request message is used for implicitly indicating that the target eNB does not start the UP IP corresponding to the E-RAB.

S806, if the UP IP strategy corresponding to the E-RAB in the context of the UE is forced to be started, and the path switching request message indicates that the target eNB does not start the UP IP corresponding to the E-RAB, the MME triggers the release of the E-RAB.

It can be appreciated that the MME maintains the context of the UE in advance, and the MME may perform S806 described above according to the context of the UE. The specific implementation principle of S806 may refer to the related description in S606, and will not be described again.

S807, the MME sends a path switch request acknowledgement (path switch request ACK) message to the target eNB. Accordingly, the target eNB receives the path switch request confirm message from the MME.

The MME may determine a path switch request acknowledgement message according to the path switch request message, to indicate that path switching of the UE is completed. Since the path switch request message itself has a function of releasing the E-RABs, the MME may further include a corresponding E-RAB identifier in the path switch request message to instruct the target eNB to release the E-RABs.

Alternatively, the target eNB may send an RRC reconfiguration message to the UE based on the E-RAB identity. The RRC reconfiguration message contains the DRB identifier to be released, so that the UE releases the air interface resource corresponding to the DRB identifier. Wherein, the DRB identifiers are in one-to-one correspondence with the E-RAB identifiers carried in the E-RAB release instruction message. The specific implementation principle of the RRC reconfiguration message may refer to the description related to S607, and will not be repeated.

Optionally, the MME may also send an E-RAB release order message to the target eNB. Accordingly, the target eNB receives an E-RAB release order message from the MME. The E-RAB release instruction message includes corresponding E-RAB identifiers for instructing the target eNB to release the E-RAB. After that, the target eNB may send an E-RAB release response message to the MME after completing the release according to the E-RAB release command message. Accordingly, the MME receives an E-RAB release response message from the target eNB. The E-RAB release response message may be used to indicate that the target eNB has released to completion. In addition, the specific implementation principles of the E-RAB release instruction message and the E-RAB release response message may refer to the relevant descriptions in S607 and S608, and will not be repeated.

Optionally, the MME may also send a deactivate EPS bearer context request message to the UE. Accordingly, the UE may receive a deactivate EPS bearer context request message from the MME to release the EPS bearer corresponding to the E-RAB according to the deactivate EPS bearer context request message. The specific implementation principle of the deactivation EPS bearer context request message may refer to the description related to S607, and will not be described in detail.

In addition, the technical effects of the technical solution of the above scenario 3 may refer to the technical effects of the technical solution of the above scenario 1, which is not described herein.

Scene 4:

fig. 9 is a schematic flow chart of a communication method according to an embodiment of the present application. The communication method can be suitable for communication among the UE, the source base station, the target eNB, the source MME and the target MME in an S1 HO scene in a 4G architecture, or suitable for the UE, the source base station, the target eNB, the source AMF network element and the target MME in a 5GS > EPS HO scene in a 4G-5G fusion architecture. As shown in fig. 9, the flow of the communication method is as follows:

s901, a source base station sends a switching requirement message to a source core network element. Correspondingly, the source core network element receives a handover required message from the source base station.

In an S1 HO scene in a 4G architecture, a source base station is a source eNB, and a source core network element is a source MME. In a 5GS > EPS HO scene in a 4G-5G fusion architecture, a source base station is a source ng-eNB or a source gNB, and a source core network element is a source AMF network element.

It can be appreciated that, since the source base station stores the context of the UE in advance, the source base station may carry, in the handover required message, relevant information of the UE according to the context of the UE, so as to request handover of the UE to the corresponding target eNB. For example, the handover required message may include: a context identification of the UE (e.g., context identification 1 and/or context identification 2), and container (container) information. The container may be a transparent container (e.g., source eNB to target eNB transparent container) between the source base station to the target eNB, i.e., the container information is not parsed by intermediate network elements (e.g., source MME/source AMF network elements, target MME) during the transfer process. Alternatively, the container information may include: the UP IP strategy is the UP IP strategy corresponding to the E-RAB. The UP IP policy is a policy obtained by the source base station from the locally stored context of the UE, and the specific implementation principle may refer to the related description in S602, which is not described in detail.

S902, the source core network element sends a relocation request message to the target MME. Correspondingly, the target MME receives a relocation request message from the source core network element.

The source core network element may determine the relocation request message according to the handover requirement message. The relocation request message is used to request transfer of the UE context from the source core network element to the target MME.

It can be appreciated that the context of the UE is pre-saved due to the source core network element. The source core network element may obtain the context of the UE according to the context identifier of the UE in the handover required message. In this way, the source core network element may also carry, according to the context of the UE, relevant information of the UE in the relocation request message, so as to request handover of the UE to the corresponding target eNB. For example, the relocation request message may include: UP IP indication information of the UE, and container information. The specific implementation principle of the UP IP indication information of the UE may refer to the description related to S601, and will not be described again. Optionally, the relocation request message may include: the UP IP strategy is the UP IP strategy corresponding to the E-RAB. The UP IP policy is a policy obtained by the source core network element from the locally stored context of the UE, and the specific implementation principle may refer to the related description in S602, which is not described herein.

S903, the target MME sends a handover request message to the target eNB. Accordingly, the target eNB receives a handover request message from the target MME.

The handover request message is used to request handover of the UE to the target eNB. The target MME may determine the handover request message from the relocation request message. As such, the handover request message may include: UP IP indication information of the UE, and container information. The specific implementation principle of the UP IP indication information of the UE may refer to the description related to S601, and will not be described again. Optionally, the handover request message may include: the UP IP strategy is the UP IP strategy corresponding to the E-RAB. The specific implementation principle of the UP IP policy may refer to the related description in S602, and will not be described again.

S904, the target eNB sends a handover request confirm message to the target MME. Accordingly, the target MME receives the handover request confirm message from the target eNB.

The target eNB may determine a handover request confirm message from the handover request message. The handover request confirm message is used to indicate that the UE may handover to the target eNB.

The handover request confirm message may include, on the basis that the target eNB supports UP IP: a context identity of the UE (e.g., context identity 1 and/or context identity 2), and an RRC reconfiguration message. The context identity of the UE may be obtained by the target eNB from the target MME. The specific implementation principle of the context identifier of the UE may refer to the related description in S602-S603, and will not be described in detail. The RRC reconfiguration message may include: UP IP activation indication information, that is, UP IP activation indication information corresponding to DRB. The UP IP activation indication information may be information determined by the target eNB according to an UP IP policy.

There may be 3 ways for the target eNB to obtain the UP IP policy. In one mode, if the UP IP policy is directly carried in the handover request message, the eNB acquires the UP IP policy in the handover request message, so as to determine UP IP activation indication information according to the UP IP policy. Or in another mode, if the UP IP policy is not directly carried in the handover request message, but the UP IP policy is carried in the handover request message, and the UP IP policy is contained in the container information, the target eNB acquires the UP IP policy from the container information, so as to determine UP IP activation indication information according to the UP IP policy. Or in another mode, if the UP IP policy is not directly carried in the handover request message, and container information is not carried, but the UE supports UP IP, the target eNB acquires a locally preconfigured UP IP policy to determine the UP IP activation indication information according to the UP IP policy. In addition, the specific implementation principle of the UP IP activation indication information may refer to the description related to S603, which is not repeated.

Optionally, the handover request acknowledgement message may further include: UP IP result information, i.e., UP IP result information corresponding to E-RAB. The specific implementation principle of the UP IP result information may refer to the related description in S605, and will not be described again.

On the basis that the target eNB does not support UP IP, the handover request confirm message may still include: UE context identity and RRC reconfiguration message. However, since the target eNB cannot determine the UP IP activation indication information and the UP IP result information, the RRC reconfiguration message does not carry the UP IP activation indication information and the handover request acknowledgement message does not carry the UP IP result information.

It will be appreciated that, similar to S605 described above, the handover request acknowledgement message may also correspondingly indicate whether the target eNB starts UP IP corresponding to the E-RAB by carrying UP IP result information, that is, UP IP result information corresponding to the E-RAB. If the path switching request message carries UP IP result information corresponding to the E-RAB, the path switching request message is used for displaying and indicating that the target eNB starts UP IP corresponding to the E-RAB. Or if the path switching request message does not carry the UP IP result information corresponding to the E-RAB, the path switching request message is used for implicitly indicating that the target eNB does not start the UP IP corresponding to the E-RAB.

S905, if the UP IP strategy corresponding to the E-RAB in the context of the UE is forced to be started, and the switching request confirmation message indicates that the target eNB does not start the UP IP corresponding to the E-RAB, the target MME triggers the release of the E-RAB.

The target MME may obtain the context of the UE according to the context identifier of the UE in the handover request confirm message. As such, the MME may perform S905 described above according to the context of the UE. The specific implementation principle of the above S905 may refer to the related description in the above S606, and will not be described again.

S906, the target MME sends a relocation response message to the source core network element. Correspondingly, the source core network element receives the relocation response message from the target MME.

The target MME may determine a relocation response message from the handover request confirm message. The relocation response message is used to indicate that the UE may handover to the target eNB. Optionally, the relocation response message may include: RRC reconfiguration message. The RRC reconfiguration message is the message acquired by the target MME in S904, that is, the target MME transparently transmits the RRC reconfiguration message. Optionally, the RRC reconfiguration message may include: UP IP activation indication information, that is, UP IP activation indication information corresponding to DRB. The specific implementation principle of the UP IP activation indication information may refer to the description related to S603, which is not repeated.

S907, the source core network element sends a switching instruction message to the source base station. Correspondingly, the source base station receives a handover instruction message from a source core network element.

The source core network element may determine the handover instruction message according to the relocation response message. The handover instruction message is used to indicate that the UE may handover to the target eNB. Optionally, the handover instruction message may include: RRC reconfiguration message. The RRC reconfiguration message is the message acquired by the source core network element in S906, that is, the source core network element transparently transmits the RRC reconfiguration message. Optionally, the RRC reconfiguration message may include: UP IP activation indication information, that is, UP IP activation indication information corresponding to DRB. The specific implementation principle of the UP IP activation indication information may refer to the description related to S603, which is not repeated.

S908, the source base station sends an RRC reconfiguration message to the UE. Accordingly, the UE receives an RRC reconfiguration message from the source base station.

The source base station may determine, according to the handover instruction message, that the UE may be handed over to the target eNB. In this way, the source eNB may send an RRC reconfiguration message in the handover command message to the UE to instruct the UE to reconfigure the RRC connection to handover to the target eNB. Optionally, the RRC reconfiguration message may further include: the specific implementation principle of the UP IP activation indication information may refer to the related description in S603, which is not repeated.

S909, the UE sends an RRC reconfiguration complete message to the target eNB. Accordingly, the target eNB receives the RRC reconfiguration complete message from the UE.

The UE may determine an RRC reconfiguration complete message according to the RRC reconfiguration message and send the RRC reconfiguration complete message to the target eNB to indicate that the UE has completed the reconfiguration of the RRC connection, thereby switching to the target eNB. In addition, if the RRC reconfiguration message carries UP IP activation indication information, that is, UP IP activation indication information corresponding to the DRBs, the UE may also correspondingly turn on or turn off UP IP of each DRB according to the UP IP activation indication information. In addition, the specific implementation principle of the UP IP activation indication information may refer to the description related to S603, which is not repeated.

S910, the target eNB sends a handover complete (handover notify) message to the target MME. Accordingly, the target MME receives the handover complete message from the target eNB.

The target eNB determines that the UE is handed over to its own cell according to the RRC reconfiguration complete message, then the target eNB may send a handover complete message to the target MME to inform that the handover is complete.

S911, the target MME sends an E-RAB release instruction message to the target eNB. Accordingly, the target eNB receives an E-RAB release order message from the target MME.

S912, the target eNB sends an E-RAB release response message to the target MME. Accordingly, the target MME receives an E-RAB release response message from the target eNB.

The specific implementation principles of S911-S912 may refer to the related descriptions in S606-S608, and will not be described again.

It is noted that S911-S912 may be performed after the target MME confirms that the handover is completed, for example, after S910. Therefore, the situation that the target eNB does not acquire the configuration information of the corresponding E-RAB yet can be avoided, and the target MME indicates to release the E-RAB, so that the E-RAB release failure is caused, the target MME can be ensured to successfully release the E-RAB, and the communication safety of a user plane is ensured.

In addition, the technical effects of the technical solutions of the above scenario 4 may refer to the technical effects of the technical solutions of the above scenario 1, which are not described herein.

Scene 5:

fig. 10 is a schematic flow chart of a communication method according to an embodiment of the present application. The communication method can be suitable for communication between UE, meNB, SN and MME in the SN configuration scene in the dual-connection architecture. The dual-connection architecture may refer to the related description in the above-mentioned 4, dual-connection architecture, and will not be repeated. As shown in fig. 10, the flow of the communication method is as follows:

S1001, the MeNB sends a SgNB/SeNB addition request (SgNB/SeNB addition request) message to the SN. Accordingly, the SN receives the SgNB/SeNB addition request message from the MeNB.

Wherein, the MeNB is a master eNB, that is, a master node, and the SN is a slave node. The SN may be a SgNB, i.e. a secondary gcb, or the SN may be a SeNB, i.e. a secondary eNB. The SgNB add request message is used to request the SgNB to provide services for the UE. The SeNB addition request message is used to request the SeNB to provide services for the UE.

It can be appreciated that, since the MeNB stores the context of the UE in advance, the MeNB may carry, in the SgNB/SeNB addition request, relevant information of the UE according to the context of the UE, so as to request the SN to provide services for the UE. For example, the SgNB/SeNB addition request may include: the specific implementation of the UP IP indication information of the UE may refer to the related description in S601, which is not described herein. Optionally, the SgNB/SeNB addition request may further include: the specific implementation of the UP IP policy, that is, the UP IP policy corresponding to the E-RAB, may refer to the description related to S602, and will not be described again.

S1002, the SN sends a SgNB/SeNB addition request acknowledgement (SgNB/SeNB addition request ACK) message to the MeNB. Correspondingly, the MeNB receives the SgNB/SeNB addition request confirmation message from the SN.

The SN may determine a SgNB/SeNB addition request acknowledgement message from the SgNB/SeNB addition request message. The handover request confirm message is used to indicate that the SN may serve the UE.

On the basis that the SN supports UPIP, the SgNB/SeNB addition request confirmation message can comprise: RRC reconfiguration message. The RRC reconfiguration message may include: UP IP activation indication information, that is, UP IP activation indication information corresponding to DRB. The UP IP activation indication information may be information determined by the SN according to an UP IP policy. There may be 2 ways for the SN to obtain the UP IP policy. In one mode, if the UP IP policy is carried in the SgNB/SeNB addition request message, the SN obtains the UP IP policy in the SgNB/SeNB addition request message, so as to determine UP IP activation indication information according to the UP IP policy. Or in another mode, if the UP IP policy is not carried in the SgNB/SeNB addition request message, but the UE supports UP IP, the SN acquires a locally preconfigured UP IP policy to determine the UP IP activation indication information according to the UP IP policy. In addition, the specific implementation principle of the UP IP activation indication information may refer to the description related to S603, which is not repeated.

Optionally, the gNB/SeNB addition request confirmation message may further include: UP IP result information, i.e., UP IP result information corresponding to E-RAB. The specific implementation principle of the UP IP result information may refer to the related description in S605, and will not be described again.

On the basis that the SN does not support UP IP, the SgNB/SeNB addition request acknowledgement message may still include: RRC reconfiguration message. However, since SN cannot determine UP IP activation indication information and UP IP result information, RRC reconfiguration message does not carry UP IP activation indication information, and SgNB/SeNB addition request acknowledgement message does not carry UP IP result information.

S1003, the MeNB sends an RRC reconfiguration message to the UE. Accordingly, the UE receives an RRC reconfiguration message from the MeNB.

After receiving the gNB/SeNB addition request confirmation message, the MeNB transparently transmits an RRC reconfiguration message in the gNB/SeNB addition request confirmation message to the UE, and the RRC reconfiguration message is used for indicating the UE to reconfigure RRC connection so as to access the SN.

S1004, the UE sends an RRC reconfiguration complete message to the MeNB. Accordingly, the MeNB receives the RRC reconfiguration complete message from the UE.

The UE may determine an RRC reconfiguration complete message according to the RRC reconfiguration message, and send the RRC reconfiguration complete message to the target eNB to indicate that the UE has completed the reconfiguration of the RRC connection, and may access the SN.

S1005, the MeNB sends a SgNB/SeNB reconfiguration complete (SgNB/SeNB reconfiguration complete) message to the SN. Accordingly, the SN receives the SgNB/SeNB reconfiguration complete message from the MeNB.

After receiving the RRC reconfiguration complete message, the MeNB may carry the RRC reconfiguration complete message to the SgNB/SeNB reconfiguration complete message to notify the SN that the reconfiguration is complete.

S1006, the MeNB sends an E-RAB modification indication (E-RAB modification indication) message to the MME. Correspondingly, the MME receives an E-RAB modification indication message from the MeNB.

After the MeNB determines that the reconfiguration is completed, i.e., after S1104, an E-RAB modification instruction may be sent to the MME to instruct the MME to modify the corresponding E-RAB. For example, the E-RAB-MeNB is modified to E-RAB-SN.

The E-RAB modification indication message may include: the UE's context identity (e.g., context identity 1 and/or context identity 2). The UE context identity is an identity obtained by the MeNB from a pre-stored UE context. The specific implementation principle of the context identifier of the UE may refer to the related description in S602-S603, and will not be described in detail. Optionally, the E-RAB modification indication message may further include: the UP IP result information obtained in S1102, that is, the UP IP result information corresponding to the E-RAB. The E-RAB is the E-RAB corresponding to the SN.

It is understood that, similar to S605 described above, the E-RAB modification indication message may also correspondingly indicate whether the SN turns on the UP IP corresponding to the E-RAB by carrying UP IP result information corresponding to the E-RAB. If the E-RAB modification indication message carries UP IP result information corresponding to the E-RAB, the E-RAB modification indication message is used for displaying indication that the SN has started UP IP corresponding to the E-RAB. Or if the E-RAB modification indication message does not carry the UP IP result information corresponding to the E-RAB, the E-RAB modification indication message is used for implicitly indicating that the SN does not start the UP IP corresponding to the E-RAB.

S1007, if the UP IP strategy corresponding to the E-RAB in the context of the UE is forced to be started, and the E-RAB modification indication message indicates that the SN does not start the UP IP corresponding to the E-RAB, the MME triggers the release of the E-RAB.

The MME can acquire the context of the UE according to the context identifier of the UE in the E-RAB modification indication message. As such, the MME may perform S1107 described above according to the context of the UE. The specific implementation principle of the above S1107 may refer to the related description in the above S606, and will not be described again.

S1008, the MME sends an E-RAB release instruction message to the MeNB. Correspondingly, the MeNB receives an E-RAB release order message from the MME.

The MME may also send a SgNB/SeNB modification request (SgNB/SeNB modification request) message to the SN according to the E-RAB release instruction message, to request the SN to release the corresponding E-RAB, e.g. E-RAB with UP IP not turned on.

S1009, the MeNB sends an E-RAB release response message to the MME. Accordingly, the MME receives an E-RAB release response message from the MeNB.

The specific implementation principles of the above S1008-S1009 may refer to the related descriptions in the above S606-S608, and will not be repeated.

In addition, the technical effects of the technical solutions of the above scenario 5 may refer to the technical effects of the technical solutions of the above scenario 1, which are not described herein.

The specific flow of the communication method provided in the embodiment of the present application under each scenario is described above in connection with scenario 1-scenario 5. The overall flow of the communication method provided in the embodiment of the present application in each scenario is described below with reference to fig. 11.

Fig. 11 is a schematic flow chart of a communication method according to an embodiment of the present application. The communication method can be applied to the communication between the RAN equipment and the MME in the communication system. The RAN device may be an eNB in the above scenario 1 or scenario 2, and correspondingly, the MME may be an MME in the above scenario 1 or scenario 2. Alternatively, the RAN device may be the target eNB in scenario 3 above, and correspondingly, the MME may be the MME in scenario 3 above. Alternatively, the RAN device may be the target eNB in scenario 4 above, and correspondingly, the MME may be the target MME in scenario 4 above. Alternatively, the RAN device may be SN in the above scenario 5, and correspondingly, the MME may be MME in the above scenario 5.

As shown in fig. 11, the flow of the communication method is as follows:

s1101, the RAN device sends an UP IP acknowledgement message to the MME. Accordingly, the MME receives an UP IP acknowledgement message from the RAN device.

The UP IP confirmation message is used for indicating whether the RAN equipment starts UP IP corresponding to the E-RAB. The E-RAB is an E-RAB corresponding to a terminal, and is used for carrying data transmitted between the RAN device and the MME, for example, service data of the terminal. The specific implementation principle of the E-RAB may refer to the related description in the above scenario 1-scenario 5, and will not be described again.

In one possible approach, an UP IP acknowledgement message may be used to display an UP IP indicating whether the RAN device is on for the E-RAB. For example, the UP IP acknowledgement message carries UP IP result information corresponding to the E-RAB. The UP IP result information corresponding to the E-RAB is used to indicate whether the UP IP corresponding to the E-RAB is on or off. Thus, through the UP IP result information corresponding to the E-RAB, it is possible to display an indication indicating whether the RAN device opens UP IP corresponding to the E-RAB. The result information corresponding to the E-RAB may be information determined by the RAN device according to the UP IP policy corresponding to the E-RAB. The UP IP policy corresponding to the E-RAB may be a policy acquired by the RAN device from other devices. For example, in the above scenario 1 or scenario 2, the UP IP policy corresponding to the E-RAB is acquired from the MME. For another example, in scenario 3 or scenario 4, the UP IP policy corresponding to the E-RAB is acquired from the source base station. For another example, in scenario 5, the UP IP policy corresponding to the E-RAB is acquired from the MeNB. In addition, the result information corresponding to the E-RAB and the specific implementation principle of the UP IP policy corresponding to the E-RAB may refer to the related description in the above scenario 1-scenario 5, which is not described again.

In another possible manner, the UP IP acknowledgement message may be used to implicitly indicate whether the RAN device turns on the UP IP corresponding to the E-RAB. For example, the UP IP acknowledgement message does not carry UP IP result information corresponding to the E-RAB, so as to implicitly indicate that the RAN device does not turn on the UP IP corresponding to the E-RAB by not carrying UP IP result information corresponding to the E-RAB.

It should be noted that, the UP IP acknowledgement message does not carry UP IP result information corresponding to the E-RAB, which generally means that: the RAN device does not support UP IP and thus cannot recognize the UP IP policy corresponding to the E-RAB. Thus, the RAN device cannot determine the UP IP result information corresponding to the E-RAB, and cannot carry the UP IP result information to the UP IP acknowledgement message. That is, whether the UP IP acknowledgement message carries UP IP result information corresponding to the E-RAB may also be used to indicate whether the RAN device supports UP IP.

It can be understood that the communication method provided in the embodiment of the present application is applied to different scenarios, and the message type of the UP IP acknowledgement message is also different. For example, the UP IP acknowledgement message may include at least one of the following: an initial context setup response message, an E-RAB setup/modification response message, a path switch request message, a switch request acknowledgement message, or an E-RAB modification indication message.

Specifically, if the communication method provided in the embodiment of the present application is applied to the scenario described in scenario 1, the UP IP acknowledgement message may be an initial context setup response message. The specific implementation principle of the initial context setup response message may refer to the related description in the above scenario 1, and will not be described again. If the communication method provided in the embodiment of the present application is applied to the scenario described in scenario 2 above, the UP IP acknowledgement message may be an E-RAB setup/modification response message. The specific implementation principle of the E-RAB setup/modification response message may refer to the related description in scenario 2, and will not be described again. If the communication method provided in the embodiment of the present application is applied to the scenario described in scenario 3, the UP IP acknowledgement message may be a path switching request message. The specific implementation principle of the path switching request message may refer to the related description in the above scenario 3, and will not be repeated. If the communication method provided in the embodiment of the present application is applied to the scenario described in scenario 4, the UP IP acknowledgement message may be a handover request acknowledgement message. The specific implementation principle of the handover request acknowledgement message may refer to the related description in the above scenario 4, and will not be described again. If the communication method provided in the embodiment of the present application is applied to the scenario described in scenario 5 above, the UP IP acknowledgement message may be an E-RAB modification indication message. The specific implementation principle of the E-RAB modification indication message may refer to the related description in the above scenario 5, and will not be described again.

In addition, the RAN device may send an UP IP acknowledgement message to the MME if the UP IP policy corresponding to the E-RAB is forced on. Alternatively, the RAN device may send an UP IP acknowledgement message to the MME if the UP IP policy corresponding to the E-RAB is not on. Or, the RAN device may also send an UP IP acknowledgement message to the MME if the UP IP policy corresponding to the E-RAB is recommended to be turned on. A specific transmission method may be: the RAN device may send an UP IP acknowledgement message to the MME based on the S1 interface. Accordingly, the MME may receive an UP IP acknowledgement message from the RAN device based on the S1 interface.

S1102, if the UP IP strategy corresponding to the E-RAB is forced to be started, and the UP IP confirmation message indicates that the RAN equipment does not start the UP IP corresponding to the E-RAB, the MME triggers the release of the E-RAB.

The MME may determine that the UP IP policy corresponding to the E-RAB is forced on, and determine that no UP IP result information corresponding to the E-RAB is in the UP IP acknowledgement message, or that UP IP result information corresponding to the E-RAB is in the UP IP acknowledgement message, and the value of the UP IP result information corresponding to the E-RAB is UP IP off. At this time, the MME triggers the release of the E-RAB. It can be understood that, in the case that the RAN device supports UP IP, the RAN device may identify an UP IP policy corresponding to the E-RAB, so that, according to the UP IP policy corresponding to the E-RAB, UP IP result information corresponding to the E-RAB is carried in an UP IP acknowledgement message to display an indication that the UP IP corresponding to the-RAB is closed. Or if the RAN device does not support UP IP, the RAN device cannot identify an UP IP policy corresponding to the E-RAB, and cannot carry UP IP result information corresponding to the E-RAB in the UP IP acknowledgement message, so as to implicitly indicate that the UP IP corresponding to the RAB is closed. That is, no matter whether the RAN device supports UP IP, when the RAN device does not start UP IP that it should start UP, the MME can trigger the RAN device to release the corresponding E-RAB according to the UP IP acknowledgement message, so as to further reduce the security risk and further ensure the communication security of the user plane.

In a first possible manner, the MME may determine whether the UP IP policy corresponding to the E-RAB is forced on. Under the condition that the UP IP strategy corresponding to the E-RAB is forced to be started, the MME can determine whether the value of the UP IP result information corresponding to the E-RAB is matched with the UP IP strategy corresponding to the E-RAB. Or, the MME may determine that there is no UP IP result information corresponding to the E-RAB in the UP IP acknowledgement message. That is, the mobility management entity only analyzes and judges the E-RAB with the UP IP policy being forced to be opened, so that the operation cost of the mobility management entity can be effectively saved, and the operation efficiency is improved. Thus, in case of mismatch, the MME triggers the release of the E-RAB.

Specifically, the MME may obtain UP IP policies corresponding to the E-RABs (e.g., all E-RABs) from the context of the terminal. The MME may determine whether an UP IP policy corresponding to the E-RAB (e.g., each E-RAB) is forced on. In the case that the UP IP policy of the E-RAB is not forced to be turned on (for example, recommended to be turned on or not turned on), the MME saves UP IP result information corresponding to the E-RAB, and does not perform subsequent judgment on the E-RAB. And under the condition that the UP IP strategy corresponding to the E-RAB is forced to be started, the UP IP confirmation message contains UP IP result information corresponding to the E-RAB, and if the value of the UP IP result information corresponding to the E-RAB is UP IP closing, the UP IP result information and the UP IP result information are not matched, and the MME triggers the release of the E-RAB. Or if the UP IP strategy corresponding to the E-RAB is forced to be started, if the UP IP result information corresponding to the E-RAB is not available in the UP IP confirmation message, the UP IP strategy and the UP IP result information are not matched, and the MME triggers the release of the E-RAB. Or if the UP IP policy corresponding to the E-RAB is recommended to be turned on or not turned on, and the UP IP result information corresponding to the E-RAB in the UP IP acknowledgement message is UP IP turned off, the two are matched, and the MME does not need to trigger the release of the E-RAB.

Or, the MME may determine whether the UP IP policy corresponding to the E-RAB is forced on in the context of the terminal. For example, when the context of the terminal is pre-established or modified, that is, before S1101, the MME may determine whether the UP IP policy corresponding to the E-RAB is forced to be turned on in the context of the terminal. On the basis, if no UP IP strategy corresponding to the E-RAB is forced to be started in the context of the terminal, the MME does not need to judge whether the RAN equipment starts the UP IP corresponding to the E-RAB or not, and the release of the E-RAB does not need to be triggered. If the UP IP strategy corresponding to the E-RAB in the context of the terminal is forced to be opened, the MME can determine whether the UP IP strategy corresponding to the E-RAB in the context of the terminal is matched with UP IP result information corresponding to the E-RAB in the UP IP confirmation message. At this time, if the UP IP acknowledgement message has UP IP result information corresponding to the E-RAB, and the UP IP result information corresponding to the E-RAB has a value of UP IP closed, or if the UP IP acknowledgement message does not have UP IP result information corresponding to the E-RAB, indicating that the two are not matched, the MME triggers release of the E-RAB. Otherwise, if the UP IP confirmation message contains UP IP result information corresponding to the E-RAB, and the value of the UP IP result information corresponding to the E-RAB is UP IP opening, which indicates that the UP IP result information and the UP IP result information are matched, the MME does not need to trigger the release of the E-RAB.

In addition, the specific implementation principles in the first possible manner may also refer to the related description of the manner a-manner B in the above scenario 1, which is not repeated.

In a second possible manner, the MME may determine whether there is UP IP result information corresponding to the E-RAB in the UP IP acknowledgement message. At this time, if the UP IP acknowledgement message has UP IP result information corresponding to the E-RAB, the MME may determine whether the value of the UP IP result information corresponding to the E-RAB matches the UP IP policy corresponding to the E-RAB. That is, the mobility management entity only analyzes and judges the E-RAB with the UP IP result information, so that the operation cost of the mobility management entity can be effectively saved, and the operation efficiency is improved. Thus, in case of mismatch, the MME triggers the release of the E-RAB.

Specifically, if the UP IP acknowledgement message includes UP IP result information corresponding to the E-RAB, the MME may determine whether the value of the UP IP result information corresponding to the E-RAB matches the UP IP policy corresponding to the E-RAB. At this time, if the value of the UP IP result information corresponding to the E-RAB in the UP IP acknowledgement message is UP IP off and the UP IP policy corresponding to the E-RAB is forced on, it indicates that the two are not matched, and the MME triggers release of the E-RAB. Otherwise, if the value of the UP IP result information corresponding to the E-RAB in the UP IP acknowledgement message is UP IP off, and the UP IP policy corresponding to the E-RAB in the context of the terminal is recommended to be on or not on, it indicates that the two are matched, and the MME does not need to trigger release of the E-RAB. However, if the UP IP result information corresponding to the E-RAB is not included in the UP IP acknowledgement message, the MME may determine whether the UP IP policy corresponding to the E-RAB is forced to be turned on in the context of the terminal. At this time, if the UP IP policy corresponding to the E-RAB is forced to be turned on in the context of the terminal, the MME triggers release of the E-RAB. Otherwise, if no UP IP policy corresponding to the E-RAB is forced to be turned on in the context of the terminal, the MME does not need to trigger release of the E-RAB. In addition, if the UP IP confirmation message contains UP IP result information corresponding to the E-RAB, and the values of the UP IP result information corresponding to the E-RAB are all UP IP start, the MME does not need to trigger the release of the E-RAB.

In addition, the specific implementation principle of the second possible manner may also refer to the description related to the manner C in the scenario 1, which is not repeated.

The MME triggering the release of the E-RAB may include: the MME sends a release message for the E-RAB to the RAN device. Accordingly, the RAN device receives a release message from the MME. And in response to the release message, the RAN equipment releases the context corresponding to the E-RAB so as to avoid the occurrence of security risk and ensure the communication security of the user plane. The specific implementation principle of the context corresponding to the RAN device E-RAB may refer to the related description in the above scenario 1, and will not be described again.

It can be appreciated that the communication method provided in the embodiments of the present application is applicable to different scenarios, and the types of the release messages are also different. For example, the release message may include at least one of the following: E-RAB release instruction message or path switching request confirmation message to realize signaling multiplexing and improve communication efficiency. Specifically, if the communication method provided in the embodiment of the present application is applied to the scenario 1, the scenario 2, the scenario 4, and the scenario 5 described in the foregoing, the E-RAB release message may be an E-RAB release instruction message. The specific implementation principle of the E-RAB release instruction message may refer to the related description in the above scenario 1-scenario 5, and will not be described again. Alternatively, if the communication method provided in the embodiment of the present application is applied to the scenario described in scenario 3, the E-RAB release message may be a path switch request acknowledgement message. The specific implementation principle of the path switch request acknowledgement message may refer to the related description in the above scenario 3, and will not be described again.

Optionally, in combination with the method shown in fig. 11, in a possible design, before the MME triggers release of the E-RAB, the MME determines that the terminal supports UP IP. For example, the MME may determine that the terminal supports UP IP before acquiring the UP IP policy corresponding to the E-RAB from the context of the terminal. For example, the MME may obtain UP IP indication information of the terminal from the context of the terminal. The UP IP indication information of the terminal may indicate that the terminal supports UP IP. In this way, the MME may continue to perform subsequent procedures to obtain the UP IP policy corresponding to the E-RAB. Of course, the UP IP indication information of the terminal may also indicate that the terminal does not support UP IP. Thus, the MME does not need to execute subsequent procedures, so that the running cost of the MME is saved, and the running efficiency is improved.

Optionally, in combination with the method shown in fig. 11, in a possible design, the UP IP acknowledgement message may further include: and the context identification of the terminal. Thus, the mobile management entity can acquire the UP IP strategy corresponding to the E-RAB from the context corresponding to the context identifier of the terminal according to the context identifier of the terminal. That is, the UP IP policy corresponding to the E-RAB may be acquired by the management entity by multiplexing the UP IP acknowledgement message to carry the context identifier of the terminal. In this way, the RAN device does not need to send the context identifier of the terminal separately, so that the communication efficiency can be improved. In addition, the specific implementation principle of the context identifier of the terminal may refer to the related description in the above scenario 1-scenario 5, which is not repeated.

In summary, in one aspect, for an MME, the UP IP acknowledgement message may indicate whether the RAN device turns on the UP IP corresponding to the E-RAB. Under the condition that the UP IP corresponding to the E-RAB is forced to be opened and the RAN equipment does not open the UP IP corresponding to the E-RAB, the MME can determine that the UP IP corresponding to the E-RAB is not opened according to the UP IP confirmation message so as to trigger the RAN equipment to release the E-RAB, thereby avoiding the occurrence of safety risk and ensuring the communication safety of a user plane.

On the other hand, for the RAN device, in the case that the UP IP corresponding to the E-RAB is forcibly turned on, if the RAN device does not turn on the UP IP corresponding to the E-RAB, the RAN device may still send an UP IP acknowledgement message to the MME to indicate that the UP IP corresponding to the E-RAB is turned off. In this way, the MME can trigger the RAN equipment to release the E-RAB, so as to avoid the occurrence of security risk and ensure the communication security of the user plane.

The communication method provided in the embodiment of the present application is described in detail above with reference to fig. 6 to 11. A communication apparatus for performing the communication method provided in the embodiment of the present application is described in detail below with reference to fig. 12 to 14.

Fig. 12 is a schematic structural diagram of a communication device according to an embodiment of the present application. As shown in fig. 12, in one embodiment, the communication apparatus 1200 may be adapted for use in the communication system shown in fig. 5, perform the functions of an eNB in the method shown in fig. 6-7, perform the functions of a target eNB in the method shown in fig. 8-9, perform the functions of an SN in the method shown in fig. 10, or perform the functions of a RAN device in the method shown in fig. 11. The communication device 1200 includes modules for performing the functions described above, such as a transceiver module 1201 and a processing module 1202. For convenience of explanation, fig. 12 shows only major components of the communication apparatus.

Wherein, the transceiver module 1201 is configured to receive a user plane integrity protection UP IP acknowledgement message from an access network device. The UP IP confirmation message indicates whether the access network equipment starts the UP IP corresponding to the E-UTRAN radio access bearer E-RAB. A processing module 1202, configured to trigger release of the E-RAB if the UP IP policy corresponding to the E-RAB is forced on and the UP IP acknowledgement message indicates that the access network device does not start UP the UP IP corresponding to the E-RAB.

In a possible design, the processing module 1202 is further configured to determine that the UP IP policy corresponding to the E-RAB is forced on, and determine that no UP IP result information corresponding to the E-RAB is in the UP IP acknowledgement message, or that the UP IP result information corresponding to the E-RAB is in the UP IP acknowledgement message, and the value of the UP IP result information corresponding to the E-RAB is UP IP off. The UP IP result information corresponding to the E-RAB is used for indicating whether the UP IP corresponding to the E-RAB is opened or closed.

In one possible design, the processing module 1202 is further configured to determine whether there is UP IP result information corresponding to the E-RAB in the UP IP acknowledgement message. And a processing module 1202, configured to determine whether the value of the UP IP result information corresponding to the E-RAB matches the UP IP policy corresponding to the E-RAB if the UP IP acknowledgement message has the UP IP result information corresponding to the E-RAB.

In one possible design, the processing module 1202 is further configured to determine whether the UP IP policy corresponding to the E-RAB is forced on. In the case that the UP IP policy corresponding to the E-RAB is forced on, the processing module 1202 is further configured to determine whether the value of the UP IP result information corresponding to the E-RAB in the UP IP acknowledgement message matches the UP IP policy corresponding to the E-RAB.

Or, in another possible design, the processing module 1202 is further configured to determine whether the UP IP policy corresponding to the E-RAB is forced on, and further determine that no UP IP result information corresponding to the E-RAB is in the UP IP acknowledgement message if the UP IP policy corresponding to the E-RAB is forced on.

In a possible design, the processing module 1202 is further configured to determine that the terminal supports UP IP before triggering release of the E-RAB.

In a possible design, the processing module 1202 is further configured to control the transceiver module 1201 to send a release message for the E-RAB to the access network device.

In one possible design, the UP IP acknowledgement message includes a context identifier of the terminal. The processing module 1202 is further configured to obtain, according to the context identifier of the terminal, an UP IP policy corresponding to the E-RAB from a context corresponding to the context identifier of the terminal.

Optionally, the transceiver module 1201 may also include a transmitting module and a receiving module (not shown in fig. 12). The transmitting module is configured to implement a transmitting function of the communication device 1200, and the receiving module is configured to implement a receiving function of the communication device 1200.

Optionally, the communication device 1200 may further include a storage module (not shown in fig. 12) that stores programs or instructions. The processing module 1202, when executing the program or instructions, causes the communications apparatus 1200 to perform the functions of an eNB in the methods illustrated in fig. 6-7, perform the functions of a target eNB in the methods illustrated in fig. 8-9, perform the functions of an SN in the methods illustrated in fig. 10, or perform the functions of a RAN apparatus in the methods illustrated in fig. 11.

It is to be appreciated that the processing module 1202 involved in the communications device 1200 may be implemented by a processor or processor-related circuit component, which may be a processor or processing unit; transceiver module 1201 may be implemented by a transceiver or transceiver related circuit component, which may be a transceiver or transceiver unit.

The communication apparatus 1200 may be a network device, for example, a mobility management entity, a chip (system) or other parts or components that may be disposed in the network device, or an apparatus including the network device, which is not limited in this application.

In addition, the technical effects of the communication apparatus 1200 may refer to the corresponding technical effects in the methods shown in fig. 6-11, which are not described herein.

In another embodiment, the communication apparatus 1200 may be adapted for use in the communication system shown in fig. 5, perform the functions of the MME in the method shown in fig. 6-8, 10-11, or perform the functions of the target MME in the method shown in fig. 9. The communication device 1200 includes modules for performing the functions described above, such as a transceiver module 1201 and a processing module 1202. For convenience of explanation, fig. 12 shows only major components of the communication apparatus.

The transceiver module 1201 is configured to send a user plane integrity protection UP IP acknowledgement message to the mobility management entity when an UP IP policy corresponding to the E-RAB of the E-UTRAN radio access bearer is forced to be turned on. The UP IP confirmation message is used for indicating whether the access network equipment starts the UP IP corresponding to the E-RAB. The transceiver module 1201 is further configured to receive a release message for the E-RAB from the mobility management entity. A processing module 1202, configured to release the context corresponding to the E-RAB in response to the release message.

Optionally, the communication device 1200 may further include a storage module (not shown in fig. 12) that stores programs or instructions. The processing module 1202, when executing the program or instructions, enables the communication apparatus 1200 to perform the functions of the MME in the method illustrated in fig. 6-8, 10-11, or the target MME in the method illustrated in fig. 9.

The communication apparatus 1200 may be a network device, for example, an access network device, a chip (system) or other parts or components that may be disposed in the network device, or an apparatus including the network device, which is not limited in this application.

Fig. 13 is a schematic diagram of a second configuration of a communication device according to an embodiment of the present application. The communication means may be a network device, such as an access network device or a mobility management entity, or may be a chip (system) or other part or component that may be provided on or include a network device. As shown in fig. 13, communications apparatus 1300 can include a processor 1301. Optionally, the communications device 1300 may also include a memory 1302 and/or a transceiver 1303. Processor 1301 is coupled to memory 1302 and transceiver 1303, which may be connected by a communication bus, for example.

The following describes each constituent element of the communication apparatus 1300 in detail with reference to fig. 13:

the processor 1301 is a control center of the communication apparatus 1300, and may be one processor, a collective term of a plurality of processing elements, or may be referred to as a logic circuit. For example, processor 1301 is one or more central processing units (central processing unit, CPU), but may also be an integrated circuit specific (application specific integrated circuit, ASIC), or one or more integrated circuits configured to implement embodiments of the present application, such as: one or more microprocessors (digital signal processor, DSPs), or one or more field programmable gate arrays (field programmable gate array, FPGAs).

Alternatively, the processor 1301 may perform various functions of the communication apparatus 1300 by running or executing a software program stored in the memory 1302, and invoking data stored in the memory 1302.

In a particular implementation, processor 1301 may include one or more CPUs, such as CPU0 and CPU1 shown in FIG. 13, as an embodiment.

In a specific implementation, as an embodiment, the communication apparatus 1300 may also include a plurality of processors, such as the processor 1301 and the processor 1304 shown in fig. 13. Each of these processors may be a single-core processor (single-CPU) or a multi-core processor (multi-CPU). A processor herein may refer to one or more devices, circuits, and/or processing cores for processing data (e.g., computer program instructions).

The memory 1302 is configured to store a software program for executing the embodiments of the present application, and is controlled by the processor 1301, so that the methods shown in fig. 6 to 11 are executed.

Alternatively, memory 1302 may be, but is not limited to, read-only memory (ROM) or other type of static storage device that can store static information and instructions, random access memory (random access memory, RAM) or other type of dynamic storage device that can store information and instructions, but may also be electrically erasable programmable read-only memory (electrically erasable programmable read-only memory, EEPROM), compact disc read-only memory (compact disc read-only memory) or other optical disk storage, optical disk storage (including compact disc, laser disc, optical disc, digital versatile disc, blu-ray disc, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. The memory 1302 may be integrated with the processor 1301, or may exist separately, and be coupled to the processor 1301 through an interface circuit of the communication apparatus 1300, or an input/output interface (not shown in fig. 13), which is not specifically limited in this embodiment of the present application.

A transceiver 1303 for communication with other communication apparatuses. For example, the communication apparatus 1300 is a terminal, and the transceiver 1303 may be used to communicate with a network device or another terminal device. As another example, the communication apparatus 1300 is a network device, and the transceiver 1303 may be used to communicate with a terminal or another network device.

Alternatively, transceiver 1303 may include a receiver and a transmitter (not separately shown in fig. 13). The receiver is used for realizing the receiving function, and the transmitter is used for realizing the transmitting function.

Alternatively, transceiver 1303 may be integrated with processor 1301, or may exist separately, and be coupled to processor 1301 through interface circuitry (not shown in fig. 13) of communication apparatus 1300, as embodiments of the present application are not specifically limited.

It should be noted that the configuration of the communication apparatus 1300 shown in fig. 13 is not limited to the communication apparatus, and an actual communication apparatus may include more or less components than those shown, or may combine some components, or may be different in arrangement of components.

In addition, the technical effects of the communication apparatus 1300 may refer to the technical effects of the communication method described in the above method embodiments, which are not described herein.

Fig. 14 is a schematic structural diagram of a communication device according to an embodiment of the present application. The communication means may be a network device, such as an access network device or a mobility management entity, or may be a chip (system) or other part or component that may be provided on or include the network device. As shown in fig. 14, the communication apparatus 1400 may include: logic 1401 and input-output interface 1402. The input/output interface 1402 is configured to receive a code instruction and transmit the code instruction to the logic circuit 1401. Logic 1401 is operable to execute code instructions to perform the methods of fig. 6-11 as described above.

In addition, the technical effects of the communication device 1400 may refer to the technical effects of the communication method described in the above-mentioned method embodiment, and will not be described herein.

The embodiment of the application provides a communication system. The communication system includes: a mobility management entity and an access network device.

In addition, the technical effects of the communication system may refer to the technical effects of the communication method described in the foregoing method embodiment, which is not described herein.

It should be appreciated that the processor in the embodiments of the present application may be a CPU, but the processor may also be other general purpose processors, DSPs, ASICs, field programmable gate arrays FPGAs or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.

It should also be appreciated that the memory in embodiments of the present application may be either volatile memory or nonvolatile memory, or may include both volatile and nonvolatile memory. The nonvolatile memory may be ROM, programmable ROM (PROM), erasable Programmable ROM (EPROM), EEPROM, or flash memory, among others. The volatile memory may be RAM, which acts as external cache. By way of example, and not limitation, many forms of RAM are available, such as Static RAM (SRAM), dynamic Random Access Memory (DRAM), synchronous Dynamic Random Access Memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous Link DRAM (SLDRAM), and direct memory bus RAM (DR RAM).

The above embodiments may be implemented in whole or in part by software, hardware (e.g., circuitry), firmware, or any other combination. When implemented in software, the above-described embodiments may be implemented in whole or in part in the form of a computer program product. The computer program product comprises one or more computer instructions or computer programs. When the computer instructions or computer programs or instructions are loaded or executed on a computer, the processes or functions described in accordance with embodiments of the present application are produced in whole or in part. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from one website site, computer, server, or data center to another website site, computer, server, or data center by wired (e.g., infrared, wireless, microwave, etc.). The computer readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. that contains one or more sets of available media. The usable medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. The semiconductor medium may be a solid state disk.

It should be understood that the term "and/or" is merely an association relationship describing the associated object, and means that three relationships may exist, for example, a and/or B may mean: there are three cases, a alone, a and B together, and B alone, wherein a, B may be singular or plural. In addition, the character "/" herein generally indicates that the associated object is an "or" relationship, but may also indicate an "and/or" relationship, and may be understood by referring to the context.

In the present application, "at least one" means one or more, and "a plurality" means two or more. "at least one of" or the like means any combination of these items, including any combination of single item(s) or plural items(s). For example, at least one (one) of a, b, or c may represent: a, b, c, a-b, a-c, b-c, or a-b-c, wherein a, b, c may be single or plural.

It should be understood that, in various embodiments of the present application, the sequence numbers of the foregoing processes do not mean the order of execution, and the order of execution of the processes should be determined by the functions and internal logic thereof, and should not constitute any limitation on the implementation process of the embodiments of the present application.

Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

It will be clear to those skilled in the art that, for convenience and brevity of description, specific working procedures of the above-described systems, apparatuses and units may refer to corresponding procedures in the foregoing method embodiments, and are not repeated herein.

In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods may be implemented in other manners. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of the units is merely a logical function division, and there may be additional divisions when actually implemented, e.g., multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.

The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in each embodiment of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit.

The above functions, if implemented in the form of software functional units and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application may be embodied essentially or in a part contributing to the prior art or in a part of the technical solution, in the form of a software product stored in a storage medium, including several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: a usb disk, a removable hard disk, a ROM, a RAM, a magnetic disk, or an optical disk, etc.

The foregoing is merely specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily think about changes or substitutions within the technical scope of the present application, and the changes and substitutions are intended to be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A method of communication, the method comprising:

the mobile management entity receives a user plane integrity protection (UP) IP confirmation message from access network equipment, wherein the UP IP confirmation message indicates whether the access network equipment starts UP IP corresponding to E-UTRAN wireless access bearer (E-RAB);

if the UP IP strategy corresponding to the E-RAB is forced to be started, and the UP IP confirmation message indicates that the access network equipment does not start the UP IP corresponding to the E-RAB, the mobile management entity triggers the release of the E-RAB.

2. The method according to claim 1, wherein the method further comprises:

the mobile management entity determines that the UP IP strategy corresponding to the E-RAB is forced to be opened, determines that no UP IP result information corresponding to the E-RAB exists in the UP IP confirmation message, or determines that the UP IP result information corresponding to the E-RAB exists in the UP IP confirmation message, and the value of the UP IP result information corresponding to the E-RAB is UP IP to be closed; the UP IP result information corresponding to the E-RAB is used for indicating whether the UP IP corresponding to the E-RAB is opened or closed.

3. The method according to claim 1, wherein the method further comprises:

the mobile management entity determines whether the UP IP result information corresponding to the E-RAB exists in the UP IP confirmation message;

if the UP IP confirmation message has the UP IP result information corresponding to the E-RAB, the mobile management entity determines whether the value of the UP IP result information corresponding to the E-RAB is matched with the UP IP strategy corresponding to the E-RAB.

4. The method according to claim 1, wherein the method further comprises:

the mobile management entity determines whether the UP IP strategy corresponding to the E-RAB is forcedly opened;

and under the condition that the UP IP strategy corresponding to the E-RAB is forced to be opened, the mobile management entity determines whether the value of the UP IP result information corresponding to the E-RAB in the UP IP confirmation message is matched with the UP IP strategy corresponding to the E-RAB.

5. The method according to any of claims 1-4, wherein before the mobility management entity triggers the release of the E-RAB, the method further comprises:

the mobility management entity determines that the terminal supports UP IP.

6. The method of any of claims 1-5, wherein the UP IP acknowledgement message comprises at least one of: an initial context setup response message, an E-RAB setup/modification response message, a path switch request message, a switch request acknowledgement message, or an E-RAB modification indication message.

7. The method according to any of claims 1-6, wherein the mobility management entity triggering the release of the E-RAB comprises:

the mobility management entity sends a release message for the E-RAB to the access network device.

8. The method of claim 7, wherein the release message comprises at least one of: an E-RAB release order message, or a path switch request acknowledgement message.

9. The method according to any of claims 1-8, characterized in that the UP IP acknowledgement message comprises a context identification of the terminal, the method further comprising:

and the mobile management entity acquires the UP IP strategy corresponding to the E-RAB from the context corresponding to the context identifier of the terminal according to the context identifier of the terminal.

10. A method of communication, the method comprising:

the access network equipment sends a user plane integrity protection UP IP confirmation message to a mobile management entity under the condition that an UP IP strategy corresponding to an E-UTRAN wireless access bearer E-RAB is forced to be opened, wherein the UP IP confirmation message is used for indicating whether the access network equipment opens the UP IP corresponding to the E-RAB;

The access network equipment receives a release message for the E-RAB from the mobile management entity;

and responding to the release message, the access network equipment releases the context corresponding to the E-RAB.

11. The method of claim 10 wherein the UP IP acknowledgement message comprises at least one of: an initial context setup response message, an E-RAB setup/modification response message, a path switch request message, a switch request acknowledgement message, or an E-RAB modification indication message.

12. The method according to claim 10 or 11, wherein the release message comprises at least one of the following messages: an E-RAB release order message, or a path switch request acknowledgement message.

13. A communication device, the device comprising: a module for performing the method of any one of claims 1-9.

14. A communication device, the device comprising: a module for performing the method of any one of claims 10-12.

15. A communication system, the system comprising: a mobility management entity and access network equipment; wherein, the liquid crystal display device comprises a liquid crystal display device,

the mobility management entity is configured to receive a user plane integrity protection UP IP acknowledgement message from the access network device, where the UP IP acknowledgement message indicates whether the access network device starts UP IP corresponding to an E-UTRAN radio access bearer E-RAB; the method is further used for triggering the release of the E-RAB if the UP IP strategy corresponding to the E-RAB is forced to be started and the UP IP confirmation message indicates that the access network equipment does not start the UP IP corresponding to the E-RAB;

The access network device is configured to receive a release message for the E-RAB from the mobility management entity, and further configured to release a context corresponding to the E-RAB according to the release message.

16. The system of claim 15 wherein the mobility management entity is further configured to determine that an UP IP policy corresponding to the E-RAB is forced on, and determine that no UP IP result information corresponding to the E-RAB exists in the UP IP acknowledgment message, or that UP IP result information corresponding to the E-RAB exists in the UP IP acknowledgment message, and that a value of the UP IP result information corresponding to the E-RAB is UP IP off; the UP IP result information corresponding to the E-RAB is used for indicating whether the UP IP corresponding to the E-RAB is opened or closed.

17. The system of claim 15 wherein the mobility management entity is further configured to determine whether there is UP IP result information corresponding to the E-RAB in the UP IP acknowledgement message; and the method is also used for determining whether the value of the UP IP result information corresponding to the E-RAB is matched with the UP IP strategy corresponding to the E-RAB or not if the UP IP confirmation message has the UP IP result information corresponding to the E-RAB.

18. The system of claim 15 wherein the mobility management entity is further configured to determine whether an UP IP policy corresponding to the E-RAB is forced on; and the method is also used for determining whether the value of the UP IP result information corresponding to the E-RAB in the UP IP confirmation message is matched with the UP IP strategy corresponding to the E-RAB under the condition that the UP IP strategy corresponding to the E-RAB is forcedly started.

19. The system according to any of claims 15-18, wherein the access network device is further configured to send the UP IP acknowledgement message to the mobility management entity if an UP IP policy corresponding to the E-RAB is forced on.

20. The system according to any of the claims 15-19, wherein the mobility management entity is further configured to determine that the terminal supports UP IP before triggering the release of the E-RAB.

21. The system of any of claims 15-20, wherein the UP IP acknowledgement message comprises at least one of: an initial context setup response message, an E-RAB setup/modification response message, a path switch request message, a switch request acknowledgement message, or an E-RAB modification indication message.

22. The system according to any of claims 15-21, wherein the UP IP acknowledgement message includes a context identifier of a terminal, and the mobility management entity is further configured to obtain, according to the context identifier of the terminal, the UP IP policy corresponding to the E-RAB from a context corresponding to the context identifier of the terminal.

23. The system of any of claims 15-22, wherein the release message comprises at least one of: an E-RAB release order message, or a path switch request acknowledgement message.