Content for  TS 23.501  Word version:  19.1.0

The content of this clause applies to non-roaming and to LBO deployments i.e. to cases where the involved entities (AF, PCF, SMF, UPF) belong to the Serving PLMN or AF belongs to a third party with which the Serving PLMN has an SLA agreement. AF influence on traffic routing may apply in the case of Home Routed deployments with Session Breakout (HR SBO) as defined in TS 23.548. In that case when an AF belonging to the V-PLMN (or with an offloading SLA with the V PLMN) desires to provide Traffic Influence policies it may invoke at the V-NEF the API defined in this clause and provide the information listed in Table 5.6.7-1 below but the corresponding Traffic Influence information is provided directly from V-NEF to V-SMF bypassing the PCF. This is further defined in clause 6.7.2 of TS 23.548. and the rest of the clause 5.6.7.1 does not address how information related with AF influence on traffic routing may be provided to the SMF in the case of HR SBO. PCF shall not apply AF requests to influence traffic routing to PDU Sessions established in Home Routed mode. The AF may determine the common EAS/DNAI for the UE set in order to indicate a common EAS or common local part of DN, and provide the common EAS/DNAI to the 5GS. An AF may send requests to influence SMF routing decisions for traffic of PDU Session. The AF requests may influence UPF (re)selection and (I-)SMF (re)selection and allow routing user traffic to a local access to a Data Network (identified by a DNAI). The AF may issue requests on behalf of applications not owned by the PLMN serving the UE. If the operator does not allow an AF to access the network directly, the AF shall use the NEF to interact with the 5GC, as described in clause 6.2.10. The AF may be in charge of the (re)selection or relocation of the applications within the local part of the DN (as defined in TS 23.548). Such functionality is not defined. For this purpose, the AF may request to get notified about events related with PDU Sessions. In the case of AF instance change, the AF may send request of AF relocation information. The AF requests are sent to the PCF via N5 (in the case of requests targeting specific on-going PDU Sessions of individual UE(s), for an AF allowed to interact directly with the 5GC NFs) or via the NEF. The AF requests that target existing or future PDU Sessions of multiple UE(s) or of any UE are sent via the NEF and may target multiple PCF(s), as described in clause 6.3.7.2. The PCF(s) transform(s) the AF requests into policies that apply to PDU Sessions. When the AF has subscribed to UP path management event notifications from SMF(s) (including notifications on how to reach a GPSI over N6), such notifications are sent either directly to the AF or via an NEF (without involving the PCF). For AF interacting with PCF directly or via NEF, the AF requests may contain the information as described in the Table 5.6.7-1:

For each information element mentioned above in the AF request, the detailed description is as follows:

1. Information to identify the traffic. The traffic can be identified in the AF request by
   • Either a DNN and possibly slicing information (S-NSSAI) or an AF-Service-Identifier
     • When the AF provides an AF-Service-Identifier i.e. an identifier of the service on behalf of which the AF is issuing the request, the 5G Core maps this identifier into a target DNN and slicing information (S-NSSAI)
     • When the NEF processes the AF request the AF-Service-Identifier may be used to authorize the AF request.
   • An application identifier or traffic filtering information (e.g. IP 5 Tuple). The application identifier refers to an application handling UP traffic and is used by the UPF to detect the traffic of the application.
     When the AF request is for influencing SMF routing decisions, the information is to identify the traffic to be routed.
     When the AF request is for subscription to notifications about UP path management events, the information is to identify the traffic that the events relate to. The AF request may include a PLMN ID of the PLMN that the DNN and S-NSSAI belong to, as described in clause 4.3.6.1 of TS 23.502.
2. Information about the N6 traffic routing requirements for traffic identified as defined in 1). This includes:
   • Information about the N6 traffic routing requirements that is provided per DNAI: for each DNAI, the N6 traffic routing requirements may contain a routing profile ID and/or N6 traffic routing information.
   • An optional indication of traffic correlation, when the information in 4) identifies a group of UEs. This implies the targeted PDU Sessions should be correlated by a common DNAI in the user plane for the traffic identified in 1). If this indication is provided by the AF, the 5GC should select a common DNAI for the target PDU Sessions from the list of DNAI(s) specified in 3).
