WO2017171434A1

WO2017171434A1 - Method and apparatus for transmitting v2x message to neighboring enb in wireless communication system

Info

Publication number: WO2017171434A1
Application number: PCT/KR2017/003492
Authority: WO
Inventors: 쑤지안; 변대욱
Original assignee: 엘지전자 주식회사
Priority date: 2016-03-30
Filing date: 2017-03-30
Publication date: 2017-10-05

Abstract

In performing vehicle-to-everything (V2X) communication through a local gateway (L-GW), an eNodeB (eNB) receives a V2X message from a V2X user equipment (UE), and transfers the V2X message to a V2X server through the L-GW. When it is determined that the V2X message needs to be propagated to a neighboring area, the V2X server provides an indicator indicating the same to the eNB through the L-GW. Upon receiving the indicator indicating that the V2X message is to be transmitted to a neighboring eNB, the eNB transmits the V2X message to the neighboring eNB.

Description

Method and apparatus for transmitting V2X message to neighbor base station in wireless communication system

The present invention relates to wireless communication, and more particularly, to a method and apparatus for transmitting a vehicle-to-everything (V2X) message to a neighbor base station in a wireless communication system.

3rd generation partnership project (3GPP) long-term evolution (LTE) is a technology for enabling high-speed packet communication. Many approaches have been proposed to reduce the cost, improve service quality, expand coverage, and increase system capacity for LTE targets. 3GPP LTE is a high level requirement that requires cost per bit, improved service usability, flexible use of frequency bands, simple structure, open interface and proper power consumption of terminals.

LTE-based vehicle-to-everything (V2X) is urgently needed from the market, because the widespread LTE-based network offers the opportunity for the automotive industry to realize the concept of a "connected car." In particular, the market for vehicle-to-vehicle (V2V) communications is expected to have ongoing or initiated related activities, such as research projects, field testing and regulatory work, in some countries or regions, such as the United States, Europe, Japan, Korea, and China. do.

3GPP proposes a solution to offload traffic to the core network by utilizing small cells introduced to increase cell capacity and eliminate shadow areas. In one of the offloading solutions, local IP access (LIPA) and selected IP traffic offload (SIPTO), traffic is delivered directly to the Internet through a local gateway (L-GW) rather than through an evolved packet system (EPC). LIPA is a method of transferring data to a local network connected to the same HeNB without passing through a macro cell to a user connected to a home eNodeB (HeNB). LIPA also connects users to any external network connected to the local network. SIPTO is a method of offloading IP traffic share of HeNB or cellular network to local network to reduce system load. The target network may be a HeNB or other gateway closer to the user in the cellular network.

A method of efficiently and without delaying V2X communication through LIPA and / or SIPTO may be proposed.

The present invention provides a method and apparatus for transmitting a vehicle-to-everything (V2X) message to a neighbor base station in a wireless communication system. The present invention provides a method and apparatus for directly transmitting a V2X message to a neighbor base station without passing through a core network when V2X communication is performed through a selected IP traffic offload at local network (SIPTO @ LN).

In one aspect, a method is provided for transmitting a vehicle-to-everything (V2X) message by an eNB (eNodeB) in a wireless communication system. The method receives a V2X message from a user equipment (V2X UE), forwards the V2X message to a V2X server through a local gateway (L-GW), and the V2X message is to be transmitted to a neighbor eNB. Receiving an indicating indicator, and transmitting the V2X message to the neighbor eNB.

In another aspect, an eNB (eNodeB) is provided in a wireless communication system. The eNB includes a memory and a processor connected to the memory, the processor receiving a V2X message from a vehicle-to-everything (V2X) user equipment (UE) and sending the V2X message to a local gateway (L). Forward to a V2X server via a local gateway (GW), receive an indicator indicating that the V2X message will be sent to a neighbor eNB, and send the V2X message to the neighbor eNB.

V2X messages may be sent to neighboring base stations without delay.

1 shows a structure of an LTE system.

2 shows a logical structure for an eNB when SIPTO @ LN is supported via a co-located L-GW.

3 shows an example of a structure for V2X communication.

