Apex Standards 3GPP Meeting Tracker

---

updated as of Mon, Apr 17, 2023, 08:03 PM UTC (5 hours ago)
Mon, Apr 17, 01:03 PM California
Mon, Apr 17, 10:03 PM Berlin/Paris
Tue, Apr 18, 04:03 AM Beijing

3GPP-C4-115-e    Agenda Item 2 : Allocation of documents to agenda items

3GPP-C4-115-e    Agenda Item 3 : Meeting Reports

3GPP-C4-115-e    Agenda Item 4 : Input liaison statements: allocation to agenda items as appropriate

TDoc C4-231011:

- The proposed draft Recommendation aims to improve the reliability and availability of IMS network.
- It specifies scenarios, signaling requirements, and procedures for bypassing network elements of IMS.
- The detail information of the proposed draft Recommendation is contained in the living list of Q3/11.

Example: "ITU-T Study Group 11 would like to inform ITU-T Study Group 2 and 3GPP CT4 that a new draft Recommendation Q.Sig_Req_ SG11 would like to receive your comments and collaborations on this proposed draft Recommendation and hope you can share your related works with us if you have similar studies in this area."

TDoc C4-231012:

- SA3 added requirements and explaining text to deal with the use case of NF and SCP not including the custom header, i.e., pre-release 17.
- The term “3gpp-Sbi-Originating-Network-Id” is used as defined in TS 29.500 as the mandatory custom header that can be always included by the sending NF from Rel-17 onwards.
- Related CRs S3-231606 and S3-231417 are attached.

Example: "Further, SA3 would like SA2, CT4, and GSMA 5GMRR to acknowledge that requirements and explaining text are added to deal with the use case of NF and SCP not including the custom header, i.e., pre-release 17, as well as distinguishing the handling between SEPPs representing only one PLMN-ID and multiple PLMN-IDs."

TDoc C4-231013:

- In-depth considerations on the integration of existing intermediaries and services in roaming and interconnect are required to enable a smooth transition to 5G SA roaming.
- The requirements outline support for the established use cases in roaming and required in 5G SA roaming and interconnect.
- GSMA 5GMRR asks 3GPP to consider the entities that currently exist in the roaming ecosystem in 3GPP specifications.

Example: "5GMRR would like to provide 3GPP with requirements, as requested by 3GPP, for the major intermediaries and services (Roaming Hub, IPX and RVAS Providers) needed within the roaming ecosystem."

TDoc C4-231014:

- 5GMRR would like to provide a stable set of requirements that cover all GSMA use cases for roaming & interconnect security and functionality.
- IPX Providers shall have the ability to provide IP transport to route roaming signaling and payload messages between PLMNs and their roaming partners.
- GSMA requests SA1, SA2, and SA3 to update their specifications to support requirements that are currently not covered.

Example: "In response to the requests made by 3GPP SA3 to ask 5GMRR to provide a stable set of requirements that cover all GSMA use cases for roaming & interconnect security and functionality, 5GMRR would like to provide the following list of general requirements from IPX Providers’ perspective."

TDoc C4-231015:

- A scalable and standard solution is needed for the relation between RVAS provider and client MNO.
- GSMA 5GMRR suggests using N32 for this purpose, where VPLMN-ID remains visible to the client MNO.
- Sponsor MNO needs to play a pivotal role in establishing an end-to-end relation between VPLMN and the actual HPLMN of the subscriber.

Example: "SUCI deconcealment would happen at the RVAS provider, before the actual client MNO can be identified (client MNO is identified based on assigned IMSI subranges, managed by RVAS provider)."

TDoc C4-231018:

- CT1 needs further discussion on the protocol details for the specification of transport of LPP messages and supplementary service event reports over a user plane connection between UE and LMF.
- CT1 requests CT4 to provide guidance to CT6, if required, on the coding of SUCI.
- CT1 believes that a new 3GPP allocated port number is necessary for SLMP.

Example: "CT1 believes that a new 3GPP allocated port number is the way forward (i.e., solution #6; 3GPP allocated port number solution) and after considering the information provided by TS 29.641, CT1 would like to request allocation of new 3GPP allocated port numbers."

TDoc C4-231019:

- CT6 needs guidance from CT1 on the coding of the SUCI as described in the LS.
- The UTF-8 coding of hexadecimal digits used in SUCI NAI is case insensitive.
- The coding of SUCI has been defined in TS 23.003 under CT4 remit.

Example: "CT1 thanks CT6 for their LS (C1-230015/C6-220715) on clarification of coding of hexadecimal digits in SUCI NAI. However since the coding of SUCI has been defined in TS 23.003, CT1 requests CT4 to provide further guidance to CT6, if required."

TDoc C4-231021:

- CT1 requests allocation of new 3GPP allocated port numbers for SEAL Off-network Location Management Protocol (SLMP).
- The SLMP is a 3GPP control protocol used by a SEAL Location Management Client (SLM-C) hosted on a UE.
- CT WG1 requests CT WG4 to allocate a UDP port number for the protocol SLMP.

Example: "CT1 has developed a protocol which require allocation of new UDP ports by IANA called Service Enabler Architecture Layer for Verticals (SEAL) Off-Location Management Protocol (SLMP) that is defined in TS 24.545 clause 6.3."

TDoc C4-231022:

- There is inconsistency on the number of PVS IP addresses and/or PVS FQDNs for remote provisioning in onboarding network between stage 2 specification and stage 3 specification.
- CT1 believes that it is not necessary to specify the maximum number of PVS IP address(es) and/or PVS FQDN(s).
- CT1 kindly requests SA2 to remove the above NOTE in TS 23.501.

Example: "There is inconsistency on the number of PVS IP addresses and/or PVS FQDNs for remote provisioning in onboarding network between stage 2 specification and stage 3 specification as below."

TDoc C4-231023:

- Entries of CH controlled prioritized lists of preferred SNPNs and G

TDoc C4-231010:

- The document discusses issues related to test cases covering SUCI calculation when non-IMSI SUPI type (NSI, GCI, or GLI) is configured in the USIM.
- It provides an understanding of the coding of SUCI, which is provided as part of the 5GS mobile identity information element in the REGISTRATION REQUEST message.
- For SUCI with SUPI format set to "Network specific identifier," the SUCI NAI field contains an NAI constructed as specified in subclause 28.7.3 of TS 23.003.
- The ME or the USIM constructs the SUCI and encodes it as UTF-8 string based on Service nº125 of the EFUST of the USIM.
- The document mentions the USIM configuration for non-IMSI SUPI type.

TDoc C4-231020:

- The document clarifies the use of "Operator Identifier" in Operator-Identifier based N3IWF FQDN for emergency services when the UE detects a user request for emergency session and determines that Untrusted non-3GPP access is to be used.
- The UE shall perform the emergency N3IWF selection procedure as if always in a visited country and without using the Non-3GPP Access Node Selection Information.
- The CT1 group requests SA2 to provide an answer to the question for clarification.

TDoc C4-231024:

- The document evaluates the checklist in clause 4.2 of 3GPP TS 29.641.
- The MSGin5G service in general is needed to be delivered between different PLMNs, and it should be supported by intra-domain interface(s).
- The CT WG1 group requests CT WG4 to allocate a UDP port number for the protocol of MSGin5G message on top of CoAP transport over MSGin5G-1 reference point in Rel-17 as specified in 3GPP TS 29.641.
- Solution #6 is preferable and selected for MSGin5G service.
- A new port number will be used for 3GPP intra-domain interface between MSGin5G Client hosted in the UE and MSGin5G Server.
- SA6 develops the stage 2 normative work of MSGin5G service under the 5GMARCH work item started in Rel-17 and captured in 3GPP TS 23.554.

TDoc C4-231027:

- RAN3 thanks CT for the LS on Tracking IANA assignment requests.
- RAN3 noticed that the W1-U interface, which uses GTP-U, has not been captured in TS 29.281.
- To CT4, RAN3 asks to update the corresponding specification.

Example from TDoc C4-231027: "RAN3 also noticed that the W1-U interface (as specified in TS 37.470), which uses GTP-U, has not been captured in TS 29.281."

TDoc C4-231028:

- RAN3 thanks SA2 for their LS response on shared NG-U Termination among gNBs.

Example from TDoc C4-231028: "RAN3 thanks SA2 for their LS response on shared NG-U Termination among gNBs."

TDoc C4-231030:

- SA2 thanks CT1 for their LS.
- NSWOF performs the proxy of the EAP message between the SWa’ interface and the SBI interface towards AUSF.
- NSWOF acts towards the WLAN Access as a Diameter server, and is not acting as an authentication server.

Example from TDoc C4-231030: "SA2 thanks CT1 for their LS."

TDoc C4-231035:

- 3GPP SA5 respectfully asks RAN2, RAN3, SA4, CT1, and CT4 to take the above information into account and update relevant specifications.
- Management Based QoE Measurement Collection (QMC) for NR including attributes for activation and Deactivation of QMC.
- Signalling Based QoE Measurement Collection for NR including attributes for activation and Deactivation of QMC.

Example from TDoc C4-231035: "3GPP SA5 respectfully asks RAN2, RAN3, SA4, CT1 and CT4 to take the above information in account and if needed update relevant specification."

[TDoc C4-231016]:
- The Roaming Hubbing service is based on a trust model where VPMN and HPMN outsource all or part of their roaming associations to their respective RH provider(s).
- The roaming hub provides services outside a PLMN’s domain without the need for PLMNs to establish direct network relations with each other.
- The solution should scale accordingly when PLMNs rely on the SEPP of the roaming hub for all roaming connections.

[TDoc C4-231017]:
- L-PRINS provides a single solution for all use cases where an intermediary provides a service other than IP routing, increasing traceability, attribution, and non-repudiation over N32 interface.
- The solution enables both the RH and Service Hub full access to the Http messages exchanged over N32-f and N32-c.
- End-to-end attribution is possible by offline processing of the RH logs made available to VPLMN or HPLMN.

[TDoc C4-231026]:
- GSMA is not in favour of C4-225387 and will not include the IP address option in their guidelines.
- Using FQDNs with PLMN IDs simplifies security checks and provides direct traceability between N32c and N32f identifiers.
- The responsibility for Subject Name and SAN field contents lies with the GSMA.

[TDoc C4-231033]:
- SA3 requests CT4 to specify the mechanisms necessary for error reporting.
- Session management and message injection by intermediaries are not covered by the current 5G architecture.
- SA3 points out potential security impacts of state mismatch between cNF and pNF and requests a stable and comprehensive set of requirements.

3GPP-C4-115-e    Agenda Item 5 : Work item management

TDoc C4-231071:

