Vehicle to Pedestrian (V2P) is one of the V2X scenarios, which enables communication between vehicles and pedestrians for both safety and traffic efficiency related applications. One of the key V2P applications is the Vulnerable Road User Protection (VRUP) as specified in
ETSI TS 103 300-2 [13]. VRUP provides warning to vehicles of the presence of vulnerable road users, e.g. pedestrian or cyclist, in case of dangerous situation. In VRUP, multiple V2X messages need to be exchanged between the pedestrian and the vehicular UEs, originating by one or more applications. Such messages can be standard VRU messages (e.g. VAM) and other V2X messages (CAM, DENM, BSM, CPM) and can be exchanged via different transmission modes (unicast, groupcast, broadcast).
In such scenario, one challenge is that a pedestrian UE might have a lower battery capacity and limited radio capability, and therefore may have to work in a low power consumption mode, e.g. not being able to send/receive V2X messages with the same periodicity as a Vehicular UE. Continuous sending/receiving V2X messages by the pedestrian UE would affect UE power efficiency. A further challenge is that multiple applications related to VRU may be deployed, which may have differentiated traffic/QoS requirements as well as transmission/reception schedules.
The VAE layer may provide support functionality for enabling V2P applications, by consolidating the V2P application requirements and aligning the communication traffic pattern with the PC5 QoS setting and the AS layer configurations (e.g. DRX cycles).
Table 9.22.2.1-1 describes information elements for the V2P application requirement request from the V2X Application Specific Server (VASS) to the VAE server or from the V2X application specific client to the VAE client.
Information element |
Status |
Description |
Requestor ID | M | The identifier of the service requestor (VASS, VAL server, App ID). |
V2X service ID | M | V2X service ID |
V2X group ID | M | V2X group ID |
V2P QoS requirements | M | The application QoS requirements (reliability, delay, jitter) for the V2P service. |
Application Traffic Pattern | M | The application transmission cycle or traffic schedule for the V2P service. This may be in form of a schedule of an expected transmission/reception of a V2X message over a pre-defined time window. |
PC5 Provisioning policies/ parameters | O | PC5 provisioning policies/parameters to be used by the V2X-UEs within the V2X service (list provided in TS 23.287). |
NOTE:
One of these shall be present.
|
Table 9.22.2.2-1 describes information elements for the V2P application requirement response from the VAE server to V2X Application Specific Server or from the VAE client to the V2X application specific client.
Information element |
Status |
Description |
Result | M | The result of the V2P application requirement request (positive or negative acknowledgement). |
Table 9.22.2.3-1 describes information elements for the V2P schedule configuration request from the VAE server to the VAE clients.
Information element |
Status |
Description |
VAE server ID | M | The identifier of the VAE server. |
V2X service ID | M
(see NOTE) | The V2X service ID for which the configuration request applies. |
V2X group ID | M
(see NOTE) | Identity of the V2X group for which the configuration request applies. |
Traffic Communication pattern | M | The traffic communication pattern includes the information for the V2P communication transmission/reception schedule, and optionally the inactivity period, sleep period. |
DRX cycle configuration | O | The DRX cycle configuration for out of coverage and groupcast/broadcast communications. |
V2P QoS requirements | O | The application QoS requirements (reliability, delay, jitter) for the V2P service. |
NOTE:
One of these shall be present.
|
Table 9.22.2.4-1 describes information elements for the V2P schedule configuration response from the VAE client to the VAE server.
Information element |
Status |
Description |
Result | M | The result corresponding to the V2P schedule configuration request. |
Table 9.22.2.5-1 describes information elements for the V2P schedule notification from the VAE client to the V2X app specific client.
Information element |
Status |
Description |
V2X service ID | M | The V2X service ID for which the configuration corresponds to. |
Traffic Communication pattern | M | The traffic communication pattern includes the information for the V2P communication transmission/reception schedule, and optionally the inactivity period, sleep period. |
DRX cycle configuration | O | The DRX cycle configuration for out of coverage and groupcast/broadcast communications. |
Table 9.22.2.6-1 describes information elements for the V2P schedule update request from a first VAE client to a second VAE client.
Information element |
Status |
Description |
VAE client ID | M | The identifier of the VAE client. |
V2X service ID | M
(see NOTE) | The V2X service ID for which the schedule update applies. |
V2X group ID | M
(see NOTE) | Identity of the V2X group for which the schedule update applies. |
Proposed Traffic Communication pattern | M | The proposed consolidated traffic communication pattern includes the information for the V2P communication transmission/reception schedule, and optionally the inactivity period, sleep period. |
NOTE:
One of these shall be present.
|
Table 9.22.2.7-1 describes information elements for the V2P schedule update response from the second VAE client to the first VAE client.
Information element |
Status |
Description |
Result | M | The result corresponding to the V2P schedule update request. |
Cause | O | The cause in case of negative result. |
Updated Traffic Communication pattern | O | The updated (after negotiation) traffic communication pattern. |
This subclause describes the procedure for V2P communication schedule configuration and update support by the VAE server.
Figure 9.22.3.1-1 illustrates the procedure where the VAE server configures the traffic schedule for V2P communications based on application requirement; and communicates with the VAE clients to trigger the translation to an AS layer/ QoS configurations update.
Pre-conditions:
-
V2X Application Specific Server has subscribed to VAE server to provide support for V2P communication.
-
VAE client of V2X UE #1 and V2X UE #2 are registered with VAE server.
Step 1.
A V2P application specific server provides the V2P application requirements in form of a request to the VAE server, including application QoS requirements for the V2P applications and provisioning policies and parameters for the PC5 communication.
Step 2.
The VAE server authorizes the request and sends a V2P application requirement response.
Step 3.
The VAE server generates a communication schedule for one or more involved V2X UEs, so that the off duration is maximized. The determination of the transmission schedule can be determined based on the V2P service KPIs. Such communication schedule may include the transmission/reception schedule for the application messages and may also include the DRX cycle configuration for out of coverage and groupcast/broadcast communications.
Step 4.
The VAE server sends a V2P communication schedule configuration request message to the involved VAE clients. This includes the generated UE level transmission schedules and may also include the DRX cycle configuration for PC5 communication in out of coverage and groupcast/broadcast modes.
Step 5.
V2X UE #1's and V2X UE #2's VAE clients provide the updated traffic pattern as V2X Application Requirements to V2X layer, also including QoS requirements such as delay requirements, priority, etc., for the PC5 communication for both applications, as specified in
clause 5.4.1.1 of TS 23.287. VAE client may also indicate the transmission mode (unicast, groupcast) per application. The V2X layer of UEs #1 and #2 process the requirements from VAE client and generates a UE level DRX schedule. The AS layer of UE #1 and #2 applies/configures the DRX schedule for the corresponding V2X communication.
Step 6.
VAE clients of V2X UEs #1 and #2 send a response to the configuration request as positive or negative acknowledgement to the VAE server.
Step 7.
VAE clients of V2X UEs #1 and #2 may send a notification to the V2X application specific client(s) to inform on the communication traffic pattern.
This subclause describes the procedure for V2P communication schedule configuration and update support by the VAE client.
Figure 9.22.3.2-1 illustrates the procedure where the VAE client configures the traffic schedule for V2P communications based on application requirement; and triggers the translation to an AS layer/ QoS configurations update.
Pre-conditions:
-
VAE client 1 has been configured by the VAE server to configure the communication schedule for V2P communications.
-
V2X UE #1 and V2X UE#2 have discovered each other based upon V2P service and established a unicast connection using the V2X Service oriented Layer-2 link establishment procedure as specified in clause 6.3.3.1 of TS 23.287.
Step 1.
On V2X UE #1, one or more V2X application specific clients send V2P application requirement request to the VAE client, including application QoS requirements for the V2P applications and provisioning policies and parameters for the PC5 communication.
Step 2.
The VAE client sends a V2P application requirement response to the requestor V2X application specific client (s).
Step 3.
V2X UE #1's VAE client consolidates requirements (from one or more application specific clients) and generates a UE level transmission schedule, so that the off-duration is maximized. The determination of the transmission schedule can be determined based on the configuration on the UE (energy efficiency target) and the service KPIs.
Step 4.
V2X UE #1's VAE client sends a V2P communication schedule update request which includes the generated UE level transmission schedule to other VAE client 2 (in vicinity, or in service-based group), in order to negotiate the optimal transmission pattern or inform on the expected reception pattern.
Step 5.
V2X UE #2's VAE client optionally generates or updates the communication schedule for V2X UE #2, based on step 4, or negotiates the traffic pattern.
Step 6.
VAE client of V2X UE #2 may send a V2P communication schedule update response indicating the result or an expected/generated UE #2 transmission pattern (in case of negotiation).
Step 7.
V2X UE #1's and V2X UE #2's VAE clients provide the updated traffic pattern as V2X Application Requirements to V2X layer, also including QoS requirements such as delay requirements, priority, etc., for the PC5 communication for both applications, as specified in
clause 5.4.1.1 of TS 23.287. VAE client may also indicate the transmission mode (unicast, groupcast) per application. The V2X layer of UEs #1 and #2 process the requirements from VAE client and generates a UE level DRX schedule. The AS layer of UE #1 and #2 applies/configures the DRX schedule for the corresponding V2X communication.
Step 8.
VAE clients of V2X UEs #1 and #2 may send a V2P schedule notification to the V2X application specific client(s) to inform on the communication traffic pattern.