4 shows an example of V2X communication via SIPTO @ LN supported by L-GW co-located.

5 shows an example of V2X communication via SIPTO @ LN supported by an independent L-GW.

6 illustrates a method of transmitting a V2X message to a neighbor eNB according to an embodiment of the present invention.

7 illustrates a method for an eNB to transmit a V2X message according to an embodiment of the present invention.

8 illustrates a wireless communication system in which an embodiment of the present invention is implemented.

The following techniques include code division multiple access (CDMA), frequency division multiple access (FDMA), time division multiple access (TDMA), orthogonal frequency division multiple access (OFDMA), single carrier frequency division multiple access (SC-FDMA), and the like. It can be used in various wireless communication systems. CDMA may be implemented by a radio technology such as universal terrestrial radio access (UTRA) or CDMA2000. TDMA may be implemented with wireless technologies such as global system for mobile communications (GSM) / general packet radio service (GPRS) / enhanced data rates for GSM evolution (EDGE). OFDMA may be implemented by wireless technologies such as Institute of Electrical and Electronics Engineers (IEEE) 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802-20, evolved UTRA (E-UTRA), and the like. IEEE 802.16m is an evolution of IEEE 802.16e and provides backward compatibility with IEEE 802.16 based systems. UTRA is part of a universal mobile telecommunications system (UMTS). 3rd generation partnership project (3GPP) long term evolution (LTE) is part of evolved UMTS (E-UMTS) using evolved-UMTS terrestrial radio access (E-UTRA), which employs OFDMA in downlink and SC in uplink -FDMA is adopted. LTE-A (advanced) is the evolution of 3GPP LTE.

For clarity, the following description focuses on LTE-A, but the technical features of the present invention are not limited thereto.

1 shows a structure of an LTE system. Referring to FIG. 1, an LTE system structure includes one or more user equipment (UE) 10, an evolved-UMTS terrestrial radio access network (E-UTRAN), and an evolved packet core (EPC). The UE 10 is a communication device moved by a user. The UE 10 may be fixed or mobile and may be referred to by other terms such as a mobile station (MS), a user terminal (UT), a subscriber station (SS), and a wireless device.

The E-UTRAN includes one or more evolved NodeBs (eNBs) 20, and a plurality of UEs may exist in one cell. The eNB 20 provides an end point of a control plane and a user plane to the UE 10. The eNB 20 generally refers to a fixed station that communicates with the UE 10 and may be referred to in other terms, such as a base station (BS), an access point, and the like. One eNB 20 may be arranged per cell.

Hereinafter, downlink (DL) means communication from the eNB 20 to the UE 10. Uplink (UL) means communication from the UE 10 to the eNB 20. Sidelink (SL) means communication between the UE (10). In the DL, the transmitter may be part of the eNB 20 and the receiver may be part of the UE 10. In the UL, the transmitter may be part of the UE 10 and the receiver may be part of the eNB 20. In the SL, the transmitter and the receiver may be part of the UE 10.

The EPC includes a mobility management entity (MME) and a serving gateway (S-GW). The MME / S-GW 30 is located at the end of the network. The MME / S-GW 30 provides an end point of session and mobility management functionality for the UE 10. For convenience of description, the MME / S-GW 30 is simply expressed as a "gateway", which may include both the MME and the S-GW. A packet dana network (PDN) gateway (P-GW) may be connected to an external network.

The MME includes non-access stratum (NAS) signaling to the eNB 20, NAS signaling security, access stratum (AS) security control, inter CN (node network) signaling for mobility between 3GPP access networks, idle mode terminal reachability ( Control and execution of paging retransmission), tracking area list management (for UEs in idle mode and activation mode), P-GW and S-GW selection, MME selection for handover with MME change, 2G or 3G 3GPP access Bearer management features, including roaming, authentication, and dedicated bearer setup, selection of a serving GPRS support node (SGSN) for handover to the network, public warning system (ETWS) and earthquake and tsunami warning system (CMAS) It provides various functions such as message transmission support. S-GW hosts can be based on per-user packet filtering (eg, through deep packet inspection), legal blocking, terminal IP (Internet protocol) address assignment, transport level packing marking in DL, UL / DL service level charging, gating and It provides various functions of class enforcement, DL class enforcement based on APN-AMBR (access point name aggregate maximum bit rate).