- Objective is to study potential optimization solutions for the NRF APIs to avoid redundant data
- No specific impacts or areas of work outlined
- Primary classification not specified
- No parent or related work items mentioned
- Justification is based on the fact that NF profiles of NF instances may share common data
- No specific example snippets provided to support the difference highlighting

TDoc C4-231177:

- CT3 and CT4 are impacted to support enhancements related to DNN and S-NSSAI specific group parameters
- NEF and Nudm_ParameterProvision service API are impacted in CT3 and CT4 respectively
- Impacts may be updated/extended based on normative work and requirements
- No primary classification or parent/related work items mentioned
- No specific example snippets provided to support the difference highlighting

TDoc C4-231179:

- Objective is to support standardized and operator-specific traffic categories in the Connection Capability of Traffic Descriptor of URSP rule
- NEF and UDR may be updated to support VPLMN specific service parameter provisioning
- Primary classification not specified
- No parent or related work items mentioned
- Justification is based on gaps in the current design of UE Policy related to URSP for home-routed and LBO roaming scenarios
- Example snippet: "Updates to the URSP TD component type connection capabilities to enhance the support for standardized and operator defined traffic categories"

TDoc C4-231181:

- CT3 and CT4 are impacted to support Traffic Steering Policy and SFC enhancements
- Nnef_TrafficInluence Service and UPF may be updated to support new SFC policy ID and optional metadata
- No primary classification or parent/related work items mentioned
- Example snippet: "Potential updates to the UPF to support optional metadata included in the FAR"
- SA2 study item on system enabler for service function chaining (FS_SFC) is mentioned as a basis for the work

TDoc C4-231211: Enhanced CT1 stage 2 specifications for supporting HPLMN provided prioritization information of VPLMNs with which the UE may register for a network slice
- NAS protocol enhancements to indicate the capability of the UE supporting SOR-enhanced for Slice-based PLMN Selection
- Definition of when the home network provides the SOR-enhanced information to the UE supporting such feature
- Definition of the SOR-enhanced information that is securely transferred from the home network to the UE and used by the UE for Slice-based PLMN selection
- Definition of the UE behaviour upon reception of enhanced-SOR information for Slice-based PLMN Selection

TDoc C4-231306: Technical improvements and enhancements to network data analytics related services in Release 18 stage 3 level not covered by other work items
- Specification of the impact of user consent in data collection and data storage
- Corrections and/or updates to network data analytics related services missed in the previous 3GPP Releases, which are not covered by the other dedicated Rel-18 work items

TDoc C4-231318: Enhanced mobility enabling support for idle and connected mode mobility between SNPNs without new network selection and support for providing access to localized services
- Impacts to cover the UE access to an SNPN within the list of equivalent SNPNs
- Possible impacts on AMF communication service, e.g. populating the target SNPN NID during an idle mode inter AMF mobility procedure, to enable the source AMF to decide whether to transfer UE context for only the access used for UE's registration in the target SNPN or for both accesses
- Enhancements of automatic network selection of a hosting network, which also includes extension of 3GPP Cellular Network ANQP-element to enable providing information needed for non-3GPP access selection of a UE attempting to access an SNPN via trusted non-3GPP access
- CP-SOR enhancements for enabling automatic network selection of a hosting network

TDoc C4-231375: Provisioning of DetNet configuration from the DetNet controller to 5GS
- Potential extension of the flow description (PCF) to include the IPv6 flow label and IPsec SPI
- Updates of the PCC procedures to describe the provisioning of DetNet configuration into 5GS
- Updates to provide node and interface information by the UPF for 5GS DetNet node reporting
- Updates of the PCC procedures and/or API impacts to cover the report of 5GS DetNet node information (procedure and parameters)

Example snippets from TDoc C4-231211:
- "The objective of this work item is to enhance the applicable CT1 stage 2 specifications (i.e. TS 23.122, etc.) to support the stage 1 requirements on HPLMN provided prioritization information of VPLMNs with which the UE may register for a network slice"
- "Define when the home network provides the SOR-enhanced information to the UE supporting such feature"
- "Define the SOR-enhanced information that is securely transferred from the home network to the UE and used by the UE for Slice-based PLMN selection"

Example snippets from TDoc C4-231306:
- "The network data analytics related services (e.g. Nnwdaf services defined in 3GPP TS 29.520, Ndccf services defined in 3GPP TS 29.574, Nadrf services defined in 3GPP TS 29.575, Nmfaf services defined in 3GPP TS 29.576, etc.) are specified in the previous 3GPP releases in order to efficiently collect the data, store the data and analytics, and provide the analytics to the consumer."
- "Corrections and/or updates to network data analytics related services missed in the previous 3GPP Releases, which are not covered by the other dedicated Rel-18 work items."

Example snippets from TDoc C4-231318:
- "Support for enhanced mobility enabling support for idle and connected mode mobility between SNPNs without new network selection"
- "Support for providing access to localized services"
- "Enhancements of automatic network selection of a hosting network."

Example snippets from TDoc C4-231375:
- "Provisioning of DetNet configuration from the DetNet controller to 5GS"
- "SA2 has been studying the integration of 5GS with DetNet networks in the study Study on Extensions to the TSC Framework to support DetNet (FS_DetNet)."
- "Updates of the PCC procedures and/or API impacts to cover the report of 5GS DetNet node information (procedure and parameters)."

• TDoc C4-231166 highlights the issue of excessive data exposure through subscriptions to data-change notifications on data-sets that NF-Service Consumers do not have access to.

Example: "if an SMF is restricted to, say, sm-data resource in Nudm_SDM API, by use of allowedOperationsperNfType definition in the NF-Service profile of the UDM; it (SMF) may still be able to subscribe to changes in am-data resource by creating a subscription to data-change notifications on am-data data-set; and thus have access to excessive data."

• One proposed solution in TDoc C4-231166 involves granting access tokens for individual data-sets being retrieved through APIs allowing retrieval or subscription to multiple data-sets.

Example: "Samsung submitted in CT4 #114 via C4-230109 proposed that, for the APIs allowing retrieval-of or subscription-to-changes-to multiple data-sets, the NF Service Consumers must possess access-token allowing access to the individual data-sets being retrieved."

• TDoc C4-231167 aims to study potential solutions for avoiding excessive data exposure and indirect access to data via subscriptions.

Example: "To study the need and potential solutions for avoiding excessive data exposure over SBI. To study the need and potential solutions for avoiding indirect access to data via, e.g. subscriptions, even as direct access to the data-set is not allowed."

• The justification for the study item is that current SBI APIs do not limit the amount of information exposed to different NF-Service Consumers.

Example: "APIs defined by SBI currently don't limit the amount of information exposed to different NF-Service Consumers. This is because access to ../sdm-subscriptions resource requires access-token granting access to the ../sdm-subscriptions resource, and not the data-sets for whose changes the NF-consumer is subscribing to."

• The study item leadership for TDoc C4-231167 is CT4.

Example: "CT4 needs to be consulted for changes that may require Stage-2 alignment."

• Other WGs, such as SA3 and CT3, may need to be consulted for information/feedback.

Example: "SA3 needs to be (potentially) consulted for changes that may require Stage-2 alignment CT3 may need to be consulted for information/feedback."

• The study does not exclude issues that are not related to security aspects of excessive data exposure.

Example: "The study does not preclude issues not relating to security aspects of excessive data exposure."

3GPP-C4-115-e    Agenda Item 6.1.3 : Study on NRF API enhancements to avoid signalling and storing of redundant data [FS_NRFe]

1. TDoc C4-231367 proposes to include evaluation for Key Issue #2 in TR 29.831.
- "Introduction: This paper proposes to include Evaluation for KI#2 in TR 29.831."

2. TDoc C4-231368 proposes a conclusion for Key Issue #2 in FS_NRFe.
- "Title: Conclusion for Key Issue #2 of FS_NRFe"

3. Both TDocs propose changes to 3GPP TR 29.831 v0.3.0.
- "It is proposed to agree the following changes to 3GPP TR 29.831 v0.3.0"

4. TDoc C4-231367 is a solution evaluation.
- "Title: Solution Evaluation for Key Issue #2"

5. TDoc C4-231368 is a conclusion.
- "Title: Conclusion for Key Issue #2"

6. TDoc C4-231367 was presented at the 3GPP TSG-CT WG4 Meeting #115e E-Meeting from April 17-21, 2023.
- "* 3GPP TSG-CT WG4 Meeting #115e C4-231367 E-Meeting, 17th– 21st April 2023"

7. TDoc C4-231368 was presented at the same meeting.
- "* 3GPP TSG-CT WG4 Meeting #115e C4-231368 E-Meeting, 17th– 21st April 2023"

TDoc C4-231098:

- Proposal to allow NRF to simplify discovery responses based on source PLMN identity
- PLMN specific rules may take additional information into account when deciding to remove parameters from discovery response messages
- Taking source PLMN identity into account when composing response messages is common in the core network
- Con: Additional NRF storage and processing resources may be needed to store and apply OAM configured policy rules
- Inter-PLMN discovery traffic represents a low contribution to overall NF discovery traffic
- Example: Policy rule for foreign PLMNs could require removal of TAIs and TAI ranges from SMF discovery responses sent to a foreign PLMN
- Policy rules define parameters of registered NF profile that can be exposed to PLMN

TDoc C4-231365:

- Proposal to identify discovered shared data using shared-data IDs and corresponding higher level NRF instance ID
- Solutions #2 and #5 restrict sharing of data to NF sets and do not address sharing of common data between different sets
- Solutions #1, alternative 2 of solution #2, and solution #4 propose additional roundtrip to retrieve shared data from NRF if corresponding shared data or set profile has not yet been received
- Solution #5 proposes NRF retrieves and subscribes to shared data from NF during registration procedure
- Solution #4 proposes higher level NRF to store shared data, addressing synchronization issue between NRFs, but adds need for synchronized configuration

Summary of Technical Differences:

1. TDoc C4-231099 discusses the evaluation of solutions for Key Issue #2, while TDoc C4-231100 discusses the conclusion for Key Issue #1.
- Example from TDoc C4-231099: "Evaluation of solutions for key issue #2 is missing."
- Example from TDoc C4-231100: "Conclusion for key issue #1 is missing."

2. TDoc C4-231099 includes a section on Conclusions, while TDoc C4-231100 includes a section on Introduction.
- Example from TDoc C4-231099: "Conclusions"
- Example from TDoc C4-231100: "Introduction"

3. TDoc C4-231099 provides a Reason for Change for the evaluation of solutions, while TDoc C4-231100 provides a Reason for Change for the conclusion of solutions.
- Example from TDoc C4-231099: "Reason for Change Evaluation of solutions for key issue #2 is missing."
- Example from TDoc C4-231100: "Reason for Change Conclusion for key issue #1 is missing."

