JP6909913B2 - Improved semi-persistent resource allocation for V2V traffic - Google Patents

Description

The present disclosure relates to improved semi-persistent resource allocation between mobile terminals and radio base stations. The present disclosure provides an integrated circuit that controls the processing of the corresponding (vehicle) mobile terminal.

<Long Term Evolution (LTE)>
Third-generation mobile communication systems (3Gs) based on WCDMA® wireless access technology are being deployed on a wide scale around the world. As the first step in enhancing, developing, or evolving this technology, both High-Speed Downlink Packet Access (HSDPA) and High Speed Uplink Packet Access (HSUPA) An enhanced uplink called is introduced to provide extremely competitive wireless access technology.

In order to meet the ever-increasing demand from users and to secure competitiveness for new wireless access technologies, 3GPP has introduced a new mobile communication system called Long Term Evolution (LTE). LTE is designed to meet carrier needs for high-speed data and media transmission and high-capacity voice support over the next decade. The ability to provide high bitrates is an important strategy in LTE.

Work item (Wite) related to long-term evolution (LTE) called advanced UMTS Terrestrial Radio Access (UTRA) and UMTS Terrestrial Radio Access Network (UTRAN). The specification has been finalized as Release 8 (LTE Release 8). LTE systems represent packet-based efficient radio access and radio access networks that provide full IP-based functionality with low latency and low cost. In LTE, multiple scalable systems such as 1.4MHz, 3.0MHz, 5.0MHz, 10.0MHz, 15.0MHz, and 20.0MHz are used to achieve flexible system deployments using a given spectrum. The transmit bandwidth is specified. The downlink has inherent resistance to multipath interference (MPI) due to its low symbol rate, the use of cyclic prefixes (CPs), and various transmit bandwidth sequences. Due to its good compatibility, Orthogonal Frequency Division Multiplexing (OFDM) -based wireless access has been adopted. In the uplink, considering that the transmission power of the user equipment (UE: User Equipment) is limited, it is prioritized to provide a wide area coverage rather than improving the peak data rate, so that the single carrier frequency is used. Radio access based on split multiple access (SC-FDMA: Single-carrier frequency division access) has been adopted. LTE Release 8/9 employs many major packet radio access technologies, including multiple-input multiple-output (MIMO) channel transmission technology, to achieve a highly efficient control signaling structure. ..

<LTE architecture>
FIG. 1 shows the entire LTE architecture. The E-UTRAN consists of an eNodeB and provides termination of the E-UTRA user plane (PDCP / RLC / MAC / PHY) and control plane (RRC) protocols towards the user equipment (UE). The eNodeB (eNB) is a physical (PHY) layer, a medium access control (MAC) layer, a radio link control (RLC) layer, including functionality for header compression and encryption of the user plane. And hosts the Packet Data Control Protocol (PDCP) layer. The eNodeB (eNB) also provides radio resource control (RRC) functionality corresponding to the control plane. eNodeB (eNB) provides radio resource management, admission control, scheduling, implementation of uplink quality of service (QoS) by negotiation, cell information broadcasting, encryption / decryption of user plane data and control plane data, It also performs many functions, including compressing / restoring downlink / uplink user plane packet headers. The eNodeBs are interconnected by an X2 interface.

In addition, a plurality of eNodeBs are connected to EPC (Evolved Packet Core) by S1 interface, more specifically, to MME (Mobility Management Entity) by S1-MME, and by S1-U. It is connected to a serving gateway (SGW: Serving Gateway). The S1 interface supports a many-to-many relationship between the MME / serving gateway and the eNodeB. The SGW serves as a mobility anchor for the user plane during handover between eNodeBs and as an anchor for mobility between LTE and other 3GPP technologies (terminating the S4 interface and between the 2G / 3G system and the PDN GW. It also functions as a relay for traffic), while routing and forwarding user data packets. For idle user equipment, the SGW terminates the downlink data path and triggers paging when the downlink data for that user equipment arrives. The SGW manages and stores the context of the user equipment, such as IP bearer service parameters, or network internal routing information. The SGW also replicates user traffic in the case of lawful intercept.

The MME is the primary control node for LTE access networks. The MME is responsible for tracking and paging procedures for user equipment in idle mode, including retransmissions. The MME is involved in the bearer activation / deactivation process and is responsible for selecting the SGW for the user equipment during initial attachment and intra-LTE handover with core network (CN) node relocation. Also bears. The MME is responsible for authenticating the user (by interacting with the HSS). Non-access layer (NAS) signaling is terminated in the MME, which also plays a role in generating a temporary ID and assigning it to the user device. The MME checks the authorization of the user equipment to camp on the service provider's Public Land Mobile Network (PLMN) and enforces roaming restrictions on the user equipment. The MME is the end point in the network for the encryption / integrity protection of NAS signaling and handles the management of security keys. Legal interception of signaling is also supported by MME. MME also provides a control plane function for mobility between LTE access networks and 2G / 3G access networks, as well as an S3 interface terminated by MME from SGSN. The MME also terminates the S6a interface to the home HSS for roaming user equipment.

個のサブキャリアと

個のＯＦＤＭシンボルのリソースグリッドによって記述される。

は、帯域幅内のリソースブロックの数である。

は、セルにおいて設定されているダウンリンク送信帯域幅に依存し、

を満たし、この場合、

および

は、それぞれ、現在のバージョンの仕様によってサポートされている最小ダウンリンク帯域幅および最大ダウンリンク帯域幅である。

は、１つのリソースブロック内のサブキャリアの数である。通常のサイクリックプレフィックスのサブフレーム構造の場合、

および

である。 <Component carrier structure in LTE>
The downlink component carriers of the 3GPP LTE system are further 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, the first downlink slot contains a control channel region (PDCCH region) within the first OFDM symbol. .. Each subframe is composed of a given number of OFDM symbols in the time domain (12 or 14 OFDM symbols in 3GPP LTE (Release 8)), and each OFDM symbol extends over the bandwidth of the component carrier. Thus, each OFDM symbol is composed of several modulation symbols transmitted on its respective subcarriers. In LTE, the signal transmitted in each slot is

With subcarriers

Described by a resource grid of OFDM symbols.

Is the number of resource blocks in the bandwidth.

Depends on the downlink transmit bandwidth set in the cell,

Meet, in this case,

and

Are the minimum and maximum downlink bandwidths supported by the current version of the specification, respectively.

Is the number of subcarriers in one resource block. For a normal cyclic prefix subframe structure

and

Is.

Assuming a multi-carrier communication system that uses OFDM, for example, as used in 3GPP Long Term Evolution (LTE), the minimum unit of resources that can be allocated by the scheduler is one "resource block". ". As illustrated in FIG. 2, a physical resource block (PRB) is a continuous OFDM symbol (for example, 7 OFDM symbols) in the time domain and a continuous subcarrier (for example, 12 component carriers) in the frequency domain. Defined as (subcarriers). Thus, in 3GPP LTE (Release 8), the physical resource block is composed of resource elements and corresponds to 180 kHz in one slot and frequency domain in the time domain (more details on the downlink resource grid can be found at http: /. Available at www. 3gp.org and incorporated herein by reference, see, eg, Section 6.2 of the current version 13.0.0 of Non-Patent Document 1).

One subframe consists of two slots, so there are 14 OFDM symbols in the subframe when the so-called "normal" CP (cyclic prefix) is used, and the so-called "extended" CP There are 12 OFDM symbols in the subframe when used. For technical purposes, the same continuous subcarrier-equivalent time-frequency resource that spans the entire subframe is referred to below as a "resource block pair" or a synonymous "RB pair" or "PRB pair".

The term "component carrier" refers to a combination of several resource blocks in the frequency domain. In future releases of LTE, the term "component carrier" will no longer be used, instead the terminology will be changed to "cell" to refer to a combination of downlink resources and optionally uplink resources. The link between the carrier frequency of the downlink resource and the carrier frequency of the uplink resource is shown in the system information transmitted on the downlink resource.

Similar assumptions about the component carrier structure apply to later releases.

<Carrier aggregation in LTE-A to support wider bandwidth>
At the World Radiocommunication Conference 2007 (WRC-07), the frequency spectrum of IMT-Advanced was determined. Although the overall frequency spectrum for IMT-Advanced has been determined, the actual available frequency bandwidth will vary by region and country. However, following the decision on the outline of the available frequency spectra, standardization of wireless interfaces has begun in the 3rd Generation Partnership Project (3GPP). At the 3GPP TSG RAN # 39 meeting, the description of the items to be examined regarding "Further Advances for E-UTRA (LTE-Advanced)" was approved. This study item covers, for example, the technical elements to be considered in the evolution and development of E-UTRA in order to meet the requirements of IMT-Advanced.

The LTE system can only support 20 MHz, while the LTE-Advanced system can support 100 MHz. Today, the lack of wireless spectrum has become a bottleneck in the development of wireless networks, and as a result, it is difficult to find a sufficiently wide spectral band for LTE-Advanced systems. As a result, there is an urgent need to find a way to obtain a wider radiospectral band, and a possible answer is carrier aggregation functionality.

In carrier aggregation, two or more component carriers are aggregated to support a wider transmit bandwidth of up to 100 MHz. Several cells in the LTE system are aggregated into one wider channel in the LTE-Advanced system, which channel is wide enough for 100 MHz even when these cells are in different frequency bands within LTE.

At the very least, all component carriers can be configured to be LTE Release 8/9 compatible when the bandwidth of the component carriers does not exceed the supported bandwidth of the LTE Release 8/9 cells. Not all component carriers aggregated by the user equipment need to be Release 8/9 compatible. Existing mechanisms (eg, burring) may be used to prevent the release 8/9 user equipment from camping on the component carrier.

User devices may simultaneously receive or transmit on one or more component carriers (corresponding to multiple serving cells), depending on their capabilities. LTE-A release 10 user equipment with receive and / or transmit capabilities for carrier aggregation can receive and / or transmit simultaneously on multiple serving cells, while LTE release 8 The / 9 user equipment can only receive and transmit on one serving cell as long as the component carrier structure complies with the Release 8/9 specifications.

Carrier aggregation is supported for both continuous and discontinuous component carriers, with each component carrier having up to 110 resource blocks in the frequency domain (using 3GPP LTE (Release 8/9) numerology). Limited to.

Set up 3GPP LTE-A (Release 10) compatible user equipment to aggregate different numbers of component carriers from the same eNodeB (base station) and in some cases with different bandwidths on the uplink and downlink. It is possible to do. The number of downlink component carriers that can be configured depends on the downlink aggregation capability of the UE. Conversely, the number of uplink component carriers that can be configured depends on the uplink aggregation capability of the UE. It may currently not be possible to configure mobile terminals with more uplink component carriers than downlink component carriers. In a typical TDD deployment, the number of component carriers and the bandwidth of each component carrier are the same for the uplink and downlink. Component carriers from the same eNodeB do not have to provide the same coverage.

The distance between the center frequencies of the continuously aggregated component carriers shall be a multiple of 300 kHz. This is to maintain compatibility with the 3GPP LTE (Release 8/9) 100 kHz frequency raster while maintaining the orthogonality of the subcarriers at 15 kHz intervals. Depending on the aggregation scenario, n × 300 kHz spacing can be facilitated by inserting a small number of unused subcarriers between successive component carriers.

The effect of aggregating multiple carriers only extends to the MAC layer. For both uplinks and downlinks, one HARQ entity is required in the MAC for each aggregated component carrier. There is at most one transport block per component carrier (without SU-MIMO for uplinks). The transport block and possibly its HARQ retransmissions need to be mapped to the same component carrier.

When carrier aggregation is set, the mobile terminal has only one RRC connection to the network. When establishing / reestablishing an RRC connection, as in LTE Release 8/9, one cell provides security inputs (one ECGI, one PCI, and one ARFCN) and non-access layer mobility information (eg TAI). offer. After establishing / reestablishing the RRC connection, the component carrier corresponding to the cell in question is referred to as a downlink primary cell (PCell). In the connected state, the only downlink PCell (DL PCell: Downlink PCell) and the only uplink PCell (UL PCell: Uplink PCell) are always set for each user device. Within the set of configured component carriers, the other cells are called secondary cells (SCell), and the carriers of the SCell are the downlink secondary component carrier (DL SCC) and the uplink secondary component carrier (DL SCC). It is called a carrier (UL SCC: Uplink Secondary Component Carrier). Up to five serving cells including PCell can be set for one UE.

<MAC layer / entity, RRC layer, physical layer>
The LTE Layer 2 user plane / control plane protocol stack includes four sublayers RRC, PDCP, RLC and MAC. The medium access control (MAC) layer is the lowest sublayer within the Layer 2 architecture of the LTE radio protocol stack, as defined, for example, by the current version 13.0.0 of Non-Patent Document 2. Connections to lower physical layers go through transport channels, and connections to higher RLC layers go through logical channels. Therefore, the MAC layer performs multiplexing and multiplex separation between the logical channel and the transport channel, that is, the transmitting MAC layer is known as a transport block from the MAC SDU received via the logical channel. The MAC PDU is constructed, and the receiving MAC layer restores the MAC SDU from the MAC PDU received via the transport channel.

The MAC layer provides a data transmission service for the RLC layer via a logical channel (see Sections 5.4 and 5.3 of Non-Patent Document 2 incorporated herein by reference). The logical channel is either a control logical channel that conveys control data (eg, RRC signaling) or a traffic logical channel that conveys user plane data. On the other hand, data from the MAC layer is exchanged with the physical layer via the transport channel, and the transport channel is classified as downlink or uplink. The data is multiplexed into transport channels depending on how it is transmitted wirelessly.

The physical layer is responsible for the actual transmission of data and control information over the air interface, i.e., the physical layer conveys all information from the MAC transport channel through the transmitting air interface. Some of the key functions that the physical layer performs are encoding and modulation, link adaptation (AMC), power control, cell search (for initial synchronization and handover purposes) and other measurements for the RRC layer (LTE). In-system and inter-system). The physical layer executes transmission based on transmission parameters such as a modulation method, a coding rate (that is, a modulation / coding method, MCS: modulation and coding scene), and the number of physical resource blocks. Detailed information about the functionality of the physical layer is described in the current version 13.0.0 of Non-Patent Document 3, which is incorporated herein by reference.

