Source base station, target base station, and method for these base stations

By configuring base stations and wireless terminals to exchange V2X support and terminal information, the patent facilitates efficient provisioning and continuous V2X communication, addressing the lack of clear procedures in existing technologies.

JP2025126260APending Publication Date: 2025-08-28NEC CORP
View PDF 1 Cites 0 Cited by

Patent Information

Application Number
JP2025105672
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Priority Date
2015-09-18
Filing Date
2025-06-23
Publication Date
2025-08-28

AI Technical Summary

Technical Problem

Existing technologies do not provide a clear procedure for provisioning wireless terminals, such as vehicle UEs and RSUs, to support V2X services, including V2V, V2I, and V2P communications.

Method used

A base station device and wireless terminal are configured to transmit and receive V2X support information and configurations, enabling them to perform V2X communication by exchanging V2X support and terminal information over dedicated or shared frequency bands, and utilizing radio resource pools and synchronization settings.

Benefits of technology

Enables efficient provisioning of V2X services by ensuring seamless communication between vehicles and infrastructure, supporting various communication types and maintaining service continuity during handovers.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2025126260000001_ABST
    Figure 2025126260000001_ABST
Patent Text Reader

Abstract

To contribute to achievement of procedures for performing provisioning for a vehicle-to-everything (V2X) service for a radio terminal that uses the V2X service.SOLUTION: A source base station transmits, to a target base station, a handover request message that is for handover of a radio terminal and includes information on an authentication state of the radio terminal related to a V2X service, and receives, from the target base station, a handover request acknowledgement message that includes V2X settings indicating area information of the V2X service.SELECTED DRAWING: Figure 5
Need to check novelty before this filing date? Find Prior Art

Description

[Technical Field]

[0001] The present disclosure relates to wireless communication systems, and in particular to V2X services. [Background technology]

[0002] Non-Patent Document 1 describes use cases and potential requirements for Long Term Evolution (LTE)-based Vehicle-to-Everything (V2X) services. V2X refers to vehicular communications and includes Vehicle-to-Vehicle (V2V) communication, Vehicle-to-Infrastructure (V2I) communication, and Vehicle-to-Pedestrian (V2P) communication. V2V communication or V2V service refers to communication or service between User Equipments (UEs) installed in vehicles and using a V2V application. V2I communication or V2I service refers to communication or service between a UE and a Road Side Unit (RSU), both of which use a V2I application. Unless otherwise specified, V2I communication includes Infrastructure-to-Vehicle (I2V) communication. Note that UE here refers not only to vehicle UEs but also to pedestrian UEs. An RSU is an entity installed on the roadside that supports V2I services, including transmission and reception with vehicular UEs that use V2I applications. The RSU is implemented in a base station (i.e., an Evolved Node B (eNB)) such as an LTE base station, or a stationary UE. V2P communication or V2P service refers to communication or service between a vehicular UE and a pedestrian UE, both of which use V2I applications. V2P communication may be performed via an RSU and is sometimes referred to as V2I2P communication or P2I2V communication.

[0003] We introduce some use cases related to the V2I service described in Non-Patent Document 1. Non-Patent Document 1 describes in Section 5.6, V2I Emergency Stop Use Case, a configuration in which both a vehicle and an RSU implement Prose-enabled UEs and perform Proximity-based services (Prose) communication. ProSe communication is an example of device-to-device (D2D) communication and includes direct communication between two or more nearby ProSe-enabled UEs. In this use case, vehicle A transmits a message indicating an event, such as an emergency stop, to a serving RSU. The serving RSU receives the message from vehicle A and relays it to surrounding vehicles. All vehicles located within the transmission range of the serving RSU can receive the message.

[0004] In the use case described in Section 5.14 "V2X Road safety service via infrastructure" in Non-Patent Document 1, RSU C detects that an accident has occurred in an area it manages, notifies a remote server (Traffic Safety Server (TSS) or Intelligent Transport Systems (ITS) server) of the accident, and starts transmitting the information within the area. The server notifies RSUs nearby RSU C that an accident has occurred in the area managed by RSU C. The nearby RSUs start transmitting V2X messages indicating that an accident has occurred in the area indicated by RSU C. [Prior art documents] [Non-patent literature]

[0005] [Non-Patent Document 1] 3GPP S1-151330 “3GPP TR 22.885 V0.2.0 Study on LTE Support for V2X Services (Release 14)”, April 2015 Summary of the Invention [Problem to be solved by the invention]

[0006] Non-Patent Document 1 does not disclose a specific procedure for starting a V2X service, that is, it does not clarify a procedure for provisioning a UE that uses the V2X service, such as a vehicle UE, a pedestrian UE, or an RSU with a UE function, for the V2X service.

[0007] One of the objectives to be achieved by the embodiments disclosed in this specification is to provide an apparatus, a method, and a program that contribute to realizing a procedure for provisioning a wireless terminal that uses a V2X service for the V2X service. It should be noted that this objective is only one of multiple objectives to be achieved by the embodiments disclosed in this specification. Other objectives or problems and novel features will become apparent from the description of this specification or the accompanying drawings. [Means for solving the problem]

[0008] In a first aspect, a base station device includes at least one radio transceiver and at least one processor configured to transmit, via the at least one radio transceiver, Vehicle-to-Everything (V2X) support information indicating that a V2X service is supported by a serving network including the base station device, and to transmit a V2X configuration to a first radio terminal in response to receiving V2X terminal information transmitted from the first radio terminal that has received the V2X support information.

[0009] In a second aspect, a method in a base station device includes: (a) transmitting Vehicle-to-Everything (V2X) support information indicating that a V2X service is supported by a serving network including the base station device; and (b) transmitting a V2X configuration to a first wireless terminal in response to receiving V2X terminal information transmitted from the first wireless terminal that received the V2X support information.

[0010] In a third aspect, a wireless terminal includes at least one wireless transceiver and at least one processor, wherein the at least one processor is configured to receive, via the at least one wireless transceiver, vehicle-to-everything (V2X) support information from a serving network indicating that the V2X service is supported by the serving network, transmit V2X terminal information indicating an interest in the V2X service to the serving network in response to receiving the V2X support information, receive a V2X configuration transmitted from the serving network in response to transmitting the V2X terminal information, and perform V2X communication in accordance with the V2X configuration.

[0011] In a fourth aspect, a method in a wireless terminal includes: (a) receiving Vehicle-to-Everything (V2X) support information from a serving network indicating that a V2X service is supported by the serving network; (b) transmitting V2X terminal information to the serving network indicating interest in the V2X service in response to receiving the V2X support information; and (c) receiving a V2X configuration transmitted from the serving network in response to transmitting the V2X terminal information, and conducting V2X communication in accordance with the V2X configuration.