4. TDoc C4-231099 pertains to Decision 1, while TDoc C4-231100 also pertains to Decision 1.
- Example from TDoc C4-231099: "Document for: Decision 1"
- Example from TDoc C4-231100: "Document for: Decision 1"

5. Both TDocs were presented at 3GPP TSG-CT WG4 Meeting #115e E-Meeting from April 17th-21st, 2023.
- Example from TDoc C4-231099: "3GPP TSG-CT WG4 Meeting #115e C4-231099 E-Meeting, 17th– 21st April 2023"
- Example from TDoc C4-231100: "3GPP TSG-CT WG4 Meeting #115e C4-231100 E-Meeting, 17th– 21st April 2023"

3GPP-C4-115-e    Agenda Item 6.1.6 : CT aspects of enhancement to the 5GC location services - phase 3 [5G_eLCS_Ph3 ]

[TDoc C4-231329]:
- The LcsPrivacyData type has properties for lpi, unrelatedClass, and plmnOperatorClasses.
- The LcsPrivacy type has properties for afInstanceId, referenceId, lpi, mtcProviderInformation, and nullable.
- The LcsPrivacy type references other YAML files for Lpi and MtcProviderInformation.
- Example snippet: "LcsPrivacyData: type: object properties: lpi: $ref: '#/components/schemas/Lpi' unrelatedClass: $ref: '#/components/schemas/UnrelatedClass' plmnOperatorClasses: type: array items: $ref: '#/components/schemas/PlmnOperatorClass' minItems: 1"

[TDoc C4-231335]:
- The first type has required properties for amfId, ldrType, hgmlcCallBackURI, ldrReference, and eventReportMessage.
- The first type references other YAML files for NfInstanceId, LocationQoS, SupportedGADShapes, Supi, Gpsi, and LdrType.
- The second type has required properties for reportedEventType and ldrReference.
- The second type references other YAML files for ReportedEventType, Supi, Gpsi, and Uri.
- Example snippet: "type: object required: - amfId - ldrType - hgmlcCallBackURI - ldrReference - eventReportMessage properties: amfId: $ref: 'TS29571_CommonData.yaml#/components/schemas/NfInstanceId' locationQoS: $ref: '#/components/schemas/LocationQoS' supportedGADShapes: type: array items: $ref: '#/components/schemas/SupportedGADShapes' minItems: 1 supi: $ref: 'TS29571_CommonData.yaml#/components/schemas/Supi' gpsi: $ref: 'TS29571_CommonData.yaml#/components/schemas/Gpsi' ldrType: $ref: '#/components/schemas/LdrType' hgmlcCallBackURI: $ref: 'TS29571_CommonData.yaml#/components/schemas/Uri'"

[TDoc C4-231338]:
- The first type has required properties for semiMajor, semiMinor, vertical, and orientationMajor.
- The first type references other YAML files for Uncertainty and Orientation.
- The second type has required properties for eventClass and eventContent.
- The second type references another YAML file for RefToBinaryData.
- Example snippet: "description: Ellipsoid with uncertainty type: object required: - semiMajor - semiMinor - vertical - orientationMajor properties: semiMajor: $ref: '#/components/schemas/Uncertainty' semiMinor: $ref: '#/components/schemas/Uncertainty' vertical: $ref: '#/components/schemas/Uncertainty' orientationMajor: $ref: '#/components/schemas/Orientation'"

[TDoc C4-231376]:
- The first type has required properties for amfId, ldrType, hgmlcCallBackURI, ldrReference, and eventReportMessage.
- The first type references other YAML files for NfInstanceId, LocationQoS, SupportedGADShapes, Supi, Gpsi, and LdrType.
- The second type has required properties for reportedEventType and ldrReference.
- The second type references other YAML files for ReportedEventType, Supi, Gpsi, and Uri.
- The second type has an enum for UPWARD and DOWNWARD.
- Example snippet: "type: object required: - amfId - ldrType - hgmlcCallBackURI - ldrReference - eventReportMessage properties: amfId: $ref: 'TS29571_CommonData.yaml#/components/schemas/NfInstanceId' locationQoS: $ref: '#/components/schemas/LocationQoS' supportedGADShapes: type: array items: $ref: '#/components/schemas/SupportedGADShapes' minItems: 1 supi: $ref: 'TS29571_CommonData.yaml#/components/schemas/Supi' gpsi: $ref: 'TS29571_CommonData.yaml#/components/schemas/Gpsi' ldrType: $ref: '#/components/schemas/LdrType' hgmlcCallBackURI: $ref: 'TS29571_CommonData.yaml#/components/schemas/Uri'"

TDoc C4-231337:

- It defines operations for the Nlmf_Location service, including DetermineLocation, EventNotify, LocationContextTransfer, and CancelLocation.
- DetermineLocation is used to determine the location of a UE.
- EventNotify is used to transfer location context information for periodic or triggered location of a target UE to a new LMF.
- LocationContextTransfer provides UE location information to the consumer NF.
- CancelLocation enables a consumer NF to cancel an ongoing periodic or triggered location for a target UE.

TDoc C4-231339:

- It defines the functionality of the Location Management Function (LMF) in the 5G Core Network.
- The LMF supports location determination for a UE.
- It obtains downlink location measurements or a location estimate from the UE, uplink location measurements from the NG RAN, and non-UE associated assistance data from the NG RAN.
- It provides broadcast assistance data to UEs and forwards associated ciphering keys to an AMF.
- Other functions of the LMF are listed in 3GPP TS 23.273 clause 4.3.8.

TDoc C4-231340 and C4-231341:

- They both define the MOLR-Type ENUMERATED datatype.
- The datatype includes values for location estimates, assistance data, deCipheringKeys, deferredMo-lrTTTPInitiation, deferredMo-lrSelfLocationInitiation, deferredMt-lrOrmo-lrTTTPLocationEstimate, deferredMt-lrOrmo-lrCancellation, periodicEvent, enteringAreaEvent, leavingAreaEvent, beingInsideAreaEvent, motionEvent, and maximumIntervalExpirationEvent.

[TDoc C4-231241]:
- The TDoc defines three query parameters: n32-purposes, preferred-features, and remote-plmn-id-roaming.
- n32-purposes is an array type that refers to the N32Purpose schema.
- preferred-features is an object type that refers to the SupportedFeatures schema.
- remote-plmn-id-roaming is a JSON content type that refers to the PlmnId schema.

Example snippet from the TDoc: Table 6.2.9-1 shows the features of supportedFeatures attribute used by Nnrf_NFDiscovery service.

[TDoc C4-231326]:
- The TDoc provides an overview of the resources and applicable HTTP methods in Table 6.1.3.1-1.
- The TDoc lists the OAuth2 scopes defined in the Nudm_SDM API in Table 6.1.9-1.
- The TDoc defines the Nudm_SDM service API with its re-used data types in Table 6.1.6.1-2.
- The TDoc shows the resource URI structure of the Nudm-SDM API in Figure 6.1.3.1-1.

Example snippet from the TDoc: Table 6.1.6.2.93-1 defines the type LcsSubscriData.

[TDoc C4-231330]:
- The TDoc specifies the data types defined for the Ngmlc_Location service-based interface protocol in Table 6.1.5.1-1.
- The TDoc defines the InputData type in Table 6.1.5.2.2-1.
- The TDoc shows the ProvideLocation Request/Response for a target UE in Figure 5.2.2.2.2-1.

Example snippet from the TDoc: Table 6.1.5.1-2 lists the Ngmlc_Location re-used data types.

[TDoc C4-231336]:
- The TDoc defines the lppMessage and lppMessageExt properties that refer to the RefToBinaryData and CorrelationID schemas, respectively.
- The TDoc defines the InputData type in Table 6.1.6.2.2-1.
- The TDoc lists the ReportingArea schema as an array type with a minimum of one and a maximum of 250 items.

Example snippet from the TDoc: Table 6.1.6.2.2-1 defines the type InputData.

Technical Differences:

- TDoc C4-231140 includes references to TS29505_Subscription_Data.yaml for subscription data related paths, while TDoc C4-231331 defines the type of LocationData in Table 6.1.5.2.3-1.
- TDoc C4-231140 deals with subscription data related paths, while TDoc C4-231331 deals with the definition of LocationData type.

Example Snippets from TDoc C4-231140:

- "/subscription-data/{ueId}/lcs-privacy-data: $ref: 'TS29505_Subscription_Data.yaml#/paths/~1subscription-data~1%7BueId%7D~1lcs-privacy-data'"
- "/subscription-data/{ueId}/lcs-mo-data: $ref: 'TS29505_Subscription_Data.yaml#/paths/~1subscription-data~1%7BueId%7D~1lcs-mo-data'"
- "/subscription-data/{ueId}/pp-data: $ref: 'TS29505_Subscription_Data.yaml#/paths/~1subscription-data~1%7BueId%7D~1pp-data'"

These snippets show that TDoc C4-231140 includes references to YAML files for defining subscription data related paths.

Example Snippets from TDoc C4-231331:

- "LocationData Table 6.1.5.2.3-1: Definition of type LocationData"

This snippet shows that TDoc C4-231331 defines the type of LocationData in a table.

3GPP-C4-115-e    Agenda Item 6.1.7 : Enhancement of Shared Data Handling [ShDatID]

3GPP-C4-115-e    Agenda Item 6.1.8 : CT Aspects of Edge Computing Phase 2 [EDGE_Ph2]

Technical differences between TDoc C4-231123 and TDoc C4-231149:

TDoc C4-231123:
- Includes routingIndicator, hNwPubKeyId, sessionAmbr, qosFlowsList, hSmfInstanceId, smfInstanceId, pduSessionSmfSetId, pduSessionSmfServiceSetId, pduSessionSmfBinding, enablePauseCharging, ueIpv4Address, ueIpv6Prefix, epsPdnCnxInfo, epsBearerInfo, maxIntegrityProtectedDataRate, maxIntegrityProtectedDataRateDl, and intraPlmnApiRoot.
- Utilizes $ref to reference common data YAML and schema components.
- Specifies type and default value for enablePauseCharging.
- Defines minItems for qosFlowsList and epsBearerInfo.

Example snippet from TDoc C4-231123:
- "qosFlowsList: type: array items: $ref: '#/components/schemas/QosFlowSetupItem' minItems: 1"

TDoc C4-231149:
- Includes communicationCharacteristics, referenceId, validityTime, mtcProviderInformation, supportedFeatures, ecsAddrConfigInfo, additionalEcsAddrConfigInfos, ecRestriction, and nullable.
- Utilizes $ref to reference common data YAML and schema components.
- Defines nullable for ecRestriction.