3. Potential locations of applications towards which the traffic routing should apply. The potential location of application is expressed as a list of DNAI(s). If the AF interacts with the PCF via the NEF, the NEF may map the AF-Service-Identifier information to a list of DNAI(s). The DNAI(s) may be used for UPF (re)selection and (I-)SMF (re)selection. When only one DNAI is included, and the Indication of traffic correlation is available, the DNAI is used as common DNAI for UEs identified by AF request. The AF request may include a PLMN ID of the PLMN that the list of DNAI(s) belongs to, as described in clause 4.3.6.1 of TS 23.502.
4. Information on the set of target UE(s). This may correspond to:
   • Individual UEs (i.e. one or a list of UEs) identified using GPSI, or an IP address/Prefix or a MAC address.
   • Group(s) of UEs identified by External Group Identifier(s) as defined in TS 23.682 when the AF interacts via the NEF, or Internal-Group Identifier (see clause 5.9.7) when the AF interacts directly with the PCF.
   • Any UE accessing the combination of DNN, S-NSSAI and DNAI(s).
   • External Group ID(s) or any UE can both be complemented with External Subscriber Category(s) for a more granular selection of UEs. NEF may map this to Internal Group ID(s) or a combination of Internal Group ID(s) and Subscriber Category(s), defined in TS 23.503.
   When the PDU Session type is IPv4 or IPv6 or IPv4v6, and the AF provides an IP address and/or an IP Prefix, or when the PDU Session type is Ethernet and the AF provides a MAC address, this allows the PCF to identify the PDU Session for which this request applies and the AF request applies only to that specific PDU Session of the UE. In this case, additional information such as the UE identity may also be provided to help the PCF to identify the correct PDU Session.
   Otherwise, the request targets multiple UE(s) and shall apply to any existing or future PDU Sessions that match the parameters in the AF request.
   When the AF request targets an individual or a list of UE(s) and GPSI is provided within the AF request, the GPSI is mapped to SUPI according to the subscription information received from UDM.
   When the AF request targets any UE or a group of UE, the AF request is likely to influence multiple PDU Sessions possibly served by multiple SMFs and PCFs.
   When the AF request targets a group of UE it provides one or several group identifiers in its request. The group identifiers provided by the AF are mapped to Internal-Group identifiers. Members of the group have Group Identifier(s) in their subscription. The Internal-Group Identifier(s) is(are) stored in UDM, retrieved by SMF from UDM and passed by SMF to PCF at PDU Session set-up. The PCF can then map the AF request with user subscription and determine whether an AF request targeting a Group of users applies to a PDU Session. When External Subscriber Category(s) is provided, the NEF maps External Subscriber Category(s) into Subscriber Category(s), the PCF can map the AF request with user subscription and then creates PCC rules for UEs that have the Subscriber Category(s) in their subscription.
   When the AF request is for influencing SMF routing decisions, the information is to identify UE(s) whose traffic is to be routed.
   When the AF request is for subscription to notifications about UP path management events, the information is to identify UE(s) whose traffic the events relate to.
   When the AF request is for traffic forwarding in a PDU Session serving for TSC, the MAC address used by the PDU Session is determined by the AF to identify UE whose traffic is to be routed according to the previously stored binding relationship of the 5GS Bridge and the port number of the traffic forwarding information received from TSN network.
5. Indication of application relocation possibility. This indicates whether an application can be relocated once a location of the application is selected by the 5GC. If application relocation is not possible, the 5GC shall ensure that for the traffic related with an application, no DNAI change takes place once selected for this application.
6. Temporal validity condition. This is provided in the form of time interval(s) or duration(s) during which the AF request is to be applied.
   When the AF request is for influencing SMF routing decisions, the temporal validity condition indicates when the traffic routing is to apply.
   When the AF request is for subscription to notifications about UP path management events, the temporal validity condition indicates when the notifications are to be generated.
7. Spatial validity condition on the UE(s) location. This is provided in the form of validity area(s). If the AF interacts with the PCF via the NEF, it may provide geographical area (e.g. a civic address or shapes) and the NEF maps the information to areas of validity based on pre-configuration. The PCF in turn determines area(s) of interest based on validity area(s).
   When the AF request is for influencing SMF routing decisions, the spatial validity condition indicates that the request applies only to the traffic of UE(s) located in the specified location.
   When the AF request is for subscription to notifications about UP path management events, the spatial validity condition indicates that the subscription applies only to the traffic of UE(s) located in the specified location.
8. Information on AF subscription to corresponding SMF events.
   The AF may request to be subscribed to change of UP path associated with traffic identified in the bullet 1) above. The AF request contains:
   • A type of subscription (subscription for Early and/or Late notifications).
     The AF subscription can be for Early notifications and/or Late notifications. In the case of a subscription for Early notifications, the SMF sends the notifications before the (new) UP path is configured. In the case of a subscription for Late notifications, the SMF sends the notification after the (new) UP path has been configured.
   • Notification target address for receiving event notification.
   • Optionally, an indication of "AF acknowledgment to be expected".
     The indication implies that the AF will provide a response to the notifications of UP path management events to the 5GC. The SMF may, according to this indication, determine to wait for a response from the AF before the SMF configures in the case of early notification, or activates in the case of late notification, the new UP path as described in clause 5.6.7.2.
   • Optionally, an immediate reporting flag.
     The immediate reporting flag is included when AF subscribe for candidate DNAI(s) of UE for common EAS/DNAI selection. With this flag, SMF should immediately response AF with the candidate DNAI(s) using Notification of user plane management event as described in clause 4.3.6.3 in TS 23.502.
   The AF subscription can also request to receive information associating the GPSI of the UE with the IP address(es) of the UE and/or with actual N6 traffic routing to be used to reach the UE on the PDU Session; in this case the corresponding information is sent by the SMF regardless of whether a DNAI applies to the PDU Session.
