RU2719633C1 - Improved semipermanent resource allocation for v2v traffic - Google Patents

Abstract

FIELD: computer equipment.SUBSTANCE: invention relates to computer engineering. Vehicle mobile device comprises: transmitter, which, during operation, transmits information on D2D data transmissions with different possible transmission intervals and / or different possible message sizes to a radio base station responsible for allocating radio resources to the mobile device of the vehicle; receiver, which during operation receives from a radio base station a plurality of configurations of semipermanent radio resources, configured by a radio base station based on the received information on D2D data transmissions.EFFECT: technical result is higher efficiency of resource allocation.19 cl, 15 dwg

Description

FIELD OF TECHNOLOGY TO WHICH THE PRESENT DISCLOSURE relates

The present disclosure relates to improved semi-permanent resource allocation between a mobile terminal and a radio base station. The present disclosure represents a corresponding mobile terminal (vehicle) and a radio base station.

BACKGROUND OF THE INVENTION

Long Term Evolution (LTE)

Third Generation (3G) mobile systems based on WCDMA radio access technology are deployed on a large scale worldwide. The first step in improving or developing this technology entails the introduction of High Speed Downlink Packet Access (HSDPA) and an improved uplink, also referred to as High Speed Packet Access Uplink (HSUPA), introducing highly competitive radio access technology.

In order to be prepared for further growing user needs and to be competitive with new radio access technologies, 3GPP has introduced a new mobile communication system called Long-Term Development (LTE). LTE is designed to meet carrier needs for high-speed data and multimedia transport, as well as high-capacity voice support for the next decade. The ability to provide high data rates is a key metric for LTE.

The Technical Description of the Long Term Evolution (WI) Work Question (WI), referred to as UMTS Evolved Terrestrial Radio Access (UTRA) and UMTS Terrestrial Radio Access Network (UTRAN), is completed as Release 8 (LTE Rel. 8). The LTE system is an efficient packet-based radio access and radio access network that provides full IP-based functionality with low latency and low cost. In LTE, scalable multiple transmission bandwidths are indicated, such as 1.4, 3.0, 5.0, 10.0, 15.0, and 20 MHz, in order to achieve flexible system deployment using a given spectrum. In the downlink, Orthogonal Frequency Division Multiplexing (OFDM) -based radio access was used due to its inherent immunity to multipath interference (MPI) due to its low symbol rate, the use of cyclic prefix (CP) and its compatibility with different bandwidth layouts transmission. Based on frequency division multiple access and single carrier (SC-FDMA) radio access was used in the uplink because providing a wide coverage area was a priority over improvement in peak data rate, considering the limited transmit power of the user equipment (UE). Many key packet radio access techniques are used, including a multi-input multiple output (MIMO) channel transmission technique and a highly efficient control signaling structure is achieved in LTE Rel. 8/9.

LTE Architecture

The general LTE architecture is shown in FIG. 1. The E-UTRAN consists of an eNodeB, providing completion of the E-UTRA user plane protocol (PDCP / RLC / MAC / PHY) and control plane (RRC) in the direction of the user equipment (UE). The eNodeB (eNB) hosts the Physical (PHY), Media Access Control (MAC), Radio Link Control (RLC) and Packet Data Management Protocol (PDCP) layers, which include compression and encryption functionality for the user plane header. It also offers Radio Resource Management (RRC) functionality appropriate to the control plane. It performs many functions, including radio resource administration, admission control, scheduling, negotiated uplink Quality of Service (QoS), broadcast cell information, encryption / decryption of user and control plane data, compression / decompression of user plane packet headers downstream / upstream communication lines. eNodeBs are interconnected with each other via an X2 interface.

The eNodeBs are also connected via an S1 interface to an EPC (Advanced Packet Core), in particular, an MME (Mobility Management Object) via an S1-MME and to a Serving Gateway (SGW) via an S1-U. The S1 interface supports the many-with-many relationship between MME / Serving Gateways and eNodeB. The SGW routes and redirects user data packets, while also acting as a mobility binding for the user plane during inter-eNodeB handoffs and as a mobility binding between LTE and other 3GPP technologies (terminating the S4 interface and relaying traffic between 2G / 3G and PDN GW). With respect to the standby state of user equipments, the SGW terminates the downlink data path and initiates a paging call when the downlink data arrives for the user equipments. It administers and stores user equipment contexts, for example, IP media service settings, or network internal routing information. It also replicates user traffic in the event of a legitimate interception.

MME is the key management node for the LTE access network. He is responsible for monitoring the standby equipment of the user and the paging procedure, including retransmissions. He is involved in the process of activating / deactivating the media and is also responsible for selecting SGW for the user equipment at the initial attachment and at the time of the intra-LTE handover, which involves the movement of the Core Network (CN) node. He is responsible for user authentication (through interaction with HSS). The Non-Access Layer Signaling ends at the MME, and it is also responsible for generating and distributing temporary credentials for user equipments. It checks the authorization of the user equipment in order to gain a foothold in the Public Service Terrestrial Mobile Network (PLMN) of the service provider and implements restrictions on the roaming of the user equipment. The MME is a network termination point for encryption / integrity protection for NAS signaling and administers a security key. Legitimate signaling interception is also supported through the MME. The MME also provides a management plane function for mobility between LTE and 2G / 3G access networks, with an S3 interface terminating in the MME from SGSN. The MME also completes the S6a interface to home HSS for roaming user equipments.

Component Carrier Structure in LTE

поднесущих и

OFDM-символов.

является числом блоков ресурсов в полосе пропускания. Количество

зависит от полосы пропускания передачи нисходящей линии связи, сконфигурированной в соте и должно удовлетворять

, где

=6 и

=110 являются соответственно наименьшими и наибольшими полосами пропускания нисходящей линии связи, поддерживаемыми текущей версией технического описания.

является числом поднесущих в одном блоке ресурсов. Применительно к структуре субкадра нормального циклического префикса

=12 и

=7.The downlink component carrier of the 3GPP LTE system is subdivided into so-called subframes in the time-frequency domain. In 3GPP LTE, each subframe is divided into two downlink slots, as shown in FIG. 2, wherein the first downlink slot comprises a control channel region (PDCCH region) in the first OFDM symbols. Each subframe consists of a predetermined number of OFDM symbols in the time domain (12 or 14 OFDM symbols in 3GPP LTE (Revision 8)), with each OFDM symbol covering the entire bandwidth of the component carrier. OFDM symbols, therefore, each consists of a number of modulation symbols transmitted on the respective subcarriers. In LTE, the transmitted signal in each slot is described by a grid of resources from

subcarriers and

OFDM characters.

is the number of resource blocks in the bandwidth. amount

Depends on the downlink transmission bandwidth configured in the cell and must satisfy

where

= 6 and

= 110 are the smallest and largest downlink bandwidths supported by the current version of the datasheet.

is the number of subcarriers in one resource block. In relation to the structure of the subframe normal cyclic prefix

= 12 and

= 7.

Assuming a multi-carrier communication system, for example using OFDM, such as used in 3GPP Long Term Evolution (LTE), the smallest unit of resources that can be assigned by the scheduler is one “resource block”. A physical resource block (PRB) is defined as consecutive OFDM symbols in the time domain (eg, 7 OFDM symbols) and consecutive subcarriers in the frequency domain, as exemplified in FIG. 2 (e.g., 12 subcarriers for a component carrier). In 3GPP LTE (Revision 8), the physical resource block thus consists of resource elements corresponding to one slot in the time domain and 180 kHz in the frequency domain (for additional details on the downlink resource grid, see, for example, 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, available at http://www.3gpp.org and incorporated herein description by reference).

One subframe consists of two slots, so that there are 14 OFDM symbols in the subframe when the so-called “normal” CP (cyclic prefix) is used, and 12 OFDM symbols in the subframe when the so-called “extended” CP is used. For terminology purposes, in the following, time-frequency resources equivalent to the same subcarriers spanning a full subframe are referred to as a “resource block pair”, or equivalently, “RB pair” or “PRB pair”.

The term "component carrier" refers to the combination of several resource blocks in the frequency domain. In a future edition of LTE, the term “component carrier” is no longer used; instead, the terminology is changed to “cell”, which refers to a combination of downlink resources and optionally uplink. The link between the frequency of the carrier resources of the downlink and the frequency of the carrier resources of the uplink is indicated in the system information transmitted over the resources of the downlink.

Similar assumptions for the component carrier structure will also apply to later revisions.

Carrier Aggregation in LTE-A for Higher Bandwidth

The decision on the frequency spectrum for Advanced-IMT was made at the 2007 World Radiocommunication Conference (WRC-07). Although a decision has been made on the entire frequency spectrum for Advanced-IMT, the actual available frequency bandwidth is different for each region or country. Following the decision on the accessible structure of the frequency spectrum, however, the 3rd Generation Partnership Project (3GPP) began standardizing the radio interface. At 3GPP TSG RAN # 39, a description of the Subject of Research for “Further Advancements for EUTRA (LTE-Advanced)” was agreed. The subject of the study covers the technological components that should be considered for the development of E-UTRA, for example, to satisfy the requirements of Advanced-IMT.

The bandwidth that the Advanced-LTE system is capable of providing is 100 MHz, while the LTE system can only provide 20 MHz. At present, the lack of a radio spectrum has become a bottleneck in the development of wireless networks, and as a result, it is difficult to find a spectrum band that is wide enough for the Advanced-LTE system. Of course, it is urgent to find a way to get a wider band of the radio spectrum, with the possible answer being the carrier aggregation functionality.

In carrier aggregation, two or more component carriers are aggregated in order to provide wider transmission bandwidths up to 100 MHz. Aggregate several cells in the LTE system into one wider channel in the Advanced LTE system, which is wide enough for 10 MHz even though these cells in LTE can be in different frequency bands.

All component carriers can be configured to be compatible with LTE Rel. 8/9, at least when the bandwidth of the component carrier does not exceed the supported bandwidth of the LTE Rel cell. 8/9. Not all constituent carriers aggregated by user equipment may necessarily be compatible with Rel. 8/9. Existing mechanisms (such as a ban) can be used to prevent Rel-8/9 user equipment from being locked into a component carrier.

The user equipment can simultaneously receive or transmit over one or more component carriers (corresponding to several serving cells) depending on its capabilities. User equipment LTE-A Rel. 10 with reception and / or transmission capabilities in relation to carrier aggregation can simultaneously receive and / or transmit over several serving cells, while LTE Rel user equipment. 8/9 can only receive and transmit on one serving cell, provided that the structure of the component carrier follows the technical description Rel. 8/9.

Carrier aggregation is supported for both adjacent and non-adjacent component carriers, with each carrier component limited to a maximum of 110 Resource Blocks in the frequency domain (using 3GPP LTE numerology (Rev. 8/9).

You can configure a 3GPP LTE-A (Revision 10) -compatible user equipment to aggregate a different number of component carriers originating from the same eNodeB (base station) and possibly different bandwidths in the uplink and downlink. The number of downlink component carriers that can be configured depends on the possibility of downlink aggregation at the UE. Conversely, the number of uplink component carriers that can be configured depends on the uplink aggregation capability of the UE. At the moment, it may not be possible to configure a mobile terminal with a larger number of uplink component carriers than the downlink component carriers. In a typical TDD deployment, the number of component carriers and the bandwidth of each carrier component in the uplink and downlink are the same. Component carriers originating from the same eNodeB are not required to provide the same coverage.

The interval between the center frequencies of adjacent aggregated carrier components must be a multiple of 300 kHz. This is in order to be compatible with the 100 kHz frequency raster of 3GPP LTE (Revision 8/9) and at the same time maintain the orthogonality of the subcarriers with a 15 kHz interval. Depending on the aggregation scenario, the n × 300 kHz spacing may be facilitated by inserting a low number of unused subcarriers between adjacent component carriers.

The essence of the aggregation of several carriers is disclosed only up to the MAC layer. For both the uplink and the downlink, there is one HARQ entity required in the MAC for each aggregated carrier component. There is (in the absence of SU-MIMO for the uplink) no more than one transport block per component carrier. The transport block and its potential HARQ retransmissions must be displayed on the same carrier component.

When carrier aggregation is configured, the mobile terminal has only one RRC connection to the network. When creating / re-creating an RRC connection, one cell provides secure input (one ECGI, one PCI and one ARFCN) and non-access layer mobility information (for example, TAI) similar to LTE Rel. 8/9. After creating / re-creating an RRC connection, a component carrier corresponding to that cell is referred to as a Downlink Primary Cell (PCell). There is always one and only one downlink PCell (DL PCell) and one uplink PCell (UL PCell) configured for a user equipment in a connected state. As part of a configured set of component carriers, other cells are referred to as Secondary Cells (SCell); with SCell carriers that are the Secondary Downlink Component Carrier (DL SCC) and the Secondary Downlink Component Carrier (UL SCC). A maximum of five serving cells, including PCell, can be configured for one UE.

Layer / MAC Object, RRC Layer, Physical Layer

The protocol plane of the user plane / control plane of the LTE layer 2 contains four sublayers, RRC, PDCP, RLC and MAC. The Media Access Control (MAC) layer is the lowest sublayer in the Layer 2 architecture at the LTE radio protocol stack and is defined using, for example, the technical standard 3GPP TS 36.321, current version 13.0.0. The connection to the physical layer below is via transport channels, and the connection to the RLC layer above is via logical channels. As a result, the MAC layer multiplexes and demultiplexes between logical channels and transport channels: the MAC layer on the transmitting side creates MAC PDUs, known as transport blocks, from the MAC SDUs received through the logical channels, and the MAC layer on the receiving side restores the MAC SDU from the MAC PDU received through transport channels.

The MAC layer provides a data transfer service (see subclauses 5.4 and 5.3 of TS 36.321, incorporated herein by reference) for the RLC layer through logical channels, which are either logical control channels that carry control data (eg, RRC signaling) or logical channels traffic that carry user plane data. On the other hand, data from the MAC layer is exchanged with the physical layer through transport channels, which are classified as a downlink or an uplink. Data is multiplexed into transport channels, depending on how they are transmitted through the air.

The physical layer is responsible for the actual transmission of data and control information through the radio interface, i.e. The Physical Layer carries all the information from the MAC transport channels through the radio interface on the transmission 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 for handover purposes) and other measures (within the LTE system and between systems) for RRC layer. The physical layer performs transfers based on transmission parameters, such as a modulation scheme, a coding rate (i.e., a modulation and coding scheme, MCS), the number of physical resource blocks, etc. More information on the functioning of the physical layer can be found in the technical standard 3GPP 16.213, current version 13.0.0, incorporated herein by reference.

The Radiocommunication Resource Management (RRC) layer controls the communication between the UE and the eNB on the radio interface and the mobility of the UE moving over several cells. The RRC protocol also supports NAS information transfer. For the UE in RRC_IDLE, RRC supports notification from the network of incoming calls. RRC connection management covers all procedures related to creating, modifying, and releasing an RRC connection, including paging, measurement configuration and reporting, radio resource configuration, initial security activation, and creation of Signaling Radio Carrier (SRB) and radio media carrying user data (Data Radio Communication Media, DRB).

The radio link control sublayer (RLC) contains mainly ARQ functionality and supports data segmentation and articulation, i.e. the RLC layer organizes the frame from the RLC SDUs to fit them at the size indicated by the MAC layer. The last two minimize protocol overhead regardless of the data rate. The RLC layer is connected to the MAC layer through logical channels. Each logical channel transports different types of traffic. The layer above the RLC layer is usually a PDCP layer, but in some cases it is an RRC layer, i.e. RRC messages are sent over the logical channels BCCH (Broadcast Control Channel), PCCH (Control Channel Paging Call) and CCCH (Common Control Channel), which do not require security and, therefore, go directly to the RLC layer, bypassing the PDCP layer. Key services and functions of the RLC sublayer include:

- Transfer of top layer PDUs supporting AM, UM or TM data transfer;

- Error Correction via ARQ;

- Segmentation according to TB size;

- Repeated segmentation if necessary (for example, when the radio quality, i.e. the supported TB size, changes)

- The articulation of the SDU for the same radio carrier is FFS;

- In-sequence delivery of the top layer of the PDU;

- Detection of Duplicates;

- Protocol error detection and recovery;

- Ignoring SDU;

- reset

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

Uplink Access Scheme for LTE

For uplink transmission, power efficient transmission of a user terminal is necessary to maximize coverage. Single carrier transmission combined with dynamic bandwidth allocation FDMA has been selected as an advanced UTRA uplink transmission scheme. The main reason for preferring single-carrier transmission is a 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 preset peak power of the terminal). During each time interval, the eNodeB assigns users a unique time / frequency resource for transmitting user data, thereby guaranteeing orthogonality within the cell. Orthogonal access on the uplink promises increased spectral efficiency by eliminating interference within the cell. Multipath interference is processed at the base station (eNodeB) using the insertion of a cyclic prefix into the transmitted signal.

The main physical resource used for data transmission consists of a frequency resource of size BWgrant for one time interval, for example, a subframe in which bits of encoded information are displayed. It should be noted that a subframe, also referred to as a transmission time interval (TTI), is the smallest time interval for transmitting user data. However, it is possible to assign a frequency resource BWgrant over a longer period of time than one TTI to a user by articulating subframes.

Alarm Control Layer 1 / Layer 2

In order to inform planned users of their distribution status, transport format, and other transmission related information (e.g., HARQ information, transmit power control (TPC) commands), the L1 / L2 control signaling is transmitted in a downlink along with the data. The L1 / L2 control signaling is multiplexed with downlink data in a subframe, assuming that the user distribution may be changed from subframe to subframe. It should be noted that user allocation can also be performed based on TTI (Transmission Time Interval), where the TTI length can be a multiple of subframes. The TTI length may be fixed in the service area for all users, may be different for different users, or may even be dynamic for each user. In general, the L1 / L2 control signaling should only be transmitted once per TTI. Without loss of versatility, the following assumes that the TTI is equivalent to one subframe.

