Communication device, method performed by the communication device and integrated circuit controlling the process of the communication device

Abstract

The invention relates to a communication device comprising: receiving circuitry to receive parameter information in a cell in which the communication device is located; control circuitry to determine, based on the parameter information, whether to use a radio resource corresponding to a geographical location of the communication device, in response to the parameter information indicating to use the radio resource, the control circuitry to: determine the geographical location, identify a location sub-section in which the communication device is located based on the parameter information, wherein the parameter information comprises a parameter indicating a length and a width of the location sub-section and a number of location sub-sections into which a location section is divided with respect to longitude and latitude, wherein the parameter is dynamically signaled from a radio base station, determine the radio resource corresponding to the identified location sub-section in which the communication device is geographically located based on the parameter, the length and the width of the location sub-section and the number of location sub-sections into which the location section is divided with respect to longitude and latitude, and perform communication using the determined radio resource.

Description

[0001] This application is a divisional application of the application patent application with the application number: 201680083786.5, the application date: 25 March 2016, and the invention name: "Improved allocation of radio resources for vehicle communication". TECHNICAL FIELD

[0002] The present disclosure relates to improved allocation of radio resources for vehicle mobile terminals. The present disclosure provides a corresponding vehicle mobile terminal, radio base station, system and method. BACKGROUND

[0003] Long Term Evolution (LTE)

[0004] Third generation mobile systems (3G) based on WCDMA radio access technology are being deployed worldwide. The first step to enhance or evolve this technology requires the introduction of High Speed Downlink Packet Access (HSDPA) and Enhanced Uplink (also known as High Speed Uplink Packet Access (HSUPA)), giving a radio access technology with a high competitiveness.

[0005] To be prepared for further growth in user needs and to be competitive with respect to new radio access technologies, 3GPP introduced a new mobile communication system called Long Term Evolution (LTE). LTE is designed to meet the carrier needs for high speed data and media transmission as well as large capacity voice support in the next decade. The ability to provide high bit rates is a key measure of LTE.

[0006] The Work Item (WI) specification for Long Term Evolution (LTE) of the Evolved UMTS Terrestrial Radio Access (UTRA) and UMTS Terrestrial Radio Access Network (UTRAN) was finalized as Release 8 (LTE Release 8). The LTE system represents a highly efficient, packet-based, radio access and radio access network that provides full IP-based functionality with low latency and low cost. In LTE, multiple transmission bandwidths, such as 1.4, 3.0, 5.0, 10.0, 15.0 and 20.0 MHz, are specified to enable flexible system deployment using a given spectrum. In the downlink, an Orthogonal Frequency Division Multiplexing (OFDM) based radio access is employed because of its inherent resistance to Multi-Path Interference (MPI) due to low symbol rates, use of a cyclic prefix (CP) and its association with different transmission bandwidth arrangements. In the uplink, a Single-Carrier Frequency Division Multiple Access (SC-FDMA) based radio access is employed because, given the limited transmit power of user equipment (UE), wide area coverage is prioritized over increasing peak data rates. A number of key packet radio access technologies, including Multiple Input Multiple Output (MIMO) channel transmission techniques, are employed and an efficient control signaling structure is implemented in LTE Release 8 / 9.

[0007] LTE Architecture

[0008] Figure 1 The overall LTE architecture is shown in Figure 1. The E-UTRAN includes the eNode B, which provides the E-UTRA user plane (PDCP / RLC / MAC / PHY) and control plane (RRC) protocol terminations towards the user equipment (UE). The eNode B (eNB) hosts the Physical (PHY), Medium Access Control (MAC), Radio Link Control (RLC), and Packet Data Control Protocol (PDCP) layers which include the functionality for header compression, ciphering / deciphering, and handover between the different radio access technologies. The eNode B also provides Radio Resource Control (RRC) functionality, which includes load management, admission control, scheduling, and enforcement of negotiated uplink QoS, cell information broadcast, and encryption / decryption of user and control plane data. The eNode Bs are interconnected with each other by the X2 interface.

[0009] The eNodeB is also connected by means of an S1 interface to the EPC (Evolved Packet Core), more specifically to the MME by means of the S1-MME (S1 -MME) interface and to the Serving Gateway (SGW) by means of the S1-U interface. The S1 interface supports a many-to-many relation between MMEs / Serving Gateways and eNodeBs. The SGW routes and forwards user data packets, while also acting as the mobility anchor for the user plane during inter-eNodeB handovers and as the anchor for user plane mobility between LTE and other 3GPP technologies (terminating S4 interface and relaying the traffic between the 2G / 3G systems and the PDN GW). For idle mode user equipments, the SGW terminates the downlink data path and triggers paging when downlink data arrives for the user equipment. It also manages and stores user equipment contexts, such as parameters for IP bearer service, network internal routing information. In case of lawful interception, the SGW also performs replication of user traffic.

[0010] The MME is the key control-node for the LTE access-network. It is responsible for idle mode user equipment tracking and paging procedure including retransmissions. It is also responsible for activating / deactivating user equipment bearers, and is also in charge of choosing the SGW for a user equipment at initial attach and at time of intra-LTE handover involving CN node relocation. It is responsible for authenticating the user (by interacting with the HSS). Non-access stratum (NAS) signaling terminates at the MME and it also is responsible for generation and allocation of temporary identities to user equipments. It checks the authorization of user equipments to camp on the service provider's public land mobile network (PLMN) and enforces user equipment roaming restrictions. The MME is the termination point in the network for ciphering / integrity protection for NAS signaling and handles the security key management. Lawful interception of signaling is also supported by the MME. The MME also provides the control plane function for the signaling between the user equipment and the PDN gateway. It also terminates the S3 interface towards the home HSS for roaming user equipments. Finally, the MME is responsible for the distribution of paging messages to the eNodeBs and for the MME-initiated paging of user equipments.

[0011] Component carrier structure in LTE

[0012] In the time-frequency domain, the downlink component carrier of the 3GPP LTE system is subdivided in so-called subframes. In 3GPP LTE, each subframe is divided as follows Figure 2The first downlink slot of the two downlink slots shown in the middle includes a control channel region (PDCCH region) within the first OFDM symbol. Each subframe includes a given number of OFDM symbols in the time domain (12 or 14 OFDM symbols in 3GPP LTE (Release 8)), each OFDM symbol spanning the entire bandwidth of the component carrier. Thus, each OFDM symbol includes a plurality of modulation symbols transmitted on a respective subcarrier. In LTE, the transmitted signal in each time slot is described by a resource grid of subcarriers and OFDM symbols. is the number of resource blocks within the bandwidth. The number depends on the configured downlink transmission bandwidth in the cell, and shall satisfy where and are the minimum and maximum downlink bandwidths supported by the current release of the specification, respectively. is the number of subcarriers within a resource block. For a normal cyclic prefix and

[0013] Assuming a multi-carrier communication system employing OFDM, such as used in 3GPP Long Term Evolution (LTE), for example, the smallest unit of resources that can be allocated by a scheduling unit is a "resource block". A physical resource block (PRB) is defined as a contiguous OFDM symbol (e.g., 7 OFDM symbols) in the time domain and a contiguous subcarrier in the frequency domain, as exemplified in Figure 2 (e.g., 12 subcarriers for a component carrier). In 3GPP LTE (Release 8), a physical resource block thus comprises a resource unit corresponding to one slot in the time domain and 180 kHz in the frequency domain (for further details on the downlink resource grid, see, e.g., 3GPP TS 36.211, "Evolved Universal Terrestrial Radio Access (E-UTRA); Physical Channels and Modulation (Release 8)", current version 13.0.0, section 6.2, which is available at http: / / www.3gpp.org and incorporated herein by reference).

[0014] One subframe includes two slots, so that there are 14 OFDM symbols in a subframe when a so-called "normal" CP (cyclic prefix) is used, and 12 OFDM symbols in a subframe when an "extended" CP is used. For terminology, a time-frequency resource spanning the same contiguous subcarriers across a complete subframe is referred to as a "resource block pair", or equivalently "RB pair" or "PRB pair".

[0015] The term "component carrier" refers to a combination of several resource blocks in the frequency domain. In future releases of LTE, the term "component carrier" is no longer used; instead, the term is changed to "cell", which refers to a combination of downlink and optionally uplink resources. The association between the carrier frequency of the downlink resources and the carrier frequency of the uplink resources is indicated in system messages transmitted on the downlink resources.

[0016] Similar assumptions for component carrier structures will also apply to later releases.

[0017] Carrier aggregation in LTE-A for supporting wider bandwidths

[0018] The spectrum for IMT-Advanced was decided at the World Radio Communication Conference 2007 (WRC-07). Although the overall spectrum for IMT-Advanced was decided, the actual available frequency bandwidths differ from region to region or country to country. However, after the outline of the available spectrum was decided, the 3rd Generation Partnership Project (3GPP) started the standardization of the radio interface. At the 3GPP TSG RAN #39 meeting, a study item description on "Further Advancements for E-UTRA (LTE-Advanced)" was approved. This study item covers technical parts to be considered for the evolution of E-UTRA, e.g., to meet the requirements of IMT-Advanced.

[0019] The bandwidth that can be supported by LTE-Advanced systems is 100 MHz, while LTE systems can only support 20 MHz. Now, the lack of radio spectrum is a bottleneck for the development of wireless networks, and therefore, it is difficult to find a spectrum band wide enough for LTE-Advanced systems. Thus, there is an urgent need to find a way to obtain a wider radio spectrum band, and the possible answer is the carrier aggregation functionality.

[0020] In carrier aggregation, two or more component carriers are aggregated in order to support a wider transmission bandwidth of up to 100 MHz. Several cells in LTE systems are aggregated into a wider channel in LTE-Advanced systems that is wide enough for 100 MHz, even if these cells in LTE can be in different frequency bands.

[0021] All component carriers can be LTE Release 8 / 9 compatible, at least when the bandwidth of the component carrier does not exceed the bandwidth supported by a Release 8 / 9 cell. Not all component carriers aggregated by a user equipment have to be LTE Release 8 / 9 compatible. Existing mechanisms, e.g., barring, can be used to avoid that Release 8 / 9 user equipments camp on a component carrier.

[0022] User equipment can simultaneously receive or transmit on one or multiple component carriers (corresponding to multiple serving cells) depending on its capabilities. LTE-A Release 10 user equipment with reception and / or transmission capabilities for carrier aggregation can simultaneously receive and / or transmit on multiple serving cells, while LTE Release 8 / 9 user equipment can only receive and transmit on a single serving cell, provided that the structure of the component carriers follows the Release 8 / 9 specifications.

[0023] Carrier aggregation is supported for both contiguous and non-contiguous component carriers, with each component carrier limited to a maximum of 110 resource blocks in the frequency domain (using 3GPP LTE (Release 8 / 9) numerology).

[0024] A 3GPP LTE-A (Release 10) compatible user equipment can be configured to aggregate a different number of component carriers originating from the same eNodeB (base station) and possibly with different bandwidths in the uplink and downlink. The number of configurable downlink component carriers depends on the UE's downlink aggregation capability. Conversely, the number of configurable uplink component carriers depends on the UE's uplink aggregation capability. It can currently not be possible to configure a mobile terminal with more uplink component carriers than downlink component carriers. In a typical TDD deployment, the number of component carriers and the bandwidth of each component carrier is the same in the uplink and downlink. The component carriers originating from the same eNodeB do not need to provide the same coverage.

[0025] The spacing between the center frequencies of the contiguous aggregated component carriers should be a multiple of 300 kHz. This is to be compatible with the 100 kHz frequency raster of 3GPP LTE (Release 8 / 9) while preserving the orthogonality of subcarriers with a 15 kHz spacing. Depending on the aggregation scenario, the n x 300 kHz spacing can be facilitated by inserting a small number of unused subcarriers between contiguous component carriers.

[0026] The nature of the aggregation of multiple carriers is only exposed upwards to the MAC layer. For both the uplink and the downlink, one HARQ entity is needed in the MAC for each aggregated component carrier. There is at most one transport block per component carrier (in the absence of SU-MIMO for the uplink). The transport block and its potential HARQ retransmissions need to be mapped onto the same component carrier.

[0027] When a carrier aggregation is configured, the mobile terminal has only one RRC connection with the network. At RRC connection setup / reestablishment, one cell provides the security input (one ECGI, one PCI, and one ARFCN) and non-access stratum mobility information (e.g., TAI), similarly as in LTE Release 8 / 9. After RRC connection setup / reestablishment, the component carrier corresponding to this cell is called the downlink primary cell (PCell). For a user equipment in each connected state, one and only one downlink PCell (DL PCell) and one uplink PCell (UL PCell) are always configured. Within the set of configured component carriers, other cells are called secondary cells (SCells); the carriers of SCells are downlink secondary component carriers (DL SCCs) and uplink secondary component carriers (UL SCCs). A maximum of five serving cells, including the PCell, can be configured for one UE.

[0028] MAC layer / entity, RRC layer, physical layer

[0029] The LTE Layer 2 user plane / control plane protocol stack includes four sub-layers, namely, RRC, PDCP, RLC, and MAC. The medium access control (MAC) layer is the lowest sub-layer in the Layer 2 architecture of the LTE radio protocol stack and is defined by, for example, the current Release 13.0.0 of the 3GPP technical standard TS 36.321. The connection to the physical layer below is through transport channels, and the connection to the RLC layer above is through logical channels. Thus, the MAC layer performs multiplexing and demultiplexing between logical channels and transport channels: the MAC layer in the transmitting side constructs MAC PDUs (called transport blocks) from MAC SDUs received through logical channels, and the MAC layer in the receiving side recovers MAC SDUs from MAC PDUs received through transport channels.

[0030] The MAC layer provides a data transfer service for the RLC layer through logical channels, which are either control logical channels carrying control data (e.g., RRC signaling) or traffic logical channels carrying user plane data (see subclauses 5.4 and 5.3 of TS 36.321 incorporated by reference herein). On the other hand, data from the MAC layer is exchanged with the physical layer through transport channels, which are classified as downlink or uplink. Data is multiplexed into transport channels according to how it is transmitted over the air.

[0031] The physical layer is responsible for the actual transmission of data and control information over the air interface, i.e. the physical layer carries all information from the MAC transport channels over the air interface on the transmitting side. Some of the important functions performed by the physical layer include coding and modulation, link adaptation (AMC), power control, cell search (for initial synchronization and handover purposes) and other measurements for the RRC layer (within the LTE system and between systems). The physical layer performs transmission based on transmission parameters such as modulation scheme, coding rate (i.e. modulation and coding scheme, MCS), number of physical resource blocks, etc. More information on the role of the physical layer can be found in the current version 13.0.0 of the 3GPP technical standard 36.213, which is incorporated herein by reference.

[0032] The radio resource control (RRC) layer controls the communication between the UE and the eNB at the radio interface and the mobility of the UE moving across several cells. The RRC protocol also supports the transfer of NAS information. For UEs in RRC IDLE, RRC supports notification of incoming calls from the network. The RRC connection control covers all procedures related to the establishment, modification and release of an RRC connection, including paging, measurement configuration and reporting, radio resource configuration, initial security activation, and establishment of signaling radio bearers (SRBs) and radio bearers carrying user data (data radio bearers, DRBs).

[0033] The radio link control (RLC) sublayer mainly includes ARQ functionality and supports data segmentation and concatenation, i.e. the RLC layer performs framing of RLC SDUs to put them in sizes indicated by the MAC layer. The latter two minimize the protocol overhead independently of the data rate. The RLC layer is connected to the MAC layer via logical channels. Each logical channel transports a different type of traffic. The layer above the RLC layer is usually the PDCP layer, but in some cases the layer above the RLC layer is the RRC layer, i.e. RRC messages sent on the logical channels BCCH (broadcast control channel), PCCH (paging control channel) and CCCH (common control channel) do not require security protection and therefore bypass the PDCP layer and go directly to the RLC layer. The main services and functions of the RLC sublayer include:

[0034] • Transfer of upper layer PDUs for AM, UM or TM data transfer;

[0035] • Error correction by ARQ;

[0036] • Segmentation according to the size of the TB;

[0037] • Re-segmentation if necessary (e.g. when the radio quality, i.e. the supported TB size, changes)

[0038] • Concatenation of SDUs for the same radio bearer is FFS;

[0039] • In-sequence delivery of upper layer PDUs;

[0040] • Duplicate detection;

[0041] • Protocol error detection and recovery;

[0042] • SDU discard;

[0043] • Reset

[0044] The ARQ functionality provided by the RLC layer will be discussed in more detail in a later section.

[0045] Uplink access scheme for LTE

