Base station device, wireless terminal and method thereof

Abstract

The present application discloses a base station device, a radio terminal and a method thereof. A source base station sends a handover request message for handover of a mobile terminal to a target base station, the handover request message including information about the authorization status of the mobile terminal for a vehicle and all V2X services. The target base station sends a handover request response message to the source base station. Therefore, for example, it can help to implement a process for performing settings of V2X services on a mobile terminal that intends to use V2X services.

Description

[0001] This application is a divisional application of invention patent application 201680054240.7 entitled "Base station device, radio terminal and method thereof" after PCT international application PCT / JP2016 / 002979 with a priority date of September 18, 2015 and a filing date of June 21, 2016 entered China. Technical Field

[0002] The present disclosure relates to radio communication systems, and in particular to V2X services. Background Art

[0003] Non-patent document 1 discloses use cases and potential requirements for vehicle-to-everything (V2X) services based on long-term evolution (LTE). V2X means vehicle communication, 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 equipment (UE) installed in a vehicle and using a V2V application. V2I communication or V2I service is communication or service between a UE and a roadside unit (RSU) both using a V2I application. Unless otherwise specified, V2I communication includes infrastructure-to-vehicle (I2V) communication. In addition, the term "UE" used in this article includes not only UEs installed in vehicles, but also UEs carried by pedestrians. RSU is an entity located on the side of the road and supports V2I services, including sending and receiving with vehicle UEs using V2I applications. The RSU is installed in a base station such as an LTE base station (ie, an evolved Node B (eNB)), or in a fixed UE. V2P communication or V2P service is communication or service between a vehicle UE and a pedestrian UE, both of which use V2I applications. V2P communication can be performed via the RSU and is therefore referred to as V2I2P communication or P2I2V communication.

[0004] Here, some use cases about the V2I service disclosed in non-patent document 1 will be introduced. Non-patent document 1 discloses in Section 5.6 V2 Emergency Stop Use Case a configuration in which a vehicle and an RSU are each equipped with a Prose-enabled UE and the vehicle and the RSU perform proximity-based service (Prose) communication. ProSe communication is device-to-device (D2D) communication and includes direct communication between two or more ProSe-enabled UEs that are close to each other. In this use case, vehicle A sends a message indicating an event such as an emergency stop to the serving RSU. The serving RSU receives the message from vehicle A and then forwards the message to the vehicles around it. All vehicles within the transmission range from the serving RSU are able to receive this message.

[0005] In the use case disclosed in Section 5.14 “V2X Road Safety Services via Infrastructure” of Non-Patent Document 1, RSU C detects that an accident has occurred in an area managed by RSU C. RSU C indicates the occurrence of the accident to a remote server (e.g., a Traffic Safety Server (TSS) or an Intelligent Transportation System (ITS) server) and starts transmission of the information in the area. The server notifies other RSUs in the vicinity of RSU C that an accident has occurred in the area managed by RSU C. Other RSUs start sending V2X messages indicating that an accident has occurred in the area indicated by RSU C.

[0006] Reference List

[0007] Non-patent literature

[0008] [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

[0009] Technical issues

[0010] Non-patent document 1 does not disclose any specific procedure for starting a V2X service. Therefore, the procedure for performing the setup of a V2X service on a UE using the V2X service (such as a vehicle UE, a pedestrian UE, or an RSU having a UE function) is unclear.

[0011] One of the purposes to be achieved by the embodiments disclosed herein is to provide a device, method and program that facilitates the implementation of a process for performing settings for V2X services on a radio terminal that intends to use V2X services. It should be noted that this purpose is only one of the goals to be achieved by the embodiments disclosed herein. Other purposes or problems and novel features will become apparent from the description in the specification and the accompanying drawings.

[0012] Solutions to the problem

[0013] In a first aspect, a base station apparatus includes at least one wireless transceiver and at least one processor. The at least one processor is configured to: send V2X support information via the at least one wireless transceiver, the V2X support information indicating that a service network including the base station apparatus supports vehicle-to-everything (V2X) services; and in response to receiving V2X terminal information sent from a first radio terminal that receives the V2X support information, send a V2X configuration to the first radio terminal.

[0014] In a second aspect, a method in a base station apparatus comprises: (a) sending V2X support information indicating that a service network including the base station apparatus supports a vehicle-to-everything (V2X) service; and (b) in response to receiving V2X terminal information sent from a first radio terminal that receives the V2X support information, sending a V2X configuration to a first radio terminal.

[0015] In a third aspect, a radio terminal includes at least one wireless transceiver and at least one processor. The at least one processor is configured to: receive, via the at least one wireless transceiver, from a service network a vehicle-to-everything (V2X) support information indicating that the service network supports a V2X service; in response to receiving the V2X support information, send to the service network V2X terminal information indicating that the radio terminal is interested in the V2X service; in response to sending the V2X terminal information, receive a V2X configuration sent from the service network; and perform V2X communication according to the V2X configuration.

[0016] In a fourth aspect, a method in a radio terminal comprises: (a) receiving V2X support information from a service network, the V2X support information indicating that the service network supports vehicle-to-everything (V2X) services; (b) in response to receiving the V2X support information, sending to the service network V2X terminal information indicating that the radio terminal is interested in the V2X services; and (c) in response to sending the V2X terminal information, receiving a V2X configuration sent from the service network, and performing V2X communication according to the V2X configuration.

[0017] 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 send a vehicle-to-everything (V2X) support information indicating that the cellular communication network supports a V2X service. The control entity is configured to send a V2X configuration to a first radio terminal via the one or more base stations in response to receiving V2X terminal information sent from a first radio terminal that received the V2X support information.

[0018] In a sixth aspect, a method in a cellular communication network comprises: (a) sending, from one or more base stations, vehicle-to-everything (V2X) support information indicating that the cellular communication network supports a vehicle-to-everything (V2X) service, and (b) in response to receiving, via the one or more base stations, V2X terminal information sent from a first radio terminal that has received the V2X support information, sending a V2X configuration from a control entity to the first radio terminal via the one or more base stations.

[0019] In a seventh aspect, a program includes instructions (software codes) that, when loaded into a computer, cause the computer to execute the method according to the second or fourth aspect described above.

[0020] Advantageous Effects of the Invention

[0021] According to the above aspects, it is possible to provide an apparatus, a method, and a program that facilitate implementation of a process for performing settings for a V2X service on a radio terminal that intends to use the V2X service. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] Figure 1 is a diagram showing a configuration example of a radio communication system according to an embodiment;