The radio resource control (RRC) layer controls the communication between the UE and the eNB on the radio interface and the mobility of the UE moving across several cells. The RRC protocol also supports the transmission of NAS information. For UEs in the RRC_IDLE state, the RRC supports notification of incoming calls from the network. RRC connection control provides paging, measurement settings and notifications, radio resource settings, initial security activation, and establishment of a signaling radio bearer (SRB) and a radio bearer (data radio bearer, DRB: Data) that carries user data. It covers all procedures for establishing, modifying and releasing RRC connections, including establishing a Radio Bearer.

The radio link control (RLC) sublayer primarily provides ARQ functionality and supports data segmentation and concatenation, i.e. the RLC layer makes the RLC SDU the size indicated by the MAC layer. Framing the SDU. The latter two minimize protocol overhead, regardless of data rate. The RLC layer is connected to the MAC layer via a logical channel. Each logical channel carries a different type of traffic. The layer above the RLC layer is usually the PDCP layer, but can also be the RRC layer, namely the logical channels BCCH (Broadcast Control Channel), PCCH (Paging Control Channel) and RRC messages transmitted on the CCCH (Common Control Channel) do not require security protection and therefore bypass the PDCP layer and enter the RLC layer directly. The main services and functions of the RLC sublayer include:
-Transmission of higher layer PDUs that support AM, UM or TM data transmission-Error correction through ARQ-Segment according to TB size-When needed (eg wireless quality, ie supported TB) Re-segmentation (when size changes) -SDU concatenation for the same wireless bearer is FFS-Ordered delivery of PDUs in higher layers-Duplicate detection-Protocol error detection and recovery-SDU discard- The ARQ functionality provided by Reset RLC will be discussed in more detail later.

<Uplink access method for LTE>
Uplink transmission requires power-efficient transmission of user equipment to maximize coverage. Single-carrier transmission in combination with FDMA with dynamic bandwidth allocation has been selected as the evolved UTRA uplink transmission method. The main reasons why single-carrier transmission is preferred are the low peak-to-average power ratio (PAPR) compared to multicarrier signals (OFDMA), and the efficiency and improvement of the corresponding improved power amplifiers. Coverage (higher data rate for a given terminal peak power). During each time interval, eNodeB allocates the user a unique time / frequency resource for transmitting user data, thereby ensuring intra-cell orthogonality. Orthogonal access on the uplink ensures increased spectral efficiency by eliminating intra-cell interference. Interference caused by multipath propagation is handled by the base station (eNodeB) with the help of inserting cyclic prefixes into the transmitted signal.

The basic physical resource used for data transmission consists of a frequency resource of size BWgrant during one time interval, eg, a subframe, and the encoded information bits are mapped to that frequency resource. It should be noted that the subframe, also referred to as the transmission time interval (TTI), is the minimum time interval for user data transmission. However, by subframe concatenation, it is possible to allocate the frequency resource BWgrant to the user for a longer period than one TTI.

<Layer 1 / Layer 2 control signaling>
L1 / L2 control signaling is used to inform the scheduled user of the user's allocation status, transport format, and other transmission-related information (eg, HARQ information, transmit power control (TPC) command). It is sent downlink with the data. The L1 / L2 control signaling is multiplexed with the downlink data within the subframe, assuming that the user allocation can change on a subframe basis. It should be noted that user allocation can also be performed on a TTI (Transmission Time Interval) basis, in which case the TTI length can be a multiple of the subframe. The TTI length can be fixed for all users within the service area, different for different users, or even dynamic for each user. In general, L1 / 2 control signaling only needs to be transmitted once per TTI. Without loss of generality, the following assumes that TTI is one subframe.

The L1 / L2 control signaling is transmitted on the physical downlink control channel (PDCCH: Physical Downlink Control Channel). The PDCCH conveys a message as downlink control information (DCI), which in most cases contains resource allocation and other control information for a group of mobile terminals or UEs. Several PDCCHs can be transmitted within one subframe.

In general, information transmitted within L1 / L2 control signaling to allocate uplink or downlink radio resources (particularly LTE (-A) Release 10) can be classified into the following items:

-User identification information: Indicates the user to be assigned. This is usually included in the checksum by masking the CRC with user identification information.
-Resource allocation information: Indicates the resource to which the user is allocated (for example, resource block (RB)). Alternatively, this information is referred to as resource block allocation (RBA). Note that the number of RBs that can be assigned a user can be dynamic.
-Carrier indicator: Used when the control channel transmitted on the first carrier allocates resources associated with the second carrier, i.e. resources on the second carrier or resources associated with the second carrier. (Cross carrier scheduling).
-Modulation / coding method: Determines the modulation method and code rate to be adopted.
-HARQ information: New data indicator (NDI: new data indicator) and / or redundant version (RV), etc., which are particularly useful when retransmitting a data packet or part thereof.
-Power control command: Adjusts the transmission power of the uplink data or control information transmission to be allocated.
-Reference signal information: Applicable cyclic shift and / or orthogonal cover code index, etc. used to transmit or receive the reference signal in connection with the allocation.
-Uplink Allocation Index or Downlink Allocation Index: Used to identify the order of allocation and is especially useful in TDD systems.
-Hopping information: For example, instructional information on whether and how to apply resource hopping to increase frequency diversity.
-CSI request: Used to trigger the transmission of channel state information in the allocated resource.
-Multi-cluster information: Indicates and controls whether transmissions occur in a single cluster (a set of consecutive RBs) or in a multi-cluster (a set of at least two discontinuous, consecutive RBs). The flag used for. Multi-cluster allocation was introduced with 3GPP LTE- (A) Release 10.

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

Downlink control information occurs in several formats, which also differ in overall size and the information contained in the fields described above. The different DCI forms currently defined for LTE are as follows: Section 5.3.3.1 of Non-Patent Document 4 (current version 13.0.0 is http: /www.3gpp. It is available in org and is incorporated herein by reference). For example, the following DCI Format can be used to convey a resource grant for the uplink.

-Format 0: DCI Form 0 is used for sending resource grants for PUSCH, using single antenna port transmission in uplink transmit mode 1 or 2.

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

The current version 13.0.0 of Non-Patent Document 4 defines control information for sidelinks in section 5.4.3, which is incorporated herein by reference.

<Semi-persistent scheduling (SPS)>
In the downlink and uplink, resources are dynamically allocated to the user equipment via the L1 / L2 control channel (PDCCH) at each transmission time interval by scheduling the eNodeB, and in the L1 / L2 control channel (PDCCH). , User devices are addressed via their unique C-RNTI. As already mentioned above, the CRC of the PDCCH is masked by the C-RNTI of the addressed user device (so-called dynamic PDCCH). Only user equipment with a matching C-RNTI can correctly decode the contents into the PDCCH, i.e. the CRC check is useful. This type of PDCCH signaling is also referred to as a dynamic (scheduling) grant. The user equipment monitors the L1 / L2 control channel for dynamic grants at each transmission time interval to find possible allocations (downlinks and uplinks) to which it is allocated.

The E-UTRAN can also allocate uplink / downlink resources for initial HARQ transmission to the persistent. If requested, retransmissions are explicitly signaled via the L1 / L2 control channel. Because retransmissions are dynamically scheduled, this type of operation is called semi-persistent scheduling (SPS), that is, resources are allocated to user equipment on a semi-persistent basis (semi-persistent resource allocation:). semi-persistent resource allocation). The advantage is that PDCCH resources for initial HARQ transmission are saved. Semi-persistent scheduling can be used in Release 10 PCells, but not in SCells.

An example of a service that can be scheduled using semi-persistent scheduling is Voice over IP (VoIP). During the talk spurt, the codec generates VoIP packets every 20 ms. As such, the eNodeB can allocate uplink or individually downlink resources to persistents every 20 ms, so that the resources can be used for the transmission of voice-over IP packets. In general, semi-persistent scheduling is beneficial to services with predictable traffic behavior, ie, constant bit rate, periodic packet arrival times.

The user equipment also monitors the PDCCH in the subframe, which is allocated resources to the persistent for initial transmission. A dynamic (scheduled) grant, i.e. a PDCCH with a CRC masked by C-RNTI, can override the semi-persistent resource allocation. If the user device finds its own C-RNTI on the L1 / L2 control channel in the subframe of the user device with the allocated semi-persistent resource, this L1 / L2 control channel allocation is the transmission time. Overriding persistent resource allocation for intervals, user equipment just follows dynamic grants. If the user device does not find the dynamic grant, it sends / receives according to the semi-persistent resource allocation.

The setting of semi-persistent scheduling is done by RRC signaling. For example, the periodicity of persistent allocation, eg PS_PERIOD, is signaled within radio resource control (RRC) signaling. Persistent allocation activation and exact timing as well as physical resources and transport format parameters are transmitted via PDCCH signaling. When semi-persistent scheduling is activated, the user equipment follows semi-persistent resource allocation per PS_PERIOD according to SPS activated PDCCH. In essence, the user equipment stores the contents of the SPS-activated PDCCH and follows the PDCCH with signaled periodicity.

Individual identification information has been introduced to distinguish dynamic PDCCH from PDCCH that activates semi-persistent scheduling (also referred to as SPS-activated PDCCH). Basically, the CRC of the SPS activated PDCCH is masked by this additional identifier, hereinafter referred to as SPS C-RNTI. The size of SPS C-RNTI is also 16 bits, which is the same as that of normal C-RNTI. Furthermore, the SPS C-RNTI is also user device specific, that is, each user device configured for semi-persistent scheduling is assigned a unique SPS C-RNTI.

If the user equipment detects that the semi-persistent resource allocation has been activated by the corresponding SPS-activated PDCCH, the user equipment stores the contents of the PDCCH (ie, semi-persistent resource allocation) and semi-persistent. It is applied at each scheduling interval, i.e. the periodicity signaled via the RRC. As already mentioned, dynamic allocation, that is, the allocation signaled on the dynamic PDCCH, is only a "one-time allocation". Retransmission of SPS allocation is also signaled using SPS C-RNTI. An NDI bit (new data indicator: new data indicator) is used to distinguish SPS activation from SPS retransmission. SPS activation is indicated by setting the NDI bit to 0. The SPS PDCCH with the NDI bit set to 1 indicates a retransmission for a semi-persistently scheduled initial transmission.

Similar to activating semi-persistent scheduling, eNodeB can also deactivate semi-persistent scheduling, also referred to as SPS resource release. There are several options for how semi-persistent scheduling deallocation can be signaled. One option is to use PDCCH signaling with some PDCCH fields set to some predetermined value, i.e. SPS PDCCH indicating zero size resource allocation. Another option is to use MAC control signaling.

Below, additional information is provided on how the eNB knows if the UE will send periodic data and when to somehow set up the SPS settings.

When a new bearer is established, according to the dedicated bearer activation procedure of Non-Patent Document 5, the MME receives a bearer session request (EPS Bearer Identity), EPS bearer Quality (EPS Bearer). QoS), Session Management Request, S1-TEID) messages are signaled to eNodeB. eNodeB maps EPS bearer quality of service to wireless bearer quality of service (Radio Bearer quality of service). The eNodeB then signals the RRC Connection Reconfiguration (radio bearer QoS, session management request, EPS RB Identity) message to the UE.

The EPS bearer QoS profile includes the parameters QCI, ARP, GBR and MBR. Each EPS bearer (GBR and non-GBR) is associated with the following bearer level QoS parameters.

-Quos Class Identifier (QCI: QoS Class Identifier)
-Allocation and Retention Priority (ARP)
The QCI is a scalar used as a reference to access node-specific parameters that control bearer-level packet forwarding processing (eg, scheduling weights, allow thresholds, queue management thresholds, link-layer protocol settings, etc.). It is preset by the operator who owns the access node (for example, eNodeB). The one-to-one mapping of standardized QCI values to standardized properties is based on that found in Non-Patent Document 6, which incorporates Non-Patent Document 6 as shown in the table below.

As is clear from the table, a QCI value of 1 corresponds to "conversational voice" or voice over IP (VoIP). When the eNB receives a "bearer configuration request" message with a QCI value of 1, the eNB configures the SPS configuration for this bearer to be established for VoIP and the UE to allocate periodic resources to send VoIP data. It turns out that it can be applied.

<LTE device-to-device (D2D) neighborhood service (ProSe)>
Neighborhood-based applications and services represent emerging social-technical trends. The identified areas include commercial and security related services of interest to businesses and users. The introduction of Prose capabilities in LTE will enable the 3GPP industry to serve this evolving market while at the same time serving the urgent needs of some security communities entrusted to LTE in solidarity.

Device-to-device (D2D) communication is a technology component introduced by LTE Release 12 that allows D2D to increase spectral efficiency as an underlay for cellular networks. For example, if the cellular network is LTE, all physical channels that carry data use SC-FDMA for D2D signaling. In D2D communication, user devices use cellular resources to transmit data signals to each other through direct links instead of going through radio base stations. Throughout the invention, the terms "D2D", "ProSe" and "sidelink" are interchangeable.

D2D communication in LTE focuses on two areas: Discovery and Communication.

ProSe (Proxicity-based Service) Direct Discovery is a ProSe-enabled UE that uses an E-UTRA direct radio signal to connect other ProSe-enabled UEs via a PC5 interface. It is defined as the procedure used to discover nearby.

In D2D communication, instead of going through a base station (BS), UEs use cellular resources to send data signals to each other through direct links. The D2D user communicates directly while under the control of the BS, that is, at least within the coverage of the eNB. Therefore, D2D can improve system performance by reusing cellular resources.

D2D is expected to operate in the uplink LTE spectrum (in the case of FDD) or uplink subframe (in the case of TDD, other than outside the coverage) of the cell providing coverage. Furthermore, D2D transmission / reception does not use full duplex on a given carrier. From the point of view of the individual UE, a given carrier D2D signal reception and LTE uplink transmission do not use full duplex, i.e., D2D signal reception and LTE UL transmission are not possible at the same time.

In D2D communication, when one particular UE 1 plays a transmitting role (transmitting user equipment or transmitting terminal), the UE 1 transmits data and another UE 2 (receiving user equipment) receives it. UE1 and UE2 can exchange roles for transmission and reception. Transmission from UE1 can be received by one or more UEs such as UE2.