An interface for user traffic transmission or control traffic transmission may be used. The UE 10 and the eNB 20 are connected by a Uu interface. The UEs 10 are connected by a PC5 interface. The eNBs 20 are connected by an X2 interface. The neighboring eNB 20 may have a mesh network structure by the X2 interface. The eNB 20 and the gateway 30 are connected through an S1 interface.

E-UTRAN uses selected IP traffic (SIPTO @ LN) via a colocated local gateway (collocated L-GW) in the eNB or a standalone gateway (coordinated with S-GW and L-GW). offload at local network).

2 shows a logical structure for an eNB when SIPTO @ LN is supported via a co-located L-GW. Referring to FIG. 2, for a SIPTO @ LN PDN connection, the eNB establishes and maintains an S5 connection to the EPC. The SIPTO @ LN PDN connection is released after the handover is performed, and the co-located L-GW in the source eNB triggers the release through the S5 interface.

When SIPTO @ LN is supported through the co-located L-GW, the eNB supports the following additional functions.

Send the co-located L-GW IP address of the eNB to the EPC via S1-MME on all idle-active transitions;

Send the co-located L-GW IP address of the eNB to the EPC via S1-MME within all uplink NAS transmission procedures;

Support of basic P-GW functions in co-located L-GWs, such as support of SGi interfaces corresponding to SIPTO @ LN;

Additional support for first packet transmission, buffering of subsequent packets, direct management of the L-GW-eNB user path and forwarding of sequence packets to the UE

-Support of necessary limited S5 procedures corresponding to the support of SIPTO @ LN functionality;

Notify the EPC of the co-located L-GW uplink tunneling endpoint ID (TEID) or generic routing encapsulation (GRE) key for the SIPTO @ LN bearer over the S5 interface within a limited set of procedures;

Trigger of SIPTO @ LN PDN disconnection by co-located L-GW after handover is performed.

If SIPTO @ LN is supported through the co-located L-GW, the MME supports the following additional features:

SIPTO @ LN activation for the requested access point name (APN) based on received co-located L-GW IP address and SIPTO authorization in subscription data;

Send “SIPTO correlation id” to the eNB via an initial context setup procedure and an E-UTRAN radio access bearer (E-RAB) setup procedure;

SIPTO @ LN PDN disconnection of idle mode UE when UE moves away from coverage area of eNB.

SIPTO @ LN is also supported using independent gateways (with S-GWs and L-GWs) deployed in the local network. The MME can determine to trigger S-GW relocation without UE movement. Unless the source and target eNBs are in the same local home eNB (HeNB) network (ie, they do not have the same LHN ID), the SIPTO @ LN PDN connection is released after handover.

When SIPTO @ LN is supported through the independent L-GW, the eNB supports the following additional functions.

Signaling its LHN ID to the MME in an initial UE message, an uplink NAS delivery message, a handover notification message and a path switch request message;

Support MME triggered S-GW relocation without UE movement via E-RAB modification request message;

If SIPTO @ LN is supported through an independent L-GW, the MME supports the following additional features:

SIPTO @ LN activation for the requested APN based on the received LHN ID and subscription data;

S-GW relocation without UE movement.

Describes vehicle-to-everything (V2X) communication. There are three types of V2X communication: vehicle-to-vehicle (V2V) communication, vehicle-to-infrastructure (V2I) communication, and vehicle-to-pedestrian (V2P) communication. These three types of V2X can use "collaboration consciousness" to provide more intelligent services for end users. This allows vehicle, road side unit (RSU) and transportation entities such as pedestrians to collect knowledge about their local environment (for example, information received from other vehicles or sensor equipment in close proximity), and can be used for collaborative collision alerts or autonomous driving. This means that knowledge can be processed and shared to provide intelligent services.