[0023] Figure 2 is a diagram showing a configuration example of a wireless communication system according to an embodiment;

[0024] Figure 3 is a diagram showing an example of the architecture / deployment of a radio communication system according to an embodiment;

[0025] Figure 4 is a sequence diagram showing one example of a setup procedure for a V2X service according to an embodiment;

[0026] Figure 5 is a sequence diagram showing one example of a switching process according to an embodiment;

[0027] Figure 6 is a diagram showing a first example of message transmission in a wireless communication system according to an embodiment;

[0028] Figure 7 is a diagram showing a second example of message transmission in a wireless communication system according to an embodiment;

[0029] Figure 8 is a diagram showing a third example of message transmission in a wireless communication system according to an embodiment;

[0030] Fig. 9 is a diagram showing a fourth example of message transmission in a wireless communication system according to an embodiment;

[0031] Fig.10 is a block diagram showing a configuration example of an RSU and a base station according to an embodiment;

[0032] Fig.11 is a block diagram showing a configuration example of an RSU and a radio terminal according to an embodiment; and

[0033] Fig.12 is a block diagram showing a configuration example of a server and a V2X controller according to an embodiment. DETAILED DESCRIPTION

[0034] The specific embodiments are described in detail below with reference to the accompanying drawings. In all drawings, the same or corresponding elements are represented by the same reference numerals, and for the sake of clarity of explanation, repeated descriptions will be omitted as needed.

[0035] The following description of the embodiments mainly focuses on the Evolved Packet System (EPS) including LTE and System Architecture Evolution (SAE). However, these embodiments are not limited to application to EPS and may be applied to other mobile communication networks or systems, such as 3GPP UMTS, 3GPP2 CDMA2000 system (1xRTT, High Rate Packet Data (HRPD)), Global System for Mobile Communications (GSM (trademark)) / General Packet Radio Service (GPRS) system and WiMAX system.

[0036] First embodiment

[0037] Figure 1 An example of a configuration of a radio communication system according to some embodiments including the first embodiment is shown. Radio terminals (i.e., UEs) 100-102 are installed in vehicles. Each of the vehicle UEs 100-102 can be implemented in an onboard processing unit (e.g., a car navigation system). Each of the vehicle UEs 100-102 executes a V2I application to support a V2I service. The UEs 100-102 can support another V2X service, i.e., a V2V service or a V2P service or both.

[0038] RSU 120 and 121 are each installed on the roadside. Figure 1In the example shown, the RSU 120 is installed near the intersection 110. The RSUs 120 and 121 can each be equipped with, for example but not limited to, a ProSe-enabled UE, and can perform ProSe communication with the onboard UEs 100-102 to provide V2I services. The RSUs 120 and 121 can each serve as a ProSe UE-to-network relay (i.e., relay UE). The ProSe UE-to-network relay mainly relays traffic (i.e., downlink and uplink) between a UE out of coverage (i.e., a remote UE) and the network. The RSUs 120 and 121 each communicate with a base station (eNB) 130 in a cellular communication network via a radio connection, and also communicate with a server 140 (e.g., an ITS server or TSS) via the eNB 130.

[0039] As mentioned above, 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 inter-UE radio link used for direct communication or direct discovery is called a PC5 interface or a sidelink. Therefore, it can be said that ProSe is a general term for communication (or service) using at least a sidelink. Figure 1 In the example shown, communication between the RSU 120 used as a UE or relay UE and the UE 100 or 101 can use the side link, and communication between two or more UEs can also use the side link. In 3GPP Release 12, the side link transmission uses the same frame structure as the uplink and downlink transmission of Long Term Evolution (LTE), and uses a subset of uplink resources in the frequency domain and time domain. In 3GPP Release 12, the UE performs side link transmission by using single carrier frequency division multiple access (SC-FDMA), which is similar to the scheme used in uplink transmission.

[0040] The server 140 communicates with the UE 100-102 and the RSU 120 and 121 supporting the V2X service. More specifically, the server 140 communicates with the V2X application executed in each of the UE 100-102 and the RSU 120 and 121 at the application layer (application level) through the cellular communication network including the base station 130. In other words, the reference point between the server 140 and each UE 100-102 may depend on the user plane of the cellular communication network, and the signaling and data between the server 140 and the UE 100-102 may be transmitted on the user plane. In a similar manner, the reference point between the server 140 and each RSU 120 and 121 may depend on the user plane of the cellular communication network.

[0041] The server 140 may be an ITS server or a TSS. For example, in response to receiving report information indicating that an accident has occurred from the RSU 120, the server 140 may notify other RSUs (eg, RSU 121) near the RSU 120 that an accident exists in the area managed by the RSU J20.