Example snippet from TDoc C4-231149:
- "nullable: true"

Overall, TDoc C4-231123 focuses on specific parameters related to session management and communication, while TDoc C4-231149 focuses on various types of configuration information and restrictions. Both utilize $ref to reference commonly used components and specify certain attributes such as minItems and nullable.

TDoc C4-231120:

- DNS message processing model defines how the EASDF processes DNS messages received for a particular UE's PDU session.
- One single DNS context is created per PDU session by the SMF.
- DNS context includes the UE IP address, S-NSSAI, DNN of the PDU session, and one or more DNS rules.
- The NF Service Consumer sends a POST request to the resource representing the DNS contexts collection resource of the EASDF to create a DNS context.

Example snippet: "The SMF shall control how the EASDF processes DNS messages received for a particular UE's PDU session by creating one single DNS context per PDU session including the following information."

TDoc C4-231121:

- Type HrsboRspInfo is defined with properties hrsboAuthResult and hDnsAddr.
- Table 6.1.6.1-1 specifies data types defined for the Nsmf service-based interface protocol, and Table 6.1.6.1-2 specifies data types re-used by the Nsmf service-based interface protocol.

Example snippet: "Table 6.1.6.1-1 specifies the data types defined for the Nsmf service-based interface protocol."

TDoc C4-231164:

- Defines procedures where HsmfUpdateData is invoked by the H-SMF or SMF.
- Table 6.1.6.2.11-1 defines type HsmfUpdateData.
- HsmfUpdateData is invoked in procedures such as Network requested PDU session modification and 5GS to EPS Idle mode mobility using N26 interface.

Example snippet: "It is invoked by the H-SMF or SMF in the following procedures."

TDoc C4-231242:

- Table 6.1.8-1 specifies supported features defined for the Nudr_DataRepository API.
- The supported features shall be negotiated using the extensibility mechanism defined in clause 6.6 of 3GPP TS 29.500.

Example snippet: "They shall be negotiated using the extensibility mechanism defined in clause 6.6 of 3GPP TS 29.500 [7]."

TDoc C4-231206:
- 3GPP TS 23.316 is for wireless and wireline convergence access support for the 5G System (5GS)
- 3GPP TS 23.558 is for architecture for enabling Edge Applications (EA)
- 3GPP TS 29.002 is for Mobile Application Part (MAP) specification
- ITU-T Recommendation Q.763 (1999) is for Specifications of Signalling System No.7; Formats and codes
- 3GPP TS 38.331 is for NR; Radio Resource Control (RRC); Protocol specification
- 3GPP TS 38.413 is for NG-RAN; NG Application Protocol (NGAP)
- 3GPP TS 24.007 is for Mobile radio interface signalling layer 3; General aspects
- 3GPP TS 33.501 is for Security architecture and procedures for 5G system; Stage 2

TDoc C4-231207:
- 3GPP TS 29.571 is for 5G System; Common Data Types for Service Based Interfaces; Stage 3
- 3GPP TS 29.542 is for 5G System; Session Management Services for Non-IP Data Delivery (NIDD); Stage 3
- 3GPP TS 29.503 is for 5G System; Unified Data Management Services; Stage 3
- 3GPP TS 23.548 is for 5G System Enhancements for Edge Computing; Stage 2
- 3GPP TS 29.524 is for 5G System; Cause codes mapping between 5GC interfaces; Stage 3
- 3GPP TS 29.510 is for Network Function Repository Services; Stage 3
- 3GPP TS 23.247 is for Architectural enhancements for 5G multicast-broadcast services; Stage 2
- IETF RFC 2387 is for The MIME Multipart/Related Content-type

TDoc C4-231297:
- 3GPP TS 23.316 is for wireless and wireline convergence access support for the 5G System (5GS)
- 3GPP TS 23.558 is for architecture for enabling Edge Applications (EA)
- 3GPP TS 29.002 is for Mobile Application Part (MAP) specification
- ITU-T Recommendation Q.763 (1999) is for Specifications of Signalling System No.7; Formats and codes
- 3GPP TS 38.331 is for NR; Radio Resource Control (RRC); Protocol specification
- 3GPP TS 38.413 is for NG-RAN; NG Application Protocol (NGAP)
- 3GPP TS 24.007 is for Mobile radio interface signalling layer 3; General aspects
- 3GPP TS 33.501 is for Security architecture and procedures for 5G system; Stage 2
- BBF TR-456 is empty

TDoc C4-231379:
- 3GPP TS 23.316 is for wireless and wireline convergence access support for the 5G System (5GS)
- 3GPP TS 23.558 is for architecture for enabling Edge Applications (EA)
- 3GPP TS 29.002 is for Mobile Application Part (MAP) specification
- ITU-T Recommendation Q.763 (1999) is for Specifications of Signalling System No.7; Formats and codes
- 3GPP TS 38.331 is for NR; Radio Resource Control (RRC); Protocol specification
- 3GPP TS 38.413 is for NG-RAN; NG Application Protocol (NGAP)
- 3GPP TS 24.007 is for Mobile radio interface signalling layer 3; General aspects
- 3GPP TS 33.501 is for Security architecture and procedures for 5G system; Stage 2
- BBF TR-456 is empty

Examples from TDoc C4-231206:
- "3GPP TS 23.316 is for wireless and wireline convergence access support for the 5G System (5GS)"
- "3GPP TS 23.558 is for architecture for enabling Edge Applications (EA)"
- "3GPP TS 33.501 is for Security architecture and procedures for 5G system; Stage 2"

Examples from TDoc C4-231207:
- "3GPP TS 29.571 is for 5G System; Common Data Types for Service Based Interfaces; Stage 3"
- "IETF RFC 2387 is for The MIME Multipart/Related Content-type"

Examples from TDoc C4-231297:
- "3GPP TS 38.413 is for NG-RAN; NG Application Protocol (NGAP)"
- "BBF TR-456 is empty"

Examples from TDoc C4-231379:
- "3GPP TS 23.316 is for wireless and wireline convergence access support for the 5G System (5GS)"
- "3GPP TS 38.413 is for NG-RAN; NG Application Protocol (NGAP)"
- "BBF TR-456 is empty"

Technical Differences:

1. MutingNotificationsSettings is an object type that indicates the event producer NF settings to the event consumer NF. It has properties of maxNoOfNotif and durationBufferedNotif. StringMatchingCondition is also an object type, but it contains a string with a matching operator.
- TDoc C4-231122: "Indicates the Event producer NF settings to the Event consumer NF"
- TDoc C4-231122: "properties: maxNoOfNotif: type: integer durationBufferedNotif: $ref: '#/components/schemas/DurationSec'"
- TDoc C4-231122: "A String with Matching Operator"
- TDoc C4-231122: "properties: matchingString: type: string matchingOperator: $ref: '#/components/schemas/MatchingOperator'"

2. The Common Data Types TDoc contains data related to common data types for service-based interfaces. It includes properties such as trackingAreaList, countries, and geographicalServiceArea.
- TDoc C4-231148: "Common Data Types for Service Based Interfaces."
- TDoc C4-231148: "properties: trackingAreaList: type: array items: $ref: '#/components/schemas/Tai' minItems: 1 countries: type: array items: $ref: '#/components/schemas/Mcc' minItems: 1 geographicalServiceArea: $ref: '#/components/schemas/GeoServiceArea'"

3. The SpatialValidityCond TDoc contains the spatial validity condition.
- TDoc C4-231122: "Contains the Spatial Validity Condition."
- TDoc C4-231122: "Type: SpatialValidityCond"
- TDoc C4-231122: "Table 5.4.4.74-1: Definition of type SpatialValidityCond"

Example Snippets:

1. TDoc C4-231122:
- "Indicates the Event producer NF settings to the Event consumer NF"
- "properties: maxNoOfNotif: type: integer durationBufferedNotif: $ref: '#/components/schemas/DurationSec'"
- "A String with Matching Operator"
- "properties: matchingString: type: string matchingOperator: $ref: '#/components/schemas/MatchingOperator'"

2. TDoc C4-231148:
- "Common Data Types for Service Based Interfaces."
- "properties: trackingAreaList: type: array items: $ref: '#/components/schemas/Tai' minItems: 1 countries: type: array items: $ref: '#/components/schemas/Mcc' minItems: 1 geographicalServiceArea: $ref: '#/components/schemas/GeoServiceArea'"

3. TDoc C4-231122:
- "Contains the Spatial Validity Condition."
- "Type: SpatialValidityCond"
- "Table 5.4.4.74-1: Definition of type SpatialValidityCond"

3GPP-C4-115-e    Agenda Item 6.1.9 : Enhancement of NSAC for maximum number of UEs with at least one PDU session/PDN connection [eNSAC]

3GPP-C4-115-e    Agenda Item 6.1.10 : UPF enhancement for exposure and SBA [UPEAS]

TDoc C4-231104:

- Includes a paths section with a /ue-ip-info endpoint for searching UeIpInfo for a PDU session
- Uses the security scheme oAuth2ClientCredentials for authentication
- Has parameters for snssai and dnn in the /ue-ip-info endpoint
- Uses the $ref keyword to refer to a schema in another YAML file
- Includes an info section with a title and description

Example snippets from TDoc C4-231104:

- "security: - {} - oAuth2ClientCredentials: - nupf-gueip"
- "paths: /ue-ip-info: get: summary: Search UeIpInfo for a PDU session from the UeIpInfo operationId: SearchUeIpInfo tags: - UE IP Info_Get parameters: - name: snssai in: query description: Slice of the PDU session schema: $ref: 'TS29571_CommonData.yaml#/components/schemas/Snssai' - name: dnn in: query description: * * A.3 Nupf_GetPrivateUEIPaddr API"
- "openapi: 3.0.0 info: version: '1.0.0-alpha.1' title: 'UPF GET Private UE IP address Service' description: | Nupf_GetPrivateUEIPaddr Service."

TDoc C4-231303:

- Defines a map object with IANA-assigned SMI Network Management Private Enterprise Codes as keys
- Uses the $ref keyword to refer to a schema in another YAML file
- Includes an anyOf section with a type string and enum options for NF types
- Includes a dnaiNwInstanceList section with a description

Example snippets from TDoc C4-231303:

- "type: object additionalProperties: type: array items: $ref: 'TS29510_Nnrf_NFManagement.yaml#/components/schemas/VendorSpecificFeature' minItems: 1 minProperties: 1 oauth2Required: type: boolean"
- "allowedOperationsPerNfType: * 6.1.6.2.3 Type: NFService Table 6.1.6.2.3-1: Definition of type NFService"
- "dnaiNwInstanceList: description: > * *"