[0046] For uplink transmission, high-efficiency user terminal transmissions are required to maximize the coverage. Single-carrier transmission combined with FDMA with dynamic bandwidth allocation has been chosen as the evolved UTRA uplink transmission scheme. The main reason for preferring single-carrier transmission is the lower peak-to-average power ratio (PAPR) compared to multi-carrier signals (OFDMA) and the corresponding improved power amplifier efficiency and improved coverage (higher data rates for a given terminal peak power). During each time interval, the eNodeB allocates a unique time / frequency resource to the user for transmitting user data, thereby ensuring intra-cell orthogonality. Orthogonal access in the uplink ensures a spectral efficiency improvement by eliminating intra-cell interference. Interference due to multipath propagation is helped by inserting a cyclic prefix in the transmitted signal at the base station (eNodeB).

[0047] The basic physical resource for data transmission comprises a frequency resource of size BWgrantduring one time interval (e.g., a subframe) onto which the coded information bits are mapped. It should be noted that a subframe (also referred to as a transmission time interval (TTI)) is the smallest time interval for user data transmission. However, frequency resources BWgrantover time periods longer than one TTI can be allocated to a user by concatenating subframes.

[0048] Layer 1 / Layer 2 control signaling

[0049] In order to inform the scheduled users about their allocation status, transmission format and other transmission related information (e.g. HARQ information, Transmit Power Control (TPC) commands), L1 / L2 control signaling is transmitted on the downlink together with the data. Assuming that the user allocation can change from subframe to subframe, the L1 / L2 control signaling is multiplexed with the downlink data in a subframe. It should be noted that the user allocation can also be performed on a TTI (Transmission Time Interval) basis, the TTI length can be a multiple of a subframe. The TTI length can be fixed in the service area for all users, can be different for different users, or can even be dynamic for each user. Generally, the L1 / L2 control signaling only needs to be transmitted once per TTI. Without loss of generality, the following assumes that a TTI corresponds to one subframe.

[0050] The L1 / L2 control signaling is transmitted on the Physical Downlink Control Channel (PDCCH). The PDCCH carries messages as Downlink Control Information (DCI), which in most cases includes resource allocation and other control information for a group of mobile terminals or UEs. Several PDCCHs can be transmitted in one subframe.

[0051] Generally, the information transmitted in the L1 / L2 control signaling for allocating uplink or downlink radio resources (especially LTE(-A) Release 10) can be categorized as follows:

[0052] - User identity , which indicates the allocated users. This is usually included in the checksum by masking the CRC with the user identity;

[0053] - Resource allocation information , which indicates the resources (e.g. Resource Blocks, RBs) allocated to the users. Alternatively, this information is referred to as Resource Block Allocation (RBA). Note that the number of RBs allocated to a user can be dynamic;

[0054] - Carrier indicator , which is used in case of cross-carrier scheduling, where the control channel transmitted on a first carrier allocates resources on a second carrier (i.e. resources on the second carrier or resources related to the second carrier);

[0055] - Modulation and coding scheme , which determines the modulation scheme and coding rate used;

[0056] - HARQ information , such as the New Data Indicator (NDI) and / or the Redundancy Version (RV), which is especially useful in retransmissions of data packets or parts thereof;

[0057] - Power control command , which is used to adjust the transmit power of the allocated uplink data or control information transmission;

[0058] - Reference signal information such as the applied cyclic shift and / or orthogonal cover code index to be used for the transmission or reception of reference signals related to the allocation;

[0059] - Uplink or downlink assignment index for identifying the allocation order, which is particularly useful in TDD systems;

[0060] hopping information, e.g. an indication of whether and how to apply resource hopping in order to increase frequency diversity;

[0061] - CSI request for triggering the transmission of channel state information in the allocated resources; and

[0062] - Multi-cluster information which is a flag for indicating and controlling whether the transmission takes place in a single cluster (a contiguous set of RBs) or in multiple clusters (at least two non-contiguous sets of contiguous RBs). Multiple cluster allocation has been introduced by 3GPP LTE-(A) Release 10.

[0063] It should be noted that the above list is non-exhaustive and that not all of the mentioned information items need to be present in each PDCCH transmission, depending on the used DCI format.

[0064] Downlink control information comes in several formats, which differ in their overall size as well as in the information contained in their fields, as described above. The different DCI formats currently defined for LTE are as follows and are described in detail in 3GPP TS 36.212 "Multiplexing and channel coding", section 5.3.3.1 (current version v. 13.0.0 is available at http: / / www.3gpp.org and hereby incorporated by reference). For further information on the relevant DCI formats and the specific information transmitted in the DCI, see the mentioned technical standard, or "LTE - The UMTS Long Term Evolution - From Theory to Practice", edited by Stefanie Sesia, Issam Toufik, Matthew Baker, chapter 9.3 (incorporated by reference here). For example, the following DCI formats can be used for carrying resource grants for the uplink.

[0065] - Format 0: DCI format 0 is used for transmitting resource grants for PUSCH using single antenna port transmission in uplink transmission mode 1 or 2.

[0066] - Format 4: DCI format 4 is used for scheduling of PUSCH with closed loop spatial multiplexing transmission in uplink mode 2.

[0067] The current version 13.0.0 of the 3GPP technical standard TS 36.212 defines in subclause 5.4.3 control information for sidelink, which is incorporated herein by reference.

[0068] LTE Device-to-Device (D2D) Proximity Services (ProSe)

[0069] Proximity-based applications and services represent an emerging social technology trend. Identified areas include services related to commercial services and public safety that operators and users will be interested in. The introduction of Proximity Services (ProSe) capabilities in LTE will enable the 3GPP industry to serve this developing market and at the same time will serve the urgent needs of several public safety groups that are committed to LTE.

[0070] Device-to-Device (D2D) communication is a technology component introduced in LTE-Release 12, which enables D2D as an underlay to cellular networks to increase spectral efficiency. For example, if the cellular network is LTE, all data carrying physical channels use SC-FDMA for D2D signaling. In D2D communication, user equipments transmit data signals to each other over a direct link using cellular resources, rather than through a radio base station. Throughout the invention, the terms "D2D", "ProSe" and "sidelink" are interchangeable.

[0071] D2D communication in LTE focuses on two areas: discovery and communication.

[0072] ProSe (Proximity-based Services) Direct Discovery is defined as a procedure used by a ProSe-enabled UE to discover other ProSe-enabled UEs within its proximity using E-UTRA direct radio signals via the PC5 interface.

[0073] In D2D communication, UEs transmit data signals to each other over a direct link using cellular resources, rather than through a base station (BS). D2D users communicate directly while remaining under control of the BS (i.e., at least when in the coverage of an eNB). Thus, D2D can improve system performance by reusing cellular resources.

[0074] D2D is assumed to operate in the uplink LTE spectrum (in case of FDD) or in the uplink subframes of the cell of a given coverage (in case of TDD, except when outside the coverage). Furthermore, D2D transmission / reception does not use full duplex on the given carrier. From the perspective of a single UE, D2D signal reception and LTE uplink transmission do not use full duplex on the given carrier, i.e. D2D signal reception and LTE UL transmission cannot be done simultaneously.

[0075] In D2D communication, when one particular UE1 has the role of transmitter (transmitting user equipment or transmitting terminal), UE1 transmits data and another UE2 (receiving user equipment) receives it. UE1 and UE2 can change their transmitting and receiving roles. The transmission from UE1 can be received by one or more UEs like UE2.

[0076] ProSe Direct Communication Layer-2 Link

[0077] In short, ProSe Direct One-to-One Communication is realized by establishing a secure Layer-2 link over PC5 between two UEs. Each UE has a Layer-2 ID for unicast communication, which is included in the Source Layer-2 ID field of every frame it transmits on the Layer-2 link and in the Destination Layer-2 ID of every frame it receives on the Layer-2 link. The UE needs to ensure that the Layer-2 ID for unicast communication is at least locally unique. Therefore, the UE should be prepared to handle Layer-2 ID conflicts with neighboring UEs using an unspeci fied mechanism (e.g. assigning a new Layer-2 ID for unicast communication by itself when a conflict is detected). The Layer-2 link for ProSe Direct Communication One-to-One is identified by the combination of the Layer-2 IDs of both UEs. This means that a UE can participate in multiple Layer-2 links for ProSe Direct Communication One-to-One using the same Layer-2 ID.

[0078] ProSe Direct Communication One-to-One includes procedures like detailed in TR 23.713 current version v13.0.0 section 7.1.2, which is incorporated herein by reference:

[0079] • Establishment of a secure Layer-2 link over PC5.

[0080] • IP address / prefix allocation.

[0081] • Layer-2 link maintenance over PC5.

[0082] • Layer-2 link release over PC5.

[0083] Figure 3 Figure illustrates how to establish a secure Layer-2 link over PC5 interface.

[0084] 1. UE-1 sends a direct communication request message to UE-2 in order to trigger mutual authentication. The link initiator (UE-1) needs to know the layer-2 ID of the peer (UE-2) in order to perform step 1. As an example, the link initiator can learn the layer-2 ID of the peer by first performing a discovery procedure or by already participating in a ProSe one-to-many communication including the peer.

[0085] 2. UE-2 initiates the procedure for mutual authentication. Successful completion of the authentication procedure enables the establishment of a secure layer-2 link over PC5.

[0086] A UE participating in isolated (non-relayed) one-to-one communication can also use a link-local address. The PC5 signaling protocol shall support a keep-alive functionality that is used to detect when a UE is not in the ProSe communication range so that the UE can proceed with an implicit layer-2 link release. The layer-2 link release over PC5 can be performed by using a disconnect request message sent to the other UE, which also deletes all associated context data. Upon receiving the disconnect request message, the other UE responds with a disconnect response message and deletes all context data associated with the layer-2 link.

[0087] ProSe direct communication related identities

[0088] The current version 13.2.0 of 3GPP TS 36.300 defines the following identities for ProSe direct communication in subclause 8.3:

[0089] • ProSeDirectCommunicationID: a unique identity used for ProSe direct communication scheduling; SL-RNTI • ProSeDirectCommunicationSourceID: identifies the sender of data in sidelink ProSe direct communication. The source layer-2 ID is 24 bits long and is used together with the ProSe layer-2 destination ID and LCID to identify the RLC UM entity and PDCP entity in the receiver;

[0090] Source layer-2 ID • ProSeDirectCommunicationDestID: identifies the target of data in sidelink ProSe direct communication. The destination layer-2 ID is 24 bits long and is split into two bit strings in the MAC layer:

[0091] • ProSeDirectCommunicationDestID: identifies the target of data in sidelink ProSe direct communication. The destination layer-2 ID is 24 bits long and is split into two bit strings in the MAC layer: Destination layer-2 ID • ProSeDirectCommunicationDestID: identifies the target of data in sidelink ProSe direct communication. The destination layer-2 ID is 24 bits long and is split into two bit strings in the MAC layer:

[0092] • ProSeDirectCommunicationDestID: identifies the target of data in sidelink ProSe direct communication. The destination layer-2 ID is 24 bits long and is split into two bit strings in the MAC layer:

[0093] • ProSeDirectCommunicationDestID: identifies the target of data in sidelink ProSe direct communication. The destination layer-2 ID is 24 bits long and is split into two bit strings in the MAC layer:■ The second bit string is the MSB part of the Destination Layer-2 ID (16 bits) and is carried within the MAC header. This is used for filtering packets at the MAC layer.

[0094] The group formation and the configuration of the Source Layer-2 ID, Destination Layer-2 ID and Sidelink Control L1 ID in the UE does not require access stratum signaling. These identities are provided by higher layers or derived from identities provided by higher layers. In case of groupcast and broadcast, the ProSe UE ID provided by higher layers is directly used as the Source Layer-2 ID and the ProSe Layer-2 Group ID provided by higher layers is directly used as the Destination Layer-2 ID in the MAC layer. In case of one-to-one communication, the Source Layer-2 ID and the Destination Layer-2 ID are provided by higher layers.

[0095] Radio resource allocation for proximity services

[0096] From the perspective of the transmitting UE, a proximity services enabled UE (ProSe enabled UE) can operate in two modes for resource allocation:

[0097] Mode 1 refers to eNB scheduled resource allocation, where the UE requests transmission resources from the eNB (or Release 10 relay node) and the eNodeB (or Release 10 relay node) in turn schedules the resources to be used by the UE for transmitting direct data and direct control information (e.g. scheduling assignment). The UE needs to be RRC CONNECTED in order to transmit data. Specifically, the UE transmits a scheduling request (D-SR or Random Access) to the eNB in the usual way, followed by a buffer status report (BSR) (see also section "Transmission procedure for D2D communication" below). Based on the BSR, the eNB can determine that the UE has data for ProSe direct communication transmission and can estimate the resources needed for the transmission.

[0098] On the other hand, mode 2 refers to UE autonomous resource selection, where the UE itself selects resources (time and frequency) from a resource pool to transmit direct data and direct control information (i.e. SA). One resource pool is defined, for example, by the content of SIB 18 (i.e. by the field commTxPoolNormalCommon), this specific resource pool is broadcasted in the cell and then commonly available to all UEs in the cell that are still in RRC Idle state. Effectively, the eNB can define up to four different instances of said pool, one for each of the four resource pools for transmitting SA messages and direct data. However, in Release 12, the UE shall always use the first resource pool defined in the list, even if it is configured with multiple resource pools. This restriction is removed for Release 13, i.e. the UE can transmit on multiple configured resource pools within one SC period. How the UE selects the resource pool for transmission is further outlined below (further specified in TS 36.321).

[0099] As an alternative, another resource pool can be defined by the eNB and signaled in SIB18 (i.e. by using the field commTxPoolExceptional) which can be used by the UE in exceptional cases.

[0100] What resource allocation mode the UE is going to use can be configured by the eNB. Furthermore, what resource allocation mode the UE is going to use for D2D data communication can also depend on the RRC state (i.e. RRC_IDLE or RRC_CONNECTED) and the coverage status of the UE (i.e. in-coverage, out-of-coverage). If the UE has a serving cell (i.e. the UE is RRC_CONNECTED or camping on a cell in RRC_IDLE), the UE is considered in-coverage.

[0101] The following rules regarding the resource allocation mode apply to the UE:

[0102] • If the UE is out-of-coverage, the UE can only use mode 2;

[0103] • If the UE is in-coverage, the UE can use mode 1 if the eNB configures the UE accordingly;

[0104] • If the UE is in-coverage, the UE can use mode 2 if the eNB configures the UE accordingly;

[0105] • When no exceptional condition exists, the UE can only change from mode 1 to mode 2 and vice versa if it is configured by the eNB to do so. If the UE is in-coverage, the UE shall only use the mode indicated by the eNB configuration unless one of the exceptional conditions occurs;

[0106] o The UE considers itself under an exceptional condition, e.g. when T311 or T301 is running;

[0107] • When an exceptional condition occurs, the UE is allowed to temporarily use mode 2 even if it is configured to use mode 1.

[0108] When in the coverage area of an E-UTRA cell, the UE shall only perform ProSe direct communication transmission on the UL carrier on the resources allocated by that cell, even if the resources of that carrier have been pre-configured in the UICC (Universal Integrated Circuit Card), for example.

[0109] For a UE in RRC_IDLE, the eNB can choose one of the following options:

[0110] • The eNB can provide in SIB the mode 2 transmission resource pool. UEs authorized for ProSe direct communication use these resources for ProSe direct communication in RRC_IDLE;

[0111] • The eNB can indicate in SIB that it supports D2D but does not provide resources for ProSe direct communication. The UE needs to enter RRC_CONNECTED to perform ProSe direct communication transmission.

[0112] For UEs in RRC_CONNECTED:

[0113] • A UE in RRC_CONNECTED authorized to perform ProSe direct communication transmission indicates to the eNB that it wants to perform ProSe direct communication transmission when it needs to perform ProSe direct communication transmission;

[0114] • The eNB uses the UE context received from the MME to verify whether the UE in RRC_CONNECTED is authorized for ProSe direct communication transmission;

[0115] • The eNB can configure a UE in RRC_CONNECTED with a mode 2 resource allocation transmission resource pool through dedicated signaling, which can be used without restriction while the UE is in RRC_CONNECTED. Alternatively, the eNB can configure a UE in RRC_CONNECTED with a mode 2 resource allocation transmission resource pool through dedicated signaling, the UE is only allowed to use this mode 2 resource allocation transmission resource pool in exceptional cases, otherwise relying on mode 1.

[0116] The resource pool for scheduling allocation when the UE is out of coverage can be configured as follows:

[0117] • A pre-configured resource pool for reception.

[0118] • A pre-configured resource pool for transmission.