[0042] In addition, in some implementations, in order to utilize the V2X services provided by the cellular communication network, the UE 100-102 can communicate with the V2X controller 150 via the base station 130 (and via the core network). Similarly, each RSU 120 and 121 acting as a UE can communicate with the V2X controller 150 via the base station 130 (and via the core network).

[0043] The V2X controller 150 provides logical functions for performing operations associated with a cellular communication network (i.e., a public land mobile network (PLMN)) to provide V2X services. For example, the V2X controller 150 may perform authentication or approval of UEs 100-102 for V2X services. The V2X controller 150 may perform authentication or approval of RSUs 120 and 121 used as UEs. The V2X controller 150 may be referred to as a V2X functional entity.

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

[0045] Figure 2 Another configuration example of a wireless communication system according to some embodiments including the first embodiment is shown. Figure 2 In the example shown, each of the RSUs 220 and 221 functions as a base station (eNB).

[0046] exist Figure 1 and Figure 2 In the configuration shown, some or all of the UEs 100-102 may be pedestrian UEs. Figure 1 and Figure 2In the configuration shown, the server 140 may be located in the same site as the eNB 130, or may be used as an eNB together with the RSU 220 or 221. Such a server is referred to as a mobile edge computing (MEC) server. Alternatively, the server 140 may be installed at a remote site geographically separated from the site where the eNB 130 (or RSU 220 or 221) is installed, and communicate with the eNB 130 via one or more entities in the cellular communication network (e.g., a mobility management entity, a packet data network gateway (P-GW), and a serving gateway (S-GW)).

[0047] Figure 3 is a diagram showing an example of the architecture / deployment of a radio communication system according to some embodiments including the first embodiment. Figure 1 and 2 As described, in one implementation, each of the RSUs 120 and 121 has the functionality of a UE, and in another implementation, the RSU 220 has the functionality of an eNB. That is, in some implementations, a UE supporting V2X services (e.g., UE 100) 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, such as Figure 3 As shown in the path 362 of FIG. 3 , the UE (eg, UE 100) may be directly connected to the eNB 130 without passing through the RSU 120 and communicate with the server 140. Additionally or alternatively, in some implementations, such as Figure 3 As shown in path 363 of , a UE (eg, UE 100 ) may be connected to an RSU 220 serving as an eNB and communicate with a server 140 via the RSU 220 .

[0048] Communication 351 between the RSU 120 used 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 (or shared spectrum) f2 that is not licensed to any operator or shared by multiple operators. Such communication using a shared frequency is 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 used as an eNB may use any of the above-mentioned frequency bands f1, f2, and f3. In addition, communication between UEs (not shown) may also use any of the above-mentioned frequency bands f1, f2, and f3.

[0049] Next, in the following description, a procedure for setting up a V2X service will be explained. Figure 4 is a sequence diagram showing a process 400 as an example of a setup process. The network 410 includes at least Figure 1 The eNB 130 in the configuration example in the embodiment of the present invention or including at least one Figure 2 The network 410 may further include a V2X controller 150.

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

[0051] The V2X support information may indicate at least one of the following: (a) V2X service is available; (b) carrier frequency band used for V2X service; (c) measurement configuration of carrier frequency band used for V2X service; (d) supported type of V2X service (e.g., V2V, V2I, V2P); and (e) transmission power allowed by radio terminals for V2X service. The transmission of V2X support information may implicitly indicate (a) that V2X service is available. In addition, together with the indication information of (b) carrier frequency band used for V2X service, an identifier of a network (e.g., a PLMN identity list) or an identifier of an area (e.g., a V2X area list) providing V2X service may be transmitted.

[0052] Additionally or alternatively, the V2X support information may indicate a radio resource pool for autonomous resource selection to be used by each UE for V2X service. The radio resource pool may include: a radio resource pool for each class of V2X service (e.g., V2V, V2I, V2P) included in the V2X service; a radio resource pool for each V2X operation mode (e.g., relay mode, direct mode) used as an RSU of the UE; a radio resource pool for each V2X service area; a radio resource pool for each device type of UE (e.g., RSU, vehicle, pedestrian); or a radio resource pool for each pre-configured category (e.g., speed, travel (or moving) direction, traffic lane). The radio resource pool may be configured for each carrier frequency band for performing V2X service.

[0053] Additionally or alternatively, the V2X support information may include a synchronization configuration of the V2X.

[0054] The eNB 130 or the RSU (eNB) 220 may broadcast the V2X support information in a cell served by the eNB 130 or the RSU (eNB) 220 so that at least a UE in an idle state (e.g., RRC_IDLE) can receive the V2X support information. The eNB 130 or the RSU (eNB) 220 may send the V2X support information on a broadcast control channel (BCCH) carrying a system information block (SIB).

[0055] The eNB 130 or the RSU (eNB) 220 may transmit V2X support information on both a first carrier frequency band for cellular communication (e.g., frequency band f3 licensed to a cellular operator) and a second carrier frequency band for V2X services (e.g., frequency band f1 dedicated to V2X). In some implementations where V2X support information is transmitted on both frequency bands, information transmitted on one of the frequency bands (e.g., frequency band f3 licensed to a cellular operator) may take precedence over information transmitted on the other frequency band (e.g., frequency band f1 dedicated to V2X).