9. An AF transaction identifier referring to the AF request. This allows the AF to update or remove the AF request and to identify corresponding UP path management event notifications. The AF transaction identifier is generated by the AF.
   When the AF interacts with the PCF via the NEF, the NEF maps the AF transaction identifier to an AF transaction internal identifier, which is generated by the NEF and used within the 5GC to identify the information associated to the AF request. The NEF maintains the mapping between the AF transaction identifier and the AF transaction internal identifier. The relation between the two identifiers is implementation specific.
   When the AF interacts with the PCF directly, the AF transaction identifier provided by the AF is used as AF transaction internal identifier within the 5GC.
10. Indication of UE IP address preservation. This indicates UE IP address related to the traffic identified in bullet 1) should be preserved. If this indication is provided by the AF, the 5GC should preserve the UE IP address by preventing reselection of PSA UPF for the identified traffic once the PSA UPF is selected.
11. Information for EAS IP Replacement in 5GC. This indicates the Source EAS identifier and Target EAS identifier (i.e. IP addresses and port numbers of the source and target EAS) for a service subject to Edge Computing.
12. User Plane Latency Requirement. This includes AF requirements for User Plane latency. (see clause 6.3.6 of TS 23.548).
13. Information on AF change. The AF relocation information includes:
    • AF Identifier: the identifier of the target AF instance.
14. Indication for EAS relocation. This indicates the application(s) are to be relocated.
15. Indication for Simultaneous Connectivity over source and target PSA at Edge Relocation (see clause 6.3.4 of TS 23.548). Indicates that source and target PSA should coexist for some time at PSA relocation, and may influence the establishment of a temporary N9 forwarding tunnel between the source UL CL and target UL CL. It may also provide guidance for the time interval after the described traffic ceases when the connectivity over the source PSA may be removed.
16. Traffic Correlation ID. Identification of a set of UEs subjecting to the AF request and accessing the application identified by the Traffic Description. UEs associated with the same Traffic Correlation ID and accessing the application identified by the Traffic Description should connect to a common EAS or EAS(es) corresponding to a common DNAI.
    The following attributes may be provided with the Traffic Correlation ID:
    • EAS Correlation indication. Indicates selecting a common EAS for a set of UEs identified by Traffic Correlation ID and accessing the application identified by the Traffic Description.
    • Common EAS IP address. IP address of the common EAS to be accessed by the UEs in the set of UEs subject to AF request, for the application identified by the Traffic Description.
    • FQDN(s). FQDN(s) corresponding to the application to be accessed by a set of UEs. When FQDN(s) is included, it is used for influencing EAS discovery procedure as defined in TS 23.548.
    • Indication of traffic correlation as described in 2).