[0119] The resource pool for scheduling allocation when the UE is in coverage can be configured as follows:

[0120] • The resource pool for reception is configured by the eNB via RRC, in dedicated or broadcast signaling.

[0121] • The resource pool for transmission is configured by the eNB via RRC if mode 2 resource allocation is used.

[0122] • The SCI (Sidelink Control Information) resource pool for transmission (also called scheduling allocation, SA, resource pool) is unknown to the UE if mode 1 resource allocation is used.

[0123] • If mode 1 resource allocation is used, the eNB schedules specific resources for the sidelink control information (scheduling assignment) transmission. The specific resources allocated by the eNB are within the resource pool used for receiving the SCI provided to the UE.

[0124] Figure 4 The use of transmission / reception resources for overlay (LTE) and underlying (D2D) systems is illustrated.

[0125] Basically, the eNodeB controls whether the UE can apply mode 1 or mode 2 transmission. Once the UE knows its resources on which it can transmit (or receive) D2D communication, the UE will only use the corresponding resources for the corresponding transmission / reception. For example, in Figure 4 , the D2D subframes will be used for receiving or transmitting D2D signals only. Since the UE operating as a D2D device operates in a half duplex mode, the UE can receive or transmit D2D signals at any point in time. Similarly, Figure 4 other subframes shown in

[0126] Transmission procedure for D2D communication

[0127] The D2D data transmission procedure differs depending on the resource allocation mode. As described above for mode 1, the eNB explicitly schedules the resources for scheduling assignment and D2D data communication after a corresponding request from the UE. In particular, the eNB can inform the UE that D2D communication is generally allowed, but no mode 2 resources (i.e. resource pool) are provided; this can be done, for example, by the exchange of a D2D communication interest indication by the UE and a corresponding response (D2D communication response), wherein the corresponding exemplary ProSeCommConfig information element will not include commTxPoolNormalCommon, meaning that a UE wanting to start a direct communication involving transmission has to request the E-UTRAN to allocate resources for each individual transmission. Thus, in this case, the UE has to request resources for each individual transmission, and the following, for this mode 1 resource allocation, exemplary different steps of the request / grant procedure are listed:

[0128] • Step 1 : The UE transmits an SR (scheduling request) to the eNB via PUCCH;

[0129] • Step 2: The eNB grants UL resources (for the UE to transmit a BSR) via PDCCH scrambled by C-RNTI;

[0130] • Step 3: The UE transmits a D2D BSR indicating the buffer status via PUSCH;

[0131] • Step 4: The eNB grants D2D resources (for the UE to transmit data) via PDCCH scrambled by D2D-RNTI;

[0132] • Step 5: The D2D Tx UE transmits SA / D2D data according to the grant received in Step 4.

[0133] The Scheduling Assignment (SA), also called SCI (Sidelink Control Information), is a compact (low payload) message containing control information such as: pointer to time-frequency resources for the corresponding D2D data transmission, modulation and coding scheme, and group destination ID. The SCI transmission conveys the sidelink scheduling information for one (ProSE) destination ID. The content of the SA (SCI) is basically according to the grant received in Step 4 above. The D2D grant and SA content (i.e. SCI content) is defined in subclause 5.4.3 of the current version 13.0.0 of the 3GPP technical standard 36.212, incorporated herein by reference, which defines in particular the SCI format 0 (see above for the content of the SCI format 0).

[0134] On the other hand, for mode 2 resource allocation, the above steps 1-4 are basically not necessary, and the UE autonomously selects the resources for SA and D2D data transmission from a pool of transmission resources configured and provided by the eNB.

[0135] Figure 5 An exemplary illustration of the transmission of the Scheduling Assignment and D2D data for two UEs (UE-1 and UE-2) is shown, where the resources for the transmission of the Scheduling Assignment are periodic, and the resources for the D2D data transmission are indicated by the corresponding Scheduling Assignment.

[0136] Figure 6 The D2D communication timing for mode 2 (autonomous scheduling) during one SA / data period (also called SC period, Sidelink Control period) is illustrated. Figure 7 The D2D communication timing for mode 1 (eNB scheduled allocation) during one SA / data period is illustrated. The SC period is the time period comprising the transmission of the Scheduling Assignment and its corresponding data. As from Figure 6As can be seen from Figure 6 , for the eNB scheduled resource allocation mode (Mode 1), the D2D data transmission, i.e. more specifically the T-RPT pattern / bitmap, starts in the next UL subframe after the last SA transmission repetition in the SA resource pool. As already explained for Figure 7 , it is assumed that three retransmissions are performed (i.e. second, third and fourth transmission of the same MAC PDU). The Mode 2 T-RPT bitmap (transmitted time resource pattern, T-RPT) basically defines the timing of the MAC PDU transmission (first transmission) and its retransmissions (second, third and fourth transmission). The SA pattern basically defines the timing of the initial transmission of the SA and its retransmissions (second, third and fourth transmission).

[0137] As currently specified in the standard, for one sidelink grant, e.g. transmitted by the eNB or selected by the UE itself, the UE can transmit multiple transport blocks MAC PDUs (only one per subframe (TTI), i.e. one after the other), but only to one ProSe Destination Group. Furthermore, the retransmissions of one transport block have to end before the start of the first transmission of the next transport block, i.e. only one HARQ process is used per sidelink grant for transmitting multiple transport blocks. Furthermore, the UE can have and use multiple sidelink grants per SC period, but selects a different ProSe Destination for each of them. Thus, in one SC period, the UE can transmit data to only one ProSe Destination at a time.

[0138] As can be seen from Figure 7 , for the eNB scheduled resource allocation mode (Mode 1), the D2D data transmission, i.e. more specifically the T-RPT pattern / bitmap, starts in the next UL subframe after the last SA transmission repetition in the SA resource pool. As already explained for Figure 6 , it is assumed that three retransmissions are performed (i.e. second, third and fourth transmission of the same MAC PDU). The Mode 2 T-RPT bitmap (transmitted time resource pattern, T-RPT) basically defines the timing of the MAC PDU transmission (first transmission) and its retransmissions (second, third and fourth transmission). The SA pattern basically defines the timing of the initial transmission of the SA and its retransmissions (second, third and fourth transmission).

[0139] The sidelink data transmission procedure can be found in section 5.14 of the 3GPP standard document TS 36.321 v13.0.0, incorporated herein by reference. Therein, mode 2 autonomous resource selection is described in detail, distinguishing between being configured with a single radio resource pool or multiple radio resource pools. Assuming mode 2 autonomous resource selection, the following steps are taken from said section of TS 36.321 :

[0140] In order to transmit on the SL-SCH (Sidelink Shared Channel), the MAC entity must have at least one sidelink grant. The sidelink grant is selected as follows:

[0141] If the MAC entity is configured by upper layers to transmit using one or multiple resource pools and there is more data available in the STCH (Sidelink Traffic Channel) than can be transmitted in the current SC period, the MAC entity shall, for each sidelink grant to be selected:

[0142] • if configured by upper layers to use a single resource pool:

[0143] - then select this resource pool for use;

[0144] • else, if configured by upper layers to use multiple resource pools:

[0145] - then select from the resource pools configured by upper layers the resource pool(s) whose associated priority list includes the priority of the sidelink logical channel with the highest priority in the MAC PDU to be transmitted for use;

[0146] NOTE: If more than one resource pool has an associated priority list that includes the priority of the sidelink logical channel with the highest priority in the MAC PDU to be transmitted, which one of those resource pools to select is left to UE implementation.

[0147] • randomly select time and frequency resources for the SL-SCH and SCI of the sidelink grant from the selected resource pool(s). The random function shall be such that each of the allowed selections can be chosen with equal probability;

[0148] • use the selected sidelink grant to determine the set of subframes in which the transmission of the SCI and the first transport block occur according to subclause 14.2.1 of TS 36.213, incorporated herein by reference (this step refers to selection of T-RPT and SA mode as explained in connection with Figure 7 );

[0149] • consider the selected sidelink grant to be the configured sidelink grant that occurs in those subframes that start at the beginning of the first available SC period that starts at least 4 subframes after the subframe in which the sidelink grant was selected;

[0150] • clear the configured sidelink grant at the end of the corresponding SC period;

[0151] Note: The retransmission on SL-SCH does not occur after the configured sidelink grant has been cleared.

[0152] Note: If the MAC entity is configured by upper layers to transmit using one or more resource pools, how many sidelink grants are selected within one SC period taking into account the number of sidelink processes is left to UE implementation.

[0153] The MAC entity shall:

[0154] - if the MAC entity has a configured sidelink grant occurring in this subframe:

[0155] - then if the configured sidelink grant corresponds to the transmission of SCI:

[0156] - then instruct the physical layer to transmit the SCI corresponding to the configured sidelink grant.

[0157] - else if the configured sidelink grant corresponds to the transmission of the first transport block:

[0158] - then deliver the configured sidelink grant and the associated HARQ information to the sidelink HARQ entity for this subframe.

[0159] Note: If the MAC entity has multiple configured grants occurring in one subframe and if it is not possible to process all of them due to single cluster SC-FDM limitation, which of these is processed according to the above procedure is left to UE implementation.

[0160] The above text taken from the 3GPP technical standard can be further clarified. For example, the step of randomly selecting time and frequency resources is random with respect to which specific time / frequency resources are selected, but for example not random with respect to the amount of time / frequency resources selected in total. The amount of resources selected from the resource pool depends on the amount of data to be transmitted with said sidelink grant to be selected autonomously. In turn, the amount of data to be transmitted depends on the preceding step of selecting a ProSe Destination Group and the amount of corresponding data ready for transmission to said ProSe Destination Group. As described later in the sidelink LCP procedure, the ProSe Destination is first selected.

[0161] Furthermore, the sidelink processing associated with the sidelink HARQ entity is responsible for instructing the physical layer to generate and perform the transmission accordingly, as apparent from section 5.14.1.2.2 of 3GPP TS 36.321 v13.0.0, which is incorporated herein by reference. In short, after determining the sidelink grant and the sidelink data to be transmitted, the physical layer takes care of actually transmitting the sidelink data based on the sidelink grant and the necessary transmission parameters.

[0162] The above discusses the current status of the 3GPP standard for D2D communication. However, it should be noted that there are always discussions on how to further improve and enhance D2D communication, which will likely result in some changes to D2D communication in future releases. The present invention, which will be described later, should also apply to those later releases.

[0163] ProSe network architecture and ProSe entities

[0164] Figure 8 A high level exemplary architecture is illustrated for the non-roaming case, including different ProSe applications in the respective UEs A and B, and a ProSe application server and a ProSe function in the network. Figure 8 The exemplary architecture is taken from TS 23.303 v.13.2.0, chapter 4.2 "Architectural Reference Model", which is incorporated herein by reference.

[0165] The functional entities are presented and explained in detail in TS 23.303 subclause 4.4 "Functional Entities", which is incorporated herein by reference. The ProSe function is a logical function that serves network related actions required for ProSe and plays different roles for each feature of ProSe. The ProSe function is part of the EPC of 3GPP and provides all relevant network services related to proximity services, such as authorization, authentication, data handling, etc. For ProSe direct discovery and communication, a UE can obtain a specific ProSe UE identity, other configuration information, and authorization from the ProSe function over the PC3 reference point. Multiple ProSe functions can be deployed in the network, but for ease of illustration, a single ProSe function is presented. The ProSe function comprises three main sub-functions that perform different roles depending on the ProSe feature: a direct provision function (DPF), a direct discovery name management function, and an EPC level discovery function. The DPF is used to provide the UE with the necessary parameters to use ProSe direct discovery and ProSe direct communication.

[0166] The term "UE" used in said connection refers to a ProSe-enabled UE that supports ProSe functionality, such as:

[0167] • Exchange of ProSe control information between a ProSe-enabled UE and the ProSe Function over the PC3 reference point.

[0168] • Procedures for open ProSe direct discovery of other ProSe-enabled UEs over the PC5 reference point.

[0169] • Procedures for one-to-many ProSe direct communication over the PC5 reference point.

[0170] • Procedures as a ProSe UE-to-Network relay. Remote UEs communicate with the ProSe UE-to-Network relay over the PC5 reference point. The ProSe UE-to-Network relay uses Layer 3 packet forwarding.

[0171] • Exchange of control information between ProSe UEs over the PC5 reference point, e.g., for UE-to-Network relay detection and ProSe direct discovery.

[0172] • Exchange of ProSe control information between another ProSe-enabled UE and the ProSe Function over the PC3 reference point. In case of a ProSe UE-to-Network relay, the remote UE will send this control information over the PC5 user plane to be relayed to the ProSe Function over the LTE-Uu interface.

[0173] • Configuration of parameters (e.g., including IP address, ProSe Layer 2 group ID, group security material, radio resource parameters). These parameters can be pre-configured in the UE or, if in coverage, provided to the ProSe Function in the network through signaling over the PC3 reference point.

[0174] The ProSe Application Server supports storage of EPC ProSe User IDs, ProSe Function IDs, and mapping of application layer user IDs and EPC ProSe User IDs. The ProSe Application Server (AS) is an entity outside the 3GPP scope. The ProSe application in the UE communicates with the ProSe AS via the application layer reference point PC1. The ProSe AS is connected to the 3GPP network via the PC2 reference point.

[0175] Vehicle Communication - V2X Services

[0176] A new study item has been set up in 3GPP to consider the usefulness of new LTE features for the automotive industry - including Proximity Services (ProSe) and LTE-based broadcast services. ProSe functionality is therefore seen as a good basis for V2X services. Connected vehicle technology aims to address some of the biggest challenges in the surface transportation industry (e.g., safety, mobility, and traffic efficiency).

[0177] V2X communication is the communication of information from a vehicle to any entity that can impact the vehicle and vice versa. This exchange of information can be used to improve safety, mobility, and environmental applications to include driver-assisted vehicle safety, speed adaptation and warning, emergency response, travel information, navigation, traffic operations, commercial fleet planning, and payment transactions.

[0178] LTE support for V2X services includes the following 3 types of different use cases:

[0179] • V2V: covers LTE-based communication between vehicles.

[0180] • V2P: covers LTE-based communication between vehicles and devices carried by individuals (e.g., handheld terminals carried by pedestrians, cyclists, drivers, or passengers).

[0181] • V2I: covers LTE-based communication between vehicles and roadside units.

[0182] These three types of V2X can use "cooperative awareness" to provide more intelligent services for end users. This means that transmitting entities (e.g., vehicles, roadside infrastructure, and pedestrians) can collect knowledge of their local environment (e.g., information received from nearby vehicles or sensor equipment), process and share this knowledge to provide more intelligent services (e.g., cooperative collision warning or autonomous driving).

[0183] With respect to V2V communication, E-UTRAN allows UEs in the vicinity of each other to exchange V2V related information using E-UTRA(N) when the permission, authorization, and proximity criteria are met. The proximity criteria can be configured by the MNO (Mobile Network Operator). However, UEs supporting V2V services can exchange this information when served by or not served by E-UTRAN supporting V2X services.

[0184] A UE supporting V2V applications sends application layer information (e.g., about its position, dynamics, and properties as part of a V2V service). The V2V payload must be flexible to accommodate different information content, and the information can be sent periodically according to a configuration provided by the MNO.

[0185] V2V is mainly broadcast-based; V2V includes direct exchange of V2V related application information between unique UEs and / or exchange of V2V related application information between unique UEs via infrastructure supporting V2X services (e.g., RSU, application server, etc.) due to limited direct communication range of V2V.

[0186] With respect to V2I communication, a UE supporting a V2I application sends application layer information to a roadside unit, which in turn can send the application layer information to a group of UEs or UEs supporting a V2I application.

[0187] V2N (Vehicle-to-Network, eNB / CN) is also introduced, where one party is a UE and the other party is a service entity, both supporting a V2N application and communicating with each other via LTE network.

[0188] With respect to V2P communication, E-UTRAN allows UEs in proximity of each other to exchange V2P related information using E-UTRAN when the permission, authorization and proximity criteria are met. The proximity criteria can be configured by the MNO. However, even when not served by an E-UTRAN supporting V2X services, a UE supporting V2P services can exchange this information.

[0189] A UE supporting a V2P application sends application layer information. This information can be broadcast by a vehicle with a UE supporting V2X services (e.g., warning to pedestrians) and / or by a pedestrian with a UE supporting V2X services (e.g., warning to vehicles).

[0190] V2P includes the exchange of direct V2P related application information between unique UEs (one for vehicles and the other for pedestrians) and / or the exchange of V2V related application information between unique UEs due to the limited direct connectivity range of V2P via an infrastructure supporting V2X services (e.g., RSU, application server, etc.).