L1 / L2 control signaling is transmitted over the Physical Downlink Control Channel (PDCCH). The PDCCH carries the message as Downlink Control Information (DCI), which in most cases includes resource assignments and other control information for a mobile terminal or groups of UEs. Multiple PDCCHs may be transmitted in one subframe.

In general, information sent in the L1 / L2 control signaling to assign uplink or downlink radio resources (in particular LTE (-A) Revision 10) can be classified into the following elements:

- User identification information indicating the user who is being distributed. This typically includes a checksum by masking the CRC with user credentials;

- Resource allocation information indicating resources (e.g., Resource Blocks, RB) over which the user is allocated. Alternatively, this information is called resource block assignment (RBA). Note that the number of RBs over which the user is distributed can be dynamic;

- The carrier indicator, which is used if the control channel transmitted on the first carrier designates resources that affect the second carrier, i.e. resources on the second carrier or resources related to the second carrier; (inter-carrier planning);

- The modulation and coding scheme, which determines the modulation scheme used and the coding rate;

- HARQ information, such as new data indicator (NDI) and / or redundancy (RV) version, which, in particular, is useful in retransmissions of data packets or parts thereof;

- Power control commands to adjust the transmit power of the assigned uplink data or transmit control information;

- Information of the reference signal, such as the applied cyclic shift and / or the index of the orthogonal coverage code, which should be used to transmit or receive reference signals related to the purpose;

- An uplink or downlink assignment index, which is used to identify the order of assignments, which is particularly useful in TDD systems;

- Hopping information, for example, an indication of whether to apply and how the hopping of resources in order to increase frequency diversity;

- A CSI request that is used to initiate the transmission of channel status information in the assigned resource; and

- Multi-cluster information, which is a flag used to indicate and control whether transmission occurs in a single cluster (adjacent RB set) or in multiple clusters (at least two non-adjacent sets of adjacent RBs). Multi-cluster allocation was introduced by 3GPP LTE- (A) Edition 10.

It should be noted that the above listing is not exhaustive, and the presence of all of the mentioned information elements in each transmission of the PDCCH is not required depending on the DCI format that is used.

The downlink control information takes place in several formats that differ in overall size and also in the information contained in their fields, as mentioned 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 v13.0.0, available at http: // www. 3gpp.org and is incorporated herein by reference). For example, the following DCI Formats can be used to carry resource resolution for an uplink.

- Format 0: DCI Format 0 is used to transmit resource permissions for the PUSCH using port transmissions of a single antenna in mode 1 or 2 of the uplink transmission.

- Format 4: DCI format 4 is used for PUSCH scheduling using closed-loop spatial multiplexing in uplink transmission mode 2.

The 3GPP TS 36.212 Technical Standard, current version 13.0.0, defines in Subclause 5.4.3, incorporated herein by reference, control information for a sidelink.

Semi-Permanent Planning (SPS)

In the downlink and uplink, the scheduling eNodeB dynamically allocates resources to the user equipments at each transmission time interval through the L1 / L2 control channel (s) (PDCCH), where addressing to the user equipments is via their special C-RNTI. As already mentioned before, the CRC of a PDCCH is masked using the C-RNTI of the addressable user equipment (the so-called dynamic PDCCH). Only user equipment with a matching C-RNTI can decode PDCCH content correctly, i.e. CRC verification is positive. This type of PDCCH signaling is also referred to as dynamic (scheduling) resolution. The user equipment monitors at each transmission time interval the L1 / L2 control channel (s) with respect to dynamic resolution in order to find a possible distribution (downlink or uplink) that is assigned to it.

In addition, the E-UTRAN may allocate uplink / downlink resources for the original HARQ transmissions in a continuous manner. When required, transmissions are explicitly signaled through the L1 / L2 control channel (s). Since retransmissions are scheduled dynamically, this type of work is called semi-persistent scheduling (SPS), i.e. resources are allocated to user equipment on a semi-permanent basis (semi-permanent resource allocation). The advantage is that PDCCH resources are saved for the original HARQ transmissions. Semi-persistent planning can be used in PCell in Release 10, but not in SCell.

One example for a service that can be scheduled using semi-persistent scheduling is Voice over IP (VoIP). Every 20ms, a VoIP packet is generated in the codec during the speech stream. Because of this, the eNodeB can allocate uplink or downlink resources continuously every 20ms, which can then be used to transmit Voice packets over IP. In general, semi-persistent scheduling provides an advantage for services with predictable traffic behavior, i.e. constant bit rate, pact arrival time is periodic.

The user equipment also monitors the PDCCH in a subframe where resources have been allocated for the original transmission continuously. Dynamic (planning) resolution, i.e. PDCCH with C-RNTI-masked CRC, can replace the semi-permanent resource allocation. In the case where the user equipment finds its C-RNTI on the L1 / L2 control channel (s) in subframes where the user equipment has a semi-permanent assigned resource, this allocation of the L1 / L2 control channel replaces the constant resource allocation for that transmission time interval, and the equipment user follows dynamic resolution. When the user equipment does not find dynamic resolution, it will transmit / receive in accordance with the semi-permanent allocation of resources.

Semi-persistent scheduling configuration is performed by RRC signaling. For example, the frequency, for example, PS_PERIOD, of a permanent allocation is signaled in the Radio Resource Management (RRC) signaling. Activation of continuous allocation, as well as accurate timing, as well as physical resources and transport format parameters, are sent through the PDCCH signaling. Once semi-persistent scheduling is activated, the user equipment follows the semi-persistent allocation of resources in accordance with the SPS activation PDCCH each PS_PERIOD. Essentially, the user equipment stores the SPS activation PDCCH content and follows the signaled periodicity of the PDCCH.

In order to distinguish a dynamic PDCCH from a PDCCH, which is activated by semi-persistent scheduling (also called SPS activation PDCCH), a separate identification is entered. Mostly, the CRC of the PDCCH SPS activation is masked by these additional identities, which are referred to as SPS C-RNTI in the following. The SPS C-RNTI size is also 16 bits, just like a normal C-RNTI. In addition, SPS C-RNTI is also special for user equipment, i.e. Each user equipment configured for semi-persistent scheduling is allocated a unique SPS C-RNTI.

In the case where the user equipment detects that the semi-persistent resource allocation is activated by the corresponding SPS activation PDCCH, the user equipment will store the PDCCH content (i.e., semi-permanent resource allocation) and apply it each half-permanent scheduling interval, i.e. periodicity is signaled via RRC. As already mentioned, dynamic allocation, i.e. signaled by dynamic PDCCH, is only a "one-time allocation." Retransmissions of SPS allocation are also signaled using SPS C-RNTI. In order to distinguish SPS activation from SPS retransmission, the NDI bit (New Data Indicator) is used. SPS activation is indicated by setting the NDI bit to 0. An SPS PDCCH with an NDI bit set to 1 indicates a retransmission for a semi-persistently scheduled initial transmission.

Similar to activating semi-persistent scheduling, an eNodeB can also deactivate semi-persistent scheduling, also called SPS resource release. There are several options as to how the deselection of semi-persistent scheduling can be signaled. One option would be to use PDCCH signaling with some PDCCH fields set to some predefined values, i.e. SPS PDCCH indicating zero-size resource allocation. Another option would be to use MAC control signaling.

In the following, additional information is provided regarding how the eNB finds out whether periodic data is transmitted by the UE and when it is possible to configure the SPS.

When a new medium is created, in accordance with the intended procedure for activating the medium in TS 23.401, the MME signals a Media Settings Request message (EPS Media Identification Information, EPS Media QoS, Session Administration Request, S1-TEID) to the eNodeB. The eNodeB maps the QoS of an EPS Carrier to the QoS of a Radio Carrier. It then signals the RRC Connection Reconfiguration message (Radio Carrier QoS, Session Administration Request, EPS RB Identity) to the UE.

The QoS profile of an EPS medium includes QCI, ARP, GBR, and MBR. Each EPS medium (GBR and Non-GBR) is associated with the following media level QoS parameters:

- QoS Class Identifier (QCI);

- Priority Retention and Distribution (ARP).

QCI is a scalar value that is used as a reference to access point-specific parameters that control packet forwarding processing at the media level (for example, scheduling weights, assumption thresholds, queue administration thresholds, link layer protocol configuration, etc. .), and which were preconfigured by means of an operator owning the access node (for example, eNodeB). A one-to-one mapping of standardized QCI values to standardized characteristics is recorded in TS 23.203, as illustrated in the table below, which is based on the one in TS 23.203.

QCI Resource type Priority level Package Delay Budget Packet Error Loss Frequency (Note 2) Sample Services 1 GBR 2 100ms 10 ^-2 Spoken voice 2 4 150ms 10 ^-3 Conversation Video (Live Streaming) 3 3 50ms 10 ^-3 Real time game 4 5 300ms 10 ^-6 Silent video (streaming with buffering) 65 0.7 75ms 10 ^-2 Critical for completing a user plane mission Click to Speak a voice (e.g. MCPTT) 66 2 100ms 10 ^-2 Non-critical to complete a user plane mission Click to Speak Voice 5 Non-GBR 1 100ms 10 ^-6 IMS Alarm 6 6 300ms 10 ^-6 Video (buffered streaming)
TCP based (e.g. www, email, chat, ftp, p2p file sharing, progressive video, etc.) 7 7 100ms 10 ^-3 Vote,
Video (Live Streaming)
Interactive game 8 8 300ms 10 ^-6 Video (buffered streaming)
TCP based (e.g. www, email, chat, ftp, p2p file sharing, progressive video, etc.) 9 9 69 0.5 60ms 10 ^-6 Mission-critical delay-sensitive alarms (e.g. MC-PTT alarms) 70 5.5 200ms 10 ^-6 Mission-critical data (e.g., sample services are exactly the same as QCI 6/8/9)

As can be seen from the table, the value of 1 QCI corresponds to "Spoken Voice", i.e. Voice over IP (VoIP). When the eNB receives the “Media Setup Request” message with a QCI value of 1, the eNB knows that the media is created for VoIP and the SPS configuration can be applied to allocate periodic resources for the UE to transmit VoIP data.

Nearby Services (ProSe) Communication Device to Device (D2D) LTE

Proximity-based applications and services represent an emerging social and technological trend. The identified areas include services related to commercial services and Public Safety that will be of interest to operators and users. The introduction of Proximity Services (ProSe) capabilities in LTE will enable the 3GPP industry to serve this emerging market, while at the same time serving the immediate needs of several Community Security communities that are jointly committed to LTE.

Device-to-Device (D2D) communications is a technology component introduced by LTE-Rel.12 that provides D2D as the base of a cellular network to increase spectral efficiency. For example, if the cellular network is LTE, all data carriers on the physical channels use SC-FDMA for D2D signaling. In D2D communication, user equipments transmit data signals to each other via a forward link using cellular resources instead of via a radio base station. Throughout the invention, the terms “D2D,” “ProSe,” and “side link” are used interchangeably.

D2D communications in LTE focuses on two zones: Discovery and Communications.

ProSe Immediate Discovery (Proximity Based Services) is defined as the procedure used by ProSe-enabled UEs to detect other ProSe-enabled UEs in its vicinity using direct E-UTRA radio signals through the PC5 interface.

In D2D communication, the UEs transmit data signals to each other via a forward link using cellular resources instead of through a base station (BS). D2D users communicate directly while remaining under BS control, i.e. at least in eNB coverage. As a result, D2D can improve system performance by reusing cellular resources.

It is assumed that D2D operates in the uplink LTE spectrum (in the case of FDD) or uplink subframes of the cell providing coverage (in the case of TDD, except when out of coverage). In addition, D2D transmission / reception does not use full duplex on a given carrier. From the point of view of an individual UE, for a given carrier, D2D signal reception and LTE uplink transmission do not use full duplex, i.e. simultaneous reception of D2D signal and UL LTE transmission is not possible.

In D2D communication, when one particular UE 1 plays a transmission role (transmitting user equipment or a transmitting terminal), UE1 sends data, and another UE2 (receiving user equipment) receives it. UE1 and UE2 can change their role of transmission and reception. A transmission from UE1 may be received by one or more UEs like UE2.

ProSe Direct Link Layer 2 Line

Briefly, ProSe direct one-to-one communication is implemented by creating a secure layer-2 link through PC5 between two UEs. Each UE has a Layer-2 ID for unicast communication, which is included in the Layer-2 ID field of the Source of each frame that is sent on the Layer-2 communication line and in the Layer-2 ID of the Recipient of each frame that it receives on the Layer-2 communication line . The UE is required to ensure that the Layer-2 ID for unicast communication is at least locally unique. Thus, the UE must be prepared to handle Layer-2 ID conflicts with adjacent UEs using unspecified mechanisms (for example, self-assigning a new Layer-2 ID for unicast communication when a conflict is detected). The Layer-2 link for ProSe direct one-to-one communication is identified by combining the Layer-2 ID of two UEs. This means that the UE can be involved in several Layer-2 communication lines in relation to direct one-to-one ProSe communication using the same Layer-2 ID.

A direct one-to-one ProSe connection is composed of the following procedures, as explained in detail in TR 23.713 current version v13.0.0 section 7.1.2, incorporated herein by reference:

- Creating a secure Layer-2 link through PC5.

- Assign IP address / prefix.

- Maintaining a layer-2 link through PC5.

- Release of communication layer-2 through PC5.

FIG. Figure 3 illustrates how to create a secure Layer-2 communication link through the PC5 interface.

1. The UE-1 sends a Direct Link Request message to the UE-2 in order to initiate 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 find out the Layer-2 ID of the peer by first executing the discovery procedure or participating in a one-to-one ProSe connection including a peer.

2. UE-2 initiates the mutual authentication procedure. Successful completion of the authentication procedure completes the creation of a secure layer-2 link through PC5.

UEs involved in isolated (non-relayed) one-to-one communications can also use local addresses for the communication link. The PC5 Signaling Protocol must support the activity checking functionality, which is used to detect when UEs are not in the ProSe Link range, so that they can continue by implicitly releasing the layer-2 link. The release of the Layer-2 communication link through PC5 can be accomplished by using the Disconnect Request message sent to another UE, which also deletes all associated context data. Upon receipt of the Disconnect Request message, the other UE responds with the Disconnect Response message and deletes all context data associated with the layer-2 link.

ProSe Direct Link Identification

3GPP TS 36.300, current version 13.2.0, defines in Subclause 8.3 the following credentials for use with ProSe Direct Link:

- SL-RNTI: Unique identification used for ProSe Direct Link Planning;

- Source Layer-2 ID: Identifies the sender of the data in ProSe Direct Link type side link. The Layer-2 ID of the Source is 24 bits long and is used with the Layer-2 ID of the ProSe and LCID to identify the RLC UM and PDCP in the receiver;

- Recipient Layer-2 ID: Identifies the ProSe Direct Link data target of the type of side link. Recipient Layer-2 ID is 24 bits long and is divided into two bit strings in the MAC layer:

- One bit string is part of the LSB (8 bits) of the Recipient Layer-2 ID and is forwarded to the physical layer as the Layer-1 ID of the Link Control. This identifies the purpose of the intended data in the Side Link Management and is used to filter packets on the physical layer.

- The second bit string is part of the MSB (16 bits) of the Recipient Layer-2 ID and is carried in the MAC header. This is used to filter packets on the MAC layer.

Non-Access Layer Signaling is required to form a group, and to configure the Source Layer-2 ID, Recipient Layer-2 ID, and Side Link Control ID L1 in the UE. These credentials are either provided by the higher layer or retrieved from the credentials provided by the higher layer. In the case of multicast or broadcast, the ProSe UE ID provided by the higher layer is used directly as the Source Layer-2 ID, and the ProSe Layer-2 Group ID provided by the higher layer is used directly as the Recipient Layer-2 ID in the layer MAC In the case of a one-to-one relationship, the higher layer provides the Source Layer-2 ID and the Recipient Layer-2 ID.

Distribution of Radio Resources for Proximity Services

From the point of view of the transmitting UE, a UE with support for Nearby Services (UE with ProSe support) can operate in two modes with respect to resource allocation:

Mode 1 refers to an eNB-planned resource allocation, where the UE requests transmission resources from the eNB (or Edition-10 relay node), and the eNodeB (or Edition-10 relay node) in turn schedules the resources used by the UE to transmit direct data and direct management information (e.g. Planning Assignment). The UE is required to be in the RRC_CONNECTED state in order to transmit data. In particular, the UE sends a scheduling request (D-SR or Random Access) to the eNB, followed by a buffer status report (BSR) in the usual way (see also the next section, “Transmission Procedure for D2D Communication”). Based on the BSR, the eNB may determine that the UE has data for transmitting the ProSe Direct Link, and may estimate the resources required for transmission.

Mode 2, on the other hand, refers to a UE-autonomous resource selection, where the UE itself selects resources (time and frequency) from the resource pool (s) to transmit immediate data and immediate control information (i.e., SA). One resource pool is determined, for example, through SIB18 content, namely, through the commTxPoolNormalCommon field, the broadcast of this particular resource pool was carried out in a cell and then it becomes usually available to all UEs in the cell, still in the RRC_Idle state. In fact, an eNB can define up to four different instances of the pool, respectively four resource pools for transmitting the SA message and the immediate data. However, in Rel-12, the UE should always use the first resource pool defined in the list, even if it was configured with multiple resource pools. This restriction was removed for Rel-13, i.e. The UE may transmit over several of the configured resource pools in a single SC period. How the UE selects the resource pools for transmission is further outlined below (further indicated in TS36.321).

Alternatively, another resource pool can be defined by the eNB and signaled in SIB18, namely by using the commTxPoolExceptional field, which can be used by the UE in exceptional cases.

Which resource allocation mode the UE is about to use is configurable by the eNB. In addition, which resource allocation mode the UE is going to use to communicate D2D data may also depend on the state of the RRC, i.e. RRC_IDLE or RRC_CONNECTED, and UE coverage states, i.e. in-coverage, out-of-coverage. A UE is considered in-coverage if it has a serving cell (i.e., the UE is in the RRC_CONNECTED state or is anchored in the cell in the RRC_IDLE state).

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

- If the UE is out of coverage, it can only use Mode 2;