V2X service is a type of communication service that includes a transmitting or receiving UE using a V2V application over 3GPP transmission. The V2X service may be divided into a V2V service, a V2I service, a V2P service, and a vehicle-to-network (V2N) service according to a counterpart who participated in the communication. V2V service is a type of V2X service that is a UE that uses V2V applications on both sides of the communication. A V2I service is a type of V2X service that uses a V2I application, with one side of communication being a UE and the other side being an RSU. The RSU is an entity supporting a V2I service that can transmit / receive with a UE using a V2I application. RSU is implemented in an eNB or a fixed UE. V2P service is a type of V2X service that is a UE that uses V2P applications on both sides of the communication. A V2N service is a type of V2X service in which one side of communication is a UE and the other is a serving entity, all using V2N applications and communicating with each other via an LTE network entity.

In V2V, the E-UTRAN allows UEs in close proximity to each other to exchange V2V related information using E-UTRA (N) when permit, authorization and proximity criteria are met. Proximity criteria may be configured by a mobile network operator (MNO). However, the UE supporting the V2V service may exchange such information when it is provided or not provided by the E-UTRAN supporting the V2X service. The UE supporting the V2V application sends application layer information (eg, about its location, dynamics and attributes as part of the V2V service). The V2V payload must be flexible to accommodate different content, and information can be sent periodically depending on the configuration provided by the MNO. V2V is mainly broadcast based. V2V includes the direct exchange of V2V related application information between different UEs, and / or due to the limited direct communication range of V2V, V2V is an infrastructure supporting V2X service for V2V related application information between different UEs (eg For example, the exchange through the RSU, application server, etc.).

In V2I, the UE supporting the V2I application transmits application layer information to the RSU. The RSU transmits application layer information to the UE supporting the UE group or the V2I application.

In V2P, the E-UTRAN allows UEs in close proximity to each other to exchange V2P related information using the E-UTRAN when permit, authorization and proximity criteria are met. Proximity criteria may be constructed by the MNO. However, the UE supporting the V2P service may exchange this information even when not serviced by the E-UTRAN supporting the V2X service. The UE supporting the V2P application transmits application layer information. Such information may be broadcast by vehicle UEs (eg, alerting pedestrians) that support V2X services and / or pedestrian UEs (eg, alerting vehicles) that support V2X services. V2P involves exchanging V2V related application information directly between different UEs (one vehicle, another pedestrian), and / or due to the limited direct communication range of V2P, V2P is a V2P related application between different UEs. This involves exchanging information through infrastructures that support V2X services (eg, RSUs, application servers, etc.).

3 shows an example of a structure for V2X communication. Referring to FIG. 3, an existing node (ie, eNB / MME) or a new node may be deployed to support V2X communication. The interface between nodes may be an S1 / X2 interface or a new interface. That is, the interface between eNB1 and eNB2 may be an X2 interface or a new interface. The interface between eNB1 / eNB2 and MME1 / MME2 may be an S1 interface or a new interface.

In addition, there may be three UEs for V2X communication, one is a vehicle UE, the other is an RSU UE, and the last is a pedestrian UE. The vehicle UE may be the same as a normal UE. An RSU UE is an RSU implemented in a UE and may relay, multicast or broadcast traffic or safety information or other vehicle UEs. A pedestrian UE is a UE that supports V2X communication carried by pedestrians, bicyclists, drivers or passengers. For V2X communication, the vehicle UE and the pedestrian UE can communicate with each other directly via the PC5 interface. Alternatively, the vehicle UE and the pedestrian UE may communicate with each other indirectly via a network node. The network node may be any one of an eNB, a new entity for V2X communication, a new gateway for V2X communication, and an RSU. The network node may not be an existing MME or S-GW. Alternatively, the vehicle UE or pedestrian UE may broadcast data, and the RSU UE may receive the broadcast data. The RSU and other vehicle UEs / pedestrian UEs may communicate with each other indirectly via a network node. The network node may be any one of an eNB, a new entity for V2X communication, a new gateway for V2X communication, and an RSU.

V2X communication can be performed via SIPTO @ LN. That is, when SIPTO @ LN is supported, the V2X message may be transmitted through the L-GW without passing through the core network. There are three use cases where V2X communication is performed via SIPTO @ LN.