<ProSe direct communication layer 2 link>
Briefly, ProSe direct one-to-one communication is achieved by establishing a secure Layer 2 link between the two UEs via PC5. Each UE is contained in the source Layer 2 ID field of every frame that the UE sends on the Layer 2 link, and in the destination Layer 2 ID of every frame that the UE receives on the Layer 2 link, unicast. It has a layer 2 ID for communication. The UE needs to ensure that the Layer 2 ID for unicast communication is at least locally unique. Therefore, UEs should be prepared to handle Layer 2 ID conflicts with neighboring UEs using unspecified mechanisms (eg, for unicast communication when conflicts are detected). Self-assign a new Layer 2 ID). The Layer 2 link for ProSe direct communication one-to-one is identified by the combination of Layer 2 IDs of the two UEs. This means that the UE can engage in multiple Layer 2 links for ProSe direct communication one-to-one using the same Layer 2 ID.

ProSe direct communication one-to-one is described in detail in Section 7.1.2 of the current version v13.0.0 of Non-Patent Document 7, which is incorporated herein by reference. It consists of procedures.
-Establishment of a secure layer 2 link via PC5.
-IP address / prefix assignment.
-Maintaining layer 2 links via PC5.
-Release of layer 2 link via PC5.

FIG. 3 shows a method of establishing a secure Layer 2 link via the PC5 interface.

1. 1. The UE-1 sends a Direct Communication Request message to the UE-2 to trigger mutual authentication. The link initiator (UE-1) needs to know the layer 2 ID of the peer (UE-2) in order to execute step 1. As an example, a link initiator may learn a peer's Layer 2 ID by first performing a discovery procedure or by participating in ProSe1 to multi-communication involving the peer.

2. UE-2 initiates the procedure for mutual authentication. Upon successful completion of the authentication procedure, the establishment of a secure Layer 2 link via PC5 is complete.

UEs involved in isolated (non-relaying) one-to-one communication may also use link-local addresses. The PC5 Signaling Protocol supports a keep-alive feature used to detect when a UE is out of ProSe communication range so that the UE can proceed with implicit Layer 2 link release. And. Layer 2 link release via PC5 can be done by using a Disconnect Request message sent to the other UE, which also deletes all relevant context data. Upon receiving the disconnect request message, the other UE responds with a Disconnect Response message and deletes all context data associated with the Layer 2 link.

<ProSe direct communication related identification information>
The current version 13.2.0 of Non-Patent Document 8 defines the following identification information used for ProSe direct communication in Section 8.3.
SL-RNTI: Unique identification information used for ProSe direct communication scheduling.
-Source layer 2 (Source Layer-2) ID: Sidelink ProSe Identifies the sender of data in direct communication. The source layer 2 ID is 24 bits long and is used together with the ProSe layer 2 destination ID and LCID for identifying RLC UM and PDCP entities in the receiver.
-Destination layer 2 (Destination Layer-2) ID: Identify the target of data in the side link ProSe direct communication. The destination layer 2 ID has a length of 24 bits and is divided into two bit strings in the MAC layer.
-One bit string is the LSB part (8 bits) of the destination layer 2 ID, and is transferred to the physical layer as a side link control layer 1 ID (Sidelink Control Layer-1 ID). It is used in Sidelink Control to identify intended data targets and filter packets at the physical layer.
-The second bit string is the MSB part (16 bits) of the destination layer 2 ID, which is transmitted in the MAC header. It is used to filter packets at the MAC layer.

Access layer signaling is not required for group formation and for setting source layer 2 IDs, destination layer 2 IDs, and side link control L1 IDs within the UE. These identifications are either provided by the higher layers or are obtained from the identifications provided by the higher layers. For group cast and 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 the destination layer in the MAC layer. 2 Used directly as an ID. In the case of one-to-one communication, the higher layer provides the source layer 2 ID and the destination layer 2 ID.

<Radio resource allocation for neighborhood services>
From the point of view of the transmitting UE, the neighborhood service-enabled UE (ProSe-enabled UE) can operate in two modes for resource allocation.

Mode 1 refers to resource allocation scheduled by the eNB, where the UE requests transmit resources from the eNB (or release 10 relay node), and the eNodeB (or release 10 relay node) then directly data and direct control information. Schedule resources used by the UE to send (eg Scheduling Assignment). The UE needs to be RRC_CONNECTED to send data. Specifically, the UE sends a scheduling request (D-SR or Random Access) to the eNB, followed by a buffer status notification (BSR) in the usual way (following chapter "D2D"). See also Send procedure for communication). Based on the BSR, the eNB can determine that the UE has data for ProSe direct communication transmission and can estimate the resources required for transmission.

Mode 2, on the other hand, refers to UE autonomous resource selection, in which the UE itself selects resources (time and frequency) from the resource pool (ie, SA) in order to transmit direct data and direct control information. One resource pool is defined, for example, by the contents of SIB18, i.e. by the field comTxPoolNormalCommon, and this particular resource pool is broadcast within the cell and is subsequently commonly used by all UEs within the cell that are still in the RRC_Idle state. It is possible. In practice, the eNB may define up to four different instances of said pool, i.e. each of the four resource pools for sending SA messages and direct data. However, in Release 12, the UE shall always use the first resource pool defined in the list, even if multiple resource pools are configured. This constraint has been removed for Release 13, that is, the UE can transmit on multiple configured resource pools within a single SC period. How the UE selects the resource pool for transmission is further outlined below (further defined in 3GPP TS 36.321 (Non-Patent Document 2)).

Alternatively, another resource pool can be signaled by defining it by eNB and using the field comTxPoolExpectional which can be used by the UE in SIB18, i.e. in exceptional cases.

Which resource allocation mode the UE will use can be set by the eNB. Furthermore, which resource allocation mode the UE will use for D2D data communication is the RRC state, i.e. RRC_IDLE or RRC_CONNECTED, and the UE coverage state, i.e. in or out of coverage. Can also depend on. A UE is considered in coverage if it has a serving cell (ie, the UE is RRC_CONNECTED or is camping on the cell in the RRC_IDLE state).

The following rules apply to UEs regarding resource allocation modes:
• If the UE is out of coverage, the UE can only use mode 2.
• If the UE is within coverage, the UE may use mode 1 if the eNB has configured the UE accordingly.
• If the UE is within coverage, the UE may use mode 2 if the eNB has configured the UE accordingly.
• In the absence of exceptional conditions, the UE may change from mode 1 to mode 2 and vice versa only if the eNB is configured to do so. If the UE is within coverage, the UE shall only use the mode indicated by the eNB configuration, unless one of the exceptional cases occurs.
The UE considers itself to be in an exceptional condition while, for example, T311 or T301 is running.
• When an exceptional case occurs, the UE is temporarily allowed to use mode 2, even if it is configured to use mode 1.

While within the coverage area of an E-UTRA cell, the UE will have resources allocated by the cell, even if the carrier's resources are preset in, for example, a UICC (Universal Integrated Circuit Card). ProSe direct communication transmission shall be executed on the UL carrier only in.

For UEs in the RRC_IDLE state, the eNB may choose one of the following options:
The eNB may provide a mode 2 transmit resource pool within the SIB. UEs authorized for ProSe direct communication use these resources for ProSe direct communication in the RRC_IDLE state.
The eNB may indicate in the SIB that it supports D2D but does not provide resources for ProSe direct communication. The UE needs to enter the RRC_CONNECTED state in order to execute ProSe direct communication transmission.

The UEs in the RRC_CONNECTED state are as follows.
-A UE in the RRC_CONNECTED state that is authorized to execute ProSe direct communication transmission indicates to the eNB that it wants to perform ProSe direct communication transmission when it is necessary to execute ProSe direct communication transmission.
The eNB uses the UE context received from the MME to check whether the UE in the RRC_CONNECTED state is authorized to transmit ProSe direct communication.
The eNB may configure a UE in the RRC_CONNECTED state by dedicated signaling in a mode 2 resource allocation transmit resource pool that can be used without restriction while the UE is in the RRC_CONNECTED state. Alternatively, the eNB is allowed to use a UE in the RRC_CONNECTED state by dedicated signaling only in exceptional cases, otherwise it may rely on mode 1 resource allocation transmit resources. Can be set in the pool.

The resource pool for scheduling allocation when the UE is out of coverage can be set as follows.
-The resource pool used for reception is preset.
-The resource pool used for transmission is preset.

The resource pool for scheduling allocation when the UE is in coverage can be set as follows.
The resource pool used for reception is set by the eNB via RRC, within dedicated or broadcast signaling.
-When mode 2 resource allocation is used, the resource pool used for transmission is set by the eNB via the RRC.
• When mode 1 resource allocation is used, the SCI (Sidelink Control Information) resource pool (also known as the Scheduling Assignment (SA) resource pool) used for transmission is known to the UE. I can't.
-When mode 1 resource allocation is used, the eNB schedules a specific resource to be used for sending side link control information (scheduling allocation). The specific resource allocated by the eNB is in the resource pool for receiving the SCI provided to the UE.

FIG. 4 shows the use of transmit / receive resources for overlay (LTE) and underlay (D2D) systems.

Basically, the eNodeB controls whether the UE can apply mode 1 transmission or mode 2 transmission. When the UE knows its resources that it can send (or receive) D2D communications, it uses the corresponding resources only for the corresponding send / receive. For example, in FIG. 4, the D2D subframe is used only to receive or transmit a D2D signal. Since the UE as a D2D device operates in half-duplex mode, it can either transmit or receive a D2D signal at any given time. Similarly, another subframe shown in FIG. 4 can be used for LTE (overlay) transmission and / or reception.

<Transmission procedure for D2D communication>
The D2D data communication procedure differs depending on the resource allocation mode. As mentioned above, for mode 1, the eNB explicitly schedules resources for scheduling allocation and D2D data communication after the corresponding request from the UE. Specifically, the UE may be notified by the eNB that D2D communication is basically allowed but mode 2 resources (ie, resource pool) are not provided, for example, D2D communication interest notification by the UE. It can be done by exchanging (D2D Communication Information) and the corresponding response, the D2D Communication Response, and the corresponding exemplary ProseCommConfig information element does not include the comTxPoolNormalCommon, i.e. A UE that wants to initiate direct communication must request E-UTRAN for resource allocation for each individual transmission. Thus, in these cases, the UE must request a resource for each individual transmission, and the following is an exemplary list of different steps in the request / authorization procedure for this mode 1 resource allocation.
Step 1: The UE transmits an SR (Scheduling Request) to the eNB via the PUCCH.
Step 2: The eNB scrambles with C-RNTI to allow UL resources (for the UE to send the BSR) via the PDCCH.
Step 3: The UE transmits a D2D BSR indicating the state of the buffer via the PUSCH.
Step 4: The eNB scrambles with D2D-RNTI to allow D2D resources (for the UE to send data) via PDCCH.
Step 5: The D2D transmission UE transmits SA / D2D data according to the grant received in step 4.

Scheduling allocation (SA), also referred to as SCI (Sidelink Control Information), refers to control information, such as pointers to time-frequency resources for the corresponding D2D data transmission, modulation and coding schemes, and A compact (low payload) message containing a group destination ID (Group Destination ID). The SCI transmits side link scheduling information for one (ProSe) destination ID. The content of SA (SCI) basically follows the grant received in step 4 above. The contents of the D2D grant and SA are defined in section 5.4.3 of the current version 13.0.0 of Non-Patent Document 4, which is incorporated herein by reference, to specify SCI format 0. (See the contents of SCI format 0 above).

On the other hand, for mode 2 resource allocation, steps 1 to 4 above are basically unnecessary, and the UE autonomously sets resources for SA and D2D data transmission from the transmission resource pool set and provided by the eNB. Select.

FIG. 5 illustrates the scheduling allocation and transmission of D2D data for the two UEs UE-1 and UE-2, the resource for transmitting the scheduling allocation is periodic, and the D2D data transmission. The resources used for are indicated by the corresponding scheduling assignments.

FIG. 6 shows the D2D communication timing for mode 2, i.e. autonomous scheduling, of one SA / data period, also known as the SC period or side link control period. FIG. 7 shows the D2D communication timing for mode 1, i.e., the allocation scheduled by the eNB, for one SA / data period. The SC period is a period consisting of scheduling allocation and transmission of corresponding data. As can be seen from FIG. 6, the UE transmits the scheduling allocation after the SA offset time using the transmit pool resource SA_Mode2_Tx_pool for the scheduling allocation for mode 2. The first transmission of the SA is followed by, for example, three retransmissions of the same SA message. The UE then sends D2D data, or more specifically, a T-RPT bitmap / pattern, at some set offset (Mode2data_offset) after the first subframe of the SA resource pool (given by SA_offset). To start. One D2D data transmission of a MAC PDU (ie, transport block) consists of its first initial transmission and several retransmissions. For the explanatory diagrams of FIG. 6 (and FIG. 7), it is assumed that three transmissions (ie, the second, third and fourth transmissions of the same MAC PDU) will be performed. Mode 2 T-RPT bitmaps (time resource pattern of transmission, T-RPT: time resource pattern of transition) are basically MAC PDU transmissions (first transmission) and their retransmissions (second, third and 4). Define the timing of the second transmission). The SA pattern basically defines the timing of the initial transmission of SA and its retransmission (second, third and fourth transmission).

The UE transmits multiple transport blocks, MAC PDUs, for one sidelink grant, either transmitted by the eNB or selected by the UE itself, as currently specified in the standard. It can be (only once per subframe (TTI), i.e. in sequence), but for only one ProSe destination group. Also, the retransmission of one transport block must end before the first transmission of the next transport block begins, i.e., for each sidelink grant for the transmission of multiple transport blocks. Only one HARQ process is used. Furthermore, the UE can have and use several sidelink grants for each SC period, but different ProSe destinations should be selected for each of the sidelink grants. In this way, in one SC period, the UE can transmit data to one ProSe destination only once.

As is clear from FIG. 7, for the resource allocation mode (mode 1) scheduled by the eNB, the D2D data transmission, or more specifically the T-RPT pattern / bitmap, is the last SA in the SA resource pool. It starts in the next UL subframe after the transmission iteration. As already described with respect to FIG. 6, the mode 1 T-RPT bitmap (time resource pattern of transmission, T-RPT: time resource pattern of transition) is basically a MAC PDU transmission (first transmission) and its re-transmission. Defines the timing of transmissions (second, third and fourth transmissions).