- If the UE is in-coverage, it may use Mode 1 if the eNB configures it accordingly;

- If the UE is in-coverage, it may use Mode 2 if the eNB configures it accordingly;

- When there are no exceptional conditions, the UE may change from Mode 1 to Mode 2 or vice versa only if it is configured by the eNB to do so. If the UE is in-coverage, it should only use the mode specified by the eNB configuration, provided that one of the exceptional cases does not occur;

- The UE considers itself as being in exceptional cases, for example, while the T311 or T301 are running;

- When an exceptional case occurs, the UE is allowed to use Mode 2 temporarily even though it has been configured to use Mode 1.

In the coverage area of the E-UTRA cell, the UE must only perform ProSe Direct Link Transmission on the UL carrier on the resources assigned by that cell, even if the resources of that carrier were pre-configured, for example, in the UICC (Universal Integrated Circuit Chart).

For a UE in the RRC_IDLE state, the eNB may select one of the following options:

- The eNB may provide a Mode 2 transmission resource pool in the SIB. UEs that are authorized for ProSe Direct Link use these resources for ProSe Direct Link in RRC_IDLE;

- The eNB may indicate in the SIB that it supports D2D but does not provide resources for ProSe Direct Communications. The UE needs to enter the RRC_CONNECTED state in order to perform ProSe Forward Link transmission.

For a UE in RRC_CONNECTED state:

- The UE in the RRC_CONNECTED state, which is authorized to perform ProSe Direct Link transmission, indicates to the eNB that it wishes to perform ProSe Direct Link transmissions when it needs to perform the ProSe Direct Link transmission;

- the eNB confirms whether the UE in the RRC_CONNECTED state is authorized to transmit the ProSe Direct Link using the UE context received from the MME;

- the eNB can configure the UE in the RRC_CONNECTED state by means of dedicated signaling of the Mode-2 resource allocation transmission resource pool, which can be used without restrictions while the UE is in the RRC_CONNECTED state. Alternatively, the eNB may configure the UE in the RRC_CONNECTED state by means of dedicated signaling by the Mode 2 resource allocation transmission resource pool, which the UE is allowed to use only in exceptional cases and otherwise rely on Mode 1.

The resource pool for the Schedule Assignment when the UE is out of coverage can be configured as follows:

- The resource pool used for reception is pre-configured.

- The resource pool used for transmission is pre-configured.

The resource pool for the Schedule Assignment when the UE is in coverage can be configured as follows:

- The resource pool used for reception is configured by the eNB through the RRC, in dedicated or broadcast signaling.

- The resource pool used for transmission is configured by the eNB through the RRC if Mode 2 resource allocation is used.

- The SCI Resource Pool (Link Side Management Information) (also referred to as the Schedule Assignment Resource Pool, SA) used for transmission is unknown to the UE if Mode 1 resource allocation is used.

- the eNB schedules the specific resource (s) to use for transmission of the Side Link Communication Information (Schedule Assignment) if the Mode 1 resource allocation is used. The special resource assigned by the eNB is located in the resource pool for receiving the SCI that is provided by the UE.

FIG. 4 illustrates the use of transmission / reception resources for an overlay system (LTE) and a substrate (D2D).

Basically, the eNodeB controls whether the UE can apply Mode 1 or Mode 2 transmission. Once the UE knows its resources by which it can transmit (or receive) D2D communications, it uses the appropriate resources only for the corresponding transmission / reception. For example, in FIG. The 4 D2D subframes will only be used to receive or transmit D2D signals. Since the UE as a D2D device will operate in Half Duplex mode, it can either receive or transmit D2D signals at any time. Similarly, other subframes illustrated in FIG. 4 can be used for transmitting and / or receiving LTE (overlay).

Transfer Procedure for D2D Communication

The D2D data transfer procedure differs depending on the mode of resource allocation. As described above for Mode 1, the eNB explicitly schedules resources for Schedule Assignment and D2D data communications after a corresponding request from the UE. In particular, the UE may be informed by the eNB that D2D communication is generally allowed, but that Mode 2 resources (i.e., resource pool) are not provided; this can be accomplished, for example, by exchanging D2D Link Interest Interest Indications by the UE and the corresponding response, the D2D Link Response, where the corresponding exemplary ProseCommConfig information element will not include commTxPoolNormalCommon, meaning that the UE that wishes to start a direct link including transmission, must request from the E-UTRAN the allocation of resources for each individual transmission. Thus, in this case, the UE must request resources for each individual transmission, and in the following, the various steps of the request / grant procedure are listed as an example for this Mode 1 resource allocation:

- Step 1: The UE sends an SR (Schedule Request) to the eNB through the PUCCH;

- Step 2: the eNB enables the UL resource (for the UE to send the BSR) through a PDCCH encrypted with a C-RNTI;

- Step 3: the UE sends a D2D BSR indicating the status of the buffer through PUSCH;

- Step 4: the eNB resolves the D2D resource (for the UE to send data) through a PDCCH encrypted by the D2D-RNTI;

- Step 5: D2D Tx UE transmits SA / D2D data in accordance with the resolution received in step 4.

A Scheduling Assignment (SA), also called SCI (Side Link Control Information), is a compact (low payload) message containing control information such as time-frequency resources pointer (s), modulation and coding scheme, and Recipient ID Groups for the corresponding D2D data transfer. SCI transports the sideline scheduling information for a single recipient ID (ProSe). Content SA (SCI) is mainly in accordance with the permission adopted in Step 4 above. D2D resolution and SA content (i.e., SCI content) are defined in technical standard 3GPP 36.212, current version 13.0.0, subclause 5.4.3, incorporated herein by reference, specifically referring to SCI format 0 (see content SCI format 0 above).

On the other hand, for Mode 2 resource allocation, the above steps 1-4 are mainly optional, and the UE autonomously selects resources for the SA and transmitting D2D data from the transmission resource pool (s) configured and provided by the eNB.

FIG. 5 illustrates, by way of example, the transmission of Scheduling Assignment and D2D data for two UEs, UE1 and UE2, where resources for sending scheduling assignments are periodic and resources used for transmitting D2D data are indicated by the corresponding Scheduling Assignment.

FIG. 6 illustrates D2D communication timing for Mode 2, autonomous scheduling, for one SA / data period, also known as an SC period, Link Side Management period. FIG. 7 illustrates D2D communication timing for Mode 1, an eNB-scheduled distribution over one SA / data period. An SC period is a time period consisting of the transmission of a Planning Assignment and its corresponding data. As can be seen from FIG. 6, the UE transmits, after the SA bias time, the Schedule Assignment using the transmission pool resources for the schedule assignments for Mode 2, SA_Mode2_Tx_pool. The 1st transmission of the SA is accompanied, for example, by three retransmissions of the same SA message. Then, the UE starts transmitting D2D data, i.e. more specifically a T-RPT bitmap / pattern, with some configured offset (Mode2data_offset) after the first subframe of the SA resource pool (specified by SA offset). One D2D data transmission of a MAC PDU (i.e., a transport unit) consists of its 1st transmission and several retransmissions. To illustrate FIG. 7 (or FIG. 7), it is assumed that three retransmissions are performed (i.e., 2nd, 3rd, and 4th transmission of the same MAC PDU). Bitmap T-RPT Mode 2 (transmission time resource template, T-RPT) mainly determines the timing of transmitting MAC PDU (first transmission) and its retransmissions ^{(2nd, 3rd,} and ^4th gear). Template SA mainly determines the timing of the initial transmission of SA and its retransmissions ^{(2nd, 3rd,} and ^4th gear).

As currently specified in the standard, for one resolution of the side link, for example, either sent via the eNB or selected by the UE itself, the UE can transmit several transport blocks, MAC PDUs, (only per subframe (TTI), i.e. one after another), however, only to one group of ProSe recipients. Also, retransmissions of one transport block must be completed before the first transmission of the next transport block begins, i.e. only one HARQ process is used based on the resolution of the side link for transmitting multiple transport blocks. In addition, the UE may have and use several side-link permissions based on the SC period, but different ProSe recipients are selected for each of them. Thus, in one SC period, the UE can transmit data to one ProSe recipient only once.

As is apparent from FIG. 7, with respect to the eNB-planned resource allocation mode (Mode 1), D2D data transmission, i.e. more specifically the T-RPT pattern / bitmap, begins in the next UL subframe after the last retransmission of the SA transmission in the SA resource pool. As already explained for FIG. 6, the Mode-1 T-RPT Bitmap (Temporary Transmission Resource Template, T-RPT) mainly defines the timing of the MAC PDU transmission (1st gear) and its retransmissions (2nd, 3rd, and 4th gear).

The procedure for transmitting side-line data can be found in 3GPP TS 36.321 v13.0.0, section 5.14, incorporated herein by reference. It details the autonomous selection of Mode-2 resources, with the difference between being configured with one radio resource pool or with multiple radio resource pools. The following steps are taken from the aforementioned TS 36/321 section, assuming an autonomous selection of Mode-2 resources:

In order to transmit on an SL-SCH (shared side-channel channel), the MAC entity must have at least one side-line resolution. Sideline permissions are selected as follows:

If the MAC object is configured through the upper layers to transmit using one or more resource pools (s) and more data is available in the STCH (side channel traffic channel) that can be transmitted in the current SC period, the MAC object must be selected for each side line resolution:

- if configured by top layers to use one resource pool:

- choose that resource pool to use;

- otherwise, if configured by top layers to use multiple resource pools:

- select a resource pool for use from resource pools configured by the upper layers, whose associated priority list includes the highest priority priority for the logical channel of the side line in the MAC PDU that must be transmitted;

Note: If more than one resource pool has an associated priority list that includes the priority of the highest priority side link logical channel in the MAC PDU to be transmitted, then one of these resource pools is stopped for implementation by the UE.

- randomly select time and frequency resources for SL-SCH and SCI at the resolution of the side link from the selected resource pool. An arbitrary function should be such that each of the allowed choices can be chosen with equal probability;

- use the selected side-link resolution to determine the set of subframes in which SCI transmission and transmission of the first transport block occurs in accordance with sub-clause 14.2.1 of TS 36.213, incorporated herein by reference (this step relates to the selection of T-RPT and template SA, as explained in connection with Fig. 7);

- consider the selected resolution of the side line of communication, as the configured resolution of the side line of communication occurring in those subframes starting at the beginning of the first available SC Period, which begins at least 4 subframes after the subframe in which the resolution of the side line was selected ;

- reset the configured side link resolution at the end of the corresponding SC Period;

Note: SL-SCH retransmissions may occur after the configured side link resolution is cleared.

Note: If the MAC object is configured through the upper layers to transmit using one or more pool (s) of resources, then the implementation of the UE is left with how many side-line permissions to choose in one SC period, given the number of side-line processes.

The MAC object must for each subframe:

- if the MAC entity has a configured side link resolution occurring in a given subframe;

- if the configured side link resolution corresponds to SCI transmission:

--- Issue instructions to the physical layer for SCI transmission corresponding to the configured side-link resolution.

- otherwise, if the configured resolution of the side link corresponds to the transmission of the first transport block:

--- Deliver the configured side link resolution and associated HARQ information to the Side Link HARQ Object for a given subframe.

Note: If the MAC object has several configured permissions that arise in one subframe and if not all of them can be processed due to the restriction of one SC-FDM cluster, then the implementation of the UE is left with which one of them to process in accordance with the procedure above .

The above text, taken from the technical standard 3GPP, can be further explained. For example, the step of randomly selecting time and frequency resources is arbitrary with respect to which specific time / frequency resources are selected, but is not, for example, arbitrary with respect to the amount of the total selected time / frequency resources. The amount of resources selected from the resource pool depends on the amount of data that must be transmitted with said side-link resolution, which should be autonomously selected. In turn, the amount of data to be transmitted depends on the previous step of selecting the ProSe recipient group and the corresponding amount of data ready for transmission intended for the said ProSe recipient group. As described later, in the side link LCP procedure, a ProSe receiver is first selected.

In addition, the side-link process associated with the side-line HARQ entity is responsible for issuing instructions to the physical layer to generate and complete the transmission, respectively, as is apparent from section 5.14.1.2.2 of 3GPP TS 36.321 v13.0.0 included in the present description by reference. In short, after determining the resolution of the side link and the side line data for transmission, the physical layer takes care that the side line data is actually transmitted, based on the resolution of the side line and the necessary transmission parameters.

What was discussed above is the current status of the 3GPP standard for D2D communications. However, it should be noted that discussions are continuing on how to further improve and strengthen the D2D link, which will likely lead to some changes being introduced to the D2D link in future editions. The present invention, as will be described later, should also be applicable to these later editions.

ProSe Network Architecture and ProSe Objects

FIG. 8 illustrates a high-level exemplary architecture for a non-roaming case, including various ProSe applications in the respective UEs A and B, as well as the ProSe Application Server and the ProSe function on the network. Exemplary Architecture FIG. 8 is taken from TS 23.303 v13.2.0, chapter 4.2 of the “Architectural Reference Model”, incorporated herein by reference.

Functional entities are presented and explained in detail in TS 23.303, Subclause 4.4, “Functional Entities”, incorporated herein by reference. The ProSe function is a logical function that is used for the network related actions required for ProSe and plays different roles for each of the ProSe features. The ProSe function is part of the 3GPP EPC and provides all relevant network services, such as authorization, authentication, data processing, etc., that relate to proximity services. In relation to the direct detection and communication of ProSe, the UE can receive special identification data of the ProSe UE, other configuration information, as well as authorization from the ProSe function through the reference point PC3. There may be several ProSe functions deployed on a network, although one ProSe function is provided for ease of illustration. The ProSe function consists of three main subfunctions that play different roles depending on the ProSe feature: Direct Provisioning Function (DPF), Direct Discovery Name Administration Function, and EPC-Level Discovery Function. DPF is used to provide the necessary parameters to the UE to use ProSe Direct Detection and ProSe Direct Communication.

The term “UE” used in said connection refers to a ProSe-enabled UE that supports ProSe functionality, such as:

- Exchange of ProSe management information between ProSe-enabled UEs and ProSe Function through PC3 reference point.

- Procedures for open ProSe Direct Detection of other UEs with ProSe support through PC5 reference point.

- One-to-many ProSe Direct Link procedures through PC5 reference point.

- Procedures to act as a ProSe UE-to-Network Repeater. The remote UE communicates with the ProSe UE-to-Network Repeater via PC5 reference point. ProSe UE-to-Network Repeater uses Layer-3 packet forwarding.

- Exchange of control information between the ProSe UE through the PC5 reference point, for example, for UE-to-Network Repeater detection and ProSe Direct Detection.

- Exchange of ProSe management information between another ProSe-enabled UE and ProSe Function through the PC3 reference point. In the case of a ProSe UE-to-Network Repeater, the Remote UE will send this control information through the PC5 user plane so that it is relayed through the LTE-Uu interface to the ProSe Function.

- Configuration of parameters (for example, including IP addresses, ProSe Layer-2 Group ID, Group security materials, radio resource parameters). These parameters can be preconfigured in the UE, or, if covered, provided by signaling through the PC3 reference point of the ProSe function on the network.

The ProSe Application Server supports Storing the ProSe EPC User ID, and ProSe Function ID, and displaying the Application Layer User ID and ProSe EPC User ID. The ProSe Application Server (AS) is an object outside the 3GPP domain. The ProSe application in the UE communicates with the ProSe AS through the reference point PC1 of the application layer. AS ProSe is connected to the 3GPP network via PC2 reference point.

Vehicle Communication - V2X Services

A new research subject has been created at 3GPP to examine the usefulness of the new LTE features for the automotive industry - including Proximity Service (ProSe) and LTE-based broadcast services. ProSe functionality is thus seen as offering a good foundation for V2X services. Combined vehicle technology aims to address some of the biggest challenges in the land transportation industry, such as safety, mobility, and road efficiency.

V2X communication is the passage of information from a vehicle to any object that may affect the vehicle, and vice versa. This information exchange can be used to improve safety, mobility and environmental applications to ensure vehicle safety with the help of a driver, adapting speed and warning, responding to emergency situations, traffic information, navigation, traffic operations, fleet planning and payment transactions .

LTE support for V2X services contains 3 types of different use cases, which are as follows:

- V2V: covering LTE-based communication between vehicles.

- V2P: covering LTE-based communication between the vehicle and the device that the individual carries (e.g., a portable terminal that carries a pedestrian, cyclist, driver or passenger).

- V2I: covering LTE-based communication between the vehicle and the road side unit.

These three types of V2X can use “shared awareness” to provide more intelligent services to end users. This means that transportation facilities, such as vehicles, roadside infrastructure, and pedestrians, can collect knowledge of their local environment (for example, information received from other vehicles or sensor equipment nearby) to process and share this knowledge in order to to provide more intelligent services such as collaborative collision warning or autonomous driving.

Regarding V2V communications, the E-UTRAN allows such UEs that are close to each other to exchange V2V-related information using E-UTRA (N) when resolution, authorization, and proximity criteria are met. Proximity criteria can be configured through MNO (Mobile Network Operator). However, UEs supporting the V2V Service may exchange such information when serviced by or are not serviced by an E-UTRAN that supports the V2V Service.

A UE supporting a V2V application transmits application layer information (e.g., its location, dynamics, and attributes as part of the V2V Service). The V2V payload must be flexible in order to accommodate different content of information, and information can be transmitted periodically in accordance with the configuration provided by the MNO.

V2V is predominantly broadcast based; V2V involves the exchange of V2V-related application information between different UEs directly and / or, due to the limited direct communication range of V2V, the exchange of V2V-related application information between different UEs through an infrastructure supporting the V2X Service, for example, RSU, application server , etc.

Regarding V2I communications, a UE supporting V2I applications sends application layer information to a Road Side Block, which in turn can send application layer information to a UE group or UE supporting V2I applications.

A V2N (Vehicle with Network, eNB / CN) is also entered where one side is a UE and the other side is a serving entity, both supporting V2N applications and communicating with each other via an LTE network.

