Apex Standards 3GPP Meeting Tracker

---

updated as of Fri, Apr 14, 2023, 01:58 PM UTC (3 days ago)
Fri, Apr 14, 06:58 AM California
Fri, Apr 14, 03:58 PM Berlin/Paris
Fri, Apr 14, 09:58 PM Beijing

3GPP-S2-156-e    Agenda Item 2 : Agenda

3GPP-S2-156-e    Agenda Item 3 : SA2#154AHE Meeting report

3GPP-S2-156-e    Agenda Item 6.2 : Common Access Control, RM and CM functions and procedure flows

- The TDocs (S2-2304317 and S2-2304318) both discuss the transfer of MT-SMS (Mobile Terminating Short Message Service) from the AMF (Access and Mobility Management Function) to the UE (User Equipment).
- If the UE has access to the AMF via both 3GPP (Third Generation Partnership Project) and non-3GPP access, the AMF determines the Access Type to transfer the MT-SMS based on operator local policy.
- If the SMS is delivered to the UE via 3GPP access, the local time zone is taken into account.
- If the SMSF (SMS Function) has more than one SMS to send, the SMSF and AMF forwards subsequent SMS/SMS ack/delivery report in the same way as described in step 4-6c.
- If the AMF indicates that the UE is not reachable, the procedure of the unsuccessful MT-SMS delivery described in clause 4.13.3.9 is performed and the following steps are skipped.
- In order to permit the SMSF to create an accurate charging record, the AMF includes IMEISV (International Mobile Equipment Identity and Software Version Number), and the current UE Location Information (ULI) of the UE as defined in clause 5.6.2 of TS 23.501.
- The SMSF acknowledges receipt of the delivery report to the UE.
- The AMF transfers the SMS message to the UE.
- The UDM (Unified Data Management) shall return both SMSF addresses.

Example snippets from the TDoc to support these differences:

- "If the UE access to the AMF via both 3GPP access and non-3GPP access, the AMF determines the Access Type to transfer the MT-SMS based on operator local policy." [TDoc S2-2304317 and S2-2304318]
- "If the SMS is delivered to the UE via 3GPP access, the local time zone." [TDoc S2-2304317 and S2-2304318]
- "If SMSF has more than one SMS to send, the SMSF and the AMF forwards subsequent SMS/SMS ack/delivery report the same way as described in step 4-6c." [TDoc S2-2304317 and S2-2304318]
- "If the AMF indicates SMSF that UE is not reachable, the procedure of the unsuccessful Mobile terminating SMS delivery described in clause 4.13.3.9 is performed and the following steps are skipped." [TDoc S2-2304317 and S2-2304318]
- "In order to permit the SMSF to create an accurate charging record, the AMF also includes IMEISV, the current UE Location Information (ULI) of the UE as defined in clause 5.6.2 of TS 23.501" [TDoc S2-2304317 and S2-2304318]
- "The SMSF acknowledges receipt of the delivery report to the UE." [TDoc S2-2304317 and S2-2304318]
- "The AMF transfers the SMS message to the UE." [TDoc S2-2304317 and S2-2304318]
- "The UDM shall return both SMSF addresses." [TDoc S2-2304317 and S2-2304318]

Technical differences between TDoc S2-2304246 and S2-2304248:

- TDoc S2-2304248 includes an additional requirement that the S-NSSAIs in the Requested NSSAI are part of the Configured and/or Allowed NSSAIs applicable for this PLMN, when they are available.
- No other technical differences are mentioned in the TDoc summaries.

Example snippets from TDoc S2-2304246:

- "When a new Allowed NSSAI for a PLMN and any associated mapping of the Allowed NSSAI to HPLMN S-NSSAIs are received over an Access Type, the UE shall:"
- "replace any stored (old) Allowed NSSAI and any associated mapping for these PLMN and Access Type with this new Allowed NSSAI;"
- "delete any stored associated mapping of this old Allowed NSSAI for this PLMN to HPLMN S-NSSAIs and, if present, store the associated mapping of this new Allowed NSSAI to HPLMN S-NSSAIs;"
- "If received, an S-NSSAI rejected for the entire PLMN shall be stored in the UE while RM-REGISTERED in this PLMN regardless of the Access Type or until it is deleted."
- "If received, the Allowed NSSAI for a PLMN and Access Type and any associated mapping of this Allowed NSSAI to HPLMN S-NSSAIs shall be stored in the UE."
- "The UE might also obtain one or more rejected S-NSSAIs with cause and validity of rejection from the AMF."

Example snippets from TDoc S2-2304248:

- "When a new Allowed NSSAI for a PLMN and any associated mapping of the Allowed NSSAI to HPLMN S-NSSAIs are received over an Access Type, the UE shall:"
- "replace any stored (old) Allowed NSSAI and any associated mapping for these PLMN and Access Type with this new Allowed NSSAI;"
- "delete any stored associated mapping of this old Allowed NSSAI for this PLMN to HPLMN S-NSSAIs and, if present, store the associated mapping of this new Allowed NSSAI to HPLMN S-NSSAIs;"
- "If received, an S-NSSAI rejected for the entire PLMN shall be stored in the UE while RM-REGISTERED in this PLMN regardless of the Access Type or until it is deleted."
- "If received, the Allowed NSSAI for a PLMN and Access Type and any associated mapping of this Allowed NSSAI to HPLMN S-NSSAIs shall be stored in the UE."
- "The S-NSSAIs in the Requested NSSAI are part of the Configured and/or Allowed NSSAIs applicable for this PLMN, when they are available."

3GPP-S2-156-e    Agenda Item 6.6 : Policy and charging control

3GPP-S2-156-e    Agenda Item 6.7 : 3GPP access specific functionality and flows

3GPP-S2-156-e    Agenda Item 7.2 : Wireless and Wireline Convergence for the 5G system architecture (5WWC)

Technical Differences Among TDocs:

1. TDoc S2-2304491 includes information about the 5G-GUTI assigned to N5CW device over 3GPP access in the NAI when the device has registered to 5GC over 3GPP access to 5GC of the selected PLMN. This is not mentioned in TDoc S2-2304492 or S2-2304493. Example snippet from TDoc S2-2304491: "If the N5CW device has registered to 5GC over 3GPP access to 5GC of the selected PLMN (i.e. it is also a 5G UE) when the above procedure is initiated, then the NAI includes the 5G-GUTI assigned to N5CW device over 3GPP access."

2. TDoc S2-2304492 skips mentioning the possibility of skipping PDU session parameters and letting the AMF or the SMF determine these parameters, while TDoc S2-2304491 and S2-2304493 mention this option. Example snippet from TDoc S2-2304491: "The TWIF may use default values to populate the parameters in the PDU Session Establishment Request message, but may also skip some PDU session parameters and let the AMF or the SMF determine these parameters based on the N5CW device subscription information received during the registration procedure."

3. TDoc S2-2304493 includes information about registering to the 5G core network over 3GPP access to 5GC of the selected SNPN, while TDoc S2-2304491 and S2-2304492 only mention registering over 3GPP access to 5GC of the selected PLMN. Example snippet from TDoc S2-2304493: "If the N5CW device has registered to 5GC over 3GPP access to 5GC of the selected PLMN or SNPN (i.e. it is also a 5G UE) when the above procedure is initiated, then the NAI includes the 5G-GUTI assigned to N5CW device over 3GPP access."

4. TDoc S2-2304493 skips mentioning that the selected NAS security algorithms of integrity protection and ciphering are set to NULL, while TDoc S2-2304491 and S2-2304492 mention this. Example snippet from TDoc S2-2304492: "The selected NAS security algorithms of integrity protection and ciphering are set to NULL."

5. TDoc S2-2304491 and S2-2304492 mention that a layer-2 or layer-3 connection is established between the Trusted WLAN Access Point and the TWIF for transporting all user-plane traffic of the N5CW device to TWIF, while TDoc S2-2304493 only mentions a layer-2 connection. Example snippet from TDoc S2-2304491: "A layer-2 or layer-3 connection is established between the Trusted WLAN Access Point and the TWIF for transporting all user-plane traffic of the N5CW device to TWIF."

6. TDoc S2-2304492 skips mentioning the possibility of using default values to populate the parameters in the PDU Session Establishment Request message, while TDoc S2-2304491 and S2-2304493 mention this. Example snippet from TDoc S2-2304493: "The TWIF may use default values to populate the parameters in the PDU Session Establishment Request message, but may also skip some PDU session parameters and let the AMF or the SMF determine these parameters based on the N5CW device subscription information received during the registration procedure."

• 5G-RG cannot support application descriptors, DNN, and connection capabilities for traffic from devices behind the 5G-RG.
• URSP focuses on determining if a detected application can be associated with an established PDU session, which means that the IP descriptor itself is insufficient to ensure that the 5G-RG establishes a PDU Session to the required DNN/S-NSSAI for traffic from devices behind the 5G-RG.
• Most of the traffic descriptors are not applicable to traffic from devices within the customer premises, i.e., to devices behind the 5G-RG.
• The underlying assumption of the URSP use by 5G-RG in TS 23.316 is that the 5G-RG would perform traffic inspection and match traffic against traffic descriptor components in URSP rules.
• Example snippet from TDoc S2-2304071: "URSP focuses on determining 'if a detected application can be associated to an established PDU Session'".
• Example snippet from TDoc S2-2304072: "URSP focuses on determining 'if a detected application can be associated to an established PDU Session'".
• Example snippet from TDoc S2-2304073: "URSP focuses on determining 'if a detected application can be associated to an established PDU Session'".
• URSP traffic descriptors (IP descriptor, domain descriptors, non-IP descriptors) are applicable to traffic from devices within the customer premises.
• Example snippet from TDoc S2-2304071: "most of the traffic descriptors are not applicable to traffic from devices within the customer premises".
• Example snippet from TDoc S2-2304072: "most of the traffic descriptors are not applicable to traffic from devices within the customer premises".
• Example snippet from TDoc S2-2304073: "most of the traffic descriptors are not applicable to traffic from devices within the customer premises".

- TDoc S2-2305095 specifies technical details related to PDU (Packet Data Unit) Session Establishment in order to support charging and fulfill regulatory requirements for providing Network Provided Location Information (NPLI) during the setup, modification, and release of IMS Voice calls or SMS transfer.
- The AMF (Access and Mobility Management Function) provides the SMF (Session Management Function) with the PEI (Packet Endpoint Identifier) of the UE (User Equipment) if available at the time of PDU Session Establishment.
- During UL (Uplink) NAS (Non-Access Stratum) or N2 signalling forwarding to a peer NF (Network Function) or during UP (User Plane) connection activation of a PDU Session, the AMF provides any User Location Information received from the 5G-AN (5G Access Network) and the Access Type (3GPP - Non 3GPP) of the AN over which it has received the UL NAS or N2 signalling.
- Upon successful PDU Session Establishment, the AMF and SMF store the Access Type associated with the PDU Session, with the AMF responsible for coordinating with the SMF.

Example snippet from TDoc S2-2305095: "At the time of PDU Session Establishment, the AMF provides the SMF with the PEI of the UE if the PEI is available at the AMF."
Example snippet from TDoc S2-2305095: "During UP connection activation of a PDU Session, the AMF provides any User Location Information it has received from the 5G-AN as well as the Access Type of the AN over which it has received the UL NAS or N2 signalling."
Example snippet from TDoc S2-2305095: "Upon successful PDU Session Establishment, the AMF and SMF stores the Access Type that the PDU Session is associated. In such case, the AMF is responsible to ensure the coordination between AMF and SMF."

- TDoc S2-2305096 also specifies technical details related to PDU Session Establishment to support charging and fulfill regulatory requirements for providing NPLI during the setup, modification, and release of IMS Voice calls or SMS transfer.
- The AMF provides the SMF with the PEI of the UE if available at the time of PDU Session Establishment.
- During UL NAS or N2 signalling forwarding to a peer NF or during UP connection activation of a PDU Session, the AMF provides any User Location Information received from the 5G-AN and the Access Type (3GPP - Non 3GPP) of the AN over which it has received the UL NAS or N2 signalling.
- Upon successful PDU Session Establishment, the AMF and SMF store the Access Type associated with the PDU Session, with the AMF responsible for coordinating with the SMF.

Example snippet from TDoc S2-2305096: "At the time of PDU Session Establishment, the AMF provides the SMF with the PEI of the UE if the PEI is available at the AMF."
Example snippet from TDoc S2-2305096: "During UL NAS or N2 signalling forwarding to a peer NF or during UP connection activation of a PDU Session, the AMF provides any User Location Information received from the 5G-AN and the Access Type of the AN over which it has received the UL NAS or N2 signalling."
Example snippet from TDoc S2-2305096: "Upon successful PDU Session Establishment, the AMF and SMF store the Access Type that the PDU Session is associated. In such case, the AMF is responsible to ensure the coordination between AMF and SMF."

- TNGF includes the UE's IP address in subsequent N2 messages after assignment (TDoc S2-2305097)
- TNGF sends EAP-Request/5G-Notification with TNGF Contact Info and UE ID after receiving TNGF key (TDoc S2-2305097)
- ULI in N2 message sent before UE is assigned an IP address contains null IP address (TDoc S2-2305097)
- 4-way handshake executed in IEEE Std 802.11 for security context between WLAN AP and UE (TDoc S2-2305097)
- Registration request may indicate UE's support for TNGF selection based on desired slices over trusted non-3GPP access (TDoc S2-2305098)
- AMF may determine target TNGF based on supported TAs and slices for each TA obtained in N2 interface management procedures (TDoc S2-2305098)
- UE selects PLMN and TNAN for connecting to PLMN using Trusted Non-3GPP Access Network selection procedure (TDoc S2-2305098)
- N2 message includes Selected PLMN ID, optional Selected NID, and Establishment cause (TDoc S2-2305098)
- TNGF key used for mutual authentication (TDoc S2-2305098)

Example snippets from TDoc S2-2305097:
- "After the UE is assigned an IP address, the TNGF includes this address in subsequent N2 messages."
- "The TNGF shall send to UE an EAP-Request/5G-Notification packet containing the 'TNGF Contact Info', which includes the IP address of TNGF."
- "In the N2 message sent in step 6b, the TNGF includes a UE Location Information (ULI) that contains a 'null' IP address (e.g. 0.0.0.0) because the UE is not yet assigned an IP address."
- "In the case of IEEE Std 802.11 [48], a 4-way handshake is executed, which establishes a security context between the WLAN AP and the UE that is used to protect unicast and multicast traffic over the air."

Example snippets from TDoc S2-2305098:
- "The registration request may contain an indication that the UE supports TNGF selection based on the slices the UE wishes to use over trusted non-3GPP access (i.e. that the UE supports Extended WLANSP rule)."
- "AMF may determine a target TNGF that supports the subset of the requested NSSAI that is allowed by the subscribed S-NSSAI(s) based on the list of supported TAs and the corresponding list of supported slices for each TA obtained in N2 interface management procedures as specified in TS 38.413"
- "UE which is not operating in SNPN access mode for Yt interface selects a PLMN and a TNAN for connecting to this PLMN by using the Trusted Non-3GPP Access Network selection procedure specified in clause 6.3.12 of TS 23.501"
- "This N2 message also includes the Selected PLMN ID and optionally the Selected NID, and the Establishment cause."

3GPP-S2-156-e    Agenda Item 7.4 : Cellular IoT support and evolution for the 5G System (5G_CIoT)

3GPP-S2-156-e    Agenda Item 7.7 : 5GS Enhanced support of Vertical and LAN Services (Vertical_LAN)

3GPP-S2-156-e    Agenda Item 7.8 : Enhancements to the Service-Based 5G System Architecture (5G_eSBA)

3GPP-S2-156-e    Agenda Item 7.9 : Architecture enhancements for the support of Integrated access and backhaul (IABARC)

TDoc S2-2304729:

- eNodeB selects an MME that supports IAB and includes IAB-indication in INITIAL UE MESSAGE for IAB authorization.
- UE Subscription data is enhanced to include IAB-authorization information.
- Authorization procedure is enhanced to verify IAB subscription information during UE attach procedure.
- UE Context setup/modification is enhanced to provide IAB authorized indication to eNodeB and IAB-donor gNB.
- Attach procedure is enhanced to indicate IAB-node's capability to MME.
- IAB-node provides IAB-indication to eNodeB when RRC connection is established.

Example snippet from TDoc S2-2304729: "If the IAB-indication is received, the eNodeB selects an MME that supports IAB, and includes the IAB-indication in the INITIAL UE MESSAGE so that the MME can perform IAB authorization."

TDoc S2-2304730:

- UE Subscription data is enhanced to include IAB-authorization information.
- Authorization procedure is enhanced to verify IAB subscription information during UE registration procedure.
- UE Context setup/modification is enhanced to provide IAB authorized indication to NG-RAN.
- Subscription data in TS 23.502 is enhanced to indicate IAB-node's capability to AMF.
- IAB-node provides IAB-indication to IAB-donor-CU when RRC connection is established.
- Registration procedure is enhanced to support IAB-UE operation.
- Existing UE authentication methods in TS 33.501 applies for IAB-UE operation.
- Procedures defined for UE are used for IAB-UE interaction with 5GC.

Example snippet from TDoc S2-2304730: "Authorization procedure during the UE Registration procedure is enhanced to perform verification of IAB subscription information."

Overall, TDoc S2-2304729 focuses more on the interaction between eNodeB and MME, while TDoc S2-2304730 focuses more on the interaction between UE and NG-RAN/5GC. Both TDcos enhance UE Subscription data to include IAB-authorization information and enhance authorization procedures to verify IAB subscription information. UE Context setup/modification is also enhanced to provide IAB authorized indication to different entities.

- The IAB-indication is received by the eNodeB, which selects an MME that supports IAB and includes the IAB-indication in the INITIAL UE MESSAGE for IAB authorization. (TDoc S2-2304731, S2-2304733)
- The UE Subscription data is enhanced to include authorization information for the IAB operation, and the authorization procedure during UE attach or registration is enhanced to verify IAB subscription information. (TDoc S2-2304731, S2-2304732, S2-2304733, S2-2304734)
- The UE Context setup/modification procedure is enhanced to provide IAB authorized indication to the eNodeB, IAB-donor gNB, or NG-RAN. (TDoc S2-2304731, S2-2304732, S2-2304733, S2-2304734)
- The Attach procedure or Registration procedure is enhanced to indicate IAB-node's capability to the MME or AMF. (TDoc S2-2304731, S2-2304732, S2-2304734)
- The IAB-node provides an IAB-indication to the eNodeB or IAB-donor-CU when the RRC connection is established. (TDoc S2-2304731, S2-2304734)
- The IAB-UE interacts with the EPC or 5GC using procedures defined for UE. (TDoc S2-2304731, S2-2304732, S2-2304733, S2-2304734)

Example snippets from the original TDocs:

- "If the IAB-indication is received, the eNodeB selects an MME that supports IAB, and includes the IAB-indication in the INITIAL UE MESSAGE so that the MME can perform IAB authorization" (TDoc S2-2304731)
- "the UE Subscription data as defined in clause 5.2.3 of TS 23.502 [3] is enhanced to include the authorization information for the IAB operation" (TDoc S2-2304732)
- "UE Context setup/modification procedure is enhanced to provide IAB authorized indication to NG-RAN" (TDoc S2-2304732)
- "The IAB-node provides an IAB-indication to the IAB-donor-CU when the RRC connection is established as defined in TS 38.331" (TDoc S2-2304734)
- "For the IAB-UE operation, the existing UE authentication methods as defined in TS 33.501 [29] applies" (TDoc S2-2304734)