The sidelink data transmission procedure is described in Section 5.14 of V13.0.0 of Non-Patent Document 2, which is incorporated herein by reference. In it, the autonomous resource selection of mode 2 is described in detail, distinguishing between a configuration in a single radio resource pool and a configuration in a plurality of radio resource pools. The following steps have been taken from the above section of Non-Patent Document 2 and assume autonomous resource selection in Mode 2.

In order to transmit on SL-SCH (sidelink shared channel: sidelink shared channel), the MAC entity must have at least one sidelink grant. Sidelink grants are selected as follows:

The MAC entity is configured by a higher layer to send using one or more pools of resources, and more data than can be sent during the current SC period is STCH (Sidelink Traffic). The MAC entity for each sidelink grant to be selected, if available within the channel: sidelink traffic channel), is as follows.
· If a higher layer configures you to use a single pool of resources:
-Select to use the pool of relevant resources.
• Otherwise, if the higher layer is set to use multiple pools of resources:
-A pool of resources from a pool of resources set by a higher layer whose associated priority list contains the highest priority of the sidelink logical channels in the MAC PDU to be transmitted. Select for use.

Note: If two or more pools of resources have an associated priority list that includes the priority of the highest priority sidelink logical channel in the MAC PDU to be transmitted, these pools of resources Which one of them is selected is left to the implementation of the UE.
-From the selected resource pool, randomly select time and frequency resources for SL-SCH and sidelink grant SCI. The random function should be able to select each of the allowed choices with equal probability.
• Selected to determine the set of subframes in which SCI transmission and transmission of the first transport block occur in accordance with Section 14.2.1 of Non-Patent Document 3 incorporated herein by reference. Use sidelink grants (this step refers to the selection of T-RPT and SA patterns, as described in association with FIG. 7).
• The selected sidelink grant with the configured sidelink grant that occurs within the subframe that begins at the beginning of the first available SC period that begins after at least 4 subframes of the selected subframe. Look out.
-Clear the set side link grant at the end of the corresponding SC period.

Note: Retransmission on SL-SCH cannot occur after the configured side link grant has been cleared.

Note: If a higher layer configures a MAC entity to send using one or more pools of resources, how many in one SC period, taking into account the number of sidelink processes. The choice of sidelink grant is left to the implementation of the UE.

The MAC entity is as follows for each subframe.

-If the MAC entity has a configured sidelink grant that occurs within this subframe-If the configured sidelink grant supports sending SCI-The configured sidelink on the physical layer Instruct to send the SCI corresponding to the grant.
-Otherwise, if the configured sidelink grant supports the transmission of the first transport block
-Deliver the configured sidelink grant and associated HARQ information to the sidelink HARQ entity for this subframe.

Note: MAC entities can handle multiple configured grants that occur within a subframe, and all of them due to the constraints of a single cluster SC-FDM. If not, it is up to the UE to decide which one of them to handle according to the above procedure.

The above text taken from the 3GPP technical standard can be further clarified. For example, the step of randomly selecting time and frequency resources is random with respect to which particular time / frequency resource is selected, but not, for example, with respect to the total amount of time / frequency resources selected. do not have. The amount of resources selected from the resource pool depends on the amount of data to be transmitted on the sidelink that should be selected autonomously. The amount of data to be transmitted then depends on the previous step of selecting the ProSe destination group and the corresponding amount of data ready to be transmitted to the ProSe destination group. The ProSe destination is selected first, as described later in the sidelink LCP procedure.

Furthermore, as is apparent from section 5.14.1.2.2 of v13.0.0 of Non-Patent Document 2, which is incorporated herein by reference, the side link associated with the HARQ entity. The process is responsible for instructing the physical layer to generate and execute transmissions accordingly. Briefly, after deciding on the sidelink grant and the sidelink data to send, the physical layer takes care that the sidelink data is actually sent based on the sidelink grant and the required send parameters. pay.

Discussed above is the current state of the 3GPP standard for D2D communications. However, it should be noted that there is ongoing debate about ways to further improve and extend D2D communications that could result in some changes being introduced in D2D communications in future releases. The present invention shall also be applicable to these later releases, as described below.

<ProSe network architecture and ProSe entities>
FIG. 8 shows a high level exemplary architecture for non-roaming cases, including different ProSe applications in UEs A and B, as well as ProSe application servers and ProSe features in the network. The architectural example of FIG. 8 is described in Non-Patent Document 9 v.I., which is incorporated herein by reference. It is taken from Chapter 4.2, "Architectural Reference Model" of 13.2.0.

Functional entities are presented and described in detail in Section 4.4, "Functional Entities" of Non-Patent Document 9, which is incorporated herein by reference. The ProSe function is a logical function used for network-related operations required for ProSe and plays a different role for each of the ProSe features. The ProSe function is part of 3GPP's EPC and provides all related network services such as authorization, authentication, data manipulation, etc. related to neighborhood services. For ProSe direct discovery and communication, the UE may obtain specific ProSe UE identification information, other configuration information, and approval from the ProSe function through the PC3 reference point. Although multiple ProSe functions can be deployed in the network, a single ProSe function is presented for ease of illustration. The ProSe function has three main sub-functions that perform different roles according to the characteristics of the ProSe, namely, the direct supply function (DPF), the direct discovery name management function (DPF), and the EPC level. It is composed of a discovery function (EPC-level Discovery Function). The DPF is used to supply the UE with the necessary parameters to use ProSe direct discovery and ProSe direct communication.

The term "UE" as used in the context refers to, for example, a ProSe-enabled UE that supports the following ProSe functionality:
-Exchange of ProSe control information between the ProSe compatible UE and the ProSe function through the PC3 reference point.
-Procedure for open ProSe direct discovery of other ProSe-enabled UEs through the PC5 reference point.
-Procedure for one-to-many ProSe direct communication through the PC5 reference point.
-Procedures for operating as a ProSe UE-to-Network Repeater. The remote UE (Remote UE) communicates with the ProSe UE-network repeater through the PC5 reference point. The ProSe UE-network repeater uses Layer 3 packet forwarding.
-Exchange of control information between ProSe UEs through the PC5 reference point, for example, for UE-network repeater detection and ProSe direct discovery.
-Exchange of ProSe control information between another ProSe compatible UE and the ProSe function through the PC3 reference point. In the case of the ProSe UE-network repeater, the remote UE transmits this control information through the PC5 user plane that should be relayed for the ProSe function through the LTE-Uu interface.
-Setting of parameters (including, for example, IP address, ProSe layer 2 group ID, group security material, and radio resource parameters). These parameters can be preset in the UE or, if within coverage, can be provided to the ProSe function in the network by signaling through the PC3 reference point.

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

<Vehicle communication-V2X service>
New considerations have been defined in 3GPP to consider the usefulness of new LTE features for the automotive industry, including neighborhood services (ProSE) and LTE-based broadcast services. As such, ProSe functionality is considered to provide a good foundation for V2X services. Connected vehicle technology aims to address some of the biggest challenges in the land transportation industry, including safety, mobility and traffic efficiency.

V2X communication is the transmission of information from a vehicle to any entity that can affect the vehicle and vice versa. This information exchange will improve safety, mobility and environmental applications to include driver assistance vehicle safety, speed adaptation and warning, emergency response, traffic information, navigation, traffic operations, commercial vehicle operation management and payment procedures. Can be used to

LTE support for V2X services includes three different types of use cases:
-V2V (Vehicle-to-Vehicle): Covers LTE-based communication between vehicles.
V2P (Vehicle-to-Pedestrian): Covers LTE-based communication between a vehicle and a device carried by an individual (eg, a handheld terminal carried by a pedestrian, cyclist, driver or passenger).
-V2I (Vehicle-to-Infrastructure): Covers LTE-based communication between the vehicle and the roadside aircraft.

These three types of V2X can use "cooperative awareness" to provide more intelligent services to the end user. It is a collaborative collision where transport entities such as vehicles, roadside infrastructure, and pedestrians collect knowledge about their local environment (eg, information received from other vehicles or sensor devices in the vicinity). That knowledge can be processed and shared to provide more intelligent services such as alerts or automated driving.

For V2V communication, E-UTRAN uses E-UTRA (N) to exchange V2V-related information with UEs in the vicinity of each other when authorization, approval and proximity criteria are met. to enable. The neighborhood standard can be set by the MNO (Mobile Network Operator: Mobile Network Operator). However, UEs that support V2V services can exchange such information when or not serviced by E-UTRAN, which supports V2X services.

UEs that support V2V applications transmit application layer information (eg, their location, dynamics, and attributes as part of the V2V service). The V2V payload must be flexible to accommodate the different information content, and the information can be transmitted periodically according to the settings provided by the MNO.

V2V is primarily broadcast-based, and V2V is a direct exchange of V2V-related application information between separate UEs, and / or because the direct communication range of V2V is limited, between separate UEs. V2V-related application information is exchanged via infrastructures that support V2X services, such as RSUs, application servers, and the like.

For V2I communication, the UE supporting the V2I application sends the application layer information to the roadside machine, which in turn sends the application layer information to the group or UE of the UE supporting the V2I application. can do.

V2N (Vehicle-to-Network, eNB / CN) has also been introduced, with one communication entity being the UE and the other communication entity being the serving entity, both supporting V2N applications and communicating with each other over the LTE network.

For V2P communications, E-UTRAN allows UEs in the vicinity of each other to exchange V2P-related information using E-UTRAN when authorization, approval and proximity criteria are met. .. The neighborhood criterion can be set by the MNO. However, UEs that support the V2P service can exchange such information even when they are not serviced by the E-UTRAN that supports the V2X service.

UEs that support V2P applications transmit application layer information. Such information is provided by vehicles with UEs that support V2X services (eg, warnings to pedestrians) and / or by pedestrians with UEs that support V2X services (eg, warnings to vehicles). Can be broadcast.

V2P is separate due to the direct exchange of V2P-related application information between separate UEs (one for vehicles and the other for pedestrians) and / or the limited direct communication range of V2P. Includes the exchange of V2P-related application information between UEs through infrastructures that support V2X services, such as RSUs, application servers, and so on.

For this new study item V2X, 3GPP provides specific terms and definitions in the current version 13.0.0 of Non-Patent Document 10 which can be reused for the present application.

Roadside Unit (RSU): An entity that supports V2I services that can send and receive from UEs using V2I applications. RSUs can be implemented in eNBs or installed UEs.
V2I service: A type of V2X service, one communication subject is a UE and the other communication entity is an RSU, both using V2I applications.
V2N service: A type of V2X service, one communication subject is a UE and the other communication entity is a serving entity, both using V2N applications and communicating with each other via LTE network entities.
V2P service: A type of V2X service, both communication entities of communication are UEs using V2P applications.
V2V service: A type of V2X service, both communication entities of communication are UEs using V2V applications.

V2X Service: A type of communication service that involves a transmit or receive UE using a V2V application via a 3GPP transport. The V2X service can be further divided into a V2V service, a V2I service, a V2P service, and a V2N service based on the other communication entity involved in the communication.

Different types of messages are defined and defined for V2V communication. For Intelligent Transport Systems (ITS), two different types of messages have already been defined by ETSI and are the corresponding European standards, Non-Patent Document 11, v1.3.1 and Non-Patent. Please refer to v1.2.1 of Document 12.

-Cooperative Awareness Message (CAM): Continuously triggered by vehicle dynamics to reflect vehicle condition.
• Decentralized Environmental Notification Message (DENM): Triggered only when a vehicle-related safety-related event occurs.

V2V standardization and ITS standardization are rather beginning, and it is hoped that other messages may be defined in the future.

Since CAM is continuously broadcast by ITS-S to exchange status information with other ITS stations (ITS-S: ITS Station), it has a greater impact on traffic load than event-triggered DENS messages. .. For this reason, the traffic characteristics of CAM messages defined by ETSI for ITS are considered to be more representative of V2V traffic.

Coordination Awareness Messages (CAMs) are messages exchanged between ITS-S to create and maintain awareness of each other in the ITS network and to support the coordinated operation of vehicles using the road network. Point-to-multipoint communication shall be used to transmit the CAM so that it is transmitted from the outgoing ITS-S to the receiving ITS-S located within the direct communication range of the outgoing ITS-S. .. CAM generation shall be triggered and managed by the Co-recognition Basic Service, which defines the time interval between two consecutive CAM messages. At present, the upper and lower limits of the transmission interval are 100 ms (ie, CAM generation rate 10 Hz) and 1000 ms (ie, CAM generation rate 1 Hz). The underlying principle of ETSI ITS is to transmit CAM when new information to be shared (eg, new position, new acceleration or new direction of travel) exists. Correspondingly, when the vehicle is moving slowly and at a constant direction and speed, a high CAM generation rate does not bring any real benefit, and the CAM only displays a minimal difference. The CAM transmission frequency of one vehicle varies in the range of 1 Hz to 10 Hz as a function of vehicle dynamics (eg, speed, acceleration, and direction of travel). For example, the slower the vehicle travels, the fewer CAMs will be triggered and transmitted. Vehicle speed is a major influencing factor for CAM traffic generation.

The trigger conditions for CAM generation are currently defined in Article 6.1.3. Of v1.3.1, Non-Patent Document 11, and are shown below.

1) The elapsed time since the last CAM generation provides the minimum time interval between two consecutive CAM generations to reduce CAM generation according to the channel usage requirements of T_GenCam_Dcc (Decentralized Congestion Control (DCC)). One of the following conditions related to ITS-S dynamics is given that is equal to or greater than the parameter).
The absolute value of the difference between the current direction of travel of the outgoing ITS-S and the direction of travel previously contained in the CAM previously transmitted by the outgoing ITS-S exceeds 4 °.
The distance between the current position of the outgoing ITS-S and the position previously included in the CAM previously transmitted by the outgoing ITS-S exceeds 4 m.
The absolute value of the difference between the current speed of the outgoing ITS-S and the speed previously contained in the CAM previously transmitted by the outgoing ITS-S exceeds 0.5 m / s.

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

If one of the above two conditions is met, the CAM shall be generated immediately.