[0056] 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 sent on the V2X dedicated frequency band f1. For example, the RSU (UE) 120 may receive the V2X support information sent from the eNB 130, and then broadcast or multicast (at least a portion of) the received V2X support information on the frequency band f1 dedicated to the V2X service. Alternatively, the RSU (UE) 120 may transmit (or relay) the received V2X support information to the UE 100 on the frequency band f1. Alternatively, the UE 100 may use a pre-stored configuration (e.g., a pre-configured radio resource for V2X).

[0057] exist Figure 4 In step 402, in response to receiving the V2X support information, the UE 100 or the RSU 120 sends V2X terminal information (ie, V2X UE information) to the network 410 indicating that the UE 100 or the RSU 120 is interested in the V2X service.

[0058] The V2X UE information may indicate at least one of: (a) the UE 100 or RSU 120 is interested in V2X services; (b) the UE 100 or RSU 120 desires to use V2X services; (c) the frequency bands that the UE 100 or RSU 120 supports V2X services; (d) the frequency bands available to the UE 100 or RSU 120 for V2X services; (e) the type of V2X services that the UE 100 or RSU 120 is interested in (e.g., V2V, V2I, V2P); and (f) the device type of the UE 100 or RSU 120 (e.g., RSU, vehicle, pedestrian).

[0059] Additionally or alternatively, the V2X UE information may include an RSU indication. The RSU indication indicates whether the source UE is an RSU. In addition, the RSU indication may indicate the type of the RSU. The RSU type may indicate the type of road on which the RSU is installed (e.g., an inbound lane, an outbound lane, a road under an elevated structure, an elevated road, a road on the ground, a road under the ground, an ordinary road, or a highway). The RSU indication may be sent 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.

[0060] The V2X UE information may be sent during a process 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 send the V2X UE information using an RRC connection establishment complete message or UE capability signaling during the RRC connection establishment process. When the RSU (UE) 120 sends the V2X UE information (e.g., an RSU indication), the eNB 130 may send information indicating that the message is related to the RSU (e.g., an RSU indicator) to the MME using an S1AP INITIAL UE MESSAGE message or an E-RAB SETUP RESPONSE message.

[0061] exist Figure 4 In step 403, in response to receiving the V2X UE from the UE 100 or the RSU 120, the network 410 (e.g., the eNB 130, the RSU 220, or the V2X controller 150) sends the V2X configuration to the UE 100 or the RSU 120. For example, the V2X configuration may be sent using an RRC connection reconfiguration message. Generating the V2X configuration based on the V2X UE information sent from the UE 100 or the RSU 120 may be performed by the eNB 130 or the RSU 220 as the eNB, or it may be performed by the V2X controller 150. The UE 100 or the RSU 120 receives the V2X configuration sent from the network 410, and performs V2X communication according to the received V2X configuration.

[0062] The V2X configuration may be transmitted on any one of the dedicated carrier frequency band 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. In addition, 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 then multicast the V2X configuration (at least a portion) on the frequency band f1 dedicated to the V2X service. Alternatively, the RSU (UE) 120 may transmit (or relay) the received V2X configuration to the UE 100 on the frequency band f1.

[0063] In some implementations, the V2X configuration may indicate a measurement configuration of a carrier frequency band 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 a configuration of a data radio bearer (DRB), a configuration of a signaling radio bearer (SRB), or both. The DRB configuration may include at least one of the following elements:

[0064] - Configuration of Physical Multicast Channel (PMCH) for Multimedia Broadcast / Multicast Service (MBMS);

[0065] - Configuration of Physical Downlink Shared Channel (PDSCH) for Single Cell Point-to-Multipoint (SC-PTM);

[0066] - Logical Channel ID (LCID); and

[0067] - E-UTRAN Radio Access Bearer (E-RAB) identity.

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

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

[0070] Additionally or alternatively, the network 410 may transmit an RSU configuration to the RSU 120 indicating how the RSU 120 should operate. The RSU configuration may be sent using an RRC connection reconfiguration message. The RSU configuration may include at least a portion of the V2X configuration. In response to receiving the V2V message, the RSU configuration may implicitly or explicitly inform the RSU 120 as to whether the RSU 120 should be used as a relay UE to send a V2X report message to the network (e.g., eNB) or as a V2X UE to send a V2X report message to the network (e.g., eNB). When the RSU configuration implicitly indicates the above, the RSU 120 may make a determination based on whether the RSU configuration includes radio resource configuration information (e.g., radio resource configuration) required for the RSU 120 to be used as a relay UE. For example, when the radio resource configuration information is included, the RSU 120 may be used as a relay UE, and when the radio resource configuration information is not included, the RSU 120 may be used as a V2V UE. When the RSU configuration explicitly indicates the above, the RSU configuration may indicate the operation mode of the RSU. The operation mode may be, for example, a relay UE mode or a V2V UE mode.

[0071] A V2X service area (SA) may be defined as an area where the same V2X configuration is specified to be applied. A V2X SA may be defined in any of the following: a dedicated carrier frequency band f1 reserved for V2X services; a shared frequency band f2 of an LSA; and a carrier frequency band f3 licensed to an operator of a cellular communication network. For example, a cell may be defined on frequency band f3, while a V2X SA may be defined on frequency band f1 or f2. A 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 in one cell, or there may be V2X SAs on multiple cells (i.e., a V2X SA that at least partially covers each of the multiple cells). In the latter case, one V2X SA may be defined by one cell or a combination of multiple cells. In addition, when a UE moves between cells belonging to the same V2X SA (i.e., the UE performs cell reselection or handover between cells), the UE may continue the V2X service without suspending the service. Alternatively, the UE may suspend the V2X service while performing cell reselection or handover, and then resume the service after completing the cell reselection or handover. That is, the V2X SA may be considered to be the "valid area" of the V2X configuration. Information about the V2X SA (e.g., the V2X SA index (ID)) may be transmitted as one of the information elements (IEs) included in the V2X configuration, or may be transmitted through a message or signaling other than the V2X configuration. For example, the eNB 130 or the RSU (eNB) 220 may incorporate the information about the V2X SA into the V2X configuration and then transmit the V2X configuration on frequency band f3. In this case, the RSU (UE) 120 may further transmit the information about the V2X SA on frequency band f1 or f2. The RSU (UE) 120 may broadcast or multicast the information about the V2X SA or transmit (or relay) the information to the UE 100.