[0012] In a fifth aspect, a cellular communication network includes one or more base stations and a control entity, the one or more base stations configured to transmit Vehicle-to-Everything (V2X) support information indicating that V2X service is supported by the cellular communication network, and the control entity configured to transmit a V2X configuration to the first wireless terminal via the one or more base stations in response to receiving V2X terminal information transmitted from a first wireless terminal that has received the V2X support information.

[0013] In a sixth aspect, a method in a cellular communication network includes: (a) transmitting Vehicle-to-Everything (V2X) support information from a base station indicating that V2X service is supported by the cellular communication network; and (b) in response to receiving V2X terminal information transmitted from a first wireless terminal that received the V2X support information via the one or more base stations, transmitting a V2X configuration from a control entity to the first wireless terminal via the one or more base stations.

[0014] In a seventh aspect, a program includes a group of instructions (software code) that, when loaded into a computer, causes the computer to perform the method according to the second or fourth aspect described above. [Effects of the Invention]

[0015] According to the above-described aspects, it is possible to provide an apparatus, a method, and a program that contribute to realizing a procedure for performing provisioning for a V2X service on a wireless terminal that uses the V2X service. [Brief explanation of the drawings]

[0016] [Figure 1] 1 is a diagram illustrating an example of the configuration of a wireless communication system according to an embodiment. [Figure 2] 1 is a diagram illustrating an example of the configuration of a wireless communication system according to an embodiment. [Figure 3]1 illustrates an example architecture / deployments of a wireless communication system according to an embodiment. [Figure 4] FIG. 10 is a sequence diagram illustrating an example of a provisioning procedure for a V2X service according to the embodiment. [Figure 5] FIG. 10 is a sequence diagram illustrating an example of a handover procedure according to an embodiment. [Figure 6] FIG. 2 is a diagram illustrating a first example of message transfer in the wireless communication system according to the embodiment. [Figure 7] FIG. 10 is a diagram illustrating a second example of message transfer in the wireless communication system according to the embodiment. [Figure 8] FIG. 10 is a diagram illustrating a third example of message transfer in the wireless communication system according to the embodiment. [Figure 9] FIG. 10 is a diagram illustrating a fourth example of message transfer in the wireless communication system according to the embodiment. [Figure 10] FIG. 2 is a block diagram illustrating an example configuration of an RSU and a base station according to an embodiment. [Figure 11] FIG. 2 is a block diagram illustrating an example configuration of an RSU and a wireless terminal according to an embodiment. [Figure 12] FIG. 2 is a block diagram illustrating an example configuration of a server and a V2X controller according to the embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0017] Hereinafter, specific embodiments will be described in detail with reference to the drawings. In each drawing, the same or corresponding elements are designated by the same reference numerals, and for clarity of explanation, duplicate explanations will be omitted as necessary.

[0018] The following embodiments are described primarily with respect to the Evolved Packet System (EPS) that includes LTE and SAE (System Architecture Evolution). However, these embodiments are not limited to the EPS and may be applied to other mobile communication networks or systems, such as 3GPP (registered trademark) UMTS, 3GPP2 CDMA2000 systems (1xRTT, HRPD (High Rate Packet Data)), global system for mobile communications (GSM (registered trademark)) / General packet radio service (GPRS) systems, and WiMAX systems.

[0019] First Embodiment FIG. 1 shows an example of the configuration of a wireless communication system according to some embodiments including the first embodiment. Wireless terminals (UEs) 100-102 are mounted on vehicles. The vehicle UEs 100-102 may be implemented in an on-board processing unit (e.g., a car navigation system). The vehicle UEs 100-102 execute a V2I application to support a V2I service. The UEs 100-102 may also support other V2X services, i.e., V2V services, V2P services, or both.

[0020] The RSUs 120 and 121 are installed on the roadside. In the example of FIG. 1, the RSU 120 is installed near an intersection 110. The RSUs 120 and 121 may each implement, for example, but not limited to, a Prose-enabled UE and perform ProSe communication with the vehicle UEs 100-102 to provide V2I services. The RSUs 120 and 121 may also function as a ProSe UE-to-Network Relay (i.e., Relay UE). The ProSe UE-to-Network Relay mainly relays traffic (downlink and uplink) between an out-of-coverage UE (remote UE) and a network. The RSUs 120 and 121 communicate with a base station (eNB) 130 in a cellular communication network via a wireless connection and further communicate with a server 140 (e.g., an ITS server or TSS) via the eNB 130.

[0021] As already explained, Proximity-based services (ProSe) defined in 3GPP Release 12 is an example of D2D communication. D2D communication includes at least one of Direct Communication and Direct Discovery. In 3GPP Release 12, the radio link between UEs used for Direct Communication or Direct Discovery is called the PC5 interface or Sidelink. Therefore, ProSe can be said to be a general term for communication (or services) that use at least Sidelink. In the example of FIG. 1, communication between the UE or RSU 120 acting as a Relay UE and the UE 100 or 101, as well as communication between two or more UEs, may use Sidelink. In 3GPP Release 12, Sidelink transmission uses the same frame structure as the Long Term Evolution (LTE) frame structure defined for uplink and downlink, and uses a subset of uplink resources in the frequency and time domains. In 3GPP Release 12, the UE transmits the sidelink using Single Carrier Frequency Division Multiple Access (SC-FDMA) similar to the uplink.

[0022] The server 140 communicates with the UEs 100-102 and the RSUs 120 and 121 that support the V2X service. More specifically, the server 140 communicates at an application layer with a V2X application running in each of the UEs 100-102 and the RSUs 120 and 121 via a cellular communication network including the base station 130. In other words, a reference point between the UEs 100-102 and the server 140 may depend on a user plane of the cellular communication network, and signaling and data between the UEs 100-102 and the server 140 may be transferred on the user plane. Similarly, a reference point between the RSUs 120 and 121 and the server 140 may depend on a user plane of the cellular communication network.

[0023] The server 140 may be an ITS server or a TSS. For example, in response to receiving report information indicating the occurrence of some accident from the RSU 120, the server 140 may notify RSUs (e.g., RSU 121) near the RSU 120 that an accident has occurred in an area managed by the RSU 120.

[0024] Furthermore, in some implementations, to utilize V2X services provided by a cellular communication network, the UEs 100-102 may communicate with the V2X controller 150 via the base station 130 (and the core network). Furthermore, the RSUs 120 and 121 operating as UEs may also communicate with the V2X controller 150 via the base station 130 (and the core network).