The CAM includes the status information and attribute information of the outgoing ITS-S. The content of the CAM varies depending on the type of ITS-S, as described in more detail below. For vehicle ITS-S, status information may include time, position, motion state, activated system, etc., and attribute information may include data about dimensions, vehicle type, and role in road traffic. Upon receiving the CAM, the receiving ITS-S becomes aware of the presence, type, and status of the outgoing ITS-S. The received information can be used by the received ITS-S to support some ITS applications. For example, by comparing the status of the outgoing ITS-S with its own status, the receiving ITS-S assesses the risk of collision with the outgoing ITS-S and, if necessary, the HMI (Human Machine Interface). ) Can be notified to the driver. As described in detail in Article 7 of v1.3.1, Non-Patent Document 11, which is incorporated herein by reference, the CAM consists of one common ITS PDU header and multiple containers. , They together make up the CAM. The ITS PDU header is a common header that contains information about the protocol version, message type, and ITS-SID of the outgoing ITS-S. For vehicle ITS-S, the CAM shall include one basic container and one high frequency container, and may also include one low frequency container and one or more other special containers. The basic container contains basic information related to outgoing ITS-S. The high frequency container contains highly dynamic information of the outgoing ITS-S. The infrequent container contains static information on the outgoing ITS-S, as well as highly non-dynamic information. The special vehicle container contains information specific to the vehicle role of the transmitting vehicle ITS-S. The general configuration of the CAM is shown in FIG.

The table below provides an overview of the different components of V2V message data and the packet size.

Vehicle ITS-S produces a CAM that is intended to include at least one high frequency vehicle container and optionally a low frequency vehicle container. Vehicle ITS-S, which has a specific role in road traffic, such as public transportation, shall provide status information within a special vehicle container.

Each V2V message exchanged between vehicles must meet security requirements, including anonymity and integrity protection. Different security schemes can have different security performance and overhead levels, which are directly related to packet size (due to security overhead) and message frequency (eg, how often a security certificate is attached). Affect.

Both ETIS ITS and IEEE 1609.2 consider public key infrastructure (PKI) -based security solutions for V2X communications and are asymmetric-based application-layer security solutions. Normally, every V2X message needs to be signed and either a certificate or a digest of the certificate to achieve anonymity and integrity protection. Typical sizes for signatures, digests, and certificates are 64 bytes, 8 bytes, and 117 bytes, respectively.

As described above, CAM messages can have different periodicity and / or different message sizes. Furthermore, periodicity can even change over time depending on speed and other (less influential) factors such as direction of travel or angle. To provide an overview, identify the possible different message components (HF, LF, certificate) and the resulting periodicity and message size according to three different typical speed ranges. The following table is provided.

As is clear from the table above, the size of the components, and thus the size of the CAM, remains the same, but their generation / transmission frequency varies according to the different speed ranges. For the above table, the CAM HF component is assumed to be sent with the signature and digest, resulting in a message size of approximately 122 bytes (ie 8 bytes for the header, 18 bytes for the base container, Enough to send 23 bytes for high frequency containers, 64 bytes for signatures, and 8 bytes for digests). The CAM LF component is piggybacked to a high frequency component and has an additional size of approximately 60 bytes, resulting in a CAM size of 182 bytes with all containers / components. The certificate component (also known as the security component) that is piggybacked to the high frequency component has an additional size of approximately 117 bytes, resulting in a CAM size of 299 with all containers / components. Bytes, ie 239 bytes without the CAM LF container / component.

FIG. 10 shows the occurrence of three different components according to the three different speed ranges introduced above, and how this results in different overall message sizes and overall periodicity. Is shown. In FIG. 10, the dashed squares indicate that they contain different components and that the components are sent as a single CAM message rather than being sent separately.

The above has described the periodic co-recognition messages in great detail, and also specifies their different content, inherent periodicity and message size. However, it should be noted that while some of the above information has already been standardized, other information such as periodicity and message size has not yet been standardized and is based on assumptions. Furthermore, standardization can change in the future, and therefore aspects of how CAMs are generated and transmitted. Furthermore, at present, the different components (CAM HF, CAM LF, certificate) discussed above are sent together, ie as a single message, if they fit together. It doesn't have to be that way. In the future, these containers / components could also be sent separately from each other, each containing a header and possibly a base container. As a result, the above detailed description of CAM is realistic in message size and periodicity and is based on simulation results, but should be understood as an example considered for explanatory purposes. The above CAM message and its contents, periodicity, and message size are used throughout the present application to illustrate the basic principles of the present invention. Important for the present invention is that V2V communication requires the vehicle UE to transmit different data in a cyclical manner, such as (relative) speed, angle, direction of travel, and in some cases vehicle distance. It can be predicted that the periodicity can change rapidly as a function of vehicle dynamics such as other factors. As a result, the challenge is to allow the vehicle UE to send several periodic packets of different message sizes with different cycles and varying cycles.

As described above, mode 1 and / or mode 2 radio resource allocation is envisioned for the vehicle UE to have radio resources on the sidelinks to transmit the CAM. For mode 1 radio resource allocation, the eNB allocates resources for SA messages and data every SA period. However, when there is a lot of traffic (eg, 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, 3GPP has agreed that sidelink semi-persistent radio resource allocation will be supported by the eNB and UE for sidelink V2V communication mode 1 (ie, radio resource allocation scheduled to the eNB). As you can see, many V2V traffic is periodic.

However, the currently standardized semi-persistent allocation mechanism needs to be improved to meet the requirements and challenges of V2V traffic.

3GPP TS 36.211, "Evolved Universal Terrestrial Radio Access (E-UTRA); Physical Channels and Modulation (Releas 8)" 3GPP TS 36.321 3GPP TS 36.213 3GPP TS 36.212, "Multiplexing and channel coding" 3GPP TS 23.401 3GPP TS 23.203 3GPP TR 23.713 3GPP TS 36.300 3GPP TS 23.303 3GPP TR 21.905 ETSI EN 302 637-2 ETSI EN 302 637-3 3GPP TS 36.331

Non-limiting and exemplary embodiments provide improved resource allocation methods for vehicle communications for vehicle mobile terminals.

The independent claims provide non-limiting and exemplary embodiments. An advantageous embodiment is subject to the dependent claims.

Accordingly, in one general first aspect, the technique disclosed herein features a mobile terminal for a vehicle for transmitting periodic data to one or more receiving entities. Vehicle mobile terminals support the transmission of periodic data, including one or more different data components that should be transmitted with possible different transmission cycles and / or potentially different message sizes. The transmitter of the vehicle mobile terminal transmits information about periodic data to a radio base station that is responsible for allocating radio resources to the vehicle mobile terminal. Information about the transmitted periodic data thereby allows the radio base station to have different transmission periodicities and / or possible different message sizes for one or more data components of the periodic data. Is like being able to determine. The receiver of the vehicle mobile terminal receives from the radio base station a plurality of semi-persistent radio resource settings set by the radio base station based on the received information about the periodic data. Each of the multiple semi-persistent radio resource configurations 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 should be transmitted by the vehicle mobile terminal. The receiver activates one or more of the multiple semi-persistent radio resource settings for periodically allocating radio resources for the vehicle mobile terminal to transmit each of the indicated data components. Receive the activation command from the radio base station. The transmitter then delivers one or more data components, one or more receiving entities, based on the radio resource and transmission periodicity, as set by the activated one or more semi-persistent radio resource settings. Send to.

Accordingly, in one general first aspect, the techniques disclosed herein are radios for allocating radio resources to vehicle mobile terminals to transmit periodic data to one or more receiving entities. It features a base station. Vehicle mobile terminals support the transmission of periodic data, including one or more different data components that should be transmitted with possible different transmission cycles and / or potentially different message sizes. The receiver of the radio base station receives from the vehicle mobile terminal information about periodic data to be transmitted by the vehicle mobile terminal to one or more receiving entities. The radio base station processor determines the different data components supported, as well as the possible different transmission cycles and / or the possible different message sizes of one or more data components. The processor sets multiple semi-persistent radio resource settings based on the determined transmission periodicity and / or the determined message size. Each of the multiple semi-persistent radio resource configurations is configured to be used to transmit at least one of the supported data components. The transmission unit of the radio base station transmits information regarding a plurality of set semi-persistent radio resource settings to the mobile terminal for the vehicle. The receiver receives instruction information from the vehicle mobile terminal that one or more of the data components should be transmitted by the vehicle mobile terminal. The processor should then be activated for the vehicle mobile terminal to periodically allocate radio resources for the vehicle mobile terminal to transmit each of the indicated data components. Select one or more of the radio resource settings. The transmitter is further configured to send an activation command to the vehicle mobile terminal to activate one or more selected semi-persistent radio resource settings for the vehicle mobile terminal.

Further benefits and advantages of the disclosed embodiments will be apparent from the specification and drawings. These benefits and / or benefits may be provided individually by the various embodiments and features of the content disclosed herein and in the drawings, and all may be provided to obtain one or more of these benefits and / or benefits. There is no need to

These general and specific embodiments may be performed using a system, method, and computer program, and any combination of system, method, and computer program.

In the following, exemplary embodiments will be described in more detail with reference to the accompanying figures and drawings.

An exemplary architecture of a 3GPP LTE system is shown. An exemplary downlink resource grid of subframe downlink slots as defined in 3GPP LTE (Release 8/9) is shown. A method of establishing a layer 2 link through PC5 for ProSe communication is schematically shown. Shows the use of transmit / receive resources for overlay (LTE) and underlay (D2D) systems. It shows scheduling allocation and transmission of D2D data for two UEs. The D2D communication timing for the UE autonomous scheduling mode 2 is shown. Shows the D2D communication timing for scheduling mode 1 scheduled by the eNB. An exemplary architectural model for ProSe for non-roaming scenarios is shown. An exemplary structure of a CAM message is shown. It shows the transmission of several different CAM components with varying periodicity and message size for three different speed ranges. It illustrates the transmission of three different CAM components and the use of three SPS settings for the transmission of CAM according to an exemplary embodiment of the first embodiment. Also shown are the transmission of three different CAM components, and the use of three SPS settings for transmission of CAM, according to a further exemplary embodiment of the first embodiment, which are assigned by the SPS settings. Radio resources are combined together. Also shown is the transmission of three different CAM components, and the use of three SPS settings for transmitting CAM, according to a further exemplary embodiment of the first embodiment, where the corresponding SPS settings are used. The allocated radio resources are sufficient to send the complete CAM message. It also illustrates the transmission of three different CAM components, and the use of nine different SPS settings for transmission of CAM, according to a further exemplary embodiment of the first embodiment, with three UEs for vehicles. It is intended to support different speed ranges. It also illustrates the transmission of three different CAM components, and the use of ten different SPS settings for the transmission of CAM, according to a further exemplary embodiment of the first embodiment, with a vehicle UE of 3 It is intended to support two different speed ranges.

A "mobile station" or "mobile node" or "user terminal" or "user device" is a physical entity within a communication network. A node can have several functional entities. A functional entity refers to a software module or hardware module that performs a given set of functions and / or provides another functional entity on a node or network. A node may have one or more interfaces to attach the node to a communication device or communication medium through which the node can communicate. Similarly, a network entity may have a logical interface that attaches a functional entity to a communication device or communication medium through which the network entity can communicate with another functional entity or communication partner node.

The claims and the term "radio resource" as used herein should be broadly understood to refer to physical radio resources such as time-frequency resources.

The term "direct communication transmission" as used in the present application should be broadly understood as transmission directly between two user devices, i.e., not via a radio base station (eg, eNB). Accordingly, direct communication transmission is performed through a "direct sidelink connection", which is a term used to refer to a connection directly established between two user devices. For example, in 3GPP, the technical term D2D (Device-to-Device) communication is used, or ProSe communication or side link communication is used. The term "direct sidelink connection" should be broadly understood as the PC5 interface described in the Background Technology section and can be understood in the context of 3GPP.

The term "ProSe" or its abbreviated form "Proximity Services" as used herein is a neighborhood-based application in an LTE system, as exemplified in the Background Techniques section. And applied in the context of services. Other terminology, such as "D2D," is also used in this context to refer to Device-to-Device communication for neighborhood services.

The term "vehicle mobile terminal" as used throughout this application should be understood in the context of the new 3GPP study item V2X (Vehicular Communication), as described in the Background Technology section. Accordingly, the vehicle mobile terminal performs vehicle communications, i.e., transmitting information related to the vehicle to other entities (vehicles, infrastructure, pedestrians, etc.), for example for the purpose of safety or driver assistance. To this end, it shall be broadly understood as a mobile terminal specifically implemented in a vehicle (eg, passenger car, commercial truck, motorcycle, etc.). Optionally, the vehicle mobile terminal may have access to information available in the navigation system, such as map information, provided that it is also implemented in the vehicle.

As explained in the Background Technology section, 3GPP has introduced new considerations for LTE-assisted vehicle communications, including various vehicle mobile terminals and other stations. It is based on the ProSe procedure for exchanging V2V traffic between. Furthermore, semi-persistent radio resource allocation shall be supported by V2V traffic for mode 1 side link allocation so as to reduce the amount of scheduling performed by the eNB. However, current SPS mechanisms are not compatible with V2V traffic and its characteristics. For example, for normal semi-persistent scheduling on the Uu link (ie between the eNB and the UE), the eNB receives QCI information (Quos Service Identifier) from the MME (Moving Management Entity). The QCI information indicates that a particular bearer configured between the eNB and the UE is configured to carry VoIP traffic, so that the eNB is the periodic traffic generated by the UE on that bearer. To learn about. The eNB can then set the semi-persistent radio resource allocation for the UE by sending RRC signaling to the UE to set the SPS periodicity. The eNB then sends a corresponding buffer status notification indicating that the UE actually needs to send VoIP data through the bearer and that there is data to be sent for VoIP traffic. A PDCCH is sent to the UE to activate the configuration, and in its SPS configuration, the PDCCH message also indicates which radio resources the UE is allowed to use periodically (thus, in this way). Allocate a specific amount of radio resources). Accordingly, the UE uses SPS resources to periodically send VoIP traffic.

However, the eNB has no knowledge of the type of traffic (eg, periodicity or message size) sent by a particular vehicle through a sidelink connection, so that the eNB is through semi-persistent radio resource allocation. Neither the amount of resources to be allocated nor the periodicity of these semi-persistent radio resources can be adequately determined.