[0191] For this new study item V2X, 3GPP has provided specific clauses and definitions in the current version 13.0.0 of TR 21.905, which can be reused for this application.

[0192] Roadside Unit (RSU): an entity supporting V2I services that can send to and receive from UEs using V2I applications. A RSU can be implemented in an eNB or a fixed UE.

[0193] V2I service: a type of V2X service where one party is a UE and the other party is a RSU, both using V2I applications.

[0194] V2N service: a type of V2X service where one party is a UE and the other party is a service entity, both using V2N applications and communicating with each other via LTE network entities.

[0195] V2P service: a type of V2X service where both parties of the communication are UEs using V2P applications.

[0196] V2V service: A type of V2X service where both parties of the communication are UEs using V2V applications.

[0197] V2X service: A type of communication service that involves a transmitting or receiving UE using V2V applications via 3GPP. It can be further divided into V2V service, V2I service, V2P service and V2N service based on the other party involved in the communication.

[0198] 3GPP has also agreed on some potential requirements for V2X communication, where some of the relevant requirements will be presented below.

[0199] [CPR-011] E-UTRA(N) shall be able to support a maximum frequency of 10 V2X messages per second per V2X entity (e.g. UE and RSU).

[0200] [CPR-015] E-UTRA(N) shall be able to transfer V2X messages between two UEs supporting V2V service with a latency of maximum 20ms only for specific use cases (i.e. pre-crash sensing).

[0201] [CPR-018] 3GPP network shall make any supported location accuracy improvement techniques (e.g. DGPS and / or OTDOA) available in a resource efficient way for a subscribed UE supporting V2X services.

[0202] [CPR-026] 3GPP system shall be able to vary the transmission rate and coverage area based on the service conditions (e.g. UE speed, UE density).

[0203] [CPR-030] E-UTRAN shall be able to transfer V2X messages between UEs supporting V2V service with a maximum relative speed of 280 km / h.

[0204] Vehicle communication will presumably be based on ProSe direct communication. However, the normal Rel. 12 D2D resource allocation can not be sufficient for the new V2X use cases. In particular, as mentioned above, randomization is a fundamental principle used in D2D communication; in particular, for Mode 2, where the UE autonomously and randomly selects radio resources for communication from a configured pool of radio resources. In D2D based vehicle communication, time and frequency resource collisions can become a more serious problem, e.g. because of the increased packet size (due to vehicle applications that can transmit often and large amounts of data) and in particular for dense UE deployment scenarios (e.g. in urban scenarios) there are a large number of UEs in the target coverage.

[0205] Correspondingly, the currently conceived resource allocation for D2D-based vehicle communication can not be optimal and various adaptations to the new usage scenario will be required. SUMMARY

[0206] The non-limiting and exemplary embodiments provide an improved resource allocation method for vehicle communication with respect to a vehicle mobile terminal.

[0207] The independent claims provide non-limiting and exemplary embodiments. Advantageous embodiments are subject to the dependent claims.

[0208] According to several aspects described herein, the determination of the radio resources to be used by a vehicle mobile terminal for communicating with another mobile terminal, be it a vehicle mobile terminal or a normal mobile terminal, should be improved.

[0209] For discussing these aspects, the following exemplary assumptions are made. It is assumed that a vehicle mobile terminal has been properly set up for performing direct communication with other mobile terminals, i.e. via a corresponding sidelink connection. It is further assumed that the vehicle mobile terminal wants to communicate with other mobile terminals and thus needs to determine the specific sidelink radio resources to be used in said respect.

[0210] According to a first aspect, the determination of these radio resources is improved. In particular, the first aspect distinguishes between two different radio resource determinations, one taking into account the position of the vehicle mobile terminal and the other not taking into account the position of the vehicle mobile terminal. As known from the background section, normal sidelink resource allocation, e.g. mode 1 and mode 2, do not take into account the position of the (vehicle) mobile terminal, e.g. the mobile terminal autonomously selects a radio resource from a pool of radio resources (i.e. mode 2) and the radio base station makes a decision regarding the radio resource without reference to the position of the mobile terminal.

[0211] On the other hand, according to the first aspect, the resource allocation with respect to vehicle communication should be improved by taking into account the position of the vehicle mobile terminal. This can for example be implemented in such a way that based on the position of the vehicle mobile terminal, the radio resources normally available to the vehicle mobile terminal will be "restricted".

[0212] Exemplarily assuming UE autonomous resource selection (mode 2), different radio resource pools can be defined with respect to different possible positions of the vehicle, such that the vehicle mobile terminal will select radio resources from the radio resource pool associated with the specific position of the vehicle mobile terminal. The vehicle mobile terminal is configured with these different radio resource pools, such that it can autonomously select among the individual radio resource pools based on its determined position. There are several ways how the vehicle mobile terminal can be configured with these different radio resource pools. According to one way, explicit information about the radio resource pools (e.g. radio resources and association with possible positions of the vehicle mobile terminal) can be provided to the vehicle mobile terminal, e.g. within system information broadcasted by the radio base station in its cell or within a message dedicated to the vehicle mobile terminal. In another implementation, the different radio resource pools can not be explicitly informed to the vehicle mobile terminal, but can be determined by the vehicle mobile terminal itself based on general information about available radio resources and about a set of rules allowing the vehicle mobile terminal itself to allocate available radio resources to individual possible positions of the vehicle mobile terminal, thereby defining the different radio resource pools from which the vehicle mobile terminal can then select the necessary radio resources.

[0213] On the other hand, when exemplarily assuming eNB scheduled resource allocation (i.e. mode 1), then the vehicle mobile terminal will determine its position and in one form or another provide information about this to the radio base station, which in turn can then select appropriate radio resources based on the received position information of the vehicle mobile terminal (e.g. but not necessarily from radio resource pools). For example, the radio base station can select radio resources such that other (vehicle) mobile terminals in the vicinity will not experience interference from the vehicle mobile terminal communication. Correspondingly, the radio base station will then inform the vehicle mobile terminal about the decided radio resources, such that the vehicle mobile terminal can use them for communication with other mobile terminals.

[0214] Generally, the position assisted resource allocation shall assist in allocating radio resources that are orthogonal to each other, such that when nearby vehicle mobile terminals communicate at the same time, interference between them in the vicinity is reduced or completely avoided.

[0215] However, this improved resource allocation can not be optimal in all cases and should therefore be used selectively according to the first aspect. In more detail, a certain entity in the communication system, e.g. the eNB, or the ProSe related entity, or the MME, can have control over whether the improved location-aided resource allocation or the normal resource allocation without taking the location of the vehicle mobile terminal into account is to be used. The entity can take the decision based on various different parameters, e.g. the number of vehicles in the respective area, the speed of the vehicles, the cell topology of the respective area (e.g. highway or city center or rural etc.) and possibly other information. For example, in the case of a dense and slow moving traffic situation, the entity can decide not to aid the resource allocation by the vehicle location. For example, it can be difficult to distinguish the various locations of the nearby vehicle mobile terminals, so that the vehicle location-aided resource allocation can not be helpful. On the other hand, in the case of a free flowing, possibly medium or high speed traffic, the entity can decide that it is advantageous to also take the vehicle location into account when determining the radio resources for the communication with other mobile terminals. On the other hand, it can be possible to decide that also other surrounding roads can be possible in dense traffic situations, given the high vehicle density (more UEs in the same location area than on a highway) pushing up the demand for resources. Furthermore, whether to use the location-aided resource allocation or not can also depend on the time (e.g. traffic is typically dense while the traffic situation is different in peak hours).

[0216] Furthermore, the vehicle mobile terminal should be able to determine in some way which resource allocation it should use at a certain point in time (i.e. location-aided or not taking its location into account). Therefore, corresponding information has to be provided to the vehicle mobile terminal, which can be done in various different forms, two examples of which will be briefly discussed below. According to one possible implementation, the vehicle mobile terminal is provided with explicit information about the result of the decision, e.g. by a flag broadcasted in the system information of the radio base station instructing the vehicle mobile terminal whether or not to use the vehicle location. Another possible implementation allows the vehicle mobile terminal to infer whether or not to take its location into account from configured parameters in the vehicle mobile terminal, e.g. from parameters related to this improved location-aided resource allocation and used by the vehicle mobile terminal when determining its location or when determining the radio resources.

[0217] So far, the first aspect has been described in general terms with respect to the position of the vehicle mobile terminal. However, there are different ways with respect to how the position of the vehicle mobile terminal can be determined and presented. One possible way is to use geographical coordinates (e.g. longitude and latitude) known from GPS, for example. According to the improvement of the first aspect, the position of the vehicle mobile terminal is determined as a section and / or sub-section of the road on which the vehicle mobile terminal is currently travelling. Thus, in this sense, each road has a corresponding identification (e.g. road or street name and / or number and corresponding start and end location). Furthermore, it is assumed that information with respect to a map is available to the vehicle UE, which can also contain information with respect to the edges of a particular road. In particular, the road is divided into sections and / or sub-sections, thus allowing to actually simply represent the position of the vehicle mobile terminal by the identification of the section and / or sub-section of the road, rather than using geographical coordinates. Correspondingly, the vehicle mobile terminal will determine its position as a section of the road (which can still require the vehicle mobile terminal to first determine geographical coordinates and then translate these to the possible section / sub-section of the road on which it is located). This will also be advantageous in those cases where the information of the determined position of the vehicle mobile terminal is to be transmitted to the radio base station (e.g. for mode 1 resource allocation, where the radio base station makes the decision with respect to the radio resources), as the amount of information that needs to be transmitted can thus be reduced.

[0218] An exemplary division of the road is based on a grid overlaying the road, the grid thereby defining sections, which in turn are further subdivided into sub-sections. For example, each section can cover all lanes of the road and can span a certain length of the road. This section is then divided into a number of sub-sections, wherein, for example, one sub-section can cover only one or more but not all lanes of the road. The sub-sections can span the same length of the road as the section, or can only span a small fraction of the section, while the remaining length of the section is "covered" by other sub-sections. Furthermore, within a certain area having the same or similar characteristics, each section shall be provided (i.e. divided) into the same number of sub-sections, such that the grid repeats along the road with the sections.

[0219] This division of the road into sections and sub-sections can repeat for each section, the same association between a position within the section (i.e. a sub-section as a possible position of a vehicle) and a particular radio resource available to a vehicle mobile terminal located in this sub-section. Within each section, the distribution of available radio resources between the sub-sections of the section is such that interference shall be mitigated or avoided. For example, the various radio resources associated with the sub-sections within a section shall be orthogonal to each other. Furthermore, since the sections and thus the sub-sections and their associated (orthogonal) radio resources themselves repeat, the interference caused by vehicle mobile terminals communicating in adjacent sections shall likewise be mitigated or avoided.

[0220] According to a further refinement of the first aspect, the resource assignment is further refined by implementing sensing capabilities in the vehicle mobile terminal, determining whether another mobile terminal is using or will use potential radio resources, in which case these potential radio resources will be blocked and should not be used if possible. In particular, assuming exemplarily UE-autonomous radio resource selection (Mode 2), the vehicle mobile terminal will determine whether another mobile terminal is actually already using the potential radio resources (i.e. in the process of the vehicle mobile terminal actually selecting) before actually selecting a radio resource from the radio resource pool associated with its location. For example, the vehicle mobile terminal will be able to determine this by e.g. using the RSSI (Received Signal Strength Indication) measure, where it measures the total received signal strength (which is a measure of the transmitted energy) on the corresponding resource elements (REs) (e.g. PRB pairs) of a candidate (time-frequency) resource. When the RSSI is greater than a certain threshold, it is concluded that the resource is occupied. Furthermore, it can be statistically concluded that the resource will remain "busy" for a certain time (e.g. number of TTIs). This statistical conclusion can be based on a UE implementation of past "busyness" of resources in the same or adjacent pool, or can be signaled by the network, e.g. in RRC signaling (broadcast or dedicated). For example, a "busyness" of 2 would mean that, on average, after the observed instance, the resource remains "busy" for 2 control / data periods.

[0221] According to an alternative or additional method, individual candidate SA messages (PSCCH) will be received and decoded, and the vehicle mobile terminal can check whether they indicate any further "busyness" in the upcoming control / data period. If no individual candidate SA is currently being transmitted, the vehicle UE can assume the control (SA) and corresponding data resources to be "free". The "busyness" in the SA message can also indicate a corresponding busyness period, during which it intends to remain transmitting on the corresponding control / data resources. In the simplest form, it would be a Boolean value indicating a "busyness" period of 1 period or some other "fixed" number of periods.

[0222] Thus, in case the radio resource that is bound to be selected is blocked by another mobile terminal, the vehicle mobile terminal should select a different radio resource.

[0223] In addition, in case no other resources can be selected from the pool of radio resources associated with the location of the vehicle mobile terminal (e.g. due to the obstruction just explained), the vehicle mobile terminal should be able to select a radio resource from another pool of radio resources (i.e. a pool of radio resources associated with a location which is not the location of the vehicle mobile terminal). For example, this other pool of radio resources can be associated with a location which is just next to the actual location of the vehicle mobile terminal; alternatively, said other pool of radio resources can be associated with a location which is further or even most distant from the actual location of the vehicle mobile terminal. Alternatively or additionally, different relative priorities can be given to the individual sub-sections and associated radio resources based on the distance of the sub-sections from the sub-section in which the vehicle mobile terminal is located. For example, the priority decreases with increasing distance, so that the vehicle mobile terminal should select a radio resource from the other pool of radio resources associated with the sub-section having the highest (remaining) priority (i.e. the sub-section which is just next to the sub-section in which the mobile terminal is located).

[0224] This additional refinement of the vehicle mobile terminal performing a sensing of potential radio resources and then actually using them is particularly advantageous in case radio resource collisions are likely to occur. For example, it was discussed before that a road can be divided into sections and / or sub-sections, each sub-section being associated with a certain set of resources (e.g. a pool of resources) from which a vehicle mobile terminal (located in the associated position) can select a suitable radio resource. Depending on how the sections and / or sub-sections are actually set up, a sub-section can cover an area in which only one or a number of vehicle mobile terminals can be located at the same time and can thus use the same associated radio resources. By first determining whether a radio resource is already obstructed before actually using these radio resources for a communication with another mobile terminal, the sensing explained above with respect to the implementation of the refinement of the first aspect can avoid these radio resource collisions.

[0225] According to a second aspect which is different from the first aspect discussed above, also the determination of radio resources by a vehicle mobile terminal is improved. In addition, the second aspect distinguishes between two different radio resource determinations, however, in this case, one radio resource assignment includes an additional process of sensing whether another mobile terminal uses or will use a radio resource, while the other radio resource assignment does not involve an additional sensing procedure.

[0226] The sensing has been discussed above as a further refinement to the location-aided radio resource determination of the first aspect, but is considered as a separate improvement according to the second aspect. As explained above, sensing is to be understood as the capability of a vehicle mobile terminal to determine whether another mobile terminal uses or will use a potential radio resource. In case another (vehicle) mobile terminal will obstruct these potential radio resources, the vehicle mobile terminal can decide not to use them, thus avoiding collisions, and proceed with determining a different radio resource again.

[0227] The sensing can involve at least two different ways as to how to determine whether a radio resource is blocked. According to a first way, the received signal strength on the corresponding radio resource, e.g. the resource elements of a candidate PRB pair, is measured by the vehicle mobile terminal and compared to a threshold, such that finally it is considered that a radio resource is blocked in case the received signal strength is greater than the threshold. Thus, the vehicle mobile terminal is able to determine whether another mobile terminal is using a potential radio resource at that specific moment in time.

[0228] Additionally or alternatively, the vehicle mobile terminal can monitor SA (Scheduling Assignment) messages transmitted by other mobile terminals as part of the D2D transmission procedure. The SA message will indicate (in the same or a later subframe) the specific radio resources that will be used to transmit the associated data message. Thus, the vehicle mobile terminal will therefore be able to learn from the SA message which radio resources will likely be used in the future by these mobile terminals and thus be blocked from using.

[0229] The vehicle mobile terminal can perform sensing when determining the radio resources according to mode 1 (eNB scheduling) or mode 2 (UE autonomous). In particular, assuming mode 2 UE autonomous resource allocation, the vehicle mobile terminal should perform sensing before actually using a radio resource from the suitable radio resource pool. For example, the vehicle mobile terminal can first select a set of potential resources from the radio resource pool and can then sense whether these selected resources are blocked by another mobile terminal and then repeat the procedure until the vehicle mobile terminal finds a free (i.e. not blocked by another mobile terminal) radio resource in the radio resource pool. On the other hand, the vehicle mobile terminal can perform sensing on all possible radio resources of the radio resource pool before even selecting a set of potential resources and will then discard those radio resources from the radio resource pool that are blocked. Subsequently, the vehicle mobile terminal can select a radio resource among those free radio resources remaining in the radio resource pool.