An AF may send requests to influence SMF routing decisions, for event subscription or for both. The AF may request to be subscribed to notifications about UP path management events, i.e. a UP path change occurs for the PDU Session. The corresponding notification about a UP path change sent by the SMF to the AF may indicate the DNAI and /or the N6 traffic routing information and/or common EAS that has changed as described in clause 4.3.6.3 of TS 23.502. It may include the AF transaction internal identifier, the type of notification (i.e. early notification or late notification), the Identity of the source and/or target DNAI, the IP address/prefix of the UE or the MAC address used by the UE, the GPSI and the N6 traffic routing information related to the 5GC UP. The AF may subscribe for notifications of candidate DNAI(s) for UE if AF selection of common EAS/DNAI for a set of UEs is used. When notifications about UP path management events are sent to the AF via the NEF, if required, the NEF maps the UE identify information, e.g. SUPI, to the GPSI and the AF transaction internal identifier to the AF transaction identifier before sending the notifications to the AF. The PCF, based on information received from the AF, operator's policy, optionally service experience analytics per UP path received from NWDAF, etc. authorizes the request received from the AF and determines for each DNAI, a traffic steering policy ID (derived from the routing profile ID provided by the AF) and/or the N6 traffic routing information (as provided by the AF) to be sent to the SMF as part of the PCC rules. The traffic steering policy IDs are configured in the SMF or in the UPF. The traffic steering policy IDs are related to the mechanism enabling traffic steering to the DN. The DNAIs are related to the information considered by the SMF for UPF selection and (I-)SMF (re)selection, e.g. for diverting (locally) some traffic matching traffic filters provided by the PCF. The PCF acknowledges a request targeting an individual PDU Session to the AF or to the NEF. For PDU Session that corresponds to the AF request, the PCF provides the SMF with a PCC rule that is generated based on the AF request, Local routing indication from the PDU Session policy control subscription information and taking into account UE location presence in area of interest (i.e. Presence Reporting Area). The PCC rule contains the information to identify the traffic, information about the DNAI(s) towards which the traffic routing should apply and optionally, an indication of traffic correlation and/or an indication of application relocation possibility and/or indication of UE IP address preservation. The PCC rule also contains per DNAI a traffic steering policy ID and/or N6 traffic routing information, if the N6 traffic routing information is explicitly provided in the AF request. If Traffic Correlation ID is included in the AF request, with EAS Correlation Indication or Common EAS, and FQDN(s) parameters, the Traffic Correlation ID and the EAS Correlation Indication or Common EAS, and FQDN(s) will be included in the PCC rule sent to SMF. The SMF can use the Traffic Correlation ID to determine that the UE belongs to a set of UEs identified by Traffic Correlation ID and a common EAS should be selected for the set of UE for the traffic identified by Traffic Descriptor as described in clause 6.2.3.2.5 of TS 23.548. If Traffic Correlation ID is included in the AF request, NEF updates the AF influence data in the UDR with the NEF Notification Endpoint to indicate it as responsible of the set of UEs associated with the Traffic correlation ID and to be notified with 5GC determined information as described in clause 6.2.3.2.7 of TS 23.548. The PCF provides in the PCC rule with information including the NEF Notification Endpoint for the SMF to notify to the NEF with 5GC determined information related to the UE members of the set of UEs identified by traffic correlation ID. If Traffic Correlation ID, and traffic correlation indication and FQDN(s) is included in the AF request, the Traffic Correlation ID and the traffic correlation indication will be included in the PCC rule sent to SMF. The SMF can use the Traffic Correlation ID to determine that the UE belongs to a set of UEs identified by Traffic Correlation ID and the UE needs to connect to EAS(s) corresponding to a common DNAI selected for the set of UE for the traffic identified by Traffic Descriptor, as described in clause 6.2.3.2.6 of TS 23.548. The PCF may also provide in the PCC rule information to subscribe the AF (or the NEF) to SMF events (UP path changes) corresponding to the AF request in which case it provides the information on AF subscription to corresponding SMF events received in the AF request. This is done by providing policies at PDU Session set-up or by initiating a PDU Session Modification procedure. When initiating a PDU Session set-up or PDU Session Modification procedure, the PCF considers the latest known UE location to determine the PCC rules provided to the SMF. The PCF evaluates the temporal validity condition of the AF request and informs the SMF to activate or deactivate the corresponding PCC rules according to the evaluation result. When policies specific to the PDU Session and policies general to multiple PDU Sessions exist, the PCF gives precedence to the PDU Session specific policies over the general policies. The PCF authorizes the AF request of User Plane Latency Requirements. If the PCF determines that the requirements can't be authorized, the PCF rejects the AF request. The spatial validity condition is resolved at the PCF. In order to do that, the PCF subscribes to the SMF to receive notifications about change of UE location in an area of interest (i.e. Presence Reporting Area). The subscribed area of interest may be the same as spatial validity condition, or may be a subset of the spatial validity condition (e.g. a list of TAs) based on the latest known UE location. When the SMF detects that UE entered the area of interest subscribed by the PCF, the SMF notifies the PCF and the PCF provides to the SMF the PCC rules described above by triggering a PDU Session Modification. When the SMF becomes aware that the UE left the area subscribed by the PCF, the SMF notifies the PCF and the PCF provides updated PCC rules by triggering a PDU Session Modification. SMF notifications to the PCF about UE location in or out of the subscribed area of interest are triggered by UE location change notifications received from the AMF or by UE location information received during a Service Request or Handover procedure. When the PCC rules are activated, the SMF may, based on local policies, take the information in the PCC rules and, optionally, the Service Experience analytics and/or DN Performance analytics per UP path (including UPF and/or DNAI and/or AS instance) as defined in clause 6.4.3 and clause 6.14.3, respectively, of TS 23.288 into account to:

• (re)select UP paths (including DNAI(s)) for PDU Sessions. The SMF is responsible for handling the mapping between the UE location (TAI / Cell-Id) and DNAI(s) associated with UPF and applications and the selection of the UPF(s) that serve a PDU Session. This is described in clause 6.3.3. If the PDU Session is of IP type and if Indication of UE IP address preservation is included in the PCC rules, the SMF should preserve the UE IP address, by not reselecting the related PSA UPF once the PSA UPF is selected, for the traffic identified in the PCC rule. If the user plane latency requirement is included in the PCC rules, the SMF chooses the PSA UPF that satisfies the user plane latency requirement. If the PCC rules are related to a 5G VN group served by the SMF and if the PCC rule includes an indication of traffic correlation, the SMF should select a common DNAI for the PDU Sessions of the 5G VN group, see clause 5.29.
• configure traffic steering at UPF, including activating mechanisms for traffic multi-homing or enforcement of an UL Classifier (UL CL). Such mechanisms are defined in clause 5.6.4. This may include that the SMF is providing the UPF with packet handling instructions (i.e. PDRs and FARs) for steering traffic to the local access to the DN. The packet handling instructions are generated by the SMF using the traffic steering policy ID and/or the N6 traffic routing information in the PCC rules corresponding to the applied DNAI. In the case of UP path reselection, the SMF may configure the source UPF to forward traffic to the UL CL/BP so that the traffic is steered towards the target UPF.
• if Information on AF subscription to corresponding SMF events has been provided in the PCC rule, inform the AF of the (re)selection of the UP path (UP path change). If the information includes an indication of "AF acknowledgment to be expected", the SMF may decide to wait for a response from the AF before it activates the new UP path, as described in clause 5.6.7.2.

