6 Functional description and information flows
23.2873GPPArchitecture enhancements for 5G System (5GS) to support Vehicle-to-Everything (V2X) servicesRelease 17TS
6.1 Control and user plane stacks
6.1.1 User plane for NR PC5 reference point supporting V2X services
Figure 6.1.1-1 depicts a user plane for NR PC5 reference point, i.e. PC5 User Plane Protocol stack.
Legend:
– PC5-U: The SDAP/PDCP/RLC/MAC/PHY functionality is specified in TS 38.300 [11].
– For PDCP SDU type "Non-IP", a "Non-IP Type" header included in the SDU by upper layer to indicate the type of non-IP messages carried will be specified in stage 3 specification.
Figure 6.1.1-1: User Plane for NR PC5 reference point
IP and Non-IP PDCP SDU types are supported for the V2X communication over PC5 reference point.
For IP PDCP SDU type, only IPv6 is supported. The IP address allocation and configuration are as defined in clause 5.6.1.1.
The Non-IP PDCP SDU contains a Non-IP Type header, which indicates the V2X message family used by the application layer, e.g. IEEE 1609 family’s WSMP [18], ISO defined FNTP [19], CCSA defined DSMP [27].
NOTE: The Non-IP Type header and allowed values are defined in TS 24.587 [24].
The packets from V2X application layer are handled by the V2X layer before transmitting them to the AS layer, e.g. V2X layer maps the IP/Non IP packets to PC5 QoS Flow and marks the corresponding PFI.
6.1.2 Control plane for NR PC5 reference point supporting V2X services
Figure 6.1.2-1 depicts a control plane for NR PC5 reference point, i.e. PC5 Signalling Protocol stack.
Legend:
– PC5-S Protocol: The protocol used for the control plane signalling over the PC5 reference point for the secure layer-2 link as specified in clause 6.3.3.
– The PDCP/RLC/MAC/PHY functionality is specified in TS 38.300 [11].
Figure 6.1.2-1: Control Plane for NR PC5 reference point
6.2 Procedures for Service Authorization and Provisioning to UE
6.2.1 General
The procedures for service authorization and provisioning to UE may be initiated by the PCF (as described in clause 6.2.2), by the UE (as described in clause 6.2.4), or by the AF (as described in clause 6.2.5).
6.2.2 PCF based Service Authorization and Provisioning to UE
For PCF based Service Authorization and Provisioning to UE, the Registration procedures as defined in clause 4.2.2.2 of TS 23.502 [7], UE Policy Association Establishment procedure as defined in clause 4.16.11 of TS 23.502 [7] and UE Policy Association Modification procedure as defined in clause 4.16.12 of TS 23.502 [7] apply with the following additions:
– If the UE indicates V2X capability in the Registration Request message and if the UE is authorized to use V2X service based on subscription data, the AMF selects the PCF which supports V2X Policy/Parameter provisioning as described in clause 6.2.3 and establishes a UE policy association with the PCF for V2X Policy/Parameter delivery.
– If the AMF receives the PC5 capability for V2X in the Registration Request message from UE, the AMF further reports the PC5 capability for V2X to the selected PCF. The PCF may determine the V2X Policy/Parameter for specific PC5 RAT based on the received UE’s PC5 capability for V2X.
– If the UE supports V2X communication and it does not have valid V2X policy/parameters, the UE includes the UE Policy Container with indicating the V2X Policy Provisioning Request during registration procedure.
– If the UE indicates the V2X Policy Provisioning Request in the UE Policy Container, the PCF determines whether to provision V2X Policy/parameters for V2X communication over PC5 reference point and/or V2X communication over Uu reference point to the UE, as specified in clause 6.1.2.2.2 of TS 23.503 [16], and the PCF provides the V2X Policy/parameters to the UE by using the procedure as defined in clause 4.2.4.3 of TS 23.502 [7].
The PCF may update the V2X Policy/parameters to the UE in following conditions:
– UE Mobility, e.g. UE moves from one PLMN to another PLMN. This is achieved by using the procedure of UE Policy Association Modification initiated by the AMF, as defined in clause 4.16.12.1 of TS 23.502 [7].
– When there is a subscription change in the list of PLMNs where the UE is authorized to perform V2X communication over PC5 reference point. This is achieved by using UE Policy Association Modification initiated by the PCF procedure as defined in clause 4.16.12.2 of TS 23.502 [7].
– When there is a change of service specific parameter as described in clause 4.15.6.7 of TS 23.502 [7].
If the serving PLMN is removed from the list of PLMNs in the service authorization parameters, the service authorization is revoked in the UE.
When the UE is roaming, the change of subscription resulting in updates of the service authorization parameters are transferred to the UE by H-PCF via V-PCF.
The UE may perform UE triggered Policy Provisioning procedure to the PCF as specified in clause 6.2.4 when the UE determines the V2X Policy/Parameter is invalid (e.g. Policy/Parameter is outdated, missing or invalid).
6.2.3 PCF discovery
PCF discovery and selection mechanism defined in clause 6.3.7.1 of TS 23.501 [6] applies with the following addition to enable a PCF instance is selected for V2X service and for UE:
– Based on the indication from the UE and/or UE subscription data during the Registration procedure as specified in clause 6.2.2, the AMF may include the V2X capability indication in the Nnrf_NFDiscovery_Request message as the optional input parameter. If provided, the NRF takes the information into account for discovering the PCF instance.
6.2.4 Procedure for UE triggered V2X Policy provisioning
The UE triggered Policy Provisioning procedure is initiated by the UE to request V2X Policy/Parameter from the PCF when UE determines the V2X Policy/Parameter is invalid in the following cases:
– if the validity timer indicated in the V2X Policy/Parameter expires;
– if there are no valid parameters, e.g. for the V2X service type a UE wants to use, for current area, or due to abnormal situation.
Figure 6.2.4-1: UE triggered V2X Policy provisioning procedure
1. The UE sends UL NAS TRANSPORT message carrying the UE Policy Container (UE V2X Policy Provisioning Request to request V2X policies) to the AMF.
2. The AMF sends the Namf_Communication_N1MessageNotify request to the PCF including the UE Policy Container received from UE.
3. The PCF receives UE Policy Container which indicates UE Policy Provisioning Request to request V2X policies. If the V2X policies are authorized based on AMF input as specified in clause 6.2.2, the PCF performs the UE Policy delivery procedure defined in clause 4.2.4.3 of TS 23.502 [7].
6.2.5 AF-based service parameter provisioning for V2X communications over control plane
The V2X Application Server can provision the 5GC with V2X service parameters via NEF as depicted in clause 4.2.2. For V2X service parameter provisioning, the procedure defined in clause 4.15.6.7 of TS 23.502 [7] is performed with the following considerations:
– The AF in TS 23.502 [7] is considered as V2X Application Server in this specification.
– Service Description indicates V2X service domain information.
– Service Parameters include policy/provisioning parameters for V2X communications over Uu and PC5. The detailed information on the parameters is described in clause 5.1.
NOTE: It is assumed that the V2X service domain information is set based on the Service Level Agreement with the operator.
6.3 Procedures for V2X communication over PC5 reference point
6.3.1 Broadcast mode V2X communication over PC5 reference point
To perform V2X communication over PC5 reference point in broadcast mode operation, the UE is configured with the related information as described in clause 5.1.2.
Figure 6.3.1-1 shows the procedure for broadcast mode of V2X communication over PC5 reference point.
Figure 6.3.1-1: Procedure for Broadcast mode of V2X communication over PC5 reference point
1. The V2X layer of receiving UE(s) determines the following for the broadcast mode communication reception:
– the destination Layer-2 ID for broadcast reception as specified in clause 5.6.1.2;
– the PC5 QoS parameters for this broadcast V2X service as specified in clause 5.4.1.1; and
– the NR Tx Profile based on the configuration as specified in clause 5.1.2.1.
The destination Layer-2 ID, the NR Tx Profile and the PC5 QoS parameters are passed down to the AS layer of receiving UE(s) for the reception. When there is no NR Tx Profile available to be mapped for this broadcast V2X service, the V2X layer does not provide NR Tx Profile to the AS layer. When there are the other V2X service type(s) that use the same destination Layer-2 ID with this broadcast V2X service, the V2X layer determines whether and how to provide the NR Tx Profile to the AS layer as specified in clause 5.9.
The AS layer of receiving UE(s) determines the PC5 DRX parameter values as specified in clause 5.9.
2. The transmitting UE V2X application layer provides data unit and may provide V2X Application Requirements specified in clause 5.4.1.2 to V2X layer.
3. The V2X layer of transmitting UE determines the following for the broadcast mode communication transmission:
– the destination Layer-2 ID for broadcast as specified in clause 5.6.1.2;
– the PC5 QoS parameters for this broadcast V2X service as specified in clauses 5.4.1.1 and 5.4.1.2; and
– the NR Tx Profile based on the configuration as specified in clause 5.1.2.1.
The transmitting UE self-assigns the source Layer-2 ID as specified in clause 5.6.1.1.
The source Layer-2 ID, the destination Layer-2 ID, the NR Tx Profile and the PC5 QoS parameters are passed down to the AS layer of transmitting UE for the transmission. When there is no NR Tx Profile available to be mapped for this broadcast V2X service, the V2X layer does not provide NR Tx Profile to the AS layer. When there are the other V2X service type(s) that use the same destination Layer-2 ID with this broadcast V2X service, the V2X layer determines whether and how to provide the NR Tx Profile to the AS layer as specified in clause 5.9.
The AS layer of transmitting UE determines the PC5 DRX parameter values as specified in clause 5.9.
4. The transmitting UE sends the V2X service data using the source Layer-2 ID and the destination Layer-2 ID.
NOTE: In step 4, there is only one broadcast message from the transmitting UE.
6.3.2 Groupcast mode V2X communication over PC5 reference point
To perform groupcast mode of V2X communication over PC5 reference point, the UE is configured with the related information as described in clause 5.1.2.1.
Figure 6.3.2-1 shows the procedure for groupcast mode of V2X communication over PC5 reference point.
Figure 6.3.2-1: Procedure for groupcast mode of V2X communication over PC5 reference point
1. V2X group management is carried out by the V2X application layer and is out of scope of this specification.
2. The V2X application layer may provide group identifier information (i.e. an Application-layer V2X Group identifier) as specified in clause 5.6.1.3.
The V2X application layer may provide V2X Application Requirements for this communication.
If the V2X application layer does not provide V2X Application Requirements, the V2X layer determines the PC5 QoS parameters based on the mapping of V2X service type to PC5 QoS parameters as defined in clause 5.1.2.1.
The V2X application layer may provide a group size and a member ID as specified in clause 5.2.1.3.
3. The V2X layer of transmitting UE determines the following for the groupcast mode communication transmission:
– a source Layer-2 ID and a destination Layer-2 ID as specified in clauses 5.6.1.1 and 5.6.1.3;
– the PC5 QoS parameters for this groupcast mode communication as specified in clauses 5.4.1.1 and 5.4.1.3; and
– the NR Tx Profile based on the configuration as specified in clause 5.1.2.1.
The source Layer-2 ID, destination Layer-2 ID, the NR Tx Profile and the PC5 QoS parameters are passed down to the AS layer of transmitting UE for the groupcast mode communication transmission. When there is no NR Tx Profile available to be mapped for this groupcast V2X service, the V2X layer does not provide NR Tx Profile to the AS layer. When there are the other V2X service type(s) that use the same destination Layer-2 ID with this groupcast V2X service, the V2X layer determines whether and how to provide the NR Tx Profile to the AS layer as specified in clause 5.9.
The V2X layer of receiving UE(s) determines the following for the groupcast mode communication reception:
– the destination Layer-2 ID, as specified in clauses 5.6.1.1 and 5.6.1.3;
– the PC5 QoS parameters for this groupcast mode communication as specified in clause 5.4.1.1; and
– the NR Tx Profile based on the configuration as specified in clause 5.1.2.1.
The destination Layer-2 ID, the NR Tx Profile and the PC5 QoS parameters are passed down to the AS layer of receiving UE(s) for the groupcast mode communication reception. When there is no NR Tx Profile available to be mapped for this groupcast V2X service, the V2X layer does not provide NR Tx Profile to the AS layer. When there are the other V2X service type(s) that use the same destination Layer-2 ID with this groupcast V2X service, the V2X layer determines whether and how to provide the NR Tx Profile to the AS layer as specified in clause 5.9.
If the group size and the member ID for Application Layer managed group are provided by the V2X application layer, the V2X layer passes them to the AS layer as described in clause 5.2.1.3.
The AS layer of transmitting UE and the AS layer of receiving UE(s) determine the PC5 DRX parameter values as specified in clause 5.9.
4. Transmitting UE has a V2X service associated with this groupcast mode communication.
Transmitting UE sends the V2X service data using the source Layer-2 ID and the destination Layer-2 ID.
NOTE: In step 4, there is only one groupcast message from the transmitting UE.
6.3.3 Unicast mode V2X communication over PC5 reference point
6.3.3.1 Layer-2 link establishment over PC5 reference point
To perform unicast mode of V2X communication over PC5 reference point, the UE is configured with the related information as described in clause 5.1.2.1.
Figure 6.3.3.1-1 shows the layer-2 link establishment procedure for unicast mode of V2X communication over PC5 reference point.
Figure 6.3.3.1-1: Layer-2 link establishment procedure
1. The UE(s) determine the destination Layer-2 ID for signalling reception for PC5 unicast link establishment as specified in clause 5.6.1.4. The destination Layer-2 ID is configured with the UE(s) as specified in clause 5.1.2.1.
2. The V2X application layer in UE-1 provides application information for PC5 unicast communication. The application information includes the V2X service type(s) and the initiating UE’s Application Layer ID. The target UE’s Application Layer ID may be included in the application information.
The V2X application layer in UE-1 may provide V2X Application Requirements for this unicast communication. UE-1 determines the PC5 QoS parameters and PFI as specified in clause 5.4.1.4.
If UE-1 decides to reuse the existing PC5 unicast link as specified in clause 5.2.1.4, the UE triggers Layer-2 link modification procedure as specified in clause 6.3.3.4.
3. UE-1 sends a Direct Communication Request message to initiate the unicast layer-2 link establishment procedure. The Direct Communication Request message includes:
– Source User Info: the initiating UE’s Application Layer ID (i.e. UE-1’s Application Layer ID).
– If the V2X application layer provided the target UE’s Application Layer ID in step 2, the following information is included:
– Target User Info: the target UE’s Application Layer ID (i.e. UE-2’s Application Layer ID).
– V2X Service Info: the information about V2X service type(s) requesting Layer-2 link establishment.
– Security Information: the information for the establishment of security.
NOTE 1: The Security Information and the necessary protection of the Source User Info and Target User Info are defined in TS 33.536 [26].
The source Layer-2 ID and destination Layer-2 ID used to send the Direct Communication Request message are determined as specified in clauses 5.6.1.1 and 5.6.1.4. The destination Layer-2 ID may be broadcast or unicast Layer-2 ID. When unicast Layer-2 ID is used, the Target User Info shall be included in the Direct Communication Request message.
UE-1 sends the Direct Communication Request message via PC5 broadcast or unicast using the source Layer-2 ID and the destination Layer-2 ID.
For transmitting and receiving the Direct Communication Request message, a default PC5 DRX configuration is used when the PC5 DRX operation is needed, e.g. based on the NR Tx Profile as specified in clause 5.1.2.1.
4. Security with UE-1 is established as below:
4a. If the Target User Info is included in the Direct Communication Request message, the target UE, i.e. UE-2, responds by establishing the security with UE-1.
4b. If the Target User Info is not included in the Direct Communication Request message, the UEs that are interested in using the announced V2X service type(s) over a PC5 unicast link with UE-1 responds by establishing the security with UE-1.
NOTE 2: The signalling for the Security Procedure is defined in TS 33.536 [26].
When the security protection is enabled, UE-1 sends the following information to the target UE:
– If IP communication is used:
– IP Address Configuration: For IP communication, IP address configuration is required for this link and indicates one of the following values:
– "IPv6 Router" if IPv6 address allocation mechanism is supported by the initiating UE, i.e., acting as an IPv6 Router; or
– "IPv6 address allocation not supported" if IPv6 address allocation mechanism is not supported by the initiating UE.
– Link Local IPv6 Address: a link-local IPv6 address formed locally based on RFC 4862 [21] if UE-1 does not support the IPv6 IP address allocation mechanism, i.e. the IP Address Configuration indicates "IPv6 address allocation not supported".
– QoS Info: the information about PC5 QoS Flow(s) to be added. For each PC5 QoS Flow, the PFI, the corresponding PC5 QoS parameters (i.e. PQI and conditionally other parameters such as MFBR/GFBR, etc.) and the associated V2X service type(s).
The source Layer-2 ID used for the security establishment procedure is determined as specified in clauses 5.6.1.1 and 5.6.1.4. The destination Layer-2 ID is set to the source Layer-2 ID of the received Direct Communication Request message.
Upon receiving the security establishment procedure messages, UE-1 obtains the peer UE’s Layer-2 ID for future communication, for signalling and data traffic for this unicast link.
5. A Direct Communication Accept message is sent to UE-1 by the target UE(s) that has successfully established security with UE-1:
5a. (UE oriented Layer-2 link establishment) If the Target User Info is included in the Direct Communication Request message, the target UE, i.e. UE-2 responds with a Direct Communication Accept message if the Application Layer ID for UE-2 matches.
5b. (V2X Service oriented Layer-2 link establishment) If the Target User Info is not included in the Direct Communication Request message, the UEs that are interested in using the announced V2X Service(s) respond to the request by sending a Direct Communication Accept message (UE-2 and UE-4 in Figure 6.3.3.1-1).
The Direct Communication Accept message includes:
– Source User Info: Application Layer ID of the UE sending the Direct Communication Accept message.
– QoS Info: the information about PC5 QoS Flow(s) requested by UE-1. For each PC5 QoS Flow, the PFI, the corresponding PC5 QoS parameters (i.e. PQI and conditionally other parameters such as MFBR/GFBR, etc.) and the associated V2X service type(s).
– If IP communication is used:
– IP Address Configuration: For IP communication, IP address configuration is required for this link and indicates one of the following values:
– "IPv6 Router" if IPv6 address allocation mechanism is supported by the target UE, i.e., acting as an IPv6 Router; or
– "IPv6 address allocation not supported" if IPv6 address allocation mechanism is not supported by the target UE.
– Link Local IPv6 Address: a link-local IPv6 address formed locally based on RFC 4862 [21] if the target UE does not support the IPv6 IP address allocation mechanism, i.e. the IP Address Configuration indicates "IPv6 address allocation not supported", and UE-1 included a link-local IPv6 address in the Direct Communication Request message. The target UE shall include a non-conflicting link-local IPv6 address.
If both UEs (i.e. the initiating UE and the target UE) selected to use link-local IPv6 address, they shall disable the duplicate address detection defined in RFC 4862 [21].
NOTE 3: When either the initiating UE or the target UE indicates the support of IPv6 router, corresponding address configuration procedure would be carried out after the establishment of the layer 2 link, and the link-local IPv6 addresses are ignored.
The V2X layer of the UE that established PC5 unicast link passes the PC5 Link Identifier assigned for the unicast link and the PC5 unicast link related information down to the AS layer. The PC5 unicast link related information includes Layer-2 ID information (i.e. source Layer-2 ID and destination Layer-2 ID) and the corresponding PC5 QoS parameters. This enables the AS layer to maintain the PC5 Link Identifier together with the PC5 unicast link related information.
6. V2X service data is transmitted over the established unicast link as below:
The PC5 Link Identifier, and PFI are provided to the AS layer, together with the V2X service data.
Optionally in addition, the Layer-2 ID information (i.e. source Layer-2 ID and destination Layer-2 ID) is provided to the AS layer.
NOTE 4: It is up to UE implementation to provide the Layer-2 ID information to the AS layer.
UE-1 sends the V2X service data using the source Layer-2 ID (i.e. UE-1’s Layer-2 ID for this unicast link) and the destination Layer-2 ID (i.e. the peer UE’s Layer-2 ID for this unicast link).
NOTE 5: PC5 unicast link is bi-directional, therefore the peer UE of UE-1 can send the V2X service data to UE-1 over the unicast link with UE-1.
6.3.3.2 Link identifier update for a unicast link
Figure 6.3.3.2-1 shows the link identifier update procedure for a unicast link. When privacy requirements is configured for a V2X service type associated with the unicast link, identifiers used for unicast mode of V2X communication over PC5 reference point (e.g. Application Layer ID, Source Layer-2 ID and IP address/prefix) shall be changed over time as specified in clauses 5.6.1.1 and 5.6.1.4. A UE may decide to change the identifiers for other reasons, e.g. application layer requirement. This procedure is used to update and exchange new identifiers between the source and the peer UEs for a unicast link before using the new identifiers, to prevent service interruptions. When there are privacy requirements as indicated above, this procedure is executed over a security protected unicast link.
If a UE has multiple unicast links using the same Application Layer IDs or Layer-2 IDs, the UE needs to perform the link identifier update procedure over each of the unicast link.
Figure 6.3.3.2-1: Link identifier update procedure
0. UE-1 and UE-2 have a unicast link established as described in clause 6.3.3.1.
1. UE-1 decides to change its identifier(s), e.g. due to the Application Layer ID change or upon expiry of a timer. UE-1 generates its new Layer-2 ID and sends a Link Identifier Update Request message to UE-2 using the old identifiers.
The Link Identifier Update Request message includes the new identifier(s) to use (including the new Layer-2 ID, Security Information, optionally the new Application Layer ID and optionally new IP address/prefix if IP communication is used). The new identifier(s) shall be cyphered to protect privacy if security is configured for the unicast link. After sending the Link Identifier Update Request message, if the UE-1 has data to send, UE-1 keeps sending data traffic to UE-2 with the old identifiers until UE-1 sends the Link Identifier Update Ack message to UE-2.
NOTE 1: The timer is running on per Source Layer-2 ID.
NOTE 2: When one of the two UEs acts as IPv6 router as described in clause 5.2.1.5 and IP address/prefix also needs to be changed, corresponding address configuration procedure would be carried out after the Link Identifier update procedure.
2. Upon reception of the Link Identifier Update Request message, UE-2 changes its identifier(s). UE-2 responds with a Link Identifier Update Response message which includes the new identifier(s) to use (including the new Layer-2 ID, Security Information, optionally the new Application Layer ID, and optionally a new IP address/prefix if IP communication is used). The new identifier(s) shall be cyphered to protect privacy if security is configured for the unicast link. The Link Identifier Update Response message is sent using the old identifiers. UE-2 continues to receive traffic with the old Layer-2 ID from UE-1 until UE-2 receives traffic with the new Layer-2 ID from UE-1. After sending the Link Identifier Update Response message, UE-2 keeps sending data traffic to UE-1 with the old identifiers, if UE-2 has data to send, until UE-2 receives the Link Identifier Update Ack message from UE-1.
3. Upon reception of the Link Identifier Update Response message, UE-1 responds with a Link Identifier Update Ack message. The Link Identifier Update Ack message includes the new identifier(s) from UE-2, as received on the Link Identifier Update Response message. The Link Identifier Update Ack message is sent using the old identifiers. UE-1 continues to receive traffic with the old Layer-2 ID from UE-2 until UE-1 receives traffic with the new Layer-2 ID from UE‑2.
4. The V2X layer of UE-1 passes the PC5 Link Identifier for the unicast link and the updated Layer-2 IDs (i.e. new Layer-2 ID for UE-1 for the source and new Layer-2 ID of UE-2 for the destination) down to the AS layer. This enables the AS layer to update the provided Layer-2 IDs for the unicast link.
UE-1 starts using its new identifiers and UE-2’s new identifiers for this unicast link.
5. Upon reception of the Link Identifier Update Ack message, the V2X layer of UE-2 passes the PC5 Link Identifier for the unicast link and the updated Layer-2 IDs (i.e. new Layer-2 ID of UE-2 for the source and new Layer-2 ID for UE-1 for the destination) down to the AS layer. This enables the AS layer to update the provided Layer-2 IDs for the unicast link.
UE-2 starts using its new identifiers and UE-1’s new identifiers for this unicast link.
NOTE 3: The Security Information in the above messages also needs to be updated at the same time as the Layer-2 IDs. This is defined in TS 33.536 [26].
6.3.3.3 Layer-2 link release over PC5 reference point
Figure 6.3.3.3-1 shows the layer-2 link release procedure over PC5 reference point.
Figure 6.3.3.3-1: Layer-2 link release procedure
0. UE-1 and UE-2 have a unicast link established as described in clause 6.3.3.1.
1. UE-1 sends a Disconnect Request message to UE-2 in order to release the layer-2 link and deletes all context data associated with the layer-2 link. The Disconnect Request message includes Security Information.
2. Upon reception of the Disconnect Request message UE-2 may respond with a Disconnect Response message and deletes all context data associated with the layer-2 link. The Disconnect Response message includes Security Information.
The V2X layer of each UE informs the AS layer that the unicast link has been released. The V2X layer uses PC5 Link Identifier to indicate the released unicast link. This enables the AS layer to delete the context related to the released unicast link.
NOTE: The Security Information in the above messages is defined in TS 33.536 [26].
6.3.3.4 Layer-2 link modification for a unicast link
Figure 6.3.3.4-1 shows the layer-2 link modification procedure for a unicast link. This procedure is used to:
– add new PC5 QoS Flow(s) in the existing PC5 unicast link.
– This covers the case for adding new PC5 QoS Flow(s) to the exisiting V2X service(s) as well as the case for adding new PC5 QoS Flow(s) to new V2X service(s).
– modify existing PC5 QoS Flow(s) in the existing PC5 unicast link.
– This covers the case for modifying the PC5 QoS parameters for existing PC5 QoS Flow(s).
– This also covers the case for removing the associated V2X service(s) from existing PC5 QoS Flow(s) as well as the case for associating new V2X service(s) with existing PC5 QoS Flow(s).
– remove existing PC5 QoS Flow(s) in the existing PC5 unicast link.
Figure 6.3.3.4-1: Layer-2 link modification procedure
0. UE-1 and UE-2 have a unicast link established as described in clause 6.3.3.1.
1. The V2X application layer in UE-1 provides application information for PC5 unicast communication. The application information includes the V2X service type(s) and the initiating UE’s Application Layer ID. The target UE’s Application Layer ID may be included in the application information. If UE-1 decides to reuse the existing PC5 unicast link as specified in clause 5.2.1.4, so decides to modify the unicast link established with UE-2, UE-1 sends a Link Modification Request to UE-2.
The Link Modification Request message includes:
a) To add new PC5 QoS Flow(s) in the existing PC5 unicast link:
– QoS Info: the information about PC5 QoS Flow(s) to be added. For each PC5 QoS Flow, the PFI, the corresponding PC5 QoS parameters (i.e. PQI and conditionally other parameters such as MFBR/GFBR, etc.) and the associated V2X service type(s).
b) To modify PC5 QoS Flow(s) in the existing PC5 unicast link:
– QoS Info: the information about PC5 QoS Flow(s) to be modified. For each PC5 QoS Flow, the PFI, the corresponding PC5 QoS parameters (i.e. PQI and conditionally other parameters such as MFBR/GFBR, etc.) and the associated V2X service type(s).
c) To remove PC5 QoS Flow(s) in the existing PC5 unicast link:
– PFI(s).
2. UE-2 responds with a Link Modification Accept message.
The Link Modification Accept message includes:
– For case a) and case b) described in step 1:
– QoS Info: the information about PC5 QoS Flow(s) requested by UE-1. For each PC5 QoS Flow, the PFI, the corresponding PC5 QoS parameters (i.e. PQI and conditionally other parameters such as MFBR/GFBR, etc.) and the associated V2X service type(s).
The V2X layer of each UE provides information about the unicast link modification to the AS layer. This enables the AS layer to update the context related to the modified unicast link.
6.3.3.5 Layer-2 link maintenance over PC5 reference point
The PC5 Signalling Protocol shall support keep-alive functionality that is used to detect if a particular PC5 unicast link is still valid. Either side of the PC5 unicast link can initiate the layer-2 link maintenance procedure (i.e. keep-alive procedure), based on for example triggers from the AS layer or internal timers. The UEs shall minimize the keep-alive signalling, e.g. cancel the procedure if data are successfully received over the PC5 unicast link.
Figure 6.3.3.5-1: Layer-2 link maintenance procedure
0. UE-1 and UE-2 have a unicast link established as described in clause 6.3.3.1.
1. Based on trigger conditions, UE-1 sends a Keep-alive message to UE-2 in order to determine the status of the PC5 unicast link.
NOTE 1: It is left to Stage 3 to determine the exact triggers for the keep-alive messages. For example, the trigger can be based on a timer associated with the Layer-2 link. The timer can be reset with a successful reception event defined by TS 38.300 [11].
2. Upon reception of the Keep-alive message, UE-2 responds with a Keep-alive Ack message.
The UE initiating the keep-alive procedure shall determine the follow up actions based on the result of the signalling, e.g. proceed with implicit layer-2 link release.
NOTE 2: It is left to Stage 3 to determine the follow up actions. For example, a successful reception event can also cancel the layer-2 link release if received in time.
6.4 Procedures for V2X communication over Uu reference point
6.4.1 Procedure for notification on QoS Sustainability Analytics to the V2X Application Server
Figure 6.4.1-1 depicts a procedure for notification on QoS Sustainability Analytics to the V2X Application Server.
Figure 6.4.1-1: Notification on QoS Sustainability Analytics to the V2X Application Server
1. The V2X Application Sever derives information on V2X service, location information (an area or path of interest), QoS requirements and reporting threshold(s). The location information can be in the form of geographic coordinates to reflect a list of waypoints.
NOTE 1: Step 1 is outside 3GPP scope. The V2X Application Server can derive this, for example, based on information provided by the UE(s) or the V2X Application Server uses locally configured information.
2. The V2X Application Server subscribes to or requests notification on QoS Sustainability Analytics provided by NWDAF via NEF by invoking Nnef_AnalyticsExposure_Subscribe service operation as defined in clause 6.1.1.2 of TS 23.288 [20] or Nnef_AnalyticsExposure_Fetch service operation as defined in clause 6.1.2.2 of TS 23.288 [20]. The parameters included in the request are described in clause 5.4.5.2.2.
The V2X Application Server may include multiple sets of parameters in order to provide different combinations of "Location information" and "Analytics Target Period" when requesting notification on QoS Sustainability Analytics.
NOTE 2: The V2X Application Server needs to set the "Time when analytics information is needed" parameter (see TS 23.288 [20]) appropriately, e.g. large enough, to perform the V2X application adjustment before the potential QoS change happens.
NOTE 3: The request made by the V2X Application Server does not have to be per UE. In order to make a request for multiple UEs, the V2X Application Server can perform mapping between individual UE path requests and subscription to notification per path/road segment. Whether a request is generated for a UE or multiple UEs, and how to set the parameters included in the request and triggers for such request are up to the V2X Application Server implementation and outside of the scope of 3GPP.
3. When the NEF receives the request from the V2X Application Server, the NEF interacts with the NWDAF as described in the procedure in clause 6.9.4 of TS 23.288 [20]. The NEF shall map the QoS Characteristics attributes including Resource Type, PDB and PER received from the V2X Application Server to the most appropriate 5QI that is supported by the network if the V2X application server does not provide 5QI. If 5QI is provided by the V2X Application Server, NEF does not perform such mapping. The NEF may map other parameters included in the request from the V2X Application Server to information used by the 3GPP system.
4. If the NEF receives the response from the NWDAF, the NEF notifies the V2X Application Server with the analytics information on QoS Sustainability Analytics by invoking Nnef_AnalyticsExposure_Notify service operation for a Subscribe-Notify model as defined in clause 6.1.1.2 of TS 23.288 [20] or Nnef_AnalyticsExposure_Fetch service operation for a Request-Response model as defined in clause 6.1.2.2 of TS 23.288 [20].
5. V2X application adjustment may take place.
NOTE 4: Step 5 is outside 3GPP scope. V2X application adjustment can take place at UE and/or V2X Application Server, e.g. adjust inter-vehicle gap, change video codec parameters, etc. For the case that the V2X Application Server uses the request for multiple UEs in step 2, the V2X Application Server can perform the V2X application adjustment for every UE corresponding to the request.
For a Subscribe-Notify model, when the V2X Application Sever wants to cancel subscription to analytics information, it invokes the Nnef_AnalyticsExposure_Unsubscribe service operation as defined in clause 6.1.1.2 of TS 23.288 [20].
6.5 Procedures for Service Authorization to NG-RAN for V2X communications over PC5 reference point
6.5.1 General
In order to enable PC5 radio resource control in NG-RAN, per PC5 RAT V2X service authorization information and PC5 QoS parameters need to be made available in NG-RAN, this clause describes the corresponding procedures and aspects.
6.5.2 Registration procedure
The Registration procedure for UE is performed as defined in TS 23.502 [7] with the following additions:
– The UE includes the PC5 Capability for V2X (i.e. LTE PC5 only, NR PC5 only, both LTE and NR PC5) as part of the "5GMM capability" in the Registration Request message. The AMF stores this information for V2X operation. The PC5 Capability for V2X indicates whether the UE is capable of V2X communication over PC5 reference point and which specific PC5 RAT(s) it supports.
– The AMF obtains the V2X Subscription data as part of the user subscription data from UDM during UE Registration procedure using Nudm_SDM service as defined in clause 4.2.2.2.2 of TS 23.502 [7].
– The AMF determines whether the UE is authorized to use V2X communication over PC5 reference point based on UE’s PC5 Capability for V2X and the subscription data related to V2X service authorization information (i.e. "V2X services authorized" indication, UE-PC5-AMBR per PC5 RAT and cross-RAT PC5 control authorization if applicable) received from UDM, and stores the V2X service authorization information as part of the UE context.
– The PCF provides the PC5 QoS parameters to AMF, and the AMF stores them in the UE context.
– If the UE is PC5 capable for V2X, and the UE is authorized to use V2X communication over PC5 reference point based on the subscription data, then the AMF shall include the following information in the NGAP message sent to NG-RAN:
– a "V2X services authorized" indication, indicating the UE is authorized to use V2X communication over PC5 reference point as Vehicle UE, Pedestrian UE or both.
– UE-PC5-AMBR per PC5 RAT and cross-RAT PC5 control authorization (if applicable), used by NG-RAN for the resource management of UE’s PC5 transmission for V2X services in network scheduled mode.
– the PC5 QoS parameters used by the NG-RAN for the resource management of UE’s PC5 transmission for V2X services in network scheduled mode.
– If the UE is authorized to use V2X communication over PC5 reference point, then the AMF should not initiate the release of the signalling connection after the completion of the Registration procedure. The release of the NAS signalling relies on the decision of NG-RAN, as specified in TS 23.502 [7].
6.5.3 Service Request procedure
The Service Request procedure for UE in CM-IDLE state is performed as defined in TS 23.502 [7] with the following additions:
– If the UE is PC5 capable for V2X, and the UE is authorized to use V2X communication over PC5 reference point, then the AMF shall include a "V2X services authorized" indication in the NGAP message, indicating the UE is authorized to use V2X communication over PC5 reference point as Vehicle UE, Pedestrian UE or both.
– The AMF includes the UE-PC5-AMBR, and cross-RAT PC5 control authorization in the NGAP message to the NG-RAN as part of the UE context and NG-RAN may use in resource management of UE’s PC5 transmission for V2X services in network scheduled mode.
– The AMF sends the PC5 QoS parameters to NG-RAN via N2 signalling. The PC5 QoS parameters may be stored in the UE context after the registration procedure. If the UE is authorized to use V2X communication over PC5 reference point but AMF does not have PC5 QoS parameters available, the AMF fetches the PC5 QoS parameters from the PCF.
6.5.4 N2 Handover procedure
The N2 based handover or the Inter-RAT to NG-RAN handover procedures for UE are performed as defined in TS 23.502 [7] with the following additions:
– If the UE is PC5 capable for V2X, and the UE is authorized to use V2X communication over PC5 reference point, then the target AMF shall send the "V2X services authorized" indication, UE-PC5-AMBR, cross-RAT PC5 control authorization, and PC5 QoS parameters to the target NG-RAN as follows:
– For the intra AMF handover, the "V2X services authorized" indication, UE-PC5-AMBR, cross-RAT PC5 control authorization, and PC5 QoS parameters are included in the NGAP Handover Request message.
– For the inter AMF handover or Inter-RAT handover to NG-RAN, the "V2X services authorized" indication, UE-PC5-AMBR, cross-RAT PC5 control authorization, and PC5 QoS parameters are included in the NGAP Handover Request message sent to the target NG-RAN.
6.5.5 Xn Handover procedure
The Xn based handover procedures for UE are performed as defined in TS 23.502 [7] with the following additions:
– If the "V2X services authorized" indication is included in the UE context (as described in TS 38.423 [23]), then the source NG-RAN shall include a "V2X services authorized" indication, UE-PC5-AMBR, cross-RAT PC5 control authorization and PC5 QoS parameters in the XnAP Handover Request message to the target NG-RAN.
– If the UE is PC5 capable for V2X, and the UE is authorized to use V2X communication over PC5 reference point, then the AMF shall send the "V2X services authorized" indication, the UE-PC5-AMBR, cross-RAT PC5 control authorization, and PC5 QoS parameters to the target NG-RAN in the Path Switch Request Acknowledge message
6.5.6 Subscriber Data Update Notification to AMF
The procedure of Subscriber Data Update Notification to AMF is performed as defined in TS 23.502 [7] with the following additions:
– The Nudm_SDM_Notification service operation may contain the "V2X services authorized" indication or the UE-PC5-AMBR, or cross-RAT PC5 control authorization or any combination;
– The AMF updates the UE Context with the above new V2X subscription data.
– When the AMF updates UE context stored at NG-RAN, the UE context contains the V2X subscription data.
6.5.7 Delivery of PC5 QoS parameters to NG-RAN
The UE Policy Association Establishment procedure and UE Policy Association Modification procedure, as defined in TS 23.502 [7], is used to provide to the AMF PC5 QoS parameters used by NG-RAN. When receiving Npcf_UEPolicyControl_Create Request from the AMF which includes the PC5 capability for V2X or when receiving the updated subscription data from UDR, the PCF generates the PC5 QoS parameters used by NG-RAN corresponding to a UE as defined in clause 5.4.2.
The (V-)PCF provides the information to the AMF as follows:
– In the roaming case, the H-PCF includes the PC5 QoS parameters used by NG-RAN in the Npcf_UEPolicyControl_Create Response message or Npcf_UEPolicyControl UpdateNotify Request message sent to V-PCF in an N2 PC5 policy container, and V-PCF relays this N2 PC5 policy container as the N2 container in the Namf_Communication_N1N2MessageTransfer message sent to AMF.
– In the non-roaming case, the PCF includes the PC5 QoS parameters used by NG-RAN in an N2 container in Namf_Communication_N1N2MessageTransfer message sent to AMF.
When the AMF determines that the N2 PC5 policy container comes from (V-)PCF, the AMF stores such information as part of the UE context.
In the UE Configuration Update procedure triggered by UE Policy Association Establishment or UE Policy Association Modification, t:
– The AMF forwards the PC5 QoS parameters in the NGAP message to the NG-RAN if a N2 PC5 policy container is received in the Namf_Communication_N1N2MessageTransfer message.
– The AMF forwards the PC5 QoS parameters in the NAS message to UE by using the UE Configuration Update procedure for transparent UE Policy delivery procedure defined in clause 4.2.4.3 of TS 23.502 [7] if a UE Policy Container is received in the Namf_Communication_N1N2MessageTransfer message.
NOTE 1: If the PC5 QoS parameters are provided to both NG-RAN and UE, both the N2 PC5 Policy Container and the UE Policy Container are included in the Namf_Communication_N1N2MessageTransfer message.
NOTE 2: Non-UE specific PC5 QoS parameters, e.g. default PC5 QoS parameters, can also be locally configured in NG-RAN. How such configuration is performed is out of scope of this specification.
6.5.8 PC5 Capability for V2X indication and V2X related information per PC5 RAT
A UE may support multiple PC5 RATs (i.e. LTE PC5 and NR PC5). For such UE, the PC5 Capability for V2X indication and V2X related information can be per PC5 RAT as described in clause 6.5.2.
The cross-RAT PC5 control authorization indicates whether LTE Uu controls LTE PC5 and/or NR PC5 from the cellular network, and whether NR Uu controls LTE PC5 and/or NR PC5 from the cellular network.
NOTE: Stage 3 does not define an explicit cross-RAT PC5 control authorization IE and it is indicated in an implicit manner as specified in TS 38.413 [22] and TS 38.423 [23].
Annex A (informative):
Application Function influence based edge computing for V2X services
To route V2X messages or any traffic for V2X purposes to/from V2X Application Server(s) in a local Data Network (DN) close to NG-RAN, V2X Application Server operated by e.g. operators, OEMs, road authorities, can use the Application Function (AF) influence on traffic routing feature defined in clause 5.6.7 of TS 23.501 [6].
The V2X Application Server that sends the AF request for AF influence based edge computing for V2X services can be the same V2X Application Server to/from which the traffic is routed.
When Application Function influence on traffic routing is applied, a local UPF can be selected to route the traffic to the local V2X Application Server.
Usage of Application Function (AF) influence on traffic routing feature and its application for SMF to control UPF data forwarding are defined in clause 5.6.7 and clause 5.8.2 of TS 23.501 [6].
Annex B (informative):
Road Side Unit (RSU) implementation options
This Annex presents examples how RSU can be implemented in 5GS, as shown in TS 23.285 [8]. Figure B-1 shows a UE-type RSU, which combines a UE with the V2X application logic.
Figure B-1: RSU includes a UE and the V2X application logic
Figure B-2 shows one example of gNB-type RSUs. In this example, the RSU comprises a gNB, a collocated UPF, and a V2X Application Server.
Figure B-2: RSU includes a gNB, collocated UPF and a V2X Application Server
Annex C (informative):
Change history
|
Change history |
|||||||
|
Date |
Meeting |
TDoc |
CR |
Rev |
Cat |
Subject/Comment |
New version |
|
2019-09 |
SP#85 |
– |
– |
– |
– |
MCC Editorial update for publication after TSG SA#85 approval |
16.0.0 |
|
2019-12 |
SP#86 |
SP-191083 |
0008 |
2 |
F |
Clarification on QoS handling |
16.1.0 |
|
2019-12 |
SP#86 |
SP-191083 |
0009 |
1 |
F |
Update on Architecture and Functional Entities |
16.1.0 |
|
2019-12 |
SP#86 |
SP-191083 |
0015 |
3 |
F |
Terminology correction: Replace service type by V2X services |
16.1.0 |
|
2019-12 |
SP#86 |
SP-191083 |
0018 |
1 |
F |
Corrections of QoS Sustainability Analytics |
16.1.0 |
|
2019-12 |
SP#86 |
SP-191083 |
0019 |
2 |
F |
Supplement for address resolution and clarification for Localized V2X Application Server discovery and routing |
16.1.0 |
|
2019-12 |
SP#86 |
SP-191083 |
0021 |
3 |
F |
Resolve editor’s note on PC5 Link-AMBR |
16.1.0 |
|
2019-12 |
SP#86 |
SP-191083 |
0023 |
3 |
F |
Application classifier at Rx UE |
16.1.0 |
|
2019-12 |
SP#86 |
SP-191083 |
0024 |
7 |
F |
Update to delivery of PC5 QoS parameters to NG-RAN |
16.1.0 |
|
2019-12 |
SP#86 |
SP-191083 |
0025 |
3 |
F |
Correction to V2X Policy update due to UE PLMN change |
16.1.0 |
|
2019-12 |
SP#86 |
SP-191083 |
0027 |
2 |
F |
Correction what a V2X service is |
16.1.0 |
|
2019-12 |
SP#86 |
SP-191083 |
0028 |
3 |
F |
V2X Policy and Parameter Provisioning for EPS and 5GS Interworking |
16.1.0 |
|
2019-12 |
SP#86 |
SP-191083 |
0030 |
2 |
F |
Clarification on IP address allocation for groupcast and multicast modes of V2X communication over PC5 reference point |
16.1.0 |
|
2019-12 |
SP#86 |
SP-191083 |
0033 |
2 |
F |
Group information to AS layer for groupcast control |
16.1.0 |
|
2019-12 |
SP#86 |
SP-191083 |
0034 |
3 |
F |
Clarification on precedence of parameters |
16.1.0 |
|
2019-12 |
SP#86 |
SP-191083 |
0036 |
1 |
F |
Removing ENs on identifiers for groupcast and unicast |
16.1.0 |
|
2019-12 |
SP#86 |
SP-191083 |
0037 |
– |
F |
Resolving ENs on NR PC5 QoS |
16.1.0 |
|
2019-12 |
SP#86 |
SP-191083 |
0039 |
1 |
F |
Clarification on Range parameter |
16.1.0 |
|
2019-12 |
SP#86 |
SP-191083 |
0040 |
2 |
F |
Removing EN related to groupcast security |
16.1.0 |
|
2019-12 |
SP#86 |
SP-191083 |
0041 |
1 |
F |
Use of unicast L2 ID for unicast link establishment |
16.1.0 |
|
2019-12 |
SP#86 |
SP-191083 |
0042 |
1 |
F |
Updated of PC5 RQIs |
16.1.0 |
|
2019-12 |
SP#86 |
SP-191083 |
0043 |
2 |
F |
Miscellaneous corrections to TS 23.287 |
16.1.0 |
|
2019-12 |
SP#86 |
SP-191083 |
0044 |
2 |
F |
unicast overview modification |
16.1.0 |
|
2019-12 |
SP#86 |
SP-191083 |
0045 |
1 |
F |
PC5 control plane protocol stack |
16.1.0 |
|
2019-12 |
SP#86 |
SP-191083 |
0047 |
1 |
F |
PC5 PQI and Priority level and PDB in PPPP |
16.1.0 |
|
2019-12 |
SP#86 |
SP-191083 |
0048 |
2 |
F |
Miscellaneous V2X corrections |
16.1.0 |
|
2019-12 |
SP#86 |
SP-191083 |
0049 |
3 |
F |
Clarification on V2X UE context delivery in Xn Handover procedure |
16.1.0 |
|
2019-12 |
SP#86 |
SP-191083 |
0053 |
2 |
F |
ENs resolution about PC5 operation in EPS/5GS IWK |
16.1.0 |
|
2019-12 |
SP#86 |
SP-191083 |
0059 |
2 |
F |
Update of unicast link establishment for security protection |
16.1.0 |
|
2020-03 |
SP#87E |
SP-200073 |
0061 |
2 |
F |
Correction on the QoS handling for groupcast |
16.2.0 |
|
2020-03 |
SP#87E |
SP-200073 |
0063 |
2 |
F |
Updates to the PC5 unicast link modification |
16.2.0 |
|
2020-03 |
SP#87E |
SP-200073 |
0066 |
1 |
F |
PC5 PDB Clarification |
16.2.0 |
|
2020-03 |
SP#87E |
SP-200073 |
0068 |
– |
F |
PC5 unicast link handling regarding RLF |
16.2.0 |
|
2020-03 |
SP#87E |
SP-200073 |
0069 |
– |
F |
Clarification on QoS related information to AS layer for unicast |
16.2.0 |
|
2020-03 |
SP#87E |
SP-200073 |
0070 |
– |
F |
Clarification on unicast link release |
16.2.0 |
|
2020-03 |
SP#87E |
SP-200073 |
0073 |
2 |
F |
Correction of NR PC5 user plane protocol stack |
16.2.0 |
|
2020-03 |
SP#87E |
SP-200073 |
0075 |
2 |
F |
Update of PC5 Link Identifier description |
16.2.0 |
|
2020-03 |
SP#87E |
SP-200073 |
0076 |
1 |
F |
Correction of set of configuration parameters in the precedence of the V2X configuration parameters |
16.2.0 |
|
2020-03 |
SP#87E |
SP-200073 |
0077 |
2 |
F |
Support of keep-alive signalling for unicast layer-2 link |
16.2.0 |
|
2020-03 |
SP#87E |
SP-200073 |
0078 |
– |
F |
Clarification on the L2 ID used for the security establishment procedures |
16.2.0 |
|
2020-03 |
SP#87E |
SP-200073 |
0084 |
2 |
F |
PC5 QoS handling for network scheduled operation mode |
16.2.0 |
|
2020-03 |
SP#87E |
SP-200073 |
0086 |
1 |
F |
Update of Link identifier update for unicast link procedure |
16.2.0 |
|
2020-03 |
SP#87E |
SP-200073 |
0087 |
1 |
F |
Miscellaneous Corrections |
16.2.0 |
|
2020-03 |
SP#87E |
SP-200073 |
0089 |
1 |
F |
Correction of QoS sustainability analytics |
16.2.0 |
|
2020-03 |
SP#87E |
SP-200073 |
0091 |
1 |
F |
served by and not served by clarification |
16.2.0 |
|
2020-03 |
SP#87E |
SP-200073 |
092 |
– |
F |
V2X application server clarfication |
16.2.0 |
|
2020-03 |
SP#87E |
SP-200073 |
0094 |
– |
F |
Clarification on V2X services communication |
16.2.0 |
|
2020-03 |
SP#87E |
SP-200073 |
0096 |
1 |
F |
Clarification on V2X Policy and Parameter Provisioning related aspects |
16.2.0 |
|
2020-03 |
SP#87E |
SP-200073 |
0097 |
1 |
F |
Clarification on V2X groupcast and broadcast security |
16.2.0 |
|
2020-03 |
SP#87E |
SP-200073 |
0098 |
1 |
F |
Resolve the EN on PC5 QoS |
16.2.0 |
|
2020-03 |
SP#87E |
SP-200073 |
0101 |
1 |
F |
Clarification of PDB |
16.2.0 |
|
2020-03 |
SP#87E |
SP-200073 |
0102 |
D |
Correction to Handling of PC5 QoS Flows based on PC5 QoS Rules |
16.2.0 |
|
|
2020-03 |
SP#87E |
SP-200073 |
0103 |
1 |
F |
V2X Subscription Data |
16.2.0 |
|
2020-03 |
SP#87E |
SP-200073 |
0104 |
1 |
F |
EPC interworking for V2X support |
16.2.0 |
|
2020-03 |
SP#87E |
SP-200073 |
0106 |
1 |
F |
Correction to Procedure for QoS Sustainability Notification |
16.2.0 |
|
2020-07 |
SP#88E |
SP-200434 |
0108 |
1 |
F |
Miscellaneous corrections |
16.3.0 |
|
2020-07 |
SP#88E |
SP-200434 |
0109 |
1 |
F |
Correction of PC5 RAT selection handling |
16.3.0 |
|
2020-07 |
SP#88E |
SP-200434 |
0110 |
1 |
F |
Correction of PC5 cast type handling |
16.3.0 |
|
2020-07 |
SP#88E |
SP-200434 |
0112 |
1 |
F |
Clarification on the mode of communication for PC5 |
16.3.0 |
|
2020-07 |
SP#88E |
SP-200434 |
0113 |
1 |
F |
Correction on V2X Policy and Parameters for PC5 |
16.3.0 |
|
2020-07 |
SP#88E |
SP-200434 |
0114 |
1 |
F |
Correction on V2X Sunbscription data |
16.3.0 |
|
2020-07 |
SP#88E |
SP-200434 |
0117 |
1 |
F |
Modify Description of N1 Reference Point |
16.3.0 |
|
2020-07 |
SP#88E |
SP-200434 |
0119 |
– |
F |
Introduction of missing definitions for Tx Profile and Mode of communication |
16.3.0 |
|
2020-07 |
SP#88E |
SP-200434 |
0120 |
– |
F |
Clarification on groupcast mode communication |
16.3.0 |
|
2020-07 |
SP#88E |
SP-200434 |
0121 |
1 |
F |
V2X Service Type |
16.3.0 |
|
2020-07 |
SP#88E |
SP-200434 |
0122 |
– |
F |
Clarification of Service Data for PC5 |
16.3.0 |
|
2020-07 |
SP#88E |
SP-200434 |
0124 |
1 |
F |
V2X service type provisioning |
16.3.0 |
|
2020-07 |
SP#88E |
SP-200434 |
0127 |
1 |
F |
RSU Implementation Options and Deployment Use Case |
16.3.0 |
|
2020-07 |
SP#88E |
SP-200434 |
0128 |
– |
F |
Clean-ups including removing EN not implemented from the approved CR |
16.3.0 |
|
2020-07 |
SP#88E |
SP-200434 |
0129 |
– |
F |
Clarification on PC5 PDB |
16.3.0 |
|
2020-07 |
SP#88E |
SP-200434 |
0130 |
1 |
C |
Clarification on mapping relationship between V2X Service and PFI for a PC5 unicast link |
16.3.0 |
|
2020-07 |
SP#88E |
SP-200434 |
0132 |
– |
F |
Correction of the SIB number for V2X communication |
16.3.0 |
|
2020-07 |
SP#88E |
SP-200434 |
0134 |
1 |
F |
Clarification on QoS Sustainability Analytics and Alignment with TS 23.288 |
16.3.0 |
|
2020-07 |
SP#88E |
SP-200434 |
0135 |
– |
D |
Editorial fix in 6.3.2 |
16.3.0 |
|
2020-07 |
SP#88E |
SP-200434 |
0137 |
– |
F |
Addition of Keep Alive in the list of PC5-S messages |
16.3.0 |
|
2020-07 |
SP#88E |
SP-200434 |
0139 |
1 |
F |
General corrections |
16.3.0 |
|
2020-09 |
SP#89E |
SP-200682 |
0141 |
– |
F |
Clarification on V2X Packet Filter Set |
16.4.0 |
|
2020-09 |
SP#89E |
SP-200682 |
0144 |
1 |
F |
Introducing new V2X service type |
16.4.0 |
|
2020-09 |
SP#89E |
SP-200682 |
0145 |
1 |
F |
Clarification of QoS info in accept message |
16.4.0 |
|
2020-09 |
SP#89E |
SP-200682 |
0146 |
1 |
F |
Clarification on SMF Configuration to UPF |
16.4.0 |
|
2020-09 |
SP#89E |
SP-200682 |
0147 |
1 |
F |
Clarification on QoS Sustainability |
16.4.0 |
|
2020-09 |
SP#89E |
SP-200682 |
0148 |
1 |
F |
Correction on PC5 RAT selection |
16.4.0 |
|
2020-09 |
SP#89E |
SP-200682 |
0149 |
1 |
F |
Correct the triggering conditions for the link identifier update procedure |
16.4.0 |
|
2020-09 |
SP#89E |
SP-200682 |
0150 |
1 |
F |
Update to Link Release Procedure |
16.4.0 |
|
2020-09 |
SP#89E |
SP-200682 |
0151 |
1 |
F |
Corrections to Link Identifier Update Procedure |
16.4.0 |
|
2020-12 |
SP#90E |
SP-200950 |
0152 |
– |
F |
Cleanup about V2X service type |
16.5.0 |
|
2020-12 |
SP#90E |
SP-200950 |
0153 |
– |
F |
Removal of Tx Profile for NR PC5 |
16.5.0 |
|
2021-06 |
SP#92E |
SP-210357 |
0154 |
1 |
B |
Support of QoS aware NR PC5 power efficiency for P-UEs |
17.0.0 |
|
2021-06 |
SP#92E |
SP-210357 |
0155 |
– |
B |
PC5 QoS parameters from V2X layer to AS layer of Rx UE for broadcast and groupcast |
17.0.0 |
|
2021-06 |
SP#92E |
SP-210357 |
0156 |
1 |
B |
PC5 DRX parameters determination |
17.0.0 |
|
2021-09 |
SP#93E |
SP-210927 |
0158 |
1 |
F |
Missing NEF in clause 4.4 Functional Entities |
17.1.0 |
|
2021-09 |
SP#93E |
SP-210927 |
0161 |
– |
B |
PC5 DRX configuration for broadcast and groupcast |
17.1.0 |
|
2021-09 |
SP#93E |
SP-210927 |
0162 |
– |
F |
EN resolution about determination of the PC5 DRX parameter values |
17.1.0 |
|
2021-09 |
SP#93E |
SP-210927 |
0163 |
1 |
F |
Removal of EN about PC5 DRX configuration for unicast |
17.1.0 |
|
2021-12 |
SP#94E |
SP-211296 |
0165 |
3 |
B |
NR Tx Profile |
17.2.0 |
|
2021-12 |
SP#94E |
SP-211296 |
0169 |
– |
F |
Resolution of ENs related to PC5 DRX |
17.2.0 |
|
2021-12 |
SP#94E |
SP-211277 |
0172 |
– |
A |
Correction to UE triggered Policy provisioning Procedure |
17.2.0 |
|
2022-06 |
SP#96 |
SP-220402 |
0177 |
1 |
F |
Clarifications on PC5 DRX operations |
17.3.0 |
|
2022-06 |
SP#96 |
SP-220402 |
0179 |
1 |
F |
SL DRX update considering new QoS parameters |
17.3.0 |
|
2022-09 |
SP#97E |
SP-220781 |
0181 |
1 |
F |
Clarifications on PC5 DRX operations |
17.4.0 |
|
2022-12 |
SP#98E |
SP-221074 |
0185 |
1 |
F |
Clarification on the PC5 DRX operation for Groupcast |
17.5.0 |