[0230] As a further improvement to the second aspect, the radio resource allocation can be improved by additionally considering the location of the vehicle mobile terminal, as explained in detail with respect to the first aspect. In order to avoid repetition, reference is made to the above sections discussing the first aspect how the vehicle mobile terminal determines its location and how the location of the vehicle mobile terminal can be used when determining the radio resources, both in mode 1 as well as in mode 2 radio resource allocation, how the location can be geographic coordinates or identifiers indicating segments and / or sub-segments of a road division, etc.

[0231] Correspondingly, in a general first aspect, the technology disclosed herein characterizes a vehicle mobile terminal for determining a radio resource for communication with at least a second mobile terminal in a communication system. A processor of the vehicle mobile terminal determines whether a radio resource is to be determined based on a location of the vehicle mobile terminal, the determination being based on information received from an entity of the communication system. In case the radio resource is to be selected based on the location of the vehicle mobile terminal, the processor determines the location of the vehicle mobile terminal and determines a radio resource for communication with at least the second mobile terminal based on the determined location of the vehicle mobile terminal.

[0232] Correspondingly, in a general first aspect, the technology disclosed herein characterizes a radio base station in a communication system for assisting a vehicle mobile terminal in determining a radio resource for communication with at least a second mobile terminal in the communication system. A processor of the radio base station determines whether a radio resource is to be determined based on a location of the vehicle mobile terminal. The determination is based on at least information about vehicle mobile terminals in a cell of the radio base station. A transmitting unit of the radio base station transmits information to the vehicle mobile terminal based on which the vehicle mobile terminal determines whether a radio resource is to be determined based on the location of the vehicle mobile terminal.

[0233] Correspondingly, in a general first aspect, the technology disclosed herein characterizes a communication device comprising: receiving circuitry to receive parameter information in a cell in which the communication device is located; and control circuitry coupled to the receiving circuitry to determine whether to use a radio resource corresponding to a geographical location of the communication device based on the parameter information, wherein, in response to the parameter information indicating to use a radio resource corresponding to the geographical location of the communication device, the control circuitry is to: determine the geographical location of the communication device, identify a location sub-section in which the communication device is geographically located based on the parameter information, wherein the parameter information comprises a first parameter indicating a length of the location sub-section, a second parameter indicating a width of the location sub-section, a third parameter indicating a number of location sub-sections into which a location section is divided with respect to a longitude length, and a fourth parameter indicating a number of location sub-sections into which the location section is divided with respect to a latitude width, wherein the first parameter to the fourth parameter are dynamically signaled from a radio base station, dynamically determine a radio resource corresponding to the identified location sub-section in which the communication device is geographically located based on the first parameter to the fourth parameter, the length and the width of the location sub-section, and the number of location sub-sections into which the location section is divided with respect to the longitude and the latitude, and perform communication using the determined radio resource.

[0234] Correspondingly, in a general first aspect, the technology disclosed herein characterizes a method performed by a communication device, the method comprising: receiving parameter information in a cell in which the communication device is located; determining, based on the parameter information, whether to use radio resources corresponding to a geographical location of the communication device; in response to the parameter information indicating to use radio resources corresponding to the geographical location of the communication device, determining the geographical location of the communication device, identifying, based on the parameter information, a location sub-section in which the communication device is geographically located, wherein the parameter information comprises a first parameter indicating a length of the location sub-section, a second parameter indicating a width of the location sub-section, a third parameter indicating a number of location sub-sections into which a location section is divided with respect to a longitude length, and a fourth parameter indicating a number of location sub-sections into which the location section is divided with respect to a latitude width, wherein the first parameter to the fourth parameter are dynamically signaled from a radio base station, dynamically determining, based on the first parameter to the fourth parameter, the length and the width of the location sub-section, and the number of location sub-sections into which the location section is divided with respect to the longitude and the latitude, radio resources corresponding to the identified location sub-section in which the communication device is geographically located, and performing communication using the determined radio resources.

[0235] Correspondingly, in a general first aspect, the technology disclosed herein characterizes an integrated circuit for controlling a process of a communication device, the process comprising: receiving parameter information in a cell in which the communication device is located; determining, based on the parameter information, whether to use radio resources corresponding to a geographical location of the communication device; in response to the parameter information indicating to use radio resources corresponding to the geographical location of the communication device, determining the geographical location of the communication device, identifying, based on the parameter information, a location sub-section in which the communication device is geographically located, wherein the parameter information comprises a first parameter indicating a length of the location sub-section, a second parameter indicating a width of the location sub-section, a third parameter indicating a number of location sub-sections into which a location section is divided with respect to a longitude length, and a fourth parameter indicating a number of location sub-sections into which the location section is divided with respect to a latitude width, wherein the first parameter to the fourth parameter are dynamically signaled from a radio base station, dynamically determining, based on the first parameter to the fourth parameter, the length and the width of the location sub-section, and the number of location sub-sections into which the location section is divided with respect to the longitude and the latitude, radio resources corresponding to the identified location sub-section in which the communication device is geographically located, and performing communication using the determined radio resources.

[0236] Correspondingly, in a general first aspect, the technology disclosed herein characterizes an integrated circuit for controlling processing of a radio base station in a communication system to assist a communication device in determining radio resources for vehicle communication with at least a second communication device in the communication system, wherein the processing comprises determining whether to determine radio resources based on a location of the communication device, wherein the determination is based on at least information about the communication device in a cell of the radio base station, transmitting information to the communication device based on which the communication device determines whether to determine radio resources based on the location of the communication device.

[0237] Additional benefits and advantages of the disclosed embodiments will be apparent from the specification and drawings. Benefits and / or advantages can be provided singly from individual embodiments and features disclosed in the specification and drawings, or from any combination of the embodiments and features.

[0238] These general and specific aspects can be implemented using a system, a method, a computer program, and any combination of a system, a method, and a computer program. BRIEF DESCRIPTION OF DRAWINGS

[0239] Exemplary embodiments are described below with reference to the accompanying drawings.

[0240] Figure 1 An exemplary architecture of a 3GPP LTE system is shown,

[0241] Figure 2 An exemplary downlink resource grid of a downlink slot of a subframe defined with respect to 3GPP LTE (Release 8 / 9) is shown,

[0242] Figure 3 How a Layer 2 link over PC5 for ProSe communication is established is schematically shown,

[0243] Figure 4 Usage of transmission / reception resources for up (LTE) and down (D2D) systems is shown,

[0244] Figure 5 Scheduling allocation and transmission of D2D data for two UEs is shown,

[0245] Figure 6 D2D communication timing for UE-autonomous scheduling mode 2 is shown,

[0246] Figure 7 D2D communication timing for eNB-scheduled scheduling mode 1 is shown,

[0247] Figure 8 An exemplary architecture model for ProSe with respect to non-roaming scenarios is shown,

[0248] Figure 9A 、 Figure 9B 、 Figure 9C exemplarily illustrates different partitioning of a road into sub-sections and sections according to embodiments, and

[0249] Figure 10 exemplarily illustrates a sequence diagram for operation of a vehicle UE according to a first embodiment. DETAILED DESCRIPTION

[0250] A mobile station or mobile node or user terminal or user equipment is a physical entity within a communication network. A node can have several functional entities. A functional entity refers to a software module or hardware module that implements a predetermined set of functions and / or provides a predetermined set of functions to other functional entities of the node or network. A node can have one or more interfaces that attach the node to a communication facility or medium over which the node can communicate. Similarly, a network entity can have a logical interface that attaches the functional entity to a communication facility or medium over which it can communicate with other functional entities or corresponding nodes.

[0251] The term "radio resources" as used in this application is to be understood broadly as referring to physical radio resources, such as time-frequency resources.

[0252] The term "direct communication transmission" as used in this application is to be understood broadly as a transmission between two user equipments directly, i.e. not via a radio base station, such as an eNB. Correspondingly, a direct communication transmission is performed over a "direct sidelink connection", which is a terminology used for a connection established directly between two user equipments. For example, in 3GPP, the terminology of D2D (Device-to-Device) communication is used, or ProSe communication, or sidelink communication. The term "direct sidelink connection" is to be understood broadly and can be understood in the context of 3GPP as the PC5 interface described in the background section.

[0253] The term "ProSe" or in its non-abbreviated form "Proximity Services" as used in this application applies in the context of proximity-based applications and services in LTE systems, as exemplarily explained in the background section. Other terminologies are used in this context as well (e.g. "D2D") to refer to device-to-device communication for proximity services.

[0254] The term "vehicle mobile terminal" as used throughout this application is to be understood in the context of the new 3GPP study item V2X (Vehicle Communication) as explained in the background section. Correspondingly, a vehicle mobile terminal is to be understood broadly as a mobile terminal specifically installed in a vehicle (e.g. a car, a commercial truck, a motorcycle, etc.) for the purpose of providing vehicle communication (i.e. communicating information related to the vehicle to other entities (e.g. vehicles, infrastructure, pedestrians)) for safety or driving assistance purposes. Optionally, the vehicle mobile terminal can have access to information available at a navigation system (in case it is installed in the car as well) (e.g. map information, etc.).

[0255] The term "road" as used throughout this application is to be understood broadly covering any ground on which a vehicle can be driven, including a highway, a motorway, a path, a route, a street, a road.

[0256] As explained in the background section, 3GPP has introduced a new study item on LTE- assisted vehicle communication, which shall be based on ProSe procedures including resource allocation according to mode 1 and mode 2. However, ProSe-based resource allocation can not be sufficient to meet all requirements with respect to V2X communication and can therefore need to be adapted.

[0257] The inventors envision the following exemplary embodiments to mitigate one or more of the above-mentioned problems.

[0258] Particular implementations of the various embodiments are to be accomplished within the broad specifications given by the 3GPP standards and are partially explained in the background section, wherein specific key features are added as explained below as belonging to the various embodiments. It should be noted that the embodiments can advantageously be used in e.g. a mobile communication system such as the 3GPP LTE-A (Release 10 / 1 1 / 12 / 13) communication system (or later releases) described in the technical background section above, but the embodiments are not limited to their use in this particular exemplary communication network.

[0259] The explanations should not be understood to limit the scope of the present disclosure but are merely examples of embodiments for a better understanding of the present disclosure. The skilled person should note that the general principles of the present disclosure as set out in the claims can and are applied to different scenarios in ways not explicitly described herein. For the purpose of illustration, several assumptions are made, however, they shall not limit the scope of the following embodiments.

[0260] Furthermore, as mentioned above, the following embodiments can be implemented in a 3GPP LTE-A (Rel. 12 / 13) environment, but possibly also in future releases. The various embodiments mainly provide an improved resource allocation for a vehicular mobile terminal. Thus, other functionality (i.e. functionality not changed by the various embodiments) can remain exactly the same as explained in the background section, or can change without any consequences for the various embodiments. This includes, for example, other procedures related to the actual usage of the determined (sidelink) radio resources (i.e. after having selected the radio resources), and the vehicular UE uses them to perform the transmission of data (possibly also including the transmission of the scheduling assignment).

[0261] First embodiment

[0262] In the following, a first embodiment for solving the above-mentioned problems will be described in detail. Also different implementations of the first embodiment and variants will be explained.

[0263] Exemplarily, a vehicular UE is assumed which is installed in a vehicle and which is capable of performing vehicular communication based on the D2D framework explained in the background section of the present application. It is further assumed that the vehicular UE shall communicate with other UEs and thus needs to first determine suitable sidelink radio resources to be used for said purpose. The first embodiment focuses on how the vehicular UE can efficiently determine the sidelink radio resources, so that then the determined radio resources can be used in a normal way to communicate with other (vehicular) UEs.

[0264] The radio resource allocation according to the first embodiment is based on the radio resource allocation already defined for D2D communication, thus generally distinguishing between mode 1 and mode 2 resource allocation as explained in detail in the background section. However, independent of the mode 1 and mode 2 resource allocation, the first embodiment additionally distinguishes between two different radio resource allocations which are different from each other, as will be explained in the following. One of the two radio resource allocations shall be the common radio resource allocation for D2D communication as explained in detail in the background section; it is apparent therefrom that the location of the (vehicular) UE has no influence on which radio resources are determined in the mode 1 or mode 2 resource allocation process. On the other hand, the second radio resource allocation according to the first embodiment is also based on the radio resource allocation for D2D communication, but additionally takes into account the location of the vehicular UE when determining the radio resources, as will be explained in more detail in the following.

[0265] The vehicle UE shall determine the radio resources according to one of the two above radio resource methods, and thus has to be informed / instructed which resource allocation it shall use. This step of informing the vehicle UE about which method of resource allocation to use can be performed by a suitable entity in the mobile communication system, e.g. the eNodeB, the MME or a ProSe related entity in the core network. This entity can also be responsible for deciding which method of resource allocation to use, and also for letting the UE know which method of resource allocation it shall use. For ease of explanation, in the following it is exemplarily assumed that the eNodeB is the entity responsible for taking the decision and informing the vehicle UE.

[0266] Assuming that the vehicle UE is to use the improved method of resource allocation introduced in the first embodiment, the vehicle UE shall determine its position, and then determine the radio resources based on the just determined position of the vehicle UE.

[0267] On the other hand, assuming that the vehicle UE is not to use the improved position assisted method of resource allocation, but the normal method of resource allocation as explained before with respect to D2D, then the vehicle UE does not have to determine its position with respect to the radio resource determination. Instead, the vehicle UE will determine the suitable radio resources for communicating with another UE in the normal way according to mode 1 or mode 2.

[0268] As broadly outlined above, the improved position assisted method of resource allocation by the first embodiment shall be selectively used under control of an entity in the mobile communication system, e.g. the eNodeB. Correspondingly, it is also considered that the resource allocation taking into account the vehicle position is not applied in all cases, but only when a substantial benefit is provided.

[0269] Generally, it should be noted that additionally considering the position of the vehicle UE in the resource allocation process can have the following benefits. Using the position as a basis for the resource allocation allows the network to contribute different amounts of resources for V2X communication based on traffic statistics, e.g. higher resources for V2X communication in more traffic dense locations, and lower resources for V2X communication in sparsely traffic areas. Furthermore, for a special implementation of the first embodiment to be discussed later, the position and the vehicle UE only sense a limited part of the available resource pools with the corresponding resource requirements. For example, if there are up to 32 configured resource pools and only a couple of them belong to the position of the vehicle UE, then sensing has to be performed only in these two resource pools. This saves not only time but also battery.

[0270] On the other hand, determining the position of a vehicle UE and possibly also sending information about this to the eNB for radio resource allocation has drawbacks: it requires the vehicle UE to repeatedly track its position, and it consumes radio resources for informing the eNB about the position, assisting resource allocation. The benefits and drawbacks of position assisted resource allocation need to be balanced. Therefore, the first embodiment selectively uses the improved position assisted resource allocation method for certain situations, but not for other situations.

[0271] Figure 10 is a sequence diagram for a vehicle UE exemplarily showing the operation of a vehicle UE as explained above with respect to the first embodiment.

[0272] In the following, more specific implementations of the first embodiment will be explained, which can provide further advantages.

[0273] The above broad explanation of the first embodiment relates to an entity (e.g. the eNB) which selectively makes a decision about using one resource allocation method or another resource allocation method (i.e. whether or not to additionally consider the vehicle UE position). As explained above, especially in certain situations, additionally considering the vehicle position for resource allocation can provide benefits. Correspondingly, the eNB can base its decision on suitable information which allows to distinguish between these different situations. The information can for example comprise at least one of the following: information about the number of vehicles in a certain area, the speed and / or direction of the vehicles, the traffic situation in a certain area (e.g. whether there is dense traffic or free flowing traffic, traffic congestion), the cell topology of a certain area (e.g. highway, city center or countryside), the time of day (as the traffic situation can change during the day). For specific implementations of the first embodiment, further information which can be important for the decision can comprise information about how a road is divided into segments and / or subsegments, as will be explained in detail later. Correspondingly, when deciding about whether a certain vehicle UE should use its vehicle position for the decision when determining the radio resources, the eNB can also consider the specific division of the road into subsegments and segments.

[0274] The following two examples are provided to understand how this decision can be performed. For example, assume a dense and slow moving traffic situation, in which vehicles are positioned side by side, so that it can be difficult to distinguish between the various positions of these nearby vehicle UEs. In said situation, the benefits that can be gained from additionally using position information for resource allocation can become minimal, and therefore, the eNB can decide that vehicle UEs in a certain area should not use the improved position assisted resource allocation method, but the normal D2D resource allocation.