[0072] According to reference Figure 4 The described process may perform the required setup of the UE 100 or the RSU 120 acting as a UE to start V2X services.

[0073] Second embodiment

[0074] This embodiment provides a specific example of UE switching supporting V2X services. Figure 1 In the example shown, UE 100 may perform a handover from a source cell served by eNB 130S to a target cell served by eNB 130T. Figure 2 In the example shown, UE 100 may perform a handover from a source cell served by RSU (eNB) 220 to a target cell served by RSU (eNB) 221 .

[0075] Figure 55 is a sequence diagram showing a process 500 as an example of a handover process of the present embodiment. In step 501, the UE 100 is connected to the source eNB 130S (or RSU 220) and performs V2X service (i.e., V2X communication). In step 502, the UE 100 sends a measurement report to the source eNB 130S (or RSU 220). The measurement report is sent when the value measured by the UE 100 meets a predetermined handover event condition.

[0076] In step 503, the source eNB 130S (or RSU 220) determines to perform 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 the V2X service; the UE 100 is allowed to use the V2X service; the UE 100 has been authenticated for the V2X service; and the UE 100 has been approved for the V2X service.

[0077] In response to receiving the handover request, the target eNB 130T (or RSU 221) sends a handover response (i.e., handover request ACK) to the source eNB 130S (or RSU 220) indicating that it accepts the handover in step 504. The handover response contains the V2X configuration of the target cell served by the target eNB 130T (or RSU 221).

[0078] In step 505, the source eNB 130S (or RSU 220) sends a handover command (i.e., an RRC connection reconfiguration message) containing the V2X configuration of the target cell to instruct the UE 100 to perform handover to the target cell. The V2X configuration may include information about the V2X service provided in the target cell or information about the V2X service area included in the target cell (or the V2X service area including the target cell) (e.g., V2X SA index (ID)).

[0079] In response to receiving the handover command (i.e., the RRC connection reconfiguration message), the UE 100 switches to the target eNB 130T (or the RSU 221) in step 506. That is, the UE 100 performs a random access procedure on the target eNB 130T (or the RSU 221) to establish synchronization with the target cell, and sends a handover confirmation message (i.e., the RRC connection reconfiguration complete message) to the target eNB 130T (or the RSU 221).

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

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

[0082] As described above, in this embodiment, the source eNB 130S (or RSU 220) is configured to send a V2X indication about the UE 100 to the target eNB 130T (or RSU 221) during the handover preparation process (i.e., step 503). In addition, the target eNB 130T (or RSU 221) is configured to send the V2X configuration of the target cell to the source eNB 130S (or RSU 220) during the handover preparation process (i.e., step 504) when it accepts the handover request containing the V2X indication. Therefore, the handover process in this embodiment allows the UE 100 to continue the V2X service after the handover. The UE 100 can continue the V2X service during the handover. For example, when the handover target cell (or eNB 130T) provides the same V2X service as the source cell (or eNB 130S), or when the target cell is included in the same V2X service area (V2X SA) as the source cell, the UE 100 may continue the V2X service.

[0083] Third embodiment

[0084] This embodiment provides some specific examples about V2X message transmission. Figure 6 A first example of message transmission is shown. Figure 6 In the illustrated example, in response to receiving the notification 660 from the vehicle UE 100 , the RSU (UE) 120 generates V2X report information 670 based on the notification 660 , and sends the V2X report information 670 to the server 140 via the eNB 130 .

[0085] For example, the RSU (UE) 120 may check (or detect) the content of the notification 660 in the application layer and generate V2X report information 670 including the content of the notification 660. 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), the RSU (UE) 120 may send the V2X report information 670.

[0086] Alternatively, the RSU (UE) 120 may detect the type (e.g., category, group, or service) of the content of the notification 660 based on a layer 2 header (e.g., a medium access control (MAC) header) for sending the notification 660, and send the V2X report information 670 in response to detecting a predetermined content type.

[0087] The notification 660 may be, for example, but not limited to, a message about an emergency stop or an accident of a vehicle equipped with the UE 100, a message about the driving state of the vehicle, or a message about the condition of a nearby road (e.g., traffic jam, weather, accident, or obstacle on the road). The UE 100 may incorporate a V2V message received from another vehicle (UE) via V2V communication or a message derived from the V2V message into the notification 660. The notification 660 may be a V2V message sent 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.

[0088] 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 the road conditions (e.g., traffic jams, weather, accidents, or obstacles on the road) in its management area, and generate the V2X report information 670 based on the monitoring results.

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