Technical Differences Among TDocs:

[TDoc C4-231157]:
- Defines Type: NotificationItem
- Defines QoS Monitoring Measurement information in QosMonitoringMeasurement object
- Contains a URL for the API
- Version: 1.1.0-alpha.1
- Re-uses Data Types for Nupf_EventExposure
- Adds changes to the original TDoc

[TDoc C4-231158]:
- Requires request body for application/json content type
- Defines callbacks for event notification URI
- Defines QoS Monitoring Measurement information in QosMonitoringMeasurement object
- Contains an enumeration for Event Type
- Re-uses Data Types for Nupf_EventExposure

[TDoc C4-231393]:
- Defines Type: NotificationItem
- Defines QoS Monitoring Measurement information in QosMonitoringMeasurement object
- Contains a URL for the API
- Version: 1.1.0-alpha.1
- Re-uses Data Types for Nupf_EventExposure
- Adds changes to the original TDoc

Examples from TDoc C4-231157:
- qosMonitoringMeasurement: $ref: '#/components/schemas/QosMonitoringMeasurement'
- QosMonitoringMeasurement: description: QoS Monitoring Measurement information type: object properties: dlPacketDelay: $ref: 'TS29571_CommonData.yaml#/components/schemas/Uint32'
- url: https://www.3gpp.org/ftp/Specs/archive/29_series/29.564/
- Re-used Data Types for Nupf_EventExposure
- Adds changes to the original TDoc

Examples from TDoc C4-231158:
- requestBody: required: true content: application/json: schema:
- callbacks: eeNotification: '{eventNotificationUri}': # The URI in {eventNotificationUri} is provided via N4 interface during provisioning of Session Reporting Rule. qosMonitoringMeasurement: $ref: '#/components/schemas/QosMonitoringMeasurement'
- QosMonitoringMeasurement: description: QoS Monitoring Measurement information type: object properties: dlPacketDelay: $ref: 'TS29571_CommonData.yaml#/components/schemas/Uint32'
- EventType: description: Event Type anyOf: - type: string enum: - QOS_MONITORING

Examples from TDoc C4-231393:
- qosMonitoringMeasurement: $ref: '#/components/schemas/QosMonitoringMeasurement'
- QosMonitoringMeasurement: description: QoS Monitoring Measurement information type: object properties: dlPacketDelay: $ref: 'TS29571_CommonData.yaml#/components/schemas/Uint32'
- url: https://www.3gpp.org/ftp/Specs/archive/29_series/29.564/
- Re-used Data Types for Nupf_EventExposure
- Adds changes to the original TDoc

TDoc C4-231069:

- Get service operation used for AF specific UE ID retrieval
- Input filter criteria included in query parameters
- Message body may contain a ProblemDetails structure with a "cause" attribute
- Response body includes a UeIpInfo object
- HTTP status code listed in Table 6.2.3.2.3.1-3 returned on failure
- NF Service Consumer sends an HTTP GET request to the "ue-ip-info" resource URI
- Request sent to UPF hosting the IP address in the query
- "200 OK" returned on success

Example snippet: "The input filter criteria for the discovery request shall be included in query parameters, e.g. the UE (public) IP address and Port Number, and optionally DNN and S-NSSAI."

TDoc C4-231156:

- Reporting time information defining last valid reporting time
- Deactivate notification flag indicating muted notification until retrieval notification flag
- Immediate Report Flag per event for immediate report generation
- Notification Correlation ID for correlation identity in event notifications

Example snippet: "The Subscribe service operation is used by a NF Service Consumer to subscribe to UPF event exposure notifications...The payload body of the POST request shall contain a representation of the individual subscription resource to be created."

TDoc C4-231391:

- Reporting time information defining last valid reporting time
- Deactivate notification flag indicating muted notification until retrieval notification flag
- Immediate Report Flag per event for immediate report generation
- Notification Correlation ID for correlation identity in event notifications

Example snippet: "The Subscribe service operation is used by a NF Service Consumer to subscribe to UPF event exposure notifications...The payload body of the POST request shall contain a representation of the individual subscription resource to be created."

TDoc C4-231178:
- Metadata specifies a byte format and a string type
- The nullable property is set to true
- The description indicates that the string is passed to the UPF for traffic to SFC

Example snippet: "A String which is transparently passed to the UPF to be applied for traffic to SFC."

TDoc C4-231373:
- Section 5.2.1.3.2 discusses the QoS Monitoring event
- No metadata or simple data types are mentioned

Example snippet: "Table 5.2.1.3.2-1: QoS Monitoring event"

TDoc C4-231392:
- Metadata specifies a byte format and a string type
- The nullable property is set to true
- The description indicates that the string is passed to the UPF for traffic to SFC

Example snippet: "A String which is transparently passed to the UPF to be applied for traffic to SFC."

The main technical difference among these TDocs is the section and topic they cover. TDoc C4-231178 and C4-231392 both discuss the same metadata with byte format and string type, while TDoc C4-231373 focuses on QoS monitoring events without any mention of data types.

3GPP-C4-115-e    Agenda Item 6.1.11 : 5MBS Phase 2 [5MBS_PH2]

Technical differences among TDoc C4-231107 and C4-231108:

1. TDoc C4-231107 includes proposed changes to data related to common data types, while TDoc C4-231108 does not mention any specific changes.
- Example from C4-231107: "Proposed changes: add a new common data type 'Time' to the list of existing common data types"
- Example from C4-231108: "Proposed changes: End of Changes"

2. TDoc C4-231107 includes two proposed changes, while TDoc C4-231108 only includes one.
- Example from C4-231107: "*** 1st Change ***" and "*** 2st Change ***"
- Example from C4-231108: "First Change ***"

3. TDoc C4-231107 is from the 3GPP TSG-CT WG4 Meeting #115e E-Meeting held on 17th-21st April 2023, while TDoc C4-231108 is also from the same meeting but does not specify a specific date.
- Example from C4-231107: "** 3GPP TSG-CT WG4 Meeting #115e C4-231107 E-Meeting, 17th– 21st April 2023"
- Example from C4-231108: "** 3GPP TSG-CT WG4 Meeting #115e C4-231108 E-Meeting"

Overall, the main difference between these two TDocs is that C4-231107 includes specific proposed changes related to common data types, while C4-231108 does not mention any specific changes. Additionally, C4-231107 includes two proposed changes compared to only one in C4-231108. Finally, both TDocs are from the same meeting but C4-231107 specifies the exact dates while C4-231108 does not.

Technical Differences Highlighted in TDoc C4-231106 and C4-231344:

TDoc C4-231106:

- Type 5MbsAuthorizationInfo and type MbsSubscriptionData are defined in different tables (6.5.6.2.22 and 6.1.6.2.84 respectively).
- Clause 6.5.6.1 specifies the application data model supported by the API and includes a table (6.5.6.1-2) of re-used data types for Nudm_PP.
- Type PpData is defined in table 6.5.6.2.2 and includes properties mbsAllowed (boolean) and mbsSessionIdList (array of MbsSessionId objects).
- The Nudm_PP API is defined in section A.6 and includes a YAML file (TS29571_CommonData.yaml) with a schema for MbsSessionId.

TDoc C4-231344:

- Type PpData and type MbsSubscriptionData are defined in different tables (6.5.6.2.2 and 6.1.6.2.84 respectively).
- The Nudm_PP API is defined in section A.6 and includes a YAML file (TS29571_CommonData.yaml) with a schema for MbsSessionId.
- Type 5MbsAuthorizationInfo is defined as an object with a nullable array of 5mbsSessionIds.
- The re-used data types for Nudm_SDM are listed in table 6.1.6.1-2.

Example Snippets from TDoc C4-231106:

- Type 5MbsAuthorizationInfo is defined in table 6.5.6.2.22: "Type: 5MbsAuthorizationInfo Table 6.5.6.2.22-1: Definition of type 5MbsAuthorizationInfo"
- Type MbsSubscriptionData is defined in table 6.1.6.2.84: "Type: MbsSubscriptionData Table 6.1.6.2.84-1: Definition of type MbsSubscriptionData"
- The re-used data types for Nudm_PP are listed in table 6.5.6.1-2: "Table 6.5.6.1-2: Nudm_PP re-used Data Types"
- Type PpData is defined in table 6.5.6.2.2 and includes properties mbsAllowed and mbsSessionIdList: "Type: PpData Table 6.5.6.2.2-1: Definition of type PpData"
- The Nudm_PP API is defined in section A.6 and includes a YAML file with a schema for MbsSessionId: "A.6 Nudm_PP API...re-used Data Types"

Example Snippets from TDoc C4-231344:

- Type PpData is defined in table 6.5.6.2.2: "Type: PpData Table 6.5.6.2.2-1: Definition of type PpData"
- Type MbsSubscriptionData is defined in table 6.1.6.2.84: "Type: MbsSubscriptionData Table 6.1.6.2.84-1: Definition of type MbsSubscriptionData"
- Type 5MbsAuthorizationInfo is defined as an object with a nullable array of 5mbsSessionIds: "[...] 5MbsAuthorizationInfo: type: object properties: 5mbsSessionIds: type: array items: $ref: 'TS29571_CommonData.yaml#/components/schemas/MbsSessionId' minItems: 1 nullable: true [...]"
- The re-used data types for Nudm_SDM are listed in table 6.1.6.1-2: "Table 6.1.6.1-2: Nudm_SDM re-used Data Types"

3GPP-C4-115-e    Agenda Item 6.1.12 : Enhancements on Service-based support for SMS in 5GC [eSMS_SBI] PDU sessions of a same UE [FS_PDUe]

3GPP-C4-115-e    Agenda Item 6.2.2 : Enhancements of UE Policy [eNPN_Ph2]

3GPP-C4-115-e    Agenda Item 6.2.4 : Support for 5WWC Phase 2 [5WWC_Ph2]

3GPP-C4-115-e    Agenda Item 6.2.6 : CT aspects of proximity based services in 5GS Phase 2 [5G_ProSe_Ph2]

3GPP-C4-115-e    Agenda Item 6.2.11 : 5G Timing Resiliency and TSC & URLLC enhancements [TRS_URLLC]

Technical Differences and Example Snippets from TDoc C4-231124 and C4-231125:

1. UE Type
- C4-231124: One UE, Group of UEs, any UE
- C4-231125: One UE, Group of UEs, any UE

2. Report Type
- C4-231124: One-Time Report, Continuous Report
- C4-231125: One-Time Report, Continuous Report