[0275] In another example, a free flowing traffic scenario is assumed, in which vehicles can drive at medium or high speed and in which the positions of the individual vehicles can easily be distinguished due to the distance that is kept between the vehicles by the vehicle drivers. Correspondingly, in this case it can be beneficial to assist the radio resource allocation by also taking into account the positions of the individual vehicles.

[0276] Thus, the eNB will take this decision in either way and should then make sure to instruct the vehicle UEs to perform the resource allocation accordingly.

[0277] Many ways can be conceived on how to provide the vehicle UEs with appropriate information on whether to use one resource allocation method or another. This also depends on the cell area controlled by the eNodeB. In particular, the cell area can be small or large and can thus also be different in that they cover certain homogeneous areas with similar traffic scenarios, in which the eNodeB will draw the same decision on whether to use position assisted resource allocation or not. In said case, all vehicle UEs reachable by the eNodeB in its cell will be configured in the same way to use or not to use position assisted resource allocation and the eNodeB can typically provide the corresponding information in a broadcast in its cell.

[0278] On the other hand, the cell of the eNodeB can cover several different roads with different characteristics, leading to the eNodeB to differentiate between different areas of its cell on whether to use position assisted resource allocation or not. Correspondingly, only some of the vehicle UEs reachable by the eNodeB in its cell will be configured in the same way, while other vehicle UEs will be configured differently. In this case, a cell broadcast can not be applicable, but the different vehicle UEs can be configured / informed by corresponding dedicated messages.

[0279] According to one possible implementation of the first embodiment, the vehicle UEs are explicitly instructed to perform either of the two resource allocation methods, which can be done by a corresponding flag, which in turn can be sent in the system information broadcast by the eNodeB in its cell or in a corresponding dedicated message addressed to a specific vehicle UE, as explained. The flag can be 1 bit long, in which each of the two bit values unambiguously instructs the vehicle UE to use either of the two resource allocation methods distinguished in the first embodiment.

[0280] Alternatively or additionally, instead of providing explicit instructions to the vehicle UEs, the second implementation of the first embodiment is based on the vehicle UEs inferring from their internal configuration whether or not to use the improved location-aided resource allocation method. Specifically, in order to apply the location-aided resource allocation method, the vehicle UEs will typically be configured with additional parameters related to this improved location-aided resource allocation. For example, as will be explained in detail below, the location of the vehicle UEs can be determined based on segments and / or sub-segments of the road they are driving on. In this case, in order for the vehicle UEs to be able to identify a specific segment and / or sub-segment, they can be provided with suitable information about the segments and / or sub-segments of the road. Thus, if the vehicle UEs are configured with these parameters for use in determining the location, they will determine that they should also use these parameters and thus the location-aided resource allocation method. Conversely, if the vehicle UEs inform that they have not been configured with these parameters so far, they will determine that the improved location-aided resource allocation method should not be used; in fact, due to the missing parameters, the vehicle UEs will not be able to determine the location as a function of the segment / sub-segment. However, this is just an example and there are other parameters that can also be configured in the vehicle mobile terminals in conjunction with both resource allocation methods. For example, in case the normal D2D resource allocation method should be used, the implementation of the first embodiment specifically provides a certain, larger pool of radio resources for vehicle communication. In this case, if the vehicle UEs determine that this larger pool of radio resources is configured, they will infer that the normal D2D resource allocation method is used instead of the location-aided resource allocation method. These pools of radio resources can be signaled, as in the legacy (e.g. public) resource pools in SIB19, or dedicated resource pools are sent to RRC connected UEs using RRC dedicated messages.

[0281] In any case, according to the various implementations of the first embodiment, each of the vehicle UEs will know at any time whether one or the other resource allocation method is to be used.

[0282] The above broad explanation of the first embodiment generally explains that the vehicle UEs will determine the radio resources based on their location, without going into details on how the radio resources are actually determined. As mentioned above, the two radio resource allocation methods distinguished by the first embodiment can exemplarily be based on the public D2D resource allocation, as explained in detail in the background section. Correspondingly, according to the implementations of the first embodiment, the mode 1 and mode 2 resource allocation are likewise distinguished, respectively extended, so as to likewise take into account the vehicle UE location.

[0283] According to mode 1 resource allocation, the eNB controls which radio resources a (vehicle) UE should use in its cell. Correspondingly, when radio resources need to be determined, the vehicle UE will request the eNodeB (which controls the radio cell in which the vehicle UE is located) about these radio resources. In detail, this can be done by the vehicle UE sending a scheduling request followed by a buffer status report to the eNodeB, as exemplarily explained in the background section with respect to D2D communication for the current 3GPP release.

[0284] The eNodeB, based on the received scheduling request and buffer status report, knows that this particular vehicle UE has data to send, and can then make a decision about the particular radio resources to be scheduled for this vehicle UE, allowing it to communicate with other UEs. According to the improved location-aided resource allocation method of the first embodiment, the eNodeB additionally receives location information from the vehicle UE (e.g. together with the buffer status report and scheduling request), and will also take this vehicle location information into account when determining the radio resources. In particular, the eNodeB will know the location of each vehicle UE as well as normal UEs in its area, and can therefore use its knowledge of the topology, vehicle density, traffic demand, out-of-band emissions, interference situation, etc. to schedule resources to vehicle UEs such that interference between them is mitigated.

[0285] The corresponding response from the NodeB to the vehicle UE will then include a suitable indication of the radio resources that the vehicle UE should use for communication with other mobile terminals. The vehicle UE will receive the corresponding response from the eNodeB, and can then perform vehicle communication, e.g. including transmitting scheduling assignment messages and data in the normal way on the radio resources scheduled by the eNodeB.

[0286] For the just described mode 1 resource allocation approach, it is assumed that the vehicle UE position is provided to the eNodeB. This operation can be done in various ways and also depends on the actual content of the vehicle UE position sent to the eNodeB. As will be explained in more detail later, the vehicle UE position can typically be presented as geographical coordinates (e.g. GPS) or segments / subsegments into which a road can be divided. Correspondingly, there is also a difference with respect to the amount of data sent, where geographical coordinates require more data and the ID of a segment / subsegment assumes that less data will be needed. In any case, the vehicle UE position can be sent to the eNodeB together with the scheduling request and the buffer status report. The information about the vehicle UE position can be carried separately from the scheduling request and the buffer status report or the scheduling request can be extended with a field carrying said information about the vehicle UE position. Another possible way to do this would be to use the RRC SidelinkUEInformation message which includes the latest position each time the position information changes substantially (e.g. every 100 ms or so).

[0287] Correspondingly, the vehicle UE will be able to determine the radio resources according to mode 1 additionally based on its own position. This mode 1 request will include the SidelinkUEInformation message which includes the details of the size and periodicity of the required V2X / V2V message transmission and then, a BSR report or the like indicating any change of buffer occupancy.

[0288] According to mode 2 resource allocation (also known as UE autonomous resource selection), the UE is adapted to select the radio resources itself, e.g. from a pool of available radio resources, to be able to send control information (SA message) and user data via a direct sidelink connection. As mentioned above, the first embodiment additionally provides a resource allocation approach which can take into account the position of the vehicle UE. This can be exemplarily implemented in the first embodiment by providing different radio resource pools with respect to different possible positions of the vehicle UE. In particular, a plurality of radio resource pools will then have to be configured in the vehicle UE, each of which will be associated with a different position in which the vehicle UE can be located. Correspondingly, when the vehicle UE needs to determine the radio resources and after determining its own position, the vehicle UE will first determine which radio resource pool to use (i.e. the radio resource pool associated with the determined vehicle UE position) and then will select the appropriate radio resources from this associated radio resource pool for sending the scheduling assignment and the data.

[0289] The configuration of the plurality of radio resource pools in the vehicle UEs described above can be under control of the eNodeB. Correspondingly, the eNodeB has to provide the vehicle UEs with the necessary information about the plurality of radio resource pools and their respective association with potential vehicle UE locations. According to one implementation of the first embodiment, the radio resource pools can be explicitly informed to the vehicle UEs, e.g. as a table identifying the radio resources and the associated locations. The following exemplary table is presented in that respect, assuming that x different radio resource pools are defined. The parameter x of the procedure can vary depending on the size of the radio cell, the available radio resources that the eNodeB intends to make available for vehicle UEs in its radio cell and possibly also other conditions including traffic type / speed etc. under control of the eNodeB.

[0290] Position Radio resource pool Orientation 1 Offset 1; number of PRBs; PRB-start; PRB-end Orientation 2 Offset 2; number of PRBs; PRB-start; PRB-end Orientation 3 Offset 3; number of PRBs; PRB-start; PRB-end … … Orientation x Offset x; number of PRBs; PRB-start; PRB-end

[0291] Correspondingly, the table can be provided by the eNodeB to the individual vehicle UEs in its radio cell, e.g. as part of the system information if the eNodeB wishes to configure all vehicle UEs in its cell in the same way or alternatively / additionally within messages dedicated to specific vehicle UEs.

[0292] As a further improvement, it can be possible to send the common values, e.g. the number of PRBs, only once, instead of sending it for each and every resource pool, thereby reducing the amount of data the eNodeB has to send to the vehicle UEs.

[0293] As an alternative to providing so much information about the radio resource pools from the eNodeB to the vehicle UEs, an alternative implementation of the first embodiment provides that the vehicle UEs themselves should be able to determine the radio resource pools and the associated locations. This can be done by using a set of rules that can divide a large resource pool among several radio resource pools associated with different locations. For example, the vehicle UEs can successively allocate a fixed amount of radio resources from a larger radio resource pool to a specific location, thereby generating different radio resource pools for different locations. This can look like a physical grid of resources, where in the simplest form each section of the grid represents a part from the whole available resource pool, so that adjacent sections of the grid represent the next part from the whole available resource pool, and so on.

[0294] According to a further implementation of the first embodiment, the resource assignment should be further improved by providing the vehicle UE with a sensing capability of the radio resources, as will be explained below. The exemplary term "sensing capability" should be understood broadly as the capability of the vehicle UE to determine whether other (vehicle) UEs use or will use a candidate radio resource (i.e. a radio resource which can be used for vehicle communication) to then not use these "blocked" radio resources if possible to avoid a corresponding collision with other (vehicle) UEs. Furthermore, the vehicle UE should use other radio resources determined not to be already used by another (vehicle) UE if possible. This sensing capability can be applied by the vehicle UE for mode 1 and mode 2 resource assignment and is on top of the additional consideration of the vehicle position when determining the radio resources, as explained in detail above.

[0295] Generally, sensing provides various benefits. For example, a sensing based collision avoidance mechanism helps to reduce resource collisions when a UE reads the control information of other UEs to avoid using the same resources for its transmission. Furthermore, sensing based resource assignment and location based resource pool partitioning have significant performance gain (i.e. PRR (Packet Reception Rate)) which significantly goes up with respect to the resource selection / assignment method in case of sensing. PRR basically describes how percent of vehicles in a given range (e.g. 100m) receive the transmitted packets from a given vehicle UE. Furthermore, sensing reduces the number of transmissions made by a UE, bringing lower in-band emission. This brings better near-far performance and saves resources.

[0296] Exemplarily, it is assumed that the vehicle UE is configured for mode 2 resource allocation and that the vehicle position is additionally taken into account with respect to the radio resource determination according to the first embodiment and, thus, the vehicle UE shall autonomously select a radio resource from the pool of radio resources associated with the determined position of the vehicle UE. Furthermore, the vehicle UE shall perform sensing such that no radio resource is used which is used or will be used by another (vehicle) UE. This operation can be realized in different ways. For example, the vehicle UE will select a set of candidate radio resources from the appropriate pool of radio resources associated with its position. However, before actually using the set of candidate radio resources, the vehicle UE shall first determine whether these radio resources are actually blocked by another mobile terminal. Then, in case another mobile terminal uses or will have used the radio resource, the vehicle UE shall repeat the process and select a different radio resource from the pool of radio resources which is then again checked with respect to whether it is blocked or not. This process can continue until the vehicle UE determines a radio resource from the pool of radio resources which is not blocked by another mobile terminal. On the other hand, the vehicle UE can perform sensing on all radio resources of the pool of radio resources before actually selecting a set of candidate radio resources from the pool of radio resources and then eliminate / discard those radio resources from the pool of radio resources which have been determined to be used or will be used by another UE. Correspondingly, the vehicle UE will then select a radio resource from among the remaining free radio resources of the pool of radio resources to be used for the communication.

[0297] A further refinement of this sensing capability considers the case that another mobile terminal uses or will use all radio resources of the radio resource pool, so that the vehicle UE is blocked from performing vehicle communication for a certain time. To avoid this situation, the implementation of the first embodiment allows that the vehicle UE can select a radio resource from another radio resource pool, i.e. a radio resource pool that is actually not associated with its own location but with another location. This will increase the likelihood that the radio resource from this other radio resource pool will not be blocked and will enable the vehicle UE to perform vehicle communication using said radio resource. As mentioned above, the vehicle UE can be configured with a plurality of different radio resource pools and according to one implementation the UE can randomly determine the other radio resource pool from which to select a radio resource. Alternatively, instead of randomly selecting the other radio resource pool, the vehicle UE can use the radio resource pool that is associated with a location that is right next to the actual location of the vehicle UE. On the other hand, the vehicle UE can use another resource pool that is associated with a location that is far away or even remote from the actual location of the vehicle UE. According to yet another alternative, the vehicle UE can assign a relative priority to each of the available radio resource pools based on a previously determined priority assignment scheme. Then, the vehicle UE can select the radio resource pool from the remaining radio resource pools that has the highest priority. For example, the relative priority can be assigned to the plurality of radio resource pools based on the distance to the actual location of the vehicle UE, so that a radio resource pool associated with a nearby or more remote location will be assigned a high priority.

[0298] On the other hand, when assuming a mode 1 resource allocation, the vehicle UE after having received a message from the eNodeB indicating the radio resources that the vehicle UE should use for communication should also perform sensing on these received and instructed radio resources and then actually use them for communication. In the same way, the vehicle UE can conclude that another (vehicle) UE uses or will use the instructed radio resources and will therefore not use them to avoid a collision. Furthermore, the vehicle UE can then again request resources from the eNodeB or can continue to autonomously select a radio resource from a suitable radio resource pool (e.g. associated with its location) to avoid a delay caused by having to request radio resources from the eNodeB again.

[0299] The vehicle UE can determine that the radio resources are or will be used in at least two different ways. According to a first implementation, the vehicle UE will measure the received signal strength (e.g. RSSI, received signal strength indication) on the corresponding resource elements (REs) (e.g. PRBs) of the candidate resources. The received signal strength is an indication whether or not another mobile terminal has used these radio resources. Correspondingly, by comparing the measured received signal strength with a suitable threshold, the vehicle UE can identify radio resources which must be considered to have been used by another UE and thus are blocked with respect to the vehicle UE. Furthermore, the vehicle UE can continue to measure the received signal strength with respect to the candidate resources and thus determine when other UEs will stop using them or will just assume that these radio resources are blocked for a certain time period (e.g. determined statistically from previous monitoring of the radio resources or instructed by the network via corresponding RRC signaling) without actually continuing to measure the received signal strength with respect to those radio resources.

[0300] According to a second implementation, the vehicle UE can monitor scheduling assignment messages transmitted by other (vehicle) UEs which indicate which radio resources will be used for transmitting data. Correspondingly, the vehicle UE will thus learn which radio resources will be used by other mobile terminals. Furthermore, the SA messages can also indicate the time period for which the radio resources will be repeatedly used, thus allowing the vehicle UE to determine radio resources which are blocked in the future.

[0301] The two different implementations on how the vehicle UE can determine whether or not a radio resource is blocked can be used in parallel to each other or separately, or only one of them can be used by the vehicle UE.

[0302] Generally, the process of additionally including a sensing by the vehicle UE before actually using the radio resources is especially advantageous in those cases where a radio resource collision is likely to occur. Although not discussed so far, depending on how precisely the possible vehicle positions can be distinguished from each other, at a certain position there can be only one vehicle UE or substantially more than one vehicle UE. For example, assuming that a pool of radio resources is associated with a certain position (area) at which several vehicle UEs can be located at the same time, so that several vehicle UEs can select radio resources from this pool of radio resources at the same or similar time, thereby increasing the likelihood of selecting the same radio resource and thus causing a collision. By implementing this sensing capability in the vehicle UEs, some of these collisions will be avoided, thereby increasing the throughput in the vehicle communication and avoiding retransmissions.