Regarding V2P communications, the E-UTRAN allows such UEs that are close to each other to exchange V2P related information using the E-UTRAN when permission, authorization, and proximity criteria are met. Proximity criteria can be configured through MNO. However, UEs supporting the V2P Service can exchange such information even when not served by an E-UTRAN that supports the V2X Service.

A UE supporting V2P applications transmits application layer information. Such information may be transmitted through broadcasting by a vehicle with a UE supporting the V2X Service (e.g., pedestrian warning) and / or by pedestrian with a UE supporting the V2X Service (e.g. warning to the vehicle).

V2P involves the exchange of V2P-related application information between different UEs (one for a vehicle and the other for a pedestrian) directly and / or, due to the limited direct communication range of V2P, the exchange of V2P-related application information between different UEs through the infrastructure supporting the V2X Service, for example, RSU, application server, etc.

For this new subject of V2X research, 3GPP provided specific concepts and definitions in TR 21.905, current version 13.0.0, which can be reused for this application.

Road Side Unit (RSU): An entity supporting the V2I Service that can transmit to and receive from the UE using the V2I application. RSU can be implemented in an eNB or a stationary UE.

V2I Service: A type of V2X Service, where one side is the UE and the other side is the RSU, both sides using the V2I application.

V2N Service: A type of V2X Service, where one side is a UE and the other side is a serving entity, both sides using V2N applications and communicating with each other via LTE network entities.

V2P Service: A type of V2X Service, where both sides of the communication are UEs using the V2P application.

V2V Service: A type of V2X Service, where both sides of the communication are UEs using the V2V application.

V2X Service: A type of communication service that includes a transmitting or receiving UE using a V2V application via 3GPP transport. Based on the other party involved in the communication, it may be further divided into V2V Service, V2I Service, and V2N Service.

Different types of messages are and will be defined for V2V communication. Two different message types have already been defined by ETSI for Intelligent Transport Systems (ITS), see the relevant European Standards ETSI EN 302 637-2 v1.3.1 and ETSI EN 302 637-3 v 1.2.1:

- Joint Awareness Messages (CAMs) that are continuously triggered by vehicle dynamics to reflect vehicle status.

- Decentralized Environmental Notification Messages (DENMs), which are triggered only when vehicle-related safety events occur.

Since the standardizations of V2V and ITS are sooner in the beginning, it should be expected that other messages may be defined in the future.

CAMs are continuous broadcast through ITS Stations (ITS-S) to exchange status information with other ITS-Ss, and therefore have a greater impact on traffic load than event-triggered DENN messages. For this reason, CAM message traffic characteristics, as determined by ETSI for ITS, are considered more representative of V2V traffic.

Joint Awareness Messages (CAMs) are messages exchanged on the ITS network between the ITS-Ss in order to create and maintain each other's awareness and to support the joint functioning of vehicles using the road network. Point-to-multipoint communications must be used for CAM transmission, so that CAMs are transmitted from the ITS-S source to the receiving ITS-S located in the direct range of the ITS-S source. CAM generation must be initiated and administered through the core Collaborative Awareness service, which defines the time interval between two consecutive CAM generation. Currently, the upper and lower limits of the transmission interval are 100ms (i.e., CAM generation frequency at 10Hz) and 1000ms (i.e., CAM generation frequency at 1Hz). The underlying philosophy of the ETSI ITS is to send CAM when there is new information to share (for example, new position, new acceleration or new course values). Accordingly, when vehicles move slowly and at a constant heading and speed, the high frequency of CAM generation does not give real benefits, since CAM show only minimal differences. The vehicle CAM transmission frequency varies between 1Hz and 10Hz as a function of vehicle dynamics (e.g. speed, acceleration, and heading). For example, the slower the transport neighborhood moves, the fewer CAMs are initiated and transmitted. Vehicle speed is the main factor influencing the generation of CAM traffic,

The triggering conditions for CAM generation are currently defined in ETSI EN 302 637-2 v1.3.1 clause 6.1.3 and are shown below:

1) The time elapsed since the last CAM generation is equal to or greater than T_GenCam_Dcc (a parameter that provides the minimum time interval between two consecutive CAM generation times in order to reduce CAM generation in accordance with the requirements of the decentralized congestion control channel (DCC) and set one of the following ITS-S dynamics related conditions:

- the absolute difference between the current rate of the ITS-S source and the course included in the CAM, previously transmitted by the ITS-S source, exceeds 4 °;

- the distance between the current position of the ITS-S source and the position included in the CAM previously transmitted by the ITS-S source exceeds 4 m;

- the absolute difference between the current speed of the ITS-S source and the speed included in the CAM previously transmitted by the ITS-S source exceeds 0.5 m / s.

2) The time elapsed since the last CAM generation is equal to or greater than T_GenCam and equal to or greater than T_GenCam_Dcc. The T_GenCam parameter represents the current valid upper limit of the CAM generation interval.

If one of the above two conditions is satisfied, CAM should be generated immediately.

CAM contains status and attribute information of the ITS-S source. CAM content varies with the type of ITS-S, as will be explained in more detail below. For an ITS-S vehicle, status information may include time, position, movement status, activated systems, etc., and attribute information may include data regarding dimensions, vehicle type and role in road traffic, and so on. .d. Upon receipt of the CAM, the receiving ITS-S becomes aware of the presence, type, and status of the ITS-S source. The received information may be used by the receiving ITS-S to support multiple ITS applications. For example, by comparing the status of the ITS-S source with its own status, the receiving ITS-S is able to assess the risk of collision with the ITS-S source and, if necessary, can inform the driver of the vehicle through the HMI (Human Machine Interface). As described in detail in article 7 of ETSI EN 302 637-2 v 1.3.1, incorporated herein by reference, a CAM consists of one common ITS PDU header and several containers that together constitute a CAM. The ITS PDU header is a common header that includes protocol version information, message type and ITS-S ID of the ITS-S source. For an ITS-S vehicle, a CAM must contain one primary container and one high-frequency container, and may also include one low-frequency container and one or more other specific containers. The main container includes basic information related to the ITS-S source. The high-frequency container contains highly-dynamic ITS-S source information. The low-frequency container contains static and not highly-dynamic ITS-S source information. The vehicle specific container contains information specific to the vehicle role of the vehicle ITS-S source. The general structure of the CAM is illustrated in FIG. 9.

The following table gives an overview and package sizes of the various data components of the V2V message:

Data items A type Typical Size (Bytes) Description Headline Mandatory 8 Protocol version, message type, sender address, and timestamp Main container Mandatory eighteen Station type (e.g. light truck, cyclist, pedestrian, etc.) and position High Frequency (HF) Container Mandatory 23 All rapidly changing vehicle status information, i.e. heading, speed, acceleration, etc. Low Frequency (LF) Container Optional 60 Static or slowly changing vehicle data, mainly track history. The history of the path consists of a number of points in the history of the path. 7 points in the history of the path are enough to cover more than 90% of cases, based on extensive testing. Each point is approximately 8 bytes. Vehicle specific container Optional 2 ~ 11 The special role of vehicles in road traffic (for example, public transport, vehicles implementing a rescue operation, etc.).

The vehicle ITS-S generates CAM, which should include at least a high-frequency container of the vehicle, and, optionally, a low-frequency container of the vehicle. Vehicle ITS-Ss, which have a special role in road traffic, such as public transport, must provide status information in specific vehicle containers.

Each V2V message exchanged between vehicles must meet security requirements, including the protection of anonymity and integrity. Different security schemes may have different security features and service data levels that directly affect the packet size (due to security service data) and the frequency of the message (for example, how frequencies are attached to the security certificate).

Both ETSI ITS and IEEE 1609.2 consider PKI-based security solutions for V2X communications, which is an asymmetry-based application layer security solution. As a rule, each V2V message should be signed, as, however, either a certificate or a certificate digest, in order to protect anonymity and integrity. Typical sizes for signature, digest, and certificate are 64 bytes, 8 bytes, and 117 bytes, respectively.

As explained above, CAM messages may have different periodicities and / or different message sizes. In addition, periodicities may even change over time depending on speed and other (less influencing) factors such as course or angle. In order to provide a general overview, the following tables are provided identifying the different possible message components (HF, LF, certificate) and the resulting frequency and size of the message depending on three different typical speed ranges.

CAM with PKI-based security overhead (for vehicle speeds> 144km / h):

Component Distribution Parameters HF CAM component transmission frequency (including signature and digest) Deterministic 10Hz (or every 100ms) LF CAM component transmission frequency Deterministic 2Hz (or every 500ms) Certificate Transfer Frequency Deterministic 1Hz (or every 1000ms) HF CAM component size (including signature and digest) Deterministic 122 bytes Component Size LF CAM Deterministic 60 bytes Certificate Size Deterministic 117 bytes

