Patent Description:
One of the development goals of mobile communications is to establish an extensive network including various types of terminals. This is also one of the starting points of developing the Internet of Things in a cellular communication framework currently. According to a prediction of the industry, in <NUM>, there will be approximately <NUM> billion cellular access terminals worldwide, and most of them will be machine communication terminals having a characteristic of the Internet of Things. The Internet of Vehicles is an extension of the Internet of Things in the transportation field. The Internet of Vehicles is a unified network in which information about vehicles, roads, and environments is collected using technologies such as wireless communications, sensing, and probing, information is exchanged and shared between vehicle-to-vehicle (V2V), and intelligent coordination and cooperation are implemented between a vehicle-to-infrastructure (V2I) to implement intelligent traffic management and control, intelligent vehicle control, and an intelligent dynamic information service. As aided driving and automatic driving technologies gradually mature, higher requirements are imposed on the reliability and a low latency of the Internet of Vehicles. An Internet of Vehicles communication technology including V2V, V2I, Vehicle-to-Pedestrian (V2P), and the like is becoming a new highlight of the Internet of Vehicles, and is a key technology of a future intelligent transportation system. The Internet of Vehicles provides for communication between vehicles, between a vehicle and a base station, and between base stations. This can be used, for example, to obtain a series of traffic information, such as live traffic, road information, and pedestrian information, to improve traffic safety and to reduce a traffic accident rate.

In an Evolved Packet Core (EPC) network architecture, a Serving Gateway (S-GW) and a Packet Data Network (PDN) Gateway (P-GW) are mainly responsible for forwarding user plane data, but also reserve a capability of processing a large amount of interface signaling. The S-GW and the P-GW may be combined into one network element, and collectively referred to as a gateway. As the network architecture evolves, to enable an application and a content source to be closer to a user, cooperate with a distributed deployment of the content source, further reduce an end-to-end service latency, and meet requirements of some low-latency applications and local voice, the gateway is deployed gradually closer to the user. Complex control logic of the gateway is separated out, and a logic control function is reserved on a centralized conventional gateway or is integrated into an integrated control plane, so that the gateway is divided into two types of gateways, one is called "control plane" (CP) and the other one is called "user plane" (UP). The UP is also known as the data plane, forwarding plane, carrier plane or bearer plane. The control plane carries signaling traffic and is responsible for routing; the user plane carries the network user data traffic. Therefore, cost pressure caused by the distributed deployment can be effectively reduced. After separation, the user plane and the control plane support independent scaling, further improving elasticity and flexibility of the network architecture. Centralized control logic makes it easier to customize a network slice and to serve diversified industry applications.

In an EPC network architecture, an Internet Protocol (IP) address of user equipment (UE) is bound to a UP, and the UP is an anchor of a service. When UP switching occurs, the IP address of the UE is changed. Therefore, a service of the UE is interrupted, and service continuity cannot be maintained.

In an existing V2V communication scenario, a D2D communication manner is mainly used. During D2D communication, a distance is relatively short, and channel quality is relatively good. Therefore, a high transmission rate, a low latency, and low power consumption can be implemented. Before the D2D technology appears, a similar communication technology, such as Bluetooth or WiFi Direct, already appears. Due to various reasons, the two technologies fail to be commercially utilized extensively. Compared with another direct communication technology that does not depend on an infrastructure network design, the D2D technology is more flexible. For example, D2D can be used for establishing a connection and performing resource allocation under the control of a base station, as well as performing information exchange without network infrastructure.

In an existing V2V communication scenario, a D2D manner is mainly used. That is, vehicle to vehicle communication is looped back at one or more base stations controlled by a same UP, and does not pass a core network. D2D aims to enable user equipments within a particular distance range to directly communicate. The UP controls a D2D connection, and the UP obtains all link information according to measurement information reported by a terminal. In the example shown in <FIG>, UE <NUM> and UE <NUM> are vehicles controlled by a base station, and exchange data by using a D2D link. As vehicles move fast, and a UP network is deployed closer to UEs, a cross-UP communication scenario easily appears. Cross-UP means that multiple UEs are served by multiple UPs. Because the existing D2D communications technology is restricted to communication in the base station or a UP loopback, UE1 and UE2 will not be able to communicate normally in the cross-UP communication scenario or to maintain continuous service when UE1 or UE2 switches from one UP to another UP.

<NPL>), discloses an overview of 3GPP device-to-device proximity services.

To resolve the technical problems, embodiments of the present invention provide a method for communication between UEs and a gateway and a system for communication between UEs.

By using the solutions provided in the method, system and gateway of different embodiments, different UEs (e.g., vehicles) controlled by a UP and a CP can exchange data by using a D2D link. When a cross-UP communication scenario appears, UEs will still be able to communicate normally and maintain service continuity.

The embodiments of the present invention are mainly related to communication between moving UEs. The UEs may be fast moving vehicles, unmanned aircraft and other moving equipments. Rapid movement of UE easily causes switching of a local anchor. Even though UEs in a motorcade communicate over one UP in most cases, cross-UP communication also occurs between UEs.