[0303] According to the broad embodiments explained previously, it is assumed that the vehicle UE determines its position and uses it for determining the radio resources (using either mode 1 or mode 2 radio resource allocation). As will be explained below, some implementations of the first embodiment focus on how the position of the vehicle UE can be represented in an efficient way.

[0304] According to one possible way, the vehicle UE position can be expressed as geographical coordinates which can be derived by known means, e.g. based on GPS satellites. The geographical coordinates will comprise at least longitude and latitude, e.g. in decimal degrees or in degrees, minutes and seconds. In this case, the vehicle UE will determine its geographical coordinates and will then take these into account when determining the necessary radio resources. For example, for mode 1 resource allocation, the vehicle UE will send these geographical coordinates to the eNodeB which in turn will use them for selecting the appropriate radio resources and for sending the corresponding message back to the vehicle UE through the scheduled radio resources. For mode 2 resource allocation, the UE will compare its determined position with geographical coordinates associated to different radio resource pools and can then select the radio resource pool associated to the geographical coordinates which are closest to the geographical coordinates of the vehicle.

[0305] According to a further implementation of the first embodiment, the vehicle position will be expressed completely differently, i.e. as a function of the segments and / or subsegments into which a road is divided. This will be explained with reference to Figure 9A , Figure 9B and Figure 9C , Figure 9A , Figure 9B and Figure 9C show exemplary divisions of a road into segments and subsegments. Each of these figures exemplarily is based on a 4-lane road, wherein all 4 lanes shall carry traffic travelling in the same direction. As shown in these figures, there are many possibilities how a portion of a road can be divided into different segments and subsegments. For Figure 9A , Figure 9B and Figure 9C , it is exemplarily assumed that each segment covers all lanes of the road, but this need not be the case. Furthermore, the same extension of a road can be divided into a different number of segments, wherein the different segments will then differ in their length. Further, the re-division of the segments into subsegments can also be performed in many different ways. For example, in Figure 9A and Figure 9B , it is exemplarily assumed that 16 different subsegments are provided, as shown. On the other hand, according to Figure 9C , a subsegment shall only cover one lane, but is of the same length as a segment, thus resulting in fewer subsegments.

[0306] How the segments and subsegments are set can be determined by a suitable entity in the mobile communication system, e.g. an entity which is also responsible for deciding which radio resource allocation method is to be used, e.g. an eNodeB, an MME or a ProSe-related entity. The length and width of the segments and subsegments can be determined by this entity, which can take different parameters into account in this respect. In Figure 9A ,Figure 9B and Figure 9C In the exemplary assumed case of a road segment with a width equal to the width of the road and a sub-segment with a width equal to the width of a lane (e.g. 4m). The length of a sub-segment can depend on the speed of a vehicle driving on the road, the inter-vehicle distance as a function of the speed of the vehicle, and also on whether one car per sub-segment or several cars per sub-segment shall be assumed. For example, in the case of one car per sub-segment only, an inter-vehicle distance of about 97m (2,5 seconds * 140km / h, see Table A.1.2-1 of TS 36.885 for highway case) in the same lane can be used as the length of a sub-segment to ensure that only one vehicle is located in the same sub-segment. There are exemplary data for absolute vehicle speeds in the highway case. The highway case has been chosen because it represents the fastest moving traffic and it is clear (e.g. to a vehicle driver) that the time for reaction is minimal in this case. Thus, if the fastest required latency to transmit a critical message to pass to other vehicles in the highway case can be met, it can very likely be possible in other cases as well.

[0307] On the other hand, the length of a segment can be determined based on the required effective range of vehicle communication given in Table A.1 of TS 22.885. For example, for the highway (motorway) case, the required effective range is 320 meters. Furthermore, to ensure mitigation of interference between two adjacent segments, it is exemplary assumed that twice the required effective range is applied as the length of a segment (i.e. 640 meters). In this case, assuming a length of a segment of 640 meters and assuming a length of a sub-segment of about 97 meters, an exemplary division can divide the length of a segment into seven sub-segments each having a length of 91 meters.

[0308] Alternatively, it is feasible to provide longer sub-segments in view of the fact that a UE shall only make one transmission in e.g. 100ms, so it can not be efficient to occupy the entire resources of a sub-segment for a UE for the remaining 99ms as well. In said case, by increasing the length of a sub-segment, it is possible to have more than one vehicle UE in a sub-segment. Figure 9C This case is exemplary shown in Fig. 4, Figure 9C with sub-segments having the same length as the segment. Correspondingly, when exemplary assuming a mode 2 resource allocation, the sub-segments will still be associated with a radio resource pool and the vehicle UEs located in the sub-segments will randomly select radio resources from the same radio resource pool associated with the sub-segment to perform vehicle communication. It is also the case that the above additional sensing applies is particularly advantageous because several UEs are selecting radio resources from the same radio resource pool and can thus create collisions; collisions can be avoided by having the vehicle UEs first determine whether radio resources are or will be free and then actually use them.

[0309] As exemplarily explained above, a road can thus be divided into segments and subsegments of a certain length and width. Moreover, it is assumed that at least for certain areas, each segment shall be divided into subsegments in the same way, as illustrated by the respective Figure 9A , Figure 9B and Figure 9C . In difference, a road is thus divided into various subsequent segments, which in turn are divided into subsegments in the same way.

[0310] Each of the subsegments can then be associated with a (different) radio resource, so that the radio resource for a certain vehicle UE can be determined by also considering the location of the vehicle UE, i.e. the segment / subsegment. For example, when assuming a mode 2 resource allocation, each subsegment can be associated with a different radio resource pool. An exemplary association is shown in the following table, which is similar to the table discussed previously, wherein the radio resource pools are more generally associated with a vehicle location.

[0311] Position Radio resource pool Subsection 1 Offset 1; number of PRBs; PRB-start; PRB-end Subsection 2 Offset 2; number of PRBs; PRB-start; PRB-end Subsection 3 Offset 3; number of PRBs; PRB-start; PRB-end … … Subsection x Offset x; number of PRBs; PRB-start; PRB-end

[0312] From the above table, it is apparent that considering that each segment is divided into subsegments in the same way, which are then equally associated with the same radio resource pool, a vehicle UE is sufficient to determine the subsegment it is located in. Thus, while a vehicle UE can also use the segment (e.g. to possibly further distinguish between different radio resource pools), this is not actually necessary in the case of the above assumption.

[0313] The radio resources of the plurality of radio resource pools to be distributed among the subsegments of each segment can be chosen so as to mitigate interference between them. Correspondingly, when communicating at the same time, vehicle UEs located in adjacent subsegments and thus using the respective resources associated with that subsegment shall not cause interference.

[0314] Based on the above grid of covered segments and subsegments on each road, a vehicle UE has to determine which segment / subsegment it is in, which it then uses itself when autonomously selecting a radio resource from a radio resource pool (i.e. mode 2), or provides to the eNodeB, which in turn can then determine the radio resource based on this (mode 1).

[0315] Correspondingly, the vehicle UEs will start by determining their geographical position, and will then identify the section and / or subsection corresponding to this geographical position. Hence, the vehicle UEs need to know how exactly the road is divided into sections and subsections, e.g. they need to know the size of the sections and the number and size of the individual subsections into which each section is divided. Furthermore, the vehicle UEs can also need to know where the grid, i.e. the sections / subsections, starts with respect to the particular road they are travelling on. This information can be provided, for example, in the form of boundaries given by identifying specific geographical coordinates of the beginning and / or end of the road. Hence, the road should be unambiguously divided into sections and subsections, so that all vehicle UEs and also the eNodeB have the same understanding of where the sections and subsections are located and start and end.

[0316] Furthermore, the vehicle UEs should adapt the grid and the corresponding sections and subsections so that they align with the road even when the road has curves.

[0317] It should also be noted that the vehicle UEs can be connected to the navigation system of the vehicle and can therefore have access to map data that assists the vehicle UEs in determining the boundaries of the road and how the road is divided into sections and / or subsections.

[0318] According to another exemplary implementation, based on the map information available from the navigation system of the vehicle, the vehicle UEs should have at least access / knowledge of the coordinates of the beginning / end of the road, the edges of the road, the number of lanes in each direction, etc. Following this operation, which can apply the following functions to calculate its section / subsection. Next, the UE can use the Decimal Degrees (DD) or DMS values (https: / / en.wikipedia.org / wiki / Decimal_degrees)

[0319] The 'units' for both the length and width of the section / subsection can be signalled in a broadcast message, e.g. 0° 00' 0.036" representing 1.1132m. The network can signal that x 'latitude units' / y 'longitude units' make up one section / subsection, additionally based on the boundary information of the road.

[0320] The above implementation of the first embodiment implicitly assumes that the vehicle UE is in coverage of the eNodeB. However, the vehicle UE can also be outside coverage of the eNodeB and should still be able to perform vehicle communication. Correspondingly, a further implementation of the first embodiment takes this case into account by specifying at vehicle UEs outside coverage that the normal D2D resource allocation method should be used, without additionally taking their vehicle position into account when determining the radio resources. For example, random radio resource selection should be sufficiently reliable, especially considering that in areas where a particular vehicle UE is outside coverage, there should not be a large number of vehicles in the first place, thus reducing the likelihood of a collision, and thus making the benefit from additionally taking the vehicle position into account minimal.

[0321] Second embodiment

[0322] In the following, a second embodiment is presented which addresses the same problem as the first embodiment (i.e. the problem explained at the beginning of the detailed description) to improve the radio resource allocation with respect to vehicle communication. The second embodiment is similar to the first embodiment in many respects and generally will use references to the first embodiment.

[0323] As explained above with respect to the first embodiment, the main feature is that the first embodiment provides an additional, improved resource allocation method which can additionally take the position of a vehicle UE into account. Furthermore, as a further optional improvement of the position-aided resource allocation, the first embodiment allows a vehicle UE to perform sensing on the allocated radio resources and then actually use them to avoid collisions on radio resources used or to be used by another UE.

[0324] According to the second embodiment, the main feature of the additional improved resource allocation method is the additional sensing capability of a vehicle UE, while the feature of the position-aided resource allocation by the vehicle UE remains optional.

[0325] In more detail, the radio resource allocation according to the second embodiment is also based on the radio resource allocation already defined for D2D communication, thus allowing mode 1 and mode 2 resource allocation as explained in the background section. Similar to the first embodiment, the second embodiment additionally distinguishes between two different resource allocations, with the difference that a vehicle UE additionally performs sensing on the determined radio resources and then actually uses them.

[0326] As explained in detail with respect to the first embodiment, the term sensing capability should be understood broadly as the capability of a vehicle UE to determine whether a candidate radio resource is used or will be used by other UEs. Then, if possible, these blocked radio resources should not be used, thus avoiding a corresponding collision with these other UEs. This sensing capability can be applied by a vehicle UE to both mode 1 and mode 2 resource allocation.

[0327] In particular, it is exemplarily assumed that the vehicle UE is configured for mode 2 resource allocation, wherein the UE autonomously selects radio resources from a suitable radio resource pool. Furthermore, the vehicle UE shall perform sensing, such that no radio resources are used or will be used by another UE. As explained in the first embodiment, the vehicle UE can first select a set of candidate radio resources from the suitable radio resource pool and then determine whether these selected candidate radio resources are actually used by another mobile terminal. In case the radio resources are blocked, the vehicle UE shall select other resources from the radio resource pool and shall perform the sensing procedure again to ensure that these radio resources are free for use. On the other hand, the vehicle UE can perform sensing on all radio resources of the radio resource pool before actually selecting a set of candidate radio resources from the radio resource pool, such that those radio resources used or will be used by another mobile terminal are eliminated / discarded. Thus, the vehicle UE will then select a radio resource from the remaining free radio resources of the radio resource pool.

[0328] Further improvements on the sensing procedure are proposed in the following with respect to the scenario that all radio resources of the radio resource pool are used or will be used by another mobile terminal. In case free radio resources are not available, the vehicle UE shall be able to select a radio resource from another radio resource pool, in a similar way already explained with respect to the first embodiment. This other radio resource pool can still be among the many resource pools configured by the network for use for V2X communication. In case there is only one configured resource pool or if the latest configured resource pool also turns out to be completely blocked, then the vehicle UE has to simply wait and try again after a certain specified time duration.

[0329] On the other hand, the second embodiment can also be applied to mode 1 resource allocation, wherein the vehicle UE has to request radio resources from the eNodeB by sending a scheduling request and possibly a buffer status report to the eNodeB. In response, the eNodeB will determine suitable radio resources and will provide a corresponding indication to the vehicle UE of the radio resources to be used. According to the second embodiment, the vehicle UE will determine whether another (vehicle) UE uses or will use the radio resources allocated by the eNodeB and will not use them in case there is blocking, to avoid collisions. Furthermore, the vehicle UE can then request other radio resources from the eNodeB again or can continue to autonomously select radio resources from a suitable radio resource pool (i.e. mode 2), to avoid the delay caused by having to request radio resources from the eNodeB again.

[0330] As explained in detail with respect to the first embodiment, there are two possible ways in which the vehicle UE can determine whether another UE will block the radio resources, and thus, with reference to the corresponding chapter of the first embodiment. In short, the vehicle UE can measure the received signal strength and compare it to a threshold, whereby in case the received signal strength is greater than the threshold it is determined that the radio resources are already in use. Alternatively or additionally, the vehicle UE can monitor the scheduling assignment messages sent by other vehicle UEs, thereby gathering information about which radio resources will be used by other UEs and thus will be blocked from use by the vehicle UE.

[0331] It is especially advantageous to additionally include a sensing procedure for the radio resource assignment in case radio resource collisions are likely to occur. This can be the case when the radio resource pool is relatively small but used by many vehicle UEs (e.g. in case many vehicle UEs are positioned side by side (e.g. in a traffic jam)).

[0332] After having explained in detail the sensing capabilities of the vehicle UEs, the second embodiment shall use the sensing capabilities in a selective way. In a similar way as in the first embodiment, an entity of the mobile communication system (e.g. the eNodeB, the MME or a ProSe related entity in the core network) can take a decision about whether to use the normal D2D resource assignment method or whether to use the improved sensing-aided resource assignment method introduced by the second embodiment. The responsible entity (for ease of explanation, assumed to be the eNodeB) can base its decision on different information. For example, the eNodeB can take into account the topology of a certain area of its cell (e.g. a highway or a city center or a rural area etc.) and the number and speed of vehicles in the certain area. Furthermore, whether to use the sensing-aided resource assignment or not can also depend on the time (e.g. traffic is usually dense while at other times the traffic situation is different peak hours).

[0333] Accordingly, the eNodeB will selectively decide whether to use one or the other resource assignment method, i.e. whether to use or not to use the additional sensing capabilities to avoid collisions. In accordance with this, the vehicle UEs are to be provided with information from which they can infer which resource assignment method is to be used. As already explained with respect to the first embodiment, this can be done in various ways, depending on whether the eNodeB takes the same decision for all vehicle UEs in its cell or not. In the latter case, explicit information (e.g. a flag) can be used which is broadcast in its radio cell or sent in a dedicated message to a certain vehicle UE. Alternatively or additionally, instead of providing explicit instructions to the vehicle UEs, the vehicle UEs can also possibly derive from internal parameters which resource assignment method is to be used. In particular, in order to perform the sensing, certain parameters can have to be provided to the UE (e.g. a threshold for comparing the received signal strength or a periodicity at which the UE shall monitor the SA messages).

[0334] Optionally, the SA message itself can contain information about the period of intended use of the resource (e.g. in the next TTI or control / data period, etc., here referred to as "busy-ness" period). In this aspect, individual candidate SA messages (PSCCH) would be received and decoded and the vehicle mobile terminal can check whether they indicate any further "busy-ness" in the upcoming control / data period. If no individual candidate SA is currently being transmitted, the vehicle UE can assume the control (SA) and corresponding data resource to be "free". The "busy-ness" in the SA message can also indicate a corresponding busy-ness period during which it intends to remain transmitting on the corresponding control / data resource. In the simplest form, it would be a Boolean value indicating the "busy-ness" period as 1 period or some other "fixed" number of periods.

[0335] In any case, according to the various implementations of the second embodiment, each of the vehicle UEs shall know at any time whether to use one or the other of the two resource allocation methods, i.e. whether to additionally apply sensing.