[0025] The V2X controller 150 provides logical functions used for operations related to a cellular communication network (i.e., a Public Land Mobile Network (PLMN)) required for the V2X service. For example, the V2X controller 150 may perform authentication or authorization of the UEs 100 to 102 for the V2X service. The V2X controller 150 may perform authentication or authorization of the RSUs 120 and 121 operating as UEs. The V2X controller 150 may also be referred to as a V2X function entity.

[0026] The reference point or interface between the UEs 100-102 (and RSUs 120 and 121) and the server 140 may depend on the user plane of the cellular communication network, and signaling and data between the UEs 100-102 (and RSUs 120 and 121) and the server 140 may be transferred on the user plane.

[0027] 2 shows another example configuration of a wireless communication system according to some embodiments including the first embodiment. In the example of FIG. 2, each of the RSUs 220 and 221 operates as a base station (eNB).

[0028] 1 and 2, some or all of the UEs 100 to 102 may be pedestrian UEs. Furthermore, in the configurations of FIGS. 1 and 2, the server 140 may be co-located within the same site with the eNB 130 or the RSU 220 or 221 operating as an eNB. Such a server is called a Mobile Edge Computing (MEC) server. Alternatively, the server 140 may be located at a remote site geographically separated from the site of the eNB 130 (or the RSU 220 or 221) and communicate with the eNB 130 via one or more entities (e.g., a Mobility Management Entity, a Packet Data Network Gateway (P-GW), and a Serving Gateway (S-GW)) in a cellular communication network.

[0029] 3 is a diagram illustrating an example of an architecture / deployment of a wireless communication system according to some embodiments, including the first embodiment. As described with reference to FIGS. 1 and 2, in some implementations, the RSUs 120 and 121 have the functionality of a UE, and in other implementations, the RSU 220 has the functionality of an eNB. That is, in some implementations, a UE (e.g., UE 100) supporting a V2X service can communicate with the server 140 via a path 361 passing through the RSU 120 acting as a UE and the eNB 130. Additionally or alternatively, in some implementations, as shown by a path 362 in FIG. 3, the UE (e.g., UE 100) can directly connect to the eNB 130 without going through the RSU 120 and communicate with the server 140. Additionally or alternatively, in some implementations, the UE (e.g., UE 100) can connect to the RSU 220 acting as an eNB and communicate with the server 140 via the RSU 220. As shown by a path 363 in FIG. 3, the UE (e.g., UE 100) can connect to the RSU 220 acting as an eNB and communicate with the server 140 via the RSU 220.

[0030] Communication 351 between the RSU 120 operating as a UE and the eNB 130 may use a dedicated carrier frequency band f1 reserved for V2X services. Alternatively, communication 351 may use a shared frequency band (shared spectrum) f2 that is not licensed to any operator or is shared by multiple operators. Communication using such a shared frequency band is also called Licensed Shared Access (LSA). Alternatively, communication 351 may use a carrier frequency band f3 licensed to an operator of a cellular communication network. Similar to communication 351, communication 352 between the UE 100 and the RSU (UE) 120, communication 353 between the UE 100 and the eNB 130, and communication 354 between the UE 100 and the RSU 220 operating as an eNB may also use any of the above-mentioned frequency bands f1, f2, and f3. Furthermore, communications between UEs (not shown) may also use any of the above-mentioned frequency bands f1, f2, and f3.

[0031] Next, a provisioning procedure for a V2X service will be described below. Fig. 4 is a sequence diagram showing a process 400 that is an example of the provisioning procedure. The network 410 includes at least the eNB 130 in the configuration example of Fig. 1, and includes at least the RSU 220 operating as an eNB in ​​the configuration example of Fig. 2. The network 410 may further include a V2X controller 150.

[0032] In step 401, the network 410 transmits V2X support information indicating that a V2X service is supported by a serving network (cellular communication network) including the eNB 130. The V2X support information is transmitted by the eNB 130 or the RSU 220 operating as an eNB. Furthermore, the V2X support information may be transmitted by an RSU operating as a UE. In this case, the RSU may broadcast or groupcast part or all of the V2X support information received from the eNB 130.

[0033] The V2X support information may indicate at least one of (a) availability of the V2X service, (b) carrier frequency bands used for the V2X service, (c) measurement configuration of the carrier frequency bands used for the V2X service, (d) supported V2X service types (e.g., V2V, V2I, V2P), and (e) transmission power permitted to the wireless terminal for the V2X service. Note that (a) availability of the V2X service may be implicitly indicated by transmitting the V2X support information. Furthermore, (b) together with the carrier frequency bands used for the V2X service, a network identifier (e.g., PLMN identity list) or an area identifier (e.g., V2X area list) in which the V2X service is provided may be transmitted.

[0034] Additionally or alternatively, the V2X support information may indicate a radio resource pool to be used for autonomous resource selection for the V2X service by each UE. The radio resource pool may include a radio resource pool for each type of V2X service (e.g., V2V, V2I, V2P) included in the V2X service, a V2X operation mode (e.g., relay mode, direct mode) of an RSU operating as a UE, a V2X service area, a device type of a UE (e.g., RSU, Vehicle, Pedestrian), or a pre-configured category (e.g., speed, direction of travel, lane). The radio resource pool may be configured for each carrier frequency band in which the V2X service is performed.

[0035] Additionally or alternatively, the V2X support information may include synchronization settings for V2X.

[0036] The eNB 130 or the RSU (eNB) 220 may broadcast the V2X support information within a cell served by the eNB 130 or the RSU (eNB) 220 so that at least multiple UEs in an idle state (e.g., RRC_IDLE) can receive the V2X support information. The eNB 130 or the RSU (eNB) 220 may transmit the V2X support information on a Broadcast Control Channel (BCCH) carrying a System Information Block (SIB).

[0037] The eNB 130 or the RSU (eNB) 220 may transmit V2X support information in both a first carrier frequency band used for cellular communication (e.g., frequency band f3 licensed to a cellular operator) and a second carrier frequency band used for V2X services (e.g., a separate frequency band f1 for V2X). In some implementations, when the V2X support information is transmitted in both of these two frequency bands, information transmitted in one frequency band (e.g., frequency band f3 licensed to a cellular operator) may be prioritized over information transmitted in the other frequency band (e.g., the separate frequency band f1 for V2X).

[0038] In some implementations, when the UE 100 is out of coverage of a cellular communication network, the UE 100 may use V2X support information transmitted in a dedicated frequency band f1 for V2X. For example, the RSU (UE) 120 may receive the V2X support information transmitted from the eNB 130 and broadcast or groupcast (at least a part of) the V2X support information in the dedicated frequency band f1 for the V2X service, or may forward (relay) the V2X support information to the UE 100. Alternatively, the UE 100 may use a pre-stored configuration (e.g., pre-configured radio resources for V2X).