1. The V2X server connects via independent L-GW and SIPTO @ LN: In this case, the V2X server processes data from a local sensor / camera array, for example, and distributes it to all locally connected vehicle UEs. Connection is provided to all local eNBs identified with the same LHN ID. By properly setting the LHN ID with the V2X service area, the V2X service can be provided at the appropriate location in the most appropriate way. Thanks to the nature of SIPTO @ LN with independent L-GW, the connection to the V2X server is always maintained in vehicle UE movement within the LHN.

2. Connection through the L-GW and SIPTO @ LN co-located with the V2X server: As in the first use example above, the connection is routed through the L-GW co-located to each eNB. In this case, however, the connection to the V2X server of the vehicle UE is suspended before the movement and is established again through the L-GW in the target eNB after the handover is completed.

3. V2X server co-located with the eNB: In this case all essential functions are implemented in the eNB. For example, this could be the physical road side box containing the sensor (ie, terminating all traffic locally) and the RSU handling the associated connection to the vehicle UE. This can be thought of as "shrink" the logical node above into a single physical node with the V2X server.

When the neighbor eNB is at the edge of the coverage of the independent L-GW in the second use case, the third use case and the first use example described above, when the V2X message received from the V2X UE needs to be propagated to the neighbor area. There may be one problem with how to transmit to a neighbor eNB.

4 shows an example of V2X communication via SIPTO @ LN supported by L-GW co-located. The V2X communication through SIPTO @ LN of FIG. 4 corresponds to the third usage example above. That is, there is an L-GW and a V2X server, which are disposed together inside the first eNB and the second eNB, respectively. Basically, there is no problem in that the V2X message received from the V2X UE is transmitted to the co-located L-GW and the V2X server in the same eNB. The V2X server present in the eNB may determine a V2X UE belonging to the same eNB, and may decide to send a V2X message to the V2X UE. That is, in FIG. 4, when the V2X UE transmits a V2X message to eNB1, it may be determined that the V2X message is transmitted to the co-located L-GW and V2X server in eNB1 and transmitted to the V2X UE belonging to eNB1 by the V2X server. have. However, if a V2X server present in eNB1 interprets a V2X message and determines that the V2X message should be delivered to a neighbor eNB (e.g., eNB2), a problem arises because there is currently no mechanism for transmitting the V2X message to a neighbor eNB. Can be.

5 shows an example of V2X communication via SIPTO @ LN supported by an independent L-GW. V2X communication via SIPTO @ LN of FIG. 5 corresponds to the case where the neighbor eNB is at the edge of coverage of the independent L-GW in the first use example above. Referring to FIG. 5, when a V2X UE transmits a V2X message to an eNB having an RSU function, the V2X message is delivered to a V2X server through an independent L-GW. The V2X server can determine how far the V2X message should be propagated. The V2X server may determine to send the V2X message to the V2X UE belonging to the eNB. Alternatively, the V2X server may determine that the V2X message should be propagated to the neighbor area. At this time, if a neighbor eNB having an RSU function exists at the edge of coverage of the independent L-GW, the V2X message cannot be directly transmitted to the neighbor eNB through the independent L-GW. There is currently no mechanism for sending the V2X message to neighbor eNBs.

In order to solve the above problem, according to an embodiment of the present invention, a method of transmitting a V2X message to a neighbor eNB is proposed. In the following description, for convenience, a third use example, that is, a case where the V2X server is located in an eNB including an L-GW arranged together is described as an example. However, the present invention is not limited to the third use example, but can also be applied to the first and second use examples.

(1) Step 1: The V2X UE reports a V2X message to eNB1. The V2X message is delivered to the co-located L-GW in eNB1 and then arrives at the V2X server in eNB1.

(2) Step 2: The V2X server determines an area to which the V2X message should propagate.

(3) Step 3: The V2X server communicates with the L-GW co-located via internal signaling or SGi interface to inform the L-GW whether the V2X message should be propagated to the neighbor eNB. To this end, the V2X server can send additional indicators to the L-GW. The additional indicator may indicate whether the V2X message should be propagated to a neighbor eNB.