A system architecture is shown in <FIG>. The system architecture comprises a CP, multiple UPs and multiple base stations. The CP can serve and manage the multiple UPs. Each UP can serve and manage one or more base stations. Via one or more base stations, multiple UPs and the CP, different UEs can communicate with each other.

Particular address pool resources are allocated in advance, such as <NUM>. <NUM> to <NUM>. <NUM> and <NUM>. <NUM> to <NUM>. <NUM>, to a UE performing a V2V service. These particular address pool resources are enabled on each UP and each UP can process data packets with these address segments.

UPs form a mesh network. The UPs may perform tunnel communication at a device granularity. For example, a data packet between UEs may be transmitted via a tunnel between different UPs, using an IP in IP protocol. Because the service is looped back in the UPs, the UPs do not need to broadcast routes of these address segments to the outside.

When a UE accesses a network, a CP selects N user plane gateways for the UE (e.g., according to a physical location of the UE), and creates a context record for the UE on each of the N selected UP gateways (wherein N is a natural number greater or equal <NUM>). The context record comprises an IP address of the UE and address information of a base station to which the UE is connected. The address information of a base station may include an IP address of the base station and a tunnel endpoint identifier (TEID) related to the base station.

The context record on a UP currently serving the UE may be marked as a "master" context record. Context records for the UE on the other N-<NUM> user planes may be marked as "slave" context records. Each of the slave context records comprises the IP address of the UE and the identifier of the UP that is currently serving the UE. The identifier of the UP may include an IP address of the UP and a tunnel endpoint identifier (TEID) related to the UP. In this embodiment and the following embodiments, the "master" or "slave" in context record is only a mark and is not a necessary field.

Here is a typical and main scenario for communication between two different UEs (See <FIG>). Assume that there are two UEs (UE1 and UE2) that need to perform a V2V service and that UE1 wants to send a data packet to UE2 (voluntarily or upon a request from UE2 or a CP). UP1 and UP2 are controlled by the CP. UE1 is being served by UP1 and UE2 is being served by UP2. The main steps are as follows:.

For instance, by means of searching the memory located in UP1 according to the IP address of UE2 included in the data packet, UP1 finds a slave context record for UE2 which includes the same IP address as the IP address of UE2 included in the data packet. Further, the slave context record for UE2 includes an identifier of UP2 and the identifier of UP2 may include an IP address of UP2 and a tunnel endpoint identifier (TEID) related to UP2.

When the distance between UP1 and UE2 is greater than a critical distance, the slave context record for UE2 may have been not created on UP1 and may therefore be not available on UP1. In this case, or whenever the context record for UE2 is not available on UP1, UP1 will send a request including an IP address of UE2 to the CP for the context record for UE2 and subsequently receive the context record for UE2 from the CP.

UP1 sends the data packet to UP2 according to the identifier of UP2.

After obtaining the context record for UE2, UP1 will send the data packet to UP2 according to the identifier of UP2 recorded in the context record for UE2.

The UPs form a mesh network, and they may perform tunnel communication. The data packet sent by UP1 is transmitted to UP2 via these tunnels using an IP in IP protocol.

UP2 sends the data packet to UE2.

The master context record for UE2 may include the IP address of UE2 and address information of a base station to which UE2 is currently connected. The address information of the base station may include an IP address of the base station and a tunnel endpoint identifier (TEID) related to the base station. Using the address information of the base station, UP2 can find the base station and send data packets to the base station, and then the base station forwards the data packets to UE2.

Optionally, the master context record for UE2 may include the IP address of UE2 and the identifier of UP2, and the address information of the base station to which UE2 is currently connected is not stored in the master context record, but stored in other locations of UP2's memory so that UP2 can find it. If so, when UE2 switches frequently between different base stations being served by UP2, the master context record does not need to be updated accordingly.

When UP2 receives the data packet, UP2 will separate out an outer IP address and find the IP address of UE2 of an inner data packet (e.g., in accordance with the IP in IP protocol). UP2 then searches a memory of UP2 and finds the master context record for UE2 on UP2 according to the IP address of UE2 of the inner data packet. UP2 then sends the data packet to UE2 via a base station whose address information is carried in the master context record or other locations.

To facilitate understanding about the embodiments of the present invention, several specific embodiments are used as examples to make further description with reference to the accompanying drawings, and the embodiments are not intended to limit the embodiments of the present invention.

A specific scenario to which this example is applied is that vehicles are performing a V2V service communication, but UP switching does not occur. Referring to <FIG>, UE1, UE2, and UE3 are terminals of a V2V service type. In this embodiment, no UP switching occurs on any UE in a communication process. The communication process mainly includes the following. UE2 and UE3 each send data packets to UE1. UE1 is served by UP1, UE2 is served by UP2, and UE3 is served by UP3. As UE1 is being served by UP1, the context record for UE1 on UP1 may be marked "master". UE1, UE2 and UE3 are not limited to terminals of a V2V service type; instead they may be other moving terminals suitable for D2D communication. A specific implementation procedure is as follows (as shown in <FIG>):.