When an I-SMF is inserted for a PDU Session, the I-SMF insertion, relocation or removal to a PDU session shall be transparent (i.e. not aware) to the PCF and to the AF. The processing of the AF influence on traffic routing is described in clause 5.34 and detailed procedure is described in clause 4.23.6 of TS 23.502.

In order to avoid or minimize service interruption during PSA relocation for a PDU session of SSC mode 3, or a PDU session with UL CL or branch point, according to the indication of "AF acknowledgment to be expected" on AF subscription to corresponding SMF events (DNAI change) (that may be provided in PCC rules received from the PCF as defined in clause 5.6.7.1 except in HR-SBO case or that may be provided directly by V-NEF to V-SMF as defined in clause 6.7.2 of TS 23.548 in case of HR-SBO) or according to local configuration (e.g. DN-related policies) the SMF may wait for a response from the AF after sending a notification (an early notification or a late notification) to the AF. In the case of late notification, based on the indication of "AF acknowledgment to be expected" on AF subscription, the SMF may send the notification before activating the UP path towards a new DNAI (possibly through a new PSA). The notification sent from the SMF to the AF indicates UP path management events (DNAI change) as described in clause 5.6.7.1. The AF can confirm the DNAI change indicated in the notification with the SMF by sending a positive response to the notification to the SMF or reject the DNAI change by sending a negative response. The AF can include N6 traffic routing information related to the target DNAI in a positive response sent to the SMF. The SMF configures the N6 traffic routing information from the AF response to the PSA on the UP path. The AF can include the EAS relocation Indication to indicate the application(s) to be relocated. In the case of early notification, based on the indication of "AF acknowledgment to be expected" on AF subscription, the SMF does not configure the UP path towards the new DNAI until it receives a positive AF response as specified in clause 4.3.6.3 of TS 23.502. In the case of late notification, based on the indication of "AF acknowledgment to be expected" on AF subscription, the SMF does not activate the UP path towards the new DNAI until it receives a positive AF response as specified in clause 4.3.5 of TS 23.502. If the SMF receives a negative response at any time, the SMF keeps using the original DNAI and may cancel related PSA relocation or addition. The SMF may perform DNAI reselection afterwards if needed. The SMF can assume according to local policy a negative response if a response is expected and but not received from the AF within a certain time window. When Early/Late Notification happens, the SMF notifies AF about the target DNAI and may indicate capability of supporting EAS IP replacement in 5GC.When EAS relocation is performed, the AF sends an/a early/late notification response to the SMF after the EAS relocation is completed, which may include the Information for EAS IP Replacement in 5GC. The SMF may instruct the local PSA to use the FAR that contains Information elements of "IP Address and Port Number Replacement" as described in clause 6.3.3 of TS 23.548. If local PSA relocation is required, the SMF may request the target local PSA to buffer uplink traffic as described in clause 6.3.5 of TS 23.548. AF relocation may be triggered by SMF e.g. in relationship with DNAI change due to UE mobility. In the case of AF relocation involving different DNAI(s), it is possible that the source EHE is unaware of other/target EHE specific deployment details. In such cases, when SMF selects a target DNAI (e.g. based on current UE location), the SMF may determine based on the EDI that the target DNAI is not supported by the source AF. The SMF determines the target AF ID based on the target DNAI and the EDI. Accordingly, as part of Early/Late Notification, the SMF provides the target AF ID to the source AF as described in clause 4.3.6.3 of TS 23.502.

The support for session and service continuity in 5G System architecture enables to address the various continuity requirements of different applications/services for the UE. The 5G System supports different session and service continuity (SSC) modes defined in this clause. The SSC mode associated with a PDU Session does not change during the lifetime of a PDU Session. The following three modes are specified with further details provided in the next clause:

• With SSC mode 1, the network preserves the connectivity service provided to the UE. For the case of PDU Session of IPv4 or IPv6 or IPv4v6 type, the IP address is preserved.
• With SSC mode 2, the network may release the connectivity service delivered to the UE and release the corresponding PDU Session(s). For the case of IPv4 or IPv6 or IPv4v6 type, the release of the PDU Session induces the release of IP address(es) that had been allocated to the UE.
• With SSC mode 3, changes to the user plane can be visible to the UE, while the network ensures that the UE suffers no loss of connectivity. A connection through new PDU Session Anchor point is established before the previous connection is terminated in order to allow for better service continuity. For the case of IPv4 or IPv6 or IPv4v6 type, the IP address is not preserved in this mode when the PDU Session Anchor changes.