3GPP-S2-156-e    Agenda Item 8.1 : Enablers for Network Automation for 5G - phase 2 (eNA_Ph2)

Technical Differences Among TDocs:

1. TDoc S2-2304780 and TDoc S2-2304781:

- Both TDocs mention the indication of Fetch Instructions in notifications sent by DCCF, NWDAF, or MFAF to the consumer.
- They both discuss Exact time-based Notification, where notifications are sent at an exact time, regardless of whether the event occurs.
- They both mention the processed notifications, which may comprise Event, Processing Interval, List of Event Parameter Name(s), and sets of attributes indicated in the processing instructions.
- They both discuss Event Spacing and Event Duration.

Example from TDoc S2-2304780: "Notifications are sent to the Consumer at an exact time, irrespective of whether the event occurs (example: every 30 min)."

2. TDoc S2-2304891:

- This TDoc mentions the allowed statistical properties for datasets, including uniformly distributed datasets and datasets with or without outliers.
- It also discusses the time when analytics information is needed by the NWDAF.
- It includes a note regarding periodic reporting mode and the periodicity of the report.

Example from TDoc S2-2304891: "The following dataset statistical properties are allowed: Uniformly distributed datasets, which indicates the use of data samples that are uniformly distributed according to the different aspects of the requested analytics..."

3. TDoc S2-2310692:

- This TDoc discusses the use of a new parameter named "Supported Nnwdaf Feature List" in the Nnwdaf_FeatureNotif service operation.
- It also mentions the use of an "NnwdafFeature" data structure and the inclusion of two new features in the feature list.

Example from TDoc S2-2310692: "This feature notification includes the new parameter Supported Nnwdaf Feature List, which includes a list of NnwdafFeature data structures."

4. TDoc S2-2310494:

- This TDoc discusses the addition of new parameters to the Nnwdaf_EventSubscription_Subscribe service operation.
- It also mentions the inclusion of new data structures in the response message of the Nnwdaf_EventSubscription_Subscribe service operation.

Example from TDoc S2-2310494: "The Nnwdaf_EventSubscription_Subscribe service operation includes new optional input parameters 'Subscription Lifetime' and 'Subscription Reference'."

5. TDoc S2-2310289:

- This TDoc discusses the addition of new data structures to the Nnwdaf_EventNotification service operation.
- It also mentions the inclusion of new parameters in the response message of the Nnwdaf_EventNotification service operation.

Example from TDoc S2-2310289: "The Nnwdaf_EventNotification service operation includes new data structures 'Event Information Request' and 'Event Information Response'."

Technical Differences:

1. TDoc S2-2304618 includes changes to an existing document while TDoc S2-2304622 is a revision of an existing document.

Example from TDoc S2-2304618: "This document presents changes made to document S2-2300743."

Example from TDoc S2-2304622: "This document is a revision of document S2-2300825."

2. TDoc S2-2304618 has a different meeting number than TDoc S2-2304622.

Example from TDoc S2-2304618: "3GPP TSG-SA WG2 Meeting #156e"

Example from TDoc S2-2304622: "3GPP TSG-SA WG2 Meeting #156e_Rev1"

3. TDoc S2-2304618 contains all new text while TDoc S2-2304622 is a revision of an existing document.

Example from TDoc S2-2304618: "* * Start of Change * * * End of Changes * * * * * * * * * * (All new text)"

Example from TDoc S2-2304622: "* * Start of Change * * * End of Changes * * * * * * * * * * (Changes are highlighted in red)"

4. TDoc S2-2304618 has a different document number than TDoc S2-2304622.

Example from TDoc S2-2304618: "S2-2304618"

Example from TDoc S2-2304622: "S2-2304622"

5. TDoc S2-2304618 presents changes made to a document while TDoc S2-2304622 presents changes made to an existing document.

Example from TDoc S2-2304618: "This document presents changes made to document S2-2300743."

Example from TDoc S2-2304622: "This document presents changes made to document S2-2300825."

6. TDoc S2-2304618 was presented at the April 17th - 21st, 2023 e-meeting while TDoc S2-2304622 does not have a specific meeting date.

Example from TDoc S2-2304618: "3GPP TSG-SA WG2 Meeting #156e S2-2304618 E-meeting, April 17th – 21st, 2023 (revison of S2-2300743)"

Example from TDoc S2-2304622: "This document is a revision of document S2-2300825."

Technical differences among the following TDocs:

- TDoc S2-2304620: This TDoc describes the process of the NEF determining the PDU session used for the user plane connection between UE and AF. The NEF sends an Nsmf_EventExposure_Subscribe to the SMF(s) identified, with the Target for Event Reporting set to the PDU Session id(s) provided and the Event ID set to IP address/prefix allocation/change. The AF in an untrusted domain correlates UE data collection and NWDAF request, and requests the NEF to provide the allocated IPv4 address or IPv6 prefix or both. If the user plane session between UE and AF is released, the AF removes the stored correlation information between the UE IP address/prefix and GPSI.
- TDoc S2-2304623: This TDoc is identical to TDoc S2-2304620, except for the "Start of Change" note at the end.
- TDoc S2-2305220: This TDoc describes additional factors that may be considered when selecting an NWDAF for ML model provisioning. The NWDAF may consider the ML model Filter information parameters S-NSSAI(s) and Area(s) of Interest, as well as the NWDAF Serving Area information, i.e. list of TAIs for which the NWDAF can provide analytics, trained ML models, and/or data. The NF consumer may consider the S-NSSAI, Analytics ID(s), supported service(s), and supported Analytics Delay of the requested Analytics ID(s). In the case of multiple instances of NWDAFs deployment, the NWDAF capabilities, including Analytics aggregation capability and Analytics metadata provisioning capability, may also be considered.

Example snippets from the original TDocs:

- TDoc S2-2304620: "Using the configuration in NEF, as described in step 2, the NEF determines the PDU session used for the user plane connection between UE and AF."
- TDoc S2-2304620: "The NEF sends Nsmf_EventExposure_Subscribe to the SMF(s) identified in step 3, including the Target for Event Reporting set to the PDU Session id(s) provided in step 3 and the Event ID set to IP address/prefix allocation/change."
- TDoc S2-2304620: "If the AF receives the Naf_EventExposure_Subscribe from NWDAF, via NEF, including Target for Event Reporting set to GPSI and not including the UE's IP address and the AF does not locally store the UE's IP address, the AF request the NEF to provide the allocated IPv4 address or IPv6 prefix or both as described in Figure 6.2.8.2.4.3-1."
- TDoc S2-2305220: "The NWDAF may consider the ML model Filter information parameters S-NSSAI(s) and Area(s) of Interest."
- TDoc S2-2305220: "The NF consumer may consider the S-NSSAI, Analytics ID(s), supported service(s), and supported Analytics Delay of the requested Analytics ID(s)."
- TDoc S2-2305220: "The NWDAF capabilities, including Analytics aggregation capability and Analytics metadata provisioning capability, may also be considered."

[TDoc S2-2304892]:

- Allowed dataset statistical properties include uniformly distributed datasets, datasets with or without outliers, and time when analytics information is needed.
- These optional parameter types enable the selection of requested analytics information.

[TDoc S2-2305145]:

- ML model related information includes ID(s) of NWDAF(s) containing MTLF, file address of the ML model(s), ID of the analytics consumer subscribed to receive analytics, and (set of) analytics context identifier(s).
- Procedure in Figure 6.1B.2.2-1 is used to request the transfer of analytics subscription(s) to another NWDAF instance.

[TDoc S2-2305146]:

- Same ML model related information as TDoc S2-2305145.
- Procedure in Figure 6.1B.2.2-1 is used to request the transfer of analytics subscription(s) to another NWDAF instance.

[TDoc S2-2305219]:

- In order to discover an NWDAF containing MTLF via NRF, an NWDAF containing MTLF must include ML model provisioning services as one of the supported services during registration in NRF.
- The NRF returns one or more candidates for instances of NWDAF containing MTLF to the NF consumer, including Analytics ID(s) and trained ML model information if available.

3GPP-S2-156-e    Agenda Item 8.2 : Enhanced support of Non-Public Networks (eNPN)

• TDoc S2-2304097 specifies that if the SNPN acting as ON-SNPN is capable of providing access to localized services, both DCS provided and locally configured PVS IP address(es) and/or PVS FQDN(s) should be included in the UE Configuration Data for User Plane Remote Provisioning.

- "If the SNPN acting as ON-SNPN is capable to provides access to localized services, the SMF should include both DCS provided and the locally configured PVS IP address(es) and/or PVS FQDN(s), in the UE Configuration Data for User Plane Remote Provisioning."

• The UE Configuration Data for User Plane Remote Provisioning may be provided to the UE during the establishment of the PDU Session used for User Plane Remote Provisioning as part of Protocol Configuration Options (PCO) in the PDU Session Establishment Response.

- "The UE Configuration Data for User Plane Remote Provisioning may be provided to the UE during the establishment of the PDU Session used for User Plane Remote Provisioning as part of Protocol Configuration Options (PCO) in the PDU Session Establishment Response." (TDoc S2-2304097 and TDoc S2-2304098)

• If the SNPN acting as ON-SNPN is not capable of providing access to localized services, the PVS IP address(es) and/or PVS FQDN(s) provided by the DCS take precedence over the locally configured PVS IP address(es) and/or PVS FQDN(s) in the ON-SNPN.

- "If the SNPN acting as ON-SNPN is not capable to provide access to localized services, the PVS IP address(es) and/or PVS FQDN(s) provided by the DCS take precedence over the locally configured PVS IP address(es) and/or PVS FQDN(s) in the ON-SNPN." (TDoc S2-2304097)

• UE Configuration Data for User Plane Remote Provisioning are either pre-configured on the UE or provided by the ONN.

- "In order to enable UP Remote Provisioning of SNPN credentials for a UE, UE Configuration Data for User Plane Remote Provisioning are either pre-configured on the UE or provided by the ONN." (TDoc S2-2304097 and TDoc S2-2304098)

• UE Configuration Data for User Plane Remote Provisioning provided by the ONN take precedence over corresponding configuration data stored in the UE.

- "UE Configuration Data for User Plane Remote Provisioning provided by the ONN take precedence over corresponding configuration data stored in the UE." (TDoc S2-2304098)

• UE Configuration Data for User Plane Remote Provisioning consist of PVS IP address(es) and/or PVS FQDN(s).

- "UE Configuration Data for User Plane Remote Provisioning consist of PVS IP address(es) and/or PVS FQDN(s)." (TDoc S2-2304098)

• The UE Configuration Data for User Plane Remote Provisioning (i.e. PVS IP address(es) or PVS FQDN(s), or both) may be locally configured in the SMF of ONN.

- "The UE Configuration Data for User Plane Remote Provisioning (i.e. PVS IP address(es) or PVS FQDN(s), or both) may be either: - locally configured in the SMF of ONN;" (TDoc S2-2304098)

• The UE Configuration Data for User Plane Remote Provisioning (i.e. PVS IP address(es) or PVS FQDN(s), or both) may be provided by the DCS to the AMF of ON-SNPN as part of the authentication procedure as specified in TS 33.501.

- "The UE Configuration Data for User Plane Remote Provisioning (i.e. PVS IP address(es) or PVS FQDN(s), or both) may be either: [...] - provided by the DCS to the AMF of ON-SNPN as part of the authentication procedure as specified in TS 33.501." (TDoc S2-2304098)

- TDoc S2-2305023 includes information on localized services, whereas the other TDocs do not mention this.
- The UE Configuration Data for User Plane Remote Provisioning may be stored in the ME in all TDocs.
- The SMF sends the PVS FQDN(s) and/or PVS IP address(es) associated to the DNN and S-NSSAI of the PDU Session to the UE as part of Protocol Configuration Options (PCO) in the PDU Session Establishment Response if certain conditions are met in all TDocs.
- The UE subscription data must contain the DNN and S-NSSAI used for onboarding in all TDocs.
- The SMF must have obtained the PVS FQDN(s) and/or PVS IP address(es) associated to the DNN and S-NSSAI of the PDU Session from local configuration in all TDocs.
- The UE must request PVS information via PCO in PDU Session Establishment Request in all TDocs.

Example snippets from TDoc S2-2304227:
- "The SMF sends the PVS FQDN(s) and/or PVS IP address(es) associated to the DNN and S-NSSAI of the PDU Session to the UE as part of Protocol Configuration Options (PCO) in the PDU Session Establishment Response if the following conditions are met:"
- "The UE Configuration Data for User Plane Remote Provisioning may be provided to the UE during the establishment of the PDU Session used for User Plane Remote Provisioning as part of Protocol Configuration Options (PCO) in the PDU Session Establishment Response."
- "The UE Configuration Data for User Plane Remote Provisioning may be stored in the ME."

Example snippets from TDoc S2-2304228:
- "The SMF sends the PVS FQDN(s) and/or PVS IP address(es) associated to the DNN and S-NSSAI of the PDU Session to the UE as part of Protocol Configuration Options (PCO) in the PDU Session Establishment Response if the following conditions are met:"
- "The UE Configuration Data for User Plane Remote Provisioning may be provided to the UE during the establishment of the PDU Session used for User Plane Remote Provisioning as part of Protocol Configuration Options (PCO) in the PDU Session Establishment Response."
- "The UE Configuration Data for User Plane Remote Provisioning may be stored in the ME."

Example snippets from TDoc S2-2305022:
- "The SMF sends the PVS FQDN(s) and/or PVS IP address(es) associated to the DNN and S-NSSAI of the PDU Session to the UE as part of Protocol Configuration Options (PCO) in the PDU Session Establishment Response if the following conditions are met:"
- "The UE Configuration Data for User Plane Remote Provisioning may be provided to the UE during the establishment of the PDU Session used for User Plane Remote Provisioning as part of Protocol Configuration Options (PCO) in the PDU Session Establishment Response."
- "The UE Configuration Data for User Plane Remote Provisioning may be stored in the ME."

Example snippets from TDoc S2-2305023:
- "The SMF sends the PVS FQDN(s) and/or PVS IP address(es) associated to the DNN and S-NSSAI of the PDU Session to the UE as part of Protocol Configuration Options (PCO) in the PDU Session Establishment Response if the following conditions are met:"
- "If the SNPN acting as ON-SNPN is capable to provides access to localized services, the SMF should include both DCS provided and the locally configured PVS IP address(es) and/or PVS FQDN(s), in the UE Configuration Data for User Plane Remote Provisioning."
- "The UE Configuration Data for User Plane Remote Provisioning may be provided to the UE during the establishment of the PDU Session used for User Plane Remote Provisioning as part of Protocol Configuration Options (PCO) in the PDU Session Establishment Response."
- "The UE Configuration Data for User Plane Remote Provisioning may be stored in the ME."

3GPP-S2-156-e    Agenda Item 8.3 : Enhancement of support for Edge Computing in 5GC (eEDGE_5GC)

• TDoc S2-2304160 and S2-2304161 both deal with PDU Sessions and AF requests.

• In S2-2304160, when the AF request is for influencing SMF routing decisions, it only applies to the traffic of UE(s) located in the specified location. The AF subscription can 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.

• S2-2304161 also states that when the AF request is for influencing SMF routing decisions, it only applies to the traffic of UE(s) located in the specified location. 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.

• S2-2304160 states that when the AF request is for subscription to notifications about UP path management events, it only applies to the traffic of UE(s) located in the specified location. 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 UE location presence in the area of interest.

• Similarly, S2-2304161 states that when the AF request is for subscription to notifications about UP path management events, it only applies to the traffic of UE(s) located in the specified location. 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 UE location presence in the area of interest.

• The spatial validity condition in both TDocs indicates that the request or subscription only applies to the traffic of UE(s) located in the specified location.

• Both TDocs specify that the PCF generates a PCC rule based on the AF request and takes into account the UE location presence in the area of interest.

• S2-2304160 mentions that the corresponding information is sent by the SMF regardless of whether a DNAI applies to the PDU Session when the AF request is for 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.

• Both TDocs include AF requirements for User Plane latency when the AF request is for subscription to notifications about UP path management events.

TDoc S2-2305305:

- NEF may request UDM for service specific authorization for group related data, including DNN and S-NSSAI associated with the group.
- Operator must ensure consistency between group related data and UE group members subscription data.
- NEF may request UDM for service specific authorization for service parameters for an individual UE based on operator's local policy.
- Group identifier can be used to identify UE(s) of external party.

Example snippet from TDoc S2-2305305 to support the difference highlighting: "NEF may also request UDM for service specific authorization for the group related data (see table 4.15.6.3b-1), i.e. the DNN, S-NSSAI associated to the group."

TDoc S2-2305306:

- NEF may request UDM for service specific authorization for group related data, including DNN and S-NSSAI associated with the group.
- Information on the AF guidance for URSP determination is provided, which consists of a list of URSP rules that associate an application traffic descriptor with requested features for the candidate PDU sessions the application traffic may use.
- NEF may request UDM for service specific authorization for service parameters for an individual UE based on operator's local policy.
- AF targets the AF guidance for URSP determination only with the inbound roamers of corresponding PLMN(s).
- PLMN ID is included in the Service Parameters.

Example snippet from TDoc S2-2305306 to support the difference highlighting: "Information on the AF guidance for URSP determination which consists of a list of URSP rules that associate an application traffic descriptor with requested features for the candidate PDU sessions the application traffic may use."

3GPP-S2-156-e    Agenda Item 8.4 : Enhancement of Network Slicing Phase 2 (eNS_Ph2)

3GPP-S2-156-e    Agenda Item 8.5 : Enhanced support of Industrial IoT - TSC/URLLC enhancements (IIoT)

3GPP-S2-156-e    Agenda Item 8.7 : Support of Aerial Systems Connectivity, Identification, and Tracking (ID_UAS)

3GPP-S2-156-e    Agenda Item 8.8 : System enhancement for Proximity based Services in 5GS (5G_ProSe)

- TDoc S2-2304803 and TDoc S2-2304804 both deal with monitoring authorization policies for 5G ProSe Direct Discovery Model A.
- Both TDocs refer to PLMNs in which the UE is authorized to perform ProSe Direct Discovery monitoring.
- Both TDocs are applied to 5G ProSe Direct discovery/communications over NR PC5 reference point.
- When the UE is "not served by NG-RAN," both TDocs specify whether the UE is authorized to perform 5G ProSe Direct Discovery for Model A and Model B.
- Note 4 in both TDocs explains that the values provisioned for the Destination Layer-2 ID(s) for 5G ProSe Direct Discovery, for Destination Layer-2 ID(s) for 5G ProSe Direct Communication, and for Destination Layer-2 ID(s) for 5G ProSe UE-to-Network Relay Discovery are different from each other.
- Both TDocs specify the application identifiers to be used for 5G ProSe Direct Discovery over PC5 interface.

Example snippets from the original TDoc to support the difference highlighting:

- TDoc S2-2304803: "PLMNs in which the UE is authorised to perform restricted 5G ProSe Direct Discovery"
- TDoc S2-2304804: "PLMNs in which the UE is authorised to perform 5G ProSe Direct Discovery monitoring"
- TDoc S2-2304803: "Indicates whether the UE is authorized to perform 5G ProSe Direct Discovery for Model A and Model B when 'not served by NG-RAN'"
- TDoc S2-2304804: "Indicates whether the UE is authorized to perform 5G ProSe Direct Discovery for Model A and Model B when 'not served by NG-RAN'"
- TDoc S2-2304803: "NOTE 4: The values provisioned for the Destination Layer-2 ID(s) for 5G ProSe Direct Discovery, for Destination Layer-2 ID(s) for 5G ProSe Direct Communication, defined in clause 5.1.3.1 and for Destination Layer-2 ID(s) for 5G ProSe UE-to-Network Relay Discovery defined in clause 5.1.4.1, are different from each other."
- TDoc S2-2304804: "NOTE 4: The values provisioned for the Destination Layer-2 ID(s) for 5G ProSe Direct Discovery, for Destination Layer-2 ID(s) for 5G ProSe Direct Communication, defined in clause 5.1.3.1 and for Destination Layer-2 ID(s) for 5G ProSe UE-to-Network Relay Discovery defined in clause 5.1.4.1, are different from each other."