[0039] In step 402 of FIG. 4, in response to receiving the V2X support information, the UE 100 or the RSU 120 transmits V2X terminal information, i.e., V2X UE Information, indicating interest in V2X services to the network 410.

[0040] The V2X UE information may indicate at least one of: (a) that the UE 100 or RSU 120 is interested in V2X services; (b) that the UE 100 or RSU 120 wishes to use V2X services; (c) frequency bands that the UE 100 or RSU 120 supports for V2X services; (d) frequency bands that the UE 100 or RSU 120 can use for the V2X services; (e) V2X service types (e.g., V2V, V2I, V2P) that the UE 100 or RSU 120 is interested in; and (f) the device type (e.g., RSU, Vehicle, Pedestrian) of the UE 100 or RSU 120.

[0041] Additionally or alternatively, the V2X UE information may include an RSU indication. The RSU indication indicates whether the source UE is an RSU. Furthermore, the RSU indication may include an RSU type. The RSU type may indicate the type of road on which the RSU is installed (e.g., uplink lane, downlink lane, underpass, onpass, ground, underground, general road, or expressway). Note that the RSU indication may be transmitted from a Mobility Management Entity (MME) to an eNB (i.e., eNB 130 or RSU (eNB) 220) using an E-RAB SETUP REQUEST message or an INITIAL CONTEXT SETUP REQUEST message.

[0042] The V2X UE information may be transmitted in a procedure for establishing a control connection (e.g., a Radio Resource Control (RRC) Connection) with the eNB 130 or the RSU (eNB) 220. For example, the UE 100 or the RSU 120 may transmit the V2X UE information using an RRC Connection Setup Complete message or UE capability signaling in the RRC connection establishment procedure. When the RSU (UE) 120 transmits the V2X UE information (e.g., an RSU indication), the eNB 130 may transmit information indicating that the message is related to an RSU (e.g., an RSU Indicator) to the MME in an S1AP INITIAL UE MESSAGE message or an E-RAB SETUP RESPONSE message.

[0043] In step 403 of FIG. 4 , the network 410 (e.g., the eNB 130, the RSU 220, or the V2X controller 150) transmits a V2X configuration to the UE 100 or the RSU 120 in response to receiving the V2X UE information from the UE 100 or the RSU 120. For example, the V2X configuration may be transmitted using an RRC Connection Reconfiguration message. The V2X configuration may be generated based on the V2X UE information transmitted from the UE 100 or the RSU 120 by the eNB 130 or the RSU 220 operating as an eNB, or by the V2X controller 150. The UE 100 or the RSU 120 receives the V2X configuration transmitted from the network 410 and performs V2X communication according to the V2X configuration.

[0044] The V2X configuration may be transmitted in any of a dedicated carrier frequency band f1 reserved for the V2X service, a shared frequency band f2 for the LSA, and a carrier frequency band f3 licensed to an operator of a cellular communication network. Furthermore, the V2X configuration may be transmitted from the RSU 120. For example, the RSU (UE) 120 may receive the V2X configuration transmitted from the eNB 130 and groupcast (at least a part of) the V2X configuration in the dedicated frequency band f1 for the V2X service, or may forward (relay) the V2X configuration to the UE 100.

[0045] In some implementations, the V2X configuration may indicate a measurement configuration of a carrier frequency band used for the V2X service. In some implementations, the V2X configuration may include a radio resource configuration for the V2X service. The radio resource configuration may include one or both of a Data Radio Bearer (DRB) configuration and a Signaling Radio Bearer (SRB) configuration. The DRB configuration may include at least one of the following elements: · Physical Multicast Channel (PMCH) configuration for Multimedia Broadcast / Multicast Service (MBMS); ·Physical Downlink Shared Channel (PDSCH) configuration for Single Cell Point to Multi-point (SC-PTM); Logical Channel ID (LCID); and ·E-UTRAN Radio Access Bearer (E-RAB) identity.

[0046] Additionally or alternatively, the V2X configuration may indicate a radio resource pool to be used for autonomous resource selection for the V2X service by the UE 100 or the RSU 120. The V2X configuration may indicate allocation of dedicated radio resources for the V2X service to the UE 100 or the RSU 120.

[0047] For example, in response to receiving, from the RSU 120, V2X UE information including an RSU indication indicating that the source UE is an RSU, the network 410 may transmit a V2X configuration indicating allocation of radio resources reserved for the RSU to the RSU 120. Alternatively, in response to receiving, from an upper device (e.g., MME) of the network 410 to a lower device (e.g., eNB) a notification indicating that the target UE is an RSU, the network 410 may transmit a V2X configuration indicating allocation of radio resources reserved for the RSU to the RSU 120. This enables the network 410 to distinguish the RSU 120 operating as a UE from a normal UE 100 and allocate radio resources (e.g., frequencies) to the RSU 120 operating as a UE that are different from the radio resources (e.g., frequencies) allocated to the normal UE 100.

[0048] Additionally or alternatively, the network 410 may transmit an RSU configuration to the RSU 120, indicating how the RSU 120 should operate as an RSU. The RSU configuration may be transmitted in an RRC Connection Reconfiguration message. Furthermore, the RSU configuration may include at least a part of the V2X configuration. Furthermore, the RSU configuration may implicitly or explicitly indicate to the RSU 120 whether the RSU 120 should transmit a V2X report message to a network (e.g., eNB) as a Relay UE or whether the RSU 120 should transmit a V2X report message to a network (e.g., eNB) in response to receiving a V2V message as a V2X UE. In the case of an implicit indication, the RSU 120 may determine whether the RSU configuration includes radio resource configuration information (e.g., Radio Resource Configuration) required to operate as a Relay UE. For example, if the radio resource configuration information is included, the RSU 120 may operate as a Relay UE, and if the radio resource configuration information is not included, the RSU 120 may operate as a V2V UE. Furthermore, if explicitly indicated, the RSU configuration may indicate the operation mode of the RSU. The operation mode may be, for example, a Relay UE mode, a V2V UE mode, etc.