SSC mode selection is done by the SMF based on the allowed SSC modes -including the default SSC mode) in the user subscription as well as the PDU Session type and if present, the SSC mode requested by the UE. The operator may provision a SSC mode selection policy (SSCMSP) to the UE as part of the URSP rule -see clause 6.6.2 of TS 23.503). The UE shall use the SSCMSP to determine the type of session and service continuity mode associated with an application or group of applications for the UE as described in clause 6.6.2.3 of TS 23.503. If the UE does not have SSCMSP, the UE can select a SSC mode based on UE Local Configuration as described in TS 23.503, if applicable. If the UE cannot select a SSC mode, the UE requests the PDU Session without providing the SSC mode. The SSC mode selection policy rules provided to the UE can be updated by the operator by updating the URSP rule. The SMF receives from the UDM the list of allowed SSC modes and the default SSC mode per DNN per S-NSSAI as part of the subscription information. If a UE provides an SSC mode when requesting a new PDU Session, the SMF selects the SSC mode by either accepting the requested SSC mode or rejecting the PDU Session Establishment Request message with the cause value and the SSC mode(s) allowed to be used back to UE based on the PDU Session type, subscription and/or local configuration. Based on that cause value and the SSC mode(s) allowed to be used, the UE may re-attempt to request the establishment of that PDU Session with the SSC mode allowed to be used or using another URSP rule. If a UE does not provide an SSC mode when requesting a new PDU Session, then the SMF selects the default SSC mode for the data network listed in the subscription or applies local configuration to select the SSC mode. SSC mode 1 shall be assigned to the PDU Session when static IP address/prefix is allocated to the PDU Session based on the static IP address/prefix subscription for the DNN and S-NSSAI. The SMF shall inform the UE of the selected SSC mode for a PDU Session. The UE shall not request and the network shall not assign SSC mode 3 for the PDU Session of Unstructured type or Ethernet type.

The IP address allocation is defined in clause 5.8.1 The UE may acquire following configuration information from the SMF, during the lifetime of a PDU Session:

• Address(es) of P-CSCF(s);
• Address(es) of DNS server(s).
• If the UE indicates support of DNS with security as defined in TS 33.501 to the network in PCO and the network wants to enforce the use of DNS with security, the configuration information sent by the SMF via PCO may also include the corresponding DNS server security information as specified in TS 24.501 and TS 33.501.
• the GPSI of the UE.

The UE may acquire from the SMF, at PDU Session Establishment, the MTU that the UE shall consider, see clause 5.6.10.4. The UE may provide following information to the SMF during the lifetime of a PDU Session:

• an indication of the support of P-CSCF re-selection based on procedures specified in clauses B.2.2.1C and L.2.2.1C of TS 24.229.
• PS data off status of the UE.

For a PDU Session set up with the Ethernet PDU Session type, the SMF and the UPF acting as PDU Session Anchor (PSA) can support specific behaviours related with the fact the PDU Session carries Ethernet frames. Depending on operator configuration related with the DNN, different configurations for how Ethernet traffic is handled on N6 may apply, for example:

• Configurations with a 1-1 relationship between a PDU Session and a N6 interface possibly corresponding to a dedicated tunnel established over N6. In this case the UPF acting as PSA transparently forwards Ethernet frames between the PDU Session and its corresponding N6 interface, and it does not need to be aware of MAC addresses used by the UE in order to route down-link traffic.
• Configurations, where more than one PDU Session to the same DNN (e.g. for more than one UE) corresponds to the same N6 interface. In this case the UPF acting as PSA needs to be aware of MAC addresses used by the UE in the PDU Session in order to map down-link Ethernet frames received over N6 to the appropriate PDU Session. Forwarding behaviour of the UPF acting as PSA is managed by SMF as specified in clause 5.8.2.5.

Based on operator configuration, the SMF may request the UPF acting as the PDU Session Anchor to respond to ARP/IPv6 Neighbour Solicitation requests based on local cache information, i.e. the mapping between the UE MAC address to the UE IP address, and the DN where the PDU Session is connected to, or to redirect the ARP traffic from the UPF to the SMF. Responding to ARP/IPv6 ND based on local cache information applies to ARP/IPv6 ND received in both UL and DL directions. Ethernet Preamble and Start of Frame delimiter are not sent over 5GS:

• For UL traffic the UE strips the preamble and frame check sequence (FCS) from the Ethernet frame.
• For DL traffic the PDU Session Anchor strips the preamble and frame check sequence (FCS) from the Ethernet frame.

Neither a MAC nor an IP address is allocated by the 5GC to the UE for a PDU Session. The PSA shall store the MAC addresses received from the UE, and associate those with the appropriate PDU Session. The SMF may receive a list of allowed VLAN tags from DN-AAA (for a maximum of 16 VLAN tags) or may be locally configured with allowed VLAN tags values. The SMF may also be configured with instructions on VLAN handling (e.g. the VLAN tag to be inserted or removed, S-TAG to be inserted or removed). Taking this into account, the SMF determines the VLAN handling for the PDU Session, and instructs the UPF to accept or discard the UE traffic based on the allowed VLAN tags, as well as to handle VLAN tags (addition/removal) via PDR (Outer header removal) and FAR (UPF applying Outer header creation of a Forwarding policy). For example:

• The UPF may insert (for uplink traffic) and remove (for downlink traffic) a S-TAG on N6 or N19 or internal interface ("5G VN internal") for the traffic from and to the UE.
• The UPF may insert (for uplink traffic) and remove (for downlink traffic) a VLAN tag on the N6 interface while there is no VLAN in the traffic to and from the UE.
• The UPF may discard any UE traffic that does not contain any allowed VLAN tag when the UPF handles the UE uplink or downlink traffic.

Apart from specific conditions related to the support of PDU sessions over W-5GAN defined in TS 23.316, the UPF shall not remove VLAN tags sent by the UE and the UPF shall not insert VLAN tags for the traffic sent to the UE. PDU(s) containing a VLAN tag shall be switched only within the same VLAN by a PDU Session Anchor. The UE may acquire from the SMF, at PDU Session Establishment, the MTU of the Ethernet frames' payload that the UE shall consider, see clause 5.6.10.4. Different Frames exchanged on a PDU Session of Ethernet type may be served with different QoS over the 5GS. Thus, the SMF may provide to the UPF Ethernet Packet Filter Set and forwarding rule(s) based on the Ethernet frame structure and UE MAC address(es). The UPF detects and forwards Ethernet frames based on the Ethernet Packet Filter Set and forwarding rule(s) received from the SMF. This is further defined in clauses 5.7 and 5.8.2. When a PDU Session of Ethernet PDU type is authorized by a DN as described in clause 5.6.6, the DN-AAA server may, as part of authorization data, provide the SMF with a list of allowed MAC addresses for this PDU Session; the list is limited to a maximum of 16 MAC addresses. When the list has been provided for a PDU Session, the SMF sets corresponding filtering rules in the UPF(s) acting as PDU Session Anchor for the PDU Session. The UPF discards any UL traffic that does not contain one of these MAC addresses as a source address if the list of allowed MAC addresses is provided. In this Release of specification, the PDU Session of Ethernet PDU Session type is restricted to SSC mode 1 and SSC mode 2. For a PDU Session established with the Ethernet PDU Session type, the SMF may, upon PCF request, need to ensure reporting to the PCF of all Ethernet MAC addresses used as UE address in a PDU Session. In this case, as defined in clause 5.8.2.12, the SMF controls the UPF to report the different MAC addresses used as source address of frames sent UL by the UE in the PDU Session. The PCF may activate or deactivate the reporting of the UE MAC address using the "UE MAC address change" Policy Control Request Trigger as defined in Table 6.1.3.5-1 of TS 23.503. The SMF may relocate the UPF acting as the PDU Session Anchor for an Ethernet PDU Session as defined in clause 4.3.5.8 of TS 23.502. The relocation may be triggered by a mobility event such as a handover, or may be triggered independent of UE mobility, e.g. due to load balancing reasons. In order to relocate the PSA UPF, the reporting of the UE MAC addresses needs to be activated by the SMF.

Different Point-to-Point (PtP) tunnelling techniques may be used to deliver Unstructured PDU Session type data to the destination (e.g. application server) in the Data Network via N6. Point-to-point tunnelling based on UDP/IP encapsulation as described below may be used. Other techniques may be supported. Regardless of addressing scheme used from the UPF to the DN, the UPF shall be able to map the address used between the UPF and the DN to the PDU Session. When Point-to-Point tunnelling based on UDP/IPv6 is used, the following considerations apply:

• IPv6 prefix allocation for PDU Sessions are performed locally by the (H-)SMF without involving the UE.
• The UPF(s) acts as a transparent forwarding node for the payload between the UE and the destination in the DN.
• For uplink, the UPF forwards the received Unstructured PDU Session type data to the destination in the data network over the N6 PtP tunnel using UDP/IPv6 encapsulation.
• For downlink, the destination in the data network sends the Unstructured PDU Session type data using UDP/IPv6 encapsulation with the IPv6 address of the PDU Session and the 3GPP defined UDP port for Unstructured PDU Session type data. The UPF acting as PDU Session Anchor decapsulates the received data (i.e. removes the UDP/IPv6 headers) and forwards the data identified by the IPv6 prefix of the PDU Session for delivery to the UE.
• The (H-)SMF performs the IPv6 related operations but the IPv6 prefix is not provided to the UE, i.e. Router Advertisements and DHCPv6 are not performed. The SMF assigns an IPv6 Interface Identifier for the PDU Session. The allocated IPv6 prefix identifies the PDU Session of the UE.
• For AF influence on traffic routing (described in clause 5.6.7), when the N6 PtP tunnelling is used over the DNAI and the AF provides, by value, information about N6 traffic routing requirements in the AF request, the AF provides N6 PtP tunnelling requirements (IPv6 address and UDP port of the tunnel end in the DN) as the N6 traffic routing information associated to the DNAI; when the SMF notifies the AF of UP path management events, it includes the N6 PtP tunnel information related to the UP (the IPv6 address and the 3GPP defined UDP port of the tunnel end at the UPF) as N6 traffic routing information in the notification.

