Source base station, target base station, and methods thereof
The base station and wireless terminal configuration facilitates V2X service provisioning by exchanging support information and settings, addressing the lack of clear procedures in existing technologies and ensuring seamless V2X communication.
Patent Information
- Application Number
- JP2023210956
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2015-09-18
- Filing Date
- 2023-12-14
- Publication Date
- 2025-07-15
- Estimated Expiration
- 2036-06-21
AI Technical Summary
Existing technologies do not provide clear procedures for provisioning V2X services for wireless terminals such as vehicle UEs, pedestrian UEs, or RSUs, which are essential for Vehicle-to-Everything (V2X) communication.
A base station apparatus and wireless terminal configuration that includes processors to transmit and receive V2X support information and settings, enabling V2X communication by exchanging V2X support information and terminal information between the wireless terminal and the serving network.
Enables the realization of V2X service provisioning procedures for wireless terminals, ensuring seamless V2X communication by configuring appropriate settings and resources for V2X services.
Smart Images

Figure 0007708164000001 
Figure 0007708164000002 
Figure 0007708164000003
Abstract
Description
Technical Field
[0001] The present disclosure relates to a wireless communication system, and particularly to V2X services.
Background Art
[0002] Non-Patent Document 1 describes use cases and potential requirements for Long Term Evolution (LTE)-based Vehicle-to-Everything (V2X) services. V2X means 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 is communication or service between User Equipments (UEs) mounted on vehicles and using V2V applications. V2I communication or V2I service means communication or service between a UE and a Road Side Unit (RSU), both using V2I applications. Unless otherwise specified, V2I communication includes Infrastructures-to-Vehicle (I2V) communication. Also, the UE here includes not only vehicle UEs but also pedestrian UEs. An RSU is an entity installed on the roadside and supports V2I services including transmission and reception with vehicle UEs using V2I applications. The RSU is implemented in a base station such as LTE (i.e., Evolved Node B (eNB)) or a stationary UE. V2P communication or V2P service means communication or service between a vehicle UE and a pedestrian UE, both using V2I applications. V2P communication may be performed via an RSU and is sometimes called V2I2P communication or P2I2V communication.
[0003] Introduce several use cases related to the V2I service described in Non-Patent Document 1. Non-Patent Document 1 describes a configuration in Section 5.6 V2I Emergency Stop Use Case where both the vehicle and the RSU implement Prose-enabled UEs and the vehicle and the RSU 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 Prose-enabled UEs in proximity. In this use case, vehicle A sends a message indicating an event such as an emergency stop to the service RSU. The service RSU receives the message from vehicle A and relays the message to surrounding vehicles. All vehicles located within the transmission range of the service RSU can receive the message.
[0004] In the use case described in Section 5.14 V2X Road safety service via infrastructure of Non-Patent Document 1, RSU C detects that an accident has occurred within the area it manages, notifies the occurrence of the accident to a remote server (Traffic Safety Server (TSS) or Intelligent Transport Systems (ITS) server), and starts transmitting the information within the area. The server notifies the RSUs near RSU C that an accident has occurred within the area managed by RSU C. The nearby RSUs start transmitting V2X messages indicating that an accident has occurred within the area indicated by RSU C.
Prior Art Documents
Non-Patent Documents
[0005]
Non-Patent Document 1
Summary of the Invention
Problems to be Solved by the Invention
[0006] Non-Patent Document 1 does not show specific procedures for starting V2X services. That is, the procedures for performing provisioning for V2X services for a UE that uses V2X services, such as a vehicle UE, a pedestrian UE, or an RSU having UE functions, are not clear.
[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 the realization of procedures for performing provisioning for V2X services for a wireless terminal that uses V2X services. It should be noted that this objective is only one of the multiple objectives to be achieved by the embodiments disclosed in this specification. Other objectives or problems and novel features will be clarified from the description of this specification or the accompanying drawings.
Means for Solving the Problems
[0008] In a first aspect, the base station apparatus includes at least one radio transceiver and at least one processor. The at least one processor is configured to transmit, via the at least one radio transceiver, V2X support information indicating that a Vehicle-to-Everything (V2X) service is supported by a serving network including the base station apparatus, and to transmit V2X settings to the first wireless terminal in response to receiving V2X terminal information transmitted from the first wireless terminal that has received the V2X support information.
[0009] In a second aspect, the method in the base station apparatus includes: (a) transmitting V2X support information indicating that a Vehicle-to-Everything (V2X) service is supported by a serving network including the base station apparatus; and (b) transmitting V2X settings to the first wireless terminal in response to receiving V2X terminal information transmitted from the first wireless terminal that has received the V2X support information.
[0010] In a third aspect, the wireless terminal includes at least one wireless transceiver and at least one processor. The at least one processor is configured to receive, from the serving network via the at least one wireless transceiver, V2X support information indicating that a Vehicle-to-Everything (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 V2X settings transmitted from the serving network in response to transmitting the V2X terminal information, and perform V2X communication according to the V2X settings.
[0011] In a fourth aspect, the method in the wireless terminal includes: (a) receiving, from the serving network, V2X support information indicating that a Vehicle-to-Everything (V2X) service is supported by the serving network; (b) transmitting V2X terminal information indicating an interest in the V2X service to the serving network in response to receiving the V2X support information; and (c) receiving V2X settings transmitted from the serving network in response to transmitting the V2X terminal information and performing V2X communication according to the V2X settings.
[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 are configured to transmit V2X support information indicating that a Vehicle-to-Everything (V2X) service is supported by the cellular communication network. The control entity is configured to transmit V2X settings to the first wireless terminal via the one or more base stations in response to receiving V2X terminal information transmitted from the 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, from a base station, V2X support information indicating that a Vehicle-to-Everything (V2X) service is supported by the cellular communication network; and (b) in response to receiving, via the one or more base stations, V2X terminal information transmitted from a first wireless terminal that has received the V2X support information, transmitting, from a control entity, V2X settings to the first wireless terminal via the one or more base stations.
[0014] In a seventh aspect, a program includes a set 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.
Advantages of the Invention
[0015] According to the above aspects, it is possible to provide an apparatus, a method, and a program that contribute to the realization of a procedure for performing provisioning for a V2X service for a wireless terminal that uses the V2X service.
Brief Description of the Drawings
[0016]
Figure 1
Figure 2
Figure 3
Figure 4
Figure 5
Figure 6
Figure 7
Figure 8
Figure 9
Figure 10
Figure 11
Figure 12
Mode for Carrying Out 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 denoted by the same reference numerals, and redundant descriptions are omitted as necessary for clarity of explanation.
[0018] The embodiments described below are mainly described with respect to an Evolved Packet System (EPS) that accommodates LTE and SAE (System Architecture Evolution). However, these embodiments are not limited to 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 a configuration example of a wireless communication system according to some embodiments including the first embodiment. Wireless terminals (UEs) 100 to 102 are mounted on vehicles. The vehicle UEs 100 to 102 may be implemented in an in-vehicle processing unit (e.g., a car navigation system). The vehicle UEs 100 to 102 execute a V2I application to support V2I services. The UEs 100 to 102 may support other V2X services, namely V2V services or V2P services or both.
[0020] RSU 120 and 121 are installed on the roadside. In the example of FIG. 1, RSU 120 is installed near intersection 110. RSU 120 and 121 implement, for example but not limited to, Prose-enabled UEs and may perform ProSe communication with vehicle UEs 100-102 to provide V2I services. Note that RSU 120 and 121 may operate as ProSe UE-to-Network Relay (i.e., Relay UE). ProSe UE-to-Network Relay mainly relays traffic (downlink and uplink) between a UE outside coverage (remote UE) and the network. RSU 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., ITS server or TSS) via eNB 130.
[0021] As already described, Proximity-based services (ProSe) defined in 3GPP Release 12 are 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, it can be said that ProSe is a general term for communication (or services) using at least Sidelink. In the example of FIG. 1, the communication between RSU120 operating as a UE or Relay UE and UE100 or 101, and the communication between two or more UEs may use Sidelink. Note that 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 performs Sidelink transmission using the same single carrier frequency division multiple access (SC-FDMA) as the uplink.
[0022] Server 140 communicates with UEs 100 - 102, as well as RSUs 120 and 121, that support V2X services. More specifically, server 140 communicates at the application layer with the V2X applications executed in each of UEs 100 - 102, as well as RSUs 120 and 121, via a cellular communication network that includes base station 130. In other words, the reference point between UEs 100 - 102 and server 140 may depend on the user plane of the cellular communication network, and the signaling and data between UEs 100 - 102 and server 140 may be transferred on the user plane. Similarly, the reference point between RSUs 120 and 121 and server 140 may depend on the user plane of the cellular communication network.
[0023] 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 RSU 120, server 140 may notify nearby RSUs (e.g., RSU 121) of the occurrence of an accident within the area managed by RSU 120.
[0024] Furthermore, in some implementations, to utilize the V2X services provided by the cellular communication network, UEs 100 - 102 may communicate with V2X controller 150 via base station 130 (and the core network). Additionally, RSUs 120 and 121 operating as UEs may also communicate with V2X controller 150 via base station 130 (and the core network).
[0025] The V2X controller 150 provides a logical function used for operations related to the cellular communication network (i.e., Public Land Mobile Network (PLMN)) necessary for V2X services. For example, the V2X controller 150 may authenticate or authorize the UEs 100 - 102 for V2X services. The V2X controller 150 may authenticate or authorize the RSUs 120 and 121 operating as UEs. The V2X controller 150 may be referred to as a V2X function entity.
[0026] The reference point or interface between the UEs 100 - 102 (as well as the RSUs 120 and 121) and the server 140 may depend on the user plane of the cellular communication network, and the signaling and data between the UEs 100 - 102 (as well as the RSUs 120 and 121) and the server 140 may be transferred on the said user plane.
[0027] Figure 2 shows another configuration example of a wireless communication system according to some embodiments including the first embodiment. In the example of Figure 2, each of the RSUs 220 and 221 operates as an evolved Node B (eNB).
[0028] In the configurations of FIGS. 1 and 2, some or all of UEs 100 to 102 may be pedestrian UEs. Further, in the configurations of FIGS. 1 and 2, server 140 may be collocated within the same site together with eNB 130 or RSU 220 or 221 operating as an eNB. Such a server is called a Mobile Edge Computing (MEC) server. Alternatively, server 140 may be located at a remote site geographically separated from the site of eNB 130 (or RSU 220 or 221) and communicate with eNB 130 via one or more entities (e.g., Mobility Management Entity, Packet Data Network Gateway (P-GW), and Serving Gateway (S-GW)) within the cellular communication network.
[0029] FIG. 3 is a diagram showing an example of the architecture / deployments 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, RSU 120 and 121 have UE functions, and in other implementations, RSU 220 has eNB functions. That is, in some implementations, a UE (e.g., UE 100) supporting V2X services can communicate with server 140 via path 361 passing through RSU 120 operating as a UE and eNB 130. Further or alternatively, in some implementations, as shown by path 362 in FIG. 3, a UE (e.g., UE 100) can directly connect to eNB 130 without passing through RSU 120 and communicate with server 140. Further or alternatively, in some implementations, as shown by path 363 in FIG. 3, a UE (e.g., UE 100) can connect to RSU 220 operating as an eNB and communicate with server 140 via RSU 220.
[0030] The communication 351 between the RSU 120 operating as a UE and the eNB 130 may use an individual (dedicated) carrier frequency band f1 reserved for V2X services. Alternatively, the communication 351 may use a shared frequency band (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 is also called Licensed Shared Access (LSA). Alternatively, the communication 351 may use a carrier frequency band f3 licensed to the operator of the cellular communication network. Similar to the communication 351, the communication 352 between the UE 100 and the RSU (UE) 120, the communication 353 between the UE 100 and the eNB 130, and the communication 354 between the UE 100 and the RSU 220 operating as an eNB may use any of the above-described frequency bands f1, f2, and f3. Furthermore, the communication between UEs (not shown) may also use any of the above-described frequency bands f1, f2, and f3.
[0031] Subsequently, the V2X service provisioning procedure 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, network 410 transmits V2X Support Information indicating that V2X services are supported by a serving network (cellular communication network) including eNB 130. The V2X Support Information is transmitted by eNB 130 or RSU 220 operating as an eNB. Further, the V2X Support Information may be transmitted by an RSU operating as a UE. In this case, the RSU may broadcast or multicast some or all of the V2X Support Information received from eNB 130.
[0033] The V2X Support Information may indicate at least one of (a) that the V2X service is available, (b) the carrier frequency band used for the V2X service, (c) the measurement configuration of the carrier frequency band used for the V2X service, (d) the type of V2X service supported (e.g., V2V, V2I, V2P), and (e) the transmission power permitted for the wireless terminal for the V2X service. Note that (a) that the V2X service is available may be implicitly indicated by the transmission of the V2X Support Information. Also, together with (b) the carrier frequency band used for the V2X service, a network identifier (e.g., PLMN identity list) or an area identifier (e.g., V2X area list) for which the V2X service is provided may be transmitted.
[0034] Additionally or alternatively, the V2X support information may indicate a radio resource pool used for autonomous resource selection by each UE for V2X services. The radio resource pool may include radio resource pools for each type of one or more V2X services included in the V2X service (e.g., V2V, V2I, V2P), for each V2X operation mode of the RSU operating as a UE (e.g., relay mode, direct mode), for each V2X service area, for each UE device type (e.g., RSU, Vehicle, Pedestrian), or for each pre-set category (e.g., speed, (moving) driving direction, lane). The radio resource pool may be set 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] eNB 130 or RSU (eNB) 220 may broadcast the V2X support information within the cell provided by eNB 130 or RSU (eNB) 220 so that a plurality of UEs in at least the idle state (e.g., RRC_IDLE) can receive the V2X support information. eNB 130 or 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 on both a first carrier frequency band used for cellular communication (e.g., the frequency band f3 licensed to the cellular operator) and a second carrier frequency band used for V2X services (e.g., the individual frequency band f1 for V2X). In some implementations, if the V2X support information is transmitted on both of these two frequency bands, the information transmitted on one frequency band (e.g., the frequency band f3 licensed to the cellular operator) may be prioritized over the information transmitted on the other frequency band (e.g., the individual frequency band f1 for V2X).
[0038] In some implementations, when the UE 100 is out-of-coverage of the cellular communication network, the UE 100 may use the V2X support information transmitted on the individual 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 multicast (at least a part of) the V2X support information on the individual frequency band f1 for V2X services, or forward (relay) it to the UE 100. Alternatively, the UE 100 may use pre-stored settings (e.g., pre-configured radio resources for V2X).
[0039] In step 402 of FIG. 4, the UE 100 or the RSU 120 transmits V2X terminal information indicating an interest in V2X services, that is, V2X UE Information, to the network 410 in response to the reception of the V2X support information.
[0040] The V2X UE information may indicate at least one of (a) the UE 100 or the RSU 120 is interested in the V2X service, (b) the UE 100 or the RSU 120 wishes to use the V2X service, (c) the frequency band supported by the UE 100 or the RSU 120 for the V2X service, (d) the frequency band available for the UE 100 or the RSU 120 to use for the V2X service, (e) the V2X service type (e.g., V2V, V2I, V2P) in which the UE 100 or the RSU 120 is interested, and (f) the device type of the UE 100 or the RSU 120 (e.g., RSU, Vehicle, Pedestrian).
[0041] Additionally or alternatively, the V2X UE information may include an RSU indication. The RSU indication indicates whether the source UE is an RSU. Further, the RSU indication may include the type of the RSU. The type of the RSU may indicate the type of the road where the RSU is installed (e.g., the uphill lane, the downhill lane, under the viaduct, above the viaduct, on the ground, underground, a general road, or a highway). Note that the RSU indication may be sent from the Mobility Management Entity (MME) to the eNB (i.e., eNB 130 or the RSU (eNB) 220) using an E-RAB SETUP REQUEST message or an INITIAL CONTEXT SETUP REQUEST message.
[0042] Note that the V2X UE information may be transmitted in the procedure of establishing a control connection (e.g., 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 V2X UE information (e.g., RSU display), the eNB 130 may send information (e.g., RSU Indicator) indicating that the message is related to the RSU 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 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 generation of the V2X configuration based on the V2X UE information transmitted from the UE 100 or the RSU 120 may be performed by the eNB 130 or the RSU 220 operating as an eNB, or may be performed 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] Note that the V2X configuration may be transmitted in any of the individual carrier frequency bands f1 reserved for V2X services, the shared frequency band f2 for LSA, and the carrier frequency band f3 licensed to the operator of the cellular communication network. Further, the V2X configuration may be transmitted from the RSU120. For example, the RSU (UE) 120 may receive the V2X configuration transmitted from the eNB130 and group-cast (at least a part of) the V2X configuration in the individual frequency band f1 for V2X services, or transfer (relay) it to the UE100.
[0045] In some implementations, the V2X configuration may indicate measurement settings for the carrier frequency band used for V2X services. In some implementations, the V2X configuration may include radio resource settings for V2X services. The radio resource settings may include either or both of the settings of the Data Radio Bearer (DRB) and the Signalling Radio Bearer (SRB). The DRB settings may include at least one of the elements listed below: · Settings of the Physical Multicast Channel (PMCH) for Multimedia Broadcast / Multicast Service (MBMS); · Settings of the Physical Downlink Shared Channel (PDSCH) 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 used for the spontaneous resource selection for the V2X service by the UE 100 or the RSU 120. The V2X configuration may indicate the allocation of individual radio resources for the V2X service for the UE 100 or the RSU 120.
[0047] For example, in response to receiving from the RSU 120 the V2X UE information including the RSU indication indicating that the source UE is the RSU, the network 410 may transmit to the RSU 120 the V2X configuration indicating the allocation of the radio resources reserved for the RSU. Or, in response to receiving from a higher-level device (e.g., MME) of the network 410 a notification indicating that the target UE is the RSU and sending the notification to a lower-level device (e.g., eNB), the network 410 may transmit to the RSU 120 the V2X configuration indicating the allocation of the radio resources reserved for the RSU. Thereby, the network 410 can distinguish the RSU 120 operating as a UE from the normal UE 100, and can allocate radio resources (e.g., frequencies) different from those radio resources (e.g., frequencies) allocated to the normal UE 100 to the RSU 120 operating as a UE.
[0048] Additionally or alternatively, network 410 may send an RSU Configuration to RSU120 indicating how RSU120 should operate as an RSU. The RSU Configuration may be sent in an RRC Connection Reconfiguration message. Further, the RSU Configuration may include at least a part of the V2X configuration. Additionally, the RSU Configuration may implicitly or explicitly indicate to RSU120 whether RSU120 should send V2X report messages to the network (e.g., eNB) as a Relay UE, or whether RSU120 should send V2X report messages to the network (e.g., eNB) in response to receiving V2V messages as a V2X UE. When indicating implicitly, RSU120 may determine based on whether the RSU Configuration includes radio resource configuration information (e.g., Radio Resource Configuration) necessary to operate as a Relay UE. For example, if the radio resource configuration information is included, RSU120 may operate as a Relay UE, and if the radio resource configuration information is not included, RSU120 may operate as a V2V UE. Also, when indicating explicitly, the RSU Configuration may indicate the operation mode of the RSU. The operation mode may be, for example, Relay UE mode, V2V UE mode, etc.
[0049] Here, an area where the same V2X configuration is applied may be defined as a V2X Service Area (SA). The V2X SA may be defined in any of an individual carrier frequency band f1 secured for V2X services, a shared frequency band f2 for LSA, and a carrier frequency band f3 licensed to an operator of a cellular communication network. For example, a cell is defined in the frequency band f3, and the V2X SA may be defined in the frequency band f1 or f2. The V2X SA may be defined independently of a cell or may be defined in association with a cell. In the former case, there may be multiple V2X SAs within a single cell, or there may be one V2X SA spanning multiple cells (i.e., covering at least partially each of the multiple cells). In the latter case, one V2X SA may be defined by one cell or a combination of multiple cells. Further, when a UE moves between cells belonging to the same V2X SA (performs cell reselection or handover), the UE may continue without interrupting the V2X service, or may interrupt during the execution of cell reselection or handover but resume immediately after completion. That is, the V2X SA can be considered as the "Valid area" of the V2X configuration. Information on 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, eNB130 or RSU(eNB)220 may transmit the V2X configuration in the frequency band f3, and the information on the V2X SA may be included therein. In this case, further, RSU(UE)120 may transmit the information on the V2X SA in the frequency band f1 or f2. RSU(UE)120 may broadcast or multicast the information on the V2X SA, or may transfer (relay) it to UE100.
[0050] According to the procedure described with reference to FIG. 4, UE100 or RSU120 operating as a UE can perform the provisioning necessary to start the V2X service.
[0051] <Second Embodiment> In this embodiment, a specific example of handover of a UE supporting V2X services is described. In the example shown in FIG. 1, the UE 100 may perform a handover from a source cell provided by the eNB 130S to a target cell provided by the eNB 130T. Similarly, in the example shown in FIG. 2, the UE 100 may perform a handover from a source cell provided by the RSU (eNB) 220 to a target cell provided by the RSU (eNB) 221.
[0052] FIG. 5 is a sequence diagram showing a process 500 which is an example of a handover procedure according to this embodiment. In step 501, the UE 100 is connected to the source eNB 130S (or RSU 220) and performs V2X services (V2X communication). In step 502, the UE 100 transmits a measurement report to the source eNB 130S (or RSU 220). The measurement report is transmitted when the measurement values by the UE 100 meet a predetermined handover event condition.
[0053] In step 503, the source eNB 130S (or RSU 220) determines the handover of 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 the following: the UE 100 is interested in V2X services, is permitted to use V2X services, is authenticated for V2X services, and is approved for V2X services.
[0054] In step 504, in response to receiving the handover request, the target eNB 130T (or RSU 221) sends a handover response (Handover Request ACK) indicating acceptance of the handover to the source eNB 130S (or RSU 220). The handover response includes V2X settings regarding the target cell provided by the target eNB 130T (or RSU 221).
[0055] In step 505, the source eNB 130S (or RSU 220) transmits a handover command (RRC Connection Reconfiguration message) including V2X settings related to the target cell to the UE 100 in order to instruct the UE 100 to perform a handover to the target cell. The V2X settings may include information on the V2X services provided in the target cell, or the V2X service area information (e.g., V2X SA Index (ID)) included in (or including) the target cell.
[0056] In step 506, in response to receiving the handover command (RRC Connection Reconfiguration message), the UE 100 performs a switch to the target eNB 130T (or RSU 221). That is, the UE 100 performs a random access procedure to the target eNB 130T (or RSU 221) to establish synchronization with the target cell, and transmits a handover confirmation (Handover Confirm) message (RRC Connection Reconfiguration Complete message) to the target eNB 130T (or RSU 221).
[0057] In step 507, the UE 100 transmits V2X UE information to the target eNB 130T (or RSU 221). Note that the V2X UE information of the UE 100 may be sent from the source eNB 130S (or RSU 220) to the target eNB 130T (or 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 services (V2X communication) in the target cell provided by the target eNB 130T (or RSU 221).
[0059] As described above, in the present embodiment, the source eNB 130S (or RSU 220) is configured to send a V2X indication regarding the UE 100 to the target eNB 130T (or RSU 221) in the handover preparation procedure (i.e., step 503). Further, when the target eNB 130T (or RSU 221) accepts a handover request including a V2X indication, it is configured to send the V2X setting of the target cell to the source eNB 130S (or RSU 220) in the handover preparation procedure (i.e., step 504). Therefore, according to the handover procedure according to the present embodiment, the UE 100 can continue the V2X service even after the handover. Note that the UE 100 may continue the V2X service even during the execution of the handover. For example, when the same V2X service is provided in the target cell (or eNB 130T) and the source cell (or eNB 130S) of the handover, or when the target cell and the source cell are included in the same V2X service area (V2X SA), the UE 100 may continue the V2X service.
[0060] <Third Embodiment> In the present embodiment, some specific examples of message transfer related to V2X are described. FIG. 6 shows a first example of message transfer. In the example of FIG. 6, the RSU (UE) 120 generates V2X report information 670 based on the notification 660 in response to the reception of the notification 660 from the vehicle UE 100, 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 including the content of the notification 660. The RSU (UE) 120 may send the V2X report information 670 when the content of the notification 660 satisfies a predetermined condition (for example, 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 for transmitting the notification 660, and transmit the V2X report information 670 when detecting a predetermined content type.
[0063] The notification 660 may be, for example, a message regarding an emergency stop or accident of the vehicle on which the UE 100 is mounted, a message regarding the driving status of the vehicle, or a message regarding the surrounding road conditions (e.g., traffic jam, weather, accident, obstacle on the road), but is not limited thereto. The UE 100 may include in the notification 660 a V2V message received from another vehicle (UE) via V2V communication or a message derived therefrom. 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 an individual message (e.g., Uu UL) from the UE 100 to the RSU(UE) 120, and the RSU(UE) 120 may receive the individual message as the notification 660.
[0064] Note that the RSU(UE) 120 may autonomously generate the V2X report information 670 without relying on the reception of the notification 660 from the vehicle UE 100. For example, the RSU(UE) 120 may monitor the road conditions (e.g., traffic jam, weather, accident, obstacle on the road) in the management area using sensors such as a camera and a weather meter, and generate the V2X report information 670 based on the monitoring result.
[0065] In some implementations, the RSU (UE) 120 may send the V2X reporting information 670 to the server 140 in the user plane (U-plane). In this case, the eNB 130 may simply (transparently) forward the V2X reporting information 670. Alternatively, in some implementations, the RSU (UE) 120 may send the V2X reporting information 670 in the control plane (C-plane). In this case, in response to receiving the V2X reporting information 670 from the RSU (UE) 120, the eNB 130 may generate a V2X report message including the V2X reporting information 670, and send the generated V2X report message to the server 140. The eNB 130 may send the V2X report message in the control plane (C-plane) or in 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 regarding road conditions (e.g., occurrence of an accident or traffic jam), or a detour guidance. The server 140 transmits the V2X control message 680 so that a plurality of vehicle UEs including the vehicle UEs 100 to 102 can receive it. In the example of FIG. 6, the V2X control message 680 is transmitted from the server 140 to the RSU(UEs) 120 and 121 via the eNB 130, and is transmitted to the vehicle UEs 100 to 102 by each RSU(UE). Each RSU may transmit the V2X control message 680 to each UE by unicast, or may transmit the V2X control message 680 to a plurality of UEs by groupcast, multicast, or broadcast. Here, the groupcast mentioned may be, for example, a communication in which the receiving side (e.g., UE) determines whether the information to be received is information to be received by a predetermined filtering process, and restores the information if it is the information to be received. The predetermined filtering may include, for example, the UE restoring a group identifier inserted into the layer 2 header and determining whether it is the group identifier to be received. Note that the group identifier may be set in advance in the receiving side (e.g., UE), or may be notified from the transmitting side (e.g., eNB, application server). Furthermore, the group identifier may be information indicating a predetermined group (e.g., a group of UEs), or may be a V2X SA Index (ID).
[0067] The second example shown in FIG. 7 shows a delivery path of the V2X control message 680 different from the delivery 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 to 102 without passing through the RSU(UEs) 120 and 121. For example, the eNB 130 may broadcast / multicast the V2X control message 680 so that a plurality of UEs located within the cell provided by itself can receive it.
[0068] In some implementations, eNB 130 may send the V2X control message 680 in the user plane (U-plane). Specifically, eNB 130 may send 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 sent 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 sent to multiple UEs via a common MRB (or PTM radio bearer).
[0069] Alternatively, in some implementations, the eNB 130 may send the V2X control message 680 on the control plane (C-plane). The eNB 130 may send the V2X control message 680 on the Broadcast Control Channel (BCCH) that carries the System Information Block (SIB). For example, the Public Warning System (PWS) for CBS in 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 Korea, and the EU-ALERT used in European countries as PWS. In PWS, the warning messages (Primary Notification and Secondary Notification) are sent in SIB 10 and SIB 11. Note that when the V2X control message 680 is sent on the C-plane, it may be sent from the server 140 to the eNB 130 via the MME. In this case, the V2X control message may be sent in the WRITE-REPLACE WARNING REQUEST message.
[0070] Figure 8 shows a third example of message transfer. In the example of Figure 8, RSU 120 and 121 operate as ProSe UE-to-Network Relay (i.e., Relay UE). RSU 120 and 121 operating as ProSe UE-to-Network Relay (Relay UE) transparently pass through without terminating the application layer of vehicle UE 100 (ProSe Remote UE). Therefore, in the example of Figure 8, RSU 100 transfers the application layer V2X report information 870 received from vehicle UE 100 to eNB 130. That is, the V2X report information 870 from vehicle UE 100 is relayed by RSU 120 as Relay UE and eNB 130 and finally reaches server 140. In response to the reception of the V2X report information 870, server 140 generates a V2X control message 880 and transmits this to a plurality of UEs 100 to 102. The V2X control message 880 may be transmitted to the plurality of UEs 100 to 102 via eNB 130 and RSU 120 or 121. Alternatively, similar to the second example described with reference to Figure 7, the V2X control message 880 may be directly transmitted from eNB 130 to the plurality of UEs 100 to 102 without passing through RSU 10 and 121.
[0071] Figure 9 shows a fourth example of message transfer. In the example of Figure 9, each of RSU 220 and 221 operates as a base station (eNB). In response to the reception of notification 960 from vehicle UE 100, RSU (eNB) 220 generates V2X report information 970 based on the notification 960 and sends the generated V2X report information 970 to server 140. Here, the notification 960 may be an individual message (e.g., Uu UL) from UE 100 to RSU (eNB) or a V2V message. Also, RSU (eNB) 220 may transmit the V2X report information 970 in the control plane (C-plane) or in the 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 in FIGS. 6 and 7, the server 140 transmits the V2X control message 980 so that a plurality of vehicle UEs including the vehicle UEs 100 to 102 can receive it. However, in the example of FIG. 9, the V2X control message 980 is transmitted from the server 140 to the RSU (eNB) 220 and 221, and is transmitted by each RSU (eNB) to the vehicle UEs 100 to 102. Similar to the eNB 130 shown in FIG. 7, the RSU (eNB) 220 and 221 may transmit the V2X control message 980 in the U-plane or in the C-plane.
[0073] FIGS. 6 to 9 show examples in which the V2X control messages 680, 880, and 980 are received by a plurality of vehicle UEs 100 to 102. However, the V2X control messages 680, 880, and 980 may be received by pedestrians (pedestrian UEs). Also, the V2X control message may include information to be received by the vehicle UE and information to be received by the pedestrian UE, and each UE may perform filtering to extract the information to be received. Furthermore, different V2X control messages for the vehicle UE and the pedestrian UE may be transmitted in different transmission modes (e.g., U-plane, C-plane).
[0074] Note that the examples of the plurality of message transfers shown in FIGS. 6 to 9 may be tried in appropriate combinations. That is, any of the three paths 361, 362, and 363 shown in FIG. 3 may be used for transferring a message from the vehicle UE 100 to the server 140. Similarly, any of the three paths 361, 362, and 363 shown in FIG. 3 may be used for transferring a message from the server 140 to the vehicle UE 100.
[0075] When the RSU (UE) 120 and eNB 130 shown in FIG. 6 and the RSU (eNB) 220 shown in FIG. 9 are used together, the eNB 130 may transfer the V2X reporting information 670 to the RSU (eNB) 220 via an inter-base station interface (e.g., X2 interface). Also, the eNB 130 may transfer the V2X control message 680 to the RSU (eNB) 220 via an inter-base station interface (e.g., X2 interface).
[0076] Subsequently, hereinafter, configuration examples of the UEs 100 to 102, RSUs 120 and 220, eNB 130, server 140, and V2X controller 150 described in the above-described multiple embodiments will be described. FIG. 10 is a block diagram showing a configuration example of the eNB 130. The RSU 220 operating as an eNB may also have the same configuration as 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 to communicate with UEs. The RF transceiver 1001 may include a plurality of transceivers. The RF transceiver 1001 is coupled to the antenna 1002 and the processor 1004. The RF transceiver 1001 receives modulation symbol data (or OFDM symbol data) from the processor 1004, generates a transmission RF signal, and supplies the transmission RF signal to the antenna 1002. Also, the RF transceiver 1001 generates a baseband reception signal based on the reception RF signal received by the antenna 1002 and supplies this to the processor 1004.
[0077] The network interface 1003 is used to communicate with network nodes (e.g., other eNBs, Mobility Management Entity (MME), Serving Gateway (S-GW), and 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] Processor 1004 performs data plane processing and control plane processing including digital baseband signal processing for wireless communication. For example, in the case of LTE and LTE-Advanced, the digital baseband signal processing by processor 1004 may include signal processing of the PDCP layer, RLC layer, MAC layer, and PHY layer. Further, the signal processing by processor 1004 may include signal processing of the GTP-U·UDP / IP layer at the X2-U interface and S1-U interface. Also, the control plane processing by processor 1004 may include processing of the X2AP protocol, S1-MME protocol, and RRC protocol.
[0079] Processor 1004 may include a plurality of processors. For example, 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·UDP / IP layer at the X2-U interface and S1-U interface, and a protocol stack processor (e.g., CPU or MPU) that performs control plane processing.
[0080] Memory 1005 is composed of a combination of volatile memory and non-volatile memory. Memory 1005 may physically include a plurality of independent memory devices. The volatile memory is, for example, Static Random Access Memory (SRAM) or Dynamic RAM (DRAM) or a combination thereof. The non-volatile memory is Mask Read Only Memory (MROM), Electrically Erasable Programmable ROM (EEPROM), flash memory, or a hard disk drive, or any combination thereof. Memory 1005 may include storage located away from processor 1004. In this case, processor 1004 may access memory 1005 via network interface 1003 or an I / O interface (not shown).
[0081] Memory 1005 may store software modules (computer programs) including instruction groups and data for performing the processing by eNB 130 described in the above-described multiple embodiments. In some implementations, processor 1004 may be configured to perform the processing of eNB 130 described in the above embodiments by reading and executing the software modules from memory 1005.
[0082] FIG. 11 is a block diagram showing a configuration example of an RSU 120 operating as a UE (or Relay UE). UEs 101-102 may also have a configuration similar to that of FIG. 11. A Radio Frequency (RF) transceiver 1101 performs analog RF signal processing to communicate with an 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 transmission RF signal, and supplies the transmission RF signal to the antenna 1102. Also, the RF transceiver 1101 generates a baseband reception signal based on the reception RF signal received by the antenna 1102 and supplies this 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. The digital baseband signal processing includes (a) data compression / decompression, (b) data segmentation / concatenation, (c) generation / decomposition of a transmission format (transmission frame), (d) channel coding / decoding, (e) modulation (symbol mapping) / demodulation, and (f) generation of OFDM symbol data (baseband OFDM signal) by Inverse Fast Fourier Transform (IFFT), etc. On the other hand, the control plane processing includes communication management of layer 1 (e.g., transmission 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 the Packet Data Convergence Protocol (PDCP) layer, Radio Link Control (RLC) layer, MAC layer, and PHY layer. Also, the control plane processing by the baseband processor 1103 may include processing of the Non-Access Stratum (NAS) protocol, RRC protocol, and MAC CE.
[0085] The baseband processor 1103 may include a modem processor (e.g., Digital Signal Processor (DSP)) that performs digital baseband signal processing and a protocol stack processor (e.g., Central Processing Unit (CPU) or 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 described later.
[0086] The application processor 1104 is also referred to as a CPU, MPU, microprocessor, or processor core. The application processor 1104 may include a plurality of processors (a plurality of processor cores). The application processor 1104 realizes various functions of the RSU 120 by executing a system software program (Operating System (OS)) and various application programs (e.g., call application, WEB browser, mailer, camera operation application, music playback application) read from the memory 1106 or a memory not shown.
[0087] In some implementations, as shown by the dashed line (1105) in FIG. 11, the baseband processor 1103 and the application processor 1104 may be integrated on one chip. In other words, the baseband processor 1103 and the application processor 1104 may be implemented as one System on Chip (SoC) device 1105. The SoC device may also be referred to as a system Large Scale Integration (LSI) or a chipset.
[0088] The memory 1106 is a volatile memory, a non-volatile memory, or a combination thereof. The memory 1106 may physically include a plurality of independent memory devices. The volatile memory is, for example, a Static Random Access Memory (SRAM), a Dynamic RAM (DRAM), or a combination thereof. The non-volatile memory is a Mask Read Only Memory (MROM), an Electrically Erasable Programmable ROM (EEPROM), a flash memory, or 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 include an embedded memory device integrated within the baseband processor 1103, within the application processor 1104, or within the SoC 1105. Further, the memory 1106 may include the memory within a Universal Integrated Circuit Card (UICC).
[0089] Memory 1106 may store a software module (computer program) including a set of instructions and data for performing the processing by the RSU 120 described in the above-described embodiments. In some implementations, the baseband processor 1103 or the application processor 1104 may be configured to perform the processing of the RSU 120 described in the above-described embodiments by reading and executing the software module from the memory 1106.
[0090] FIG. 12 is a block diagram showing a configuration example of the server 140. The V2X controller 150 may also have the same configuration as that shown in 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., eNodeB 130, MME, 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 program) from the memory 1203 to perform the processing of the server 140 described in the above-described embodiments using the sequence diagrams and flowcharts. The processor 1202 may be, for example, a microprocessor, an MPU, or a CPU. The processor 1202 may include a plurality of processors.
[0092] The memory 1203 is composed of a combination of volatile memory and non-volatile memory. The memory 1203 may include storage located away from the processor 1202. In this case, the processor 1202 may access the memory 1203 via an I / O interface (not shown).
[0093] In the example of FIG. 12, the memory 1203 is used to store a group of software modules. The processor 1202 can perform the processing of the server 140 described in the above embodiments by reading out and executing these groups of software modules from the memory 1203.
[0094] As described with reference to FIGS. 10 to 12, each of the processors of the UE 100 to 102, the RSU 120 and 320, the eNB 130, the server 140, and the V2X controller 150 in the above embodiments executes one or more programs including a group of instructions for causing a computer to perform the algorithms described with reference to the drawings. This program can be stored using various types of non-transitory computer readable media and supplied to a computer. Non-transitory computer readable media include various types of tangible storage media. Examples of non-transitory computer readable media include magnetic recording media (e.g., flexible disks, magnetic tapes, hard disk drives), magneto-optical recording media (e.g., magneto-optical disks), Compact Disc Read Only Memory (CD-ROM), CD-R, CD-R / W, semiconductor memories (e.g., mask ROM, Programmable ROM (PROM), Erasable PROM (EPROM), flash ROM, Random Access Memory (RAM)). Also, the program may be supplied to a computer by various types of transitory computer readable media. Examples of transitory computer readable media include electrical signals, optical signals, and electromagnetic waves. Transitory computer readable media can supply the program to a computer via wired communication paths such as electric wires and optical fibers, or wireless communication paths.
[0095] <Other Embodiments> In the configuration shown in FIG. 1, each of the RSU 120 and 121 may operate to periodically transmit 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 the occurrence of a failure of the RSU when it fails to receive a keep-alive or heartbeat message from a certain RSU.
[0096] The above-described embodiments mainly described LTE / LTE-Advanced and its improvements. However, the above-described embodiments may be applied to other wireless communication networks or systems.
[0097] Furthermore, the above-described embodiments are merely examples regarding the application of the technical idea obtained by the present inventor. That is, the technical idea is not limited to only the above-described embodiments, and it goes without saying that various changes are possible.
[0098] This application claims priority based on Japanese Patent Application No. 2015-185290 filed on September 18, 2015, and incorporates the entire disclosure thereof herein.
Description of Reference Numerals
[0099] 100~102 UE 120, 121 RSU 130 eNB 140 Server 150 V2X Controller 220, 221 RSU 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 including information about the authentication status of the wireless terminal for Vehicle-to-Everything (V2X) service to a target base station for handover of the wireless terminal; Means for receiving a handover request positive response message including V2X settings indicating area information of the V2X service from the target base station; A source base station comprising the above.
2. The V2X settings further indicate the V2X service, The source base station according to claim 1.
3. Further comprising means for transmitting an Radio Resource Control (RRC) message including the V2X settings to the wireless terminal, The source base station according to claim 1 or 2.
4. Transmitting a handover request message including information about the authentication status of the wireless terminal for Vehicle-to-Everything (V2X) service to a target base station for handover of the wireless terminal, and Receiving a handover request positive response message including V2X settings indicating area information of the V2X service from the target base station, A method of a source base station comprising the above.
5. The V2X settings further indicate the V2X service, The method according to claim 4.
6. Further comprising transmitting an Radio Resource Control (RRC) message including the V2X settings to the wireless terminal, The method according to claim 4 or 5.
7. Means for receiving a handover request message including information about the authentication status of the wireless terminal for Vehicle-to-Everything (V2X) service from a source base station for handover of the wireless terminal; Means for transmitting a handover request positive response message including V2X settings indicating area information of the V2X service to the source base station; A target base station comprising the above.
8. The V2X settings further indicate the V2X service, The target base station according to claim 7.
9. Receiving a handover request message including information about the authentication status of the wireless terminal for Vehicle-to-Everything (V2X) service from a source base station for handover of the wireless terminal, and Transmitting a handover request positive response message including V2X settings indicating area information of the V2X service to the source base station, A method for a target base station, comprising: Claim 10 The V2X settings further indicate the V2X service, The method according to claim 9.
Citation Information
Patent Citations
Method and apparatus for performing handover in vehicle communication environment
US20150065142A1
Fast access in v2v communication services by dynamic resources allocation
US20150195827A1
Vehicle gateway access in cellular network for vehicle communications
WO2014015470A1
Method and apparatus for authorizing vehicle UE and RSU UE in wireless communication system
WO2017014536A1