[0049] Here, an area to which the same V2X configuration is applied may be defined as a V2X Service Area (SA). A V2X SA may be defined in any of an individual carrier frequency band f1 reserved for V2X services, a shared frequency band f2 for LSAs, and a carrier frequency band f3 licensed to a cellular communication network operator. For example, a cell may be defined in frequency band f3, and a V2X SA may be defined in frequency band f1 or f2. A V2X SA may be defined independently of a cell or in association with a cell. In the former case, multiple V2X SAs may exist within a cell, or one V2X SA may span multiple cells (i.e., at least partially cover each of multiple cells). In the latter case, one V2X SA may be defined by one cell or a combination of multiple cells. Furthermore, when a UE moves between cells belonging to the same V2X SA (performing cell reselection or handover), the UE may continue the V2X service without interruption, or may suspend the V2X service during cell reselection or handover and resume it as soon as it is completed. In other words, the V2X SA can be considered the "Valid Area" of the V2X configuration. Information about the V2X SA (e.g., V2X SA Index (ID)) may be transmitted as one of the information elements (IEs) included in the V2X configuration, or may be transmitted in a message or signaling separate from the V2X configuration. For example, the eNB 130 or the RSU (eNB) 220 may transmit the V2X configuration on frequency band f3, which may include information about the V2X SA. In this case, the RSU (UE) 120 may also transmit information about the V2X SA on frequency band f1 or f2. The RSU (UE) 120 may broadcast or groupcast the V2X SA information, or may forward (relay) it to the UE 100.

[0050] According to the procedure described with reference to FIG. 4, the UE 100 or the RSU 120 acting as a UE can perform the provisioning required to start the V2X service.

[0051] <Second embodiment> In this embodiment, a specific example of handover of a UE supporting V2X service will be described. In the example shown in Fig. 1, the UE 100 may perform handover from a source cell provided by an eNB 130S to a target cell provided by an eNB 130T. Similarly, in the example shown in Fig. 2, the UE 100 may perform handover from a source cell provided by an RSU (eNB) 220 to a target cell provided by an RSU (eNB) 221.

[0052] 5 is a sequence diagram showing a process 500 as an example of a handover procedure according to the present embodiment. In step 501, the UE 100 connects to the source eNB 130S (or the RSU 220) and performs a V2X service (V2X communication). In step 502, the UE 100 transmits a measurement report to the source eNB 130S (or the RSU 220). The measurement report is transmitted when the measurement value by the UE 100 matches a predetermined handover event condition.

[0053] In step 503, the source eNB 130S (or RSU 220) decides to handover the UE 100 based on the measurement report and sends a handover request including a V2X indication to the target eNB 130T (or RSU 221). The V2X indication indicates at least one of that the UE 100 is interested in the V2X service, is authorized to use the V2X service, is authenticated for the V2X service, and is authorized for the V2X service.

[0054] In step 504, in response to receiving the handover request, the target eNB 130T (or the RSU 221) sends a handover response (Handover Request ACK) indicating acceptance of the handover to the source eNB 130S (or the RSU 220). The handover response includes a V2X configuration for the target cell served by the target eNB 130T (or the RSU 221).

[0055] In step 505, the source eNB 130S (or the RSU 220) transmits a handover command (RRC Connection Reconfiguration message) including a V2X configuration for the target cell to instruct the UE 100 to perform handover to the target cell. The V2X configuration may include information on a V2X service provided in the target cell or a V2X service area (e.g., a V2X SA Index (ID)) that the target cell includes (or is included in).

[0056] In step 506, in response to receiving the handover command (RRC Connection Reconfiguration message), the UE 100 switches to the target eNB 130T (or the RSU 221). That is, the UE 100 performs a random access procedure to the target eNB 130T (or the RSU 221) to establish synchronization with the target cell, and transmits a handover confirm message (RRC Connection Reconfiguration Complete message) to the target eNB 130T (or the RSU 221).

[0057] In step 507, the UE 100 transmits the V2X UE information to the target eNB 130T (or the RSU 221). Note that the V2X UE information of the UE 100 may be sent from the source eNB 130S (or the RSU 220) to the target eNB 130T (or the RSU 221) in step 503. In this case, the transmission of the V2X UE information in step 507 may be omitted.

[0058] In step 508, the UE 100 performs V2X service (V2X communication) in the target cell provided by the target eNB 130T (or the RSU 221).

[0059] As described above, in this embodiment, the source eNB130S (or the RSU220) is configured to send a V2X indication regarding the UE100 to the target eNB130T (or the RSU221) in the handover preparation procedure (i.e., step 503). Furthermore, the target eNB130T (or the RSU221) is configured to send a V2X configuration of the target cell to the source eNB130S (or the RSU220) in the handover preparation procedure (i.e., step 504) if the target eNB130T (or the RSU221) accepts the handover request including the V2X indication. Therefore, according to the handover procedure of this embodiment, the UE100 can continue the V2X service even after the handover. Note that the UE100 may continue the V2X service even during the handover. For example, if the same V2X service is provided in the target cell (or eNB130T) and source cell (or eNB130S) of the handover, or if the target cell and source cell are included in the same V2X service area (V2X SA), the UE 100 may continue the V2X service.

[0060] <Third embodiment> In this embodiment, several specific examples of message forwarding related to V2X will be described. Fig. 6 shows a first example of message forwarding. In the example of Fig. 6, in response to receiving a notification 660 from the vehicle UE 100, the RSU (UE) 120 generates V2X report information 670 based on the notification 660 and sends the generated V2X report information 670 to the server 140 via the eNB 130.

[0061] For example, the RSU (UE) 120 may analyze (or detect) the content of the notification 660 at the application layer and generate V2X report information 670 that includes the content of the notification 660. The RSU (UE) 120 may transmit the V2X report information 670 when the content of the notification 660 satisfies a predetermined condition (e.g., when the content of the notification 660 relates to a predetermined category, group, or service).

[0062] Alternatively, the RSU (UE) 120 may detect the content type (e.g., category, group, or service) of the notification 660 using a Layer 2 header (e.g., Medium Access Control (MAC) header) used to transmit the notification 660, and transmit the V2X report information 670 if a predetermined content type is detected.

[0063] The notification 660 may be, for example, but is not limited to, a message regarding an emergency stop or an accident of a vehicle in which the UE 100 is installed, a message regarding the vehicle's driving status, or a message regarding surrounding road conditions (e.g., traffic congestion, weather, accidents, obstacles on the road). The UE 100 may include a V2V message received from another vehicle (UE) via V2V communication or a message derived therefrom in the notification 660. Note that the notification 660 may be a V2V message transmitted from the UE 100 to another (unspecified) UE, and the RSU (UE) 120 may receive the V2V message as the notification 660. Alternatively, the notification 660 may be a dedicated message (e.g., Uu UL) from the UE 100 to the RSU (UE) 120, and the RSU (UE) 120 may receive the dedicated message as the notification 660.