3. Input
- C4-231124: UE ID(s), "ANY_UE", optionally filters: Area identifier (a TA list, an area Id or "LADN")
- C4-231125: UE ID(s), "ANY_UE", optionally filters: Area identifier (a TA list, an area Id or "LADN")

4. Notification
- C4-231124: UE ID, most recent registration state (REGISTERED/DEREGISTERED) with access type
- C4-231125: UE ID, most recent registration state (REGISTERED/DEREGISTERED) with access type

5. Event
- C4-231124: Connectivity-State-Report
- C4-231125: Connectivity-State-Report

6. Example Snippets from C4-231124:
- "A NF subscribes to this event to receive the current connection management state of a UE or a group of UEs."
- "Report for updated connection management state of a UE or any UE in the group when AMF becomes aware of a connection management state change of the UE."

7. Example Snippets from C4-231125:
- "A NF subscribes to this event to receive the current connection management state of a UE or a group of UEs."
- "Report for updated connection management state of a UE or any UE in the group when AMF becomes aware of a connection management state change of the UE."

8. Example Snippets from both TDocs:
- " UE Type: One UE, Group of UEs"
- "Report Type: One-Time Report, Continuous Report"
- "Input: UE ID(s), "ANY_UE", optionally filters: Area identifier (a TA list, an area Id or "LADN")"
- "Notification: UE ID(s)"
- "Event: Type-Allocation-Code-Report"
- "A NF subscribes to this event to receive the TAC of a UE or a group of UEs or any UE."

3GPP-C4-115-e    Agenda Item 6.2.12 : Extensions to the TSC Framework to support DetNet [DetNet]

3GPP-C4-115-e    Agenda Item 6.2.13 : CT aspects of 5G System Enabler for Service Function Chaining [SFC]

3GPP-C4-115-e    Agenda Item 6.2.14 : CT aspects of Access Traffic Steering, Switch and Splitting support in the 5G system architecture; Phase 3 [ATSS_PH3]

TDoc C4-231138:

- The TDoc is related to 3GPP TS 23.214, which is about architecture enhancements for control and user plane separation of EPC nodes.
- Octet 5 contains three different flags, namely V4, V6, and NV4.
- If V4 is set to "1", the Link-Specific IPv4 Address for 3GPP Access shall be present in the Link-Specific IP Address IE.
- If V6 is set to "1", the Link-Specific IPv6 Address for 3GPP Access shall be present in the Link-Specific IP Address IE.
- If NV4 is set to "1", it indicates MPTCP steering functionality is of type Transport Converter.

TDoc C4-231248:

- The TDoc is related to 3GPP TS 23.214, which is about architecture enhancements for control and user plane separation of EPC nodes.
- Octet 5 contains four different flags, namely V4, V6, NV4, and NV6.
- If V4 is set to "1", the UE Link-Specific IPv4 Address for 3GPP Access shall be present in the UE Link-Specific IP Address IE.
- If V6 is set to "1", the UE Link-Specific IPv6 Address for 3GPP Access shall be present in the UE Link-Specific IP Address IE.
- If NV4 is set to "1", the UE Link-Specific IPv4 Address for Non-3GPP Access shall be present in the UE Link-Specific IP Address IE.
- If NV6 is set to "1", it indicates steering functionality.

Examples from TDoc C4-231138:

- "If this bit is set to '1', then the Link-Specific IPv4 Address for 3GPP Access shall be present in the Link-Specific IP Address IE." (V4 flag)
- "If this bit is set to '1', then the Link-Specific IPv6 Address for 3GPP Access shall be present in the Link-Specific IP Address IE." (V6 flag)
- "If this bit is set to '1', it indicates that the required MPTCP steering functionality is of type Transport Converter." (NV4 flag)

Examples from TDoc C4-231248:

- "If this bit is set to '1', then the UE Link-Specific IPv4 Address for 3GPP Access shall be present in the UE Link-Specific IP Address IE." (V4 flag)
- "If this bit is set to '1', then the UE Link-Specific IPv6 Address for 3GPP Access shall be present in the UE Link-Specific IP Address IE." (V6 flag)
- "If this bit is set to '1', then the UE Link-Specific IPv4 Address for Non-3GPP Access shall be present in the UE Link-Specific IP Address IE." (NV4 flag)
- "If this bit is set to '1', it indicates steering functionality." (NV6 flag)

- TDoc C4-231250 introduces a new feature related to UE assistance mode termination and load balancing.
- It specifies that the UPF shall store the original split percentage provisioned by the SMF and apply it when the UE assistance mode is terminated.
- Additionally, if the Steering mode is set to Load-Balancing and the UE Assistance Indicator is set, the UPF may apply the split percentages in the UE Assistance Data to all DL traffic for which the SMF has enabled the UE assistance operation.
- TDoc C4-231137 and 231249 both discuss the Access Traffic Steering, Switching and Splitting (ATSSS) feature, which enables the support of Multi-Access (MA) PDU sessions.
- This feature can be used with one 3GPP access network or one non-3GPP access network at a time or simultaneously with one 3GPP access network and one non-3GPP access network.
- If the UE is registered to both 3GPP and non-3GPP access, distinct N3/N9 tunnels shall be established for each access network of the MA PDU session.
- This is done by providing two UL PDRs to the PSA UPF in PFCP Session Establishment Request or PFCP Session Modification Request message, with one PDR for UL data from 3GPP access and another for UL data from non-3GPP access.
- The support of the ATSSS feature is optional for the SMF and the UPF, subject to corresponding support by the UE.
- TDoc C4-231250 lists four procedures related to performance measurement and UE assistance data provisioning: RTT measurement procedure, Packet Loss Rate measurement procedure, Access available/unavailable report procedure, and UE Assistance Data provisioning procedure.
- These procedures can be initiated by the UE or the UPF.

3GPP-C4-115-e    Agenda Item 6.2.15 : Enablers for Network Automation for 5G phase 3 [eNA_PH3]

3GPP-C4-115-e    Agenda Item 6.2.16 : CT aspects on enhancement of network slicing phase 3 [eNS_PH3]

[TDoc C4-231127]:
- Technical difference: NSAC admission modes for roaming UEs
- Example snippet: "depending on operator's policy and roaming agreement, a specific NSAC admission mode (i.e. VPLMN NSAC admission, VPLMN with HPLMN assistance admission or HPLMN NSAC admission) is determined for the NSAC procedure for roaming UEs"

[TDoc C4-231130]:
- Technical difference: Definition of type AuthorizedNssaiAvailabilityData and NssfEventNotification
- Example snippet: "Table 6.2.6.2.4-1: Definition of type AuthorizedNssaiAvailabilityData"

[TDoc C4-231196]:
- Technical difference: Re-used data types for Nnssf service based interface protocol
- Example snippet: "Table 6.2.6.1-2 specifies data types re-used by the Nnssf service based interface protocol from other specifications"

[TDoc C4-231198]:
- Technical difference: Feature negotiation mechanism for NSSAI availability information resource
- Example snippet: "The NSSF shall determine the supported features for the updated NSSAI Availability information resource as specified in clause 6.6 of 3GPP TS 29.500 [4] and shall indicate the supported features by including the supportedFeatures attribute in the authorized NSSAI availability information it returns in the HTTP response"

[TDoc C4-231200]:
- Technical difference: Use of Notify SM Context Status in UE requested PDU Session Establishment procedure
- Example snippet: "UE requested PDU Session Establishment procedure, when the PDU session establishment fails after the Create SM Context response or to provide the SMF derived CN assisted RAN parameters tuning"

[TDoc C4-231257]:
- Technical difference: Services offered by NSACF to different NFs
- Example snippet: "Within the 5GC, the NSACF offers services to the AMF, SMF (or combined SMF+PGW-C), NWDAF, NEF and DCCF via the Nnsacf service based interface"

Overall, the technical differences among these TDocs range from NSAC admission modes and data types to feature negotiation mechanisms and service offerings for different NFs.

TDoc C4-231280:
- The NF Service Consumer shall invoke the NumOfPDUsUpdate service operation to request the NSACF to perform network slice admission control procedure related to the number of PDU sessions.
- The NSACF shall check whether the access type provided by the NF Service Consumer is configured for NSAC for the indicated S-NSSAI to control the number of PDU sessions.

TDoc C4-231281:
- The Subscribe service operation is invoked by a NF Service Consumer towards the NSACF to create a subscription to monitor the event relevant to the NSACF.
- The POST method shall support URI query parameters such as notification threshold and notification periodicity.
- A ProblemDetails IE shall be included in the payload body of POST response with the "cause" attribute of ProblemDetails set to application error codes.

TDoc C4-231371:
- The Notify Service operation shall be used by the NSSF to update the NF Service Consumer with any change in status, on a per TA basis, of the S-NSSAIs available per TA and the S-NSSAIs restricted per PLMN in that TA in the serving PLMN of the UE.
- The NF service consumer shall return one of the HTTP status code together with the response body listed in Table 6.2.5.2.3.1-2 on failure or redirection.
- The NSSF shall determine the supported features for the updated NSSAI Availability information resource and shall indicate the supported features by including the supportedFeatures attribute in the authorized NSSAI availability information it returns in the HTTP response.

TDoc C4-231372:
- The Notify Service operation shall be used by the NSSF to update the NF Service Consumer with any change in status, on a per TA basis, of the S-NSSAIs available per TA and the S-NSSAIs restricted per PLMN in that TA in the serving PLMN of the UE.
- The NF service consumer shall return one of the HTTP status code together with the response body listed in Table 6.2.5.2.3.1-2 on failure or redirection.
- The NSSF shall determine the supported features for the updated NSSAI Availability information resource and shall indicate the supported features by including the supportedFeatures attribute in the authorized NSSAI availability information it returns in the HTTP response.

Examples from the original TDoc:
- TDoc C4-231280: "The NSACF shall remove the PDU registration entry when the PDU session is released from all access types."
- TDoc C4-231281: "A ProblemDetails IE shall be included in the payload body of POST response, with the "cause" attribute of ProblemDetails set to application error codes specified in table 6.2.5.2.2.1-3."
- TDoc C4-231371: "Table 6.2.6.1-1 specifies the data types defined for the Nnssf_NSSAIAvailability service based interface protocol."
- TDoc C4-231372: "The following features are defined for the Nnssf_NSSAIAvailability service."

TDoc C4-231129:

- The API contains a property called AdditionalSnssaiData with type object.
- The property requiredAuthnAuthz is of type boolean.
- The property subscribedUeSliceMbr is referred from a different YAML file and is of type SliceMbrRm.
- The property subscribedNsSrgList is an array of items referred from a different YAML file and is of type NsSrg, with a minimum of 1 item.