According to the invention, in a process of communication between vehicles, service continuity is maintained even when movement of a vehicle causes a change of a user plane gateway serving a UE. As illustrated in <FIG>, both UE1 and UE2 are terminals of a V2V service type and UE2 sends data packets to UE1. As UE1 is being served by UP1, the context record for UE1 created on UP1 may be marked "master". Because of movement of UE1, the user plane gateway serving UE1 is switched from UP1 to UP3. The path of transmitting data packets has changed from path <NUM> to path <NUM>. UE1 and UE2 are not limited to terminals of a V2V service type; instead, they may be other moving terminals capable of D2D communication. A specific implementation procedure is as follows (as shown in <FIG>):.

The foregoing description is a detailed description of the method for communication between UEs according to embodiments of the present invention with reference to <FIG>. The following describes a system and an apparatus for communication between UEs according to embodiments of the present invention with reference to <FIG>.

<FIG> schematically shows a communication system comprising user planes UP1 and UP2, and user equipments UE1 and UE2. UP1 is configured to receive a data packet from UE1, the data packet including data and an IP address of UE2; obtain a context record for UE2, the context record including the IP address of UE2 and an identifier of UP2; and send the data packet to UP2 according to the identifier of UP2. UP2 is configured to send the data packet to UE2.

For example, UP1 may be configured to obtain the context for UE2 from UP1 when the context record for UE2 has been stored on UP1.

The system further includes a CP. When the context record for UE2 is not available, for obtaining the context record for UE2, UP1 is configured to send a request to the CP for the context record for UE2, and receive the context record for UE2 from the CP.

In the example, the system further includes UP3, and when UE2 switches from UP1 to UP3, the CP is configured to update the context for UE2 in UP1, the updated context for UE2 including the IP address of UE2 and an identifier of UP3; UP1 is configured to receive a subsequent data packet from UE1, wherein the subsequent data packet includes data and the IP address of UE2; send the subsequent data packet to UP3 according to the identifier of UP3; and UP3 is configured to send the subsequent data packet to UE2.

When UE2 switches to UP3, the CP is configured to obtain a critical distance and for each user plane in a set of one or more user planes of the system, if a distance from the respective user plane to the second UE is less than a critical distance, the CP is configured to.

the updated or created context record for UE2 including the IP address of UE2 and an identifier of UP3.

<FIG> is a schematic block diagram of a user plane gateway <NUM>. The UP gateway <NUM> comprises:.

The context record for UE2 may have been stored in a memory <NUM> of the gateway <NUM>. However, when the processor <NUM> determines that the context record for UE2 is not available in the memory <NUM>, the transmitter <NUM> is configured to send a request to a control plane for the context for UE2, and the receiver <NUM> is configured to receive the context record for UE2 from the control plane and to store it in the memory <NUM> for future use.

When UE2 switches from the other gateway to a third gateway, the context record for UE2 (in the memory <NUM>) is updated. The updated context for UE2 includes the IP address of UE2 and an identifier of the third gateway.

A person of ordinary skill in the art may understand that all or some of the steps of the embodiments may be implemented by hardware or a program instructing related hardware. The program may be stored in a computer-readable storage medium. The storage medium may include: a read-only memory, a magnetic disk, or an optical disc.

Claim 1:
A method for device-to-device communication between a first and a second user equipments, UEs, comprising:
receiving, by a first user plane gateway, a second session context record for the second UE from a control plane gateway, wherein the session context record for the second UE on the first user plane gateway comprises an Internet Protocol, IP, address of the second UE and an identifier of a second user plane gateway serving the second UE;
receiving, by the first user plane gateway, a first session context record for the first UE from the control plane gateway;
receiving (<NUM>), by the first user plane gateway, a first data packet to be sent to the second UE from the first UE, wherein the first data packet comprises first data and the IP address of the second UE;
obtaining, by the first user plane gateway from the second session context record, the identifier of the second user plane gateway based on the IP address of the second UE;
sending (<NUM>), by the first user plane gateway, via a first tunnel, the first data packet to the second user plane gateway according to the identifier of the second user plane gateway;
when the second UE has switched to a third user plane gateway, the method further comprises:
receiving (7b), by the first user plane gateway, an updated session context record for the second UE from the control plane gateway to update the context record for the second UE, wherein the updated context record includes the IP address of the second UE and an identifier of the third user plane gateway;
receiving (<NUM>), by the first user plane gateway, a second data packet to be sent to the second UE from the first UE, wherein the second data packet comprises second data and the IP address of the second UE;
obtaining, by the first user plane gateway from the updated session context record, the identifier of the third user plane gateway based on the IP address of the second UE and
sending (<NUM>), by the first user plane gateway, via a second tunnel, the second data packet to the third user plane gateway according to the identifier of the third user plane gateway included in the updated context record.