3GPP-S2-156-e    Agenda Item 8.14 : Enhancement to the 5GC LoCation Services-Phase 2 (5G_eLCS_Ph2)

3GPP-S2-156-e    Agenda Item 8.21 : Dynamically Changing AM Policies in the 5GC (TEI17_DCAMP)

3GPP-S2-156-e    Agenda Item 8.27 : Architecture support for NB-IoT/eMTC Non-Terrestrial Networks in EPS (IoT_SAT_ARCH_EPS)

• TDoc S2-2304203 and TDoc S2-2304204 both discuss the setting of PDU session types in 5GS based on the PDN type of a PDN connection in EPS.
• The specific trigger for this setting can include new radio conditions, load balancing, or specific services such as QoS flows for voice.
• A generic mechanism exists for the source NG-RAN node to retrieve information on the level of support for a certain feature at the target NG-RAN side associated with an NGAP IE.
• If the non-IP PDN type is locally associated in UE and SMF to PDU session type Ethernet, it means that Ethernet PDN type is not supported in EPS.
• The mechanism uses the Source to Target and Target to Source transparent containers.
• TDoc S2-2304203 specifies that if the PDN type is non-IP and locally associated in UE and SMF to PDU session type Ethernet or Unstructured, the PDU session type in 5GS shall be set to Ethernet or Unstructured respectively.
• TDoc S2-2304204 repeats the information from TDoc S2-2304203 but with different numbering (i.e., [2] instead of [10]) and without any additional information.

Technical Differences:

1. TDoc S2-2304292 and TDoc S2-2304293 both have the same change regarding the use of extended NAS timers when the UE is accessing the network using a satellite RAT. However, they have different document numbers and meeting details.

2. There are no other technical differences between the two TDocs.

Examples from the Original TDoc:

- "Whenever the UE is accessing the network using a satellite RAT, the MME shall set the NAS timers long enough according to TS 24.301 [46]." (TDoc S2-2304292 and TDoc S2-2304293)

- "# 156-e 17-21 April 2023, Electronic Meeting was S2-2302441" (TDoc S2-2304292)

- "# 156-e 17-21 April 2023, Electronic Meeting was S2-2302442" (TDoc S2-2304293)

• The first TDoc snippet discusses the MME's action when requested to monitor reachability for data and the UE enters ECM-CONNECTED. The MME sends a monitoring report message to the address indicated in the related monitoring request.

Example: "If the MME is requested to monitor Reachability for Data and the UE enters ECM-CONNECTED, the MME sends a Monitoring Report message to the address that was indicated in the related Monitoring Request as described in TS 23.682."

• The second TDoc snippet discusses the UE's action when the periodic LAU timer expires while EPS attached only and either camps on an E UTRAN cell or is in ECM CONNECTED state. The UE shall perform a Location Area Update procedure in NMO II or combined RA/LA update in NMO I when it next returns to GERAN/UTRAN coverage.

Example: "If the UE is EPS attached only and either camps on an E UTRAN cell or is in ECM CONNECTED state when the UE's periodic LAU timer expires, the UE shall perform a Location Area Update procedure in NMO II or combined RA/LA update in NMO I when it next returns to GERAN/UTRAN coverage."

• The third TDoc snippet discusses the MME's action when the PPF flag is set in the MME and the UE leaves EUTRAN connection due to handover to GERAN/UTRAN. The MME should clear the PPF flag and start an Implicit Detach timer with a relatively large value, slightly larger than the UE's E-UTRAN Deactivate ISR timer if ISR is activated.

Example: "Instead the MME should clear the PPF flag in the MME and start an Implicit Detach timer, with a relatively large value and if ISR is activated, at least slightly larger than the UE's E-UTRAN Deactivate ISR timer."

• The fourth TDoc snippet discusses the UE's periodic TAU timer, which is restarted from its initial value whenever the UE enters ECMIDLE mode and when the UE leaves the EUTRAN connection due to handover to GERAN/UTRAN. The MME may allocate a long periodic TAU timer value to the UE according to clause 4.3.17.3.

Example: "The UE's periodic TAU timer is restarted from its initial value whenever the UE enters ECMIDLE mode and when the UE leaves the EUTRAN connection due to handover to GERAN/UTRAN. The MME may allocate long periodic TAU timer value to the UE according to clause 4.3.17.3."

• Both TDoc snippets are identical and discuss the MME's action when requested to monitor reachability for data and the UE enters ECM-CONNECTED. The MME sends a monitoring report message to the address indicated in the related monitoring request.

Example: "If the MME is requested to monitor Reachability for Data and the UE enters ECM-CONNECTED, the MME sends a Monitoring Report message to the address that was indicated in the related Monitoring Request as described in TS 23.682."

3GPP-S2-156-e    Agenda Item 8.28 : Rel-17 CAT B/C alignment CR(s) due to the work led by other 3GPP Working Groups

1. TDoc S2-2304214 introduces a new UDM service for verifying the usage of AF specific UE IDs, which can be used by PCF and NEF to allow or reject AF requests based on the validity of the AF specific UE ID/AF ID pair. The NEF is not involved in the interaction between AF and CN, but the PCF/NEF can verify the validity of the AF specific UE ID/AF ID pair through the UDM service.

Example snippet from TDoc S2-2304214: "The PCF/NEF, when needed, queries the UDM to verify that a certain AF specific UE ID/AF ID pair is valid."

2. TDoc S2-2304215 and S2-2304216 discuss how an AF can identify the target UE of an AF request for external exposure of 5GC capabilities (e.g. data provisioning or event exposure) by providing the UE's address information. The NEF may provide an AF specific UE Identifier to the AF based on the address of the UE and the corresponding DNN and/or S-NSSAI information.

Example snippet from TDoc S2-2304215: "The NEF may provide an AF specific UE Identifier to the AF that has explicitly requested a translation from the address of the UE to a unique UE identifier (via Nnef_UEId service)."

3. TDoc S2-2304219 and S2-2304220 reiterate the same point as S2-2304215 and S2-2304216, that an AF can only identify the target UE of an AF request for external exposure of 5GC capabilities by providing the UE's address information.

Example snippet from TDoc S2-2304219: "The NEF may provide an AF specific UE Identifier to the AF that has implicitly requested a translation from the address of the UE to a AF specific UE Identifier by requesting external exposure about an individual UE identified by its address."

Overall, the technical differences among these TDdocs mainly relate to the introduction of a new UDM service in S2-2304214 and the discussion of how an AF can identify the target UE of an AF request for external exposure of 5GC capabilities in the other TDdocs. The examples provided in the TDdocs highlight the specific ways in which NEF can provide AFs with a unique UE identifier based on the UE's address information, either explicitly or implicitly.

- TDoc S2-2304278 highlights the technical difference in core network assistance for PEIPS, which uses paging subgrouping support indication and PEIPS assistance information to determine the paging subgroup for the UE. Both the AMF and NG-RAN use this information to allocate subgroups consistently across all AMFs connected to one gNB. This is in compliance with TS 38.300.
- TDoc S2-2304542 focuses on monitoring capability, which allows identification of the 5G network function suitable for configuring specific monitoring events, detecting them, and reporting them to the authorized external party. The Expected UE Behaviour parameters can be used to set mobility and session management parameters of the UE. The UE Member selection capability allows external parties to acquire lists of candidate UEs based on filtering criteria from assistance information generated by the 5G system.
- TDoc S2-2304544 highlights the need for usage restrictions of AF specific UE Identifier to be enforced between NEF and other 5GC NFs that may expose services accepting AF Specific UE Identifiers. The AF Specific UE Identifier can be ensured to be different for different AFs by MNO configuration, and GPSI is an optional input parameter for PolicyControl services.
- TDoc S2-2305225 is similar to TDoc S2-2304542 in terms of monitoring capability, Expected UE Behaviour parameters, and UE Member selection capability. The NEF can support exposure of 5GS and/or UE availability and capabilities for time synchronization service, and an AF can identify the target UE for external exposure of 5GC capabilities by providing the UE's address information. There is an asterisk (*) indicating that this proposal may be incomplete or require further review.

Example snippets from the original TDoc to support the difference highlighting:

- For TDoc S2-2304278: "To support the Paging Early Indication with Paging Subgrouping (PEIPS), Paging Subgrouping Support Indication and the PEIPS Assistance Information is used by the AMF and NG-RAN to help determine whether PEIPS applies to the UE and which paging subgroup used when paging the UE (see TS 38.300)."
- For TDoc S2-2304542: "The UE Member selection capability is for allowing an external party to acquire one or more list(s) of candidate UE(s) (among the list of target member UE(s) provided by the AF) and additional information that is based on the assistance information generated by 5G System based on some defined filtering criteria, the details are explained in clause 4.15.13 in TS 23.502."
- For TDoc S2-2304544: "Considering the above, we could infer that an inter-NF (i.e., between NEF and other 5GC NFs that may expose services accepting AF Specific UE Identifiers) enforcement of usage restrictions of AF specific UE Identifier is not needed."
- For TDoc S2-2305225: "The NEF may support exposure of 5GS and/or UE availability and capabilities for time synchronization service as specified in clause 5.27.1.8. An AF may only be able to identify the target UE of an AF request for external exposure of 5GC capabilities (e.g. Data Provisioning or for Event Exposure for a specific UE) by providing the UE's address information."

Technical differences among the listed TDocs:

1. TDoc S2-2303921: Defines the format for Local Identifier and External Identifier as specified in TS 23.682 and TS 23.003 respectively. SA2 requests SA3 to consider these specifications and make changes in TS 23.501 accordingly.

Example snippet: "The username part format of the External Identifier shall contain a Local Identifier as specified in 3GPP TS 23.682"

2. TDoc S2-2304217: Describes how the AF can obtain an AF specific UE ID and use NEF provided services. Introduces a new service operation Nudm_AFSpecificUEID Verify and updates the table in clause 5.2.3.1 to include this operation.

Example snippet: "The changes introduced can be summarized as follows: Introduced new clause 4.15.10A to describe how the new Nudm_AFSpecificUEID Verify service operation is used by the PCF and NEF"

3. TDoc S2-2304218: Similar to TDoc S2-2304217, describes how the AF can obtain an AF specific UE ID and use NEF provided services. Also introduces a new service operation Nudm_AFSpecificUEID Verify and updates the table in clause 5.2.3.1 to include this operation.

Example snippet: "The changes introduced can be summarized as follows: Introduced new clause 4.15.10A to describe how the new Nudm_AFSpecificUEID Verify service operation is used by the PCF and NEF"

4. TDoc S2-2304340: Highlights the requirement for disabling power saving mechanisms while the UE has an active emergency PDU session, as specified in TS 23.501 clause 5.12.4 and TS 24.501 clause 5.3.25. Asks RAN2 and RAN3 to ensure that the behaviour of a UE with an active emergency PDU session is aligned with this requirement.

Example snippet: "SA2 asks RAN2 and RAN3 to ensure that the behaviour of a UE with an active emergency PDU session specifically with regards to the use of PEI and UE ID based sub grouping and any other power saving mechanisms in general is aligned with the stage 2 requirement"

1. Use of PEI during an emergency PDU session is not supported when it comes to CM-IDLE paging and CM-CONNECTED paging (RAN paging on Xn/F1).
- "disabling UE-ID based PEI for CM-IDLE paging (Paging on NG) and CM-CONNECTED paging (RAN paging on Xn/F1) during an emergency PDU session is not supported" (TDoc S2-2303953)

2. The UE-ID based PEI capability (pei-SubgroupingSupportBandList-r17) is signalled in the PAGING message (UERadioPagingInformation) from either AMF or the last serving gNB.
- "The UE-ID based PEI capability (pei-SubgroupingSupportBandList-r17) is signalled in the PAGING message (UERadioPagingInformation) either from AMF or from the last serving gNB" (TDoc S2-2303953)

3. UE-ID based PEI is used even when the UE has an emergency PDU session, based on the UE capability and gNB’s configuration (PEI-Config-r17).
- "Based on the UE capability and gNB’s configuration (PEI-Config-r17) UE-ID based PEI is used even when the UE has an emergency PDU session" (TDoc S2-2303953)

4. Latency introduced by UE-ID based PEI (similar as for CN-assigned PEI) depends on the configured time offset between PEI and the following Paging Occasion (PO) e.g. 50 ms.
- "The latency introduced by UE-ID based PEI (similar as for CN-assigned PEI) depends on the configured time offset between PEI and the following Paging Occasion (PO) e.g. 50 ms" (TDoc S2-2303953)

5. CN-assigned PEI (PEIPS Assistance Information) is not used when the UE has an emergency PDU session, but UE-ID based PEI is used.
- "This means that when the UE has an emergency PDU session the CN-assigned PEI (PEIPS Assistance Information) is not used, but UE-ID based PEI is used" (TDoc S2-2303953)

6. SA2 has agreed to restrict the use of the PEI function, even when UE-ID based PEI function is deployed in the network.
- "SA2 has agreed the attached CR to restrict the use of the PEI function even when UE-ID based PEI function is deployed in the network" (TDoc S2-2304192)

7. Power-saving related functions shall be disabled in SA2 specs when UE has emergency PDU session.
- "SA2 considers power-saving related functions shall be disabled in SA2 specs when UE has emergency PDU session. This general rule shall be followed to avoid any delay related to emergency service" (TDoc S2-2304192)

8. SA2 thanks RAN2 for their LS on the use of PEI during an emergency PDU session.
- "SA2 thanks RAN2 for their LS on the use of PEI during an emergency PDU session (R2-2302302 / S2-2303953)" (TDoc S2-2305229)

9. TS 23.501 already contains a statement in clause 5.4.12.2 that "when the UE has an active emergency PDU Session: - The UE shall not signal Paging Subgrouping Support Indication in the Registration Request message."
- "Regarding the use of CN-based PEI while an emergency PDU session is active, SA2 would like to point out that TS 23.501 already contains this statement in clause 5.4.12.2: “When the UE has an active emergency PDU Session: - The UE shall not signal Paging Subgrouping Support Indication in the Registration Request message”" (TDoc S2-2305229)

3GPP-S2-156-e    Agenda Item 9.1.2 : 5G System with Satellite Backhaul (5GSATB)

[TDoc S2-2304388]:
- The AMF may determine the GEO Satellite ID serving the UE and send it to the SMF.
- The SMF selects the UL CL/BP/local PSA based on the DNAI corresponding to the GEO Satellite ID and other factors.
- The SMF is locally configured with mapping relationship between DNAI and GEO Satellite ID.
- Edge Computing via UPF deployed on satellite only applies to GEO satellite backhaul.

[TDoc S2-2304647]:
- The (H-)PCF gets policy subscription related information and the latest list of PSIs from the UDR using Nudr_DM_Query service operation.
- The V-PCF provides the Service Parameters to the H-PCF in roaming scenario.
- The AMF may provide to the V-PCF the PCF ID of the selected H-PCF based on operator policies.

[TDoc S2-2304673]:
- The AMF shall contact the PCF when the UE requested a DNN within the list of DNN candidates for replacement for the S-NSSAI indicated in the Access and mobility related policy information.
- The AMF shall contact the PCF when the AMF detects that the UE requested an unsupported DNN and the PCF indicated DNN replacement of unsupported DNNs in the Access and mobility related policy information.
- The AMF interacts with the PCF for all changes in the Service Area restriction or RFSP index data.
- The AMF interacts with the PCF when the list of NWDAF Instance IDs used for the UE or associated Analytics IDs used for the UE at the AMF are changed in the AMF.
- The AMF interacts with the PCF when the Generation of a Target NSSAI trigger is triggered.

[TDoc S2-2304822]:
- The DNN, S-NSSAI corresponding to the PDU session are sent.
- The event notification may contain information such as "EARLY" or "LATE", DNAI, UE IP address / Prefix, N6 traffic routing information, Candidate DNAI(s) for the PDU Session, and Change of common EAS.
- QoS Monitoring report for the QoS parameter(s) to be measured may be included.

[TDoc S2-2304823]:
- The SMF may need to send transparently through NG-RAN the PDU Session Modification Command to inform the UE about changes in the QoS parameters.
- The SMF is responsible for updating the QoS rules and QoS Flow level QoS parameters if needed for the QoS Flow(s) associated with the QoS rule(s) in the UE accordingly.
- An RRC Connection Reconfiguration may take place with the UE modifying the necessary (R)AN resources related to the PDU Session or only N1 SM container is received in step 4 from AMF.

[TDoc S2-2304843]:
- The UE and the AF shall provide all available flow description information to enable the binding functionality and the generation or selection of the service data flow filter(s) in the PCC rules.
- To use ToS/TC for service data flow detection, network configuration by the operator needs to ensure there is no ToS/TC re-marking applied along the path from the application to the PSA UPF and the specific ToS/TC values are managed properly.
- QoS Monitoring control enables real-time measurements of QoS parameters for a service data flow.

TDoc S2-2305117:

- The UE and the AF must provide flow description information to enable binding functionality and generation or selection of service data flow filters in PCC rules.
- To use ToS/TC for service data flow detection, network configuration needs to ensure no re-marking is applied along the path and ToS/TC values are managed properly to avoid collision with other usage.
- QoS control refers to authorization and enforcement of maximum QoS for service data flow, QoS Flow, or PDU Session.

Example snippets:

- "The UE and the AF shall provide all available flow description information (e.g. source and destination IP address and port numbers and the protocol information) to enable the binding functionality and the generation or selection of the service data flow filter(s) in the PCC rules."
- "To use ToS/TC for service data flow detection, network configuration by the operator...needs to ensure...the specific ToS/TC values are managed properly to avoid potential collision with other usage."
- "Policy control QoS control refers to the authorization and enforcement of the maximum QoS that is authorized for a service data flow, for a QoS Flow or for the PDU Session."

TDoc S2-2305198:

- If the SMF selection management trigger is set, the AMF contacts the PCF when the UE requests a DNN within the list of candidates for replacement for the S-NSSAI indicated in the Access and mobility related policy information.
- If the SMF selection management trigger is set, the AMF contacts the PCF when the UE requests an unsupported DNN and the PCF indicated DNN replacement of unsupported DNNs in the Access and mobility related policy information.
- Service Area restriction change trigger and RFSP index change trigger trigger AMF to interact with PCF for changes in the Service Area restriction or RFSP index data received in AMF from UDM.

Example snippets:

- "If the SMF selection management trigger is set, then the AMF shall contact the PCF when the UE requested a DNN within the list of DNN candidates for replacement for the S-NSSAI indicated in the Access and mobility related policy information."
- "If the SMF selection management trigger is set, then the AMF shall contact the PCF when the AMF detects that the UE requested an unsupported DNN and the PCF indicated DNN replacement of unsupported DNNs in the Access and mobility related policy information."
- "The reporting includes that the trigger is met and the subscribed Service Area restriction or the subscribed RFSP index provided to AMF by UDM, as described in clause 6.1.2.1."

TDoc S2-2305268:

- SMF may need to send PDU Session Modification Command to inform UE about changes in QoS parameters that NG-RAN is currently fulfilling.
- SMF is responsible for updating QoS rules and QoS Flow level QoS parameters if needed for QoS Flow(s) associated with QoS rule(s) in UE.
- RRC Connection Reconfiguration may take place with UE modifying necessary (R)AN resources related to PDU Session.

Example snippets:

- "The SMF may need to send transparently through NG-RAN the PDU Session Modification Command to inform the UE about changes in the QoS parameters (i.e. 5QI, GFBR, MFBR) that the NG-RAN is currently fulfilling after the SMF receives QoS Notification Control..."
- "If the (R)AN rejects QFI(s), the SMF is responsible of updating the QoS rules and QoS Flow level QoS parameters if needed for the QoS Flow(s) associated with the QoS rule(s) in the UE accordingly, i.e. the SMF shall trigger a separate NAS PDU Session Modification procedure after step 11 to align the SM context of this PDU Session in UE."
- "For example, in the case of a NG-RAN, an RRC Connection Reconfiguration may take place with the UE modifying the necessary (R)AN resources related to the PDU Session or if only N1 SM container is received in step 4 from AMF, RAN transports only the N1 SM container to the UE."

TDoc S2-2305269:

- UE reporting Connection Capabilities from associated URSP rule trigger indicates to SMF to forward this information to PCF.
- PCF provides new PCC Rule with received Traffic Descriptor in SDF Template and Downlink Data Notification Control information set according to requested type(s) of notifications if PCRT is not set in SMF.
- If installed PCC rule exists for received Traffic Descriptor, PCF sets Downlink Data Notification Control information of that rule according to requested type(s) of notifications.

Example snippets:

- "The UE reporting Connection Capabilities from associated URSP rule trigger indicates to the SMF that when a UE includes Connection Capabilities in the PDU Session Establishment Request or PDU Modification Request, the SMF shall forward this information to the PCF..."
- "Otherwise, the PCF provides a new PCC Rule with the received Traffic Descriptor in the SDF Template, the Downlink Data Notification Control information set according to the requested type(s) of notifications and other PCC Rule information set to the same values as in the existing PCC rule that previously matched the traffic."
- "[2]), report the BAT offset and optionally the adjusted periodicity to the PCF for the PCC rule which is bound to the QoS Flow for which the notification from RAN was received."

TDoc S2-2304828:

- The H-SMF SM Context ID in the Input provides addressing information allocated by the H-SMF for service operations towards the H-SMF for this PDU Session.
- This service operation is invoked by the H-SMF towards the V-SMF for both UE initiated and HPLMN initiated PDU Session Modification and PDU Session Release cases.
- It can also be invoked by the H-SMF towards the V-SMF to release the 5GC and 5G-AN resources in handover scenarios where the UE is not notified.
- This service operation is invoked by the V-SMF towards the H-SMF in the case of UE or serving network requested PDU Session Modification.
- It is used to carry DN Request Container information between the DN-AAA Server and the UE.

TDoc S2-2304856:

- If SMF determines that the UEs are under the same GEO satellite, the SMF selects and inserts the UPF deployed on GEO satellite according to the DNAI as UL CL/BP and L-PSA.
- The SMF configures UL CL/BP with the following rule:
- Route the data traffic received from the UE and destined to IP address(es) of the target UE(s) to the L-PSA.
- Route other data traffic received from the UE to the PSA UPF of the UE's PDU Session.
- Selection of PSA UPF or UL CL/BP/local PSA on satellite is described in clause 6.3.3.
- N6 may be used for carrying traffic between L-PSA UPFs deployed on different satellites.

TDoc S2-2304921:

- QoS monitoring comprises measurements of QoS parameters for a QoS Flow.
- It can be enabled based on 3rd party application requests and/or operator policies configured in the PCF.
- The PCF may generate the authorized QoS Monitoring policy for a service data flow based on the QoS Monitoring request received from the AF.
- The SMF configures the UPF to perform QoS monitoring for the QoS Flow and to report the monitoring results.
- The QoS parameter which can be measured are parameters which describe the QoS experienced in the 5GS by the application.
- The PCF includes the authorized QoS Monitoring policy in the PCC rule and provides it to the SMF.

TDoc S2-2305373:

- SMF is locally configured with mapping relationship between DNAI and GEO Satellite ID.
- The SMF selects the PSA UPF or UL CL/BP/local PSA based on the DNAI corresponding to the GEO Satellite ID and other factors.
- The AMF may determine the GEO Satellite ID serving the UE and send it to the SMF based on configuration.
- The 5G System supports reporting the usage of satellite backhaul.

Example from TDoc S2-2304828:

- "This service operation is invoked by the H-SMF towards the V-SMF for both UE initiated and HPLMN initiated PDU Session Modification and PDU Session Release cases"

Example from TDoc S2-2304856:

- "Selection of PSA UPF or UL CL/BP/local PSA on satellite is described in clause 6.3.3."

Example from TDoc S2-2304921:

- "The QoS parameter which can be measured are parameters which describe the QoS experienced in the 5GS by the application."

Example from TDoc S2-2305373:

- "The AMF may determine the GEO Satellite ID serving the UE and send it to the SMF based on configuration."

3GPP-S2-156-e    Agenda Item 9.2.2 : Satellite access Phase 2 (5GSAT_Ph2)

Technical Differences:

1. O&M Provisioning:
- TDoc S2-2304407: Satellite coverage availability information may be provisioned to the AMF by O&M
- TDoc S2-2305089: Satellite coverage availability information may be provisioned to the AMF by O&M by AF.

Example from TDoc S2-2305089: "The O&M may provision satellite coverage availability information to the AMF by AF."

2. Meeting Location:
- TDoc S2-2304407: Elbonia, March 17 - 21, 2023
- TDoc S2-2305089: Electronic, April 17 - 21, 2023

3. Minor Formatting Differences:
- TDoc S2-2304407 uses asterisks (*) to indicate changes, while TDoc S2-2305089 uses dashes (-).

Example from TDoc S2-2304407: "*** First Change ***"
Example from TDoc S2-2305089: "* * * First change * * *"

4. No Other Technical Differences Found.

Example from TDoc S2-2304407: "The AMF may use satellite coverage availability information to support satellite access by UEs with discontinuous coverage operation. The satellite coverage availability information is not UE specific and can be applied by the AMF for any UE in the affected area. The satellite coverage availability information provisioned to the AMF describes when and where satellite coverage is expected to be available in an area. Satellite coverage availability information may be provisioned to the AMF by O&M."

Example from TDoc S2-2305089: "The AMF may use satellite coverage availability information to support satellite access by UEs with discontinuous coverage operation. The satellite coverage availability information is not UE specific and can be applied by the AMF for any UE in the affected area. The satellite coverage availability information provisioned to the AMF describes when and where satellite coverage is expected to be available in an area. Satellite coverage availability information may be provisioned to the AMF by O&M by AF."

1. TDoc S2-2305295: The MME sends a Notify Request to the HSS for mobility with non-3GPP accesses after receiving Modify Bearer Response message and checking subscription data for handover permission.
Example: "if Request Type does not indicate handover and an EPS bearer was established and the subscription data indicates that the user is allowed to perform handover to non-3GPP accesses, and if the MME selected a PDN GW that is different from the PDN GW identity which was indicated by the HSS in the PDN subscription context, the MME shall send a Notify Request including the APN and PDN GW identity to the HSS for mobility with non-3GPP accesses."

2. TDoc S2-2305295: The PDN GW indicates 3GPP PS Data Off UE Status to the charging system for offline and online charging during handover attach.
Example: "In the case of handover attach, and if the PDN GW detects that the 3GPP PS Data Off UE Status is active, the PDN GW shall indicate this status to the charging system for offline and online charging."

3. TDoc S2-2305298: The AMF updates Mobility Restrictions for the UE and provides the NG-RAN with updated Mobility Restrictions, considering subscription-based restrictions to simultaneous registration of network slices and NSSRG Information constraints.
Example: "[Conditional] If the Mobility Restrictions for the UE were updated and the Mobility Restrictions were not provided in the N2 message that delivers the UE Configuration Update Command, the AMF provides the NG-RAN with updated Mobility Restrictions unless the AMF releases the UE in this step (see below). [2] and, if the UE supports the subscription-based restrictions to simultaneous registration of network slices, also taking into account the NSSRG Information constraints as described in clause 5.15.12 of TS 23.501"

4. TDoc S2-2305382: The UE indicates its UE identity in the Registration Request message using native 5G-GUTI or SUCI, and the (R)AN forwards the message to the AMF based on the N2 connection of the UE during CM-CONNECTED state.
Example: "If the UE is registering with an SNPN, when the UE is performing an Initial Registration the UE shall indicate its UE identity in the Registration Request message as follows, listed in decreasing order of preference: i) a native 5G-GUTI assigned by the same SNPN to which the UE is attempting to register, if available; ii) a native 5G-GUTI assigned by an equivalent SNPN to the SNPN to which the UE is attempting to register along with the NID of the SNPN that assigned the 5G-GUTI, if available; iii) a native 5G-GUTI assigned by any other SNPN along with the NID of the SNPN that assigned the 5G-GUTI, if available; or iv) Otherwise, the UE shall include its SUCI in the Registration Request as defined in TS 33.501 [15]. If UE is in CM-CONNECTED state, the (R)AN can forward the Registration Request message to the AMF based on the N2 connection of the UE."

5. TDoc S2-2305383: The grid point approach can be used to indicate different locations over an area for an AMF or MME, and possible future locations of the UE can be used to define a larger area for which SCAI is provided.
Example: "To indicate different locations over an area (e.g. for an AMF or MME or for a UE whose future movement was unknown), a grid point approach can be used in which locations are indicated for a set of grid points in a rectangular or hexagonal array with equal spacing. In other cases, where a UE can move by longer distances, possible future locations of the UE (e.g. based on a maximum distance of travel estimate) can be used to define a larger area for which SCAI is provided."

[TDoc S2-2303996]:
- Identity TAU Tracking Area Update: This is a procedure used to update the location of a UE in the core network.
- TI Transaction Identifier: This is a unique identifier used for transactions between the UE and the network.
- TIN Temporary Identity used in Next update: This is a temporary identifier used during handover between base stations.
- UCMF UE radio Capability Management Function: This function is responsible for managing the capabilities of the UE.
- URRP-MME UE Reachability Request Parameter for MME: This parameter is used to request information about the reachability of the UE.
- UL TFT UpLink Traffic Flow Template: This is a set of rules used to manage the flow of data from the UE to the network.
- ULR-Flags Update Location Request Flags: These flags are used to control the behavior of the Update Location Request message.

[S6a]:
- Enables transfer of subscription and authentication data: This interface is used to authenticate and authorize user access to the network.
- Between MME and HSS: The MME and HSS are the two network elements that communicate over this interface.

[S1-U]:
- Reference point between E-UTRAN and Serving GW: This reference point is used for user plane tunneling and inter eNodeB path switching during handover.

[S4]:
- Provides related control and mobility support: This interface is used for mobility support and control between the GPRS Core and the Serving GW.
- Between GPRS Core and the 3GPP Anchor function of Serving GW: The GPRS Core and the Anchor function of the Serving GW are the two network elements that communicate over this interface.

[S9]:
- Provides transfer of QoS policy and charging control information: This interface is used to transfer information about QoS policies and charging between the Home PCRF and the Visited PCRF.
- Between Home PCRF and Visited PCRF: The Home PCRF and Visited PCRF are the two network elements that communicate over this interface.
- Supports local breakout function: This interface supports the local breakout function, which allows traffic to be routed directly to the internet from the visited network.

[S3]:
- Enables user and bearer information exchange: This interface is used for exchanging information about users and bearers.
- For inter 3GPP access network mobility: This interface is used for mobility between 3GPP access networks.

[S8]:
- Inter PLMN variant of S5: This interface is the inter-PLMN variant of the S5 interface, which is used for mobility support between the Serving GW and the Packet Data Network Gateway (PDN-GW).

[TDoc S2-2303997]:
- Um/Uu/LTE-Uu interfaces: These interfaces are used for connecting a UE to the 3GPP network.
- Satellite access interface for NB-IoT, WB-E-UTRAN and LTE-M: This interface allows UEs to connect to the network via satellite.
- Service capability exposure to SCS and AS: This refers to the exposure of network service capabilities to Service Capability Server (SCS) and Application Server (AS).
- User Plane communication is routed directly through the serving PLMN/VPLMN: In local breakout scenarios, user plane communication is routed directly through the serving network.

[S2-2305155]:
- Event Filter: This is a set of criteria used to filter events.
- External Application Identifier(s): This is the identifier(s) for external applications that are interested in receiving event notifications.
- Subscription Correlation ID: This is the identifier used to correlate event subscriptions with specific UEs.
- Expiry time: This is the time at which an event subscription expires.
- List of group member UE(s): This is a list of UEs that are members of a group-based event notification subscription.
- Operation indication: This indicates whether an event subscription is being cancelled or added.
- DNN: This is the Data Network Name, which is used to identify the data network to which the UE is connected.
- S-NSSAI: This is the Slice/Service Network Selection Assistance Information, which is used to select a specific network slice or service.
- Idle Status Indication request: This is a request for an indication of the UE's idle status.

[TDoc S2-2305300]:
- Maximum wait time: This refers to the maximum amount of time that UEs must wait before returning to coverage.
- IE(disaster return wait range information): This is an existing IE used for disaster return wait range information.
- SA2 requests CT1 to comment on whether an existing IE or a new IE is beneficial for maximum wait time.

3GPP-S2-156-e    Agenda Item 9.4.2 : Phase 2 for UAS, UAV and UAM (UAS_Ph2)

[TDoc S2-2304062]:
- Enhancements in the procedure for UE initiated PDU Session Modification and PDU Session Establishment for C2 Communication, specifically related to establishing a direct PC5 link for connectivity to UAV-C.
- The C2 Aviation Payload sent by the UAV includes an indication that the authorization is also for Direct C2 Communication.
- The use of PC5-based communications for BRID and DDAA for UAV with UICC is subjected to successful UUAA authentication/authorization of the UAV and authorization via A2XP.

[TDoc S2-2304065]:
- Configuration parameters for A2X communication may be pre-configured in the ME, configured in the UICC, preconfigured in the ME and configured in the UICC, provided/updated by the A2X Application Server via PCF and/or A2X1 reference point, or provided/updated by the PCF to the UE.
- The UE considers the configuration parameters in a specific priority order.
- Deconflicting policy is defined to indicate the communication mode (unicast or broadcast) for deconflicting.
- The use of PC5-based communications for BRID and DDAA for UAV with UICC is subjected to successful UUAA authentication/authorization of the UAV and authorization via A2XP.

[TDoc S2-2304066]:
- Defines an A2X Policy (A2XP) to provide configuration parameters to the UE for A2X communication over the PC5 reference point.
- Configuration parameters may be pre-configured in the ME, configured in the UICC, preconfigured in the ME and configured in the UICC, provided/updated by the A2X Application Server via PCF and/or A2X1 reference point, or provided/updated by the PCF to the UE.
- The UE considers the configuration parameters in a specific priority order.
- Deconflicting policy is defined to indicate the communication mode (unicast or broadcast) for deconflicting.
- The use of PC5-based communications for BRID and DDAA for UAV with UICC is subjected to successful UUAA authentication/authorization of the UAV and authorization via A2XP.

[TDoc S2-2304231]:
- A2X service type for direct C2 Communication may be preconfigured in the UAV.
- Source and Target User Info are set to the Application Layer ID of the UAV and UAV-C, respectively.
- Communications over PC5 between UAV UEs served by different PLMNs is possible in NR when the UAV UEs use the same carrier.
- The use of PC5-based communications for BRID and DDAA for UAV with UICC is subjected to successful UUAA authentication/authorization of the UAV and authorization via A2XP.

[TDoc S2-2304232]:
- Standardized 5QI values are specified for services that benefit from optimized signaling by using standardized QoS characteristics.
- Dynamically assigned 5QI values can be used for services for which standardized 5QI values are not defined.
- Communications over PC5 between UAV UEs served by different PLMNs and with subscriptions to different PLMNs is supported depending on RAN WG2 feedback.
- PC5 Relay communications are not supported in this Release.

[TDoc S2-2304242]:
- Authentication and authorization of a UAV with the USS during 5GS registration and PDU session establishment.
- Provides a reference model for UAV tracking, supporting three UAV tracking modes.
- Geofencing/geocaging mechanisms are an air traffic control functionality performed by the USS and are out of scope of this specification.

[TDoc S2-2304345]:
- Both UAV UEs that utilize Uu connectivity and that do not utilize Uu connectivity are supported.
- Subscription to A2X services is based on user's profile stored in the UDM containing the subscription information.
- The use of PC5-based communications for BRID and DDAA for UAV with UICC is subjected to successful UUAA authentication/authorization of the UAV and authorization via A2XP.

[TDoc S2-2304346]:
- Defines an A2X Policy (A2XP) to provide configuration parameters to the UE for A2X communication over the PC5 reference point.
- Configuration parameters may be pre-configured in the ME, configured in the UICC, preconfigured in the ME and configured in the UICC, provided/updated by the A2X Application Server via PCF and/or A2X1 reference point, or provided/updated by the PCF to the UE.
- The UE considers the configuration parameters in a specific priority order.
- Deconflicting policy is defined to indicate the communication mode (unicast or broadcast) for deconflicting.
- The use of PC5-based communications for BRID and DDAA for UAV with UICC is subjected to successful UUAA authentication/authorization of the UAV and authorization via A2XP.

[TDoc S2-2304348]:
- The AMF determines whether the UE is authorized to use A2X communication over PC5 reference point based on UE's PC5 Capability for A2X and the subscription data related to A2X service authorization information received from UDM.
- The PCF provides the PC5 QoS parameters to AMF, and the AMF stores them in the UE context.
- If the UE is authorized to use A2X communication over PC5 reference point, then the AMF includes the "A2X services authorized" indication and the PC5 QoS parameters in the NGAP message sent to NG-RAN.

- Amendment 3: If the UE indicates A2X capability in the Registration Request message and if the UE is authorized to use A2X service based on subscription data, the AMF selects the PCF which supports A2X Policy/Parameter provisioning.
- Registration procedures as defined in clause 4.2.2.2 of TS 23.502 are used for PCF based Service Authorization and Provisioning to 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 PCF may determine the A2X Policy/Parameter for specific PC5 RAT based on the received UE's PC5 capability for A2X.
- The AAM uses PC5 unicast link to provide each UAV present in the arena/area with local DAA policies as user traffic.
- For the applicable airspace of the area/arena the AAM defines individually adapted local collision avoidance rules for correspondingly located UAVs.
- Direct Communication over PC5 involves compliance with authorization and provisioning principles described in clause 4.2.1.2.2.
- If the UE attempts to establish a new PDU Session request is rejected by the network, then the UE shall perform the association of the application to a PDU Session or to Non-Seamless Offload or ProSe Layer-3 UE-to-Network Relay Offload.
- The PCF provides Policy Control Request Triggers to the AMF indicating a specific UE in the Policy Association establishment and modification procedures defined in the TS 23.502.
- For LTE PC5 in EPS, the network scheduled operation mode defined in TS 23.285 is not supported and the A2X uses only the UE autonomous resources selection mode.
- A2X supports Broadcast communication mode for BRID and DDAA.
- PC5 Relay communications are not supported in this release.
- Groupcast mode for NR based PC5 is not supported.

Examples from the original TDoc:

- "If the UE indicates A2X capability in the Registration Request message and if the UE is authorized to use A2X service based on subscription data, the AMF selects the PCF which supports A2X Policy/Parameter provisioning."
- "The AAM uses PC5 unicast link to provide each UAV present in the arena/area with local DAA policies as user traffic."
- "If the UE attempts to establish a new PDU Session request is rejected by the network, then the UE shall perform the association of the application to a PDU Session or to Non-Seamless Offload or ProSe Layer-3 UE-to-Network Relay Offload."
- "For LTE PC5 in EPS, the network scheduled operation mode defined in TS 23.285 is not supported and the A2X uses only the UE autonomous resources selection mode."
- "A2X supports Broadcast communication mode for BRID and DDAA."

TDoc S2-2304233:

- Authentication and authorization of a UAV with the USS during 5GS registration (optional).
- A UAV that is configured for UAS services may support A2X Capability and PC5 Capability for A2X to be reported to 5GC over N1 reference point.
- A2X Policy Provisioning Request in UE Policy Container for UE triggered A2X Policy provisioning can be indicated.
- A2X parameters can be received from 5GC over N1 reference point.
- AF functionality is included, and it may support A2X service parameters provisioning for A2X communications over PC5 reference point.

(TDoc reference [11] supports the inclusion of AF functionality and A2X service parameters provisioning.)

TDoc S2-2304349:

- Range(s) of (UE) IPv4 addresses or Range(s) of (UE) IPv6 prefixes, Range(s) of SUPIs or Range(s) of GPSIs, or a BSF Group ID (in the case of BSF) are listed for support.
- The SCP Domain the NF belongs to is included.
- DCCF Serving Area information, NF types of the data sources, and NF Set IDs of the data sources (if available) are listed (in the case of DCCF).
- The Supported DNAI list is included (in the case of SMF).
- For SNPN, capability to support SNPN Onboarding in the case of AMF and capability to support User Plane Remote Provisioning in the case of SMF are listed.
- IP address range and DNAI for UPF are included.
- Additional V2X related NF profile parameters are defined in TS 23.287.
- Event ID(s) supported by AFs are included in the case of NEF.

(TDoc reference [1] supports the inclusion of Event ID(s) supported by AFs.)

TDoc S2-2304934:

- The Nudm_SDM_Notification service operation may contain the "A2X 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 new A2X subscription data.
- Delivery of PC5 QoS parameters to NG-RAN is supported.
- The UE Policy Association Establishment procedure and UE Policy Association Modification procedure are defined in TS 23.502.
- 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 using the UE Configuration Update procedure for transparent UE Policy delivery procedure defined in clause 4.2.4.3 of TS 23.502.
- When the AMF updates UE context stored at NG-RAN, the UE context contains the A2X subscription data.

(TDoc reference [3] supports the inclusion of the Nudm_SDM_Notification service operation and UE Context updates.)

TDoc S2-2305123:

- During the procedure of MBS session creation, USS/UTM provisions the service area(s) to MB-SMF via NEF.
- MBS service area for remote ID broadcasting is determined by USS/UTM based on the UAV UE(s) location.

(TDoc reference [1] supports the inclusion of MBS service area determination.)

Overall, these TDocs describe technical differences in terms of functionalities supported for UAVs and their integration with the 5G network, including authentication and authorization, A2X capabilities, AF functionality, QoS parameters delivery, and MBS service area determination. These differences are supported by references to other technical documents within the 3GPP framework.

[TDoc S2-2304063]:
- Enhancements to procedure for UE initiated PDU Session Establishment for C2 Communication
- UAV includes indication for Direct C2 Communication authorization in C2 Aviation Payload
- Enhancements to procedure for UE initiated PDU Session Modification for C2 Communication
- UAV includes indication for Direct C2 Communication authorization in C2 Aviation Payload
- Use of UUAA-SM for DC2 authorization requires establishment and maintenance of unused PDU session for C2

[TDoc S2-2304064]:
- Enhancements to procedure for UE initiated PDU Session Modification for C2 Communication
- UAV includes indication for Direct C2 Communication authorization in C2 Aviation Payload
- Enhancements to procedure for UE initiated PDU Session Establishment for C2 Communication
- UAV includes indication for Direct C2 Communication authorization in C2 Aviation Payload
- Change from Rel-15 to Rel-16
- Reason for change is editorial modification

[TDoc S2-2304347]:
- Use of C2 Authorization request during UUAA-SM procedure in 5GS to request C2 authorization for Direct C2 Communication
- UAV includes indication for Direct C2 Communication authorization in C2 Aviation Payload
- Use of UE requested PDN connectivity for C2 authorization in EPS to request C2 authorization for Direct C2 Communication

[TDoc S2-2304566]:
- UAV includes Direct C2 pairing information in C2 Aviation Payload
- USS may include Direct C2 pairing information in C2 Authorization Payload
- Enhancements to procedure for UE initiated PDU Session Establishment for C2 Communication
- UAV includes indication for Direct C2 Communication authorization in C2 Aviation Payload

Example snippet from TDoc S2-2304063 to support difference highlighting: "When the UAV needs to establish a direct PC5 link required for connectivity to UAV-C (i.e. Direct C2 Communication), the C2 Aviation Payload sent by the UAV includes an indication that the authorization is also for Direct C2 Communication."

Example snippet from TDoc S2-2304347 to support difference highlighting: "When the UAV needs to establish a direct PC5 link required for connectivity to UAV-C (i.e. Direct C2 Communication), the C2 Aviation Payload sent by the UAV includes an indication that the authorization is also for Direct C2 Communication."

Example snippet from TDoc S2-2304566 to support difference highlighting: "If the UAV supports Direct C2 Communication and intends to request C2 authorization for Direct C2 Communication to the USS, it shall include an indication for Direct C2 Communication authorization in the authorization request."

3GPP-S2-156-e    Agenda Item 9.13.2 : RedCap Phase 2 (NR_RedCAP_Ph2)

- TDoc S2-2303999: Specifies that the Namf_MT EnableUEReachability request should allow the SMF to provide paging policy information/parameters including the PPI, ARP, and 5QI of the QoS flow of the PDU session, and the AMF would include the same towards the NG-RAN to enable similar NG-RAN paging as when NG-RAN pages the UE upon receiving DL packets for a UE in RRC_INACTIVE state.
- Observation 5: In the presence of DL data corresponding to a mix of SDT and non-SDT radio bearers and assuming that the subsequent Data Notifications are suppressed, the RAN handling will be suboptimal in case the single Data Notification was triggered by SDT traffic.
- Observation 4: While SDT is completely transparent to CN, RAN would benefit from obtaining assistance from the CN to identify whether the underlying RB is of SDT or non-SDT type.
- TDoc S2-2304155: The AMF responds to NG-RAN and informs other NFs (e.g. SMF and UPF) involved in downlink data or signalling handling and triggers the data buffering as specified in clause 4.8.1.1a of TS 23.502 when the UE enters RRC_CONNECTED state if the NG-RAN had sent the indication for the CN to handle MT communication.
- TDoc S2-2304184: When UE is in CM-CONNECTED with RRC_INACTIVE state, if RAN has received Location Reporting Control message from AMF with the Reporting Type indicating single stand-alone report or continuously reporting whenever the UE changes the cell, the RAN shall perform location reporting as specified in clause 4.10 of TS 23.502 [52] for E-UTRA connected to 5GC, that allows the RAN to calculate the UE's RAN paging occasions.
- TDoc S2-2304185: When UE is in CM-CONNECTED with RRC_INACTIVE state, if RAN has received Location Reporting Control message from AMF with the Reporting Type indicating single stand-alone report or continuously reporting whenever the UE changes the cell, the RAN shall perform location reporting as specified in clause 4.10 of TS 23.502 [52] for E-UTRA connected to 5GC, that allows the RAN to calculate the UE's RAN paging occasions. It also highlights the following differences:
- An indication that Paging Cause Indication for Voice Service is supported.
- AMF PEIPS Assistance Information (see clause 5.4.12.2) for paging a UE in CM-CONNECTED with RRC_INACTIVE state over NR as defined in TS 38.300.
- 3GPP TSG- Meeting # April 17-21, 2023, Electronic (revision of S2-23xxxxx) FIRST CHANGE 5.31.7.2.4 Paging for extended DRX for RRC_INACTIVE in NR connected to 5GC: Specifies that the NG-RAN may request the CN to handle MT communication for the UE configured with eDRX for RRC_INACTIVE state by means of the Connection Inactive procedure with CN based MT communication handling Procedure. This allows the CN to apply high latency communication functions as specified in clause 5.31.8.
- TDoc S2-2303999: Highlights the difference in paging policy information/parameters for SMF and NG-RAN, and the need for AMF to include the same towards NG-RAN.
- Observation 5: Highlights the suboptimal RAN handling in the presence of DL data corresponding to a mix of SDT and non-SDT radio bearers, assuming that the subsequent Data Notifications are suppressed.
- Observation 4: Highlights the need for RAN to obtain assistance from CN to identify whether the underlying RB is of SDT or non-SDT type.
- TDoc S2-2304155: Highlights the AMF's response to NG-RAN and informing other NFs involved in downlink data or signalling handling, and the data buffering trigger when UE enters RRC_CONNECTED state.
- TDoc S2-2304184: Highlights the location reporting as per clause 4.10 of TS 23.502 [52] for E-UTRA connected to 5GC, and the impact of extended idle mode DRX cycle length on reachability requirements of applications running on UE.
- TDoc S2-2304185: Highlights the location reporting as per clause 4.10 of TS 23.502 [52] for E-UTRA connected to 5GC, and the inclusion of Paging Cause Indication for Voice Service and AMF PEIPS Assistance Information for paging a UE in CM-CONNECTED with RRC_INACTIVE state over NR as defined in TS 38.300.
- 3GPP TSG- Meeting # April 17-21, 2023, Electronic (revision of S2-23xxxxx) FIRST CHANGE 5.31.7.2.4 Paging for extended DRX for RRC_INACTIVE in NR connected to 5GC: Highlights the NG-RAN's request to CN to handle MT communication for UE configured with eDRX for RRC_INACTIVE state, and the high latency communication functions as specified in clause 5.31.8.

Technical Differences:

1. eDRX cycle length value:
In TDoc S2-2304364 and TDoc S2-2304436, the UE and network negotiate the use of extended idle mode DRX for reducing power consumption, while being available for mobile terminating data and/or network originated procedures within a certain delay dependent on the DRX cycle value. The AMF assigns a Paging Time Window length to be used, and provides this value to the UE during Registration Update procedures together with the extended idle mode DRX cycle length in the extended DRX parameter information element. However, TDoc S2-2305138 states that when a UE is in CM-CONNECTED with RRC_INACTIVE state, if RAN has received Location Reporting Control message from AMF with the Reporting Type indicating single stand-alone report or continuously reporting whenever the UE changes the cell, the RAN shall perform location.

Example: TDoc S2-2304364 - "The extended DRX parameters information element includes the extended idle mode DRX cycle length."

2. Handling of Mobile Terminated Communication:
According to TDoc S2-2304364, based on implementation, the NG-RAN may send an indication to the AMF if the AMF supports the indication for the CN to handle mobile terminated (MT) communication and the CN can then handle mobile terminated (MT) communication as specified in clause 5.31.7.2.4 and apply high latency communication as specified in clause 5.31.8. However, TDoc S2-2304437 states that when downlink data is received and the SMF/UPF is requested to perform buffering as specified in clause 4.8.1.1a, the UPF/SMF checks with AMF for the possibility of data delivery, similar to step 2 of clause 4.24.2.

Example: TDoc S2-2304364 - "When the UE has PDU Session associated with emergency services, the UE and AMF follow regular discontinuous reception as defined in clause 5.4.5 and shall not use the extended idle mode DRX."

3. UE Radio Capability Update:
TDoc S2-2305138 states that when a UE is in CM-CONNECTED with RRC_INACTIVE state, and a trigger to change the UE's NG-RAN or EUTRAN UE Radio Capability information happens, the UE shall move to CM-IDLE state and initiate the procedure for updating UE Radio Capability defined in clause 5.4.4.1.

Example: TDoc S2-2305138 - "When a UE is in CM-CONNECTED with RRC_INACTIVE state, and a trigger to change the UE's NG-RAN or EUTRAN UE Radio Capability information happens, the UE shall move to CM-IDLE state and initiate the procedure for updating UE Radio Capability defined in clause 5.4.4.1."

Overall, the technical differences among the TDocs can be seen in the way the network and UE negotiate over non-access stratum signalling and the handling of mobile terminated communication. Additionally, TDoc S2-2305138 provides specific requirements for a UE operating in dual-registration mode.

Technical Differences among TDocs:

1. TDoc S2-2303947: This document is a request from RAN2 to SA2, CT1, and RAN3 to take their information into account and provide feedback. It discusses the plans of RAN2 to allow configuring extended DRX (eDRX) beyond 10.24 sec in RRC_INACTIVE together with SDT features. The document also mentions the dates of the next TSG RAN WG2 meetings.

Example snippet: "RAN2 would like to inform that in Rel-18, RAN2 intends to allow configuring extended DRX (eDRX) beyond 10.24 sec in RRC_INACTIVE together with SDT features (including MO and/or MT versions of SDT)."

2. TDoc S2-2303954: This document is a reply LS from RAN3 clarifying the scope of the first answer from previous reply RAN3 LS regarding the triggering criteria for gNB sending a CN based MT communication handling request to CN for eDRX cycle lengths larger than 10.24s. The document also thanks SA2 for their LS and agreed CRs on update of CN based MT handling.

Example snippet: "RAN3 would like to clarify that the scope of the first answer from previous reply RAN3 LS (S2-2300055/R3-226776), i.e., the triggering criteria for gNB sending a CN based MT communication handling request to CN, is for eDRX cycle lengths larger than 10.24s."

3. TDoc S2-2304188: This document is a draft reply LS from SA2 to CT4 and RAN3 regarding paging policy information for network triggered connection resume. The document thanks CT4 for informing the enhancement related to paging policy differentiation and requests CT4 and RAN3 to take the information into consideration.

Example snippet: "SA2 thanks CT4 for informing the enhancement related to paging policy differentiation. ACTION: SA2 kindly asks CT4 and RAN3 to take above information into consideration."

4. TDoc S2-2304277: This document is a reply LS from SA2 to CT4 regarding paging policy information for network triggered connection resume INACTIVE. The document thanks CT4 for their LS on Paging Policy Information for Network Triggered Connection Resume and brings to their attention that the N2 message sent by the AMF requesting connection resume includes the QFI, PPI, and ARP of the QoS Flow that triggered the connection resume.

Example snippet: "SA2 would like to bring to the attention of CT4 that the N2 message sent by the AMF requesting connection resume (step 2 in 23.502 Figure 4.8.2.2b-1) includes the QFI, PPI and ARP of the QoS Flow that triggered the connection resume."

Overall, these TDocs differ in their content and purpose. TDoc S2-2303947 is a request from RAN2, while TDoc S2-2303954 is a reply LS from RAN3 clarifying their previous LS. TDoc S2-2304188 and TDoc S2-2304277 are both reply LS from SA2 but differ in their specific details and the information they convey.

- TDoc S2-2304000 involves the SMF/UPF checking with the AMF for the possibility of data delivery when downlink data is received and buffering is requested, with the AMF determining UE reachability based on the stored eDRX cycle value for RRC_INACTIVE state provided by NG-RAN in clause 4.8.1.1a.
- TDoc S2-2304186 also involves the SMF/UPF checking with the AMF for the possibility of data delivery when downlink data is received and buffering is requested, with the AMF determining UE reachability based on the stored eDRX cycle value for RRC_INACTIVE state provided by NG-RAN in clause 4.8.1.1a.
- The main difference between the two TDocs is that TDoc S2-2304186 includes additional steps involving NG-RAN performing RAN paging towards the UE and initiating the UE triggered Connection Resume procedure, with the NG-RAN notifying CN as specified in clause 4.8.2.2 including the N2 Notification in step 3b.
- TDoc S2-2304000 only involves the SMF sending an Nsmf_PDUSession_UpdateSMContext response in cases where the UE context associated with the UE attempting to resume its connection is not locally available at the accessed NG-RAN.
- TDoc S2-2304186 has additional steps involving the NG-RAN performing RAN paging towards the UE based on the N2 message from the AMF to trigger the UE triggered Connection Resume procedure in clause 4.8.2.2, and the AMF accepting the request and responding to the consumer NF immediately if the UE is in CM-CONNECTED state.

Example snippets from TDoc S2-2304000:

- "When downlink data is received and the SMF/UPF is requested to perform buffering as specified in clause 4.8.1.1a, the UPF/SMF checks with AMF for the possibility of data delivery, similar to step 2 of clause 4.24.2 with the following differences..."
- "The AMF determines if the UE is reachable based on the stored eDRX cycle value for RRC_INACTIVE state provided by NG-RAN in clause 4.8.1.1a."
- "UE Context Retrieval is performed when the UE Context associated with the UE attempting to resume its connection is not locally available at the accessed NG-RAN."
- "The SMF sends the Nsmf_PDUSession_UpdateSMContext response."

Example snippets from TDoc S2-2304186:

- "When downlink data is received and the SMF/UPF is requested to perform buffering as specified in clause 4.8.1.1a, the UPF/SMF checks with AMF for the possibility of data delivery, similar to step 2 of clause 4.24.2 with the following differences..."
- "The AMF determines if the UE is reachable based on the stored eDRX cycle value for RRC_INACTIVE state provided by NG-RAN in clause 4.8.1.1a."
- "NG-RAN performs RAN paging towards the UE."
- "When the UE receives RAN paging, it initiates the UE triggered Connection Resume procedure and NG-RAN notifies CN as specified in clause 4.8.2.2 including the N2 Notification in step 3b."
- "During the procedure, the NG-RAN (i.e. gNB) performs RAN paging towards the UE based on the N2 message from the AMF in order to trigger the UE triggered Connection Resume procedure in clause 4.8.2.2."
- "The AMF accepts the request and respond the consumer NF immediately if UE is in CM-CONNECTED state."

3GPP-S2-156-e    Agenda Item 9.14.2 : Evolution of IMS multimedia telephony service (NG_RTC)

- TDoc S2-2304986: The DCSF handles event reports and manages data channel resources, and supports HTTP web server functionality for downloading data channel applications from the Data Channel Application Repository.
- TDoc S2-2304987: Media Stream Descriptor resource information includes Media ID, Local Mb Specification, Additional media resource description, and Additional Media Specification with Media Resource Description.
- TDoc S2-2304988: Principles for IMS Data Channel establishment include the UE initiating a request and the IMS AS discarding Data Channel requests from non-subscribed UEs.
- TDoc S2-2305060: The Nimsas_MediaControl_MediaInstruction service operation provides instructions for controlling media flows and includes a complete DCMF media specification for terminating or originating media flows.
- TDoc S2-2304986 highlights the functionality of the DCSF in managing resources and downloading applications from the repository.
- TDoc S2-2304987 outlines the different components of Media Stream Descriptor resource information.
- TDoc S2-2304988 details the principles for the establishment of IMS Data Channels.
- TDoc S2-2305060 discusses the Nimsas_MediaControl_MediaInstruction service operation and its role in controlling media flows.

TDoc S2-2304008:

- The IMS Data Channel shall be a service profile.
- No example snippets provided.

TDoc S2-2304014:

- No changes made.
- No example snippets provided.

TDoc S2-2304969:

- AC.7 Data Channel Procedures is the first change.
- No example snippets provided.

TDoc S2-2304971:

- Subscribers entitled to use IMS Data Channel shall be allocated in HSS.
- No example snippets provided.