CAM with PKI-based security overhead (speed ∈ [[72, 144] km / h)

Component Distribution Parameters HF CAM component transmission frequency (including signature and digest) Deterministic 5Hz (or every 200ms) LF CAM component transmission frequency Deterministic 1.67Hz (or every 600ms) Certificate Transfer Frequency Deterministic 1Hz (or every 1000ms) HF CAM component size (including signature and digest) Deterministic 122 bytes Component Size LF CAM Deterministic 60 bytes Certificate Size Deterministic 117 bytes

CAM with PKI-based security overhead (speed ∈ [[48, 72] km / h)

Component Distribution Parameters HF CAM component transmission frequency (including signature and digest) Deterministic 3.33Hz (or every 300ms) LF CAM component transmission frequency Deterministic 1.67Hz (or every 600ms) Certificate Transfer Frequency Deterministic 0.83Hz (or every 1200ms) HF CAM component size (including signature and digest) Deterministic 122 bytes Component Size LF CAM Deterministic 60 bytes Certificate Size Deterministic 117 bytes

As is obvious from the above table, the size of the components and, therefore, the CAM remains the same, but their frequency of generation / transmission varies with different speed ranges. In relation to the above table, the HF CAM component is assumed to be transmitted along with the signature and digest, resulting in a message size of approximately 122 bytes (i.e. sufficient to transport 8 bytes for the header, 18 bytes for the main container, 23 bytes for high-frequency container, 64 bytes for signature and 8 bytes for digest). The LF CAM component, which integrates with the high frequency component, has approximately an extra 60 bytes in size, so the resulting CAM size with all containers / components is 182 bytes. The certificate component (also referred to as the security component), which is combined with the high-frequency component, is approximately an additional 117 bytes in size so that the resulting CAM size with all containers / components is 299 bytes or without a container / component LF CAM is 239 bytes.

FIG. 10 illustrates the occurrence of three different components depending on the three different speed ranges entered above and how this leads to different total message sizes and full periodicities. In FIG. 10, a dashed square containing different components should indicate that the components are not transmitted separately, but as a single CAM message.

In the above, the periodic Joint Awareness messages have been described in great detail, also indicating their different content, specific frequency and size of the message. However, it should be noted that although some of the above information has already been standardized, other information, such as the frequency and size of the message, has not yet been standardized and is based on assumptions. In addition, standardization may change in the future and, therefore, may also change aspects of how CAMs are generated and transmitted. In addition, despite the fact that currently the various components described above (HF CAM, LF CAM, certificate) are transferred together, i.e. as one message, when they happen together, this is not necessarily the case. In the future, there is also the possibility of transferring these containers / components separately from each other, then probably including the Header and possibly the main container. Therefore, the foregoing detailed description of CAM should be understood as an example formulated for purposes of illustration, although message sizes and periodicities are realistic and based on simulation results. The CAM message described above and its content, the frequency and size of the message will be used throughout this application in order to explain the underlying principles of the invention. What is important for the invention is that the V2V communication will require the UE of the vehicles to transmit different data periodically, and it is predictable that the periodicity can change rapidly as a function of vehicle dynamics, such as (relative) speed, angles, course , and possibly other factors, such as vehicle distance, etc. Therefore, the challenge is that the vehicle UE must be able to transmit several periodic packets of different message sizes with different and varying periodicities.

In order for the vehicle UE to have radio resources on the side link in order to transmit CAM, it is assumed that the radio resources of Mode 1 and / or Mode 2 are allocated, as explained above. For Mode 1 radio resource allocation, the eNB allocates resources for the SA message and data for each SA period. However, when there is a lot of traffic (e.g., high frequency periodic traffic), the overhead on the Uu link from the UE to the eNB can be large.

As is clear from the above, most V2V traffic is periodic, so 3GPP agreed that for Mode 1 V2V side-line communications (i.e., eNB planned radio resource allocation), a semi-permanent allocation of side-channel radio resources will be supported by eNB and UE.

However, the currently standardized semi-persistent distribution mechanism needs to be improved and adapted to the requirements and objectives of V2V traffic.

SUMMARY OF THE INVENTION

Non-limiting and exemplary embodiments provide an improved method of allocating resources for communicating vehicles to a mobile terminal of a vehicle.

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

Accordingly, in one general first aspect, the techniques disclosed herein are characterized by a mobile terminal of a vehicle for transmitting periodic data to one or more receiving entities. The vehicle’s mobile terminal supports the transmission of periodic data containing one or more different data components that must be transmitted with different possible transmission frequencies and / or different possible message sizes. The transmitter of the mobile terminal of the vehicle transmits information about the periodic data of the radio base station responsible for allocating radio resources to the mobile terminal of the vehicle. The transmitted periodic data information is such that it allows the radio base station to determine different possible transmission frequencies and / or different possible message sizes of one or more data components of the periodic data. The vehicle mobile terminal receiver receives from the radio base station a plurality of configurations of semi-permanent radio resources configured by the radio base station based on the received periodic data information. Each of a plurality of configurations of semi-permanent radio resources is configured to be used to transmit at least one of the supported data components. The transmitter then indicates to the radio base station that one or more of the data components will be transmitted via the vehicle’s mobile terminal. The receiver receives an activation command from the radio base station to activate one or more of a plurality of configurations of semi-permanent radio resources to periodically allocate radio resources to the mobile terminal of the vehicle to transmit each of these data components. The transmitter then transmits one or more data components to one or more receiving entities based on radio resources and transmission frequency, as configured by one or more configurations of semi-permanent radio resources.

Accordingly, in one general first aspect, the techniques disclosed herein are characterized by a radio base station for allocating radio resources to a mobile terminal of a vehicle for transmitting periodic data to one or more receiving entities. The vehicle’s mobile terminal supports the transmission of periodic data containing one or more different data components that must be transmitted with different possible transmission frequencies and / or different message sizes. The receiver of the radio base station receives information from the mobile terminal of the vehicle about periodic data to be transmitted via the mobile terminal of the vehicle to one or more receiving entities. The radio base station processor determines the different supported data components and the different possible transmission frequencies and / or the different possible message sizes for one or more data components. The processor configures a plurality of configurations of semi-permanent radio resources based on certain transmission frequencies and / or a specific message size. Each of a plurality of configurations of semi-permanent radio resources is configured to be used to transmit at least one of the supported data components. The radio base station transmitter transmits information about the configured plurality of configurations of semi-permanent radio resources to the mobile terminal of the vehicle. The receiver receives, from the vehicle’s mobile terminal, an indication that one or more of the data components should be transmitted via the vehicle’s mobile terminal. The processor then selects one or more of a plurality of configurations of semi-permanent radio resources to be activated for the vehicle’s mobile terminal in order to periodically allocate radio resources for the vehicle’s mobile terminal in order to transmit each of these data components. The transmitter is further configured to transmit an activation command to the mobile terminal of the vehicle to activate the selected one or more configurations of semi-permanent radio resources for the mobile terminal of the vehicle.

Additional benefits and advantages of the disclosed embodiments will be apparent from the technical description and the Figures. Benefits and / or advantages can be individually provided through various embodiments and features of the technical description and disclosure of the drawings, and it is not required that all be provided in order to obtain one or more of them.

These general and specific aspects can be implemented using a system, method, and computer program, and any combination of systems, methods, and computer programs.

BRIEF DESCRIPTION OF THE FIGURES

In the following, exemplary embodiments are described in more detail with reference to the attached figures and drawings.

FIG. 1 shows an exemplary 3GPP LTE system architecture,

FIG. 2 shows an exemplary downlink resource grid at a downlink slot of a subframe, as defined for 3GPP LTE (Revision 8/9),

FIG. 3 schematically illustrates how to create a layer-2 communication line through PC5 for ProSe communication,

FIG. 4 illustrates the use of transmission / reception resources for an overlap system (LTE) and a substrate (D2D),

FIG. 5 illustrates the transmission of Scheduling Assignment and D2D data for two UEs,

FIG. 6 illustrates D2D communication timing for UE autonomous Mode 2 scheduling,

FIG. 7 illustrates D2D communication timing for eNB-scheduled Mode 1 scheduling,

FIG. 8 illustrates an example architecture model for ProSe for a non-roaming scenario,

FIG. 9 illustrates an exemplary composition of a CAM message,

FIG. 10 illustrates the transmission of several different CAM components, with varying periodicities and message sizes, for three different speed ranges,

FIG. 11 illustrates the transmission of three different CAM components, as well as the use of three SPS configurations for CAM transmission in accordance with an exemplary implementation of the first embodiment,

FIG. 12 also illustrates the transmission of three different CAM components, as well as the use of three SPS configurations for CAM transmission in accordance with a further exemplary implementation of the first embodiment, where the radio resources allocated by the SPS configurations are combined together,

FIG. 13 also illustrates the transmission of three different CAM components, as well as the use of three SPS configurations for CAM transmission in accordance with a further exemplary implementation of the first embodiment, where the radio resources allocated by the corresponding SPS configuration are sufficient to transmit the complete CAM message, and

FIG. 14 also illustrates the transmission of three different CAM components, as well as the use of nine different SPS configurations for CAM transmission in accordance with a further exemplary implementation of the first embodiment, assuming that the vehicle UE supports three different speed ranges,

FIG. 15 also illustrates the transmission of three different CAM components, as well as the use of ten different SPS configurations for CAM transmission in accordance with a further exemplary implementation of the first embodiment, under the assumption that the vehicle UE supports three different speed ranges.

DETAILED DESCRIPTION

A mobile station or mobile node, or a user terminal or user equipment is a physical entity in a communication network. One node can have several functional objects. A functional object refers to a software or hardware module that implements and / or offers a predefined set of functions to other functional objects of a node or network. Nodes can have one or more interfaces that connect the node to a communication medium or medium through which the nodes can communicate. Similarly, a network entity may have a logical interface connecting a functional entity to a communication medium or medium through which it can communicate with functional entities or corresponding nodes.

The term "radio resources", used in the set of claims and in the application, should be understood in a broad sense as referring to physical radio resources, such as time-frequency resources.

The concept of “direct communication transmission” used in the application should be understood in a broad sense as transmission directly between two user equipments, i.e. not through a radio base station (e.g. eNB). Accordingly, direct communication transmission is performed through a “direct side-line connection”, which is a concept used for a connection created directly between two user equipments. For example, 3GPP uses D2D (Device-to-Device) communication terminology or ProSe communication, or side-line communication. The concept of “direct connection of the side line” should be understood in a broad sense and should be understood in the context of 3GPP as the PC5 interface described in the prerequisites section of the invention.

The concept of “ProSe” or in its unabbreviated form, “Proximity Services” used in the application, is used in the context of Proximity applications and services in the LTE system as explained as an example in the background section of the invention. Other terminology, such as “D2D”, is also used in this context to refer to Device-to-Device communications in relation to Proximity Services.

The term “vehicle mobile terminal”, used throughout the application, should be understood in the context of the new subject of research V2X (vehicle communication) 3GPP, as explained in the section of the premises of the invention. Accordingly, a mobile terminal of a vehicle should be understood in a broad sense as a mobile terminal, which is in particular installed in a vehicle (e.g., automobile, trucks, motorcycles, etc.) in order to communicate with the vehicles, i.e. passing information related to the vehicle to other objects (such as vehicles, infrastructure, pedestrians), for example, in order to ensure safety or help the driver. Optionally, the vehicle’s mobile terminal may have access to information available in the navigation system (provided that it is also installed on the car), such as map information, etc.

As explained in the background section of the invention, 3GPP has introduced a new research subject for LTE-enabled vehicle communications, which should be based on ProSe procedures in order to exchange V2V traffic between various mobile vehicle terminals and other stations. In addition, a semi-permanent allocation of radio resources should be supported by V2V traffic for the allocation of side-link Mode 1 in order to reduce the amount of scheduling to be performed by the eNB. However, these SPS mechanisms are not adapted for V2V traffic and its characteristics. For example, for conventional semi-persistent scheduling on a Uu link (i.e., between an eNB and a UE), the eNB receives QCI information (QoS class identifier) from the MME (Mobility Management Entity). The QCI information indicates that a specific medium configured between the eNB and the UE is configured to transport VoIP traffic, so that the eNB learns about the periodic traffic generated by the UE on the medium. The eNB can then configure a semi-permanent allocation of radio resources for the UE by sending RRC signaling to the UE to configure the frequency of the SPS. Then, when the UE is required to actually transmit VoIP data through the medium and transmit the corresponding Buffer Status Report indicating that there is data to be transmitted for VoIP traffic, the eNB will send the PDCCH to the UE to activate the SPS configuration, with the message The PDCCH also indicates which radio resources the UE is allowed to periodically use (thereby allocating a specific amount of radio resources). Accordingly, the UE uses SPS resources to periodically transmit VoIP traffic.

However, the eNB does not have knowledge of the type of traffic (e.g., frequency or message size) that will be transmitted to a specific vehicle UE via a side-link connection, so that it cannot correctly determine either the amount of resources to be allocated through a semi-permanent allocation of radio resources nor the frequency of these semi-permanent radio resources.

Even if the eNB somehow receives information regarding the traffic to be transmitted by the vehicle UE, it should be noted that the vehicle UE will have to transmit V2V traffic at different intervals and / or different message sizes, which is significantly different from the type of VoIP traffic for which the current SPS engine has been developed. In addition, the frequency with which V2V traffic is to be transmitted is variable because it can vary, for example, depending on the dynamics of the vehicle, such as the speed at which the vehicle is moving. As a result, the current standardized SPS mechanism is not enough to deal with these different V2V usage scenarios.

The following exemplary embodiments are formulated by the inventors to mitigate one or more of the problems that are explained above.

Specific implementations of the various embodiments should be implemented in a broad technical description, as defined by 3GPP standards and partially explained in the background section of the invention, with specific key features added as explained in the following regarding the various embodiments. It should be noted that the embodiments can be advantageously used, for example, in a mobile communication system such as 3GPP LTE-A communication systems (Edition 10/11/12/13), as described in the Technical Background of the Invention above (or later) editions), but embodiments are not limited to their use in these specific example communication networks.

The explanations should not be understood as limiting the scope of the disclosure, but merely as an example of embodiments in order to better understand the present disclosure. One of skill in the art should be aware that the general principles of the present disclosure, as set forth in the claims, can be applied to different scenarios and in ways that are not explicitly described in this document. To illustrate the objectives, several assumptions are made, which, however, should not limit the scope of the following embodiments.

A variety of embodiments mainly provide an improved procedure for the semi-permanent allocation of resources between the UEs (vehicles) and the eNB, which is responsible for the allocation of radio resources of the UEs (vehicles). As a result of this, other functionality (i.e., functionality that does not vary with the various embodiments) may remain exactly the same as explained in the background section of the invention or may be changed without any consequences for the various embodiments. This includes, for example, other procedures related to how the actual transmission of periodic data is performed by the vehicle UEs after the suitable semi-permanent radio resources are allocated to the vehicle UEs.

First Embodiment

In the following, the first embodiment for solving the above problems (s) will be described in detail. Various implementations and variations of the first embodiment will also be explained.

As an example, a vehicle UE is assumed that is installed in a vehicle and configured to communicate vehicles based on the D2D infrastructure, as explained in the background section of the invention. However, as will be explained in more detail later, the principles underlying the invention are not limited to applying only to vehicle UEs, but can also be implemented by conventional UEs (i.e., not related to vehicles), which for example, transmit periodic data via a Uu interface to an eNB or a PC5 interface (side link connection) to another UE. Whatever the case, in relation to the following discussion, it is assumed that this is a vehicle UE that needs to periodically transmit V2V data.

Additionally, it is assumed that the vehicle UE transmits (broadcasts) periodic data destined to other UEs (vehicles), although it is also possible that periodic data is transmitted to other UEs (vehicles) (via the PC5 interface), its eNB (via the Uu interface), Road Side Blocks (possibly via the PC5 interface) and / or other suitable stations for which periodic data transmitted by the vehicle UE is interesting; it may be assumed that the transmission from the UE of the vehicles is a point-to-multipoint type, thereby reaching all receiving objects in its area.

The periodic data to be transmitted by the vehicle UE will be exemplified by Joint Awareness Messages (CAMs), which are explained in detail in the background section of the invention. Characteristics of the CAMs that are relevant to the invention are consistent with the fact that CAMs are transmitted periodically. However, CAMs are significantly different from the usual VoIP scenario in semi-persistent planning scenarios in that there are different and even varying transmission frequencies and / or different message sizes (i.e., the amount of data to be transmitted and for which the transport UEs funds require radio resources). VoIP demonstrates a fixed periodicity and a fixed message size, which can be well processed through a semi-permanent allocation of radio resources.

It should be noted that CAMs are only an example of such periodic data, and that the invention can be applied to other types of data, as, however, and can be standardized further for communication between vehicles and non-vehicles. In particular, with regard to vehicle communications, it is likely that the vehicle UE should periodically broadcast (status and attribute) data with different and / or even varying periodicities, and therefore should transmit messages at different times with less or a large number of data, due to different periodicities.

As will be explained in detail below, CAM messages are a suitable example of this kind of periodic data, and will therefore be used to explain the first embodiment and its variants, although the invention is not limited to them, as already mentioned.

There are various CAM components (for example, HF CAM, LF CAM, the certificate will be CAM components, on the basis of which the invention will be explained in the following), the broadcast of which should be carried out periodically by the vehicle UE, but with different intervals. In the following, it is generally assumed that at a particular point in time, only one CAM message is transmitted / broadcast by means of a vehicle UE, and said CAM message, however, contains different CAM components that must be transmitted at that moment in time (t .e. CAM components that coincide with that point in time, despite the fact that they have different periodicities). In other words, in the case where different CAM components must be transmitted by the vehicle UE at the same time (SC period in the PC5 interface), the different CAM components are combined together to form a single CAM message, which is then transmitted. In order for the association to actually work, the periodicities of the various CAM components must be coordinated (i.e., be multiples of each other) so that the different CAM components really coincide at specific same points in time. Single CAMs are thus transmitted periodically, with a single periodicity (which is determined by the highest transmission frequency of the CAM components that must be transmitted (for example, the HF CAM component), but with different content and, therefore, message size (i.e. different CAM components are contained in single CAM messages at different points in time), where messages of different sizes also vary periodically (see, for example, Fig. 10 and the associated description). Thus, the mechanism for allocating radio resources requires different the amount of radio resources at different points in time.

Alternatively, it is also possible that different CAM components at different intervals are transmitted as separate CAM messages. This may be a disadvantage since more radio resources are required since each of the individual CAM messages may need to include at least a header and possibly also a main container (see Fig. 9 and related description), which is avoided in the first alternative by combining CAM components together. However, the provision of separate CAM messages has the advantage that avoiding the need to coordinate the different periodicities of the respective CAM components can be avoided, i.e. that the periodicities of the respective CAM components can be determined freely. In this case, CAM messages have different periodicities and different message sizes.

It should be noted that the 3GPP standardization has not yet fully agreed on the transmission frequency of the various CAM components, whether or not the association will be optional or mandatory, or in what way different CAM components will be transmitted. In any case, this may also change in future editions. The principles underlying the invention apply to any of these cases, even though minor adaptations may be required to take these changes into account.

In the following, it will mainly be assumed that at a particular point in time, only one CAM message is transmitted by the vehicle UEs, meaning that different CAM components will form a single CAM message.

In addition, it is expected that the required frequency of transmission of the CAM components can change rapidly over time as a function of vehicle dynamics, such as speed, heading, and / or angle; perhaps other factors may be determined in the future.

Briefly, the UE (vehicles) will transmit periodic data (e.g., CAM) to other receiving entities (e.g., other vehicle stations). In order to transmit periodic data, the vehicle UE requires radio resources, which can, for example, be allocated by the eNodeB, for example, in accordance with the allocation of ProSe Mode 1 radio resources, as explained in the background section of the invention. According to a first embodiment, the eNodeB allocates semi-permanent radio resources of the vehicle UEs, thereby allowing the vehicle UEs to transmit periodically pending periodic data.

In order to already present a brief overview, the first embodiment can conceptually be divided into a preparation phase and a execution phase. In the preparation phase, various SPS configurations will be configured by the eNodeB to transmit later periodic data that is supported by the vehicle UEs and which may thus be transmitted by the vehicle UEs in the future. The vehicle UE will be configured using a variety of different SPS configurations that can be activated during the execution phase, if necessary. The execution phase may be assumed to begin when the transmission of part or all of the supported periodic data begins by means of the UE of the vehicles. Accordingly, specific SPS configurations, from among the previously prepared SPS configurations, are activated in the UE and then used by the vehicle UE to transmit pending periodic data. During the execution phase, either the message size or the periodicity of the pending periodic data can change so that different SPS configurations, from among the previously prepared SPS configurations, must be activated in the vehicle UE so as to still be able to transmit periodic data at a different frequency or with different message size (s).

The preparation phase will now be explained in more detail. In order for the eNodeB to be able to configure the appropriate SPS configuration (s) for the periodic data supported by the UE, the eNodeB needs to know about the periodic data that may be transmitted to the vehicle UEs in the future. Typically, the SPS configuration distributes periodically (i.e., with periodic times) a specific amount of radio resources, which in turn depends on the amount of data that the UE needs to transmit (e.g., the size of the CAM message). Accordingly, the vehicle UE transmits information on the periodic data of the eNodeB so that the eNodeB is able to determine one or more different possible periodicities and / or different possible message sizes that may be transmitted to the vehicle UE in the future. Upon learning this information, the eNodeB is then able to configure many different SPS configurations in such a way that by activating later one or more of these SPS configurations for the vehicle UEs, the vehicle UEs are enabled to actually transmit one or more of the supported periodic data using radio resources periodically distributed through activated SPS configurations.

After thus configuring a plurality of SPS configurations, the eNodeB provides relevant information about the plurality of SPS configurations to the vehicle UE so that the vehicle UE is aware of the plurality of SPS configurations that may be activated in the future. The vehicle eNodeBs and UEs are thus prepared to process the transmission of one or more of the supported periodic data.

Now, the execution phase will be explained in more detail. It is then assumed that the vehicle UE will ultimately want to transmit some or all of the CAM data components, and thus it needs (semi-permanently distributed) radio resources to complete the transmission. Accordingly, the vehicle UE will inform the eNB about which CAM components it would like to transmit, and the eNB in response selects, from among the previously prepared SPS configurations, one or more SPS configurations that will allocate the appropriate resources of the vehicle UE so that transmit all of the currently awaiting CAM components. The eNB will then accordingly activate the selected one or more SPS configurations in the UE, for example, by transmitting a suitable activation command.

The vehicle UE accordingly activates specific SPS configurations as prescribed by the eNodeB, and thus can use the periodic radio resources scheduled by the activated SPS configurations in order to transmit the pending one or more CAM data components to other UEs (vehicles).

As explained above, according to the first embodiment, it is possible to allocate SPS resources for the vehicle UEs, even though the data to be transmitted by the vehicle UEs may have varying periodicities and / or varying message sizes. As a result of this, it is possible to reduce the signaling overhead on the Uu link between the eNodeB and the UE, which are otherwise necessary in order to repeatedly perform dynamic allocation of radio resources (for example, see the ProSe Mode 1 explanations in the background section of the invention) for each SC period. In addition, it is not necessary to transmit the Buffer Status Report used by the vehicle UE to indicate that (periodic) data is awaiting transmission from the UE to the eNB in order to trigger the eNB to allocate dynamic resources each time periodic data arrives on side of the UE.

FIG. 11 as an example illustrates that three different SPS configurations are activated to enable the transfer of three different CAM components (Certificate, LF CAM component, and HF CAM component) in accordance with an exemplary implementation of the first embodiment. For this exemplary implementation of the first embodiment, it is assumed that one SPS configuration is configured for one particular CAM data component. Accordingly, a vehicle UE that wishes to transmit three different CAM components can use the periodic radio resources allocated by the SPS configuration 1 to transmit the HF CAM component, can use the periodic radio resources distributed by the SPS configuration 2 to transmit the LPS CAM, and may use the periodic radio resources allocated by the SPS configuration 3 to transmit the certificate.

Depending on whether different CAM components are transmitted in the same message or in separate messages, different SPS configurations must be combined by the vehicle UEs in order to be able to transmit a larger combined CAM message or can be used separately to transmit separate CAM messages .

In the following, there will be more specific implementations of the first embodiment.

In the broad implementation of the first embodiment, it was simply assumed, without going into further details, that the vehicle UE would support the transmission of periodic data that contains one or more different data components that must be transmitted with different possible transmission frequencies and / or different possible sizes messages. As explained previously, the task of the SPS distribution mechanism of the first embodiment is that the transmission of vehicle data includes various possible periodicities and / or different message sizes. This will be explained in more detail based on the CAM messages presented in the background section of the invention.

According to one possible exemplary scenario, the vehicle UE supports the transmission of several CAM components, for example, an HF CAM component, an LF CAM component, and a security certificate. Accordingly, the possible message size differs depending on which CAM components are transmitted in the CAM message. An overview of the different possible message sizes is given in the following table:

CAM component The size of the resulting CAM message HF CAM component (including header, main container, signature and digest) 122 bytes HF CAM component + LF CAM component 182 bytes HF CAM component + LF CAM component + CAM security certificate 299 bytes HF CAM component + CAM security certificate 239 bytes

In relation to the above table, it is assumed that different CAM components transmitted at the same moment in time form one single CAM message so that the LF CAM component and the CAM security certificate are combined with the base HF CAM component, which is transmitted with the highest transmission frequency. Accordingly, the size of the message will vary with time, as listed in the right column of the table and as illustrated by way of example in FIG. 11 (due to the alleged different periodicities of the CAM components, FIG. 11 does not show the transmission of the HF CAM component + CAM security certificate; for this, see FIG. 10 middle portion).

Different CAM components must be transmitted at different intervals so that every possible CAM message that must be transmitted at a particular point in time will be transmitted at different intervals, as shown as an example in the following table:

CAM component The size of the resulting CAM message Transmission Frequency HF CAM component (including header, main container, signature and digest) 122 bytes Every 100ms HF CAM component + LF CAM component 182 bytes Every 500ms HF CAM component + LF CAM component + CAM security certificate 299 bytes Every 1000ms HF CAM component + CAM security certificate 239 bytes Every 1000ms

The transmission periodicity value assumed above actually refers to the periodicity of that CAM component in the CAM message with the lowest transmission frequency (for example, 500 ms for the LF CAM component for the CAM message containing the HF CAM and LF CAM components). The indicated transmission frequency should not be understood as the frequency of transmission of a specific CAM message. For example, a CAM message containing the HF CAM and LF CAM components is not actually transmitted every 500ms (but every 1000ms, see Fig. 11).

The exemplary values assumed in the table above for transmission frequency are those assumed for one vehicle speed range> 144 km / h, which is assumed to be only one supported vehicle UE.

According to another possible exemplary scenario, the vehicle UE only supports the transmission of one CAM component, for example, the HF CAM component, thus having an expected fixed size of 122 bytes (see table above) and an expected fixed frequency of 100ms (see table higher). However, a particular characteristic of V2V data is that the frequency of different CAM components can vary with the dynamics of the vehicle, for example, the speed at which the vehicle UE moves. Because of this, even though the UE of the vehicle supports the transmission of only one CAM component, the frequency with which one CAM component must be transmitted can vary in time, again leading to the fact that several periodicities must be taken into account by the SPS allocation mechanism. This is given as an example to the table below.

CAM component Resulting CAM Size Transmission frequency at speeds> 144km / h Frequency of transmission at a speed of [72, 144] km / h Frequency of transmission at a speed of [48, 72] km / h HF CAM component (including header, main container, signature and digest) 122 bytes Every 100ms Every 200ms Every 300ms

According to another possible exemplary scenario, the vehicle UE supports the transmission of a variety of CAM components (for example, all three components of the CAM, HF CAM, LF CAM, and security certificate) and in addition must support multiple speeds (ranges). The resulting varying frequency and size of the message will become apparent from the table below.

CAM component The size of the resulting CAM message Transmission frequency at speeds> 144km / h Frequency of transmission at a speed of [72, 144] km / h Frequency of transmission at a speed of [48, 72] km / h HF CAM component (including header, main container, signature and digest) 122 bytes Every 100ms Every 200ms Every 300ms HF CAM component + LF CAM component 182 bytes Every 500ms Every 600ms Every 600ms HF CAM component + LF CAM component + CAM security certificate 299 bytes Every 1000ms Every 1000ms Every 1200ms HF CAM component + CAM security certificate 239 bytes Every 1000ms Every 1000ms Every 1200ms

As an example above, there can be many different combinations of CAM components (left column of the table above) leading to different possible sizes of CAM messages (for example, 122 bytes, 182 bytes, 299 bytes, or 239 bytes) and leading to different possible intervals depending on the specific CAM component and / or possibly supported speeds (ranges) for the vehicle UE (e.g., 100ms, 200ms, 300ms, 500ms, 600ms, 1000ms, 1200ms). SPS configurations configured by the eNB during the preparation phase must take this into account and must coordinate the resulting CAM message transmission intervals and / or the resulting CAM message sizes supported by the vehicle UEs so that suitable SPS configurations can be activated later to allow the vehicle UE to transmit any (combination) of supported periodic data.

A variety of different SPS configurations are prepared by the eNodeB, as will be exemplified for the above selected examples. In particular, it is first assumed for simplicity that the vehicle UE supports the transmission of several CAM components, but supports only one speed range, for example, the highest speed range> 144 km / h, so that despite the fact that several different periodicities are taken into account, by themselves periodicities do not change over time (for example, due to a change in speed).

CAM component The size of the resulting CAM message Transmission Frequency SPS configurations HF CAM component (including header, main container, signature and digest) 122 bytes Every 100ms Configuration 1 SPS (122 bytes every 100ms) HF CAM component + LF CAM component 182 bytes Every 500ms Configuration 2 SPS (60 bytes every 500ms) HF CAM component + LF CAM component + CAM security certificate 299 bytes Every 1000ms 3 SPS configuration (117 bytes every 1000ms) HF CAM component + CAM security certificate 239 bytes Every 1000ms Separate SPS configuration not required

In the above exemplary implementation of the first embodiment, three different SPS configurations 1, 2, and 3 are configured by the eNodeB such that there is one separate SPS configuration that is consistent with each of the possible CAM components that the vehicle UE supports for transmission. It should be noted that for the possible combination of the HF CAM component and the CAM security certificate, in this particular example, a separate SPS configuration is not required, since this particular combination does not occur due to the approximate intervals assumed for individual CAM components.

SPS configuration 1 allocates specific radio resources sufficient to transmit 122 bytes of the HF CAM base component every 100ms, which is the frequency of the HF CAM component. Accordingly, the UE will use the periodic radio resources allocated by the SPS configuration 1 in order to transmit CAM messages containing the HF CAM component.

Moreover, SPS configuration 2 allocates specific radio resources sufficient to transmit 60 bytes of an additional (combinable) LF CAM component every 500ms, which is the frequency of the LF CAM component. Accordingly, the UE will use the periodic radio resources allocated by the SPS configuration 2 in order to transmit CAM messages containing the CAM LF component. In addition, SPS configuration 3 allocates specific radio resources sufficient to transmit 117 bytes of additional (merged) security certificate every 1000ms, which corresponds to the frequency of the security certificate. Accordingly, the UE will use periodic radio resources allocated through SPS configuration 3 in order to transmit CAM messages containing a security certificate.

FIG. 12 illustrates the use of three SPS configurations, as exemplified above, for transmitting CAM messages by vehicle UEs in accordance with an exemplary implementation of the first embodiment. As is apparent from FIG. 12, the three SPS configurations are consistent with three different data components to be transmitted by the vehicle UE. Dotted rectangles spanning multiple data components that must be transmitted at the same point in time should indicate that these different data components are transmitted as a single CAM message, as exemplified above. As is apparent from FIG. 12, at times where several CAM components are to be transmitted in a single CAM message, the vehicle UE combines the radio resources allocated through several SPS configurations so as to have sufficient radio resources to transmit the entire CAM message (i.e. including several CAM components). For example, when transmitting the HF CAM component together with the LF CAM component, the radio resources allocated through the SPS configurations 1 and 2 are combined (i.e., summed, used together) to thereby have sufficient radio resources available for transmission. Similarly, when transmitting the HF CAM component together with the LF CAM component, as well as the security certificate, the radio resources allocated through the SPS configurations 1, 2 and 3 are combined to thus have enough available radio resources to transmit all the combined CAM message.

As just explained, the radiocommunication resources allocated through different SPS configurations may need to be combined for those times where the vehicle UE must transmit large combined CAM messages. In accordance with the following alternative implementation of the first embodiment, this combination of radio resources allocated separately by SPS configurations is no longer required. Instead, individual SPS configurations are configured in such a way that they already take into account the resulting size of a single CAM message. In accordance with the discussion above, the following table will illustrate by way of example this alternative implementation of the first embodiment.

CAM component The size of the resulting CAM message Transmission Frequency SPS configurations HF CAM component (including header, main container, signature and digest) 122 bytes Every 100ms Configuration 1 SPS (122 bytes every 100ms) HF CAM component + LF CAM component 182 bytes Every 500ms Configuration 2 SPS (182 bytes every 500ms) HF CAM component + LF CAM component + CAM security certificate 299 bytes Every 1000ms 3 SPS configuration (299 bytes every 1000ms) HF CAM component + CAM security certificate 239 bytes Every 1000ms Separate SPS configuration not required

As is apparent from the table, the SPS configurations are different from the previous implementation in that the amount of radio resources allocated by the respective SPS configurations is larger, thereby taking into account the larger size of the CAM message when several CAM components are transmitted in a single CAM message.

In accordance with FIG. 12, FIG. 13 illustrates how different configurations are used by vehicle UEs to transmit periodic CAM data (components). At those times at which the vehicle UE must transmit several CAM components in a single CAM message, the vehicle UE must select that SPS configuration from among those activated that provides sufficient radio resources to transmit a larger CAM message. As in the previous exemplary implementation of the first embodiment, the vehicle UE will select an SPS configuration 1 in order to transmit a CAM message containing only the HF CAM component. On the other hand, when transmitting the HF CAM component together with the LF CAM component, radio resources are required to transmit a total of 182 bytes, so that the vehicle UE must select SPS configuration 2 and must use specific radio resources allocated through SPS configuration 2 in order to to transmit the aforementioned CAM message containing the HF CAM component, as well as the LF CAM component. Accordingly, when transmitting the HF CAM component together with the LF CAM component, as well as the security certificate, radio resources are required to transmit a total of 299 bytes so that the vehicle UE must choose 3 SPS configuration. The vehicle UE will thus use the specific radio resources allocated by the SPS configuration 3 in order to transmit the aforementioned CAM message containing three components.

The implementations discussed above of the first embodiment in accordance with FIG. 12 and FIG. 13 can also be applied to more complex cases where the vehicle UE also supports several speed ranges, for example, three estimated speed ranges of> 144, between 72 and 144, and between 48 72, resulting in additional distinct periodicities that must be maintained for the corresponding CAM components.

The following table assumes that the radio resources allocated through different SPS configurations can be combined by the vehicle UEs to collect enough radio resources to be able to transmit combined CAM messages containing several data components (see discussion for Fig. 12).

CAM component The size of the resulting CAM message Transmission Frequency SPS configurations for speeds> 144km / h SPS configurations for speed [72, 144] km / h SPS configurations for speed [48, 72] km / h HF CAM component (including header, main container, signature and digest) 122 bytes Every 100ms
Every 200ms
Every 300ms Configuration 1 SPS (122 bytes every 100ms) 4 SPS configuration (122 bytes every 200ms) Configuration 7 SPS (122 bytes every 300ms) HF CAM component + LF CAM component 182 bytes Every 500ms
Every 600ms Configuration 2 SPS (60 bytes every 500ms) 5 SPS configuration (60 bytes every 600ms) Configuration 8 SPS (60 bytes every 600ms) HF CAM component + LF CAM component + CAM security certificate 299 bytes Every 1000ms
Every 1200ms 3 SPS configuration (117 bytes every 1000ms) 6 SPS configuration (117 bytes every 1000ms) 9 SPS configuration (117 bytes every 1200ms) HF CAM component + CAM security certificate 239 bytes Every 1000ms
Every 1200ms Separate SPS configuration not required Separate SPS configuration not required Separate SPS configuration not required

As is evident from the above table, it is assumed that the eNodeB in the preparation phase configures 9 separate SPS configurations, respectively, allocating radio resources with a suitable frequency so that the vehicle UE, after activating later one or more SPS configurations, transmit the corresponding CAM components in a periodic manner.

Depending on the current speed of the vehicle UE, the eNodeB will configure the vehicle UE to either activate SPS configurations 1, 2 and 3 when the speed is> 144km / h, or activate SPS configurations 4, 5 and 6 when the speed is between 72 and 144 km / h, or activate SPS 7, 8 and 9 configurations when the speed is between 48 and 72 km / h.

FIG. 14 illustrates how 9 individual SPS configurations can be used by vehicle UEs to periodically transmit CAM messages of different sizes. The upper part of FIG. 14 (i.e., relating to a speed> 144 km / h) mainly corresponds to FIG. 12 and therefore will not be explained again. For a speed range between 72 and 144 km / h, FIG. 14 illustrates how a vehicle UE combines radio resources allocated through an activated configuration 4, 5, and 6 so as to be able to transmit CAM messages of different sizes. In particular, a CAM message composed of a HF CAM component, as well as a LF CAM component, can be transmitted by vehicle UEs by combining radio resources allocated by SPS configurations 4 and 5. A CAM message composed of all three components (HF CAM, LF CAM, Security Certificate) can be transmitted by the vehicle UEs by combining and using radio resources allocated through SPS configurations 4, 5 and 6. The CAM message composed of the HF CAM component, as well as the safety certificate, can be transmitted to the vehicle UEs by combining and using radio resources allocated via SPS configurations 4 and 6.

For a speed range between 48 and 72km / h, FIG. 14 illustrates how vehicle UEs combine radio resources allocated by activated SPS configurations 7, 8, and 9 to be able to transmit CAM messages of different sizes. In particular, the CAM message composed of the HF CAM component, as well as the LF CAM component, can be transmitted by the vehicle UEs by combining the radio resources allocated by the SPS configurations 7 and 8. A CAM message composed of all three components (HF CAM, LF CAM, Security Certificate) can be transmitted by the vehicle UEs by combining and using radio resources allocated through SPS configurations 7, 8 and 9.

In the following, an alternative implementation of the first embodiment, which has been explained in connection with FIG. 13, will now also be expanded to a vehicle UE that supports multiple speed ranges.

CAM component The size of the resulting CAM message Transmission Frequency SPS configurations for speeds> 144km / h SPS configurations for speed [72, 144] km / h SPS configurations for speed [48, 72] km / h HF CAM component (including header, main container, signature and digest) 122 bytes Every 100ms
Every 200ms
Every 300ms Configuration 1 SPS (122 bytes every 100ms) 4 SPS configuration (122 bytes every 200ms) Configuration 8 SPS (122 bytes every 300ms) HF CAM component + LF CAM component 182 bytes Every 500ms
Every 600ms Configuration 2 SPS (182 bytes every 500ms) 5 SPS configuration (182 bytes every 600ms) 9 SPS configuration (182 bytes every 600ms) HF CAM component + LF CAM component + CAM security certificate 299 bytes Every 1000ms
Every 1200ms Configuration 3 SPS (299 bytes every 1000ms) Configuration 6 SPS (299 bytes every 1000ms) 10 SPS configuration (299 bytes every 1200ms) HF CAM component + CAM security certificate 239 bytes Every 1000ms
Every 1200ms Separate SPS configuration not required Configuration 7 SPS (239 bytes every 1000ms) Separate SPS configuration not required

FIG. 15 illustrates the appropriate use of different SPS configurations by vehicle UEs in order to transmit various possible CAM messages. The upper part of FIG. 15 (relating to speed> 144km / h) mainly corresponds to FIG. 13 and therefore will not be explained again. In order to support the transmission of all possible CAM components for a speed range between 72 and 144 km / h, four different SPS configurations are configured via the eNodeB. Unlike the scenario for a speed range> 144 km / h, vehicle UEs need to transmit a CAM message composed of an HF CAM component and a CAM security certificate. In this alternative implementation of the first embodiment, the eNodeB must thus configure a separate SPS configuration for a given possible CAM message, i.e. 7 SPS configuration allocating special radio resources sufficient to transport 239 bytes every 1000ms. This SPS configuration 7 was optional in the previous implementation of the first embodiment, since the radio resources of SPS configurations 4 and 6 could be flexibly combined so as to allocate enough (but not so many) resources to transmit the CAM message composed of the CAM HF component as however, a safety certificate (see Fig. 14).

As repeatedly mentioned, several SPS configurations are prepared via the eNodeB to support different possible speed ranges over which the UE can move (as an example of vehicle dynamics that affects the frequency of various CAM data components). In such a scenario, the eNB also needs to be informed of the possible speed ranges by the vehicle UE, as this will affect the different periodicities that must be taken into account when preparing multiple SPS configurations. One option is to transfer explicit information about the speed ranges that are supported by the vehicle UEs to the eNB, for example, together or separately from the periodic data information, in order to allow the eNB to determine from them the resulting different periodicities of the periodic data components that should be considered when preparing multiple SPS configurations. Another option is that the vehicle UE transmits a variety of possible periodicities that also contain periodicities in the supported speed ranges, so it is not necessary for the UE to further inform the eNB of the supported speed ranges; The eNB can derive supported speed ranges from the various periodicities reported in the reports, assuming that the eNB has access to specific information allowing this association to be made, such as standardized definitions for the frequency of messages and CAM components in different speed ranges.

In addition, when the UE wants to actually start transmitting periodic data, the UE must inform the eNB of the current speed (or the speed range it is in), so that the eNB can select and activate those SPS configurations prepared for that specified speed range that UE vehicles are currently being tested. The current speed information may, for example, be transmitted by a vehicle together with or separately from indicating which data components of the vehicle UE would like to transmit. For example, an exemplary implementation of the first embodiment ensures that this indication is a buffer status report indicating that for specific logical channel groups, data is pending in the corresponding buffer in the UE. Accordingly, information about the current speed of the vehicle UE can also be transmitted in the buffer status report.

In addition, as mentioned before, the frequency of the CAM data components may depend on the dynamics of the vehicle, such as speed, which, however, may change over time. Additional implementations of the first embodiment, thus, allow you to change the activated SPS configurations depending on the current dynamics of the vehicle (for example, the speed of the UE of the vehicles). In this regard, the vehicle UE can monitor its own speed and can determine if the speed range has changed compared to the speed range in which it was previously. In this case, the vehicle UE may inform the eNodeB of this change in speed range. Alternatively, the vehicle UE may regularly transmit information about its current speed of the eNodeB so that the eNodeB itself can determine when a particular vehicle UE changes the speed range relevant to SPS configurations. In any case, changing the speed range can thus trigger the selection and activation of the eNodeB of other SPS configurations prepared for that specified speed range instead of the previously activated SPS configurations. A vehicle UE receiving such an activation command for modified SPS configurations will no longer use the previous activated SPS configurations, but will use the new activated SPS configurations.

According to another alternative implementation of the first embodiment, instead of transmitting the current speed or the current changed speed range of the eNodeB, the vehicle UE, when determining that it has changed a specific speed range, can actually identify the corresponding SPS configurations that are required for that changed speed range , and may send an eNodeB request to use these new SPS configurations due to a change in the speed range. In turn, the eNodeB accepts this request and can make a decision as to whether it should follow the request or not. Accordingly, it can determine that the change in SPS configurations is in order, and thus it accordingly transmits a response to the request in order to activate the requested SPS configurations. The vehicle UE will therefore no longer use the previous activated SPS configurations, but will now use the new activated SPS configurations.

When changing SPS configurations in a vehicle UE, as just explained due to a change in vehicle dynamics (e.g. speed), in accordance with one possible implementation of the first embodiment, the vehicle UE can always start by transmitting all of the CAM components (t i.e., a CAM message containing all CAM components) in order to avoid that some of the components are not transmitted due to frequent changes in speed and thus frequent changes to SPS configurations.

As explained above, the vehicle UE transmits eNB information on supported periodic data that the vehicle UE will possibly transmit in the future. As will be explained in detail with reference to the following implementations of the first embodiment, this can be implemented in a variety of ways. According to an exemplary implementation of the first embodiment, the vehicle UE may explicitly inform the eNodeB of the different possible periodicities and / or different possible message sizes of the CAM messages / components that the vehicle UE supports and thus may actually transmit in the future . For example, the periodic data information may thus include a list of possible periodicities and / or possible sizes of CAM messages that are supported by the vehicle UEs. The eNodeB is thus capable of preparing suitable SPS configurations for a variety of different supported periodicities and / or message sizes.

In accordance with the variants of this implementation of the first embodiment, information about the periodic data can be transmitted in one message or in at least two separate messages, in particular, information about the possible periodicities and possible sizes of the message can be transmitted in one message, for example , a message that is based on the SidelinkUEInformation message that is currently specified in the standards to indicate eNodeB side-line information (e.g., the frequency at which the UE is interested in transmitting the communication of the side communication line, as well as the recipients of the transmission of the communication of the side communication line for which the UE requests the assignment of the intended resources) (see 3GPP TS 36.331 v13.0.0 section 6.2.2, incorporated herein by reference). In the following, an exemplary extended SidelinkUEInformation message is determined in accordance with this implementation of the first embodiment.

SidelinkUEInformation Message

- ASN1START

SidelinkUEInformation-r12 :: = SEQUENCE {

criticalExtensions CHOICE {

c1 CHOICE {

sidelinkUEInformation-r12 SidelinkUEInformation-r12-IEs,

spare3 NULL, spare2 NULL, spare1 NULL

},

criticalExtensionsFuture SEQUENCE {}

}

}

SidelinkUEInformation-r12-IEs :: = SEQUENCE {

commRxInterestedFreq-r12 ARFCN-ValueEUTRA-r9

OPTIONAL,

commTxResourceReq-r12 SL-CommTxResourceReq-r12

OPTIONAL,

discRxInterest-r12 ENUMERATED {true}

OPTIONAL,

discTxResourceReq-r12 INTEGER (1..63)

OPTIONAL,

lateNonCriticalExtension OCTET STRING

OPTIONAL,

nonCriticalExtension SidelinkUEInformation-v13 × 0-IEs

OPTIONAL,

}

SidelinkUEInformation-v13 × 0-IEs :: = SEQUENCE {

commTxResourceReq121-r13 SL-CommTxResourceReqUC-r13

OPTIONAL,

commTxResourceInfoReqRelay-r13 SEQUENCE {

commTxResourceReqRelay-r13 SL-CommTxResourceReqUC-r13,

ue-Type-r13 ENUMERATED {relayUE, remoteUE}

}

OPTIONAL,

discTxResourceReq-v13 × 0 SEQUENCE {

carrierFreqDiscTx-r13 INTEGER (1..maxFreq),

discTxResourceReqAddFreq-r13 SL-DiscTxResourceReqPerFreqList-r13

OPTIONAL

}

OPTIONAL,

discTxResourceReqPS-r13 SL-DiscTxResourceReq-r13

OPTIONAL,

discRxGapReq-r13 SL-GapRequest-r13

OPTIONAL,

discTxGapReq-r13 SL-GapRequest-r13

OPTIONAL,

discSysInfoReportList-r13 SL-SysInfoReportList-r13

OPTIONAL,

nonCriticalExtension SEQUENCE {}

OPTIONAL,

}

SL-CommTxResourceReq-r12 :: = SEQUENCE {

carrierFreq-r12 ARFCN-ValueEUTRA-r9

OPTIONAL,

destinationInfoList-r12 SL-DestinationInfoList-r12

}

SL-CommTxResourceReqUC-r13 :: = SEQUENCE {

carrierFreq-r13 ARFCN-ValueEUTRA-r9

OPTIONAL,

destinationInfoListUC-r13 SL-DestinationInfoListUC-r13

}

SL-DiscTxResourceReqPerFreqList-r13 :: = SEQUENCE (SIZE (1..maxFreq)) OF SL-DiscTxResourceReq-r13

SL-DiscTxResourceReq-r13 :: = SEQUENCE {

carrierFreq-r13 ARFCN-ValueEUTRA-r9

OPTIONAL,

discTxResourceReq-r13 INTEGER (1..63)

}

SL-DestinationInfoList-r12 :: = SEQUENCE (SIZE (1..maxSL-Dest-r12)) OF SL-DestinationIdentity-r12

SL-DestinationIdentity-r12 :: = BIT STRING (SIZE (24))

SL-DestinationInfoListUC-r13 :: = SL-DestinationInfoList-r12

SL-SysInfoReportList-r13 :: = SEQUENCE (SIZE (1 .. maxSL-DiscSysInfoReportFreq-r13)) OF SL-SysInfoReport-r13

SidelinkUEInformation-v14 × 0-IEs :: = SEQUENCE {
commTXResourceReq121-r14 SL-CommTxResourceReq-14 OPTIONAL,
... ..}
SL-CommTxResourceReq-r14 :: = SEQUENCE {
carrierFreq-r14 ARFCN-ValueEUTRA-r9 Optional
destinationInfoListUC-r14 SL-DestinationInfoList-r14
SL-Traffic-r14 SL-TrafficList-r14 Optional
} SL-TrafficList-r14 :: = SEQUENCE (SIZE (1..maxSL-Traffic-r14)) OF
SL-TrafficType-r14 SL-TrafficType-r14 :: = SEQUENCE {
trafficType ENUMERATED {periodic, non-periodic}
periodicity ENUMERATED {
sf100, sf200, sf300, sf500,
sf600, sf1000, sf1200, spare10,
spare9, spare8, spare7, spare6,
spare5, spare4, spare3, spare2,
spare1},
messageSize INTEGER (1 ... 300)

Additional elements, exemplified by the SidelinkUEInformation message of this implementation of the first embodiment, are shown in bold and are also indicated in the box above. As is clear from this, there is a periodicity field that allows you to specify a variety of different periodicities, such as those mentioned above for CAM messages. Similarly, a message size field is provided that allows you to specify a variety of different message sizes, respectively with a value between 1 and 300 bytes. Optionally, the traffic type field allows the UE to inform the eNodeB whether the data is periodic or non-periodic.

Alternatively, instead of indicating the size (s) of the message along with possible periodicities, in accordance with an additional embodiment of the first embodiment, the size of the message (i.e., the amount of data that the UE wishes to transmit) is transmitted along with the Buffer Status Report, which indicates that the data is pending to be sent by the vehicle UE. In this case, in one example, in the preparation phase, the eNodeB will only receive information about the possible different periodicities, but not information about the possible different sizes, and will thus proceed to prepare different SPS configurations based on the information about the possible different periodicities. For example, the many SPS configurations prepared by the eNodeB will be different in terms of frequency, but will not be special in terms of how much and how much radio resources will be allocated through the SPS configuration. Then, at the moment at which the vehicle UE actually wants to start transmitting one or more possible data components, the corresponding buffer (s) will be filled, thereby initiating that a report on the status of the buffer should be transmitted to the eNodeB and, based on which, the eNodeB may actually determine the amount of data that the UE would like to transmit with respect to one or more possible data components. In response, the eNodeB will select and activate the appropriate appropriate SPS configurations (with appropriate suitable intervals), and then will activate the selected SPS configuration (s) for the vehicle UEs, while at the same time indicating for each activated SPS configuration which resources are allocated by the corresponding activated SPS configuration.

In other words, in contrast to the previously explained in connection with FIG. 11 to 15, in this particular embodiment of the first embodiment, the eNodeB does not yet indicate radio resources (for example, SPS configuration 1 defining radio resources sufficient to transmit 122 bytes), but merely indicates periodicity. For example, an eNodeB may prepare an SPS configuration 1 to support the transmission of an HF CAM component by vehicle UEs with a frequency of 100ms (assuming a speed range> 144km / h); similarly for other SPS configurations. In relation to the scenario that is intended for FIG. 12, the eNodeB will thus also prepare three distinct SPS configurations, namely for three periodicities each of 100ms, 500ms, and 1000ms, respectively. In relation to the scenario that is intended for FIG. 14, the eNodeB will prepare nine distinct SPS configurations, respectively three for each speed range.

According to another exemplary implementation of the first embodiment, the vehicle UE may inform the eNodeB about specific data components that the vehicle UE supports in order to transmit, in addition to or instead of transmitting information about different possible transmission frequencies and / or different possible message sizes. For example, the periodic data information may thus include a list identifying data components that the vehicle UE maintains in order to transmit in the future. The eNodeB has access to information on the possible periodicities and message sizes that are associated with these identified data components; for example, 3GPP standardization may explicitly indicate sizes and periodicities for various possible CAMs and their components. Thus, the eNodeB is therefore capable of preparing suitable SPS configurations for a variety of different supported periodicities and / or message sizes.

Although not described in detail above, the activation command transmitted by the eNodeB to the vehicle UE in order to activate the selected configurations may be implemented as an example transmitted as a message transmitted via the PDCCH, a physical downlink control channel. For example, in a similar fashion to the current specified SPS engine, the eNodeB may transmit one or more DCIs to activate one or more of the previously configured SPS configurations. In one example, a new C-RNTI can be used for DCI in relation to side-line activation / deactivation, since the UE needs to know that DCIs are for side-line SPSs, and not for SPS Uu or dynamic Uu link allocation. As mentioned above, with respect to specific implementations of the first embodiment, the PDCCH message can also identify specific radio resources that the UR supports in order to use for the activated SPS configuration (s).

Although not specified in detail above, the eNodeB, after having defined a plurality of SPS configurations, must inform the UE of the plurality of SPS configurations. This can, for example, be implemented as an RRC message, such as sps-ConfigSidelink in a radioResourceConfigDedicated message. The current SPS configuration for the Uu link is transmitted in the radioResourceConfigDedicated message. To indicate SPS configurations for the side link, a new element can be created as sps-ConfigSidelink, which can also be transmitted in the radioResourceConfigDedicated message. As explained above, many SPS configurations configured by the eNodeB in the preparation phase can, for example, identify both frequency and radio resources, or can only identify periodicity (where radio resources can then be identified with the activation command transmitted from the eNodeB to UE).

Although implementations of the first embodiment have been explained based on V2V and vehicle UEs in communication with other vehicle UEs via a side-line connection, the underlying principles of the first embodiment can also be applied to transfer vehicle data between vehicle UEs means and, for example, the eNodeB via the Uu interface or between the vehicle UE and the Road Side Unit via, for example, the PC5 interface.

In addition, although the implementations of the first embodiment have been explained based on the vehicle UEs, the underlying principles of the first embodiment can also be implemented by “normal” UEs that are in communication with the eNB or other “normal” UEs or vehicle UEs via a side link connection (s).

Implementation in the Hardware and Software of this Disclosure

Other exemplary embodiments relate to the implementation of the various embodiments described above using hardware, software, or software in combination with hardware. In this regard, a user terminal (mobile terminal) is provided. The user terminal is configured to perform the methods described herein, including corresponding objects, to participate appropriately in the methods, such as receiver, transmitter, processors.

Additionally, it should be borne in mind that various embodiments can be implemented or performed using computing devices (processors). A computing device or processor may, for example, be general-purpose processors, digital signal processors (DSPs), problem-oriented integrated circuits (ASICs), programmable gate arrays (FPGAs), or other programmable logic devices, etc. A variety of embodiments may also be implemented or embodied by a combination of these devices. In particular, each function block used in the description of each embodiment described above can be implemented by LSI as an integrated circuit. They may be individually formed as chips, or one chip may be formed to include part or all of the functional blocks. They may include data input and output tools associated with them. LSI in this document may be referred to as IC, LSI systems, super LSI, or ultra LSI, depending on differences in the degree of integration. However, the methodology for implementing the integrated circuit is not limited to LSI and can be implemented using a dedicated circuit or general-purpose processor. In addition, an FPGA (Programmable Gate Array) can be used, which can be programmed after manufacturing the LSI, or a reconfigurable processor in which the connections and settings of the circuit cells located inside the LSI can be reconfigured.

In addition, various embodiments may also be implemented by software modules that are executed by a processor or directly in hardware. Also, a combination of software modules and hardware implementations is possible. The software modules can be stored on any type of computer-readable storage media, for example, RAM, EPROM, EEPROM, flash memory, registers, hard drives, CD-ROM, DVD, etc. Additionally, it should be noted that the individual characteristics of different embodiments may individually or in arbitrary combination be the subject of another embodiment.

One of skill in the art would appreciate that numerous variations and / or modifications may be made with respect to the present disclosure, as shown in particular embodiments. As a consequence, the present embodiments should be considered in all respects as illustrative and not restrictive.

Regulation 1. A mobile terminal of a vehicle for transmitting periodic data to one or more receiving entities, the mobile terminal of a vehicle supporting the transmission of periodic data containing one or more different data components that must be transmitted with different possible transmission frequencies and / or different possible the size of the messages, while the mobile terminal of the vehicle contains:

a transmitter configured to transmit periodic data information to a radio base station responsible for allocating radio resources to a mobile terminal of a vehicle, the transmitted periodic data information allowing the radio base station to determine different possible transmission frequencies and / or different possible message sizes of one or more Periodic data components

a receiver configured to receive from the radio base station multiple configurations of semi-permanent radio resources configured by the radio base station based on received periodic data information, each of the multiple configurations of semi-permanent radio resources being adapted to be used to transmit at least one of the supported data components, this

the transmitter is further configured to indicate to the radio base station that one or more of the data components will be transmitted by the mobile terminal of the vehicle,

the receiver is further configured to receive an activation command from a radio base station to activate one or more of a plurality of configurations of semi-permanent radio resources to periodically allocate radio resources to a mobile terminal of a vehicle for transmitting each of said data components, and

the transmitter is further configured to transmit one or more data components to one or more receiving entities based on radio resources and transmission frequency, as configured by activated one or more configurations of semi-permanent radio resources.

Regulation 2. The mobile terminal of the vehicle in accordance with Regulation 1, while the transmitted information about the periodic data contains:

information about part or all of the different possible transmission frequencies and / or different possible message sizes of one or more data components, optionally information about the message size of at least one data component to be transmitted by the vehicle’s mobile terminal is transmitted by the mobile terminal a vehicle together with a buffer status report that indicates that the data is pending to be transmitted for one data component, or

information about different data components, allowing the radio base station to determine different possible transmission frequencies and / or different possible message sizes based on received information about different possible data components.

Regulation 3. The mobile terminal of the vehicle according to Regulation 1 or 2, in which the transmitter is further configured to transmit information about the vehicle’s parameters, such as speed supported by the mobile terminal of the vehicle, to the radio base station, wherein the vehicle’s parameter information is used by the base a radiocommunication station for determining various possible transmission intervals of one or more supported data components, and

the transmitter is further configured to transmit information about vehicle parameters that are currently being tested by the vehicle’s mobile terminal to the radio base station, wherein the current vehicle parameters are used by the radio base station to select one or more of a plurality of configurations of semi-permanent radio resources for them activation, while optionally information about the current vehicle parameters is transmitted to location indicating that one or more data components should be transmitted by the mobile terminal of the vehicle.

Regulation 4. The mobile terminal of the vehicle according to Regulation 3, in which, when one of the vehicle’s parameters changes by more than a predetermined threshold value, the transmitter is additionally configured to transmit information about the changed vehicle parameters to the radio base station, and the receiver is made with the ability to receive a further activation command from a radio base station in response to activate other configurations of semi-permanent radio resources ligature instead of the previously activated semipermanent radio resources configurations, or

when one of the vehicle’s parameters changes by more than a predetermined threshold value, the transmitter is further configured to request activation of the configurations of semi-permanent radio resources, others with respect to previously activated configurations of semi-permanent radio resources, from the radio base station, and the receiver is configured to receive from the radio base station in response to an additional activation command to activate these other requested semi configurations permanent radio resources instead of previously activated configurations of semi-permanent radio resources, and

the transmitter is further configured to transmit one or more data components based on radio resources and transmission frequency, as configured by other configurations of semi-permanent radio resources,

while optionally an additional activation command is received in the message through the Physical Control Channel Downlink (PDCCH).

Regulation 5. The mobile terminal of the vehicle according to any one of Provisions 1-4, wherein the information on the periodic data is transmitted in one message, or the information on the periodic data is transmitted in at least two separate messages, and optionally information on different possible the periodicity of one or more supported data components is transmitted in the first message and information about the message size of at least one data component to be transmitted by the mobile ter Inal vehicle transmitted from the mobile terminal of the vehicle together with the report of the buffer status indicating that the data of one data component are waiting to be sent.

Position 6. The mobile terminal of the vehicle according to any one of Positions 1-5, wherein each of the received multiple configurations of semi-permanent radio resources identifies:

radio resources and frequency suitable for transmitting at least one of the supported data components, optionally multiple configurations of semi-permanent radio resources are received in a Radio Resource Control (RRC) protocol message, or

the frequency for transmitting at least one of the data components, moreover, information about the radio resources used by the mobile terminal of the vehicle to transmit at least one of the data components is received together with the activation command to activate one or more of the many configurations of semi-permanent radio resources, when optionally, an activation command and radio resource information are received in a message through a Physical Downlink Control Channel (PDCCH).

Regulation 7. The mobile terminal of the vehicle according to any one of Provisions 1-6, while the data components that must be transmitted at the same time are transmitted either as a single message or as separate messages.

Regulation 8. A mobile terminal of a vehicle according to any one of Provisions 1-7, wherein the receiving entities comprise other mobile terminals of the vehicles or mobile terminals not related to the vehicles, and periodic data is transmitted via the side line connection, and / or the receiving entities contain a radio base station and periodic data is transmitted via a radio connection.

Clause 9. The mobile terminal of the vehicle according to any one of Claims 1-8, wherein the plurality of configurations of semi-permanent radio resources are configured such that there is one configuration of semi-permanent radio resources for each data component with a specific message size and a specific transmission frequency, or

wherein the data components transmitted at the same time are transmitted as a single message, and the plurality of configurations of semi-permanent radio resources are configured such that there is one configuration of semi-permanent radio resources for each possible message containing one or more of the data components that must be transmitted by the mobile terminal of the vehicle, and optionally, the transmitter is configured to transmit a message containing these one or more data items, based on the activated configuration of semi-permanent radio resources corresponding to the data components contained in the message to be transmitted.

Regulation 10. A radio base station for allocating radio resources to a mobile terminal of a vehicle for transmitting periodic data to one or more receiving entities, the mobile terminal of the vehicle supporting transmitting periodic data containing one or more different data components that must be transmitted with different possible transmission frequencies and / or various possible message sizes, while the radio base station contains:

a receiver configured to receive from the mobile terminal of the vehicle information about the periodic data to be transmitted by the mobile terminal of the vehicle to one or more receiving objects,

a processor configured to determine different supported data components and different possible transmission frequencies and / or different possible message sizes of one or more data components,

wherein the processor is configured to configure a plurality of configurations of semi-permanent radio resources based on said specific transmission frequencies and / or said specific message sizes, wherein each of the plurality of configurations of semi-permanent radio resources is adapted to be used to transmit at least one of the supported data components,

a transmitter configured to transmit information about a configured plurality of configurations of semi-permanent radio resources to a mobile terminal of a vehicle,

the receiver is further configured to receive from the vehicle’s mobile terminal an indication that one or more of the data components should be transmitted by the vehicle’s mobile terminal,

wherein the processor is further configured to select one or more of a plurality of configurations of semi-permanent radio resources to be activated for a mobile terminal of a vehicle in order to periodically allocate radio resources to a mobile terminal of a vehicle for transmitting each of said data components, and

the transmitter is further configured to transmit an activation command to the vehicle’s mobile terminal to activate the selected one or more configurations of semi-permanent radio resources for the vehicle’s mobile terminal.

Regulation 11. The radio base station according to Regulation 10, while the received information about the periodic data contains:

information about a part or all different possible transmission frequencies and / or different possible message sizes of one or more data components, optionally information about the message size of at least one data component to be transmitted by the vehicle’s mobile terminal is received from the mobile a vehicle terminal together with a buffer status report that indicates that the data is pending to be transmitted for one data component, or

information about different data components, while the processor is further configured to determine different possible transmission frequencies and / or different possible message sizes based on the received information about different possible data components.

Regulation 12. The radio base station according to Regulation 10 or 11, in which the receiver is further configured to receive information about vehicle parameters, such as speed, supported by the vehicle’s mobile terminal from the vehicle’s mobile terminal, and the processor is further configured to determine different possible frequency of transmission of one or more supported data components based on the reception of information about the vehicle parameters, and

the receiver is further configured to receive information from the vehicle’s mobile terminal about vehicle parameters that are currently being tested by the vehicle’s mobile terminal, the processor being further configured to select one or more of a plurality of configurations of semi-permanent radio resources to activate them based on receiving current vehicle parameters, while optionally information about the current parameters of the vehicle a means is received from the mobile terminal of the vehicle along with an indication that one or more components of data to be transmitted by the mobile terminal of the vehicle.

Regulation 13. The radio base station according to Regulation 12, in which the receiver is configured to receive information about the changed vehicle parameters from the mobile terminal of the vehicle, and the processor is configured to select, based on the changed parameters, other configurations of semi-permanent radio resources instead of previously selected and activated configurations of semi-permanent radio resources, and the transmitter is configured to transmit an additional activation command to abundant vehicle terminal to activate the selected other configurations semipermanent radio resources, or

the receiver is configured to receive a request from the vehicle’s mobile terminal to activate configurations of semi-permanent resources of radio communication, other with respect to previously activated configurations of semi-permanent resources of uplink communication, and the processor is configured to determine whether to activate these other configurations of semi-permanent resources of radio communication , and, in the positive case, the transmitter is configured to transmit additionally to the vehicle’s mobile terminal tion activation command to activate said other configurations requested semipermanent radio resources instead of the previously activated configurations semipermanent radio resources,

in this case, optionally, an additional activation command is transmitted in the message through the Physical Control Channel Downlink (PDCCH).

Regulation 14. The radio base station according to any one of Provisions 10-13, and from the configured and transmitted multiple configurations of semi-permanent communication resources, identifies:

radio resources and frequency suitable for transmitting at least one of the supported data components, optionally multiple configurations of semi-permanent radio resources are transmitted in a Radio Resource Management (RRC) protocol message, or

periodicity for transmitting at least one of the data components, moreover, information about the radio resources used by the mobile terminal of the vehicle to transmit at least one of the data components is transmitted by the transmitter together with an activation command to activate one or more of the many configurations of semi-permanent radio resources, while in an optional activation command and information on radio resources are transmitted in a message through the Physical Control Channel Downlink (PDCC H).

Regulation 15. A radio base station according to any one of Provisions 10-14, wherein a plurality of configurations of semi-permanent radio resources are configured such that there is one configuration of semi-permanent radio resources for each data component with a specific message size and a specific transmission frequency, or

wherein the data components transmitted by the vehicle’s mobile terminal at the same time are transmitted as one message, and the plurality of configurations of semi-permanent radio resources are configured such that there is one configuration of semi-permanent radio resources for each possible message containing one or more of the components data to be transmitted by the mobile terminal of the vehicle, so that the mobile terminal of the vehicle transmits a message containing its one or more data components, based on an activated configuration of semi-permanent radio resources corresponding to the data components contained in the message to be transmitted.

Claims (65)

1. A mobile device of a vehicle for transmitting data via a device-to-device communication (D2D data communications) to one or more receiving objects, the mobile device comprising: a transmitter that, during operation, transmits information about D2D data transmissions with different possible transmission frequencies and / or different possible message sizes to a radio base station responsible for allocating radio resources to a vehicle’s mobile device, wherein the transmitted D2D data transmissions contributes to the radio base station in determining different possible transmission frequencies and / or different possible message sizes of one or more D2D data transmissions, a receiver that, when operating, receives from the radio base station a plurality of configurations of semi-permanent radio resources configured by the radio base station based on the received information about D2D data transmissions, each of the multiple configurations of semi-permanent radio resources is adapted to be used for at least one of the D2D data transmissions, and which, when operating, receives an activation command from a radio base station to activate one or more of a variety of configurations semi-permanent radio resources to periodically allocate radio resources to the mobile device of the vehicle for each of the D2D data transmissions, and while the transmitter during operation performs one or more D2D data transmissions to one or more receiving objects based on radio resources and transmission frequencies, as configured by activated one or more configurations of semi-permanent radio resources. 2. The mobile device of the vehicle according to claim 1, while the transmitted information about D2D data transmissions contains at least one of: information about part or all of the different possible transmission frequencies and / or different possible sizes of one or more D2D data transmissions, and information about different D2D data transmissions, assisting the radio base station in determining different possible transmission frequencies and / or different possible message sizes based on received information about different possible D2D data transmissions. 3. The vehicle’s mobile device according to claim 1, wherein the transmitter is further configured to transmit vehicle parameter information, such as speed, supported by the vehicle’s mobile device to the radio base station, wherein the vehicle parameter information is used by the radio base station to determine the different possible transmission intervals of one or more D2D data transmissions, and the transmitter is additionally configured to transmit information about the vehicle parameters that are currently being tested by the vehicle’s mobile device to the radio base station, wherein the current vehicle parameters are used by the radio base station to select one or more of a plurality of configurations of semi-permanent radio resources for their activation. 4. The vehicle’s mobile device according to claim 3, in which, when one of the vehicle’s parameters changes by more than a predetermined threshold value, the transmitter is further configured to transmit information about the changed vehicle parameters to the radio base station, and the receiver is configured with the ability to receive a further activation command from the radio base station in response to activate other configurations of semi-permanent radio resources instead of the previously active Semi-permanent radio resource configurations, or when one of the vehicle’s parameters changes by more than a predetermined threshold value, the transmitter is further configured to request activation of the configurations of semi-permanent radio resources, others with respect to previously activated configurations of semi-permanent radio resources, from the radio base station, and the receiver is configured to receive from the radio base station in response to an additional activation command to activate these other requested semi configurations permanent radio resources instead of previously activated configurations of semi-permanent radio resources, and wherein the transmitter is further configured to transmit one or more D2D data transmissions based on radio resources and transmission frequency, as configured by other configurations of semi-permanent radio resources, however, an additional activation command is received in the message through the Physical Control Channel Downlink (PDCCH). 5. The mobile device of the vehicle according to claim 1, wherein the information on D2D data transmissions is transmitted in a single message, or wherein information on D2D data transmissions is transmitted in at least two separate messages, moreover, information on different possible periodicities of one or more D2D data transmissions is transmitted in the first message and information on the message size of at least one D2D data transmission to be transmitted by mobile by the vehicle’s device, transmitted by the vehicle’s mobile device together with a buffer status report indicating that the data from this one of the D2D data transmissions is pending before achie. 6. The mobile device of the vehicle according to claim 1, wherein each of the received multiple configurations of semi-permanent radio resources identifies: radio resources and periodicity suitable for transmitting at least one of the D2D data transmissions, wherein a plurality of configurations of semi-permanent radio resources are received in a Radio Resource Management (RRC) protocol message, or the periodicity for transmitting at least one of the D2D data transmissions, wherein information on the radio resources used by the vehicle’s mobile device to transmit at least one of the D2D data transmissions is received together with an activation command to activate one or more of a plurality of configurations of semi-permanent radio resources while the activation command and information about the radio resources are received in the message through the Physical Control Channel Downlink (PDCCH). 7. The mobile device of the vehicle according to claim 1, wherein the D2D data transmissions of the data to be transmitted at the same time are transmitted either as a single message or as separate messages. 8. The mobile device of a vehicle according to claim 1, wherein the receiving objects comprise other mobile devices of the vehicles or mobile devices not related to the vehicles, and the data transmission data D2D is transmitted via the side line connection, and / or the receiving objects contain the base a radio station and data transmission data D2D are transmitted via a radio connection. 9. The vehicle mobile device of claim 1, wherein the plurality of configurations of semi-permanent radio resources are configured such that there is one configuration of semi-permanent radio resources for each D2D data transmission with a specific message size and a specific transmission frequency, or wherein, the data transmission D2D transmitted at the same time is transmitted as one message, and the plurality of configurations of semi-permanent radio resources are configured such that there is one configuration of semi-permanent radio resources for each possible message containing one or more of D2D data transmissions to be transmitted by the mobile device of the vehicle, wherein the transmitter is configured to transmit a message containing one or more data transmission data D2D to based on an activated configuration of semi-permanent radio resources corresponding to data transmission data D2D contained in the message to be transmitted. 10. A radio base station for allocating radio resources to a mobile device of a vehicle for transmitting D2D data transmissions to one or more receiving entities, the radio base station comprising: a receiver that, when operating, receives information on D2D data transmissions from various possible transmission frequencies and / or different possible message sizes transmitted from the vehicle’s mobile device to one or more receiving objects from the vehicle’s mobile device, a circuit that, when operating, determines different possible transmission frequencies and / or different possible message sizes of one or more D2D data transmissions, and which, when operating, configures a plurality of configurations of semi-permanent radio resources based on said specific transmission frequencies and / or said specific message sizes, each of the many configurations of semi-permanent radio resources adapted to be used to transmit at least one of the D2D data transmissions . a transmitter that, when operating, transmits information about a configured plurality of configurations of semi-permanent radio resources to a mobile device of a vehicle, wherein said operation circuit selects one or more of a plurality of configurations of semi-permanent radio resources to be activated for the vehicle’s mobile device to periodically allocate radio resources to the vehicle’s mobile device for transmitting each of the D2D data transmissions, and while the transmitter, when operating, transmits an activation command to the vehicle’s mobile device to activate the selected one or more configurations of semi-permanent radio resources for the vehicle’s mobile device. 11. The radio base station of claim 10, while the received information about D2D data transmissions contains at least one of: information about part or all of the different possible transmission frequencies and / or different possible message sizes of one or more D2D data transmissions, and information about different D2D data transmissions, wherein said circuit is further configured to determine different possible transmission frequencies and / or different possible message sizes based on the received information about different possible D2D data transmissions. 12. The radio base station of claim 10, wherein the receiver is further configured to receive information about vehicle parameters, such as speed, supported by the vehicle’s mobile device from the vehicle’s mobile device, said circuit being further configured to determine various possible the frequency of transmitting one or more D2D data transmissions based on the reception of vehicle parameter information, and the receiver is further configured to receive information about vehicle parameters that are currently being tested by the vehicle’s mobile device from the vehicle’s mobile device, the circuit being further configured to select one or more of a plurality of configurations of semi-permanent radio resources to activate them based on the received current vehicle parameters. 13. The radio base station of claim 12, wherein the receiver is configured to receive information about the changed vehicle parameters from the vehicle’s mobile device, and said circuit is configured to select, based on the changed parameters, other configurations of semi-permanent radio resources instead of previously selected and activated configurations of semi-permanent radio resources, and the transmitter is configured to transmit an additional activation command to the mobile device TVO vehicle to activate the selected other configurations semipermanent radio resources, or the receiver is configured to receive a request from the vehicle’s mobile device to activate configurations of semi-permanent radio resources, other with respect to previously activated configurations of semi-permanent resources of the uplink, said circuit being configured to determine whether to activate these other configurations of semi-permanent radio resources or no, and, in the positive case, the transmitter is configured to transmit transport media to the mobile device Twa additional activation command to activate said other configurations requested semipermanent radio resources instead of the previously activated configurations semipermanent radio resources, however, an additional activation command is transmitted in the message through the Physical Control Channel Downlink (PDCCH). 14. The radio base station of claim 10, wherein each of the configured and transmitted multiple configurations of semi-permanent communication resources identifies: radio resources and frequency suitable for transmitting at least one of the D2D data transmissions, wherein a plurality of configurations of semi-permanent radio resources are transmitted in a Radio Resource Management (RRC) protocol message, or the frequency for transmitting at least one of the D2D data transmissions, wherein information on the radio resources used by the vehicle’s mobile device to transmit at least one of the D2D data transmissions is transmitted by the transmitter together with an activation command to activate one or more of the many semi-permanent configurations radio resources, wherein the activation command and information on radio resources are transmitted in a message through the Physical Channel Downlink Control (PDCCH). 15. The radio base station of claim 10, wherein the plurality of configurations of semi-permanent radio resources are configured such that there is one configuration of semi-permanent radio resources for each D2D data transmission with a specific message size and a specific transmission frequency, or wherein the data transmission data D2D transmitted by the vehicle’s mobile device at the same time is transmitted as one message, and the plurality of configurations of semi-permanent radio resources are configured such that there is one configuration of semi-permanent radio resources for each possible message containing one or more D2D data transmissions of data to be transmitted by the mobile device of the vehicle, so that the mobile device of the vehicle transmits community s, comprising the one or more data D2D data transmission, based on the activated configuration semipermanent radio resources appropriate D2D data transmission data contained in the message to be transmitted. 16. A method for a mobile device of a vehicle for transmitting data via a device-to-device (D2D data communications) communication to one or more receiving entities, the method comprising the steps of: transmit information on D2D data transmissions with different possible transmission frequencies and / or different possible message sizes to a radio base station responsible for allocating radio resources to a mobile device of the vehicle, and the transmitted information on D2D data transmissions helps the radio base station to determine different possible transmission intervals and / or various possible message sizes of one or more D2D data transmissions; receiving from the radio base station a plurality of configurations of semi-permanent radio resources configured by the radio base station based on the received information on D2D data transmissions, each of the plurality of configurations of semi-permanent radio resources being adapted to be used for at least one of the D2D data transmissions; receiving an activation command from the radio base station to activate one or more of a plurality of configurations of semi-permanent radio resources to periodically allocate radio resources to the vehicle’s mobile device for each of the D2D data transmissions; and perform one or more D2D data transmissions to one or more receiving entities based on radio resources and transmission frequencies, as configured by activated one or more configurations of semi-permanent radio resources. 17. A method for a radio base station for allocating radio resources to a mobile device of a vehicle for transmitting D2D data transmissions to one or more receiving entities, the method comprising the steps of: receive from the mobile device of the vehicle information about D2D data transmissions with different possible transmission frequencies and / or different possible message sizes transmitted by the mobile device of the vehicle to one or more receiving objects; determining different possible transmission frequencies and / or different possible message sizes of one or more D2D data transmissions; configuring a plurality of configurations of semi-permanent radio resources based on said specific transmission frequencies and / or said specific message sizes, wherein each of the plurality of configurations of semi-permanent radio resources is adapted to be used for transmitting at least one of D2D data transmissions; transmitting information about the configured plurality of configurations of semi-permanent radio resources to the mobile device of the vehicle; selecting one or more of a plurality of configurations of semi-permanent radio resources to be activated for the vehicle’s mobile device to periodically allocate radio resources to the vehicle’s mobile device for transmitting each of the D2D data transmissions; and transmitting the activation command to the mobile device of the vehicle to activate the selected one or more configurations of semi-permanent radio resources for the mobile device of the vehicle. 18. An integrated circuit that, when operating, controls the process of a vehicle’s mobile device for transmitting data via a device-to-device (D2D data transfer) communications to one or more receiving entities, the process comprising: transmitting information about D2D data transmissions with different possible transmission frequencies and / or different possible message sizes to a radio base station responsible for allocating radio resources to a mobile device of the vehicle, and the transmitted information about D2D data transmissions helps the radio base station to determine different possible transmission intervals and / or various possible message sizes of one or more D2D data transmissions, receiving, from a radio base station, a plurality of configurations of semi-permanent radio resources configured by a radio base station based on received information about D2D data transmissions, each of a plurality of configurations of semi-permanent radio resources being adapted to be used for at least one of the D2D data transmissions, receiving, from a radio base station, an activation command to activate one or more of a plurality of configurations of semi-permanent radio resources to periodically allocate radio resources to a vehicle’s mobile device for each of the D2D data transmissions, and performing one or more D2D data transmissions to one or more receiving entities based on radio resources and transmission frequencies, as configured by activated one or more configurations of semi-permanent radio resources. 19. An integrated circuit that, when operating, controls the process of a radio base station to allocate radio resources to a mobile device of a vehicle for transmitting D2D data transmissions to one or more receiving entities, the process comprising: receiving, from the vehicle’s mobile device, information about D2D data transmissions with different possible transmission frequencies and / or different possible message sizes transmitted by the vehicle’s mobile device to one or more receiving objects, determining different possible transmission frequencies and / or different possible message sizes of one or more D2D data transmissions, configuring a plurality of configurations of semi-permanent radio resources based on said specific transmission frequencies and / or said specific message sizes, wherein each of the plurality of configurations of semi-permanent radio resources is adapted to be used for transmitting at least one of D2D data transmissions, transmitting information about the configured set of configurations of semi-permanent radio resources to the mobile device of the vehicle, selecting one or more of a plurality of configurations of semi-permanent radio resources to be activated for the vehicle’s mobile device to periodically allocate radio resources to the vehicle’s mobile device for transmitting each of the D2D data transmissions, and transmitting the activation command to the mobile device of the vehicle to activate the selected one or more configurations of semi-permanent radio resources for the mobile device of the vehicle.

Images