Even if the eNB somehow receives information about the traffic to be sent by the vehicle UE, the vehicle UE must send V2V traffic with different periodicity and / or different message sizes. It should be noted that this is significantly different from the VoIP traffic type for which the current SPS mechanism was designed. Further, the periodicity in which the V2V traffic should be transmitted is variable because the periodicity can change depending on the vehicle dynamics such as the speed at which the vehicle travels. As such, the currently standardized SPS mechanisms are inadequate to address these different V2V usage scenarios.

The following exemplary embodiments have been conceived by the inventor to alleviate one or more of the problems described above.

Specific embodiments of the various embodiments are related to the various embodiments, with the addition of certain key features as described below, provided by the 3GPP standard, and partially described in the Background Techniques section. As it does, it should be implemented with a wide range of specifications. Although embodiments may be advantageously used in, for example, mobile communication systems, such as the 3GPP LTE-A (release 10/11/12/13) communication system (or later release) described in the technical background section above. It should be noted that the embodiments are not limited to its use in this particular exemplary communication network.

The description should not be construed as limiting the scope of this disclosure, but should be construed as merely an example of an embodiment for a better understanding of this disclosure. Those skilled in the art can apply the general principles of the present disclosure, which are expressly stated in the claims, to different scenarios and in methods not expressly described herein. You should know that. For illustration purposes, some assumptions have been made, but they shall not limit the scope of the following embodiments.

Various embodiments primarily provide an improved semi-persistent resource allocation procedure between the UE (for vehicles) and the eNB responsible for allocating radio resources to the UE (for vehicles). As such, other functionality (ie, functionality that does not change with different embodiments) can remain exactly as described in the Background Techniques section, or has any consequences for different embodiments. Can be changed without. This includes, for example, other steps on how the vehicle UE performs the actual transmission of periodic data after the vehicle UE has been assigned the appropriate semi-persistent radio resources.

(First Embodiment)
In the following, the first embodiment for solving the above-mentioned problem will be described in detail. Different embodiments and various variants of the first embodiment are also described.

Illustratively, a vehicle UE is envisioned that is mounted on a vehicle and capable of performing vehicle communications based on the D2D framework described in the Background Techniques section of the present application. However, as will be described in more detail later, the underlying principles of the present invention are not constrained to be simply applied by the vehicle UE, for example, to the eNB via the Uu interface or to the PC5 interface. It can also be implemented by a normal (ie, non-vehicle) UE that sends periodic data to other UEs via (sidelink connection). However, for the following discussion, it is assumed that the UE is a vehicle UE that needs to periodically transmit V2V data.

Periodic data is from other (vehicle) UEs (via PC5 interface), their eNB (via Uu interface), roadside machines (possibly via PC5 interface), and / or vehicle UEs. The vehicle UE transmits (broadcasts) periodic data destined for other (vehicle) UEs, although it may be possible to transmit the periodic data transmitted by the vehicle to other suitable stations of interest. It is further assumed that the transmission from the vehicle UE will reach all receiving entities in its area as it can be assumed to be point-to-multipoint.

The periodic data to be transmitted by the vehicle UE is, for example, the Co-recognition Message (CAM) detailed in the Background Technology section. A characteristic of CAM according to the present invention is that CAM is transmitted in a periodic manner. However, the CAM has different, even varying transmission periodicities and / or different message sizes (ie, the amount of data that the vehicle UE needs radio resources for, which should be transmitted). In that respect, the semi-persistent scheduling scenario differs significantly from the normal VoIP usage scenario. VoIP specifies fixed periodicity and fixed message size that are easy to handle with semi-persistent radio resource allocation.

It should be noted that the CAM is merely an example of such periodic data, and that the present invention may be applicable to other data types that may be standardized in the future for vehicle or non-vehicle communications. be. Especially for vehicle communications, vehicle UEs are likely to have to periodically broadcast data (status and attributes) with different and / or even varying periodicities, resulting in different periodicities. Due to this, it may be necessary to send messages with more or less data at different time instances.

As described in detail below, the CAM message is a good example of this type of periodic data, and as just described, the present invention is not limited to it, but the first embodiment and It is used to describe its variant.

Different CAM components that need to be broadcast periodically, but with different periodicity, by the vehicle UE (eg, CAM HF, CAM LF, Certificates, based on which the invention is described below, CAM. Is a component) exists. In the following, only one CAM message is transmitted / broadcast by the vehicle UE in a particular time instance, where the CAM message should be transmitted in that time instance with different CAM components (ie, different periodicity). It is mostly assumed that it contains a CAM component) that occurs in the time instance in question, regardless of having. In other words, in the case where different CAM components should be transmitted simultaneously by the vehicle UE (the SC period of the PC5 interface), the different CAM components are piggybacked together to form a single CAM message, which is then it. Will be sent. The periodicity of the different CAM components is adjusted (ie, a multiple of each other) so that the different CAM components actually occupy in a particular same time instance so that the piggyback actually works. There is a need. Thus, a single CAM has a single periodicity (given by the maximum transmission rate of the CAM component to be transmitted (eg, CAM HF component)), but with different content and therefore different messages. It is sent in a periodic manner in size (ie, different CAM components are contained in a single CAM message in different time instances), and the different message sizes also change cyclically (eg, Figure 10 and related). See the description). Thus, the radio resource allocation mechanism needs to allocate different amounts of radio resources in different time instances.

Alternatively, different CAM components with different periodicity can be sent as separate CAM messages. More radio resources are needed because each of the separate CAM messages may need to include at least the header and, in some cases, the base container (see Figure 9 and related description). Considering this can be a disadvantage, but this is avoided by piggybacking the CAM components together in the first alternative. However, providing separate CAM messages has the advantage that the need to adjust the different periodicity of each CAM component can be avoided, i.e. the periodicity of each CAM component can be freely defined. There is. In this case, the CAM message has different periodicity and different message sizes.

3GPP standardization is still complete about the transmission speeds of different CAM components, whether piggybacking is optional or mandatory, or exactly how different CAM components are transmitted. Has not agreed. In either case, it may change in a future release. The underlying principles of the invention can be applied to any of these modifications, even if it may be necessary to apply a slight adaptation to constitute these modifications.

In the following, it is mainly assumed that only one CAM message is transmitted by the vehicle UE in a particular time instance, that is, different CAM components form a single CAM message.

Furthermore, the required transmission periodicity of the CAM component can change rapidly over time as a function of vehicle dynamics such as speed, direction of travel, and / or angle, and possibly other factors can be defined in the future. Is expected.

In summary, the UE (for vehicles) sends periodic data (eg, CAM) to other receiving entities (eg, other stations for vehicles). To transmit periodic data, the vehicle UE requires radio resources that can be allocated, for example by the eNB, according to, for example, the ProSe mode 1 radio resource allocation described in the Background Techniques section. According to the first embodiment, the eNodeB allocates semi-persistent radio resources to the vehicle UE so that the vehicle UE can periodically transmit the waiting periodic data.

Provided in advance, the first embodiment can be conceptually divided into a preparation phase and an execution phase. In the preparatory phase, different SPS settings are set by the eNodeB for later transmission of periodic data that is supported by the vehicle UE and therefore may be transmitted by the vehicle UE in the future. The vehicle UE is configured with a variety of different SPSs that can be activated during the execution phase as needed. The execution phase can be considered to begin when the vehicle UE begins transmitting some or all of the supported periodic data. Accordingly, of the previously prepared SPS settings, a particular SPS setting is activated within the UE and then used by the vehicle UE to transmit waiting periodic data. During the execution phase, either the message size or the periodicity of the waiting periodic data can change, resulting in different SPS settings of the previously prepared SPS settings with different periodicity. , Or must be activated within the vehicle UE so that it can still send periodic data with different message sizes.

Here, the preparation phase will be described in more detail. The eNodeB needs to know about the periodic data that may be transmitted by the vehicle UE in the future so that the eNodeB can set up the appropriate SPS settings for the periodic data supported by the UE. Typically, the SPS configuration allocates a specific amount of radio resources in a periodic manner (ie, in a periodic time instance), and the specific amount of radio resources is the amount of data that the UE needs to transmit (eg, CAM). Message size). Accordingly, the vehicle can allow the eNodeB to determine one or more possible different periodicities and / or potentially different message sizes that may be transmitted by the vehicle UE in the future. The UE sends information about the periodic data to the eNodeB. By learning this information and, as a result, later activating one or more of these SPS settings for the vehicle UE, the vehicle UE was periodically assigned by the activated SPS settings. The eNodeB can set a number of different SPS settings in such a way that radio resources can be used to actually transmit one or more of the supported periodic data.

In this way, the eNodeB provides the vehicle UE with corresponding information about the multiple SPS settings so that the vehicle UE knows the multiple SPS settings that may be activated in the future after the multiple SPS settings have been set up. offer. In this way, the eNodeB and the vehicle UE are ready to handle the transmission of one or more of the supported periodic data.

Here, the execution phase will be described in more detail. The vehicle UE may eventually want to transmit some or all of the CAM data components and need radio resources (allocated to the semi-persistent) to perform the transmission. It is supposed. In response, the vehicle UE informs the eNB of which CAM component it wants to send, and in response the eNB sends all of the currently waiting CAM components from the pre-prepared SPS settings. Select one or more SPS settings to allocate the appropriate radio resources to the vehicle UE. The eNB then activates one or more selected SPS settings in the UE, for example, by sending the appropriate activation command.

The vehicle UE accordingly activates a particular SPS configuration as instructed by the eNodeB, so it is active to send one or more waiting CAM data components to the other (vehicle) UE. Periodic radio resources scheduled by the customized SPS configuration can be used.

As described above, according to the first embodiment, the SPS resource can be allocated to the vehicle UE even if the periodicity and / or message size of the data to be transmitted by the vehicle UE can change. It is possible. As a result, the Uu link between the eNodeB and the UE would otherwise have to repeatedly perform dynamic radio resource allocation (see, eg, ProSe Mode 1 description in the Background Technology section) for each SC period. It is possible to reduce the above signaling overhead. Furthermore, the buffer status notification used by the vehicle UE to indicate that the (periodic) data is waiting to be transmitted triggers to allocate dynamic resources each time there is periodic data coming to the UE side. There is no need to send from the UE to the eNB to do so.

FIG. 11 shows three different CAM components (certificates, CAM LF components, and CAM HF components) according to an exemplary embodiment of the first embodiment to allow transmission. It exemplifies that the SPS setting is activated. For this exemplary embodiment of the first embodiment, one SPS setting is set for one particular CAM data component. Vehicle UEs wishing to transmit three different CAM components accordingly can use the periodic radio resources allocated by SPS setting 1 to transmit the CAM HF component and transmit the CAM LF component. The periodic radio resource allocated by SPS setting 2 can be used to do so, and the periodic radio resource allocated by SPS setting 3 can be used to transmit the certificate.

Depending on whether the different CAM components are sent in one message or in separate messages, the different SPS settings are combined by the vehicle UE so that a larger combined CAM message can be sent. Or they can be used separately from each other to send separate CAM messages.

More specific embodiments that the first embodiment can take are shown below.

In a broad embodiment of the first embodiment, the vehicle UE is one or more different data components to be transmitted with possible different transmission cycles and / or possible different message sizes. It is assumed, though not described in more detail, to support the transmission of periodic data including. As described above, the challenge imposed on the SPS allocation mechanism of the first embodiment is that the transmission of vehicle data involves potentially different periodicities and / or different message sizes. be. This will be explained in more detail based on the CAM message introduced in the Background Technology section.

According to one possible exemplary scenario, the vehicle UE supports the transmission of several CAM components, such as the CAM HF component, the CAM LF component, and the security certificate. Accordingly, the possible message size depends on which CAM component is sent in the CAM message. A summary of the possible different message sizes is given in the table below.

For the above table, different CAM components sent in the same time instance are one such that the CAM LF component and the CAM security certificate are piggybacked back to the base CAM HF component, which is sent at the highest transmission rate, respectively. It is expected to form a single CAM message. Correspondingly, the message size will vary depending on the time instance (assumed different CAM components, as listed in the right column of the table and as exemplified in Figure 11). Due to the periodicity, FIG. 11 does not show the transmission of the CAM HF component + CAM security certificate, see the central portion of FIG. 10 for the above points).

Different CAM components are different so that each of the possible CAM messages that should be sent at a particular time instance must be sent with different periodicity, as illustrated in the table below. It should be transmitted periodically.

The transmission periodicity value assumed above is the periodicity of the CAM component in the CAM message that has the lowest transmission rate (eg, for CAM messages containing CAM HF and CAM LF components, CAM LF. It is actually related to the component's 500ms). The indicated transmission periodicity should not be understood as the transmission periodicity of a particular CAM message. For example, a CAM message containing a CAM HF component and a CAM LF component is not actually transmitted every 500 ms (sent every 1000 ms, see FIG. 11).

The values exemplarily assumed in the above table for transmission periodicity are assumed for a single vehicle speed range greater than 144 km / h, and that speed range is the only one supported by the vehicle UE. It is supposed to be one.

According to another possible exemplary scenario, the vehicle UE predicts with only one CAM component, eg, a CAM HF component, and therefore a predicted fixed size of 122 bytes (see table above). It supports transmission with a fixed periodicity of 100 ms (see table above). However, a special characteristic of V2V data is that the periodicity of different CAM components can vary with vehicle dynamics, eg, the speed at which the vehicle UE is traveling. As a result, even if the vehicle UE supports the transmission of only one CAM component, the periodicity that one CAM component should transmit will change over time, and the SPS allocation mechanism will take into account some periodicity. It can bring the result that it needs to be put in again. This is illustrated in the table below.

According to another possible exemplary scenario, the vehicle UE supports and supports the transmission of various CAM components (eg, CAM HF, CAM LF, and all three CAM components of security certificates). In addition, some speeds (ranges) shall be supported. The resulting varying periodicity and message size are revealed in the table below.

As illustrated above, there can be many different combinations of CAM components (left column in the table above) and possible different CAM message sizes (eg 122 bytes, 182 bytes, 299 bytes, etc.). Or 239 bytes) and may have different periodicity (eg 100 ms, depending on the specific CAM component and / or possibly supported speed (range) for the vehicle UE). 200ms, 300ms, 500ms, 600ms, 1000ms, 1200ms). The SPS settings set by the eNB during the preparation phase need to take this into account and are appropriate so that the vehicle UE can send any (combination) of the supported periodic data. It shall match the resulting CAM message transmission periodicity and / or the resulting CAM message size supported by the vehicle UE so that the SPS configuration is later activated.

