Content for TS 23.286 Word version: 18.0.0
9.17 V2X groupcast/broadcast configuration by VAE layer
9.17.1 General
9.17.2 Information flows
9.17.3 V2X groupcast/broadcast configuration by VAE layer
9.17.4 V2X groupcast/broadcast delivery by VAE layer
9.18 Local MBMS support
9.19 Session-oriented services
9.19.1 General
9.19.2 Information flows
9.19.3 UE initiated session-oriented service
9.19.4 V2X application specific server triggered session-oriented service
9.19.5 Session-oriented service
9.20 Monitoring and control of QoS for eV2X communications
9.20.1 General
9.20.2 Information flows
9.20.3 Subscription Procedure
9.20.4 Notification Procedure
9.21 Support for VRU zone configuration and operation
...
...
9.17 V2X groupcast/broadcast configuration by VAE layer |R17| p. 81
9.17.1 General p. 81
The VAE client configures policies for the UE-to-UE broadcast/groupcast delivery, based on the requirement received by the VAE server, to reduce V2X broadcast flooding, while ensuring meeting the KPIs for one or more V2X services in a service area.
Following procedures are provided for this feature:
the UE-to-UE broadcast/groupcast configuration by VAE client as specified in clause 9.17.3; and
the UE-to-UE delivery which is handled by VAE clients over V5-AE as specified in clause 9.17.4.
9.17.2 Information flows p. 81
9.17.2.1 V2V configuration requirement request p. 81
Table 9.17.2.1-1 describes the information flow V2V configuration requirement request from the V2X application specific server to the VAE server.
| Information Element | Status | Description |
|---|---|---|
| V2X group ID | M (NOTE) | Identity of the V2X group for which the V2X application requirement is initiated |
| V2X service ID | M (NOTE) | The V2X service ID for which application requirement corresponds to |
| Candidate Relay V2X-UE ID list | O | List of identities of the V2X UEs, which are candidate to serve as application layer relays |
| V2X application QoS requirements | O | The application QoS requirements (reliability, delay, jitter) for the V2X service |
|
NOTE:
Either of the information element should be present.
|
||
9.17.2.2 V2V configuration requirement response p. 81
Table 9.17.2.2-1 describes the information flow V2V configuration requirement response from the VAE server to the V2X application specific server.
| Information Element | Status | Description |
|---|---|---|
| Result | M | The result corresponding to the V2V configuration requirement request |
9.17.2.3 V2X groupcast/broadcast configuration request p. 82
Table 9.17.2.3-1 describes the information flow V2X groupcast/broadcast configuration request from the VAE server to the VAE client.
| Information Element | Status | Description |
|---|---|---|
| VAE Server ID | M | Identity of the VAE server which is requester of the V2X groupcast/broadcast configuration |
| V2X group ID | M (NOTE) | Identity of the V2X group for which the V2X groupcast/broadcast configuration is requested |
| V2X service ID | M (NOTE) | The V2X service ID for which the groupcast/broadcast configuration is requested |
| PC5 Provisioning policies/ parameters | M | PC5 provisioning policies/parameters to be used by the V2X-UEs within the V2X service (list provided in TS 23.287) |
| Relay V2X-UE ID list | O | List of identities of the V2X UEs to serve as application layer relays |
| Minimum number of re-transmissions | O | Minimum Number of allowed re-transmissions for the V2X message delivery |
9.17.2.4 V2X groupcast/broadcast configuration response p. 82
Table 9.17.2.4-1 describes the information flow V2X groupcast/broadcast configuration response from the VAE client to the VAE server.
| Information Element | Status | Description |
|---|---|---|
| Result | M | The result corresponding to the V2X groupcast/broadcast configuration request |
9.17.2.5 UE-to-UE groupcast/broadcast configuration request p. 82
Table 9.17.2.5-1 describes the information flow UE-to-UE groupcast/broadcast configuration request from a VAE client to another VAE client within the group or the V2X service.
| Information Element | Status | Description |
|---|---|---|
| VAE client ID | M | Identity of the VAE client which is requester of the UE-to-UE groupcast/broadcast configuration |
| V2X group ID | M (NOTE) | Identity of the V2X group for which the UE-to-UE groupcast/broadcast configuration is requested |
| V2X service ID | M (NOTE) | The V2X service ID for which the UE-to-UE groupcast/broadcast configuration is requested |
| UE-to-UE groupcast/broadcast configuration policies/ parameters | M | The requested configuration policies to be applied for the UE-to-UE broadcast/groupcast communications. The policies / parameters may be the following:
|
9.17.2.6 UE-to-UE groupcast/broadcast configuration response p. 83
Table 9.17.2.6-1 describes the information flow UE-to-UE groupcast/broadcast configuration response from a VAE client to another VAE client within the group or the V2X service.
| Information Element | Status | Description |
|---|---|---|
| Result | M | The result corresponding to the UE-to-UE groupcast/broadcast configuration request |
9.17.2.7 VAE message p. 83
Table 9.17.2.7-1 describes the information flow for a VAE client to deliver a VAE message to another VAE client.
| Information Element | Status | Description |
|---|---|---|
| VAE client ID | M | Identity of the VAE client which provides the V2X message |
| V2X group ID | M (NOTE 1) | Identity of the V2X group (for groupcast delivery) |
| V2X service ID | M (NOTE 1) | Identity of the V2X service (for broadcast delivery) |
| V2X Message ID(s) | O | Identity of the V2X message(s) within the VAE message (CPM, PCM, MCM, DENM) |
| Management Container | O | Management Container provides basic information about the transmitter, including the V2X-UE type (e.g. vehicle or RSU) and position |
| VAE payload | M | V2X message(s) payload carried by the VAE message |
|
NOTE 1:
Either of the information element should be present.
NOTE 2:
One or more V2X messages may be carried within a VAE payload (e.g. CPM, PCM, MCM, DENM) depending on whether V2X message bundling is activated
|
||
9.17.3 V2X groupcast/broadcast configuration by VAE layer p. 84
9.17.3.1 General p. 84
This subclause describes the procedure for V2X groupcast/broadcast configuration by the VAE layer.
9.17.3.2 Procedure p. 84
Figure 9.17.3.2-1 illustrates the procedure where the VAE client configures policies for the UE-to-UE broadcast/ groupcast delivery to other VAE clients (within the V2X group or the V2X service), based on the requirement received by the VAE server.
Pre-conditions:
- The V2X UEs have connected to the V2X application server.
- VAE client 1 is registered with VAE server.
Figure 9.17.3.2-1: V2V groupcast/broadcast configuration by VAE layer
(⇒ copy of original 3GPP image)
(⇒ copy of original 3GPP image)
Step 1.
The V2X application specific server provides an V2V configuration requirement request to the VAE server to manage the UE-to-UE broadcast/groupcast communication. The VAE server may also provide within the request the list of V2X-UEs which are capable to serve as application layer relays.
Step 2.
The VAE server sends a V2V configuration requirement response to the V2X application specific server.
Step 3.
The VAE server provides a V2V broadcast/groupcast configuration request to VAE client 1. The VAE server may also provide within the request the list of V2X-UEs to serve as application layer relays based on the candidate list of relay V2X-UEs provided in step 1.
Step 4.
The VAE client 1 selects and stores one or more UE-to-UE groupcast/broadcast configuration policies per V2X application for the UE-to-UE broadcast/groupcast communications.
Step 5.
The VAE client 1 sends a V2V broadcast/groupcast configuration response to VAE server to notify on the result.
Step 6.
The VAE client 1 sends a request to VAE client N (can be any VAE client within the V2X group or V2X service) with the requested UE-to-UE groupcast/broadcast configuration policies for the UE-to-UE broadcast/groupcast communications.
Step 7.
The VAE client 1 receives a response from the VAE client 2, which includes either a positive or a negative acknowledgement of the message.
9.17.4 V2X groupcast/broadcast delivery by VAE layer p. 85
9.17.4.1 General p. 85
This subclause describes the procedure for V2X groupcast/broadcast delivery by the VAE layer.
9.17.4.2 Procedure p. 85
Figure 9.17.4.2-1 illustrates the procedure where the VAE client delivers the VAE message based on the configured policies (based on the procedure in clause 9.17.3).
Pre-conditions:
- The VAE clients of the V2X-UEs have received and stored the UE-to-UE broadcast/groupcast configuration policies per V2X application.
Step 1.
The V2X application specific client of the V2X UE 1 sends to the VAE client 1, the V2X message to be broadcasted/groupcasted. This message may be for example a PCM, CPM, MCM, DENM.
Step 2.
The VAE client 1 retrieves the mapping for the V2X service and configuration policy related to the V2X message. The VAE client 1 forms a VAE message, based on the V2X message(s) and the applied configuration policy.
Step 3.
The VAE message is sent from the transmitting V2X-UE 1 to the receiving V2X-UE N (which may be application relay or destination V2X-UEs). For the case when a V2X-UE acts as application relay, the message is relayed towards the destination VAE client.
Step 4.
The V2X message is provided from the destination VAE client to the corresponding V2X application specific client. In case of message bundling, the receiving VAE client first un-bundles the V2X message and then sends to the V2X application specific client.
9.18 Local MBMS support |R17| p. 86
For local MBMS based MBMS data delivery as defined in TS 23.285, the BM-SC can be provided with the local MBMS information (i.e. M1 interface information including transport network IP Multicast Address, IP address of multicast source and C-TEID, as well as MB2-U or xMB-U interface information including IP address and UDP port number for the user plane) from the V2X application plane. Such local MBMS information can be pre-configured in the VAE server based on service requirements or deployment needs. The VAE server may request SEAL NRM server to establish the MBMS bearers by providing the local MBMS information as described in subclause 14.3.4.3.2 of TS 23.434 and subclause 14.3.4.3.2 of TS 23.434.
9.19 Session-oriented services |R17| p. 86
9.19.1 General p. 86
The VAE layer provides support at the application layer for V2X application specific server and V2X UE to initiate session-oriented services by providing mechanisms for establishing, updating and terminating sessions.
9.19.2 Information flows p. 86
9.19.2.1 Session-oriented service trigger request p. 86
Table 9.19.2.1-1 describes the information flow session-oriented service trigger request from the V2X application specific server to the VAE server.
| Information element | Status | Description |
|---|---|---|
| Remote V2X UE ID | M | Identity of the V2X UE (VAE client) which is the remote vehicle. |
| V2X service ID | M | The V2X service ID for which application requirement corresponds to. |
| V2X application specific server identity information | M | Identity information of the V2X application specific server. |
| Session ID | O | The session identifier to be used for the session-oriented service. |
| V2X application QoS requirements for the session | O | The application QoS requirements (reliability, delay, jitter) for the session-oriented service. |
9.19.2.2 Session-oriented service trigger response p. 86
Table 9.19.2.2-1 describes the information flow session-oriented service trigger response from the VAE server to the V2X application specific server.
| Information element | Status | Description |
|---|---|---|
| Acknowledgement | M | Acknowledgement for the request |
9.19.2.3 Session-oriented service establishment notification p. 86
Table 9.19.2.3-1 describes the information flow session-oriented service establishment notification from the VAE server to the V2X application specific server.
| Information element | Status | Description |
|---|---|---|
| Result | M | The result indicating success or failure to establish session-oriented service |
| Remote V2X UE ID | M | Identity of the V2X UE (VAE client) which is the remote vehicle. |
| Session ID | O (NOTE) | The session identifier to be used for the session-oriented service. |
|
NOTE:
This IE is present when Result is success. It is generated by the VAE server if not provided by the requester.
|
||
9.19.2.4 Session-oriented change trigger request p. 87
Table 9.19.2.4-1 describes the information flow session-oriented change trigger request from the V2X application specific server to the VAE server.
| Information element | Status | Description |
|---|---|---|
| Session ID | M | The session identifier of the session-oriented service. |
| V2X application QoS requirements for the session | M | The application QoS requirements (reliability, delay, jitter) for the session-oriented service that is to be updated. |
9.19.2.5 Session-oriented change trigger response p. 87
Table 9.19.2.5-1 describes the information flow session-oriented change trigger response from the VAE server to the V2X application specific server.
| Information element | Status | Description |
|---|---|---|
| Acknowledgement | M | Acknowledgement for the request |
9.19.2.6 Session-oriented service change notification p. 87
Table 9.19.2.6-1 describes the information flow session-oriented service change notification from the VAE server to the V2X application specific server.
| Information element | Status | Description |
|---|---|---|
| Result | M | The result indicating success or failure to change session-oriented service |
9.19.2.7 Session-oriented termination trigger request p. 87
Table 9.19.2.7-1 describes the information flow session-oriented termination trigger request from the V2X application specific server to the VAE server.
| Information element | Status | Description |
|---|---|---|
| Session ID | M | The session identifier of the session-oriented service. |
9.19.2.8 Session-oriented termination trigger response p. 88
Table 9.19.2.8-1 describes the information flow session-oriented termination trigger response from the VAE server to the V2X application specific server.
| Information element | Status | Description |
|---|---|---|
| Acknowledgement | M | Acknowledgement for the request |
9.19.2.9 Session-oriented service termination notification p. 88
Table 9.19.2.9-1 describes the information flow session-oriented service termination notification from the VAE server to the V2X application specific server.
| Information element | Status | Description |
|---|---|---|
| Result | M | The result indicating success or failure to terminate session-oriented service |
9.19.3 UE initiated session-oriented service p. 88
9.19.3.1 General p. 88
The VAE layer provides support at the application layer for V2X UE to initiate session-oriented services by providing mechanisms for establishing, updating and terminating sessions.
9.19.3.2 UE initiated session-oriented service establishment p. 88
Pre-conditions:
- The V2X UE (acting as remote controller) has been authenticated for using session-oriented services and has connected to the VAE server.
- The V2X application-specific client has triggered the VAE client to establish a session with the remote V2X UE (vehicle).
Figure 9.19.3.2-1: Procedure for establishing a UE initiated session-oriented service between the VAE client (remote controller) and the VAE client (remote vehicle)
(⇒ copy of original 3GPP image)
(⇒ copy of original 3GPP image)
Step 1.
The VAE client (acting as remote controller) sends a trigger request to the VAE server to establish a session-oriented service with one or more V2X UEs (remote vehicle). It may include the identity of the VAE client, the identity of the service session, the V2X service ID, the "type" or "QoS requirements" of the session, service information (e.g. geo-referenced information for tele-operated driving service in the form of geographical area where the service is expected to be delivered or in the form of expected/planned vehicle trajectory, or time interval during which the service is expected) and requirements (e.g. reporting configuration).
Step 2.
The VAE server checks whether the VAE client is authorized to establish session-oriented service with one or more V2X UEs (remote vehicles). The VAE server provides a session-oriented service trigger response to the VAE client indicating the ability or inability of VAE server to initiate a session-oriented service with the VAE client. The VAE server performs the procedure to establish session oriented service with VAE client (e.g. remote vehicle).
9.19.3.3 UE initiated session-oriented service update p. 89
Pre-condition:
- The VAE client (remote controller) has established a session-oriented service with a VAE client (remote vehicle) via the VAE server.
Figure 9.19.3.3-1: Procedure for updating an UE initiated session-oriented service between the VAE client (remote controller) and the VAE client (remote vehicle)
(⇒ copy of original 3GPP image)
(⇒ copy of original 3GPP image)
Step 1.
The VAE client (acting as remote controller) sends a change trigger request to the VAE server to update the session-oriented service to one or more VAE clients (remote vehicle) including the identity of the service session, updates to service information (e.g. activated services, updates to vehicle trajectory), requirements (e.g. change of network/QoS requirements), or server information (e.g. change of VAE server).
Step 2.
The VAE server provides a session-oriented change trigger response to the VAE client indicating the ability or inability of VAE server to continue the session-oriented service with the VAE client with the updated conditions. The VAE server performs the procedure to change session oriented service with VAE client (e.g. remote vehicle).
9.19.3.4 UE initiated session-oriented service termination p. 89
Pre-condition:
- The VAE client (remote controller) has established a session-oriented service with the VAE client (remote vehicle).
Figure 9.19.3.4-1: Procedure for terminating an UE initiated session-oriented service between the VAE client (remote controller) and the VAE client (remote vehicle)
(⇒ copy of original 3GPP image)
(⇒ copy of original 3GPP image)
Step 1.
The VAE client (acting as remote controller) sends a session-oriented termination trigger request to the VAE server to terminate the session (e.g. end of session with VAE server or requirements for session-oriented service not satisfied) with one or more V2X UEs (remote vehicles) including the identity of the service session.
Step 2.
The VAE server sends a session-oriented termination trigger response to the VAE client indicating the result of the session-oriented service termination with one or more V2X UEs (remote vehicles). The VAE server performs the session-oriented service termination procedure to terminate session oriented service with VAE client (e.g. remote vehicle).
9.19.4 V2X application specific server triggered session-oriented service p. 90
9.19.4.1 General p. 90
The VAE layer provides support at the application layer for V2X application specific server triggered session-oriented services by providing mechanisms for establishing, updating and terminating sessions.
9.19.4.2 Triggering of session-oriented service establishment p. 90
Pre-conditions:
- The V2X application-specific server has decided to trigger the session-oriented service.
Figure 9.19.4.2-1: Triggering of session-oriented service establishment
(⇒ copy of original 3GPP image)
(⇒ copy of original 3GPP image)
Step 1.
The V2X application-specific server triggers the VAE server to initiate a session-oriented service to the VAE client. This request can include information such as the identity of the VAE client, the identity of the V2X application specific server, the identity of the service session, the V2X service ID and the "type" or "QoS requirements" of the session.
Step 2.
The VAE server provides a session-oriented service trigger response to the V2X application-specific server indicating the ability or inability of VAE server to initiate a session-oriented service with the VAE client.
9.19.4.3 Triggering of session-oriented service update p. 90
Pre-conditions:
- The VAE server has established a session-oriented service with the VAE client as described in clause 9.19.5.2.
- The V2X application-specific server needs to update parameters of the session.
Step 1.
The V2X application-specific server provides the VAE server with the identity of the session and the update of session parameters, e.g. change of QoS requirements of the session.
Step 2.
The VAE server provides a session-oriented service update response to the V2X application specific server including the ability or inability to continue the session-oriented service with the VAE client with the updated conditions.
9.19.4.4 Triggering of session-oriented service termination p. 91
Pre-conditions:
- The VAE server has established a session-oriented service with the VAE client as described in clause 9.19.5.2.
- The V2X application specific server has decided to terminate the session-oriented service.
Figure 9.19.4.4-1: Triggering of session-oriented service termination
(⇒ copy of original 3GPP image)
(⇒ copy of original 3GPP image)
Step 1.
The V2X application-specific server provides the VAE server with a request to terminate the session-oriented service with the VAE client. It may include the identity of the service session.
Step 2.
The VAE server provides a session-oriented service termination response to the V2X application-specific server that the session can be terminated.
9.19.5 Session-oriented service p. 91
9.19.5.1 General p. 91
The VAE layer provides support at the application layer for session-oriented services by providing mechanisms for establishing, updating and terminating sessions.
9.19.5.2 Session-oriented service establishment p. 91
Pre-conditions:
- The V2X UE has been authenticated for using session-oriented services and has connected to the V2X application server.
- The VAE server has agreed to establish a session upon the request from the V2X application specific server or from the VAE client.
- The V2X application specific client has subscribed with the VAE client to receive notifications related to session-oriented service and the V2X application specific server has subscribed with VAE server to receive notifications related to session-oriented service.
- The V2X application specific client for the terminating V2X UE has been informed about the already negotiated session oriented service to VAE client.
Figure 9.19.5.2-1: Procedure for establishing a session-oriented service between the VAE server and the VAE client
(⇒ copy of original 3GPP image)
(⇒ copy of original 3GPP image)
Step 1.
The VAE server sends a request to one or more VAE clients to establish a session-oriented service including identity of the VAE client, identity of the session, V2X service ID and reporting configuration.
Step 2.
The VAE client sends a session-oriented service response to the VAE server indicating approval of session establishment request by the VAE server.
Step 3.
If V2X application specific server has triggered then, the VAE server sends a session-oriented service establish notification to the V2X application-specific server.
Step 4.
The VAE client sends a session-oriented service establish notification to the V2X application-specific client.
9.19.5.3 Session-oriented service update p. 92
Pre-condition:
- The VAE server has established a session-oriented service with the VAE client.
- The VAE server has received a session-oriented service update from the V2X application-specific server or from the VAE client or a change in QoS and network conditions from 3GPP network system.
- The V2X application specific client has subscribed with the VAE client to receive notifications related to session-oriented service and the V2X application specific server has subscribed with VAE server to receive notifications related to session-oriented service.
- The VAE server has agreed to continue the session-oriented service with the VAE client with the updated conditions upon the request from the V2X application specific server or from the VAE client.
Figure 9.19.5.3-1: Procedure for updating a session-oriented service between the VAE server and the VAE client
(⇒ copy of original 3GPP image)
(⇒ copy of original 3GPP image)
Step 1.
The VAE server sends a change request to one or more VAE clients including the identity of the session, updates requirements (e.g. change of network/QoS requirements), or server information (e.g. change of VAE server).
Step 2.
The VAE client sends a change response to the VAE server indicating acceptance of the change request by the VAE server.
Step 3.
If V2X application specific server has triggered then, the VAE server sends a session-oriented service change notification to the V2X application-specific server.
Step 4.
The VAE client sends a session-oriented service change notification to the V2X application-specific client.
9.19.5.4 Session-oriented service termination p. 93
Pre-condition:
- The VAE server has established a session-oriented service with the VAE client.
- The VAE server has received a session-oriented service termination request from the V2X application-specific server or from the VAE client or a change in QoS or network conditions from 3GPP network system that prevents the VAE server from continuing the session-oriented service.
- The V2X application specific client has subscribed with the VAE client to receive notifications related to session-oriented service and the V2X application specific server has subscribed with VAE server to receive notifications related to session-oriented service.
- The VAE server has indicated to terminate the session-oriented service with the VAE client upon the request from the V2X application specific server or from the VAE client.
Figure 9.19.5.4-1: Procedure for terminating a session-oriented service between the VAE server and the VAE client
(⇒ copy of original 3GPP image)
(⇒ copy of original 3GPP image)
Step 1.
The VAE server sends a session-oriented termination request to the VAE client to terminate the session (e.g. end of session with VAE server or requirements for session-oriented service not satisfied) including the identity of the session.
Step 2.
The VAE client sends a session-oriented termination response to the VAE server indicating acceptance of the termination request by the VAE server.
Step 3.
If V2X application specific server has triggered then, the VAE server sends a session-oriented service termination notification to the V2X application-specific server.
Step 4.
The VAE client sends a session-oriented service termination notification to the V2X application-specific client.
9.20 Monitoring and control of QoS for eV2X communications |R17| p. 93
9.20.1 General p. 93
5GS supports eV2X communications with extended QoS monitoring and reporting.The VAE layer utilizes these monitoring and reporting mechanisms to support control of QoS for eV2X communications. The V2X application specific server subscribes to service adaptation and QoS control events from the VAE layer and receives notifications about the relevant service requirement adaptations and corresponding QoS changes.
9.20.2 Information flows p. 94
9.20.3 Subscription Procedure p. 94
Pre-conditions:
- The VAE server includes an Application Function (AF) functionality, as defined in TS 23.287.
- The VAE server has subscriptions with SEAL servers to receive V2X service-related information (e.g. UE IDs, location, group, configuration info, etc.).
Figure 9.20.3-1: Subscription for monitoring and control of QoS for eV2X communications
(⇒ copy of original 3GPP image)
(⇒ copy of original 3GPP image)
Step 1.
The V2X application specific server sends a service adaptation and QoS control subscription request to the VAE server.
Step 2.
The VAE server, who acts as an AF, subscribes to QoS monitoring service from 5GS (e.g. PCF/NWDAF). This subscription may be active for a certain period of time or a given geographical area. The monitoring may either include the request for QoS sustainability events as specified in TS 23.288, or can include a QoS change notification requests as provided by SMF and specified in TS 23.287. The reporting may be configured by the application enabler layer for a given area, time, periodicity etc taking into account the service requirement and other parameters (e.g. expected congestion in certain area, time of the day, road conditions).
Step 3.
The VAE server sends a service adaptation and QoS control subscription response indicating success or failure of subscription.
9.20.4 Notification Procedure p. 94
Figure 9.20.4-1: Notification for monitoring and control of QoS for eV2X communications
(⇒ copy of original 3GPP image)
(⇒ copy of original 3GPP image)
Step 1.
Based on the subscription, as specified in TS 23.287, 5GS provides the extended QoS monitoring report, over N33 interface. This report may come either from NWDAF or SMF via PCF/NEF.
Step 2.
The VAE server, based on the monitoring events (step 1) for one or multiple V2X-UEs within one service or across multiple services, may trigger a service requirement adaptation (step 3) based on the actual or expected QoS change for one or more V2X services.
Step 3.
The VAE server sends a service requirement adaptation notification request to V2X application specific server to identify the action which is needed, based on the actual or expected QoS change. This could be the adaptation of the Level of Automation (LoA) for one or more V2X-UEs or V2X services.
Step 4.
The V2X application specific server decides whether to adapt the service requirement based on step 3.
Step 5.
The V2X application specific server sends a response to VAE server with a positive or negative acknowledgment. Optionally, this may include the list of a sub-set of V2X-UEs within a service for which the requirement change should be applied
Step 6.
If no QoS adaptation is required, V2X application layer may adapt based on the adapted service requirements; and steps 7-10 are optional.
Step 7.
If a QoS adaptation is required, the VAE server, triggers the adaptation of QoS for the affected V2X-UE(s) within the service or across multiple services in close vicinity.
Step 8.
The VAE server performs network resource adaptation by interacting with the NRM server as specified in the TS 23.434.
Step 9.
The VAE server also notifies about the QoS adaptation to the V2X application specific server.
9.21 Support for VRU zone configuration and operation |R18| p. 96
9.21.1 General p. 96
This capability supports the configuration and provisioning of the VRU high risk zone at the VAE layer based on a request from the V2X application specific server (VASS).
9.21.2 Information flows p. 96
9.21.2.1 VRU zone management subscription request p. 96
Table 9.21.2.1-1 describes information elements for the VRU zone management subscription request from the VASS to the VAE server.
| Information element | Status | Description |
|---|---|---|
| Requestor ID | M | The identifier of the service requestor (VASS, VAL server, App ID) |
| VRU zone ID | O | The identifier of the VRU zone which may be provided by the requestor. |
| VRU zone information | M | This information identifies, based on the VRUP scenario, which type of UEs (V2X UEs, pedestrian UEs) are to be considered. Also, whether it is a static or dynamic zone can be identified. |
| VRU application requirements | M | This includes requirements include the types of supported messages and requirements (e.g. requirements for VAM messages), and application QoS requirement dedicated for the VRU zone (e.g. URLLC like). |
| List of VAL UE IDs | O | The identifiers of the VAL UEs for which the VRU zone is applicable |
| Area of Interest | O | The geographical or service area for which the subscription request applies |
| Time validity | O | The time validity of the request |
9.21.2.2 VRU zone management subscription response p. 96
Table 9.21.2.2-1 describes information elements for the VRU zone management subscription response from the VAE server to VASS.
| Information element | Status | Description |
|---|---|---|
| Result | M | The result of the VRU zone management subscription request (positive or negative acknowledgement) |
9.21.2.3 VRU zone info notification p. 96
Table 9.21.2.3-1 describes information elements for the VRU zone info notification from the VAE server to the VAE clients.
| Information element | Status | Description |
|---|---|---|
| VRU zone ID | M | The identifier of the VRU zone |
| VRU zone information | M | This information identifies based on the VRUP scenario, which type of UEs (V2X UEs, pedestrians) are to be considered. Also, whether it is a static or dynamic zone. |
| VRU zone area | M | The geographical (coordinates) or topological area for the zone (cell IDs, TAs) |
| QoS requirements | M | The application QoS requirements for the services within the zone |
| VRU zone configuration parameters | M | These parameters include:
|
| VRU zone adaptation assistance info | O | If the VRU zone is dynamic, this IE provides assistance info on the configuration adaptation triggers or to provide the planning (e.g. based on a school bus route) to allow the network to adapt the configuration. |
9.21.2.4 Enter/Leave Notification p. 97
Table 9.21.2.4-1 describes information elements for the Enter/Leave Notification from the VAE server to the VASS or the VAE client(s) within the zone.
| Information element | Status | Description |
|---|---|---|
| VAL UE ID | M (NOTE) | The identity of the UE of interest (GPSI, or external ID) |
| VAL group ID | M (NOTE) | The group UE identity (if this applies to a group of UEs). |
| VRU zone ID | M | The identifier of the VRU zone |
| VRU zone information | M | This information identifies based on the VRUP scenario, which type of UEs (V2X UEs, pedestrians) are to be considered. Also, whether it is a static or dynamic zone. |
| Enter/Leave timing info | M | The timing info for the UE enter / leave the zone. This includes for entering a start time of VRUP and an expected duration, and for leaving an expected leave time (if the UE is approaching the VRU zone boundaries) |
| UE/group mobility info | O | The expected mobility/speed/direction of the UE or group of interest |
|
NOTE:
One of these shall be present.
|
||
9.21.3 Procedure on VAL server - triggered VRU zone configuration p. 97
Figure 9.21.3-1 illustrates the procedure where the VAE server configures the VRU zone based on application requirement; and supports the run-time operation based on an expected UE entrance to the zone.
Pre-conditions:
- V2X application specific server or client has subscribed to VAE layer to provide support for V2P communication.
Step 1.
The V2X application specific server sends a subscription request to manage the configuration of a new high-risk area zone and requires the VAE server support to translate it to a network-related zone configuration and provisioning to the UEs within the requested area.
Step 2.
The VAE server processes the request and stores the subscription. The processing includes the translation of the zone requirement of step 1 and determines a set of network-related zone parameters which indicates the configuration parameters.
Step 3.
The VAE sever sends a VRU zone management subscription response to VASS.
Step 4.
The VAE server initiates the SEAL LMS service for location tracking both for static location and dynamically changing location for all UEs within the VRU zone area. VAE server obtains and initiates tracking the V2X UEs location from the location management server 1 as specified in clause 9.3.12 of TS 23.434 or, for static area, it obtains location area monitoring information based on clause 9.3.10 of TS 23.434.
Step 5.
The VAE server sends a notification message including the VRU zone configuration parameters. Parameters can be based on the parameters provided in step 2. This configuration will be provided to the V2X-UEs (and pedestrians) within the area that will be covered by the VRU zone.
Step 6.
The VAE server keeps monitoring the VRU zone area based on monitoring SEAL LMS events. This includes events on whether a UE (e.g. UE1) is moving in or out a target area of interest.
The VAE server translates the UE1 mobility event to an expected entrance to a VRU high risk zone, and based on the configuration of the zone, it identifies whether to generate and send a notification to the VASS on the expected entrance / leave of UE1.
Step 7.
The VAE server alerts the VASS that the UE1 is expected to move to the VRU zone area in a given time horizon and provides also information on its mobility as well as the UE1 capabilities (e.g. VRU capable).
Step 8.
The VAE server may also alert the VAE client (if deployed at the UE1) that it is expected to enter the VRU zone and requests the confirmation for allowing the push of VRU messages within the zone.