Example snippet: "AdditionalSnssaiData: type: object", "requiredAuthnAuthz: type: boolean", "subscribedUeSliceMbr: $ref: 'TS29571_CommonData.yaml#/components/schemas/SliceMbrRm'", "subscribedNsSrgList: type: array items: $ref: 'TS29571_CommonData.yaml#/components/schemas/NsSrg' minItems: 1"

TDoc C4-231132:

- The table 6.1.6.3.8-1 has an enumeration called Cause that indicates a cause information.

Example snippet: "Table 6.1.6.3.8-1: Enumeration Cause", "The enumeration Cause indicates a cause information."

TDoc C4-231279:

- The API has a property called apiRoot defined in clause 4.4 of 3GPP TS 29.501.
- The security is defined as an empty object and oAuth2ClientCredentials with values nnrf-disc and nf-instances:read-complete-profile.
- The paths contain a GET method for the route /nf-instances that searches a collection of NF Instances.
- The method has a summary, operationId, and tags defined.
- The parameters for the method are not specified in the example snippet.

Example snippet: "description: apiRoot as defined in clause 4.4 of 3GPP TS 29.501", "security: - {} - oAuth2ClientCredentials: - nnrf-disc - oAuth2ClientCredentials: - nnrf-disc - nnrf-disc:nf-instances:read-complete-profile", "paths: /nf-instances: get: summary: Search a collection of NF Instances operationId: SearchNFInstances tags: - NF Instances (Store)"

1. TDoc C4-231197:
- Defines a data type object called MutingNotificationsSettings with two properties, maxNoOfNotif and durationBufferedNotif.
- Includes a data type called ExtSnssai combining two other data types, Snssai and SnssaiExtension.
- Describes the exclusivity of sdRanges and wildcardSd attributes in ExtSnssai.
- Contains changes made during the 3GPP TSG-CT WG4 Meeting #115e on April 17th-21st, 2023.

2. TDoc C4-231199:
- Specifies procedures related to DDN failure status notification, PDU session modification, and mobility using N26 interface.
- Defines a type called HsmfUpdateData in Table 6.1.6.2.11-1.
- Includes changes made during an unspecified event.

3. TDoc C4-231256:
- Contains an array of Dnai data types.
- Specifies query parameters called pdu-session-types, event-id-list, and nwdaf-event-list, each referencing another data type.
- Describes the features of supportedFeatures attribute used by Nnrf_NFDiscovery service.

4. TDoc C4-231377:
- Defines a data type object called MutingNotificationsSettings with two properties, maxNoOfNotif and durationBufferedNotif.
- Includes a data type called ExtSnssai combining two other data types, Snssai and SnssaiExtension.
- Describes the exclusivity of sdRanges and wildcardSd attributes in ExtSnssai.
- Contains changes made during an unspecified time period.

Example snippets:
- "Indicates the Event producer NF settings to the Event consumer NF" (TDoc C4-231197)
- "allOf: - $ref: '#/components/schemas/Snssai' - $ref: '#/components/schemas/SnssaiExtension'" (TDoc C4-231197)
- "Specifies procedures related to DDN failure status notification, PDU session modification, and mobility using N26 interface" (TDoc C4-231199)
- "Contains an array of Dnai data types" (TDoc C4-231256)
- "Defines a data type object called MutingNotificationsSettings with two properties, maxNoOfNotif and durationBufferedNotif" (TDoc C4-231377)

3GPP-C4-115-e    Agenda Item 6.2.17 : Generic group management, exposure and communication enhancements [GMEC]

3GPP-C4-115-e    Agenda Item 6.2.18 : CT aspects of Next Generation Real time Communication services [NG_RTC]

Technical Differences:

1. TDoc C4-231216 includes a section on Overview, while TDoc C4-231217 includes a section on Services offered by IMS AS.
- Example from TDoc C4-231216: "4 Overview"
- Example from TDoc C4-231217: "5 Services offered by the"

2. TDoc C4-231216 includes a section on Conclusions, while TDoc C4-231217 does not have this section.
- Example from TDoc C4-231216: "Conclusions "
- Example from TDoc C4-231217: N/A

3. TDoc C4-231216 has the title "Pseudo-CR on Overview", while TDoc C4-231217 has the title "Pseudo-CR on Services offered by IMS AS".
- Example from TDoc C4-231216: "Title: Pseudo-CR on Overview"
- Example from TDoc C4-231217: "Title: Pseudo-CR on Services offered by IMS AS"

4. TDoc C4-231216 is for Agenda item 6.2.18, while TDoc C4-231217 is also for Agenda item 6.2.18.
- Example from TDoc C4-231216: "Agenda item: 6.2.18"
- Example from TDoc C4-231217: "Agenda item: 6.2.18"

Example from TDoc C4-231216 to support the difference highlighting:
- "4 Overview": This section is included in TDoc C4-231216 and not in TDoc C4-231217, indicating a difference in the content covered by the two documents.

Example from TDoc C4-231217 to support the difference highlighting:
- "5 Services offered by the": This section is included in TDoc C4-231217 and not in TDoc C4-231216, indicating a difference in the content covered by the two documents.

- TDoc C4-231214 focuses on various technical specifications related to the 5G system, including principles and guidelines for service definition, technical realization of service-based architecture, security architecture and procedures, system architecture, procedures, and network function repository services.
- TDoc C4-231215 deals with the definitions, symbols, and abbreviations used in the technical specifications. It specifies that any definitions, symbols, or abbreviations defined in the present document take precedence over those in 3GPP TR 21.905.
- TDoc C4-231301 specifies the stage 3 protocol and data model for the Service Based Interface and references various technical specifications related to the 5G system.
- 3GPP TS 29.501 focuses on the principles and guidelines for service definition in the 5G system and provides details on service requirements, service capabilities, and service authorization.
- 3GPP TS 29.500 deals with the technical realization of service-based architecture and provides details on the service-based architecture, functional architecture, and service-based interfaces.
- 3GPP TS 33.501 specifies the security architecture and procedures for the 5G system, including security services, security mechanisms, and security protocols.
- 3GPP TS 23.501 specifies the system architecture for the 5G system and provides details on the overall architecture, network functions, and network slicing.
- 3GPP TS 23.502 specifies the procedures for the 5G system, including mobility management, session management, and QoS management.
- 3GPP TS 29.510 specifies the network function repository services for the 5G system and provides details on the functions and interfaces of the repository.
- 3GPP TR 21.900 deals with the technical specification group working methods and provides guidelines for the development and maintenance of technical specifications.
- 3GPP TR 21.905 provides a vocabulary for 3GPP specifications and defines terms, symbols, and abbreviations used in the specifications.
- IETF RFC 8259 specifies the JSON data interchange format and provides guidelines for the syntax and semantics of JSON data.

Example snippet from TDoc C4-231215: "An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 3GPP TR 21.905."

Example snippet from TDoc C4-231301: "The present document specifies the stage 3 protocol and data model for the Service Based Interface."

Example snippet from 3GPP TS 29.501: "The service requirements and capabilities are defined in terms of the 5G system functions that they require, and the 5G system functions that they provide."

Example snippet from 3GPP TS 23.501: "The 5G system architecture provides a flexible and scalable architecture to support diverse use cases and service requirements."

Example snippet from IETF RFC 8259: "JSON is a text format that is completely language independent but uses conventions that are familiar to programmers of the C family of languages."

• TDoc C4-231218: Pseudo-CR on Service operation of Nimsas_SessionEventControl service
- This TDoc focuses on the service operation of the Nimsas_SessionEventControl service.
- The reason for change is that the service operation was needed.
- Example snippet from the TDoc: "Service operation of Nimsas_SessionEventControl service needed."

• TDoc C4-231219: Pseudo-CR on Service operation of Nimsas_MediaControl service
- This TDoc focuses on the service operation of the Nimsas_MediaControl service.
- The reason for change is that the service operation was needed.
- Example snippet from the TDoc: "Service operation of Nimsas_MediaControl service needed."

• TDoc C4-231224: Pseudo-CR on API definition of Nimsas_SessionEventControl Service
- This TDoc focuses on the API definition of the Nimsas_SessionEventControl Service.
- The reason for change is that the API definition was needed.
- Example snippet from the TDoc: "API definition of Nimsas_SessionEventControl Service needed."

• TDoc C4-231225: Pseudo-CR on API definition of Nimsas_MediaControl Service
- This TDoc focuses on the API definition of the Nimsas_MediaControl Service.
- The reason for change is that the API definition was needed.
- Example snippet from the TDoc: "API definition of Nimsas_MediaControl Service needed."

1. TDoc C4-231212 specifies stage 3 protocol and data model for the NNF Service Based Interface.
- Example: "The present document specifies the stage 3 protocol and data model for the Service Based Interface."

2. The resource URI variables for a specific resource are defined in Table 6.1.3.2.2-1.
- Example: "Table 6.1.3.2.2-1: Resource URI variables for this resource."

3. Standard methods supported by a resource are specified in the document.
- Example: "The following clauses will specify the standard methods supported by the resource."

4. Custom operations without associated resources are defined in Table 6.1.4.1-1.
- Example: "Table 6.1.4.1-1: Custom operations without associated resources."

5. Authorization is possible through the OAuth2 protocol.
- Example: "the access to the API may be authorized by means of the OAuth2 protocol (see IETF RFC 6749 [9]), based on local configuration, using the 'Client Credentials' authorization grant."

6. The document may be modified and re-released with an increase in version number.
- Example: "Should the TSG modify the contents of the present document, it will be re-released by the TSG with an identifying change of release date and an increase in version number."

7. The encoding and MIME media type for HTTP requests/responses are defined in a specific clause.
- Example: "6.1.2.2.2 Content type This clause will indicate the encoding of HTTP requests/responses and the applicable MIME media type for the related Content-Type header."

8. "Cardinality" defines the allowed number of occurrences for a specific data type.
- Example: ""Cardinality": Defines the allowed number of occurrence of data type ."

9. TDoc C4-231300 specifies stage 3 protocol and data model for the NNF Service Based Interface.
- Example: "The present document specifies the stage 3 protocol and data model for the Service Based Interface."

10. Application errors for a specific API service are defined in Table 6.1.7.3-1.
- Example: "The application errors defined for the service are listed in Table 6.1.7.3-1."

3GPP-C4-115-e    Agenda Item 6.2.19 : CT Aspect of Further Architecture Enhancement for UAV and UAM Ph2 [UAS_Ph2]

3GPP-C4-115-e    Agenda Item 6.2.21 : CT aspects of System Support for AI/ML-based Services [AIMLsys]

3GPP-C4-115-e    Agenda Item 6.2.22 : CT aspects of Personal IoT Network [PIN]