[0090] 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., an accident or traffic jam) or detour route guidance. The server 140 transmits the V2X control message 680 in a manner that the vehicle UEs including the vehicle UEs 100-102 can receive the V2X control message 680. Figure 6 In the example shown, a V2X control message 680 is sent from a server 140 to RSUs (UEs) 120 and 121 via an eNB 130, and then sent by each RSU (UE) to vehicle UEs 100-102. Each RSU may send a V2X control message 680 to each UE via unicast, or it may send the V2X control message 680 to multiple UEs via groupcast, multicast, or broadcast. In a groupcast, for example, a receiver (e.g., a UE) determines whether information should be received by performing certain filtering processes, and recovers the information if the information should be received. In certain filtering processes, for example, a UE may recover a group identifier contained in a layer 2 header and determine whether the group identifier should be received. The group identifier may be pre-configured in a receiver (e.g., a UE), or may be sent from a sender (e.g., an eNB or an application server). The group identifier may be information indicating a specific group (e.g., a UE), or may be a V2X SA index (ID).

[0091] Figure 7 The second example shown in FIG. 6 shows the V2X control message 680 and Figure 6 Another transmission path different from the transmission path shown. Figure 7 In the example shown, the V2X control message 680 is sent 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 in such a manner that multiple UEs 130 located within a cell served by the eNB 130 may receive the message.

[0092] In some implementations, the eNB 130 may send the V2X control message 680 on a user plane (U-plane). Specifically, the eNB 130 may use a broadcast bearer, a multicast bearer, or a point-to-multipoint (PTM) bearer to send the V2X control message 680. The V2X control message 680 may be sent on a data radio bearer used to carry 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).

[0093] Alternatively, in some implementations, the eNB 130 may send the V2X control message 680 on a control plane (C-plane). The eNB 130 may send 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 LTE / Evolved Packet System (EPS) may be used. 3GPP specifies 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 EU-ALERT used in European countries as PWS. In PWS, warning messages (primary notifications and secondary notifications) are sent by SIB 10 and SIB 11. 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 by a WRITE-REPLACEWARNING REQUEST message.

[0094] Figure 8 A third example of message transmission is shown. Figure 8 In the example shown, the RSUs 120 and 121 each function as a ProSe UE to network relay (i.e., relay UE). The RSUs 120 and 121 functioning as ProSe UE to network relays (i.e., relay UEs) do transparently transmit the application layer of the vehicle UE 100 (i.e., ProSe remote UE) without terminating it. Figure 8 In the example shown, the RSU 100 receives V2X report information 870 as application layer information from the UE 100 and then forwards the information to the eNB 130. That is, the V2X report information 870 transmitted from the vehicle UE 100 is relayed by the RSU 120 and the eNB 130 as relay UEs and finally reaches the server 140. The server 140 generates a V2X control message 880 in response to receiving the V2X report information 870 and transmits the message to the plurality of UEs 100-102. The V2X control message 880 may be transmitted to the plurality of UEs 100-102 via the eNB 130 and the RSU 120 or 121. Alternatively, similar to the example of reference 1, the V2X report information 870 transmitted from the vehicle UE 100 is relayed by the RSU 120 and the eNB 130 as relay UEs and finally reaches the server 140. The server 140 generates a V2X control message 880 in response to receiving the V2X report information 870 and transmits the message to the plurality of UEs 100-102. Figure 7 In the second example described, the V2X control message 880 may be sent directly from the eNB 130 to the plurality of UEs 100 - 102 without passing through the RSUs 10 and 121 .

[0095] Fig. 9 A fourth example of message transmission is shown. Fig. 9In the example shown, each of the RSUs 220 and 221 functions as a base station (eNB). In response to receiving the notification 960 from the vehicle UE 100, the RSU (eNB) 220 generates V2X report information 970 based on the notification 960 and sends the V2X report information 970 to the server 140. The notification 960 may be a dedicated message (e.g., Uu UL) sent from the UE 100 to the RSU (eNB), or it may be a V2V message. The RSU (eNB) 220 may send the V2X report information 970 on a control plane (C-plane) or on a user plane (U-plane).

[0096] 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. Figure 6 and Figure 7 In the example shown, the server 140 sends the V2X control message 980 in a manner that multiple vehicle UEs including the vehicle UEs 100-102 can receive the V2X control message 980. Fig. 9 In the example shown, V2X control messages 980 are sent from the server 140 to the RSUs (eNBs) 220 and 221 and are sent by the RSUs (eNBs) to the vehicle UEs 100-102. Figure 7 The eNB 130, RSU (eNB) 220 and 221 shown in FIG. 1 may send a V2X control message 980 on the U-plane or the C-plane.

[0097] Figure 6-9 An example of receiving V2X control messages 680, 880, and 980 by a plurality of vehicle UEs 100-102 is shown. However, the V2X control messages 680, 880, and 980 may be received by pedestrians (i.e., pedestrian UEs). The V2X control message may contain information for the vehicle UE and information for the pedestrian UE, and each UE performs filtering to extract necessary information from the V2X control message. The V2X control message for the vehicle UE and the V2X control message for the pedestrian UE may be transmitted using transmission formats different from each other (e.g., U-plane and C-plane).

[0098] Figure 6-9 The multiple examples of message transmission shown can be appropriately combined with each other. Specifically, Figure 3 Any of the three paths 361, 362, and 363 shown may be used for message transmission from the vehicle UE 100 to the server 140. In a similar manner, Figure 3 Any of the three paths 361 , 362 , and 363 shown may be used for message transmission from the server 140 to the vehicle UE 100 .

[0099] when Figure 6 The RSU (UE) 120 and the eNB 130 are shown with Fig. 9 When used together with the RSU (eNB) 220 shown, the eNB 130 may transmit the V2X report information 670 to the RSU (eNB) 220 via an inter-base station interface (e.g., an X2 interface). In addition, the eNB 130 may transmit the V2X control message 680 to the RSU (eNB) 220 via an inter-base station interface (e.g., an X2 interface).