Overall, the technical differences among these TDocs are not clearly stated, and there are no specific example snippets provided to highlight the changes. However, some of the TDocs mention changes related to the IMS Data Channel service profile, third-party registration in the IMS AS, and data channel procedures.

• The first TDoc (S2-2303966) is a response to LS S1-230045/S2-2301827 on PS Data Off for IMS Data Channel Service from SA2, while the second TDoc (S2-2304944) is a revision of S2-230xxxx.

• TDoc S2-2303966 is related to Release 19 Work Item: IMSDCDataOff, while TDoc S2-2304944 does not mention any specific work item.

• SA1 agreed to a Release 19 CR to TS 22.011 to define IMS Data Channel as part of the 3GPP PS Data Off Exempt Services in TDoc S2-2303966.

• TDoc S2-2303966 mentions SA WG2 Meeting #S2-156E, while TDoc S2-2304944 mentions 3GPP SA WG2 Meeting #156E.

• TDoc S2-2303966 asks SA2 to take the provided information into account, while TDoc S2-2304944 does not mention any specific actions.

Example snippets from TDoc S2-2303966:

- "SA1 agreed the attached Release 19 CR to TS 22.011 to define IMS Data Channel as part of the 3GPP PS Data Off Exempt Services."
- "SA1 would like to provide the following information: SA1 agreed the attached Release 19 CR to TS 22.011 to define IMS Data Channel as part of the 3GPP PS Data Off Exempt Services."
- "SA1 asks SA2 to take the above information into account."

Example snippets from TDoc S2-2304944:

- "3GPP SA WG2 Meeting #156E S2-2304944 April 17 - 21, 2023, Elbonia (revision of S2-230xxxx)"
- "FIRST CHANGE"
- "END OF CHANGES"

3GPP-S2-156-e    Agenda Item 9.15.2 : Access Traffic Steering, Switching and Splitting support in the 5GS; Phase 3 (ATSSS_Ph3)

-TDoc S2-2304079: The UE may duplicate traffic based on Redundant steering mode policies and UE implementation when it receives a PMF-Resume Duplication Request message from UPF. ATSSS-LL functionality with Active-Standby Steering Mode is mandatory in UE for an MA PDU Session of type IP to support non-MPTCP traffic when UE supports MPTCP functionality. When UPF sends PMF-Suspend Duplication Request message to UE, UE shall stop duplicating the type of traffic. ATSSS-LL functionality is mandatory in UE for an MA PDU Session of type IP when UE does not support MPTCP functionality. If the UPF does not provide the type of traffic in PMF-Suspend Duplication Request message, traffic duplication is suspended for all traffic.

-TDoc S2-2304080: UE receives MPTCP proxy information and one IP address/prefix for MA PDU session and two additional IP addresses/prefixes, called "link-specific multipath" addresses when UE supports MPTCP functionality with any steering mode and ATSSS-LL functionality with Active-Standby steering mode or any steering mode and network accepts to activate these functionalities.

-TDoc S2-2304081: The AMF forwards "Non-3GPP path switching while using old AN resources" indication to SMF if it supports maintaining two N2 connections for non-3GPP access during Registration procedure in case of MA PDU Session. AMF delays the release of old N2 connection if UE provides "Non-3GPP path switching while using old AN resources" indication during Registration Request. The UE can use UP connection(s) via old non-3GPP access during the Registration procedure when it provides "Non-3GPP path switching while using old AN resources" indication in Registration Request.

-TDoc S2-2304082: No corresponding information from the application or corresponding information from the application does not match any of the values in Traffic descriptor component determine a URSP rule is determined not to be applicable. A lower priority Route Selection Descriptor without a DNN must be provided to UEs. Route Selection Descriptor indicates that the traffic of matching application should be routed via a PDU Session supporting the included PDU Session Type. Access Type Preference indicates the Access Type on which the PDU Session should be established. URSP rule is determined to be applicable when every component in the Traffic descriptor matches the corresponding information from the application. It includes one or more DNN(s).

-TDoc S2-2304106: UE receives ATSSS rules from SMF to indicate uplink traffic routing across 3GPP access and non-3GPP access. ATSSS-LL functionality with any steering mode (as specified in clause 5.32.6.1) is supported by UE and network accepts to activate this functionality. When dynamic PCC is

Suspended Traffic Duplication:
- The UPF can suspend traffic duplication for a UE by sending a PMF-Suspend Duplication Request message to the UE.
- The UPF may indicate in PMF-Suspend Duplication Request message the type of traffic (i.e. GBR or non-GBR) for which traffic duplication is being suspended.
- If the UPF does not provide the type of traffic in the PMF-Suspend Duplication Request message, traffic duplication is suspended for all traffic for which traffic duplication is being performed.
- Once the UE receives PMF-Suspend Duplication Request message from the UPF, the UE shall stop duplicating the type of traffic for which traffic duplication is suspended.
- Once the UE receives PMF-Resume Duplication Request message from the UPF, the UE may again duplicate the type of traffic for which traffic duplication is resumed based on the provided Redundant steering mode policies and UE implementation.

Multi-Access PDU Sessions:
- A Multi-Access PDU (MA PDU) Session is managed by using the session management functionality specified in clause 5.6, with some additions and modifications.
- When the UE wants to request a new MA PDU Session and is registered to the same PLMN over 3GPP and non-3GPP accesses, then the UE shall send a PDU Session Establishment Request over any of the two accesses.
- If the UE indicates support for the ATSSS-LL functionality with any steering mode and the network accepts to activate this functionality, then the network may provide to UE Measurement Assistance Information and shall provide to UE one or more ATSSS rules.
- The UE can request activation of single access PDU Session(s) over the target non-3GPP access while performing Mobility Registration Update procedure according to the existing procedure.

MPQUIC Functionality:
- The MPQUIC functionality in the UE initiates the establishment of one or more multipath QUIC connections, after the establishment of the MA PDU Session.
- For each uplink UDP flow, the MPQUIC functionality selects a QoS flow, a steering mode, and a transport mode based on the QoS rules and ATSSS rules.
- The MPQUIC functionality communicates with the MPQUIC Proxy functionality in the UPF using the user plane of the 3GPP access, or the non-3GPP access, or both.
- The UE and the MPQUIC Proxy functionality in the UPF use the "MPQUIC link-specific multipath" addresses/prefixes for transmitting UDP flows over non-3GPP access and over 3GPP access.
- After the MA PDU Session is established, the UE determines the number of multipath QUIC connections to be established with the UPF.
- The supported transport modes are defined below.

Output Information for PDU Session:
- The Output includes PDU Session ID, S-NSSAI, Cause, PCO, UE IP address, IPv6 Prefix allocated to the PDU Session, information needed by V-SMF in the case of EPS interworking, such as the PDN Connection Type, EPS bearer context(s), linked EBI, Reflective QoS Timer, Always-on PDU Session Granted.
- It also includes information provided by H-SMF related to charging in home routed scenario, MA PDU request indication, MA PDU Network-Upgrade Allowed indication, Indication on whether the UE is registered in both accesses, QoS constraints from the VPLMN, Satellite backhaul category, Notification of the SM Policy Association Establishment and Termination, PCF binding information, Disaster Roaming service indication, HR-SBO request indication, VPLMN EASDF address, and ECS Address Configuration Information associated with PLMN ID of visited network.
- The SMF SM Context ID in the Input provides addressing information allocated by the SMF (to be used for service operations towards the SMF for this PDU Session).
- APN is not mentioned in this TDoc.

Examples from the original TDoc to support the differences:
- NOTE 2: If the UPF does not provide the type of traffic (GBR or non-GBR) in the PMF-Suspend Duplication Request message, traffic duplication is suspended for all traffic for which traffic duplication is being performed. [TDoc S2-2304924]
- If the UE is registered to the same PLMN over 3GPP and non-3GPP accesses, then the UE shall send a PDU Session Establishment Request over any of the two accesses. [TDoc S2-2305017]
- The MPQUIC functionality in the UE communicates with the MPQUIC Proxy functionality in the UPF (see Figure 4.2.10-1) using the user plane of the 3GPP access, or the non-3GPP access, or both. [TDoc S2-2305019]
- Output, Optional: PDU Session ID, S-NSSAI, Cause, PCO, UE IP address, IPv6 Prefix allocated to the PDU Session, information needed by V-SMF in the case of EPS interworking such as the PDN Connection Type, EPS bearer context(s), linked EBI, Reflective QoS Timer, Always-on PDU Session Granted, information provided by H-SMF related to charging in home routed scenario [TDoc S2-2305270]

Technical Differences among TDocs:

1. TDoc S2-2304558: Proposal 2
- Provides additional information in the PMF-Suspend Duplication Request message to indicate the access leg to use for uplink transmissions while duplication is suspended.
- UPF may send a PMF-Suspend Duplication Request message to the UE indicating to suspend duplication for a certain type of traffic or all traffic.
- UE and UPF may duplicate traffic over the 3GPP access and non-3GPP access based on ATSSS rules, N4 rules, and UE/UP implementation.
- The reasons for UPF to suspend traffic duplication are implementation specific.

Example: "To help resolve this congestion, the UPF may send a PMF-Suspend Duplication Request message to the UE indicating: suspend duplication for a certain type of traffic (GBR or non-GBR), or suspend duplication for all traffic."

2. TDoc S2-2304910:
- Redundant Steering Mode: UE and UPF shall duplicate traffic of the SDF on both accesses when the measured Packet Loss Rate exceeds the provided threshold value on both accesses.
- A Steering Mode Indicator allows UE to adjust traffic steering based on its own decisions.
- SMF decides to which access network to provide the QoS profile for the GBR QoS flow based on its local policy.

Example: "If the PCC rule allows a GBR QoS Flow in both accesses, the SMF decides to which access network to provide the QoS profile for the GBR QoS Flow based on its local policy (e.g. the access where the traffic is ongoing according to the Multi Access Routing rules)."

3. TDoc S2-2304923:
- The PCC rule enables policy control and proper charging for a service data flow.
- Bind to QoS Flow associated with the default QoS rule and apply PCC rule parameters Indication has to be used when the 5QI priority level has to be changed.
- PCF may provide one or more threshold values together with the priority of the accesses for the Priority-based steering mode.
- Operator defines the PCC rules.

Example: "The Bind to QoS Flow associated with the default QoS rule and apply PCC rule parameters Indication has to be used whenever the PDU Session related information Authorized default 5QI/ARP (as described in clause 6.3.1) cannot be directly used as the QoS parameters of the QoS Flow associated with the default QoS rule, for example when a GBR 5QI is used or the 5QI priority level has to be changed."

4. TDoc S2-2305021:
- Same as TDoc S2-2304923.

Example: "The Bind to QoS Flow associated with the default QoS rule and apply PCC rule parameters Indication has to be used whenever the PDU Session related information Authorized default 5QI/ARP (as described in clause 6.3.1) cannot be directly used as the QoS parameters of the QoS Flow associated with the default QoS rule, for example when a GBR 5QI is used or the 5QI priority level has to be changed."

• TDoc S2-2303914 proposes to remove the editor's note in TR 23.700-53 clause 5.1.1 that makes Ethernet traffic support optional and instead make it mandatory.
Example: "to remove the editor’s note in TR 23.700-53 clause 5.1.1 which quotes: “Whether support of steering, switching and splitting of Ethernet traffic flows is required is FFS” and rather include Ethernet traffic support as mandatory"

• TDoc S2-2303914 proposes to ensure that the recommended solution supports non-TCP traffic splitting, including Ethernet traffic splitting and potentially encrypted traffic splitting for a local network behind the 5G-RG.
Example: "to ensure that the recommended solution supports non-TCP traffic splitting, in particular Ethernet traffic splitting, and potentially encrypted traffic splitting for a local network behind the 5G-RG"

• TDoc S2-2304222 specifies that ATSSS-LL functionality with Active-Standby Steering Mode is mandatory in the UE for an MA PDU Session of type IP to support non-MPTCP traffic. When the UE does not support MPTCP functionality, the ATSSS-LL functionality is also mandatory in the UE for an MA PDU Session of type IP, but it is mandatory for an MA PDU Session of type Ethernet.
Example: "When the UE supports the MPTCP functionality, the ATSSS-LL functionality with Active-Standby Steering Mode is mandatory in the UE for an MA PDU Session of type IP to support non-MPTCP traffic. [...] The ATSSS-LL functionality is mandatory in the UE for MA PDU Session of type Ethernet."

• TDoc S2-2304222 states that the network must support the ATSSS-LL functionality as defined for the UE, and that the UPF enables ATSSS-LL functionality for an MA PDU Session based on ATSSS-LL functionality indication received in the Multi-Access Rules (MAR). The UE can enable ATSSS-LL functionality by providing an "ATSSS-LL capability" during the PDU Session Establishment procedure. The ATSSS-LL functionality in the UE does not apply a specific protocol and supports Redundant Steering Mode.
Example: "The network shall also support the ATSSS-LL functionality as defined for the UE. [...] The ATSSS-LL functionality in the UPF is enabled for a MA PDU Session by ATSSS-LL functionality indication received in the Multi-Access Rules (MAR). The ATSSS-LL functionality may be enabled in the UE when the UE provides an "ATSSS-LL capability" during the PDU Session Establishment procedure. The ATSSS-LL functionality in the UE does not apply a specific protocol. The ATSSS-LL functionality Redundant Steering Mode."

3GPP-S2-156-e    Agenda Item 9.16.2 : UPF enhancement for Exposure And SBA (UPEAS)

TDoc S2-2304692:

- Required outputs for subscription include Subscription Correlation ID and Expiry time (if applicable)
- Optional inputs for subscription include DNN, S-NSSAI, geographical area, and AF identifier
- Required inputs for DNAI mapping subscription include EAS address information
- One-time reporting can be done with maximum number of reports=1 and Immediate reporting flag set

TDoc S2-2304834:

- NF ID parameter is mandatory for Nupf_EventExposure_Subscribe and must be in the same format as NF instance ID
- Only NWDAF and SMF can consume Nupf_EventExposure_Subscribe service, external AFs cannot consume it
- If the consumer of subscription service is a 5GC NF, NF ID is mandatory in the subscription request

TDoc S2-2304967:

- NF ID parameter for Nupf_EventExposure_Subscribe is intended to take the same format as NF instance ID
- Only NWDAF and SMF can consume Nupf_EventExposure_Subscribe service, external AFs cannot consume it
- No specific handling of Nupf_EventExposure_Subscribe service operation requires NF ID parameter to always be present

TDoc S2-2305193:

- Request for UPF address includes UE (public) IP address and Port Number, and optionally IP domain, DNN, and S-NSSAI
- Request for UPF address is made using Nnrf_NFDiscovery service operation and includes UE address and AF Identifier, with optional Port Number, MTC Provider Information, Application Port ID, and IP domain
- NRF responds with UPF address of the UPF implementing NAT functionality for the UE (public) IP address
- Combination of IP address and Port Number can be used by 5GC to derive UE private IP address assigned by 5GC if UE is behind a NAT
- UPF responds with UE's IP address and optionally IP domain in Nupf_GetPrivateUEIP_Get response message

(TDoc snippets used to support the differences are included in each summary bullet point)

[TDoc S2-2305010]:
- Subscription requests for information per data flow include packet filter set and Applications Identifier (if available).
- TSC management information (UMIC, PMIC, NW-TT port number) is included in notification per clause 5.8.5.14 of TS 23.501.
- Throughput Measurement provides measurements of data throughput (UL and DL) for PDU Session or per application.
- QoS Monitoring events are used for UPF Data collection.

[TDoc S2-2305077]:
- 5GS supports transfer of standardized and deployment-specific user plane node management information transparently between TSN AF or TSCTSF and NW-TT, respectively inside a User Plane Node Management Information Container.
- 5GS supports transfer of standardized and deployment-specific port management information transparently between TSN AF or TSCTSF and DS-TT or NW-TT, respectively inside a Port Management Information Container.
- PTP Instances in a DS-TT port or NW-TT port can be deleted using the PTP Instance ID to reference the selected entry as described in clause K.2.2.1.
- The exchange of port management information is initiated by DS-TT to provide port management capabilities related to ports located in DS-TT or NW-TT.
- The SMF provides the port number via PCF to the TSN AF or TSCTSF.

[TDoc S2-2305078]:
- TSC management information (UMIC, PMIC, NW-TT port number) is included in notification per clause 5.8.5.14 of TS 23.501.
- Alternative Service Requirements, TSC Assistance Container, MPS for Data Transport Service indicator, SFC Policy Identifier(s), and Metadata are included in notification per clause 6.1.3.11 of TS 23.503.
- The presented DNAI is the target DNAI when only one DNAI and corresponding routing profile ID(s) and the Indication for EAS Relocation are available per clause 6.3.7 of TS 23.548.
- Throughput Measurement provides measurements of data throughput (UL and DL) for PDU Session or per application.
- This event provides statistical measurements.

[TDoc S2-2305126]:
- Reporting suggestion information may be included in event subscription to minimize impact on UPF data processing.
- Only NWDAF can subscribe to the UPF event exposure service directly for data collected for load analytics or analytics targeting "any UE."
- The NF profile for UPF Event Exposure service includes related event ID(s).
- NF consumers, including AF/NEF, TSNAF/TSCTSF, and NWDAF, may receive UPF event notifications.
- Reporting suggestion information includes Report urgency and Reporting window information.
- To get exposure data from UPF, NF consumers may subscribe directly or indirectly via SMF.

1. PCC Rule Parameters Indication:

The PCC rule comprises the information required to enable the user plane detection of policy control and proper charging for a service data flow. The Bind to QoS Flow associated with the default QoS rule and apply PCC rule parameters Indication has to be used whenever the PDU Session related information cannot be directly used as the QoS parameters of the QoS Flow associated with the default QoS rule. The operator defines the PCC rules.

2. QoS monitoring and reporting:

The SMF may configure the UPF to perform QoS monitoring for a QoS Flow and to report the monitoring results with the help of the following parameters provided in the Session Reporting Rule (SRR): QoS parameter(s) to be measured, Reporting period, Target of the reporting, Indication of direct event notification, and Reporting threshold. Subsequent reports shall not be sent by the UPF during the Minimum waiting time.

3. Configuration of QoS Parameters:

The PCF needs to be configured with the corresponding QoS parameters and their values as well as the appropriate Charging key (or receive this information from the UDR). The AF may change the QoS by providing a different QoS Reference while the AF session is ongoing. The PCF authorizes the service information from the AF and generates a PCC rule, including Alternative QoS Parameter Sets for this PCC rule based on the QoS Reference parameters or the Requested Alternative QoS Parameter Sets in the Alternative Service Requirements.

4. UPF Reporting:

The UPF shall report the minimum and the maximum measurement result when the Minimum waiting time is over. An optional Target of the reporting and Indication of direct event notification indicate that the UPF shall send the reports to a different NF than the SMF (i.e., to the Local NEF or the AF). If no measurement result is available to the UPF within the Reporting period, the UPF shall report a measurement failure.

Example snippets from the original TDoc:

- "The Bind to QoS Flow associated with the default QoS rule and apply PCC rule parameters Indication has to be used whenever the PDU Session related information cannot be directly used as the QoS parameters of the QoS Flow associated with the default QoS rule." (TDoc S2-2304105)
- "The SMF may configure the UPF to perform QoS monitoring for a QoS Flow and to report the monitoring results with the help of the following parameters provided in the Session Reporting Rule (SRR)." (TDoc S2-2304452)
- "The AF may change the QoS by providing a different QoS Reference while the AF session is ongoing. The PCF authorizes the service information from the AF and generates a PCC rule, including Alternative QoS Parameter Sets for this PCC rule based on the QoS Reference parameters or the Requested Alternative QoS Parameter Sets in the Alternative Service Requirements." (TDoc S2-2304963)
- "The UPF shall report the minimum and the maximum measurement result when the Minimum waiting time is over. An optional Target of the reporting and Indication of direct event notification indicate that the UPF shall send the reports to a different NF than the SMF (i.e., to the Local NEF or the AF)." (TDoc S2-2304964)