(4) Step 4: Upon receiving the additional indicator from the V2X server, the L-GW communicates with eNB1 via internal signaling or interface to inform eNB1 that the V2X message should be sent to a neighbor eNB. The L-GW may send the additional indicator to eNB1.

(5) Step 5: Upon receiving the additional indicator from the L-GW, eNB1 may know whether the V2X message should be sent to a neighbor eNB (eg, eNB2). eNB1 may convert the V2X message into a protocol data unit (PDU) and send the PDU to eNB2 via a new or existing X2 control plane message. The V2X message in the PDU may be transparent to eNB1 and eNB2. That is, the V2X message may be encapsulated in a PDU. An additional indicator may be added to the PDU to inform eNB2 that the PDU should be sent to the corresponding L-GW of eNB2. The additional indicator may be realized by a new information element (IE) or a new message in the X2AP message.

Alternatively, a user plane based approach may also be possible to send the V2X message to eNB2. Specifically, eNB1 may transmit a request message for establishing a GPRS tunneling protocol (GTP) tunnel to eNB2 to transmit the V2X message. An additional indicator may be added to the request message. Alternatively, a new message can be used as the additional indicator. Upon receiving the request message, eNB2 provides a response message including GTP tunnel information. Then, eNB1 may send the V2X message to eNB2 based on the established UP path.

(6) Step 6: Upon receiving the X2AP message including the V2X message and the additional indicator, eNB2 may check the additional indicator to check whether the V2X message should be propagated. eNB2 may deliver the X2AP message to the L-GW co-located within eNB2. The L-GW may communicate with a V2X server in eNB2.

(7) Step 7: The V2X server may make a decision and then establish a PDN connection or a multimedia broadcast multicast services (MBMS) session to transmit the V2X message to the UEs under the control coverage area.

In step S100, the eNB receives a V2X message from the V2X UE. In step S110, the eNB delivers the V2X message to the V2X server through the L-GW. The L-GW is an independent L-GW, and the V2X server may be located outside of the eNB. This corresponds to the first use example described above. Alternatively, the L-GW may be an L-GW co-located in the eNB, and the V2X server may be located outside the eNB. This corresponds to the second use example described above. Alternatively, the L-GW and the V2X server may be co-located within the eNB. This corresponds to the third use example described above.

In step S120, the eNB receives an indicator indicating that the V2X message will be sent to the neighbor eNB. The indicator may be generated by the V2X server and may be received by the eNB via the L-GW.

Upon receiving an indicator indicating that the V2X message will be sent to a neighbor eNB, in step S130, the eNB sends the V2X message to the neighbor eNB. In order to send the V2X message to the neighbor eNB, the eNB may encapsulate the V2X message in a PDU and send the PDU to the neighbor eNB. The PDU may be included in an X2AP message and transmitted to the neighbor eNB. The X2AP message may include an indicator indicating to the neighbor eNB that the PDU includes the V2X message and will be sent to the L-GW corresponding to the neighbor eNB. Alternatively, the eNB transmits a request message for establishing a GTP tunnel to the neighbor eNB, receives a response message including information about the GTP tunnel from the neighbor eNB, and receives the V2X message through the GTP tunnel. May transmit to a neighbor eNB. The request message may include an indicator indicating that the V2X message will be sent to the L-GW corresponding to the neighbor eNB.

According to the present invention, when V2X communication is performed through SIPTO @ LN, the V2X message to be propagated to the neighbor base station goes up to the core network and is transmitted through the MME, MBMS GW, MCE, etc., but instead directly through the X2 interface to the neighbor base station Can be sent. When the V2X message is transmitted to the neighbor base station through the core network, a delay occurs for each node. According to the present invention, the V2X message can be quickly transmitted to the neighbor base station without such a delay.

The first eNB 800 includes a processor 810, a memory 820, and a transceiver 830. Processor 810 may be configured to implement the functions, processes, and / or methods described herein. Layers of the air interface protocol may be implemented by the processor 810. The memory 820 is connected to the processor 810 and stores various information for driving the processor 810. The transceiver 830 is connected to the processor 810 to transmit and / or receive a radio signal.