[0100] The following provides configuration examples of the UEs 100 - 102 , the RSUs 120 and 220 , the eNB 130 , the server 140 , and the V2X controller 150 described in the above embodiments. Fig.10 1 is a block diagram showing a configuration example of the eNB 130. The RSU 220 used as the eNB may have Fig.10 A similar configuration is shown in Figure 1. 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 the UE. The RF transceiver 1001 may include a plurality of 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 transmission RF signal, and provides the transmission RF signal to the antenna 1002. In addition, the RF transceiver 1001 generates a baseband reception signal based on the reception RF signal received by the antenna 1002, and provides the baseband reception signal to the processor 1004.

[0101] The network interface 1003 is used to communicate with network nodes (eg, other eNBs, mobility management entities (MMEs), serving gateways (S-GWs), and TSS or ITS servers). The network interface 1003 may include, for example, a network interface card (NIC) compliant with the IEEE 802.3 series.

[0102] Processor 1004 performs data plane processing, including digital baseband signal processing and control plane processing for radio communication. For example, in the case of LTE and advanced LTE, the digital baseband signal processing performed by processor 1004 may include signal processing of the PDCP layer, RLC layer, MAC layer, and PHY layer. In addition, the signal processing performed by processor 1004 may include signal processing of the GTP-U UDP / IP layer for X2-U and S1-U interfaces. In addition, the control plane processing performed by processor 1004 may include processing of the X2AP protocol, S1-MME protocol, and RRC protocol.

[0103] The processor 1004 may include a plurality of processors. The processor 1004 may include, for example, a modem processor (e.g., DSP) that performs digital baseband signal processing, a processor (e.g., DSP) that performs digital signal processing of the GTP-U UDP / IP layer for the X2-U and S1-U interfaces, and a protocol stack processor (e.g., CPU or MPU) that performs control plane processing.

[0104] The memory 1005 is composed of a combination of volatile memory and non-volatile memory. The memory 1005 may include multiple memory devices that are physically independent of each other. 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, a hard disk drive, or any combination thereof. The memory 1005 may include a storage device located away from the processor 1004. In this case, the processor 1004 can access the memory 1005 via the network interface 1003 or an I / O interface (not shown).

[0105] The memory 1005 may store software modules (computer programs) including instructions and data to perform the processing of the eNB 130 described in the above embodiments. In some implementations, the processor 1004 may be configured to load the software module from the memory 1005 and execute the loaded software module, thereby performing the processing of the eNB 130 described in the above embodiments.

[0106] Fig.11 1 is a block diagram showing a configuration example of an RSU 120 used as a UE (or relay UE). UEs 101 and 102 may have Fig.11 The radio frequency (RF) transceiver 1101 performs analog RF signal processing to communicate with the eNB 130. The analog RF signal processing performed by the RF transceiver 1101 includes up-conversion, down-conversion, and amplification. The RF transceiver 1101 is coupled to the antenna 1102 and the baseband processor 1103. That is, the RF transceiver 1101 receives the 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. In addition, the RF transceiver 1101 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.

[0107] The baseband processor 1103 performs digital baseband signal processing (i.e., data plane processing) and control plane processing for radio communication. Digital baseband signal processing includes (a) data compression / decompression, (b) data segmentation / concatenation, (c) synthesis / decomposition of transmission formats (i.e., transmission frames), (d) channel coding / decoding, (e) modulation (i.e., symbol mapping) / demodulation, and (f) generation of OFDM symbol data (i.e., baseband OFDM signal) by inverse fast Fourier transform (IFFT). On the other hand, 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., regarding attachment, mobility, and call management).

[0108] For example, in the case of LTE and Advanced LTE, the digital baseband signal processing performed by the baseband processor 1103 may include a packet data convergence protocol (PDCP) layer, a radio link control (RLC) layer, a MAC layer, and a PHY layer. In addition, the control plane processing performed by the baseband processor 1103 may include processing of a non-access stratum (NAS) protocol, an RRC protocol, and a MAC CE.

[0109] 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 microprocessing unit (MPU)) that performs control plane processing. In this case, the protocol stack processor that performs control plane processing may be integrated with the application processor 1104 described below.

[0110] The application processor 1104 is also called a CPU, an MPU, a microprocessor, or a processor core. The application processor 1104 may include a plurality of processors (processor cores). The application processor 1104 executes a system software program (operating system (OS)) loaded from the memory 1106 or from another memory (not shown) and various application programs (e.g., a voice call application, a WEB browser, a mail program, a camera operation application, and a music player application), thereby providing various functions of the RSU 120.

[0111] In some implementations, such as Fig.11 As shown by the dotted line (1105) in FIG. 1 , the baseband processor 1103 and the application processor 1104 may be integrated on a single chip. In other words, the baseband processor 1103 and the application processor 1104 may be implemented in a single system on chip (SoC) device 1105. The SoC device may be referred to as a system large scale integration (LSI) or a chipset.

[0112] The memory 1106 is a volatile memory, a non-volatile memory, or a combination thereof. The memory 1106 may include a plurality of memory devices that are physically independent of each other. 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, for example, a mask read-only memory (MROM), an electrically erasable programmable ROM (EEPROM), a flash memory, a hard disk drive, or any combination thereof. The memory 1106 may include, for example, an external memory device that can be accessed from the baseband processor 1103, the application processor 1104, and the SoC 1105. The memory 1106 may include an internal memory device integrated in the baseband processor 1103, the application processor 1104, or the SoC 1105. In addition, the memory 1106 may include a memory in a universal integrated circuit card (UICC).