3GPP-S2-156-e    Agenda Item 9.19.2 : Vehicle Mounted Relays (VMR)

1. Difference in MBSR authorization indication:
- TDoc S2-2305328: The AMF may provide the indication either in a Registration Accept if the or a Registration Reject if the PLMN does not allow the MBSR IAB-UE to be registered in the PLMN.
- TDoc S2-2305332: The AMF may provide the indication either in a Registration Accept (if the PLMN allows the MBSR IAB-UE to be registered in the PLMM) or in a Registration Reject (if the PLMN does not allow the MBSR IAB-UE to be registered in the PLMN).
Example snippet from TDoc S2-2305328: "The AMF of the MBSR can indicate to the MBSR IAB-UE that it is not allowed to act as an MBSR IAB node as part of registration procedure, and in this case the AMF does not include MBSR authorization indication to donor-gNB."
Example snippet from TDoc S2-2305332: "When the MBSR (IAB-UE) performs initial registration with the serving PLMN, it indicates the request to operate as a MBSR as described in clause 5.35A.1. The AMF authorizes the MBSR based on the subscription information, and provides indication to NG-RAN."

2. Difference in UE identity indication during initial registration:
- TDoc S2-2305335: The UE shall indicate its UE identity in the Registration Request message in decreasing order of preference of native 5G-GUTIs or SUCI.
- TDoc S2-2305361: The UE shall indicate its UE identity in the Registration Request message in decreasing order of preference of native 5G-GUTIs or SUCI.
Example snippet from TDoc S2-2305335: "If UE is in CM-CONNECTED state, the (R)AN can forward the Registration Request message to the AMF based on the N2 connection of the UE."
Example snippet from TDoc S2-2305361: "If UE is in CM-CONNECTED state, the (R)AN can forward the Registration Request message to the AMF based on the N2 connection of the UE."

Overall, the technical differences among these TDocs seem to focus on specific details of the MBSR authorization indication and the UE identity indication during initial registration. However, both TDocs do indicate that the mechanism applies to both roaming and non-roaming MBSR operations.

1. TDoc S2-2304738 does not provide a description of how to provide the MBSR cell ID/TAC for certain services, while TDoc S2-2305018 specifies that the TAC and cell ID broadcasted by the MBSR cell(s) are configured as specified in TS 38.470.
- Example from TDoc S2-2305018: "The TAC and cell ID broadcasted by the MBSR cell(s) are configured as specified in TS 38.470"

2. TDoc S2-2304738 mentions that the description of how to provide the MBSR cell ID/TAC for certain services will be enhanced if needed based on RAN WG work progress, while TDoc S2-2305018 does not include this note.
- Example from TDoc S2-2304738: "Editor's note: The description of how to provide the MBSR cell ID/TAC for certain services will be enhanced if needed based on RAN WG work progress."

3. TDoc S2-2305018 is a revision of S2-230xxxx, while TDoc S2-2304738 does not indicate any previous versions or revisions.
- Example from TDoc S2-2305018: "TSG-WG SA2 Meeting #156E S2- 2305018 Elbonia, April 17 – 21, 2023 (revision of S2-230xxxx)"

4. TDoc S2-2304738 includes the title "5.35A.6 Providing cell ID/TAC of MBSR for services," while TDoc S2-2305018 includes the same title with no additional information.
- Example from both TDocs: "5.35A.6 Providing cell ID/TAC of MBSR for services"

5. TDoc S2-2304738 includes the meeting location as "Elbonia," while TDoc S2-2305018 includes the meeting location as "Elbonia" and also specifies the date range of the meeting as April 17-21, 2023.
- Example from TDoc S2-2304738: "S2-2304738 Elbonia"
- Example from TDoc S2-2305018: "TSG-WG SA2 Meeting #156E S2- 2305018 Elbonia, April 17 – 21, 2023"

6. TDoc S2-2305018 includes a reference to TS 38.470, while TDoc S2-2304738 does not mention this specification.
- Example from TDoc S2-2305018: "The TAC and cell ID broadcasted by the MBSR cell(s) are configured as specified in TS 38.470"

Overall, the main technical differences between these two TDocs involve the level of detail provided regarding the configuration of MBSR cell ID/TAC for services and the inclusion of references to specific specifications. TDoc S2-2304738 is more general in nature, indicating that further detail may be added based on work progress, while TDoc S2-2305018 provides more specific information and references a particular specification.

1. The TDoc S2-2304182 involves providing cell ID/TAC of MBSR for services, with the possibility of enhancing the description based on RAN WG work progress.
- Example: "The description of how to provide the MBSR cell ID/TAC for certain services will be enhanced if needed based on RAN WG work progress."

2. The TAC and cell ID broadcasted by the MBSR cell(s) are configured as specified in TS 38.470 in the TDoc S2-2304182.

3. The TDoc S2-2305041 involves changes to the document, with all text being new.
- Example: "First change (All text new)"

4. The TDoc S2-2305076 involves three changes made to the document.
- Example: "Second Change", "Third Change", "End of Changes"

5. The TDoc S2-xxxxxxx is being revised in TDoc S2-2304182.
- Example: "Elbonia, 17 – 21 April, 2023 (revision of S2-xxxxxxx)"

6. The meetings associated with these TDocs are e-meetings and physical meetings.
- Example: "3GPP TSG-SA WG2 Meeting #156E (e-meeting)", "3GPP TSG-WG SA2 Meeting"

7. The technical details of the changes made to the documents are not specified in the summary.
- Example: None.

3GPP-S2-156-e    Agenda Item 9.20.2 : Support for 5WWC Phase 3 (5WWC_Ph2)

- The solution allows isolation of connectivity groups into separate network slices with separate N-SSAIs for each PDU Session
- VLAN IDs and Connection Capabilities can be used as Traffic Descriptors in URSP, provided that the 5G-RG has a corresponding configuration of virtual ports with the same VLAN IDs or Connection Capabilities
- Admin settings on the 5G-RG can group devices based on mac addresses and set different QoS/priority levels for a group of devices
- The mapping of DSCP markings and corresponding QoS may be determined based on the N3IWF/TNGF IP addresses carried in packets received from the UE
- The SMF may update the provisioned mapping rules in 5G-RG to include DSCP markings and N3IWF/TNGF IP addresses
- Packet detection filters in the 5G-RG's PDU Session can be based on N3IWF/TNGF IP addresses and DSCP markings
- The registration request may contain an indication that the UE supports N3IWF selection based on the slices the UE wishes to use over untrusted non-3GPP access
- The AMF may trigger the UE PCF to update the N3IWF selection related policies on the UE if the UE registration request indicates support for N3IWF selection
- The AMF may determine a target N3IWF that supports the subset of the requested NSSAI that is allowed by the subscribed S-NSSAI(s) based on the list of supported TAs and the corresponding list of supported slices for each TA obtained in N2 interface management procedures
- The registration request may contain an indication that the UE supports TNGF selection based on the slices the UE wishes to use over trusted non-3GPP access
- The AMF may determine a target TNGF that supports the subset of the requested NSSAI that is allowed by the subscribed S-NSSAI(s) based on the list of supported TAs and the corresponding list of supported slices for each TA obtained in N2 interface management procedures
- The UE selects a PLMN and a TNAN for connecting to this PLMN using the Trusted Non-3GPP Access Network selection procedure specified in clause 6.3.12 of TS 23.501

Example snippet from TDoc S2-2305266: "When these devices have common QoS sessions and DNN/S-NSSAI to be served then, these devices are classified into 'connectivity groups' where each group connects to the 5G-RG using a separate physical or virtual port."

Example snippet from TDoc S2-2305267: "The packet detection filters in the underlying 5G-RG's PDU Session can be based on the N3IWF/TNGF IP address and the DSCP markings."

Example snippet from TDoc S2-2305272: "If the UE Registration Request contains an indication that the UE supports N3IWF selection based on the slices the UE wishes to use over untrusted non-3GPP access, the AMF may trigger the UE PCF to update the N3IWF selection related policies on the UE."

Example snippet from TDoc S2-2305274: "The UE which is not operating in SNPN access mode for Yt interface selects a PLMN and a TNAN for connecting to this PLMN by using the Trusted Non-3GPP Access Network selection procedure specified in clause 6.3.12 of TS 23.501."

Technical differences between TDoc S2-2304119 and TDoc S2-2304480:

1. Meeting Type:
- TDoc S2-2304119: Electronic meeting
- TDoc S2-2304480: Physical meeting in Elbonia

2. Meeting Date:
- TDoc S2-2304119: April 17-21, 2023
- TDoc S2-2304480: April 17-21, 2023

3. Revision:
- TDoc S2-2304119: None mentioned
- TDoc S2-2304480: Revision of S2-230xxxx

4. Changes mentioned:
- TDoc S2-2304119: First Change
- TDoc S2-2304480: Second Change, First Change

Example snippets from TDoc S2-2304119 to support difference highlighting:
- "Electronic meeting"
- "First Change"

Example snippets from TDoc S2-2304480 to support difference highlighting:
- "Physical meeting in Elbonia"
- "Revision of S2-230xxxx"
- "Second Change"
- "First Change"

[TDoc S2-2304089]:

- Technical difference: Introduction of support for SMF to provide non-3GPP QoS assistance information to the 5G-RG.
- Example snippet: "Add clause on differentiated QoS for devices behind the 5G-RG stating that during PDU session establishment and PDU session modification, if the SMF provides the 5G-RG with QoS flow descriptions, the SMF may additionally signal Non-3GPP QoS Assistance Information (N3QAI) for each QoS flow to the 5G-RG."

[TDoc S2-2304768]:

- Technical difference: Introduction of support for 5G NSWO for 3GPP UE accessing via 5G-RG.
- Example snippet: "The 5G NSWO is the capability provided by 5G system and by UE to enable the connection to a WLAN access network using 5GS credentials without registration to 5GS."

[TDoc S2-2305015]:

- Technical difference: Progress on normative work on 5WWC_Ph2 with impacts on 5G-RG specifications.
- Example snippet: "SA2 would like to inform BBF, CableLabs that it has well progressed its normative work on 5WWC_Ph2 and that this work has some impacts on 5G-RG specifications."

TDoc S2-2304767:

- The W-AGF terminates N2 and N3 interfaces to 5G Core Network for control and user-plane, respectively.
- It handles N2 signalling from SMF related to PDU Sessions and QoS.
- It relays uplink and downlink user-plane packets between the 5G-RG and UPF and between FN-RG and UPF.
- The W-AGF does not use the 5G-S-TMSI for AMF selection since the wireline AS layer can only carry the GUAMI.
- It terminates wireline access protocol on Y4 and Y5.
- In the case of FN-RG, the W-AGF acts as the endpoint of N1 on behalf of the FN-RG.

TDoc S2-2304771:

- 5G Access Stratum-based Time Distribution provides the 5GS time to the UE(s) over the radio interface.
- LTE-M is a 3GPP RAT type Identifier used in the Core Network only.
- MA PDU Session provides a PDU connectivity service.
- Network Function is a processing function in a network.
- Network Slice instance is a set of Network Function instances and the required resources.
- Network Instance identifies a domain.

TDoc S2-2305099:

- An RG connecting via W-5GAN or NG-RAN access towards 5GC can provide connectivity for a UE behind the RG to access an N3IWF or TNGF.
- FN-RG and W-5GAN acting as trusted Non-3GPP access is not considered in this specification as it is assumed that FN-RG does not support EAP-based access control.
- The 5G-RG can be connected to 5GC via W-5GAN, NG-RAN, or both accesses.
- The UE can be connected to 5GC via 5G-RG, NG-RAN, or both accesses.

TDoc S2-2305205:

- W-UP is the protocol used to carry PDU Session user plane traffic between the 5G-RG and the W-AGF over the Y4 reference point.
- W-CP is the protocol used to transport AS and NAS signalling between the 5G-RG and the W-AGF over the Y4 reference point.
- RG Level Wireline Access Characteristics provides wireline access technology-specific QoS information.
- L-W-CP is a legacy control plane protocol between the FN-RG and W-AGF.

3GPP-S2-156-e    Agenda Item 9.21 : Stage 2 of MPS_WLAN (MPS_WLAN)

3GPP-S2-156-e    Agenda Item 9.26.2 : System Enabler for Service Function Chaining (SFC)

The technical differences between TDoc S2-2304548 and TDoc S2-2304847 are as follows:

- TDoc S2-2304548 focuses on the PCF deriving TSP IDs based on the SFC ID received from the AF, which can be different for uplink and downlink directions. The TSP IDs and metadata are then sent to the SMF as part of PCC rules. If both AF influenced Traffic Steering Enforcement Control information and N6-LAN Traffic Steering Enforcement Control information are provided for the uplink direction, the SMF derives N4 rules to enable the UPF to steer the traffic to the local network after service function enforcement in the N6-LAN. In the non-roaming scenario, Application Function influence on Service Function Chain and Application Function influence on traffic routing can be applied to the same traffic simultaneously.
- TDoc S2-2304847 expands on the actions that can be taken when AF influences traffic routing. Examples include determining a target DNAI and adding, replacing, or removing UPFs in the data path, allocating a new prefix to the UE (in the case of IPv6 multi-homing), updating the UPF regarding the target DNAI, subscribing to notifications from the AMF for an area of interest, and determining whether to relocate PSA UPF based on user plane latency requirements provided by the AF and alternative service requirements.

Examples from the original TDocs to support the highlighted differences are:

- In TDoc S2-2304548: "Based on the SFC ID received from the AF, the PCF derives the TSP IDs that can be different for uplink and downlink directions that apply to PDU Session and sends the TSP IDs and optionally Metadata (as provided by the AF) to the SMF as part of the PCC rules. In case that AF influenced Traffic Steering Enforcement Control information and N6-LAN Traffic Steering Enforcement Control information for the uplink direction are both provided, the SMF shall derive N4 rules to enable the UPF to steering the traffic to the local network after the traffic is enforced by the service function(s) deployed in the N6-LAN. In the non-roaming scenario, Application Function influence on Service Function Chain and Application Function influence on traffic routing (as defined in clause 5.6.7) can be applicable to the same traffic simultaneously."
- In TDoc S2-2304847: "In the case of AF influence on traffic routing, examples of actions are: - Determining a target DNAI and adding, replacing or removing UPF(s) in the data path, e.g. to act as UL CL, Branching Point, and/or PDU Session Anchor e.g. as described in clause 4.3.5. - Allocate a new Prefix to the UE (when IPv6 multi-Homing applies). - Updating the UPF regarding the target DNAI with . - Subscribe to notifications from the AMF for an Area of Interest via Namf_EventExposure_Subscribe service operation. - Determining whether to relocate PSA UPF considering the user plane latency requirements provided by the AF (see clause 6.3.6 of TS 23.548 [20], Alternative Service Requirements (containing one or more QoS Reference parameters or Requested Alternative QoS Parameter Sets in a prioritized order), TSC Assistance Container, QoS parameter(s) to be measured, Reporting frequency, Target of reporting and optional an indication of local event notification as described in clause 6.1.3.21 of TS 23.503 5a."

3GPP-S2-156-e    Agenda Item 9.27.2 : Extensions to the TSC Framework to support DetNet (DetNet)

• TDoc S2-2304224 and TDoc S2-2304355 both discuss the usage of IETF DetNet YANG model in 5G system.

• TDoc S2-2304224 highlights the absence of ongoing work in the IETF DetNet WG regarding specifying per-node traffic requirements, while TDoc S2-2304355 mentions the usage of 3GPP extensions to the IETF DetNet YANG model for providing specific latency and loss information to the DetNet controller.

• TDoc S2-2304224 suggests involving experts from both SDOs (IETF and 3GPP) to contribute to the problem scope, while TDoc S2-2304355 specifies a required QoS procedure for signaling between the TSCTSF and the PCF.

• TDoc S2-2304224 emphasizes the importance of revisiting the per-node related DetNet WG draft, while TDoc S2-2304355 provides information on the device side ports for the TSCTSF and DetNet controller.

• TDoc S2-2304355 also mentions the optional inclusion of the MTU size for IPv4 or IPv6.

Example snippets from TDoc S2-2304224:

• "There is no ongoing work in the IETF DetNet WG to specify per-node traffic requirements such as delay budget."

• "The IETF DetNet WG suggested that appropriate experts from both SDO’s (IETF and 3GPP) be involved to contribute to the problem scope."

• "This implies that now is the good timing to revisit the per-node related DetNet WG draft."

Example snippets from TDoc S2-2304355:

• "When both the TSCTSF and the DetNet controller support 3GPP extensions to the IETF draft-ietf-detnet-yang [37], the DetNet controller may provide the 5GS-node-max-latency and 5GS-node-max-loss specific to the 5GS system."

• "When the PCF has received the 5GS Bridge/Router information for the PDU Session from SMF and has a subscription for the 5GS Bridge/Router information Notification from the TSCTSF or based on a local policy, if integration with IETF Deterministic Networking applies, the PCF provides the following information to the TSCTSF for device side ports: - user-plane node ID; - port number; - IP address or IPv6 prefix allocated to the PDU Session; - MTU size for IPv4 or MTU size for IPv6 (optional)."

• "The related QoS information to the PCF as specified in the AF session with required QoS procedure for the signaling between the TSCTSF and the PCF described in clause 4.15.6.6 of TS 23.502 [37]."

In TDoc S2-2304127, the technical differences are as follows:

- The PCF reports the outcome of UE Policies delivery to the AF when roaming
- The PCF provides QoS Reference parameter or the Requested Alternative QoS Parameter Set to the AF
- The PCF informs the AF about the Out of credit event and the applied termination action

Example snippets from TDoc S2-2304127:

- "If the AF requests the (H-)PCF, via V-PCF when roaming, to report on the outcome of the UE Policies delivery due to service specific parameter provisioning procedure targeting a single UE, the (H-)PCF reports the outcome of the related UE Policies provisioning procedure for the related traffic descriptor for the UE to the AF, via V-PCF when roaming."
- "If the SMF has notified the PCF that the resource allocation of a Service Data Flow is successful and the currently fulfilled QoS matches an Alternative QoS parameter set (as described in clause 6.2.2.1), the PCF shall also provide to the AF the QoS Reference parameter or the Requested Alternative QoS Parameter Set which corresponds to the Alternative QoS parameter set referenced by the SMF."
- "If an AF requests the PCF to report on the Out of credit event for the associated service data flow(s), the PCF shall inform the AF (when it gets informed by the SMF) that credit is no longer available for the services data flow(s) related to the AF session together with the applied termination action."

In TDoc S2-2304354, the technical differences are as follows:

- The TSCTSF can include authentication, authorization, and throttling of signalling from the DetNet controller
- The 5GS can act as a sub-network when it acts as a TSN network
- The routing of downlink packets is achieved using existing 3GPP functions
- The architecture does not require DS-TT or NW-TT functionality to be supported in devices or UPFs, but it can co-exist with such functions
- The NW-TT control plane function is used for reporting information about network side ports
- The 5GS acts as a DetNet router in the DetNet domain

Example snippets from TDoc S2-2304354:

- "Depending on the needs of a given deployment, functions such as the authentication, authorization and potential throttling of signalling from the DetNet controller can be achieved by including such functionalities in the TSCTSF."
- "A special case where the 5GS can act as a sub-network is when the 5GS acts as a TSN network, which is supported by the 3GPP specifications based on the architecture in clause 4.4.8.2."
- "The architecture does not require the DS-TT functionality to be supported in the device nor require the user plane NW-TT functionality to be supported in the UPF, however, it can co-exist with such functions."
- "For the reporting of information of the network side ports, NW-TT control plane function is used."
- "5GS acts as a DetNet router in the DetNet domain."

TDoc S2-2304356:

- Capability of the UPF and the functionality required for the particular UE session: An appropriate UPF can be selected by matching the functionality and features required for an UE. (Section 5.6.2)
- Data Network Name (DNN). (Section 5.6.3.1)
- PDU Session Type (i.e. IPv4, IPv6, IPv4v6, Ethernet Type or Unstructured Type) and if applicable, the static IP address/prefix. (Section 5.6.3.2)
- SSC mode selected for the PDU Session. (Section 5.6.5)
- UE subscription profile in UDM. (Section 5.6.1)
- DNAI as included in the PCC Rules and described in clause 5.6.7. (Section 5.6.3.1)
- Local operator policies. This allows limiting the SMF provisioning of UPF(s) using NRF to those UPF(s) associated with a certain SMF Area Identity. This information may be acquired by the SMF using N4. (Section 5.6.2.5)
- Information regarding the N3 User Plane termination(s) of the AN serving the UE. Whether and how to apply APN-AMBR for the PDN Connection associated with this DNN/APN is implementation dependent, e.g. possibly only AMBR enforcement per PDU Session applies. (Section 5.6.3.3)

TDoc S2-2304357:

- TSCTSF NF consumers (which manage network signalling not based on SUPI/SUCI (e.g. the NEF)) select a TSCTSF instance based on the GPSI or External Group ID range the UE's GPSI or External Group ID belongs to or based on the results of a discovery procedure with NRF using the UE's GPSI or External Group ID as input for TSCTSF discovery. (Section 6.3.23)
- The NFs (e.g. NEF, AF and PCF) may utilize the NRF to discover TSCTSF instance(s) unless TSCTSF information is available by other means, e.g. locally configured in the requested NF. (Section 6.3.24)
- For example, the same TSCTSF Set shall be selected by the PCF serving PDU Sessions for this DNN and S-NSSAI to notify the TSCTSF for a PDU Session that is potentially impacted by the (g)PTP time synchronization service. (Section 6.3.23)

TDoc S2-2304358:

- 5GS shall also support transfer of standardized and deployment-specific user plane node management information transparently between TSN AF or TSCTSF and NW-TT, respectively inside a User Plane Node Management Information Container. (Section 4.7.6)
- When the DS-TT or the NW-TT functions are used, the 5GS shall support transfer of standardized and deployment-specific port management information transparently between TSN AF or TSCTSF and DS-TT or NW-TT, respectively inside a Port Management Information Container. (Section 4.7.7)
- Exchange of port management information is initiated by DS-TT to provide port management capabilities. (Section 4.7.7.2)

3GPP-S2-156-e    Agenda Item 9.33 : New WID on Dynamically Changing AM Policies in the 5GC Phase 2 (TEI18_DCAMP_Ph2)

Summary of Technical Differences Among TDoc:

1. Methods for AF Influence on Access and Mobility Related Policy Control:
- [TDoc S2-2304018]: AF may request notifications on outcome of service area coverage change, indicates high throughput for one or multiple target UEs, associated with Application Identifier(s) or (DNN,S-NSSAI) combination, and has AF transaction identifier, policy expiration time, and Notification Correlation Id. NEF performs necessary mappings.
- [TDoc S2-2304838]: AF requests service area coverage and/or indicates high throughput if certain conditions are met.

Supporting Example from [TDoc S2-2304018]: "The AF may request notifications on outcome of service area coverage change, represented by a geographical area, may indicate that high throughput is desired for one or multiple target UEs, which may be associated to an Application Identifier(s) or to a (DNN,S-NSSAI) combination..."

2. Nudr Interface Functions:
- [TDoc S2-2304018]: NEF performs mappings for service area coverage change and high throughput requests. AF has AF transaction identifier, policy expiration time, and Notification Correlation Id.
- [TDoc S2-2304838]: Nudr interface supports request and provisioning of policy control related subscription information and application specific information from/to UDR, notifications on changes in policy control related subscription information, subscription to UDR for AF requests targeting a group of UEs, and notifications from UDR on update of AF requests targeting a group of UEs.

Supporting Example from [TDoc S2-2304838]: "The Nudr interface supports the following functions: - request for policy control related subscription information and application specific information from the UDR; - provisioning of policy control related subscription information and application specific information to the UDR; - notifications from the UDR on changes in the policy control related subscription information..."

3. Context Removal by AF:
- [TDoc S2-2304018]: AF removes context at time of request expiration.
- [TDoc S2-2304838]: No mention of AF context removal.

Supporting Example from [TDoc S2-2304018]: "The assumption is that the AF also removes the context at the time the AF request expires."

Overall, the technical differences among the TDocs revolve around the methods for AF influence on access and mobility related policy control, Nudr interface functions, and the removal of AF context. The examples provided in the TDocs highlight these differences and provide additional context for understanding them.

The technical differences among the following TDoc are:

1. The first TDoc (S2-2304019) describes the process of creating a new request in which the AF provides "AM influence information" data to the NEF using the Nnef_AMInfluence_Create service operation. On the other hand, the second TDoc (S2-2304832) describes the AM Policy Association establishment as described in clause 4.16.1.

Example from S2-2304019 to support the difference highlighting: "To create a new request, the AF provides "AM influence information" data to the NEF using the Nnef_AMInfluence_Create service operation (together with the AF identifier and potentially further inputs as specified in clause 5.2.6.23.2), including a target (one UE identified by GPSI, a group of UEs identified by an External Group Identifier, or all UEs, noting that the "all UEs" option is applicable only if an External Application Identifier is also provided), an optional indication of target application traffic, a list of (DNN, S-NSSAI)(s) and optionally a list of External Application Identifier(s) and requirements related to access and mobility management policies (e.g. service coverage requirements, throughput requirements)."

2. The first TDoc (S2-2304019) mentions that if the AF has subscribed to access and mobility management related events, then the PCF reports the event to the AF as described in clause 4.16.2.2. However, the second TDoc (S2-2304832) does not mention anything about subscription to events.

Example from S2-2304019 to support the difference highlighting: "If the AF has subscribed to access and mobility management related events, i.e. request for service area coverage outcome in step 3, then the PCF reports the event (i.e. outcome of the request for service area coverage) to the AF as described in clause 4.16.2.2."

3. The first TDoc (S2-2304019) describes the target for the new request, which can be one UE identified by GPSI, a group of UEs identified by an External Group Identifier, or all UEs (if an External Application Identifier is also provided). In contrast, the second TDoc (S2-2304832) mentions that the PCF itself determines the start/stop of application traffic or SM policy establishment/termination for a DNN, S-NSSAI.

Example from S2-2304019 to support the difference highlighting: "including a target (one UE identified by GPSI, a group of UEs identified by an External Group Identifier, or all UEs, noting that the "all UEs" option is applicable only if an External Application Identifier is also provided)."

4. The first TDoc (S2-2304019) mentions that the list of (DNN, S-NSSAI)(s) and optionally a list of External Application Identifier(s) and requirements related to access and mobility management policies can be provided in the new request. On the other hand, the second TDoc (S2-2304832) only mentions the Data Sub Key and the Data Set Identifier.

Example from S2-2304019 to support the difference highlighting: "a list of (DNN, S-NSSAI)(s) and optionally a list of External Application Identifier(s) and requirements related to access and mobility management policies (e.g. service coverage requirements, throughput requirements)."

5. The first TDoc (S2-2304019) requires the Operation execution result indication as an output, while the second TDoc (S2-2304832) does not mention anything about outputs.

Example from S2-2304019 to support the difference highlighting: "Outputs, Required: Operation execution result indication."

3GPP-S2-156-e    Agenda Item 9.34 : Enhancement of NSAC for maximum number of UEs with at least one PDU session/PDN connection (eNSAC)

3GPP-S2-156-e    Agenda Item 10.3 : New and revised Rel-18 Work Items

3GPP-S2-156-e    Agenda Item 99 : Withdrawn and Reserved documents

TDoc S2-2304334:
- SMF sends PVS FQDN(s) and/or PVS IP address(es) associated to DNN and S-NSSAI of PDU Session to UE as part of PCO in PDU Session Establishment Response if certain conditions are met
- UE Configuration Data for User Plane Remote Provisioning may be provided to UE during establishment of PDU Session and may be stored in ME

TDoc S2-2304335:
- Same as TDoc S2-2304334, but if SNPN acting as ON-SNPN can provide access to localized services, SMF includes both DCS provided and locally configured PVS IP address(es) and/or PVS FQDN(s) in UE Configuration Data

TDoc S2-2304383:
- UE replaces any previously received discontinuous coverage wait timer with new one in Registration Accept or UE Configuration Update Command message
- AMF may determine wait timer before UEs are allowed to initiate NAS signalling with network
- Upon returning to coverage after being out of coverage due to discontinuous coverage, UE sets wait timer to random value up to and including latest for this PLMN and RAT type, and starts timer

TDoc S2-2304424:
- NEF (PFDF) translates each external application identifier to corresponding application identifier known in core network
- PFD(s) retrieved for application identifier from NEF (PFDF) are cached in SMF and SMF maintains caching timer associated with PFD(s) to control how long they are valid
- SMF differentiates need for PFD retrieval based on operator configuration in SMF

TDoc S2-2304537:
- NWDAF considers ML model Filter information parameters S-NSSAI(s) and Area(s) of Interest, supported Analytics Delay, and NWDAF Serving Area information when selecting NWDAF for ML model provisioning
- NF consumer considers S-NSSAI, Analytics ID(s), and supported service(s) when selecting NWDAF
- In case of multiple instances of NWDAFs deployment, NWDAF Capabilities are considered

TDoc S2-2304543:
- SNPN-enabled UE with PLMN subscription may be configured with user controlled prioritized list of preferred SNPNs, Credentials Holder controlled prioritized list of preferred SNPNs and GINs, and validity information
- Credentials Holder controlled prioritized lists of preferred SNPNs and GINs may be updated by Credentials Holder using Steering of Roaming (SoR) procedure

TDoc S2-2304625:
- Location of local NEF instance may be used in conjunction with location of L-PSA UPF or AF for local NEF selection
- IP address(es)/port(s) of NEF or L-NEF may be locally configured in AF, AF may discover FQDN or IP address(es)/port(s) of NEF/L-NEF by performing DNS query using External Identifier of individual UE or using External Group Identifier of group of UEs or using EDNS Client Subnet, or AF may utilize NRF to discover FQDN or IP address(es)/port(s) of NEF or L-NEF

TDoc S2-2304633:
- Local switch where traffic is locally forwarded by single UPF if UPF is common PSA UPF of different PDU Sessions for same 5G VN group
- SMF handles user plane paths of 5G VN group, may prefer to select single PSA UPF for as many PDU sessions as possible to implement local switch on UPF
- AF can influence traffic routing for all members of 5G VN group when N6-based traffic forwarding is expected

TDoc S2-2304785:
- Bind to QoS Flow associated with default QoS rule and apply PCC rule parameters Indication must be used when Authorized default 5QI/ARP cannot be directly used as QoS parameters of QoS Flow associated with default QoS rule
- When SMF indicates subscription event, PCF checks for installed PCC rule and sets Downlink Data Notification Control information of that PCC rule according to requested type(s) of notifications
- If exclusive charging information related to Application function record information is required, PCF provides service identifier for AF session and indicates exclusion from session level monitoring

TDoc S2-2305025:
- TSCTSF provides notification towards AF when there is a change in support status for UE or group of UEs for 5G access stratum time synchronization service or (g)PTP time synchronization service status update
- TSCTSF determines UEs for which impacted UPF/NW-TT is configured to send (g)PTP messages
- AMF includes clock quality reporting control information provided by TSCTSF or received from UDM when providing 5G access stratum time distribution indication and Uu time synchronization error budget to NG-RAN

1. TDoc S2-2304102 deals with the procedures for obtaining the private IP address of a user equipment (UE) behind a network address translator (NAT), while TDoc S2-2304384 deals with the provisioning of satellite coverage availability information to the access and mobility management function (AMF).
- Example from TDoc S2-2304102: "The request includes the UE (public) IP address and Port Number... The request message shall include UE address (IP address or MAC address) and AF Identifier, it may include, Port Number associated with the IP address, MTC Provider Information, Application Port ID, IP domain."
- Example from TDoc S2-2304384: "The satellite coverage availability information provisioned to the AMF describes when and where satellite coverage is expected to be available in an area."

2. TDoc S2-2304102 involves the use of the Nnrf_NFDiscovery service operation to obtain the address of the user plane function (UPF) implementing NAT functionality for the UE, while TDoc S2-2304384 involves the provisioning of satellite coverage availability information to the AMF by O&M.
- Example from TDoc S2-2304102: "The NEF uses the Nnrf_NFDiscovery service operation to obtain the address of the UPF implementing NAT functionality for the UE (public) IP address."
- Example from TDoc S2-2304384: "Satellite coverage availability information may be provisioned to the AMF by O&M."

3. TDoc S2-2304102 includes the optional parameters of IP domain, DNN, and S-NSSAI associated with the application function (AF) ID, while TDoc S2-2304384 does not involve any UE-specific information in the satellite coverage availability information provisioned to the AMF.
- Example from TDoc S2-2304102: "The request includes the UE (public) IP address and Port Number, and optionally IP domain, DNN and S-NSSAI associated with the AF ID."
- Example from TDoc S2-2304384: "The satellite coverage availability information is not UE specific and can be applied by the AMF for any UE in the affected area."

4. TDoc S2-2304102 involves the use of the combination of IP address and Port Number to derive the UE private IP address if the UE is behind a NAT, while TDoc S2-2304384 does not involve any such procedures.
- Example from TDoc S2-2304102: "The combination of IP address and Port Number can be used by 5GC to derive the UE private IP address assigned by 5GC if the UE is behind a NAT, see steps 3-6 below."
- Example from TDoc S2-2304384: None.

Overall, the two TDocs involve different technical procedures and information elements, with TDoc S2-2304102 dealing with the obtaining of UE private IP addresses behind a NAT, and TDoc S2-2304384 involving the provisioning of satellite coverage availability information to the AMF.

[TDoc S2-2304790]:

- The AF can locally configure the IP address(es)/port(s) of the NEF or L-NEF, or discover it using DNS query or NRF.
- Local NEF selection can be based on the location of the NEF instance and L-PSA UPF or AF.
- EDNS Client Subnet option can be used to determine a local NEF directly.

[TDoc S2-2305346]:

- AI/ML decisions and operation logic reside at the AF and UE application client.
- The application decides whether to request assistance from 5GC.
- 5GS assistance to support AI/ML operations in the application layer is applicable to operations within a single slice.
- AF requests for 5GS assistance to AI/ML operations must be authorized by the 5GC.
- UPF can detect AI/ML traffic and the network needs to support charging for it.

[TDoc S2-2305349]:

- NEF interacts with 5GC NFs to collect data based on filtering criteria provided by the AF to derive a list of candidate UE(s).
- NEF provides the AF with UE member selection assistance information, including candidate UE(s) list(s) and additional information.
- AF can choose whether to use the selection assistance functionality provided by NEF.

[TDoc S2-2305356]:

- SNPN-enabled UE with PLMN subscription can be configured with user-controlled and Credentials Holder-controlled prioritized lists of preferred SNPNs and GINs.
- The Credentials Holder can update the lists using the SoR procedure, which is not applicable for Credentials Holder with AAA Server.

Example snippets from the original TDocs:

- "When the AF discovers the FQDN or IP address(es)/port(s) of the NEF/L-NEF by performing a DNS query, the AF can add in its DNS request an EDNS Client Subnet option in order to help the DNS determine a local NEF directly." (TDoc S2-2304790)
- "UPF can perform traffic detection for AI/ML traffic as defined in clause 5.8.2.4 and the network needs to support charging for AI/ML traffic." (TDoc S2-2305346)
- "Referring to the filtering criteria provided by the AF, NEF interacts with 5GC NFs using existing services to collect the corresponding data from relevant 5GC NFs (e.g. PCF, NWDAF and AMF) to derive the list(s) of candidate UE(s)" (TDoc S2-2305349)
- "Updating Credentials Holder controlled prioritized lists of preferred SNPNs and GINs via the Steering of Roaming (SoR) procedure is not applicable for Credentials Holder with AAA Server." (TDoc S2-2305356)

TDoc S2-2305028:

- The TSCTSF may provide notification to AFs subscribed for 5G access stratum time synchronization service or (g)PTP time synchronization service when there is a change in support status for a UE or group of UEs due to NG-RAN or UPF timing synchronization status change.
- The TSCTSF modifies the subscription to remove the RAN node ID from the Area of Interest if the RAN node notifies the TSCTSF for the status improvement.
- The TSCTSF determines the UEs for which an impacted UPF/NW-TT is configured to send (g)PTP messages.
- The AMF includes clock quality reporting control information provided by the TSCTSF or received from UDM in the 5G access stratum time distribution indication and the Uu time synchronization error budget when provided to NG-RAN.

TDoc S2-2305086:

- The NSACF checks network slice availability before returning a response to the SMF+PGW-C.
- The NSACF responds to the SMF+PGW-C with the information that the network slice is available if the UE identity is already included in the list of UE IDs registered with a network slice or the current number of UE registration did not reach the maximum number.
- The AMF instance serving the UE logically belongs to each of the Network Slice instances serving the UE.
- The number of simultaneous connection of Network Slice instances per UE is limited by the number of S-NSSAIs in the Requested/Allowed NSSAI.

TDoc S2-2305355:

- NEF executes the corresponding service operation based on the filtering criteria provided by the AF and verifies the authorization of the AF Request.
- NEF consolidates all the information collected from other 5GC NFs and derives one or more list(s) of candidate UEs and possibly additional information according to the filtering criteria requested by the AF.
- NEF derives the list(s) of candidate UE(s) which fulfill the filtering criteria in the AF request based on the collected information from other 5GC NFs.
- Table 4.15.13.2-1 provides a summary of the filtering criteria that the AF may request.

TDoc S2-2305357:

- This clause describes the procedure to request QoS and perform QoS monitoring for the communication between a list of UEs and the AF identified by the UE IP address(es).
- The NEF notifies the Application AI/ML AF via Nnef_MultiMemberAFSessionWithQoS_Notify for the collected UPF QoS monitoring reports together with the status of the Consolidated-MBR monitoring and the AF Transaction Reference ID when the aggregate bit rate exceeds the Consolidated-MBR threshold.
- The NEF notifies the AF periodically with the collected UPF QoS monitoring reports together with the status of the Consolidate-MBR monitoring and the AF Transaction Reference ID if requested.
- The NEF authorizes the Multi-member AF request and may apply policies to control the overall amount of QoS authorized for the AF.

Examples from the TDoc:

- "The TSCTSF may provide notification towards the AF when there is a change in support status for a UE or group of UEs."
- "The NSACF responds to the SMF+PGW-C with the information that the network slice is available."
- "NEF consolidates all the information collected from other 5GC NFs and derives one or more list(s) of candidate UEs."
- "The NEF notifies the Application AI/ML AF via Nnef_MultiMemberAFSessionWithQoS_Notify for the collected UPF QoS monitoring reports together with the status of the Consolidated-MBR monitoring and the AF Transaction Reference ID."