3GPP-C4-115-e    Agenda Item 6.2.23 : CT aspects of enhancement of 5G UE Policy [eUEPO]

3GPP-C4-115-e    Agenda Item 6.2.24 : CT aspects of Architecture Enhancements for Vehicle Mounted Relays [VMR]

3GPP-C4-115-e    Agenda Item 6.2.25 : CT aspects on 5G AM Policy [AMP]

3GPP-C4-115-e    Agenda Item 6.2.26 : Architecture Enhancements for XR and media services [XRM]

[TDoc C4-231078]:
- Port Number field present if creation of UDP/IP header requested
- TEID field present if creation of GTP-U header requested
- IPv6 Address field present if creation of IPv6 header requested
- IPv4 Address field present if creation of IPv4 header requested
- S-TAG field present if setting of S-Tag in Ethernet packet requested
- Outer Header Creation Description field encoded as specified in Table 8.2.56-1

[TDoc C4-231079]:
- Extension header length defined in variable length of 4 octets
- Bits 7 and 8 of Next Extension Header Type have specific meanings
- Endpoint Receiver is ultimate receiver of GTP-PDU
- Recipient of extension header of unknown type but marked as 'comprehension not required' shall read Next Extension Header Type field
- Extension Header Length field specifies length of particular Extension header in 4 octets units
- Next Extension Header Type field specifies type of any Extension Header that may follow
- Figure 5.2.1-1 and 5.2.1-2 provide outlines and definitions

[TDoc C4-231080]:
- TEID field present if creation of GTP-U header requested
- IPv6 Address field present if creation of IPv6 header requested
- IPv4 Address field present if creation of IPv4 header requested
- Port Number field present if creation of UDP/IP header requested
- When present, destination Customer-VLAN tag or IPv6 address included

[TDoc C4-231081]:
- Extension header length defined in variable length of 4 octets
- Bits 7 and 8 of Next Extension Header Type have specific meanings
- Endpoint Receiver is ultimate receiver of GTP-PDU
- Recipient of extension header of unknown type but marked as 'comprehension not required' shall read Next Extension Header Type field
- Extension Header Length field specifies length of particular Extension header in 4 octets units
- Next Extension Header Type field specifies type of any Extension Header that may follow
- Figure 5.2.1-1 and 5.2.1-2 provide outlines and definitions

[TDoc C4-231110]:
- Create QER grouped IE encoded as shown in Figure 7.5.2.5-1
- Create SRR grouped IE encoded as shown in Figure 7.5.2.9-1
- Session Report grouped IE encoded as shown in Table 7.5.8.6-1
- UP Function Features IE takes form of bitmask where each bit set indicates that corresponding feature is supported
- PFCP IE type values specified in Table 8.1.2-1
- Access Availability Control Information IE encoded as shown in Table 7.5.2.9-2
- QoS Monitoring per QoS flow Control Information IE encoded as shown in Table 7.5.2.9-3

The original TDoc snippets that support these differences include:

- Table 8.2.56-1 (TDoc C4-231078)
- Figure 5.2.1-1, 5.2.1-2, and 5.2.1-3 (TDoc C4-231079 and TDoc C4-231081)
- Figure 7.5.2.5-1, 7.5.2.9-1, and Table 7.5.8.6-1 (TDoc C4-231110)
- Table 8.1.2-1, Table 7.5.2.9-2, and Table 7.5.2.9-3 (TDoc C4-231110)

1. TDoc C4-231082 focuses on the creation of a Forwarding Action Rule (FAR) Information Element (IE) within PFCP Session Establishment Request, while TDoc C4-231258 deals with data types such as ArpRm, AmbrRm, PreemptionCapabilityRm, and SliceMbr.
- Example from TDoc C4-231082: "7.5.2.3 Create FAR IE within PFCP Session Establishment Request"
- Example from TDoc C4-231258: "ArpRm: anyOf: - $ref: '#/components/schemas/Arp'"
2. Table 7.5.2.3-2 in TDoc C4-231082 introduces the Forwarding Parameters IE in FAR, while Table 7.5.3.1-1 in TDoc C4-231258 defines the provisions that shall be followed.
- Example from TDoc C4-231082: "Table 7.5.2.3-2: Forwarding Parameters IE in FAR"
- Example from TDoc C4-231258: "It shall comply with the provisions defined in table 5.5.3.1-1."
3. TDoc C4-231082 has a specific table (Table 7.5.2.3-5) for MBS Multicast Parameters IE in the Create FAR IE, while it has another table (Table 7.5.2.3-6) for adding MBS Unicast Parameters IE in the same location.
- Example from TDoc C4-231082: "Table 7.5.2.3-5: MBS Multicast Parameters IE in the Create FAR IE" and "Table 7.5.2.3-6: Add MBS Unicast Parameters IE in the Create FAR IE"
4. TDoc C4-231258 defines the data types ArpRm, AmbrRm, PreemptionCapabilityRm, and SliceMbr with the OpenAPI 'nullable: true' property.
- Example from TDoc C4-231258: "ArpRm: anyOf: - $ref: '#/components/schemas/Arp' - $ref: '#/components/schemas/NullValue' description: > This data type is defined in the same way as the 'Arp' data type, but with the OpenAPI 'nullable: true' property."
5. TDoc C4-231082 includes a specific encoding for the Create FAR grouped IE, as shown in Figure 7.5.2.3-1.
- Example from TDoc C4-231082: "The Create FAR grouped IE shall be encoded as shown in Figure 7.5.2.3-1."

TDoc C4-231226:

- Measurement Period IE can be used for generating periodic usage reports or periodic QoS monitoring reports, or for detecting and reporting a QoS monitoring measurement failure.
- SRRs can be provisioned for a PFCP session in a PFCP Session Establishment Request or a PFCP Session Modification Request to request the UP function to detect and report events for a PFCP session.
- Change of 3GPP or non-3GPP access availability for an MA PDU session can be detected.

TDoc C4-231227:

- The number of fixed octets and whether an IE is extendable, variable-length or fixed-length are specified in a table.
- To be forward compatible, all PFCP IEs should be TLV coded.

TDoc C4-231228:

- The Port Number field shall be present if the Outer Header Creation Description requests the creation of a UDP/IP header.
- The TEID field shall be present if the Outer Header Creation Description requests the creation of a GTP-U header.
- The IPv6 Address field shall be present if the Outer Header Creation Description requests the creation of an IPv6 header.
- The IPv4 Address field shall be present if the Outer Header Creation Description requests the creation of an IPv4 header.
- The S-TAG field shall be present if the Outer Header Creation Description requests the setting of the S-Tag in Ethernet packet.

TDoc C4-231229:

- The Port Number field shall be present if the Outer Header Creation Description requests the creation of a UDP/IP header.
- The TEID field shall be present if the Outer Header Creation Description requests the creation of a GTP-U header.
- The IPv6 Address field shall be present if the Outer Header Creation Description requests the creation of an IPv6 header.
- The IPv4 Address field shall be present if the Outer Header Creation Description requests the creation of an IPv4 header.
- The S-TAG field shall be present if the Outer Header Creation Description requests the setting of the S-Tag in Ethernet packet.

Examples from TDoc C4-231226:

- "Change of 3GPP or non-3GPP access availability for an MA PDU session (see clause 5.20.4.2)."
- "PFCP IE type values are specified in Table 8.1.2-1."
- "Bit 3 was allocated in earlier versions of the specification but its usage has been deprecated."
- "Spare, for future use and set to '0'."

Examples from TDoc C4-231227:

- "Fixed Length: the IE has a fixed set of fields, and a fixed number of octets;"
- "Variable Length: the IE has a fixed set of fields, and has a variable number of octets."
- "Extendable: the IE has a variable number of fields, and has a variable number of octets."

Examples from TDoc C4-231228:

- "The Port Number field shall be present if the Outer Header Creation Description requests the creation of a UDP/IP header, i.e. if in Octet 5 any of the bits 5/3 and 5/4 are set."
- "The TEID field shall be present if the Outer Header Creation Description requests the creation of a GTP-U header, i.e. if in Octet 5 any of the bits 5/1 and 5/2 are set."
- "The IPv6 Address field shall be present if the Outer Header Creation Description requests the creation of an IPv6 header, i.e. if in Octet 5 any of the bits 5/2, 5/4 and 5/6 are set."
- "The IPv4 Address field shall be present if the Outer Header Creation Description requests the creation of an IPv4 header, i.e. if in Octet 5 any of the bits 5/1, 5/3 and 5/5 are set."
- "The S-TAG field shall be present if the Outer Header Creation Description requests the setting of the S-Tag in Ethernet packet."

Examples from TDoc C4-231229:

- "The Port Number field shall be present if the Outer Header Creation Description requests the creation of a UDP/IP header, i.e. if in Octet 5 any of the bits 5/3 and 5/4 are set."
- "The TEID field shall be present if the Outer Header Creation Description requests the creation of a GTP-U header, i.e. if in Octet 5 any of the bits 5/1 and 5/2 are set."
- "The IPv6 Address field shall be present if the Outer Header Creation Description requests the creation of an IPv6 header, i.e. if in Octet 5 any of the bits 5/2, 5/4 and 5/6 are set."
- "The IPv4 Address field shall be present if the Outer Header Creation Description requests the creation of an IPv4 header, i.e. if in Octet 5 any of the bits 5/1, 5/3 and 5/5 are set."
- "The S-TAG field shall be present if the Outer Header Creation Description requests the setting of the S-Tag in Ethernet packet."

3GPP-C4-115-e    Agenda Item 6.3.1 : eNPN [eNPN, TEI18]

3GPP-C4-115-e    Agenda Item 6.3.2 : eNetAE [eNetAE]

3GPP-C4-115-e    Agenda Item 6.3.3 : SMS_SBI [SMS_SBI, TEI18]

3GPP-C4-115-e    Agenda Item 6.3.4 : Vertical_LAN [Vertical_LAN, TEI18]

3GPP-C4-115-e    Agenda Item 6.3.5 : eV2XARC [eV2XARC, TEI18]

3GPP-C4-115-e    Agenda Item 6.3.6 : MINT [MINT, TEI18]

3GPP-C4-115-e    Agenda Item 6.3.7 : Port number allocation [PortAl, TEI18]

3GPP-C4-115-e    Agenda Item 6.3.8 : Diamenter [TEI18]

3GPP-C4-115-e    Agenda Item 6.3.9 : AMF [TEI18]

3GPP-C4-115-e    Agenda Item 6.3.10 : GTP [TEI18]

3GPP-C4-115-e    Agenda Item 6.3.12 : MBS [TEI18]

3GPP-C4-115-e    Agenda Item 6.3.13 : PFCP [TEI18]