In this Release of the specification there is support for maximum one 5G QoS Flow per PDU Session of Type Unstructured. In this Release of specification, the PDU Session of Unstructured PDU Session type is restricted to SSC mode 1 and SSC mode 2. The UE may acquire from the SMF, at PDU Session Establishment, the MTU that the UE shall consider, see clause 5.6.10.4.

In order to avoid data packet fragmentation between the UE and the UPF acting as PSA, the link MTU size in the UE should be set to the value provided by the network as part of the IP configuration. The link MTU size for IPv4 is sent to the UE by including it in the PCO (see TS 24.501). The link MTU size for IPv6 is sent to the UE by including it in the IPv6 Router Advertisement message (see RFC 4861). When using a PDU Session type Unstructured, the maximum uplink packet size, and when using Ethernet, the Ethernet frames' payload, that the UE should use may be provided by the network as a part of the session management configuration by encoding it within the PCO (see TS 24.501). When using a PDU Session type Unstructured, to provide a consistent environment for application developers, the network shall use a maximum packet size of at least 128 octets (this applies to both uplink and downlink). When the MT and the TE are separated, the TE may either be pre-configured to use a specific default MTU size or the TE may use an MTU size provided by the network via the MT. Thus, it is not always possible to set the MTU value by means of information provided by the network.

Service Function Chaining, also called N6-LAN Traffic Steering, refers to the steering of subscriber's traffic flows to appropriate operator or 3rd party Service Functions (e.g. NAT, antimalware, parental control, DDoS protection) in the N6-LAN. The content of this clause applies to non-roaming and to Home Routed roaming scenario, i.e. to cases where the involved entities (AF, PCF, SMF, UPF) belong to the Home PLMN and the AF has an agreement with the Home PLMN. The PCF controls Service Function Chaining by provisioning and modifying traffic steering control information for N6-LAN Traffic Steering as described in TS 23.503, e.g. clause 6.1.3.14. The traffic steering control information for N6-LAN Traffic Steering consists of a traffic description and a reference to a traffic steering policy that is configured in the SMF/UPF. The PCF derives the TSP ID(s) (that can be different for uplink and downlink directions) based on operator configuration and sends the TSP ID(s) to the SMF as part of the N6-LAN Traffic Steering Enforcement Control information in the PCC rule as described in clause 6.3.1 of TS 23.503. When the PCC rule is activated or updated with N6-LAN Traffic Steering Enforcement Control information, the SMF sets the Forwarding Policy (uplink and/or downlink) within the FAR(s) based on the authorized TSP ID(s) in the PCC rule and under consideration of the direction. In case that Application Function influence on traffic routing Enforcement Control information and N6-LAN Traffic Steering Enforcement Control information are both provided for the uplink direction, the SMF shall derive N4 rules which instruct the UPF to pass the traffic through the relevant Service Function(s) deployed in the N6-LAN before steering the traffic to the local data network. The SMF provides instructions to UPF for N6-LAN traffic steering as further detailed in clause 5.8.5.6. The UPF applies traffic steering mechanism based on Forwarding Policy, i.e. the UPF performs deployment specific actions as configured for the Forwarding Policy. When performing deployment specific actions configured for the Forwarding Policy, the UPF may support traffic steering related functionality and user plane encapsulation protocols that are out of 3GPP scope (e.g. as defined by other standards organizations). The mechanism used for forwarding the traffic between the Service Functions within the N6-LAN is out of 3GPP scope.

An AF may request the steering of user plane traffic to a pre-configured chain of Service Functions on N6-LAN. In the non-roaming scenario, Application Function influence on Service Function Chaining and Application Function influence on traffic routing (as defined in clause 5.6.7) can be applicable to the same traffic simultaneously. It is assumed that a service level agreement exists between the operator and a third party that includes a list of authorized predefined Service Function Chains (SFCs), each SFC being identified based on a Service Function Chaining identifier (SFC ID). The AF may request the selected traffic flows to be steered towards a specific SFC, either at PDU Session establishment or any time after PDU Session establishment. The AF requests may be sent to the PCF via the NEF. When SFC ID is included in the AF request, the parameters listed in Table 5.6.16.2-1 may be included in the AF request.

The PCF checks whether the SFC ID received from the AF corresponds to an authorized predefined SFC according to the service level agreement with this AF. Based on the SFC ID received from the AF, the PCF derives the TSP ID(s) (that can be different for uplink and downlink directions) and sends the TSP ID(s) and optionally Metadata (as provided by the AF) to the SMF as part of the PCC rule(s) as described in clause 6.3.1 of TS 23.503. The SMF behaves in the same way it is described in clause 5.6.16.1. If the SMF has received Metadata in the N6-LAN Traffic Steering Enforcement Control information of the PCC rule, the SMF forwards the Metadata to the UPF via N4 in the corresponding FAR as described in clause 5.8.5.6.