A variety of different SPS settings are provided by eNodeB, as illustrated for the selected example above. Especially at first, for brevity, several different periodicities should be taken into account, but for vehicles so that the periodicity itself does not change over time (eg, due to speed changes). The UE supports transmission of several CAM components, but is expected to support only one speed range, eg, the highest speed range above 144 km / h.

In the exemplary embodiment of the first embodiment described above, there is one separate SPS configuration that matches each of the possible CAM components supported to be transmitted by the vehicle UE. Three different SPS settings 1, 2 and 3 are set by the eNodeB. For possible combinations of CAM HF components and CAM security certificates, this particular combination does not occur due to the exemplary periodicity for separate CAM components. It should be noted that separate SPS settings are not required in this example.

SPS setting 1 allocates sufficient specific radio resources to transmit 122 bytes of the basic CAM HF component every 100 ms, which is the periodicity of the CAM HF component. Accordingly, the UE uses the periodic radio resources allocated by SPS setting 1 to send the CAM message containing the CAM HF component.

The SPS setting 2 also allocates sufficient specific radio resources to transmit an additional (piggybacked) CAM LF component of 60 bytes every 500 ms, which is the periodicity of the CAM LF component. Accordingly, the UE uses the periodic radio resources allocated by SPS configuration 2 to send the CAM message containing the CAM LF component. In addition, SPS setting 3 allocates sufficient specific radio resources to send an additional 117 bytes of (piggybacked) security certificate every 1000 ms corresponding to the periodicity of the security certificate. Accordingly, the UE uses the periodic radio resources allocated by SPS configuration 3 to send a CAM message containing a security certificate.

FIG. 12 illustrates the use of the three SPS settings exemplarily assumed above for the transmission of a CAM message by a vehicle UE according to an exemplary embodiment of the first embodiment. As is clear from FIG. 12, the three SPS settings match three different data components to be transmitted by the vehicle UE. A dashed square containing multiple data components to be sent in the same time instance indicates that these different data components are sent as a single CAM message, as exemplified above. It shall be. As is clear from FIG. 12, in a time instance where several CAM components should be transmitted in one CAM message, the vehicle UE transmits the entire CAM message (ie, includes multiple CAM components). Combines the radio resources allocated by multiple SPS configurations so that they have sufficient radio resources available for. For example, when transmitting a CAM HF component with a CAM LF component, the radio resources allocated via SPS settings 1 and 2 are combined (ie, summed and used together), resulting in transmission. Have sufficient wireless resources available. Similarly, when sending the CAM HF component along with the CAM LF component and security certificate, the radio resources allocated via SPS settings 1, 2 and 3 are combined, resulting in the entire combined CAM message. Have sufficient radio resources available to transmit.

As just described, radio resources allocated by different SPS settings may have to be combined for a time instance in which the vehicle UE sends a larger combined CAM message. According to an alternative embodiment of the first embodiment below, this coupling of radio resources separately allocated by the SPS configuration is no longer necessary. Instead, the separate SPS settings are set in such a way that the size of the resulting single CAM message is taken into account in advance. In line with the above discussion, the table below exemplifies this alternative embodiment of the first embodiment.

As is clear from the table, the SPS settings have a larger amount of radio resources allocated by each SPS setting, thereby making the larger CAM message when several CAM components are transmitted within one CAM message. It differs from the previous embodiment in that it takes size into account.

Corresponding to FIG. 12, FIG. 13 shows how different SPS settings are used by the vehicle UE to transmit periodic CAM data (components). In a time instance where the vehicle UE sends several CAM components in one CAM message, the vehicle UE has sufficient radio resources to send the larger CAM message of the activated SPS settings. SPS settings that provide As in the previous exemplary embodiment of the first embodiment, the vehicle UE selects SPS setting 1 to send a CAM message containing only the CAM HF component. On the other hand, when transmitting a CAM HF component with a CAM LF component, radio resources are required to transmit a total of 182 bytes, resulting in the transmission of said CAM message containing the CAM HF component and the CAM LF component. To do so, the vehicle UE shall select SPS setting 2 and use the specific radio resources allocated by SPS setting 2. Correspondingly, when transmitting the CAM HF component together with the CAM LF component and the security certificate, radio resources are required to transmit a total of 299 bytes, so that the vehicle UE has an SPS setting of 3 Shall be selected. In this way, the vehicle UE uses the specific radio resource allocated by the SPS setting 3 to transmit the CAM message containing the three components.

In the embodiment discussed above of the first embodiment according to FIGS. 12 and 13, the vehicle UE has several speed ranges, eg, three assumed speed ranges, greater than 144, 72 to. 144, and 48-72, can also be applied to more complex cases, which also support, resulting in additional different periodicity supported for each CAM component.

The table below shows that the radio resources allocated by different SPS settings are collected by the vehicle UE to collect enough radio resources to be able to send a combined CAM message containing several data components. It is assumed that they can be combined (see discussion for Figure 12).

As is clear from the table above, during the preparation phase, the eNodeB will allow the vehicle UE to transmit the corresponding CAM components in a cyclical manner when one or more SPS settings are later activated. As such, set up nine separate SPS settings, each allocating radio resources with appropriate periodicity.

Depending on the current speed of the vehicle UE, the eNodeB activates any of the SPS settings 1, 2, and 3 when the speed is greater than 144 km / h, or when the speed is 72 km / h to 144 km / h. Sets the vehicle UE to activate SPS settings 4, 5, and 6 or to activate SPS settings 7, 8 and 9 when the speed is between 48 km / h and 72 km / h.

FIG. 14 shows how nine separate SPS settings can be used by the vehicle UE to periodically send CAM messages of different sizes. The upper part of FIG. 14 (ie, with reference to speeds above 144 km / h) basically corresponds to FIG. 12, and will not be described again. For a speed range of 72 km / h to 144 km / h, FIG. 14 shows that the vehicle UE has activated SPS settings 4, 5, and 6 so that different sized CAM messages can be sent. Shows how to combine the radio resources allocated by. In particular, a CAM message composed of CAM HF and CAM LF components can be transmitted by the vehicle UE by combining the radio resources allocated by SPS settings 4 and 5. A CAM message consisting of all three components (CAM HF, CAM LF, security certificate) is provided by the vehicle UE by combining and using the radio resources allocated by SPS settings 4, 5 and 6. Can be sent. A CAM message consisting of a CAM HF component and a security certificate can be transmitted by the vehicle UE by combining and using the radio resources allocated by SPS settings 4 and 6.

For a speed range of 48 km / h to 72 km / h, FIG. 14 shows that the vehicle UE is assigned by activated SPS settings 7, 8 and 9 so that different sized CAM messages can be sent. It shows how to combine the radio resources. In particular, a CAM message composed of CAM HF and CAM LF components can be transmitted by the vehicle UE by combining the radio resources allocated by SPS settings 7 and 8. A CAM message consisting of all three components (CAM HF, CAM LF, security certificate) is transmitted by the vehicle UE by combining and using the radio resources allocated by SPS settings 7, 8 and 9. be able to.

In the following, an alternative embodiment of the first embodiment, described in association with FIG. 13, can be extended here to a vehicle UE that supports some speed range.

FIG. 15 shows the use of the corresponding different SPS settings by the vehicle UE to send various possible CAM messages. The upper part of FIG. 15 (see speed over 144 km / h) basically corresponds to FIG. 13, and will not be described again. For the speed range 72 km / h to 144 km / h, four different SPS settings are set by eNodeB to support the transmission of all possible CAM components. Unlike the scenario for speed ranges above 144 km / h, the vehicle UE must actually send a CAM message consisting of a CAM HF component and a CAM security certificate. In this alternative embodiment of the first embodiment, the eNodeB is sufficient to transmit thus separate SPS settings, ie 239 bytes every 1000 ms, for this possible CAM message. The SPS setting 7, which allocates specific radio resources, must be set. The radio resources in SPS settings 4 and 6 could be flexibly combined to allocate sufficient (but not too much) resources to send a CAM message consisting of a CAM HF component and a security certificate (but not too much). (See FIG. 14), so this SPS setting 7 was not required in the previous embodiment of the first embodiment.

As reiterated, some SPS settings by eNodeB to support different possible speed ranges that the UE can drive (as an example of vehicle dynamics that affect the periodicity of various CAM data components). Is prepared. In these scenarios, when preparing multiple SPS settings, the possible speed ranges supported by the vehicle UE affect the different periodicity to be taken into account, so the eNB is notified about them. It is also necessary to do. One option is that explicit information about the speed range supported by the vehicle UE needs to be taken into account when the eNB prepares multiple SPS settings from that information, resulting in periodic data. It is to be sent to the eNB, for example, with or separately from the information about the periodicity so that the different periodicity of the component can be determined. Another option is for the vehicle UE to have a variety of possible periodicity, including periodicity in the supported speed range, so that the UE does not need to additionally notify the eNB of the supported speed range. Pre-transmitted, the eNB expects the eNB to have access to specific information that allows this relationship to be established, such as CAM messages in different speed ranges and standardized definitions of component periodicity. The supported velocity range can then be estimated from the different reported periodicities.

Furthermore, when the UE actually wants to initiate the transmission of periodic data, the eNB may select and activate the SPS settings provided for the indicated speed range currently experienced by the vehicle UE. As such, the UE shall notify the eNB of its current speed (or its current speed range). Information about the current speed can be transmitted by the vehicle UE, for example, with or separately from instructional information as to which data component the vehicle UE wants to transmit. For example, an exemplary embodiment of the first embodiment is a buffer state notification indicating that the instruction information is waiting for data in the corresponding buffer in the UE for a particular logical channel group. Is stipulated. Accordingly, information about the current speed of the vehicle UE can also be transmitted within the buffer status notification.

Furthermore, as mentioned above, the periodicity of the CAM data component can depend on vehicle dynamics such as speed, although it can change over time. Therefore, a further embodiment of the first embodiment allows the activated SPS settings to be varied depending on the current vehicle dynamics (eg, the speed of the vehicle UE). In the above points, the vehicle UE can monitor its own speed and determine if the speed range has changed compared to the speed range it was in front of. In this case, the vehicle UE may notify the eNodeB of this change in speed range. Alternatively, the vehicle UE may periodically transmit information about its current speed to the eNodeB so that the eNodeB itself can determine when a particular vehicle UE changes the speed range associated with the SPS setting. In either case, the speed range change thus selects and activates a different SPS setting provided for the indicated speed range in place of the previously activated SPS setting. As such, it can trigger the eNodeB. The vehicle UE receives these activation commands for the changed SPS settings and no longer uses the previously activated SPS settings, but uses the newly activated SPS settings.

According to another alternative embodiment of the first embodiment, instead of transmitting the current speed or the current modified speed range to the eNodeB, the vehicle UE has modified its own specific speed range. When determining, the corresponding SPS settings required for the changed speed range can actually be identified and a request is sent to the eNodeB to use these new SPS settings due to changes in the speed range. obtain. The eNodeB can then receive this request and decide whether or not to comply with the request. Accordingly, the eNodeB may determine that the change in the SPS settings is valid and therefore sends a response to the request accordingly to activate the requested SPS settings. As such, the vehicle UE no longer uses the previously activated SPS settings, but now uses the newly activated SPS settings.

As just described, when changing the SPS settings in the vehicle UE due to changes in vehicle dynamics (eg speed), according to one possible embodiment of the first embodiment, the vehicle UE To avoid sending some of the components due to frequent changes in speed, and the resulting frequent changes in SPS settings, all of the CAM components (ie, CAM messages containing all CAM components). You can always start by sending.

As described above, the vehicle UE transmits to the eNB information about supported periodic data that the vehicle UE may have to transmit in the future. This can be done in a variety of ways, as described in detail with reference to the following embodiments of the first embodiment. According to one exemplary embodiment of the first embodiment, the vehicle UE is supported by the vehicle UE and, as a result, of a CAM message / component that may actually have to be transmitted in the future. , Possible different periodicities and / or possible different message sizes may be explicitly notified to the eNodeB. Thus, for example, information about periodic data may include a list of possible periodicity and / or possible CAM message sizes supported by the vehicle UE. In this way, the eNodeB can provide the appropriate SPS settings for the various different periodicities and / or message sizes supported.