[0336] Furthermore, the second embodiment can also be enhanced by assisting the radio resource allocation with the position of the vehicle UEs, on top of the sensing capability. As explained in detail with respect to the first embodiment, the vehicle UEs can determine their position and use the position in the process of determining the radio resources for communication with other mobile terminals. Correspondingly, certain implementations of the second embodiment combine the sensing capability with the position-assisted resource allocation as explained with respect to the first embodiment. In order to avoid repetition, reference is made to the specific chapters of the first embodiment which deal in detail with how the vehicle UE position can be determined by the UE (as simple geographical coordinates or as a function of a sub-section of a road), how the vehicle UE position can be used when determining the radio resources by mode 1 or mode 2, how the vehicle UE position can be expressed as a function of geographical coordinates or sections and / or sub-sections of a road, how a road can be divided into sections / sub-sections, how the vehicle UE position can be transmitted to the eNodeB for mode 1 resource allocation, etc. of the various different implementations of the first embodiment.

[0337] According to embodiments of the present disclosure, at least the following vehicle mobile terminals and radio base stations are disclosed.

[0338] A vehicle mobile terminal according to the disclosure, for determining a radio resource for communicating at least with a second mobile terminal in a communication system, comprises a processor determining whether to determine a radio resource based on a location of the vehicle mobile terminal, the determination being based on information received from an entity of the communication system, in case the radio resource is to be selected based on the location of the vehicle mobile terminal, the processor further determining the location of the vehicle mobile terminal, and the processor further determining a radio resource for communicating at least with the second mobile terminal based on the determined location of the vehicle mobile terminal.

[0339] A vehicle mobile terminal according to the disclosure, the information received by the vehicle mobile terminal from the entity in the communication system is: • provided in system information, broadcasted by a radio base station in a cell of which the vehicle mobile terminal is located, optionally the information is a flag indicating whether the determination of the radio resource is based on the location of the vehicle mobile terminal, or • information on parameters to be used by the vehicle mobile terminal when determining the location of the vehicle mobile terminal, or when determining the radio resource.

[0340] A vehicle mobile terminal according to the disclosure, the processor determines the location of the vehicle mobile terminal by: determining geographical coordinates of the vehicle mobile terminal, and / or by identifying a segment of a road on which the vehicle mobile terminal is located.

[0341] A vehicle mobile terminal according to the disclosure, identifying a segment of a road on which the vehicle mobile terminal is located comprises: • determining geographical coordinates of the vehicle mobile terminal, and • determining the segment of the road based on an association between the determined geographical coordinates of the vehicle mobile terminal and a plurality of segments in which a road is divided.

[0342] A vehicle mobile terminal according to the disclosure, determining the radio resource comprises selecting, by the vehicle mobile terminal, a radio resource from among radio resources defined in a radio resource pool associated with the determined location of the vehicle mobile terminal.

[0343] A vehicle mobile terminal according to the disclosure, the vehicle mobile terminal is configured with a plurality of radio resource pools, each of which is associated with a different location in which the vehicle mobile terminal can be located, optionally the configuration of the radio resource pools is transmitted to the vehicle mobile terminal as system information or within a message dedicated to the vehicle mobile terminal, optionally the plurality of radio resource pools is configured in the vehicle mobile terminal by providing explicit information on the radio resource pools and the individual radio resources in each radio resource pool, or based on rules defining how radio resources are divided into the plurality of radio resource pools.

[0344] According to the vehicle mobile terminal of the present disclosure, determining the radio resources comprises: requesting radio resources from a radio base station controlling a cell in which the vehicle mobile terminal is located, transmitting information on the determined position of the vehicle mobile terminal to the radio base station, optionally the information on the determined position being geographical coordinates or an identifier of a segment of a road in which the vehicle mobile terminal is located, and receiving an indication of radio resources to be used for the communication with at least the second mobile terminal from the radio base station.

[0345] According to the vehicle mobile terminal of the present disclosure, the processor further determines, when determining the radio resources, whether potential radio resources are used or will be used by another mobile terminal and, in case the potential radio resources are used or will be used by another mobile terminal, the processor does not determine the radio resources but determines different radio resources.

[0346] According to the vehicle mobile terminal of the present disclosure, determining the radio resources comprises: selecting, by the vehicle mobile terminal, radio resources from among radio resources defined in a radio resource pool associated with the determined position of the vehicle mobile terminal, and in case potential radio resources not used or not to be used by another mobile terminal are not available in the associated radio resource pool, the processor selects radio resources from another radio resource pool associated with another position than the position of the vehicle mobile terminal, optionally the other position being next to the position of the vehicle mobile terminal.

[0347] According to the vehicle mobile terminal of the present disclosure, the position of the vehicle mobile terminal is based on a grid overlaying a road in which the vehicle mobile terminal is located, a portion of the road in which the vehicle mobile terminal is located being divided into a plurality of segments, optionally each of the plurality of segments covering all lanes of the road, all of the plurality of segments being further divided into a same number of non-overlapping sub-segments, optionally each of the plurality of sub-segments covering at least one of the lanes of the road, and optionally each of the plurality of sub-segments being associated with a radio resource pool.

[0348] According to the vehicle mobile terminal of the present disclosure, the radio resources associated with the plurality of sub-segments are orthogonal to each other, and the segments and the sub-segments are such that the radio resources associated with a sub-segment mitigate interference between adjacent segments, and optionally the division of the plurality of segments into sub-segments assumes one vehicle mobile terminal in each sub-segment or more than one vehicle mobile terminal in each sub-segment.

[0349] According to the vehicle mobile terminal of the present disclosure, determining the position of the vehicle mobile terminal comprises determining an identifier of the section and / or an identifier of the sub-section in which the vehicle mobile terminal is located, and optionally further comprising transmitting the determined position of the vehicle mobile terminal to the radio base station, which comprises transmitting the identifier of the section and / or the identifier of the sub-section.

[0350] According to the vehicle mobile terminal of the present disclosure, the processor further determines whether the vehicle mobile terminal is in coverage or out of coverage of a radio base station, and in case of being out of coverage, the processor determines that the radio resources are not to be selected based on the position of the vehicle mobile terminal.

[0351] According to the vehicle mobile terminal of the present disclosure, the entity of the communication system determines whether radio resources to be used by the vehicle mobile terminal for communicating at least with the second mobile terminal are to be determined based on the position of the vehicle mobile terminal, and information about the result of the determination is provided by the entity of the communication system to the vehicle mobile terminal, optionally the entity of the communication system is a radio control entity controlling the cell in which the vehicle mobile terminal is located or is an entity controlling the network.

[0352] According to the radio base station in a communication system of the present disclosure, for assisting a vehicle mobile terminal in determining radio resources for communicating at least with a second mobile terminal in the communication system, comprising: a processor determining whether radio resources are to be determined based on a position of the vehicle mobile terminal, the determination being based at least on information about vehicle mobile terminals in a cell of the radio base station, a transmitting unit transmitting information to the vehicle mobile terminal based on which the vehicle mobile terminal determines whether radio resources are to be determined based on the position of the vehicle mobile terminal.

[0353] According to the radio base station of the present disclosure, the information is provided to the vehicle mobile terminal in the following ways: • in system information, broadcasted by the radio base station in its cell, optionally the information is a flag indicating whether the determination of the radio resources is based on the position of the vehicle mobile terminal, or, as a parameter to be used by the vehicle mobile terminal when determining the position of the vehicle mobile terminal, or when determining the radio resources.

[0354] According to the radio base station of the present disclosure, the transmitting unit further transmits information on a plurality of radio resource pools to the vehicle mobile terminal, each of the plurality of radio resource pools being associated with a different location at which the vehicle mobile terminal can be located, such that the vehicle mobile terminal can select a radio resource from among radio resources defined in the radio resource pool associated with the location of the vehicle mobile terminal, optionally, the information on a plurality of radio resource pools is transmitted by the radio base station as system information or within a message dedicated to the vehicle mobile terminal.

[0355] According to the radio base station of the present disclosure, the receiving unit receives from the vehicle mobile terminal a request for a radio resource to be used by the vehicle mobile terminal for communication with another mobile terminal and receives information on the location of the vehicle mobile terminal, optionally, the information on the location of the vehicle mobile terminal is a geographical coordinate or an identifier of a segment of a road at which the vehicle mobile terminal is located, the processor further determines a radio resource to be used by the vehicle mobile terminal for communication with another mobile terminal, and the transmitting unit further transmits information on the determined radio resource to the vehicle mobile terminal.

[0356] According to the radio base station of the present disclosure, the location of the vehicle mobile terminal is based on a grid overlaying a road at which the vehicle mobile terminal is located, a portion of the road at which the vehicle mobile terminal is located being divided into a plurality of segments, optionally, each of the plurality of segments covers all lanes of the road, all of the plurality of segments being further divided into a same number of a plurality of non-overlapping sub-segments, optionally, each of the plurality of sub-segments covers at least one of the lanes of the road, and optionally, each of the plurality of sub-segments is associated with a radio resource pool, the transmitting unit further transmits information on the grid, the segments and sub-segments to the vehicle mobile terminal, such that the vehicle mobile terminal can use the information to determine the location of the vehicle mobile terminal as a segment and / or a sub-segment, optionally, the receiving unit of the radio base station receives from the vehicle mobile terminal an identifier of the segment and / or an identifier of the sub-segment as the information on the location of the vehicle mobile terminal.

[0357] Hardware and software implementations of the present disclosure

[0358] Other exemplary embodiments relate to implementations of the above-described various embodiments using hardware, software, or software in conjunction with hardware. Herein, a user terminal (mobile terminal) is provided. The user terminal is adapted to perform the methods described herein, including the corresponding entities (e.g. receiving unit, transmitting unit, processor) for appropriately participating in the methods.

[0359] It should be further understood that individual embodiments can be implemented or performed using a computing device (processor). The computing device or processor can be, for example, a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, etc. Combinations of these can also be used. In particular, each function block used in the descriptions of each of the above described embodiments can be implemented by an LSI as an integrated circuit. These can be formed individually, or one chip can be formed so as to include a part or all of the function blocks. They can include a data input and output coupled thereto. Depending on the degree of integration, the LSI here can be referred to as an IC, a system LSI, a super LSI, or a ultra LSI. However, the technique of implementing an integrated circuit is not limited to the LSI and can be realized by using a dedicated circuit or a general purpose processor. Further, a FPGA (Field Programmable Gate Array) that can be programmed after manufacturing the LSI, or a reconfigurable processor where the connections and the settings of circuit cells disposed inside the LSI can be reconfigured can be used.

[0360] Further, the individual embodiments can also be implemented by a software module executed by a processor or directly in hardware. Also, a combination of software modules and a hardware implementation can be possible. The software module can be stored in any kind of computer readable storage medium (for example, RAM, EPROM, EEPROM, flash memory, registers, hard disk, CD-ROM, DVD, etc.). It should also be noted that the individual features of the different embodiments can individually or in arbitrary combination be a subject matter of another embodiment.

[0361] Those skilled in the art will understand that numerous modifications and / or alterations of the present disclosure can be devised, as shown in the various embodiments. Therefore, the embodiments of the present application are to be considered as illustrative only and the full scope of the disclosure to be outlined by the appended claims and equivalents thereof.

Claims

1. A communication device, comprising: receiving circuitry to receive parameter information in a cell in which the communication device is located; and control circuitry coupled to the receiving circuitry to determine, based on the parameter information, whether to use radio resources corresponding to a geographical location of the communication device, wherein, in response to the parameter information indicating to use radio resources corresponding to the geographical location of the communication device, the control circuitry is to: determine the geographical location of the communication device, identify, based on the parameter information, a location sub-section in which the communication device is geographically located, wherein the parameter information comprises a first parameter indicating a length of the location sub-section, a second parameter indicating a width of the location sub-section, a third parameter indicating a number of location sub-sections into which a location section is divided for a longitude length, and a fourth parameter indicating a number of location sub-sections into which the location section is divided for a latitude width, wherein the first to fourth parameters are dynamically signaled from a radio base station, determine, based on the first to fourth parameters, the length and width of the location sub-section, and the number of location sub-sections into which the location section is divided for longitude and latitude, radio resources corresponding to the identified location sub-section in which the communication device is geographically located, and perform communication using the determined radio resources.

2. The communication device of claim 1, wherein, The control circuitry is to determine to use radio resources in a radio resource pool associated with the identified location sub-section.

3. The communication device of claim 1, configured with a plurality of radio resource pools associated with different geographical locations in which the communication device can be located, wherein the configuration of the radio resource pools is transmitted to the communication device, and the configuration of the radio resource pools is defined by explicit information about radio resource pools and respective radio resources in each radio resource pool, or by rules defining how radio resources are divided into the radio resource pools.

4. The communication device of claim 1, wherein, The control circuitry is to determine to use radio resources by: requesting radio resources from the radio base station, transmitting, to the radio base station, information about the determined geographical location of the communication device, wherein the information about the determined geographical location is geographical coordinates or an identifier of a location section in which the communication device is geographically located, and receiving, from the radio base station, an indication of radio resources to use.

5. The communication device of claim 1, wherein, The control circuitry is to: determine, based on signaling from a radio base station or sensing by the communication device, whether potential radio resources are being or will be used by another communication device, and in response to determining that the potential radio resources are being or will be used by the other communication device, determine not to use the potential radio resources and to use different radio resources.

6. The communication device of claim 5, wherein, The control circuitry is to determine to use radio resources by: determining radio resources in a radio resource pool associated with the geographical location of the communication device, and in response to determining that the potential radio resources in the radio resource pool are being or will be used by the other communication device, determining to use radio resources in another radio resource pool associated with another geographical location different from the geographical location of the communication device, wherein the other geographical location is adjacent to the geographical location of the communication device.

7. The communication device of claim 1, wherein, the geographical location of the communication device is defined by a grid covering a road on which the communication device is located, the road is divided into a plurality of location segments, and each of the plurality of location segments covers all lanes in the road, wherein all of the plurality of location segments are subdivided into a same number of non-overlapping location sub-segments, and each location sub-segment covers at least one lane in the road, and wherein each location sub-segment is associated with a radio resource pool.

8. The communication device of claim 7, wherein, the radio resources associated with the location sub-segments, respectively, are orthogonal to each other to mitigate interference.

9. The communication device of claim 1, wherein, the control circuit determines the geographical location of the communication device by determining an identifier of a location segment and / or an identifier of a location sub-segment in which the communication device is geographically located.

10. The communication device of claim 1, wherein, the control circuit: determines whether the communication device is within or outside a coverage range of the radio base station, and in response to determining that the communication device is outside the coverage range, determines not to use radio resources corresponding to the geographical location of the communication device.

11. A method performed by a communication device, the method comprising: receiving parameter information in a cell in which the communication device is located; based on the parameter information, determining whether to use radio resources corresponding to a geographical location of the communication device; in response to the parameter information indicating to use radio resources corresponding to the geographical location of the communication device, determining the geographical location of the communication device, identifying a location sub-segment in which the communication device is geographically located based on the parameter information, wherein the parameter information comprises a first parameter indicating a length of the location sub-segment, a second parameter indicating a width of the location sub-segment, a third parameter indicating a number of location sub-segments into which a location segment is divided for a longitude length, and a fourth parameter indicating a number of location sub-segments into which the location segment is divided for a latitude width, wherein the first to fourth parameters are dynamically signaled from a radio base station, determining radio resources corresponding to the identified location sub-segment in which the communication device is geographically located based on the first to fourth parameters, the length and width of the location sub-segment, and the number of location sub-segments into which the location segment is divided for longitude and latitude, and performing communication using the determined radio resources.

12. An integrated circuit for controlling a process of a communication device, the process comprising: receiving parameter information in a cell in which the communication device is located; based on the parameter information, determining whether to use radio resources corresponding to a geographical location of the communication device; in response to the parameter information indicating to use radio resources corresponding to the geographical location of the communication device, determining the geographical location of the communication device, identifying a position sub-section in which the communication device is geographically located based on the parameter information, wherein the parameter information comprises a first parameter indicating a length of the position sub-section, a second parameter indicating a width of the position sub-section, a third parameter indicating a number of position sub-sections into which a position section is divided for a longitude length, and a fourth parameter indicating a number of position sub-sections into which the position section is divided for a latitude width, wherein the first to fourth parameters are dynamically signaled from a radio base station, determining dynamically radio resources corresponding to the identified position sub-section in which the communication device is geographically located based on the first to fourth parameters, the length and width of the position sub-section, and the number of position sub-sections into which the position section is divided for longitude and latitude, and performing communication using the determined radio resources.

13. An integrated circuit for controlling processing of a radio base station in a communication system to assist a communication device in determining radio resources for vehicle communication with at least a second communication device in the communication system, wherein the processing comprises: determining whether radio resources are to be determined based on a position of the communication device, wherein the determination is based at least on information about the communication device in a cell of the radio base station, sending information to the communication device based on which the communication device determines whether radio resources are to be determined based on a position of the communication device.

Images