[0064] Note that the RSU (UE) 120 may autonomously generate the V2X report information 670 without relying on receiving the notification 660 from the vehicle UE 100. For example, the RSU (UE) 120 may monitor road conditions (e.g., congestion, weather, accidents, obstacles on the road) within a management area using sensors such as a camera and a weather meter, and generate the V2X report information 670 based on the monitoring results.

[0065] In some implementations, the RSU (UE) 120 may transmit the V2X report information 670 to the server 140 on the user plane (U-plane). In this case, the eNB 130 may simply forward (transparently) the V2X report information 670. Alternatively, in some implementations, the RSU (UE) 120 may transmit the V2X report information 670 on the control plane (C-plane). In this case, in response to receiving the V2X report information 6700 from the RSU (UE) 120, the eNB 130 may generate a V2X report message including the V2X report information 670 and transmit the generated V2X report message to the server 140. The eNB 130 may transmit the V2X report message on the control plane (C-plane) or the user plane (U-plane).

[0066] In response to receiving the V2X report information 670 from the RSU (UE) 120, the server 140 generates a V2X control message 680 based on the V2X report information 670. The V2X control message 680 may include, for example, a warning about road conditions (e.g., the occurrence of an accident or congestion) or detour route guidance. The server 140 transmits the V2X control message 680 so that multiple vehicle UEs including the vehicle UEs 100 to 102 can receive the V2X control message 680. In the example of FIG. 6 , the V2X control message 680 is transmitted from the server 140 to the RSUs (UE) 120 and 121 via the eNB 130, and then transmitted by each RSU (UE) to the vehicle UEs 100 to 102. Each RSU may transmit the V2X control message 680 to each UE by unicast, or may transmit the V2X control message 680 to multiple UEs by groupcast, multicast, or broadcast. The groupcast here may be, for example, communication in which the receiving side (e.g., UE) determines whether or not the information should be received by a predetermined filtering process, and if it is, restores the information. The predetermined filtering may include, for example, the UE restoring the group identifier inserted in the Layer 2 header and determining whether or not it is a group identifier that should be received. Note that the group identifier may be configured in advance on the receiving side (e.g., UE) or may be notified by the transmitting side (e.g., eNB, application server). Furthermore, the group identifier may be information indicating a predetermined group (e.g., UE group) or may be a V2X SA Index (ID).

[0067] The second example shown in Fig. 7 illustrates a distribution path of the V2X control message 680 that is different from the distribution path shown in Fig. 6. In the example of Fig. 7, the V2X control message 680 is transmitted directly from the eNB 130 to the vehicle UEs 100-102 without passing through the RSUs (UEs) 120 and 121. For example, the eNB 130 may broadcast / multicast the V2X control message 680 so that it can be received by multiple UEs located within the cell served by the eNB 130.

[0068] In some implementations, the eNB 130 may transmit the V2X control message 680 in the user plane (U-plane). Specifically, the eNB 130 may transmit the V2X control message 680 using a broadcast bearer, a multicast bearer, or a Point-to-Multipoint (PTM) bearer. The V2X control message 680 may be transmitted on a data radio bearer for carrying MBMS data, i.e., an MBMS Radio Bearer (MRB) or a Point-to-Multipoint (PTM) Radio Bearer. In MBMS, the same data (message) is transmitted to multiple UEs via a common MRB (or PTM radio bearer).

[0069] Alternatively, in some implementations, the eNB 130 may transmit the V2X control message 680 on a control plane (C-plane). The eNB 130 may transmit the V2X control message 680 on a broadcast control channel (BCCH) carrying a system information block (SIB). For example, a public warning system (PWS) for CBS in the LTE / Evolved Packet System (EPS) may be used. 3GPP has standardized the Earthquake and Tsunami Warning System (ETWS) used in Japan, the Commercial Mobile Alert System (CMAS) used in North America, the Korean Public Alert System (KPAS) used in South Korea, and the EU-ALERT used in European countries as PWSs. In the PWS, warning messages (primary notification and secondary notification) are transmitted in SIB 10 and SIB 11. When the V2X control message 680 is transmitted on the C-plane, it may be transmitted from the server 140 to the eNB 130 via the MME. In this case, the V2X control message may be transmitted in a WRITE-REPLACE WARNING REQUEST message.

[0070] FIG. 8 shows a third example of message forwarding. In the example of FIG. 8, the RSUs 120 and 121 operate as ProSe UE-to-Network Relays (i.e., Relay UEs). The RSUs 120 and 121 operating as ProSe UE-to-Network Relays (Relay UEs) pass through the application layer of the vehicular UE 100 (ProSe Remote UE) without terminating it. Therefore, in the example of FIG. 8, the RSU 100 forwards V2X report information 870 of the application layer received from the vehicular UE 100 to the eNB 130. That is, the V2X report information 870 from the vehicular UE 100 is relayed by the RSU 120 and the eNB 130 as Relay UEs and finally reaches the server 140. In response to receiving the V2X report information 870, the server 140 generates a V2X control message 880 and transmits it to the multiple UEs 100 to 102. The V2X control message 880 may be transmitted to the multiple UEs 100-102 via the eNB 130 and the RSU 120 or 121. Alternatively, similar to the second example described with reference to FIG. 7 , the V2X control message 880 may be transmitted directly from the eNB 130 to the multiple UEs 100-102 without passing through the RSUs 10 and 121.

[0071] 9 shows a fourth example of message forwarding. In the example of FIG. 9, each of the RSUs 220 and 221 operates as a base station (eNB). In response to receiving a notification 960 from the vehicle UE 100, the RSU (eNB) 220 generates V2X report information 970 based on the notification 960 and sends the generated V2X report information 970 to the server 140. Here, the notification 960 may be a dedicated message (e.g., Uu UL) from the UE 100 to the RSU (eNB) or may be a V2V message. Furthermore, the RSU (eNB) 220 may transmit the V2X report information 970 on a control plane (C-plane) or a user plane (U-plane).

[0072] In response to receiving the V2X report information 970 from the RSU (eNB) 220, the server 140 generates a V2X control message 980 based on the V2X report information 970. Similar to the examples of FIGS. 6 and 7 , the server 140 transmits the V2X control message 980 so that multiple vehicle UEs including the vehicle UEs 100-102 can receive the V2X control message 980. However, in the example of FIG. 9 , the V2X control message 980 is transmitted from the server 140 to the RSUs (eNBs) 220 and 221, and then transmitted to the vehicle UEs 100-102 by each RSU (eNB). Similar to the eNB 130 shown in FIG. 7 , the RSUs (eNBs) 220 and 221 may transmit the V2X control message 980 on either the U-plane or the C-plane.