According to a variation of this embodiment 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 possible periodicity and possible message size can be found in one message, eg, the Sidelink UE Information currently specified in the standard to indicate side link information to the eNodeB (eg, UE sidelinks). Frequencies of interest to communicate, and side-link communication destinations requiring the UE to allocate dedicated resources for it) (v13.0 of Non-Patent Document 13 incorporated herein by reference). It can be sent in a message based on (see Section 6.2.2 of .0). The following defines an exemplary extended SidelinkUE Information message for this embodiment of the first embodiment.
<SiderinkUE Information message>
--ASN1START
SidelinkUEInformation-r12 :: = SEQENCE {
critical Extensions CHOICE {
c1 CHOICE {
SidelinkUEInformation-r12 SidelinkUEInformation-r12-IEs,
spare3 null, spare2 null, spare1 null
},
criticalExtensionsFuture Sequence Sequence {}
}
}
SidelinkUEInformation-r12-IEs :: = SEQENCE {
comRxInterestedFreq-r12 ARFCN-ValueEUTRA-r9 OPTIONAL,
comTxResourceReq-r12 SL-CommTxResourceReq-r12 OPTIONAL,
discRxInterest-r12 ENUMERATED {true} OPTIONAL,
discTxResourceReq-r12 INTER (1..63) OPTIONAL,
lateNonCriticalExtension Octet STRING OPTIONAL,
nonCriticalExtension SidelinkUEInformation-v13x0-IEs OPTIONAL
}
SidelinkUEInformation-v13x0-IEs :: = SEQENCE {
comTxResourceReq121-r13 SL-CommTxResourceReqUC-r13 OPTIONAL,
comTxResourceInfoReqRelay-r13 SEQENCE {
comTxResourceReqRelay-r13 SL-CommTxResourceReqUC-r13,
ue-Type-r13 ENUMERATED {relayUE, remoteUE}
}
OPTIONAL,
discTxResourceReq-v13x0 SEQENCE {
carrierFreqDiscTx-r13 INTER (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 Sequence {} OPTIONAL
}
SL-CommTxResourceReq-r12 :: = SEQENCE {
carrierFreq-r12 ARFCN-ValueEUTRA-r9 OPTIONAL,
destinationInfoList-r12 SL-DestinationInfoList-r12
}
SL-CommTxResourceReqUC-r13 :: = SEQENCE {
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 :: = SEQENCE {
carrierFreq-r13 ARFCN-ValueEUTRA-r9 OPTIONAL,
discTxResourceReq-r13 INTER (1..63)
}
SL-DestinationInfoList-r12 :: = SEQUENCE (SIZE (1..max SL-Dest-r12)) OF SL-DestinationIdentity-r12
SL-DestinationIdentity-r12 :: = BIT STRING (SIZE (24))
SL-DestinationInfoListUC-r13 :: = SL-DestinationInfoList-r12
SL-SysInfoReportList-r13 :: = SEQENCE (SIZE (1..maxSL-DiscSysInfoReportFreq-r13)) OF SL-SysInfoReport-r13
SidelinkUEInformation-v14x0-IEs :: = SEQENCE {
comTxResourceReq121-r14 SL-CommTxResourceReq-14 OPTIONAL,
.. .. .. .. .. }
SL-CommTxResourceReq-r14 :: = SEQENCE {
carrierFreq-r14 ARFCN-ValueEUTRA-r9 Optical
destinationInfoListUC-r14 SL-DestinationInfoList-r14
SL-Traffic-r14 SL-TrafficList-r14 Optical
}
SL-TrafficList-r14 :: = SEQENCE (SIZE (1..maxSL-Traffic-r14)) OF SL-TrafficType-r14
SL-TrafficType-r14 :: = SEQENCE {
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 in the Sidelink UE Information message of this embodiment of the first embodiment are bold and framed above. It is then clear that there are periodic fields that allow CAM messages to exhibit a variety of different periodicities, such as those mentioned above. Similarly, a message size field is provided that allows each to indicate a variety of different message sizes, each with a value of 1 to 300 bytes. Optionally, the traffic type field allows the UE to inform the eNodeB whether the data is periodic or aperiodic.

Alternatively, instead of indicating the message size along with the possible periodicity, according to a further variation of the first embodiment, the message size (ie, the amount of data the UE wants to send) is with the buffer state notification. And the buffer status notification indicates that the data is waiting to be transmitted by the vehicle UE. In this case, in one example of the preparation phase, the eNodeB receives only information about possible different periodicities, not information about possible different message sizes, and thus may have different periodicities. Based on the information in, proceed to prepare different SPS settings. For example, the multiple SPS settings provided by eNodeB differ in terms of periodicity, but it is not clear which radio resources and how many radio resources are allocated by the SPS settings. Then, when the vehicle UE actually wants to start transmitting one or more of the possible data components, it triggers that the corresponding buffer is filled and, as a result, a buffer status notification is sent to the eNodeB. And based on that, it may actually determine the amount of data the UE wants to communicate with for one or more possible data components. Correspondingly, the eNodeB selects and activates the corresponding appropriate SPS settings (of the corresponding appropriate periodicity) and then activates the selected SPS settings for the vehicle UE, while simultaneously activating each of them. For activated SPS settings, it shows which resources are allocated by each activated SPS setting.

In other words, unlike previously described in association with FIGS. 11-15, in this particular variant of the first embodiment, the eNodeB pre-defines a radio resource (eg, transmits 122 bytes). SPS setting that defines sufficient radio resources for 1) is not performed, and only periodicity is specified. For example, the eNodeB may provide SPS setting 1 to support transmission of CAM HF components by the vehicle UE with a periodicity of 100 ms (assuming a speed range greater than 144 km / h), as well as other SPS settings. The same is true. For the scenario envisioned for FIG. 12, eNodeB thus provides three different SPS settings for each of the three periodicities of 100 ms, 500 ms, and 1000 ms. For the scenario assumed for FIG. 14, eNodeB prepares nine different SPS settings, three for each speed range.

According to another exemplary embodiment of the first embodiment, in addition to or instead of transmitting information about possible different periodicities and / or possible different message sizes. The vehicle UE may notify the eNodeB of certain data components that the vehicle UE is supported to transmit. For example, thus, the periodicity information may include a list that identifies the data components that the vehicle UE is supported to transmit in the future. The eNodeB can access information about possible periodicity and message size associated with these identified data components, for example, the 3GPP standard may have different CAMs and them. Size and periodicity can be explicitly defined for the components of. In this way, the eNodeB is thus able to provide the appropriate SPS settings for the various different periodicities and / or message sizes supported.

Although not specified in detail above, the activation command sent by the eNodeB to the vehicle UE to activate the selected SPS configuration is exemplary as a message sent over the PDCCH or physical downlink control channel. Can be implemented in. For example, in a manner similar to that for the currently specified SPS mechanism, the eNodeB may send one or more DCIs to activate one or more of the previously set SPS settings. In one example, the UE needs to know that the DCI is for the sidelink SPS, not the Uu SPS or Uulink dynamic allocation, so a new C for the DCI for sidelink activation / deactivation. -RNTI can be used. As mentioned above, for a particular embodiment of the first embodiment, the PDCCH message may also identify a particular radio resource that the UE is to use for the activated SPS configuration.

Although not specified in detail above, the eNodeB shall notify the UE of the plurality of SPS settings after determining the plurality of SPS settings. This can be implemented, for example, as an RRC message such as sps-Config Sidelink in a radioRelocationConfigDedicated message. The current SPS settings for the Uu link are transmitted within the radioRelocationConfigDedicated message. A new element can be generated as a sps-Config Sidelink to indicate the SPS configuration for the sidelink, which can also be sent within the radioRelocationConfigDedicated message. As described above, the multiple SPS settings set by the eNodeB during the preparation phase can, for example, identify both periodicity and radio resources, or can only set periodicity (in this case). The radio resource can then be identified along with the activation command sent from the eNodeB to the UE).

Although embodiments of the first embodiment have been described based on V2V and a vehicle UE that communicates with other vehicle UEs via a side link connection, the underlying principles of the first embodiment have been described. It can also be applied to transmit vehicle data between the vehicle UE and the eNodeB via the Uu interface, or between the vehicle UE and the roadside machine, for example via the PC5 interface.

Furthermore, although embodiments of the first embodiment have been described based on the vehicle UE, the underlying principle of the first embodiment is with the eNB via a side link connection, or other "ordinary". It can also be performed by a "normal" UE that communicates with the "no" or UE for the vehicle.

<Implementation of this disclosure by hardware and software>
Another exemplary embodiment relates to embodiments of the various embodiments described above that use hardware, software, or software that works with the hardware. In this regard, a user terminal (mobile terminal) is provided. The user terminal is adapted to perform the methods described herein, including corresponding entities such as receivers, transmitters, processors, etc. that are appropriately involved in these methods.

Various embodiments are further recognized as being able to be implemented or implemented using a computing device (processor). The computing device or processor may be, for example, a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable logic device. Various embodiments may be implemented or embodied by a combination of these devices. Specifically, each functional block used in each description of the above-described embodiment can be realized by an LSI as an integrated circuit. These functional blocks may be formed individually as chips, or one chip may be formed so as to include a part or all of the functional blocks. These chips may include a data input / output unit that is coupled to them. Here, the LSI may also be referred to as an IC, a system LSI, a super LSI, or an ultra LSI, depending on the difference in the degree of integration. However, the technique for implementing an integrated circuit is not limited to LSI, and may be realized by using a dedicated circuit or a general-purpose processor. Also, using an FPGA (Field Programmable Gate Array) that can be programmed after the LSI is manufactured, or a reconfigurable processor that can reconfigure the connection and settings of the circuit cells located inside the LSI. May be good.

Furthermore, various embodiments may be implemented by software modules, which are executed by the processor or directly in hardware. In addition, a combination of a software module and a hardware implementation may be possible. The software module may be stored in any kind of computer-readable storage medium, such as RAM, EPROM, EEPROM, flash memory, registers, hard disks, CD-ROMs, DVDs, and the like. It should be further noted that the individual characteristics of a number of different embodiments can be the subject of another embodiment, either individually or in any combination.

It will be appreciated by those skilled in the art that various changes and / or modifications to the present disclosure set forth in the specific embodiments may be made. Therefore, this embodiment should be regarded as exemplary in all respects and not intended to be limiting.

Claims (9)

An integrated circuit that controls the processing of a vehicle mobile terminal to transmit periodic data to one or more receiving entities.
The vehicle mobile terminal supports the transmission of said periodic data, including one or more different data components that should be transmitted with possible different transmission cycles and / or potentially different message sizes. However, the above processing
It is a transmission process that transmits information about the periodic data to a radio base station that is responsible for allocating radio resources to the mobile terminal for vehicles, and the transmitted information regarding the periodic data is transmitted by the radio base station. The transmission process and the transmission process, which allows the possible different transmission periodicity and / or the possible different message sizes of the one or more data components of the periodic data.
A reception process for receiving a plurality of semi-persistent radio resource settings set by the radio base station from the radio base station based on the transmitted information regarding the periodic data, wherein the plurality of semi-persistent radio resource settings are received. Each of the stent radio resource configurations includes said reception processing, which can be used to transmit at least one of the supported data components.
The transmission process is performed so as to indicate to the radio base station that one or more of the data components should be transmitted by the vehicle mobile terminal.
The receive process activates one or more of the plurality of semi-persistent radio resource settings for periodically allocating radio resources for the vehicle mobile terminal to transmit each of the data components. The conversion command is received from the radio base station.
The transmission process may include the one or more data components based on the radio resource and the transmission periodicity as set by the activated one or more semi-persistent radio resource settings. Performed to send to multiple receiving entities,
Integrated circuit. The transmitted information regarding the periodic data is
Information about some or all of the one or more data components, said with different transmission cycles and / or with possible different message sizes, transmitted by the vehicle mobile terminal. The information about the message size of at least one data component to be sent is transmitted by the vehicle mobile terminal along with a buffer status notification indicating that the data is waiting to be transmitted for the one data component. , Information, or
To allow the radio base station to determine the possible different transmission cycles and / or the possible different message sizes based on the received information about the different possible data components. Includes information about the different data components.
The integrated circuit according to claim 1. The transmission process is performed so as to transmit information about the vehicle parameters indicating the vehicle dynamics including at least the speed supported by the mobile terminal for the vehicle to the radio base station, and the information regarding the vehicle parameters is the same. It can be used by said radio base station to determine said said possible different transmission periodicity of one or more supported data components.
The transmission process is performed so as to transmit the information regarding the vehicle parameter currently experienced by the vehicle mobile terminal to the radio base station, and the information regarding the vehicle parameter currently experienced is activated. The information regarding the current vehicle parameters can be used by the radio base station to select said one or more of said multiple semi-persistent radio resource settings to be made by one or more data components. Transmitted with instructions that it should be transmitted by the vehicle mobile terminal,
The integrated circuit according to claim 1 or 2. When one of the vehicle parameters changes by a predetermined threshold value or more, the transmission process is performed so as to transmit information about the changed vehicle parameter to the radio base station, and the reception process is performed on the radio base station. In reply from, to receive additional activation commands to activate other semi-persistent radio resource settings instead of the pre-activated semi-persistent radio resource settings, or
When one of the vehicle parameters changes by a predetermined threshold value or more, the transmission process activates the semi-persistent radio resource setting other than the pre-activated semi-persistent radio resource setting. The reception process activates the other requested semi-persistent radio resource settings in place of the pre-activated semi-persistent radio resource settings in reply from the radio base station. It is done to receive further activation commands to make it
The transmission process is to transmit the one or more data components based on the radio resource and the transmission periodicity, as set by the other activated semi-persistent radio resource settings. we,
The further activation command is received within a message via the PDCCH or Physical Downlink Control Channel.
The integrated circuit according to claim 3. The information about the periodic data is transmitted or transmitted in one message.
The information about the periodic data is transmitted in at least two separate messages, and the information about the possible different periodicities of the one or more supported data components is in the first message. Information about the message size of at least one data component transmitted and to be transmitted by the vehicle mobile terminal is accompanied by a buffer state notification indicating that the data of the one data component is waiting for transmission. , Transmitted by the vehicle mobile terminal,
The integrated circuit according to any one of claims 1 to 4. Each of the multiple semi-persistent radio resource settings received is
The radio resource and periodicity suitable for transmitting at least one of the supported data components, the plurality of semi-persistent radio resource settings, are radio resource control (Radio Resource Control) or RRC protocol messages. Radio resources and periodicity received within, or
The information about the radio resource that is periodic to transmit at least one of the data components and can be used by the vehicle mobile terminal to transmit at least one of the data components is said to be plural. Received in conjunction with the activation command for activating one or more of the semi-persistent radio resource configurations of the activation command, and the information about the radio resource via the PDCCH or physical downlink control channel. Identify the periodicity, received in the message
The integrated circuit according to any one of claims 1 to 5. The data component, which should be sent in the same time instance, is sent as either a single message or a separate message.
The integrated circuit according to any one of claims 1 to 6. The receiving entity comprises other vehicle or non-vehicle mobile terminals, said periodic data is transmitted over a side link connection, and / or said receiving entity comprises said radio base station. , The periodic data is transmitted over a wireless connection,
The integrated circuit according to any one of claims 1 to 7. The plurality of semi-persistent radio resource settings are set so that there is one semi-persistent radio resource setting for each data component having a unique message size and a unique transmission periodicity.
The data components transmitted in the same time instance are transmitted as one message, and the plurality of semi-persistent radio resource settings include one or more of the data components to be transmitted by the vehicle mobile terminal. For each possible message, one semi-persistent radio resource setting was set to exist and the transmission process was activated corresponding to the included data component of the message to be transmitted. Based on the semi-persistent radio resource configuration, the message containing the one or more data components is to be transmitted.
The integrated circuit according to any one of claims 1 to 8.

Images