[0113] The memory 1106 may store software modules (computer programs) including instructions and data to perform the processing of the RSU 120 described in the above embodiments. In some implementations, the baseband processor 1103 or the application processor 1104 may load the software module from the memory 1106 and execute the loaded software module, thereby performing the processing of the RSU 120 described in the above embodiments.

[0114] Fig.12 is a block diagram showing a configuration example of the server 140. The V2X controller 150 may also have Fig.12 The configuration shown is similar to the configuration shown in the reference 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 a network node (e.g., eNodeB 130, MME, or P-GW). The network interface 1201 may include, for example, a network interface card (NIC) compliant with the IEEE 802.3 series.

[0115] The processor 1202 loads software (computer program) from the memory 1203 and executes the loaded software (computer program), thereby performing the processing of the server 140 described with reference to the sequence diagram and the flowchart in the above embodiment. The processor 1202 may be, for example, a microprocessor, an MPU, or a CPU. The processor 1202 may include a plurality of processors.

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

[0117] exist Fig.12In the example shown, the memory 1203 is used to store software modules. The processor 1202 loads these software modules from the memory 1203 and executes the loaded software modules, thereby performing the processing of the server 140 described in the above embodiment.

[0118] As mentioned above Figure 10-12 As described, each processor included in the UE 100-102, RSU 120 and 320, eNB 130, server 140 and V2X controller 150 according to the above embodiment executes one or more programs, which include algorithms for causing a computer to execute the description with reference to the accompanying drawings. The program can be stored and provided to a computer using any type of non-transitory computer-readable medium. Non-transitory computer-readable media include any type of tangible storage media. Examples of non-transitory computer-readable media include magnetic storage media (such as floppy disks, tapes, hard disk drives, etc.), optical magnetic storage media (such as magneto-optical disks), compact disk read-only memories (CD-ROMs), CD-Rs, CD-R / Ws, and semiconductor memories (such as mask ROMs, programmable ROMs (PROMs), erasable PROMs (EPROMs), flash ROMs, random access memories (RAMs), etc.). The program can be provided to a computer using any type of transient computer-readable media. Examples of transient computer-readable media include electrical signals, optical signals, and electromagnetic waves. Temporary computer-readable media can provide the program to a computer via a wired communication line (such as wires and optical fibers) or a wireless communication line.

[0119] Other embodiments

[0120] exist Figure 1 In the configuration shown, both RSUs 120 and 121 may be configured to periodically send keepalive messages or heartbeat messages to eNB 130 or server 140. Upon failure to receive a keepalive or heartbeat message from an RSU, eNB 130 or server 140 may detect that a failure has occurred in the RSU.

[0121] The description of the above embodiments mainly focuses on LTE / LTE-Advanced and its extensions. However, the above embodiments may be applied to other radio communication networks or systems.

[0122] In addition, the above-described embodiments are merely examples of application of the technical ideas obtained by the inventors. Of course, these technical ideas are not limited to the above-described embodiments, and various modifications may be made thereto.

[0123] This application is based upon and claims the benefit of priority from Japanese Patent Application No. 2015-185290, filed on Sep. 18, 2015, the entire contents of which are incorporated herein by reference.

[0124] Reference numerals list

[0125] 100-102 UE

[0126] 120, 121 RSU

[0127] 130 eNB

[0128] 140 Server

[0129] 150 V2X controller

[0130] 220, 221 RSU

[0131] 1001 RE Transceiver

[0132] 1004 Processor

[0133] 1101 RE Transceiver

[0134] 1103 Baseband Processor

[0135] 1104 Application Processor

[0136] 1202 Processor

[0137] 1203 Memory.

Claims

1. A source base station, comprising: at least one wireless transceiver; as well as At least one processor configured to: Sending a handover request message for handover of the mobile terminal to the target base station, the handover request message including information about the authorization status of the mobile terminal for the vehicle and all V2X services; receiving a handover request response message from the target base station, The handover request response message includes a V2X configuration indicating area information of the V2X service.

2. The source base station according to claim 1, wherein: The V2X configuration also indicates the V2X service.

3. The source base station according to claim 2, wherein: The at least one processor is further configured to send a radio resource control (RRC) message including the V2X configuration to the mobile terminal.

4. A method of a source base station, comprising: Sending a handover request message for handover of the mobile terminal to the target base station, the handover request message including information about the authorization status of the mobile terminal for the vehicle and all V2X services; receiving a handover request response message from the target base station, The handover request response message includes a V2X configuration indicating area information of the V2X service.

5. The method according to claim 4, wherein: The V2X configuration also indicates the V2X service.

6. The method according to claim 5, further comprising: Sending a radio resource control (RRC) message including the V2X configuration to the mobile terminal.

7. A target base station, comprising: at least one wireless transceiver; as well as At least one processor configured to: receiving a handover request message for handover of the mobile terminal from the source base station, the handover request message including information about the authorization status of the mobile terminal for the vehicle and all V2X services; sending a handover request response message to the source base station, The handover request response message includes a V2X configuration indicating area information of the V2X service.

8. The target base station according to claim 7, wherein: The V2X configuration also indicates the V2X service.

9. A method for a target base station, comprising: receiving a handover request message for handover of the mobile terminal from the source base station, the handover request message including information about the authorization status of the mobile terminal for the vehicle and all V2X services; sending a handover request response message to the source base station, The handover request response message includes a V2X configuration indicating area information of the V2X service.

10. The method of claim 9, wherein: The V2X configuration also indicates the V2X service.

Images