[0073] 6 to 9 show an example in which V2X control messages 680, 880, and 980 are received by multiple vehicle UEs 100 to 102. However, V2X control messages 680, 880, and 980 may also be received by pedestrians (pedestrian UEs). Alternatively, the V2X control messages may include information to be received by vehicle UEs and information to be received by pedestrian UEs, with each UE filtering to extract the information to be received. Furthermore, different V2X control messages for vehicle UEs and pedestrian UEs may be transmitted in different transmission formats (e.g., U-plane, C-plane).

[0074] 6 to 9 may be used in any suitable combination. That is, any of the three routes 361, 362, and 363 shown in FIG. 3 may be used to transfer a message from vehicular UE 100 to server 140. Similarly, any of the three routes 361, 362, and 363 shown in FIG. 3 may be used to transfer a message from server 140 to vehicular UE 100.

[0075] 6 and the RSU (eNB) 220 shown in FIG. 9 are used together, the eNB 130 may forward V2X report information 670 to the RSU (eNB) 220 via an inter-base station interface (e.g., X2 interface). The eNB 130 may also forward a V2X control message 680 to the RSU (eNB) 220 via the inter-base station interface (e.g., X2 interface).

[0076] Next, exemplary configurations of the UEs 100 to 102, the RSUs 120 and 220, the eNB 130, the server 140, and the V2X controller 150 described in the above embodiments will be described below. FIG. 10 is a block diagram showing an exemplary configuration of the eNB 130. The RSU 220 operating as an eNB may also have a configuration similar to that shown in FIG. 10. Referring to FIG. 10, the eNB 130 includes an RF transceiver 1001, a network interface 1003, a processor 1004, and a memory 1005. The RF transceiver 1001 performs analog RF signal processing for communication with UEs. The RF transceiver 1001 may include multiple transceivers. The RF transceiver 1001 is coupled to an antenna 1002 and a processor 1004. The RF transceiver 1001 receives modulation symbol data (or OFDM symbol data) from the processor 1004, generates a transmit RF signal, and provides the transmit RF signal to the antenna 1002. The RF transceiver 1001 also generates a baseband received signal based on the received RF signal received by the antenna 1002 and supplies it to the processor 1004 .

[0077] The network interface 1003 is used to communicate with network nodes (e.g., other eNBs, a Mobility Management Entity (MME), a Serving Gateway (S-GW), and a TSS or ITS server). The network interface 1003 may include, for example, a network interface card (NIC) compliant with the IEEE 802.3 series.

[0078] The processor 1004 performs data plane processing, including digital baseband signal processing, and control plane processing for wireless communication. For example, in the case of LTE and LTE-Advanced, the digital baseband signal processing by the processor 1004 may include signal processing of the PDCP layer, RLC layer, MAC layer, and PHY layer. Furthermore, the signal processing by the processor 1004 may include signal processing of the GTP-U UDP / IP layer on the X2-U interface and the S1-U interface. Furthermore, the control plane processing by the processor 1004 may include processing of the X2AP protocol, the S1-MME protocol, and the RRC protocol.

[0079] The processor 1004 may include multiple processors. For example, the processor 1004 may include a modem processor (e.g., DSP) that performs digital baseband signal processing, a processor (e.g., DSP) that performs signal processing of the GTP-U and UDP / IP layers on the X2-U interface and the S1-U interface, and a protocol stack processor (e.g., CPU or MPU) that performs control plane processing.

[0080] The memory 1005 is configured by a combination of volatile memory and nonvolatile memory. The memory 1005 may include multiple physically independent memory devices. The volatile memory is, for example, Static Random Access Memory (SRAM), Dynamic RAM (DRAM), or a combination thereof. The nonvolatile memory is, for example, Mask Read Only Memory (MROM), Electrically Erasable Programmable ROM (EEPROM), flash memory, or a hard disk drive, or any combination thereof. The memory 1005 may include storage located remotely from the processor 1004. In this case, the processor 1004 may access the memory 1005 via the network interface 1003 or an I / O interface (not shown).

[0081] The memory 1005 may store software modules (computer programs) including instructions and data for performing the processes described in the above embodiments by the eNB 130. In some implementations, the processor 1004 may be configured to read and execute the software modules from the memory 1005 to perform the processes of the eNB 130 described in the above embodiments.

[0082] FIG. 11 is a block diagram showing an example configuration of an RSU 120 operating as a UE (or Relay UE). The UEs 101 and 102 may have a configuration similar to that shown in FIG. 11. A radio frequency (RF) transceiver 1101 performs analog RF signal processing for communication with the eNB 130. The analog RF signal processing performed by the RF transceiver 1101 includes frequency up-conversion, frequency down-conversion, and amplification. The RF transceiver 1101 is coupled to an antenna 1102 and a baseband processor 1103. That is, the RF transceiver 1101 receives modulation symbol data (or OFDM symbol data) from the baseband processor 1103, generates a transmit RF signal, and provides the transmit RF signal to the antenna 1102. The RF transceiver 1101 also generates a baseband receive signal based on the receive RF signal received by the antenna 1102 and provides the baseband receive signal to the baseband processor 1103.

[0083] The baseband processor 1103 performs digital baseband signal processing (data plane processing) and control plane processing for wireless communication. Digital baseband signal processing includes (a) data compression / decompression, (b) data segmentation / concatenation, (c) transmission format (transmission frame) generation / decomposition, (d) transmission path coding / decoding, (e) modulation (symbol mapping) / demodulation, and (f) generation of OFDM symbol data (baseband OFDM signal) using Inverse Fast Fourier Transform (IFFT). Meanwhile, control plane processing includes communication management for Layer 1 (e.g., transmit power control), Layer 2 (e.g., radio resource management and hybrid automatic repeat request (HARQ) processing), and Layer 3 (e.g., signaling related to attachment, mobility, and call management).

[0084] For example, in the case of LTE and LTE-Advanced, the digital baseband signal processing by the baseband processor 1103 may include signal processing of a Packet Data Convergence Protocol (PDCP) layer, a Radio Link Control (RLC) layer, a MAC layer, and a PHY layer. Also, the control plane processing by the baseband processor 1103 may include processing of a Non-Access Stratum (NAS) protocol, an RRC protocol, and a MAC CE.

[0085] The baseband processor 1103 may include a modem processor (e.g., a Digital Signal Processor (DSP)) that performs digital baseband signal processing and a protocol stack processor (e.g., a Central Processing Unit (CPU) or a Micro Processing Unit (MPU)) that performs control plane processing. In this case, the protocol stack processor that performs control plane processing may be shared with the application processor 1104, which will be described later.