The second eNB 900 includes a processor 910, a memory 920, and a transceiver 930. Processor 910 may be configured to implement the functions, processes, and / or methods described herein. Layers of the air interface protocol may be implemented by the processor 910. The memory 920 is connected to the processor 910 and stores various information for driving the processor 910. The transceiver 930 is connected to the processor 910 to transmit and / or receive a radio signal.

Processors

810 and 910 may include application-specific integrated circuits (ASICs), other chipsets, logic circuits, and / or data processing devices. The

memory

820, 920 may include read-only memory (ROM), random access memory (RAM), flash memory, memory card, storage medium, and / or other storage device. The

transceivers

830 and 930 may include a baseband circuit for processing radio frequency signals. When the embodiment is implemented in software, the above-described technique may be implemented as a module (process, function, etc.) for performing the above-described function. The module may be stored in the

memory

820, 920 and executed by the

processor

810, 910. The

memories

820 and 920 may be inside or outside the

processors

810 and 910, and may be connected to the

processors

810 and 910 by various well-known means.

In the exemplary system described above, methods that may be implemented in accordance with the above-described features of the present invention have been described based on a flowchart. For convenience, the methods have been described as a series of steps or blocks, but the claimed features of the present invention are not limited to the order of the steps or blocks, and some steps may occur in the same order or in a different order than the other steps. In addition, those skilled in the art will appreciate that the steps shown in the flowcharts are not exclusive and that other steps may be included or one or more steps in the flowcharts may be deleted without affecting the scope of the present invention.

Claims

In a method for transmitting a vehicle-to-everything (V2X) message by an eNB (eNodeB) in a wireless communication system,

Receive a V2X message from a V2X user equipment (UE);

Forward the V2X message to a V2X server via a local gateway (L-GW);

Receive an indicator indicating that the V2X message will be sent to a neighbor eNB; And

Sending the V2X message to the neighbor eNB.
The method of claim 1,

The L-GW is an independent L-GW,

The V2X server is located outside of the eNB.
The method of claim 1,

The L-GW is an L-GW co-located in the eNB,

The V2X server is located outside of the eNB.
The method of claim 1,

The L-GW and the V2X server are collocated together in the eNB.
The method of claim 1,

Sending the V2X message to the neighbor eNB,

Encapsulating the V2X message in a protocol data unit (PDU);

Transmitting the PDU to the neighbor eNB.
The method of claim 5, wherein

The PDU is included in an X2AP message and transmitted to the neighbor eNB.
The method of claim 6,

The X2AP message includes an indicator indicating to the neighbor eNB that the PDU includes the V2X message and will be sent to the L-GW corresponding to the neighbor eNB.
The method of claim 1,

Sending the V2X message to the neighbor eNB,

Send a request message to a neighbor eNB to establish a GPRS tunneling protocol (GTP) tunnel;

Receive a response message from the neighbor eNB including information about the GTP tunnel; And

And transmitting the V2X message to the neighbor eNB via the GTP tunnel.
The method of claim 8,

The request message includes an indicator indicating that the V2X message will be sent to the L-GW corresponding to the neighbor eNB.
In an eNB (eNodeB) in a wireless communication system,

Memory; And

Including a processor connected to the memory,

The processor,

Receive a V2X message from a vehicle-to-everything (V2X) user equipment (UE),

The V2X message is delivered to a V2X server through a local gateway (L-GW),

Receive an indicator indicating that the V2X message will be sent to a neighbor eNB, and

The V2X message is transmitted to the neighbor eNB.
The method of claim 10,

The L-GW is an independent L-GW,

The V2X server is located outside of the eNB.
The method of claim 10,

The L-GW is an L-GW co-located in the eNB,

The V2X server is located outside of the eNB.
The method of claim 10,

The L-GW and the V2X server are collocated together in the eNB.
The method of claim 10,

Sending the V2X message to the neighbor eNB,

Encapsulate the V2X message in a protocol data unit (PDU),

And sending the PDU to the neighbor eNB.
The method of claim 14,

The PDU is included in an X2AP message and is transmitted to the neighbor eNB.