[0086] The application processor 1104 is also called a CPU, an MPU, a microprocessor, or a processor core. The application processor 1104 may include multiple processors (multiple processor cores). The application processor 1104 executes a system software program (operating system (OS)) and various application programs (e.g., a calling application, a web browser, a mailer, a camera operation application, and a music playback application) read from the memory 1106 or a memory not shown, thereby realizing various functions of the RSU 120.

[0087] In some implementations, the baseband processor 1103 and the application processor 1104 may be integrated on a single chip, as indicated by the dashed line (1105) in Figure 11. In other words, the baseband processor 1103 and the application processor 1104 may be implemented as a single System on Chip (SoC) device 1105. An SoC device may also be called a system Large Scale Integration (LSI) or a chipset.

[0088] The memory 1106 is volatile memory, nonvolatile memory, or a combination thereof. The memory 1106 may include multiple physically independent memory devices. The volatile memory may be, for example, static random access memory (SRAM), dynamic RAM (DRAM), or a combination thereof. The nonvolatile memory may be mask read only memory (MROM), electrically erasable programmable ROM (EEPROM), flash memory, a hard disk drive, or any combination thereof. For example, the memory 1106 may include an external memory device accessible from the baseband processor 1103, the application processor 1104, and the SoC 1105. The memory 1106 may also include an internal memory device integrated within the baseband processor 1103, the application processor 1104, or the SoC 1105. Furthermore, the memory 1106 may include memory within a universal integrated circuit card (UICC).

[0089] The memory 1106 may store software modules (computer programs) including instructions and data for performing the processes described in the above-described embodiments by the RSU 120. In some implementations, the baseband processor 1103 or the application processor 1104 may be configured to read and execute the software modules from the memory 1106 to perform the processes of the RSU 120 described in the above-described embodiments.

[0090] Fig. 12 is a block diagram showing a configuration example of the server 140. The V2X controller 150 may also have a configuration similar to that of Fig. 12. Referring to Fig. 12, the server 140 includes a network interface 1201, a processor 1202, and a memory 1203. The network interface 1201 is used to communicate with network nodes (e.g., the eNodeB 130, the MME, and the P-GW). The network interface 1201 may include, for example, a network interface card (NIC) compliant with the IEEE 802.3 series.

[0091] The processor 1202 reads and executes software (computer programs) from the memory 1203 to perform the processing of the server 140 described using sequence diagrams and flowcharts in the above-described embodiments. The processor 1202 may be, for example, a microprocessor, an MPU, or a CPU. The processor 1202 may include multiple processors.

[0092] The memory 1203 is configured by a combination of volatile memory and non-volatile memory. The memory 1203 may include storage located remotely from the processor 1202. In this case, the processor 1202 may access the memory 1203 via an I / O interface (not shown).

[0093] 12, the memory 1203 is used to store software modules. The processor 1202 reads and executes these software modules from the memory 1203, thereby performing the processing of the server 140 described in the above embodiment.

[0094] As described with reference to FIGS. 10 to 12 , each of the processors included in the UEs 100 to 102, the RSUs 120 and 320, the eNB 130, the server 140, and the V2X controller 150 in the above-described embodiments executes one or more programs including instructions for causing a computer to execute the algorithms described with reference to the drawings. The programs can be stored and provided to a computer using various types of non-transitory computer-readable media. Non-transitory computer-readable media include various types of tangible storage media. Examples of non-transitory computer-readable media include magnetic storage media (e.g., flexible disks, magnetic tapes, hard disk drives), magneto-optical storage media (e.g., magneto-optical disks), compact disc read-only memories (CD-ROMs), CD-Rs, CD-R / Ws, and semiconductor memories (e.g., mask ROMs, programmable ROMs (PROMs), erasable PROMs (EPROMs), flash ROMs, and random access memories (RAMs)). The program may be provided to the computer by various types of transitory computer-readable media. Examples of transitory computer-readable media include electrical signals, optical signals, and electromagnetic waves. The transitory computer-readable media may provide the program to the computer via a wired communication path such as an electrical wire or optical fiber, or via a wireless communication path.

[0095] <Other embodiments> 1, each of the RSUs 120 and 121 may operate to periodically send a keep-alive message or a heartbeat message to the eNB 130 or the server 140. The eNB 130 or the server 140 may detect a failure of an RSU when it fails to receive a keep-alive or heartbeat message from the RSU.

[0096] Although the above-described embodiments are mainly described in relation to LTE / LTE-Advanced and its improvements, the above-described embodiments may also be applied to other wireless communication networks or systems.

[0097] Furthermore, the above-described embodiments are merely examples of application of the technical ideas obtained by the inventors of the present invention. In other words, the technical ideas are not limited to the above-described embodiments, and various modifications are possible.

[0098] This application claims priority based on Japanese Patent Application No. 2015-185290, filed September 18, 2015, the disclosure of which is incorporated herein in its entirety. [Explanation of symbols]

[0099] 100~102UE 120, 121 RSUs 130 eNB 140 servers 150 V2X Controller 220, 221 RSUs 1001 RF Transceiver 1004 processor 1101 RF Transceiver 1103 Baseband Processor 1104 Application Processor 1202 processor 1203 memory

Claims

1. means for transmitting a handover request message to a target base station for handover of a wireless terminal and including information about an authentication status of the wireless terminal with respect to a Vehicle-to-Everything (V2X) service; means for receiving a handover request acknowledgement message from the target base station, the handover request acknowledgement message including a V2X configuration indicating area information of the V2X service; A source base station comprising:

2. sending a handover request message to a target base station for handover of the wireless terminal and including information about an authentication status of the wireless terminal with respect to a Vehicle-to-Everything (V2X) service; and receiving a handover request acknowledgement message from the target base station, the handover request acknowledgement message including a V2X configuration indicating area information of the V2X service; A method for a source base station comprising:

3. means for receiving, from a source base station, a handover request message for a handover of a wireless terminal and including information about an authentication status of the wireless terminal with respect to a Vehicle-to-Everything (V2X) service; means for transmitting a handover request acknowledgement message to the source base station, the handover request acknowledgement message including a V2X configuration indicating area information of the V2X service; A target base station comprising:

4. receiving a handover request message from a source base station for a handover of a wireless terminal and including information about an authentication status of the wireless terminal with respect to a Vehicle-to-Everything (V2X) service; and sending a handover request acknowledgement message to the source base station, the handover request acknowledgement message including a V2X configuration indicating area information of the V2X service; A method for a target base station, comprising:

Citation Information

Patent Citations

  • Source base station, target base station, and method thereof

    JP2024015404A