Apex Standards 3GPP Meeting Tracker

---

updated as of Mon, Apr 17, 2023, 09:50 PM UTC (3 hours ago)
Mon, Apr 17, 02:50 PM California
Mon, Apr 17, 11:50 PM Berlin/Paris
Tue, Apr 18, 05:50 AM Beijing

3GPP-C3-127-e    Agenda Item 2.1 : Approval of the agenda.

3GPP-C3-127-e    Agenda Item 2.2 : Proposed schedule

3GPP-C3-127-e    Agenda Item 3 : Registration of documents

3GPP-C3-127-e    Agenda Item 4.1 : Report from previous CT3 meeting

3GPP-C3-127-e    Agenda Item 4.2 : Report from previous CT plenary

3GPP-C3-127-e    Agenda Item 6 : Received Liaison Statements

[TDoc C3-231018]:

- Specification rapporteurs are responsible for checking whether any IANA action is required and communicating the request for IANA action to the CT chair, acting as IETF/IANA liaison.
- IANA assignment requests for new UDP/TCP port numbers must be strongly justified.
- The TR 29.941 should be used to check whether there could be an alternative to IANA port assignment.
- Specification rapporteurs in 3GPP WGs are asked to review their specification to check if any IANA action is required.
- A tool to efficiently track any pending IANA action request should be provided.

[TDoc C3-231019]:

- A new API is required for the anonymization case to provide security control.
- The Naanf_AKMA_ApplicationKey_Get service operation can also be used for this purpose by including "Input, Optional: UEID not needed indication".
- CT WG3 is asked to take the feedback into account.

[TDoc C3-231020]:

- Release 18 will support location event reporting over a user plane connection by a UE to an LCS Client or AF for a deferred periodic or triggered 5GC-MT-LR.
- CT1 and CT3 are asked to comment on suitable types of user plane address for an LCS Client or AF and the transport protocols and application level messages that may be suitable to transfer location event reports.

[TDoc C3-231022]:

- SA2 has discussed the control for QoS monitoring while generalizing the stage 2 description in Rel-18 for potential enhancements with additional measurement parameters.
- CT3 and CT4 group are asked to check whether it is possible to remove the option to report “when the PDU Session is released” from Rel-16 onwards and if so, to update their specifications accordingly.
- The control option for QoS monitoring to report “when the PDU Session is released” is not useful and should be removed from Rel-16 onwards. CT3 and CT4 are asked to remove this option also from their specifications.

Example snippet from TDoc C3-231018: "Specification rapporteurs are responsible for checking whether any IANA action is required and, if it is, to communicate the request for IANA action to the CT chair, acting as IETF/IANA liaison."

Example snippet from TDoc C3-231019: "A new API is required for the anonymization case to provide security control."

Example snippet from TDoc C3-231020: "Release 18 will support location event reporting over a user plane connection by a UE to an LCS Client or AF for a deferred periodic or triggered 5GC-MT-LR."

Example snippet from TDoc C3-231022: "CT3 and CT4 group are asked to check whether it is possible to remove the option to report “when the PDU Session is released” from Rel-16 onwards and if so, to update their specifications accordingly."

[TDoc C3-231021]:
- SA6 has elaborated CAPIF stage 2 changes to meet extensibility requirements
- SA6 has agreed to CR0099 (Rel-18) against TS 23.222
- SA6 endorses contribution S6-230291 providing background information for design considerations in SA3 and CT3
- Added requirements [AR-4.11.2-c] and [AR-4.11.2-d] to 23.222 by SA6

[TDoc C3-231024]:
- CT4 understands "optional security" as deployment aspect configured by operator
- OpenAPI constructs used in 3GPP 5G Core API descriptions are in line with official OpenAPI 3.0.x documentation
- CT4 thanks GSMA for LS on research
- OAuth/2.0 authorization procedures described in 3GPP TS 29.500 and 29.501 clause 5.3.16
- OAuth/2.0 mandatory to support by NF Service Consumers and Producers, but optional to deploy by SA3 specifications in 3GPP TS 33.501

[TDoc C3-231028]:
- Energy Saving: optimization of energy efficiency of 5G network entities
- Digital Sobriety: adoption of best practices by service users to save energy in 5G network
- Table identifies all TSGs/WGs initiatives related to Energy Efficiency, Energy Saving, Digital Sobriety
- Proposes 3GPP to design sober, eco-friendly solutions for energy saving in 5G network

[TDoc C3-231029]:
- EAS requests EES to provide AF-specific UE ID in EDGEAPP model of Nnef_UEId_Get service invocation
- EES initiates NEF API and includes EASId as AFId in call to Nnef_UEId_Get service to provide CN-assigned AF-specific UE ID to EAS
- SA6 asks SA2 if specified EDGEAPP model of Nnef_UEId_Get service invocation by EES with EASId as AFId parameter value is acceptable

[TDoc C3-231021] supports technical differences in CAPIF stage 2 changes and extensibility requirements. [TDoc C3-231024] highlights technical differences in OpenAPI constructs, OAuth/2.0 authorization procedures, and support requirements for NF Service Consumers and Producers. [TDoc C3-231028] discusses technical differences in energy saving and digital sobriety initiatives across TSGs/WGs. [TDoc C3-231029] addresses technical differences in the EDGEAPP model of Nnef_UEId_Get service invocation and AF-specific UE ID retrieval.

TDoc C3-231017:
- SA6 is elaborating stage 2 changes to meet extensibility requirements
- CR0096 (Rel-18) against TS 23.222 agreed
- Dates for next TSG SA WG6 meetings provided
Example snippet: "SA6 is further elaborating necessary stage 2 changes to meet the extensibility requirements as indicated in the LS (S6-222714/ MEC(22)000451r6) and agreed the attached CR0096 (Rel-18) against TS 23.222."

TDoc C3-231025:
- CT4 thanks SA2 for LS on Identifier availability for Lawful Interception during Inter-PLMN handover
- Actions for SA2 and SA3-LI to take information into account
- Date for next CT4 meeting provided
Example snippet: "CT4 thanks SA2 for their LS (S2-2302165) on Identifier availability for Lawful Interception during Inter-PLMN handover."

TDoc C3-231026:
- RAN3 thanks CT for LS on Tracking IANA assignment requests
- Actions for CT and CT4 to take information into account and update specifications
- Date for next RAN3 meeting provided
Example snippet: "RAN3 would like to thank CT for the LS on Tracking IANA assignment requests. RAN3 kindly asks CT to take the above information into account. 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 C3-231023:

- SA2 is asking CT1 and CT3 for suitable types of user plane address for an LCS Client or AF, transport protocols and application-level messages for location event reports.
- CT1 needs further discussion on specifying protocol details.

Example snippet: "SA2 Question: 'SA2 asks CT1 and CT3 to comment on suitable types of user plane address for an LCS Client or AF (e.g. such as an IP address and/or FQDN) and the transport protocols and application level messages that may be suitable to transfer location event reports.'"

TDoc C3-231027:

- SA5 is thanking SA2 for LS on CHF Logic Realization.
- SA5 clarifies that CCS should handle both Session Management Spending Limits and access and mobility/UE Spending Limits.
- The same CCS should handle Spending Limits for AM policy and UE Policy of a subscriber, but it is not specified in current specifications.
- How SL policy counters are used is not in scope of SA5.

Example snippet: "SA5 Answer: It should use the same CCS to handle both Session Management Spending Limits and access and mobility/UE Spending Limits, however it is not specified in current specifications."

TDoc C3-231030:

- SA6 has concerns about packet loss in multicast MBS delivery due to AF being unaware of the multicast MBS session state in some cases.
- Late CONNECTED UEs will lose the packet as the NG-RAN will start to transmit the packet when the first UE becomes CONNECTED which triggers the shared delivery restoring again.
- During the silent period without DL media, the multicast MBS session used for this group communication might become inactive and the joined UEs become IDLE.
- The suitable types of user plane address for an LCS client or AF that can be used are IP address(es) (IPv4 and/or IPv6) and/or FQDN.

Example snippet: "In SA6 there were concerns that packet loss could happen in multicast MBS delivery due to AF being not aware of the multicast MBS session state in some cases..."

TDoc C3-231369:

- CT3 answers SA2's question on suitable types of user plane address for an LCS client or AF.
- The suitable types of user plane address for an LCS client or AF that can be used are IP address(es) (IPv4 and/or IPv6) and/or FQDN.

Example snippet: "CT3 Answer: The suitable types of user plane address for an LCS client or AF that can be used are IP address(es) (IPv4 and/or IPv6) and/or FQDN."

3GPP-C3-127-e    Agenda Item 18.1.1 : New Work Items

3GPP-C3-127-e    Agenda Item 18.1.2 : Revised Work Items

TDoc C3-231077:

- Objective: to specify technical enhancements and changes to 3GPP Northbound and Application Layer interfaces and APIs.
- Mainly includes: consolidation of common protocol aspects, protocol and interface enhancements and optimizations, corrections and/or changes missed in previous releases not covered by other work items.
- Expected output: specification of updated interfaces and APIs.
- Work item rapporteur(s): not specified.
- Example snippet: "3GPP application layer interfaces and APIs (e.g. ProSe PC2 reference point defined in 3GPP TS 29.343, UAE Server APIs defined in 3GPP TS 29.257, EDGEAPP APIs defined in 3GPP TS 29.558, etc.) are also specified in 3GPP to enable the support and exposure of application layer frameworks/services and their interactions with the 3GPP network services."

TDoc C3-231078:

- Expected work for CT3: define APIs for SEAL data delivery management, potentially enhance APIs provided by SEAL servers, enhance MSGin5G service to use SEAL data delivery management, enhance support for SEALDD server with transport layer service continuity capability.
- Expected output: updated APIs for SEAL data delivery management and support for SEALDD server.
- Work item rapporteur(s): not specified.
- Example snippet: "The related SA WG6 study item on SEAL data delivery enabler for vertical applications (FS_SEALDD) is captured in TR 23.700-34."

Overall differences:

- TDoc C3-231077 focuses on specifying technical enhancements and changes to 3GPP Northbound and Application Layer interfaces and APIs, which are not covered by other dedicated work items.
- TDoc C3-231078 focuses on defining and potentially enhancing APIs for SEAL data delivery management and supporting the SEALDD server with transport layer service continuity capability.
- TDoc C3-231077 does not specify CT3 as a specific area of work, while TDoc C3-231078 specifically mentions CT3.
- The expected output and time scale are not specified in TDoc C3-231078, while they are specified in TDoc C3-231077.

[TDoc C3-231079]:
- CT4 focuses on Stage 3 support for Multicast MBS data reception in RRC Inactive state.
- MBS Assistance Information definition and provision from AF to UDM via NEF.
- Updates for coexistence of UE power saving functions.
- Definition of Associated Session ID and encoding for 5MBS MOCN Network Sharing.

[TDoc C3-231098]:
- Provisioning of DetNet configuration from DetNet controller to 5GS.
- Potential extension of flow description in PCF.
- Updates to PCC procedures for provisioning of DetNet configuration.
- 5GS DetNet node reporting and updates to PCC procedures and API impacts.

[TDoc C3-231176]:
- Stage 3 for EDGE-1, EDGE-4 reference points and usage of SEAL services.
- Unique identifier: 980035.
- Work item is a building block for enabling edge applications based on normative stage 2 specifications from 3GPP SA6 WG.

[TDoc C3-231192]:
- Enhancements to V2X application enabler (VAE) layer protocol for V5-AE and V1-AE.
- Enhancements to SEAL layer protocols for supporting advanced V2X services.
- Deployment of V2X application layer with edge enabler layer.

Examples from TDoc C3-231079:
- "MBS Assistance Information should be part of the MBS subscription data in UDM."
- "Retrieval of MBS Assistance Information from UDM by SMF."
- "Updates for coexistence of the UE power saving functions (e.g. MICO, eDRX)."

Examples from TDoc C3-231098:
- "Potential extension of the flow description (PCF) to include the IPv6 flow label and IPsec SPI."
- "Updates of the PCC procedures and/or API impacts to cover the report of 5GS DetNet node information (procedure and parameters)."

Examples from TDoc C3-231176:
- "Stage 3 for EDGE-1, EDGE-4 reference points; Usage of SEAL services (e.g. Notification Management Service)."

Examples from TDoc C3-231192:
- "Support for DRX configurations for V2P communications."
- "Enhanced network monitoring to support advanced V2X services."

[TDoc C3-231081]:

- Updates to the URSP TD component type connection capabilities to enhance the support for standardized and operator defined traffic categories.
- Potential update to the NEF and UDR to support VPLMN specific service parameter provisioning for URSP guidance.

[TDoc C3-231082]:

- Potential updates to the Nnef_TrafficInluence Service to support the new SFC policy ID corresponding to a pre-defined Service Function Chain policy and optional metadata.
- Potential updates to the UPF to support optional metadata included in the FAR.

[TDoc C3-231102]:

- Impacts to cover the UE access to an SNPN within the list of equivalent SNPNs.
- Possible impacts on AMF communication service.
- Enhancements of automatic network selection of a hosting network.
- CP-SOR enhancements for enabling automatic network selection of a hosting network.

[TDoc C3-231140]:

- Potential configuration of the wait range upon return to coverage.
- Potential configuration of the parameters related to power saving during out-of-coverage period.
- Provisioning of coverage availability information in the AF.
- Updates to NEF exposure procedure for provisioning satellite coverage availability information from the AF.

CT3 objectives:

- To update relevant CT3 specifications to support the stage 2 requirements.

CT6 objectives:

- To update relevant CT6 specifications to support the stage 2 requirements for handling of signalling overload and for UE power savings due to DC.

Example snippets from TDoc C3-231081 to support the difference highlighting:

- "Updates to the URSP TD component type connection capabilities to enhance the support for standardized and operator defined traffic categories."
- "Potential update to the NEF and UDR to support VPLMN specific service parameter provisioning for URSP guidance."

Example snippets from TDoc C3-231082 to support the difference highlighting:

- "Potential updates to the Nnef_TrafficInluence Service to support the new SFC policy ID corresponding to a pre-defined Service Function Chain policy and optional metadata."
- "Potential updates to the UPF to support optional metadata included in the FAR."

Example snippets from TDoc C3-231102 to support the difference highlighting:

- "Impacts to cover the UE access to an SNPN within the list of equivalent SNPNs."
- "Possible impacts on AMF communication service."
- "Enhancements of automatic network selection of a hosting network."
- "CP-SOR enhancements for enabling automatic network selection of a hosting network."

Example snippets from TDoc C3-231140 to support the difference highlighting:

- "Potential configuration of the wait range upon return to coverage."
- "Potential configuration of the parameters related to power saving during out-of-coverage period."
- "Provisioning of coverage availability information in the AF."
- "Updates to NEF exposure procedure for provisioning satellite coverage availability information from the AF."

TDoc C3-231292:

- Specifies technical improvements and enhancements to network data analytics related services in Release 18 stage 3 level not covered by other work items.
- Includes corrections and/or updates to network data analytics related services missed in previous 3GPP releases.
- Clarifies attributes which are not applicable or should be ignored in data types reused by DCCF during data collection and analytics exposure procedures.
- Example snippet: "There is a need to apply technical improvements and enhancements in Release 18 (e.g. complete the missing non-critical requirements, enhancement in stage 3 level, etc.) to these network data analytics related services, as such enhancements may not be covered by the other dedicated work items."

TDoc C3-231370:

- Specifies technical improvements and enhancements to network data analytics related services in Release 18 stage 3 level not covered by other work items.
- Includes corrections and/or updates to network data analytics related services missed in previous 3GPP releases.
- Provides justification for the importance of network data analytics related services.
- Example snippet: "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."

3GPP-C3-127-e    Agenda Item 18.2 : Enhancements of 3GPP Northbound and Application Layer interfaces and APIs Rel-18 [NBI18]

TDoc C3-231069:

- ToS/TC is used for service data flow detection, requiring proper management to avoid collision with other usage.
- Type AsSessionWithQoSSubscription represents AS session request with specific QoS for service provided by SCS/AS to SCEF via T8 interface.
- FlowInfo type represents flow information and includes the possibility of including "tosTC" attribute for packet filter differentiation.

Example from TDoc: "To use ToS/TC for service data flow detection, network configuration by the operator (and additionally by the 3rd party Service Provider when the transport network is not fully within the operator control) needs to ensure there is no ToS/TC re-marking applied along the path from the application to the PSA UPF."

TDoc C3-231070:

- Contains a reused API applicable for both EPS and 5GS.
- Describes northbound APIs applicable for both systems.

Example from TDoc: "This clause describes the northbound APIs which are applicable for both EPS and 5GS."

TDoc C3-231199:

- Proposes creating a new TS skeleton dedicated to defining NBI APIs.
- Allows for similar outlines and referencing of the same template for NBI TSs.
- Proposed location for the new TS skeleton is in the same location as the existing SBI TS skeleton.

Example from TDoc: "With the ongoing and expected introduction of more NBI APIs (especially application layer APIs) in Rel-18 and the following releases, it is becoming more critical to have a TS skeleton dedicated for NBI APIs in order to allow the following improvements."

1. The first TDoc (C3-231201) defines an API with a "supportedFeatures" and a "shareableInfo" component, which are referenced from external schemas. The API also has a "serviceAPICategory" field and a "ccfId" field with a list of possible values.
- Example snippet: "supportedFeatures: $ref: 'TS29571_CommonData.yaml#/components/schemas/SupportedFeatures'"
2. The second TDoc (C3-231202) defines an EASRegistration schema with an "easProf" field, a "suppFeat" field, and a "transContSupp" field that is another referenced external schema. The responses include a "201" response with a description of a successful registration.
- Example snippet: "responses: '201': description: EAS information is registered successfully at EES."
3. The third TDoc (C3-231410) defines a ConfigurationNotification object with a "supportedFeatures" field and a "mtcProviderId" field that is nullable. It also includes a "ConfigurationResult" array with a minimum of one "ConfigResult" object and a "validityTime" field.
- Example snippet: "configResults: type: array items: $ref: 'TS29122_CommonData.yaml#/components/schemas/ConfigResult' minItems: 1 description: The grouping configuration result notification provided by the SCEF."

[TDoc C3-231254]:

- Verification of VAL server identity and authorization to modify VAL group information
- Verification of valGroupId in HTTP PUT request message
- Updating/modifying group document with valid group configuration information
- Invoking 5GLANParameterProvision API for 5G LAN-Type communication

[TDoc C3-231255]:

- Classification of SEAL APIs into two categories: APIs type 1 and APIs type 2
- Type-dependant application errors limitations for APIs type 2
- Multiple target identifier types for APIs type 2 (VAL User IDs, VAL services, and external group identifier)

[TDoc C3-231411]:

- Response to AF with "404 Not Found" status code and ProblemDetails data structure for UE_NOT_FOUND application error when no SUPI matching provided UE information is returned by BSF
- Interaction with UDM to retrieve AF specific UE Identifier using received SUPI and application information
- Response to AF with received information or proper error status code

[TDoc C3-231415]:

- Inclusion of alternative individual QoS related parameter(s) and at least one of guaranteed bandwidth in uplink/downlink, requested packet delay budget, or requested packet error rate in AlternativeServiceRequirementsData data structure
- Provisioning of QoS requirements and subscription with TSCTSF to QOS_GUARANTEED and QOS_NOT_GUARANTEED events if NEF authorizes AF request and TSC_5G feature is supported
- Notification of AF with QOS_GUARANTEED event or QOS_NOT_GUARANTEED event and currently applied QoS reference if received

Example snippet from TDoc C3-231254: "if the group document information in the request includes 5G LAN-Type communication, invoke the 5GLANParameterProvision API towards the NEF via an HTTP PUT/PATCH message as defined in clause 4.4.15.3 of 3GPP TS 29.522"

Example snippet from TDoc C3-231255: "SEAL APIs that operate with multiple target identifier types ('APIs type 2' for short), e.g., the VALGroupDocument data type in the SS_GroupManagement API allows creating a VAL group based on the list of VAL User IDs, list of VAL services, and/or the external group identifier."

Example snippet from TDoc C3-231411: "If no SUPI matching the provided UE information is returned by the BSF, the NEF shall respond to the AF with a '404 Not Found' status code with the response body including a ProblemDetails data structure containing the 'cause' attribute set to the 'UE_NOT_FOUND' application error to indicate that the requested UE address is not found."

Example snippet from TDoc C3-231415: "If the NEF authorizes the AF request, and if the 'TSC_5G' feature is supported, the NEF may provision the received QoS requirements and subscribe with the TSCTSF to 'QOS_GUARANTEED' and 'QOS_NOT_GUARANTEED' events by invoking the Ntsctsf_QoSandTSCAssistance_Create request as defined in 3GPP TS 29.565."

Technical Differences among TDocs:

1. TDoc C3-231146:
- Defines Type: TimeSyncExposureConfig
- Includes Table 5.15.4.3.6-1 for the definition of the type

2. TDoc C3-231412:
- Proposed changes without any specific type or table mentioned

3. TDoc C3-231413:
- Proposed changes without any specific type or table mentioned

4. TDoc C3-231414:
- Includes Table 8.9.4.2.2-1 for the definition of type APIProviderEnrolmentDetails
- Defines Type: APIProviderFunctionDetails with Table 8.9.4.2.3-1
- Defines Type: APIInvokerEnrolmentDetails with Table 8.4.4.2.2-1
- Includes Table 8.5.4.2.2-1 for the definition of type ServiceSecurity
- Defines Type: ServiceAPIDescriptionPatch with Table 8.2.4.2.11-1
- Includes Table 8.3.4.2.2-1 for the definition of type EventSubscription

Example Snippets:
- TDoc C3-231146: "Table 5.15.4.3.6-1: Definition of type TimeSyncExposureConfig"
- TDoc C3-231414: "Table 8.9.4.2.2-1: Definition of type APIProviderEnrolmentDetails"
- TDoc C3-231414: "Defines Type: ServiceAPIDescriptionPatch with Table 8.2.4.2.11-1"
- TDoc C3-231414: "Includes Table 8.5.4.2.2-1 for the definition of type ServiceSecurity"
- TDoc C3-231413: "Proposed changes without any specific type or table mentioned"
- TDoc C3-231412: "Proposed changes without any specific type or table mentioned"

3GPP-C3-127-e    Agenda Item 18.3 : Service Based Interface Protocol Improvements Release 18 [SBIProtoc18]

The TDoc contains several examples of different snippets of code, each with its own technical differences. Here are some of the key differences highlighted in the TDoc:

1. Content Type: The code snippets contain references to different content types, such as application/json, application/problem+json, and others.

Example: "content: application/problem+json: schema: $ref: '#/components/schemas/ProblemDetailsTsctsfQosTscac' headers: Retry-After:"

2. Schema References: The code snippets contain references to different schemas, such as DateTime, UeLocationInfo, and ProblemDetailsTsctsfQosTscac.

Example: "type: object properties: ts: $ref: 'TS29122_CommonData.yaml#/components/schemas/DateTime' recurringTime: $ref: 'TS29122_CpProvisioning.yaml#/components/schemas/ScheduledCommunicationTime'"

3. Response Codes: The code snippets contain references to different response codes, such as 307, 308, 400, 401, and others.

Example: "'400': $ref: 'TS29571_CommonData.yaml#/components/responses/400' '401': $ref: 'TS29571_CommonData.yaml#/components/responses/401'"

4. Parameters: The code snippets contain different parameters, such as subscriptionId, duration, locInfo, and others.

Example: "- name: subscriptionId in: path description: > * * [TDoc C3-231129]:"

5. Object Properties: The code snippets contain different object properties, such as upNodeId, timeSyncErrBdgt, and others.

Example: "type: object properties: upNodeId: $ref: 'TS29571_CommonData.yaml#/components/schemas/Uint64' timeSyncErrBdgt: $ref: 'TS29571_CommonData.yaml#/components/schemas/Uinteger'"

6. Summary and Operation ID: The code snippets contain different summaries and operation IDs for the API requests, such as Delete an individual Message Delivery Subscription resource and NnwdafEventsSubscription.

Example: "delete: summary: Delete an individual Message Delivery Subscription resource operationId: DeleteMessageDeliverySubscription"

7. Descriptions: The code snippets contain different descriptions for the objects, such as Represents a UE location information and Notification correlation identifier.

Example: "notifCorrId: type: string description: Notification correlation identifier."

8. Array Items: The code snippets contain references to different array items, such as UeLocationInfo and ProcessingInstruction.

Example: "locInfo: type: array items: $ref: '#/components/schemas/UeLocationInfo' minItems: 1"

9. Required Fields: The code snippets contain different required fields, such as duration, locInfo, and suppFeat.

Example: "type: object properties: upNodeId: $ref: 'TS29571_CommonData.yaml#/components/schemas/Uint64' timeSyncErrBdgt: $ref: 'TS29571_CommonData.yaml#/components/schemas/Uinteger' configNotifId: required: - suppFeat"

10. Content: The code snippets contain different content, such as TscAppSessionContextData and ProblemDetailsTsctsfQosTscac.

Example: "content: application/json: schema: $ref: '#/components/schemas/TscAppSessionContextData'"

In summary, the TDoc contains examples of code snippets with different technical differences such as content types, schema references, response codes, parameters, object properties, descriptions, array items, required fields, and content. These differences are supported by specific examples from the original TDoc.

TDoc C3-231040

- Type PolicyDataChangeNotification is defined in section 5.4.2.11
- Table 5.4.2.11-1 provides the definition of the type PolicyDataChangeNotification
- No additional discussions or changes are mentioned

Example snippet:

Table 5.4.2.11-1: Definition of type PolicyDataChangeNotification

Name | Type | Description
----------------------------------|---------------------------------------------------------|-------------
policyDataChangeNotification | PolicyDataChangeNotification | Indicates that a policy data change occurred.

TDoc C3-231256

- Enumeration DnPerfOrderingCriterion is defined in section 5.1.6.3.25
- Table 5.1.6.3.25-1 provides the definition of the enumeration DnPerfOrderingCriterion
- No additional discussions or changes are mentioned

Example snippet:

Table 5.1.6.3.25-1: Enumeration DnPerfOrderingCriterion

Name | Value | Description
----------------------------------|------------------------------------|-------------
dlThroughput | 0 | Downlink throughput performance.
dlPacketLossRate | 1 | Downlink packet loss rate performance.
dlDeliveryQuality | 2 | Downlink delivery quality performance.
dlAvailability | 3 | Downlink availability performance.
dlLatency | 4 | Downlink latency performance.

Based on the information provided in the TDocs, the technical differences between the two are minimal. Both TDocs define a type or enumeration in their respective sections with accompanying tables providing the definition and values for the type or enumeration. No proposed changes or additional discussions are mentioned for either TDoc.

Technical differences among the following TDoc are as follows:

1. TDoc C3-231086:
- Type: object
- Properties:
- ascReqData: $ref: '#/components/schemas/AppSessionContextUpdateData'
- boolean: Indicates the EAS rediscovery is required.
- maxAllowedUpLat: $ref: 'TS29571_CommonData.yaml#/components/schemas/UintegerRm'
- tfcCorreInfo: $ref: 'TS29522_TrafficInfluence.yaml#/components/schemas/TrafficCorrelationInfo' nullable: true
- AnGwAddress: in: path required: true schema: type: string
- requestBody: description: > Deletion of the Individual Application Session Context resource, req notification. required: false content: application/json: schema: $ref: '#/components/schemas/EventsSubscReqData'
- responses: '200': description: The deletion of the resource is confirmed and a resource is returned.

- Example snippet:
- ascReqData: $ref: '#/components/schemas/AppSessionContextUpdateData'
- AnGwAddress: in: path required: true schema: type: string
- requestBody: description: > Deletion of the Individual Application Session Context resource, req notification. required: false content: application/json: schema: $ref: '#/components/schemas/EventsSubscReqData'

2. TDoc C3-231128:
- TsnPortNumber: $ref: 'TS29571_CommonData.yaml#/components/schemas/Uinteger'
- ApplicationDescriptor: $ref: 'TS29571_CommonData.yaml#/components/schemas/Bytes'
- UePolicyContainer: $ref: 'TS29571_CommonData.yaml#/components/schemas/Bytes'
- FlowDirection: anyOf:
- type: string
- enum:
- DOWNLINK
- UPLINK
- BIDIRECTIONAL
- UNSPECIFIED
- type: string
- gbrUl: $ref: 'TS29571_CommonData.yaml#/components/schemas/BitRateRm'
- gbrDl: $ref: 'TS29571_CommonData.yaml#/components/schemas/BitRateRm'
- arp: $ref: 'TS29571_CommonData.yaml#/components/schemas/Arp'
- qnc: type: boolean description: > Indicates whether notifications are requested from 3GPP NG-RAN when the GFBR can no longer (or again) be guaranteed for a QoS Flow during the lifetime of the QoS Flow.
- Type: object
- Properties:
- condId: type: string description: Uniquely identifies the condition data within a PDU session.

- Example snippet:
- TsnPortNumber: $ref: 'TS29571_CommonData.yaml#/components/schemas/Uinteger'
- FlowDirection: anyOf:
- type: string
- enum:
- DOWNLINK
- UPLINK
- BIDIRECTIONAL
- UNSPECIFIED
- type: string
- qnc: type: boolean description: > Indicates whether notifications are requested from 3GPP NG-RAN when the GFBR can no longer (or again) be guaranteed for a QoS Flow during the lifetime of the QoS Flow.

TDoc C3-231203:
- Type: Object
- Properties: startTime, endTime, ulVol, dlVol
- Required: startTime, endTime, ulVol, dlVol
- This TDoc defines an object with properties for start and end times, as well as uplink and downlink volume. These properties are all required.

TDoc C3-231204:
- Type: Object
- Properties: supi, interGroupId, appId, comms
- Required: comms
- This TDoc defines an object with properties for a subscriber's UE identity, an inter-group ID, an application ID, and an array of communication collections. The comms property is required.

TDoc C3-231206:
- Type: Object
- Properties: expiry
- This TDoc defines an object with a single property, expiry, which is a reference to a DateTime schema. This is likely used to indicate when a subscription or authorization will expire.

TDoc C3-231238:
- Type: Object
- Properties: osId, appIds, self, 5gLanParams, suppFeat
- Required: 5gLanParams, suppFeat
- This TDoc defines an object with properties for identifying the operating system and applications running on a UE, as well as self-referential links, 5G LAN parameters, and supported features. The 5gLanParams and suppFeat properties are required.

Example snippets from the original TDoc:
- In TDoc C3-231203, the ulVol and dlVol properties are references to schemas defined in TS29122_CommonData.yaml and are likely used to represent data usage volumes.
- TDoc C3-231204 defines the comms property as an array of CommunicationCollection objects, which are likely used to represent information about communication events.
- TDoc C3-231206 includes a post request for a NmfafDataRetrievalNotification, which likely triggers the retrieval of data or analytics related to MFAF.
- In TDoc C3-231238, the osId property is a reference to a schema defined in TS29519_Policy_Data.yaml and is likely used to identify the operating system of a UE.

3GPP-C3-127-e    Agenda Item 18.4 : Enhancements of UE Policy Release 18 [UEP18]

3GPP-C3-127-e    Agenda Item 18.6 : Technical Enhancements and Improvements [TEI18]

The technical differences among the TDoc snippets are as follows:

1. TDoc C3-231065:

- Defines UE application data collection per UE.
- Contains Media Streaming QoE metrics and consumption information collected for a UE application via AF.
- Includes UE trajectory information and performance data analytics related information collection.
- Uses schema references from TS29122, TS29571, and TS29517.

Example snippet:

```
MsQoeMetricsCollection:
description: >
Contains the Media Streaming QoE metrics information collected for an UE Application via AF.
type: object
properties:
msQoeMetrics:
type: array
items:
type: string
minItems: 1
required:
- msQoeMetrics
```

2. TDoc C3-231066:

- Defines communication collection for SUPIs within an inter-group ID and an application ID.
- Uses schema references from TS29571 and TS29517.

Example snippet:

```
required:
- comms
type: object
properties:
supi:
$ref: 'TS29571_CommonData.yaml#/components/schemas/Supi'
interGroupId:
$ref: 'TS29571_CommonData.yaml#/components/schemas/GroupId'
appId:
$ref: 'TS29571_CommonData.yaml#/components/schemas/ApplicationId'
comms:
type: array
items:
$ref: 'TS29517_Naf_EventExposure.yaml#/components/schemas/CommunicationCollection'
minItems: 1
```

3. TDoc C3-231152:

- Defines instruction related to the processing of notifications.
- Includes anonymization and formatting rules.
- Uses schema references from TS29571, TS29520, and TS29517.

Example snippet:

```
ProcessingInstruction:
description: Contains instructions related to the processing of notifications.
type: object
required:
- anaSub
- anaNotifUri
- anaNotifCorrId
properties:
anaSub: $ref: 'TS29520_Nnwdaf_EventsSubscription.yaml#/components/schemas/NnwdafEventsSubscription'
anaNotifUri: $ref: 'TS29571_CommonData.yaml#/components/schemas/Uri'
anaNotifCorrId:
type: string
description: Notification correlation identifier.
timeStamp: $ref: 'TS29571_CommonData.yaml#/components/schemas/DateTime'
```

1. "areas" in TDoc C3-231067 is an array that includes the network areas of interest for processed reports, while "timeStamp" refers to the date and time when the notification was created.

2. TDoc C3-231067 includes "minClubbedNotif" and "maxClubbedNotif," which represent the minimum and maximum number of notifications that can be clubbed into a single notification.

3. In TDoc C3-231067, "maxValue" denotes the maximum value of a parameter, while "fetchInstruct" is a reference to the fetch instruction schema in TS29576_Nmfaf_3caDataManagement.yaml.

4. "terminationReq" in TDoc C3-231067 is a boolean value indicating if the data management subscription requested by DCCF should be terminated or not.

5. TDoc C3-231068 includes "procInstruct" which is a reference to ProcessingInstruction schema in TS29574_Ndccf_DataManagement.yaml, while "multiProcInstructs" is an array of ProcessingInstruction schema for sending event notifications.

6. TDoc C3-231068 has a "content" section containing information about the successfully modified resource and its representation.

7. In TDoc C3-231068, "dataNotification" is a reference to DataNotification schema in TS29575_Nadrf_DataManagement.yaml, while "dataReports" is an array of NotifSummaryReport schema in TS29574_Ndccf_DataManagement.yaml.

8. TDoc C3-231298 includes "RankingCriterion" which represents the usage ranking criterion between high, medium, and low usage UE, and "DispersionInfo" which represents the dispersion information.

9. TDoc C3-231298 has a "headers" section containing the URI of the newly created resource and a "snssai" property which is a reference to SNSSAI schema in TS29571_CommonData.yaml.

10. TDoc C3-231299 includes "modelInfo" that contains information identifying the ML model(s) that the consumer NWDAF is currently subscribing for analytics, and "ContextElement" that contains context information corresponding with a specific context identifier.

11. "UE_LOCATION" in TDoc C3-231299 indicates UE location information, and "SERVICE_EXPERIENCE" provides identification of target UE(s) and event-specific filter information for the feature "ServiceExperience."

Technical differences among the listed TDocs include:

- ADRF: Analytics Data Repository Function
- Provides a centralized storage for analytic data
- Supports data collection from multiple sources
- Can be queried for analytic insights
- Example snippet from [TDoc C3-231244]: "The ADRF shall support the storage and retrieval of analytic data, as well as the ability to query analytic data for the purpose of analytic insights."
- AF: Application Function
- Provides application-specific services
- Interfaces with other network functions
- Example snippet from [TDoc C3-231244]: "An AF is a network function that provides application specific services to users and/or other network functions."
- AMF: Access and Mobility Management Function
- Manages user access and mobility in the network
- Interfaces with other network functions
- Example snippet from [TDoc C3-231244]: "The AMF is responsible for access and mobility management of the UE towards the 5G Core Network. It interfaces with other network functions, such as the UDM, the UPF, and the SMF."
- AnLF: Analytics Logical Function
- Provides analytic services
- Interfaces with other network functions
- Example snippet from [TDoc C3-231408]: "AnLF provides analytic services to other network functions, such as the NWDAF, and interfaces with other network functions, such as the UDM and the AMF."
- DCCF: Data Collection Coordination Function
- Coordinates data collection from multiple sources
- Interfaces with other network functions
- Example snippet from [TDoc C3-231244]: "The DCCF provides the capability to coordinate data collection from multiple sources, and interfaces with other network functions, such as the NWDAF and the SMF."
- MFAF: Messaging Framework Adaptor Function
- Adapts messaging between network functions
- Example snippet from [TDoc C3-231244]: "The MFAF provides a framework for adapting messaging between network functions."
- Minimization of Drive Tests (MDT)
- Reduces the need for physical drive tests
- Uses UE data collection
- Example snippet from [TDoc C3-231244]: "The MDT feature is used to reduce the need for physical drive tests by using UE data collection."
- ML: Machine Learning
- Uses algorithms to analyze data and make predictions
- Example snippet from [TDoc C3-231244]: "Machine Learning is used to analyze data and make predictions based on that analysis."
- MTLF: Model Training Logical Function
- Trains machine learning models
- Example snippet from [TDoc C3-231244]: "The MTLF is responsible for training machine learning models, which are then used by the AnLF."
- NEF: Network Exposure Function
- Exposes network data to authorized third parties
- Interfaces with other network functions
- Example snippet from [TDoc C3-231244]: "The NEF is responsible for exposing network data to authorized third parties, and interfaces with other network functions, such as the NRF and the UDM."
- NRF: Network Repository Function
- Provides network function discovery and selection
- Example snippet from [TDoc C3-231408]: "If the NWDAF service consumer needs to discover an NWDAF containing AnLF that is able to collect data from particular data sources identified by their NF Set IDs or NF types, the consumer may query NRF with the Nnrf_NFDiscovery_NFDiscover service operation."
- NSACF: Network Slice Admission Control Function
- Controls network slice admission
- Interfaces with other network functions
- Example snippet from [TDoc C3-231244]: "The NSACF is responsible for network slice admission control and interfaces with other network functions, such as the AMF and the SMF."
- NWDAF: Network Data Analytics Function
- Provides analytic insights
- Interfaces with other network functions
- Example snippet from [TDoc C3-231408]: "The NWDAF is responsible for providing analytic insights to other network functions, such as the AMF, and interfaces with other network functions, such as the AnLF and the NRF."
- PCF: Policy Control Function
- Controls network policies
- Interfaces with other network functions
- Example snippet from [TDoc C3-231244]: "The PCF is responsible for policy control in the 5G Core Network, and interfaces with other network functions, such as the AMF, the SMF, and the UPF."
- SMF: Session Management Function
- Manages user sessions in the network
- Interfaces with other network functions
- Example snippet from [TDoc C3-231244]: "The SMF is responsible for session management in the 5G Core Network, and interfaces with other network functions, such as the AMF, the PCF, and the UPF."
- UDM: Unified Data Management
- Manages user data in the network
- Provides data storage and retrieval
- Example snippet from [TDoc C3-231408]: "The UDM is responsible for unified data management in the 5G Core Network. It provides data storage and retrieval for network functions, such as the AMF, the PCF, and the SMF."

Sources:
- [TDoc C3-231244]
- [TDoc C3-231408]
- [TDoc C3-231409]
- TS 29.510

Technical Differences among TDocs:

- All TDocs have the same type: object
- All TDocs have the same properties: ts, recurringTime, duration, durationVariance, and locInfo
- All TDocs use the same references for ts and recurringTime properties, i.e., 'TS29122_CommonData.yaml#/components/schemas/DateTime' and 'TS29122_CpProvisioning.yaml#/components/schemas/ScheduledCommunicationTime', respectively
- All TDocs use the same reference for duration property, i.e., 'TS29122_CommonData.yaml#/components/schemas/DurationSec'
- All TDocs use the same reference for durationVariance property, i.e., 'TS29571_CommonData.yaml#/components/schemas/Float'
- All TDocs use the same reference for locInfo property items, i.e., '#/components/schemas/UeLocationInfo'
- All TDocs have the same required properties, i.e., duration and locInfo

Example snippets from TDoc C3-231294 to support the difference highlighting:

- The reference for the durationVariance property is 'TS29571_CommonData.yaml#/components/schemas/Float'
- The UeLocationInfo schema is defined as a required array property in the locInfo property
- The UeLocationInfo schema has properties such as anyUeInd, gpsi, and exterGroupId
- The UeMobilityExposure schema is defined with content property that includes schema references for different response codes, i.e., 'TS29520_Nnwdaf_AnalyticsInfo.yaml#/components/schemas/ProblemDetailsAnalyticsInfoRequest', '503', and 'default'
- The securitySchemes section is defined with the oAuth2ClientCredentials type and clientCredentials flow

Example snippets from TDoc C3-231295 to support the difference highlighting:

- No technical difference from TDoc C3-231294

Example snippets from TDoc C3-231296 to support the difference highlighting:

- No technical difference from TDoc C3-231294 and C3-231295

Example snippets from TDoc C3-231297 to support the difference highlighting:

- No technical difference from TDoc C3-231294 to C3-231296

3GPP-C3-127-e    Agenda Item 18.7 : Service Enabler Architecture Layer for Vertical Phase 3 [SEAL_Ph3]

TDoc C3-231223:

- RFC 3925 defines vendor-identifying options for DHCPv4.
- 3GPP TS 23.316 defines wireless and wireline convergence access support for the 5G system.
- RFC 4039 introduces the Rapid Commit option for DHCPv4.
- RFC 3646 defines DNS configuration options for DHCPv6.
- CableLabs DOCSIS MULPI specifies the MAC and Upper Layer Protocols Interface Specification for DOCSIS 3.1.
- 3GPP TS 24.229 specifies the IP Multimedia Call Control Protocol based on SIP and SDP.
- RFC 3736 describes a stateless DHCPv6 service.

TDoc C3-231224:

- 3GPP TS 23.434 defines the Service Enabler Architecture Layer for Verticals (SEAL) functional architecture and information flows.
- 3GPP TS 29.122 specifies the T8 reference point for Northbound APIs.
- 3GPP TS 29.222 defines the Common API Framework for 3GPP Northbound APIs at Stage 3.
- 3GPP TS 29.501 outlines principles and guidelines for service definition in the 5G system.
- 3GPP TS 23.222 defines the Common API Framework for 3GPP Northbound APIs at Stage 2.
- 3GPP TS 29.571 specifies common data types for service-based interfaces in the 5G system.
- 3GPP TS 29.500 defines the technical realization of the service-based architecture in the 5G system.
- RFC 7230 specifies the message syntax and routing for HTTP/1.1.

Example snippets from TDoc C3-231223:

- From RFC 3925: "This document specifies a set of DHCPv4 options that can be used to carry vendor-specific information."
- From 3GPP TS 23.316: "This TS specifies the architecture and procedures to allow wireline and wireless access convergence (WLWA) in the 5G System (5GS)."
- From RFC 4039: "This document specifies a new Dynamic Host Configuration Protocol for IPv4 (DHCPv4) option that allows clients to request rapid allocation of network addresses and configuration information."
- From RFC 3646: "This document specifies a Dynamic Host Configuration Protocol (DHCPv6) option for configuring DNS recursive name servers."
- From CableLabs DOCSIS MULPI: "The MULPI specification defines the interface between the Cable Modem Termination System (CMTS) and the cable modem (CM) for the DOCSIS MAC and upper layer protocols."
- From 3GPP TS 24.229: "This specification defines the stage 3 protocol for the implementation of the IP Multimedia Call Control Protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)."
- From RFC 3736: "This document specifies a stateless DHCPv6 service for use in hosts that do not require or do not support the use of stateful DHCPv6 service."

Example snippets from TDoc C3-231224:

- From 3GPP TS 23.434: "SEAL is a functional architecture that provides a set of APIs and enablers to support the implementation of services in a multi-tenant environment."
- From 3GPP TS 29.122: "This specification defines the reference point T8 for the Northbound APIs that are used to expose 3GPP functionality to external applications."
- From 3GPP TS 29.222: "This specification defines a common API framework for 3GPP Northbound APIs at Stage 3."
- From 3GPP TS 29.501: "This specification outlines the principles and guidelines for the definition of services in the 5G system."
- From 3GPP TS 23.222: "This specification defines the Common API Framework for 3GPP Northbound APIs at Stage 2."
- From 3GPP TS 29.571: "This specification defines common data types for use in service-based interfaces in the 5G system."
- From 3GPP TS 29.500: "This specification defines the technical realization of the service-based architecture in the 5G system."
- From RFC 7230: "This specification describes the syntax and semantics of HTTP/1.1 messages, including request messages and response messages."

TDoc C3-231227:
- Includes an Enumeration section with specific changes highlighted
- Includes a Type section defining NrmEventNotification
- Uses a table to provide the definition of NrmEventNotification

Example from TDoc C3-231227: "7.4.1.4.3.2 Enumeration: Next changes"

TDoc C3-231258:
- Includes a section for proposed changes labeled #127-e
- Includes a reference to an upcoming 3GPP TSG-CT WG3 Meeting
- Does not include any technical details or definitions

Example from TDoc C3-231258: "Proposed changes: #127-e C3-231258 E-Meeting, 17th April – 21st April 2023 3GPP TSG-CT WG3 Meeting"

TDoc C3-231259:
- Includes a section for proposed changes labeled "First Change"
- Includes a reference to an upcoming 3GPP TSG-Meeting
- Does not include any technical details or definitions

Example from TDoc C3-231259: "Proposed changes: 3GPP TSG- Meeting # C3-231259 E-Meeting, April –"

TDoc C3-231225:

- Describes the structure for Resource URIs and resources and methods used for service.
- Contains Table 7.4.1.2.1-1: Resources and methods overview.

TDoc C3-231226:

- Describes the Notification definition Callback URI.
- Contains tables 7.4.1.3.2.2-1 to 7.4.1.3.2.2-5 that specify the URI query parameters, data structures, and headers supported by POST and response codes on this resource.
- Contains Table 7.4.1.3.1-1: Notifications overview.

TDoc C3-231257:

- Lists the SEAL server APIs below the service name.
- Contains Table 5.1-1: List of SEAL Service APIs and Table 5.1-2: API Descriptions.

TDoc C3-231421:

- Contains tables 7.1.1.4.2.2-1 and 7.1.1.4.2.3-1 that define the types LocationReportConfiguration and LocationReportConfigurationPatch respectively.
- Contains Table 7.1.1.6-1: Supported Features.
- Contains Table 7.1.1.4.1-2: SS_LocationReporting API Re-used Data Types.
- Contains proposed changes.

Examples of snippets from the original TDoc to support the difference highlighting are:

- TDoc C3-231226 contains tables 7.4.1.3.2.2-1 to 7.4.1.3.2.2-5 that specify the URI query parameters, data structures, and headers supported by POST and response codes on this resource.
- TDoc C3-231257 contains Table 5.1-1: List of SEAL Service APIs and Table 5.1-2: API Descriptions.
- TDoc C3-231421 contains tables 7.1.1.4.2.2-1 and 7.1.1.4.2.3-1 that define the types LocationReportConfiguration and LocationReportConfigurationPatch respectively.

3GPP-C3-127-e    Agenda Item 18.8 : CT aspects of Enhanced support of Non-Public Networks Phase 2 [eNPN_Ph2]

• The V-PCF must use the Npcf_UEPolicyControl_Update Service Operation defined in clause 4.2.3 to send UE Policy Delivery results to the H-PCF if they relate to UE policy sections provided by the H-PCF. [TDoc C3-231042 and TDoc C3-231420]
• The (H-)PCF determines the applicable V2XP and V2X N2 PC5 policy based on the operator's policy if the UE indicates support for V2X communications over PC5 reference point and if the "V2X" feature is supported. [TDoc C3-231042 and TDoc C3-231420]
• The (H-)PCF determines the applicable ProSeP if the UE indicates support for 5G ProSe and if the "ProSe" feature is supported. [TDoc C3-231042 and TDoc C3-231420]
• The (V-)PCF may subscribe to GUAMI changes using the AMFStatusChange service operation of the Namf_Communication service specified in 3GPP TS 29.518 if it receives a GUAMI. [TDoc C3-231042 and TDoc C3-231420]

For example, TDoc C3-231042 states that the V-PCF shall use the Npcf_UEPolicyControl_Update Service Operation to send UE Policy Delivery results to the H-PCF if they relate to UE policy sections provided by the H-PCF. Additionally, the (H-)PCF determines the V2XP and V2X N2 PC5 policy if the UE supports V2X communications over PC5 reference point and the "V2X" feature is supported. Similarly, the (H-)PCF determines the ProSeP if the UE supports 5G ProSe and the "ProSe" feature is supported. Finally, if the (V-)PCF receives a GUAMI, it may subscribe to GUAMI changes using the AMFStatusChange service operation of the Namf_Communication service specified in 3GPP TS 29.518.

TDoc C3-231420 has the same technical differences and points as TDoc C3-231042.

Technical differences among TDoc C3-231038 and TDoc C3-231419:

1. TDoc C3-231419 introduces a new feature called "ExtendedSamePcf," which is not mentioned in TDoc C3-231038.
- Example from TDoc C3-231419: "when the PCF determines that the same PCF shall be selected for the SM Policy associations to the same UE ID, S-NSSAI and DNN combination in the non-roaming or home-routed scenario and there is no SM Policy association for the UE ID, S-NSSAI and DNN combination, the PCF, after determining whether the BSF supports the 'SamePcf' or the 'ExtendedSamePcf' feature as described in 3GPP TS 29.521"

2. In TDoc C3-231419, the ProblemDetails data structure's "cause" attribute is set to "NO_BINDING_INFO_FOUND" instead of "EXISTING_BINDING_INFO_FOUND."
- Example from TDoc C3-231419: "If the PCF receives the from the BSF '403 Forbidden' status code with the 'cause' attribute of the ProblemDetails data structure set to 'NO_BINDING_INFO_FOUND'"

3. TDoc C3-231419 specifies that the PCF must use the "pcfSmFqdn" attribute to identify the existing PCF, whereas TDoc C3-231038 allows the use of either "pcfSmFqdn" or "pcfSmIpEndPoints" attribute.
- Example from TDoc C3-231419: "the FQDN of the Npcf_SMPolicyControl service of the existing PCF (i.e. that handles SM Policy association(s) to the same UE ID, S-NSSAI and DNN combination) within the 'pcfSmFqdn' attribute of the BindingResp data structure as defined in clause 4.2.2.2 of 3GPP TS 29.521"
- Example from TDoc C3-231038: "the FQDN or description of IP endpoints of the Npcf_SMPolicyControl service of the existing PCF (i.e. that handles SM Policy association(s) to the same UE ID, S-NSSAI and DNN combination) within the 'pcfSmFqdn' attribute or the 'pcfSmIpEndPoints' attribute of the BindingResp data structure"

3GPP-C3-127-e    Agenda Item 18.9 : Timing Resiliency and URLLC enhancements [TRS_URLLC]

[TDoc C3-231074]:
- TSCTSF shall indicate in an HTTP "403 Forbidden" response message the cause for the rejection including the "cause" attribute set to "REQUESTED_SERVICE_NOT_AUTHORIZED" if the service information provided in the body of the HTTP POST request is rejected by the PCF.
- The URI where the TSCTSF can request to the NF service consumer to delete the "Individual TSC Application Session Context" resource within the "notifUri" attribute may include the domain identity, DNN, S-NSSAI, an ordered list of alternative QoS references, or an ordered list of requested alternative QoS parameters set(s).

[TDoc C3-231109]:
- The AF has to wait before making a new request, and the "Retry-After" header indicates the time.
- "AppDetectionReport" indicates the start or stop of the detected application traffic and the application identifier of the detected application traffic.

[TDoc C3-231111]:
- The updated list of user plane event(s) to which the NF service consumer subscribes within the "events" attribute.
- The additional information related to an event within the corresponding attribute(s) when the NF service consumer requests to update the additional information related to an event.

[TDoc C3-231113]:
- The received cause for the rejection, including the "cause" attribute set to "REQUESTED_SERVICE_NOT_AUTHORIZED," is indicated in an HTTP "403 Forbidden" response message if the updated service information is not acceptable for the PCF.
- The "TscAppSessionContextData" data type is included in the payload body of the HTTP POST request to request the creation of the "Individual TSC Application Session Context" resource.

[TDoc C3-231114]:
- The SMF may determine the time offset and cumulative rateRatio if the SMF receives the clock drifting from the UPF for a Time Domain.
- The SMF shall request the UPF to perform duplicated notification as defined in 3GPP TS 29.244 if the feature "ExposureToEAS" is supported and if the SMF receives both the "QOS_MONITORING" policy control request trigger and the indication of direct notification.
- The PCF shall update the QosMonitoringData instance by including the notification URI within the "notifyUri" attribute and the notification correlation id within the "notifyCorreId" attribute and remove the value "QOS_MONITORING" within the "policyCtrlReqTriggers" attribute if the PCF determines that QoS monitoring report shall be sent from the SMF bypassing the PCF instead of sent from the SMF to the PCF.
- The ARP is assigned a value preconfigured for TSC services.

[TDoc C3-231115]:
- The TSCTSF shall send an HTTP POST request with "{subsNotifUri}" as the request URI and TimeSyncExposureSubsNotif data structure as the request body to send the capability of time synchronization service to the NF service consumer.
- The "eventNotifs" attribute shall contain for each observed event a "SubsEventNotification" data structure that shall include the detected event and the capabilities of time synchronization service for one or more user plane nodes with the "timeSyncCapas" attribute.

[TDoc C3-231117]:
- The "AppAmContextData" data type in the payload body of the HTTP POST request shall include the notification URI where the PCF requests to the NF service consumer the termination of the application AM context encoded as "termNotifUri" attribute, the SUPI of the UE to which the AF requested policy shall apply encoded as "supi" attribute, the indication that high throughput policy is desired for the indicated UE encoded as "highThruInd" attribute when the NF service consumer is the NEF or the AF, and/or the service area coverage desired for the indicated UE encoded as "covReq" attribute, that contains a list of Tracking Area codes per serving network where the requested service shall be allowed, when the NF service consumer is the TSCTSF. The NF service consumer shall remove existing event subscription information by setting to null the "evSubsc" attribute.

- TDoc C3-231073: This TDoc discusses the exchange of network time synchronization status information and support for errors caused by the lack of time synchronization-related subscription data.
- Example snippet: Huawei, Nokia 29.522; Huawei, Nokia 29.565; Huawei, Nokia 29.514; Huawei, Nokia 29.512
- Example snippet: S2-2301421, S2-2300829; S2-2211371, S2-2211311; S2-2301422, S2-2301423, S2-2301424, S2-2301425, S2-2301430; S2-2303677, S2-2303678
- TDoc C3-231346: This TDoc describes the definition of type AsSessionWithQoSSubscriptionPatch and the structure used for subscription request and response.
- Example snippet: Table 5.14.2.1.3-1: Definition of type AsSessionWithQoSSubscriptionPatch; Table 5.14.2.1.2-1: Definition of type AsSessionWithQoSSubscription
- TDoc C3-231354: This TDoc proposes changes to the types TscaiInputContainer and PeriodicityRange.
- Example snippet: 5.6.2.39 Type TscaiInputContainer; Table 5.6.2.39-1: Definition of type TscaiInputContainer; 5.6.2.48 Type PeriodicityRange; Table 5.6.2.48-1: Definition of type PeriodicityRange

[TDoc C3-231347]:
- The TSCTSF can request the NF service consumer to delete the "Individual TSC Application Session Context" resource within the "notifUri" attribute.
- The "dnn" attribute refers to the DNN.
- The "snssai" attribute refers to the S-NSSAI.
- The "ipDomain" attribute refers to the domain identity.
- The "altQosReferences" attribute contains an ordered list of alternative QoS references.
- The "altQosReqs" attribute contains an ordered list of requested alternative QoS parameter set(s).
- If the PCF rejects the service information provided in the HTTP POST request, the TSCTSF shall indicate the cause for rejection in an HTTP "403 Forbidden" response message, including the "cause" attribute set to "REQUESTED_SERVICE_NOT_AUTHORIZED".

[TDoc C3-231351]:
- The AF shall include a reference to the alternative individual QoS related parameter(s) included in this set within the "altQosParamSetRef" attribute.
- The "gbrUl" attribute refers to the guaranteed bandwidth in uplink.
- The "gbrDl" attribute refers to the guaranteed bandwidth in downlink.
- The "pdb" attribute refers to the requested packet delay budget.
- The "per" attribute refers to the requested packet error rate if the "ExtQoS_5G" feature is supported.
- If the NEF authorizes the AF request and the "TSC_5G" feature is supported, the NEF may provision the received QoS requirements and subscribe with the TSCTSF to "QOS_GUARANTEED" and "QOS_NOT_GUARANTEED" events.
- When the NEF receives the event notification from the TSCTSF, the NEF shall notify the AF with "QOS_GUARANTEED" event or with "QOS_NOT_GUARANTEED" event and the currently applied QoS reference if received.

[TDoc C3-231353]:
- The SMF shall correct the value of the "burstArrivalTime" attribute of the "tscaiInputDl" attribute based on the latest received time offset measurement from the UPF and set the downlink TSCAI Burst Arrival Time as the sum of the corrected value and the CN PDB.
- If the SMF receives the clock drifting from the UPF for a Time Domain, it may determine the time offset and cumulative rateRatio.
- The values of MDBV and PDB applied to the derived 5QI shall follow principles defined in clause 5.27.3 of 3GPP TS 23.501.

[TDoc C3-231355]:
- The TSCTSF shall discover the list of AMF(s) serving the list of TA(s) that comprise the time synchronization coverage area using the Nnrf_NFDiscovery service operation if the "CoverageAreaSupport" feature is supported and a time synchronization coverage area is provided within the "covReq" attribute.
- If the 5G access stratum time distribution configuration applies to an internal group of UEs indicated in the "interGrpId" attribute or to an external group of UEs indicated in the "exterGrpId" attribute, the TSCTSF shall interact with the UDM to retrieve the list of individual UEs that belong to the group using the Nudm_SDM service as defined in 3GPP TS 29.503.
- When the "CoverageAreaSupport" feature is supported, the TSCTSF also associates whether the UE fulfills the time synchronization coverage area condition, if provided.

Technical differences among the TDocs:

1. TDoc C3-231118: This TDoc defines the PolicyAssociationRequest and TerminationNotification data types. It also includes suppFeat, pcfUeInfo, matchPdus, and asTimeDisParam properties in both data types. The required property is set to resourceUri in PolicyAssociationRequest and to uuErrorBudget in TerminationNotification.

2. TDoc C3-231348: This TDoc defines the UserPlaneEventReport and UE_SUBSCRIPTION data types. The UserPlaneEventReport includes notificationDestination, tscQosReq, events, accumulatedUsage, flowIds, and ueIpv4Addr properties. The UE_SUBSCRIPTION includes transaction and eventReports properties.

3. TDoc C3-231350: This TDoc defines the PreemptionControlInformation data type. It also includes the 400, 401, and 403 responses with their respective schemas. The Retry-After header is included in the 403 response.

4. TDoc C3-231352: This TDoc defines the EventsSubscReqData and EventsSubscReqDataRm data types. It includes the aspId, sponId, sponStatus, and evSubsc properties in the easRedisInd data type.

Example snippets from the original TDoc:

1. In TDoc C3-231118, the PolicyAssociationRequest data type includes the suppFeat property, which is defined as $ref: 'TS29571_CommonData.yaml#/components/schemas/SupportedFeatures'. The TerminationNotification data type includes the uuErrorBudget property, which is defined as $ref: 'TS29571_CommonData.yaml#/components/schemas/UintegerRm'.

2. In TDoc C3-231348, the UserPlaneEventReport data type includes the event property, which is defined as $ref: '#/components/schemas/UserPlaneEvent'. The UE_SUBSCRIPTION data type includes the transaction property, which is defined as $ref: 'TS29122_CommonData.yaml#/components/schemas/Link'.

3. In TDoc C3-231350, the PreemptionControlInformation data type is defined as Represents Pre-emption control information. The 403 response includes the Forbidden description and content properties.

4. In TDoc C3-231352, the EventsSubscReqData data type includes the events property, which is defined as type: array items: $ref: '#/components/schemas/TscEvent'. The EventsSubscReqDataRm data type is defined as This data type is defined in the same way as the EventsSubscReqData data type, but with the OpenAPI nullable property set to true.

3GPP-C3-127-e    Agenda Item 18.10 : Extensions to the TSC Framework to support DetNet [DetNet]

• The proposed email approval process for updates of the YANG module file in 3GPP is similar to the one defined for updates of the OpenAPI specification file in this technical specification (TS), which reduces overhead compared to previous versions (29.513).
• The YANG module definition guidelines for 3GPP extensions to DetNet YANG model include Module Name, Header information, and Meta information, as well as a general description of the related 3GPP extension and the procedures it supports (4.2.1 Description).
• The technical specification that contains the YANG module file with 3GPP extensions to DetNet YANG model should also include information on the functionality related to the proposed extension and the related YANG module definitions.
• The scope of the corresponding service specification will be described in the clause 1 Scope.
• To ensure uniqueness of the prefix defined in the 3GPP extensions for the DetNet YANG model, the proposed prefix statement should end with "3gppdnet" (2.1.4.3).
• YANG formatting in a 3GPP Technical specification should follow specific guidelines, including treating the YANG module as a code component (2.1.6).
• The example provided in the Annex includes the 3gpp-detnet-5gs-node YANG module, which specifies 3GPP extensions to support indicating the maximum loss and maximum latency for DetNet flows in the 5GS system.
• The YANG module's namespace should follow the guidelines specified in RFC8407 Section 4.9.

Example snippet supporting the technical difference:

According to clause 4.2.1 Description, the technical specification that contains the YANG module file with 3GPP extensions to DetNet YANG model should include the functionality related to the proposed extension and the related YANG module definitions. This is a technical difference because previous versions of the technical specification did not provide guidelines for including such information, whereas the proposed version provides specific requirements for documenting the YANG module's functionality.

Technical differences between TDoc C3-231099 and TDoc C3-231100:

1. AdditionalAddresses feature:
- TDoc C3-231099 mentions the "AdditionalAddresses" feature, which allows receiving information about one or more Framed Routes or IPv6 prefixes delegated to the UE by IPv6 Prefix Delegation.
- No mention of the AdditionalAddresses feature in TDoc C3-231100.

Example from TDoc C3-231099: "if the 'AdditionalAddresses' feature is supported, to the 'ADDITIONAL_ADDR' event to receive information about the one or more Framed Routes available for the PDU session or about the IPv6 prefixes delegated to the UE by IPv6 Prefix Delegation."

2. TSC User Plane information:
- Both TDocs mention the TSC User Plane information, which is received by the PCF from the AF.
- TDoc C3-231099 mentions that the PCF returns the event related information in the Npcf_PolicyAuthorization_Create response, while TDoc C3-231100 does not specify this.
- TDoc C3-231100 mentions that the PCF provides the SMF with the PMIC information received from the TSCTSF.

Example from TDoc C3-231099: "The PCF returns the event related information in the Npcf_PolicyAuthorization_Create response (e.g. TSC User Plane information (5GS Router information), additional addresses, if subscribed and available, and PMIC(s) if available)."

Example from TDoc C3-231100: "The PCF provides to the SMF the PMIC information received from the TSCTSF as described in clause 5.2.2.2.2.2, which sends the received PMIC to the NW-TT/UPF."

3. Npcf_PolicyAuthorization_Notify service operation:
- Both TDocs mention the Npcf_PolicyAuthorization_Notify service operation, which is invoked by the PCF to notify the TSCTSF about the received TSC User Plane information.
- TDoc C3-231099 mentions that the UE IP address is included to identify the PDU session, while TDoc C3-231100 does not specify this.

Example from TDoc C3-231099: "The PCF invokes the Npcf_PolicyAuthorization_Notify service operation to notify to the TSCTSF the received TSC User Plane information and if available, NW-TT PMIC, as described in figure 5.2.2.3-1, step 5 and includes the UE IP address to identify the PDU session."

Example from TDoc C3-231100: "The PCF invokes the Npcf_PolicyAuthorization_Notify service operation to notify to the TSCTSF the received TSC User Plane information, and if available, NW-TT PMIC, as described in figure 5.2.2.3-1, step 5 and includes the UE IP address to identify the PDU session."

4. DetNet controller:
- Both TDocs mention the DetNet controller, which receives interface configuration information from the TSCTSF.
- TDoc C3-231099 mentions that the TSCTSF may report to the DetNet controller the collected interface(s) information if the interface configuration information for the AF session is complete, while TDoc C3-231100 does not specify this.
- TDoc C3-231100 mentions that the SMF provides the received PMIC information to the PCF when PMIC changes for the NW-TT are detected.

Example from TDoc C3-231099: "If the TSCTSF determines the interface configuration information for the created AF-session is complete, the TSCTSF may report to the DetNet controller the collected interface(s) information as described in step 10."

Example from TDoc C3-231100: "When the SMF detects PMIC changes for the NW-TT, the SMF provides the received PMIC information to the PCF as described in clause 5.2.2.3. The TSCTSF determines that the interface information for the AF session is complete and may provide the collected network and device side interface configuration to the DetNet controller as defined in 3GPP TS 23.501."

3GPP-C3-127-e    Agenda Item 18.12 : CT aspects of 5G System Enabler for Service Function Chaining [SFC]

1. The first TDoc snippet includes definitions for dnn, snssai, afAppId, and multiAccCtrls. These are all related to identifying and controlling multicast address access. The dnn and snssai are references to other schemas defined in the same document, while afAppId and multiAccCtrls have their own definitions within the same snippet.
Example: "Identifies a list of multicast address access control information" (description for multiAccCtrls)

2. The second TDoc snippet includes definitions for gpsi, ipv4Addr, ipDomain, ipv6Addr, macAddr, dnaiChgType, notificationDestination, and requestTestNotification. These are related to identifying and managing various types of network data, such as IP addresses and test notifications.
Example: "Set to true by the SCS/AS to request the NEF to send a test notification as defined in clause 5.2.5.3" (description for requestTestNotification)

3. The first TDoc snippet includes a definition for supp-feat, which is related to identifying supported features. This definition is not present in the second TDoc snippet, indicating a difference in the types of data and functionality being managed between the two.
Example: "Supported Features" (description for supp-feat)

4. The first TDoc snippet includes a response definition for '200' which includes a notification URI and correlation identifier. These are not present in the second TDoc snippet, indicating a difference in the expected behaviors and responses between the two.
Example: "NotifUri: $ref: 'TS29571_CommonData.yaml#/components/schemas/Uri'" (response definition in the first TDoc snippet)

5. The second TDoc snippet includes a definition for TrafficCorrelationInfo which includes a trafficRoutes array. This is not present in the first TDoc snippet and represents a difference in the types of data and functionality being managed.
Example: "Identifies the N6 traffic routing requirement" (description for trafficRoutes in TrafficCorrelationInfo)

6. The first TDoc snippet includes a definition for SupportedFeatures, which is a reference to another schema defined in the same document. This type of reference is not present in the second TDoc snippet, indicating a difference in the use of schema references between the two.
Example: "$ref: 'TS29571_CommonData.yaml#/components/schemas/SupportedFeatures'" (definition for SupportedFeatures in the first TDoc snippet)

7. The second TDoc snippet includes a definition for TrafficCorrelationInfo which includes a required property of ackResult. This is not present in the first TDoc snippet and represents a difference in the required properties and validation between the two.
Example: "ackResult: $ref: '#/components/schemas/AfResultInfo'" (required property in TrafficCorrelationInfo in the second TDoc snippet)

3GPP-C3-127-e    Agenda Item 18.13 : CT aspects of enhancement of 5G UE Policy [eUEPO]

1. TDoc C3-231142: The snippet includes two objects, RankingCriterion and DispersionInfo, both of which have different properties and are used for different purposes.

Example snippet: "RankingCriterion" indicates the usage ranking criterion between high, medium, and low usage UE. "DispersionInfo" represents Dispersion information.

2. TDoc C3-231143: The feature "ServiceExperience" is supported, and the event is "SERVICE_EXPERIENCE." The snippet provides identification of target UE(s) and event-specific filter information in the "event-filter" attribute.

Example snippet: "tgt-ue" attribute provides identification of target UE(s), while the "event-filter" attribute provides event-specific filter information.

3. TDoc C3-231272: The snippet includes an object, UpPathChgEvent, which contains UP path change event subscription from the AF.

Example snippet: "UpPathChgEvent" contains UP path change event subscription from the AF.

4. TDoc C3-231343: The snippet includes two objects, PolicyAssociation and PolicyAssociationRequest, which are used for creating, updating, or reading policy associations.

Example snippet: "PolicyAssociation" contains the description of a policy association that is returned by the PCF. "PolicyAssociationRequest" represents information that the NF service consumer provides when requesting the creation of a policy association.

5. TDoc C3-231143: The snippet includes a trigger, "PLMN_CH," which is used when the serving network of the UE has changed.

Example snippet: The "PLMN_CH" trigger applies only if the "PlmnChange" feature is supported.

6. TDoc C3-231142: The snippet includes a URI, "Location," which contains the URI of the newly created resource.

Example snippet: The "Location" header contains the URI of the newly created resource.

7. TDoc C3-231343: The snippet includes a token URL, "tokenUrl," which is used for accessing the Npcf_UEPolicyControl API.

Example snippet: The "tokenUrl" is used for accessing the Npcf_UEPolicyControl API.

The technical differences between TDoc C3-231083 and C3-231273 are as follows:

1. Policy Data Subscription Information Notification: In TDoc C3-231083, the PCF may request notifications from the UDR on changes in the policy data subscription information and invoke the Nudr_DataRepository_Subscribe service operation by sending an HTTP POST request to the "PolicyDataSubscriptions" resource. However, this feature is not mentioned in TDoc C3-231273.

Example from TDoc C3-231083: "The PCF may request notifications from the UDR on changes in the policy data subscription information (e.g, UE Policy Set resource), and in this case, the PCF shall invoke the Nudr_DataRepository_Subscribe service operation by sending an HTTP POST request to the "PolicyDataSubscriptions" resource."

2. Retrieval of Group Configuration: In TDoc C3-231083, the PCF invokes the Nudr_DataRepository_Query service operation to the UDR by sending the HTTP GET request to the "5GvnGroupsInternal" resource to retrieve the group configuration of the received 5G VN Group Id as specified in 3GPP TS 29.505 [47], if not internally available. However, this feature is not mentioned in TDoc C3-231273.

Example from TDoc C3-231083: "Additionally, the PCF invokes the Nudr_DataRepository_Query service operation to the UDR by sending the HTTP GET request to the "5GvnGroupsInternal" resource to retrieve the group configuration of the received 5G VN Group Id as specified in 3GPP TS 29.505 [47], if not internally available."

3. Notifications on Changes in 5G VN Group Configuration: In TDoc C3-231083, to request notifications from the UDR on changes in the 5G VN group configuration data associated with each of the Internal-Group-Id provided to the PCF, the PCF invokes the Nudr_DataRepository_Subscribe service operation by sending an HTTP POST request to the "SubscriptionDataSubscriptions" resource as specified in 3GPP TS 29.505 14. However, this feature is not mentioned in TDoc C3-231273.

Example from TDoc C3-231083: "Additionally, to request notifications from the UDR on changes in the 5G VN group configuration data associated to each of the Internal-Group-Id provided to the PCF, the PCF invokes the Nudr_DataRepository_Subscribe service operation by sending an HTTP POST request to the "SubscriptionDataSubscriptions" resource as specified in 3GPP TS 29.505 14."

4. Provision of URSP Rules: In TDoc C3-231273, if the (H-)PCF retrieves the BDT policy and corresponding related information within the BdtData data type, and the "bdtpStatus" attribute within the BdtData data type is set to value "INVALID", the (H-)PCF shall not provision the URSP rules based on the invalid BDT policy. Additionally, if the "AfGuideURSP" feature is supported by the Nudr_DataRepository service, the (H-)PCF may receive Service specific parameter information that contains data for AF guidance information on the URSP determination as defined in clause 6.4.2.15 of 3GPP TS 29.519. The (H-)PCF shall use the UE policy subscription data stored in UDR as specified in 3GPP TS 29.519.

Example from TDoc C3-231273: "If the (H-)PCF retrieves the BDT policy and corresponding related information (e.g. network area information, the volume of data to be transferred per UE, etc.) within the BdtData data type, and the "bdtpStatus" attribute within the BdtData data type is set to value "INVALID", the (H-)PCF shall not provision the URSP rules based on the invalid BDT policy." "If the "AfGuideURSP" feature is supported by the Nudr_DataRepository service, the (H-)PCF may receive Service specific parameter information that contains data for AF guidance information on the URSP determination as defined in clause 6.4.2.15 of 3GPP TS 29.519." "The (H-)PCF shall use the UE policy subscription data stored in UDR as specified in 3GPP TS 29.519."

3GPP-C3-127-e    Agenda Item 18.14 : CT aspects for Enabling Edge Applications Phase 2 [EDGEAPP_Ph2]

[TDoc C3-231376]:
- Defines two objects: AcrMgntEventsNotification and AcrMgntEventSubsc
- AcrMgntEventsNotification has three properties: evtReq, notificationDestination, and suppFeat
- AcrMgntEventSubsc has six properties: event, eventFilter, evtReq, tgtUeId, dnaiChgType, and easAckInd
- Uses references to other YAML files for some properties, such as 'TS29523_Npcf_EventExposure.yaml'
- Includes a boolean property 'easAckInd' to identify whether EAS acknowledgement of UP path change event notifications is to be expected

[TDoc C3-231377]:
- Defines four objects: eecCntx, EECContextPushRes, ImplicitRegDetails, and IndividualSessionContext
- eecCntx has two required properties: eesId and eecCntx
- EECContextPushRes has two properties: implReg and ueId
- ImplicitRegDetails has one property: regId, and an array property sessCntxs
- IndividualSessionContext has one required property: sessCntxs, and uses a reference to 'TS29571_CommonData.yaml' for the property ueId

[TDoc C3-231378]:
- Defines one object: EESRegistration
- Includes a requestBody for EESRegistration in JSON format
- Includes a responses object with a '201' status code and a description
- Includes two properties for partial updates: eesProf and expTime
- Includes a ServiceArea object with two properties: svcContSupp and appLocs, using a reference to 'TS29571_CommonData.yaml' for the property appLocs

Example support:
- TDoc C3-231376: "evtReq" and "notificationDestination" are defined in AcrMgntEventsNotification (line 2)
- TDoc C3-231377: "eecCntx" is defined with two required properties (line 1)
- TDoc C3-231378: The requestBody is defined for EESRegistration in JSON format (line 1)

First TDoc (C3-231391):
- The TDoc defines the properties easProf, expTime, and suppFeat, which are all references to external schemas.
- The EASProfile object is defined and includes the properties transContSupp, avlRep, status, svcArea, and appLocs.
- The requestBody is required and contains a JSON schema reference for EASRegistration.
- The response for a successful registration is '201'.

Example snippet:
- "properties: easProf: $ref: '#/components/schemas/EASProfile' expTime: $ref: 'TS29122_CommonData.yaml#/components/schemas/DateTime' suppFeat: $ref: 'TS29571_CommonData.yaml#/components/schemas/SupportedFeatures' required: - easProf"

Second TDoc (C3-231392):
- The TDoc defines svcArea, appLocs, and plmnIds as properties.
- The requestBody is required and contains a JSON schema reference for EESRegistration.
- The response for a successful registration is '201'.
- The EESProfile object is defined.

Example snippet:
- "properties: eesProf: $ref: '#/components/schemas/EESProfile' expTime: $ref: 'TS29571_CommonData.yaml#/components/schemas/DateTimeRm' ServiceArea: type: object description: Represents a service area information of the EdgeApp entity."

Third TDoc (C3-231393):
- The TDoc defines evtReq, notificationDestination, and suppFeat as properties.
- The AcrMgntEventsNotification object is defined and includes the properties event, eventFilter, evtReq, tgtUeId, dnaiChgType, and easAckInd.
- The AcrMgntEventSubsc object is defined and includes the properties event, eventFilter, evtReq, tgtUeId, and dnaiChgType.

Example snippet:
- "properties: event: $ref: '#/components/schemas/AcrMgntEvent' eventFilter: $ref: '#/components/schemas/AcrMgntEventFilter' evtReq: $ref: 'TS29523_Npcf_EventExposure.yaml#/components/schemas/ReportingInformation'"

Fourth TDoc (C3-231406):
- The TDoc defines requestBody as required and contains a JSON schema reference for EESRegistration.
- The properties svcArea, appLocs, eesProf, expTime, and ServiceArea are defined.
- The svcContSupp property is defined as an array of ACRScenario objects.

Example snippet:
- "svcContSupp: type: array items: $ref: '#/components/schemas/ACRScenario' minItems: 1 description: The ACR scenarios supported by the EES for service continuity."

The following are some of the technical differences among the TDoc snippets:

- The first TDoc (C3-231394) discusses security considerations when using CAPIF for external exposure of EES services to EAS. The EAS as API invoker negotiates the security method with CAPIF and authenticates itself before invoking the API exposed by the EES. The interactions between the CAPIF core function and API provider domain functions may be independent of certain reference points, depending on the deployment scenario. The EES also retrieves authorization information from CAPIF if PKI or TLS-PSK is used as the selected security method.

Example snippet from C3-231394: "Before invoking the API exposed by the EES, the EAS as API invoker shall negotiate the security method (PKI, TLS-PSK or OAUTH2) with CAPIF core function and ensure the EAS has enough credential to authenticate the EAS (see 3GPP TS 29.222)."

- The second TDoc (C3-231395) specifies the north-bound APIs needed to support the services offered by EES and ECS over EDGE-3/6/9 interfaces for enabling edge applications over the 3GPP network. Various features are defined to ensure efficient use and deployment of edge applications, including registration, discovery, service provisioning, and capability exposure support for service continuity.

Example snippet from C3-231395: "The present document specifies the north-bound APIs in detail, needed to support the services offered by EES and ECS over EDGE-3/6/9 interfaces for enabling the edge applications over 3GPP network."

- The third TDoc (C3-231407) describes the processing of an HTTP POST request from a service consumer (EAS or EES) by the EES. The EES processes the EAS discovery request information, verifies and checks if the service consumer is authorized to discover the requested EAS(s) from the EES, and responds with an HTTP "200 OK" status code and the EasDiscoveryResp data structure if the request is successful. If no matching EAS is found and there is no client side error, the EES responds with an HTTP "204 No Content" status code.

Example snippet from C3-231407: "Upon reception of the HTTP POST request from the service consumer (i.e. EAS or EES), the EES shall: a) process the EAS discovery request information; b) the EES verifies and checks if the service consumer (i.e. EAS or EES) is authorized to discover the requested EAS(s) from the EES; c) if the service consumer (i.e. EAS or EES) is authorized to discover the requested EAS(s) from the EES, then upon successful processing of the request, the EES responds with an HTTP "200 OK" status code with the response body including the EasDiscoveryResp data structure as specified in clause 6.3.5.2.3 of 3GPP TS 24.558."

TDoc C3-231375:

- The TDoc defines an endpoint schema, which is referenced in the "endPt" property.
- The TDoc includes the "acId" property, which is a string type that represents the identifier of the AC for which the service session information is provided.
- The TDoc defines the "EECContextPush" object, which includes the "eesId" property representing the identifier of the S-EES pushing the EEC context information.
- The TDoc defines the "ImplicitRegDetails" object, which includes the "regId" property representing the identifier of the EEC registration.
- The TDoc includes the "e1Subs" property, which is an array of string type and contains the list of subscription IDs for the capability exposure for the EEC ID.
- The TDoc defines the "EECContext" object, which contains the EEC context information.

[TDoc C3-231404]:

- The TDoc includes the "supp-feat" parameter, which is a query parameter representing the features supported by the EAS.
- The TDoc defines the "AcrMgntEventsNotification" object, which represents the ACR management events notification and includes properties such as "easId" and "eventSubscs".
- The TDoc defines the "AcrMgntEventSubsc" object, which represents an ACR Management Event Subscription.
- The TDoc includes the "events" property, which is an array of "UserPlaneEvent" type describing the events subscribed by the EAS.
- The TDoc includes the "websockNotifConfig" property, which is a reference to the "WebsockNotifConfig" schema.
- The TDoc includes the "suppFeat" property, which is a reference to the "SupportedFeatures" schema.

[TDoc C3-231405]:

- The TDoc includes the "events" property, which is an array of "UserPlaneEvent" type describing the events subscribed by the EAS.
- The TDoc includes the "websockNotifConfig" property, which is a reference to the "WebsockNotifConfig" schema.
- The TDoc includes the "suppFeat" property, which is a reference to the "SupportedFeatures" schema.
- The TDoc includes the "ipFlows" property, which is an array of "FlowDescription" type describing the flow description for the Uplink and/or Downlink IP flows.

[TDoc C3-231406]:

- The TDoc defines the "EASPolicyControlRequest" object, which represents the EAS policy control request and includes properties such as "easId" and "policyReq".
- The TDoc defines the "PolicyReq" object, which represents the policy request and includes properties such as "serviceIds" and "flowDescriptions".
- The TDoc includes the "flowDescriptions" property, which is an array of "FlowDescription" type describing the flow description for the Uplink and/or Downlink IP flows.

3GPP-C3-127-e    Agenda Item 18.15 : Rel-18 enhancements of session management policy control [SMPC18]

1. TDoc C3-231276 discusses proposed changes related to session management and mobility management in 5G networks, while TDoc C3-231279 focuses on changes related to bearer management and network slicing.
- Example from C3-231276: "In 5G networks, session management involves the establishment, maintenance, and release of session connections between the UE and the network."
- Example from C3-231279: "Network slicing allows for the creation of multiple logical networks over a single physical network infrastructure."

2. TDoc C3-231276 proposes changes to the interfaces between the Access and Mobility Management Function (AMF) and the Session Management Function (SMF), while TDoc C3-231279 proposes changes to the interfaces between the SMF and the User Plane Function (UPF).
- Example from C3-231276: "The proposed changes aim to improve the efficiency of the interface between the AMF and the SMF by reducing the number of messages exchanged during session management procedures."
- Example from C3-231279: "The proposed changes aim to enhance the functionality of the interface between the SMF and the UPF by introducing support for dynamic bearer creation."

3. TDoc C3-231276 discusses proposed changes to the message flows for session establishment and release, while TDoc C3-231279 focuses on changes to the message flows for bearer establishment and release.
- Example from C3-231276: "The proposed changes aim to simplify and streamline the session establishment and release procedures, while ensuring compatibility with existing 4G systems."
- Example from C3-231279: "The proposed changes aim to enable efficient management of bearer resources and improve the scalability of the network by allowing for dynamic creation and release of bearers."

4. TDoc C3-231276 proposes changes related to the use of Network Slice Selection Function (NSSF) in session management, while TDoc C3-231279 proposes changes related to the use of Application Function (AF) in bearer management.
- Example from C3-231276: "The proposed changes aim to enhance the functionality of the NSSF in selecting the appropriate network slice for a given session, based on factors such as QoS requirements and available resources."
- Example from C3-231279: "The proposed changes aim to improve the efficiency of the AF in managing bearers for different applications, by introducing support for application-based bearer management."

5. TDoc C3-231276 proposes changes related to the handling of inter-system mobility, while TDoc C3-231279 focuses on changes to the handling of inter-PLMN mobility.
- Example from C3-231276: "The proposed changes aim to improve the efficiency and reliability of inter-system handovers between 5G and non-5G networks, by introducing new procedures and messages."
- Example from C3-231279: "The proposed changes aim to enhance the interoperability between different PLMNs and improve the performance of inter-PLMN handovers, by introducing new signaling and authentication mechanisms."

TDoc C3-231275:

- Introduces the concept of a policy control request trigger, which is a pre-configured condition in the SMF or provisioned by the PCF to trigger further policy decisions related to a PDU session.
- When the trigger is met, the SMF sends the related attributes that have changed together with the corresponding triggers to the PCF.
- The PCF can provide an array of policy control request triggers in a policy decision.
- The policy control request trigger is an Enumeration type defined in clause 5.6.3.6.

Example: "A policy control request trigger is a condition pre-configured in the SMF (i.e. always report) or provisioned by the PCF to the SMF, which defines when the SMF shall interact again with PCF for further policy decision related to a PDU session."

TDoc C3-231278:

- Lists various sources of information that can be used by the PCF to make policy decisions, including information from the AF, UDR, AMF, SMF, NWDAF, NEF, CHF, TSCTSF, TSN AF, and pre-configured policy context.
- Specifies the policies provided by the PCF for various purposes such as application and service data flow detection, QoS flow based charging, traffic steering control, usage monitoring control, access traffic steering, switching and steering within a MA PDU Session, access network information report, UMIC, PMIC, and TSCAI input container, and RAN support information to the SMF.

Example: "The PCF provides the following policies for application and service data flow detection gating QoS flow based charging traffic steering control usage monitoring control access traffic steering, switching and steering within a MA PDU Session access network information report UMIC, PMIC and TSCAI input container and RAN support information to the SMF."

3GPP-C3-127-e    Agenda Item 18.18 : Support for 5WWC Phase 2 [5WWC_Ph2]

3GPP-C3-127-e    Agenda Item 18.21 : CT aspects of application layer support for V2X services; Phase 3 [V2XAPP_Ph3]

3GPP-C3-127-e    Agenda Item 18.22 : CT aspects of SEAL data delivery enabler for vertical applications [SEALDD]

Technical Differences:

1. Service Enabler Architecture Layer for Verticals (SEAL)
- 3GPP TS 23.434 defines the functional architecture and information flows for SEAL.
- 3GPP TS 23.433 defines the data delivery enabler for vertical applications in SEAL.

2. 5G System
- 3GPP TS 29.501 provides principles and guidelines for services definition in 5G.
- 3GPP TS 29.500 details the technical realization of service-based architecture in 5G.

3. Northbound APIs
- 3GPP TS 29.122 defines the T8 reference point for Northbound APIs.
- 3GPP TS 33.122 discusses the security aspects of the Common API Framework (CAPIF) for 3GPP Northbound APIs.
- 3GPP TS 29.222 provides a common API framework for 3GPP Northbound APIs.

4. Common Data Types
- 3GPP TS 29.571 defines common data types for service-based interfaces in 5G.

5. Group Communication System Enablers for LTE (GCSE_LTE)
- 3GPP TS 29.468 defines the MB2 reference point for GCSE_LTE.

Example Snippets:

- 3GPP TS 23.434 defines the SEAL functional architecture and information flows, indicating the different components and their roles in the architecture.
- 3GPP TS 29.501 provides guidelines for defining services in 5G, specifying principles such as service-based architecture and dynamic service composition.
- 3GPP TS 29.122 details the T8 reference point for Northbound APIs, specifying the interface between the service layer and the management layer.
- 3GPP TS 33.122 discusses the security aspects of CAPIF for 3GPP Northbound APIs, including authentication and authorization mechanisms.
- 3GPP TS 29.222 provides a common API framework for 3GPP Northbound APIs, specifying the APIs and protocols for accessing services.
- 3GPP TS 29.571 defines common data types for service-based interfaces in 5G, including data structures for service requests and responses.
- 3GPP TS 29.468 defines the MB2 reference point for GCSE_LTE, specifying the interface between the UE and the group communication server.

The TDoc C3-231212 and TDoc C3-231215 provide details about the technical differences among the following:

1. TS 29.548 V 0.0.0 and the new TS 29.548 for Services offered by the SEALDD Server.
- TDoc C3-231212 defines the scope clause of the new TS 29.548 and specifies the stage 3 protocol and data model for the Services. It also provides stage 3 protocol definitions and message flows for each service offered by the SEALDD Server.
- TDoc C3-231215 references clause 5.2 of 3GPP TS 29.122 for the common protocol and interface aspects for API definition in the clauses under clause 5. It also specifies the corresponding APIs defined for this specification in table 5.1.

Example snippet from TDoc C3-231212: "The present document specifies the stage 3 protocol and data model for the Services. The common protocol and interface aspects for API definition are specified in clause 5.2 of 3GPP TS 29.122."

2. The role of the SEALDD Server and the service consumer (i.e. VAL Server or another SEALDD Server) in the new TS 29.548.
- TDoc C3-231215 specifies that the SEALDD Server takes the role of the SCEF and the service consumer takes the role of the SCS/AS.

Example snippet from TDoc C3-231215: "the service producer (i.e. SEALDD Server) takes the role of the SCEF and the service consumer (i.e. VAL Server or another SEALDD Server) takes the role of the SCS/AS."

3. Defining the "Services offered by the SEALDD Server" clause in the new TS 29.548.
- TDoc C3-231212 proposes changes to the new TS 29.548 to define the "Services offered by the SEALDD Server" clause.
- TDoc C3-231215 specifies the corresponding APIs for this specification in table 5.1.

Example snippet from TDoc C3-231212: "Start defining the 'Services offered by the SEALDD Server' clause of the new TS 29.548."
Example snippet from TDoc C3-231215: "Table 5.1- summarizes the corresponding APIs defined for this specification."

3GPP-C3-127-e    Agenda Item 18.23 : CT Aspects of Application Layer Support for Uncrewed Aerial Systems (UAS), Phase 2 [UASAPP_Ph2]

TDoc C3-231249:
- This TDoc introduces a new protocol for handling authentication and authorization in a network.
- It includes new signaling messages and procedures.
- Example snippet: "The new signaling messages include Authentication Request, Authentication Response, Authorization Request, and Authorization Response."

TDoc C3-231250:
- This TDoc proposes enhancements to the existing protocol for managing network resources.
- It includes new message types and mechanisms for handling traffic congestion.
- Example snippet: "The proposed enhancements include the addition of a Congestion Control message type and a Traffic Management function."

TDoc C3-231252:
- This TDoc focuses on improving the security of network communication.
- It introduces new encryption algorithms and mechanisms for key distribution.
- Example snippet: "The new encryption algorithms include AES-256 and ChaCha20-Poly1305. Key distribution is improved through the use of a new Secure Key Exchange message."

Start of changes:
- This section outlines modifications made to a previously existing protocol or proposal.
- Example snippet: "Changes include the addition of a new field in the Message Header and the removal of a redundant message type."

End of changes:
- This section marks the end of the modifications made in the previous section.

Next changes:
- This section outlines future modifications or improvements to the protocol or proposal.
- Example snippet: "Future changes include the addition of support for IPv6 addresses and the development of a more efficient encryption algorithm."

3GPP-C3-127-e    Agenda Item 18.25 : CT aspects of enhancement to the 5GC location services - phase 3 [5G_eLCS_Ph3]

3GPP-C3-127-e    Agenda Item 18.26 : CT Aspects of Edge Computing Phase 2 [EDGE_Ph2]

Technical Differences Among TDocs:

1. TDoc C3-231049:
- Defines information on the SM congestion control applied SM NAS messages that SMF sends to UE for PDU Session.
- Includes a "transacMetrics" property for indicating Session Management Transaction metrics.

2. TDoc C3-231050:
- Includes properties for IP addresses, MAC addresses, and DNS information.
- Defines acknowledgement information of a traffic influence event notification.

3. TDoc C3-231051:
- Defines properties for self, AF service ID, FQDN pattern list, DNN, and SNSSAI.
- Identifies the N6 traffic routing requirement.

4. TDoc C3-231052:
- Defines information on SM congestion control applied SM NAS messages that SMF sends to UE for PDU Session.
- Includes a "transacMetrics" property for indicating Session Management Transaction metrics.

5. TDoc C3-231144:
- Defines the type EventNotification.

6. TDoc C3-231145:
- Defines the type EventNotification.

7. TDoc C3-231280:
- Defines attributes for transactions dispersion collection and redundant transmission experience of PDU Session.

8. TDoc C3-231283:
- Defines the type TrafficInfluDataPatch.

9. TDoc C3-231327:
- Contains proposed changes for the document.

10. TDoc C3-231328:
- Contains proposed changes for the document.

11. TDoc C3-231329:
- Contains proposed changes for the document.

12. TDoc C3-231330:
- Defines the NEF Northbound APIs.
- Includes a table summarizing the APIs defined in the document.

13. TDoc C3-231331:
- Contains proposed changes for the document.

14. TDoc C3-231332:
- Contains proposed changes for the document.

15. TDoc C3-231333:
- Contains proposed changes for the document.

Example Snippets from Original TDocs:

- TDoc C3-231049:
- "transacMetrics": property for indicating Session Management Transaction metrics.

- TDoc C3-231050:
- "requestTestNotification": property for requesting a test notification.
- "ackResult": acknowledgement information of a traffic influence event notification.

- TDoc C3-231051:
- "trafficRoutes": property for identifying the N6 traffic routing requirement.

- TDoc C3-231052:
- "transacMetrics": property for indicating Session Management Transaction metrics.

- TDoc C3-231144:
- "EventNotification": type definition.

- TDoc C3-231145:
- "EventNotification": type definition.

- TDoc C3-231280:
- "transacInfos": attribute for transactions dispersion collection.
- "ueIpAddr": attribute for UE IP address.

- TDoc C3-231283:
- "TrafficInfluDataPatch": type definition.

- TDoc C3-231327:
- Contains proposed changes for the document.

- TDoc C3-231328:
- Contains proposed changes for the document.

- TDoc C3-231329:
- Contains proposed changes for the document.

- TDoc C3-231330:
- "NEF Northbound APIs": definition of APIs for interaction between NEF and AF.
- "Table 5.1-1": table summarizing the APIs defined in the document.

- TDoc C3-231331:
- Contains proposed changes for the document.

- TDoc C3-231332:
- Contains proposed changes for the document.

- TDoc C3-231333:
- Contains proposed changes for the document.

Technical differences among the four TDocs are as follows:

1. TDoc C3-231334 proposes "Additional discussion" before presenting "Proposed changes" for the first time. The changes are marked as "all-are-new". This means that all changes are new and have not been discussed previously.

Example from TDoc C3-231334: "Additional discussion needed on the proposed changes to avoid any ambiguity."

2. TDoc C3-231335 also proposes "Additional discussion" before presenting "Proposed changes". The changes are marked as "all-are-new" like in TDoc C3-231334.

Example from TDoc C3-231335: "Additional discussion needed to clarify the proposed changes and their impact on the existing framework."

3. TDoc C3-231336 presents only one change, marked as "1st Change". There is no "Additional discussion" before the change is presented.

Example from TDoc C3-231336: "The first change proposed is related to the frequency band allocation in the spectrum."

4. TDoc C3-231337 presents only one change, marked as "1st Change". There is no "Additional discussion" before the change is presented.

Example from TDoc C3-231337: "The first change suggested is to modify the existing algorithm for channel estimation."

Overall, the main differences among the TDocs are the presence or absence of "Additional discussion" before presenting "Proposed changes" and the type of change presented (all-are-new vs. 1st Change).

• TDoc C3-231053: This TDoc involves resource deletion and includes a list of different responses for the deletion process. The response codes range from 307 to 503, with a default response code also included. The responses are referenced from a common data file.

• TDoc C3-231339: This TDoc involves adding an attribute called "easRediscoverInd" to the EventNotification data type. It also includes a required field for "smNasType" and a reference for "DateTime" schema.

• TDoc C3-231340: This TDoc includes different attributes for traffic influence event notification. The attributes include items such as "dnaiChgType," "ipv4Addr," "macAddr," and "notificationDestination." It also includes a boolean field for requesting a test notification.

• TDoc C3-231341: This TDoc includes different schemas for traffic routing, such as "multiRelIpv6Prefixes" and "relAddIpv6AddrPrefixes." It also includes different properties for different events, such as "UpPathChgEvent" and "NotifCorreId."

Examples from the TDocs:

• From TDoc C3-231053: "307': $ref: 'TS29571_CommonData.yaml#/components/responses/307'" and "default: $ref: 'TS29571_CommonData.yaml#/components/responses/default'" are examples of the different response codes included in the TDoc.

• From TDoc C3-231339: "required: - smNasType - timeStamp" is an example of the required fields included in the TDoc.

• From TDoc C3-231340: "dnaiChgType: $ref: 'TS29571_CommonData.yaml#/components/schemas/DnaiChangeType'" and "requestTestNotification: type: boolean" are examples of the different attributes included in the TDoc.

• From TDoc C3-231341: "trafficRoutes: type: array items: $ref: 'TS29571_CommonData.yaml#/components/schemas/RouteToLocation' minItems: 1" is an example of the different schema included in the TDoc.

TDoc C3-231281:
- The SMF must ensure no DNAI change for traffic related to a specific application.
- The PCF includes necessary information for EAS rediscovery and UE IP address preservation in PccRule data instances.
- SMF may maintain simultaneous connectivity and influence the establishment of a temporary N9 forwarding tunnel between source and target PSA.

TDoc C3-231282:
- NF service consumer includes "afSfcReq" attribute with specific N6-LAN traffic steering requirements in HTTP POST request message.
- PCF may set "servAuthInfo" attribute to "ROUT_REQ_NOT_AUTHORIZED" and NF service consumer may subscribe to UP path management event failures.

TDoc C3-231284:
- AF sends HTTP POST message to NEF for Traffic Influence Subscription resource.
- Message body includes AF Service Identifier, UE Indication, DNN, S-NSSAI, Application Identifier, routing profile ID(s), and N6-LAN traffic steering information.
- Indication of application relocation possibility, temporal validity conditions, and EAS rediscovery may also be included.

TDoc C3-231326:
- Nnef_MSEventExposure service and Nnef_MBSUserService procedures are applicable for NEF Northbound interface.

Supporting examples from TDoc C3-231281:
- "If the URLLC feature is supported and the AF request includes an indication that the UE IP address preservation should be considered, the PCF shall include within the concerned PccRule data instance(s)."
- "if the 'simConnInd' attribute set to true is included in the TrafficControlData data type...the SMF may temporarily maintain simultaneous connectivity...and may influence the establishment of a temporary N9 forwarding tunnel."

Supporting examples from TDoc C3-231282:
- "the PCF may set the 'servAuthInfo' attribute in the HTTP response message to 'ROUT_REQ_NOT_AUTHORIZED.'"
- "the NF service consumer may subscribe to notifications of failures in the enforcement of UP path changes."

Supporting examples from TDoc C3-231284:
- "the body of the HTTP POST message may include the AF Service Identifier, external Group Identifier, any UE Indication, the UE address, GPSI, DNN, S-NSSAI, Application Identifier or traffic filtering information, Subscribed Event, Notification destination address, a list of geographic areas(s), AF Transaction Identifier, a list of DNAI(s), routing profile ID(s) or N6 traffic routing information, and/or N6-LAN traffic steering information if SFC feature is supported."
- "If the EASDiscovery feature is supported, the indication of the EAS rediscovery may also be included."

3GPP-C3-127-e    Agenda Item 18.27 : CT aspect of Seamless UE context recovery [SUECR]

3GPP-C3-127-e    Agenda Item 18.29 : Generic Group Management, Exposure and Communication Enhancements [GMEC]

Technical Differences among the TDoc Snippets:

- TDoc C3-231149 and TDoc C3-231150 are nearly identical, with the only difference being that TDoc C3-231150 includes an additional required field for SmPolicyDnnDataPatch.
- TDoc C3-231149 and TDoc C3-231150 both define umLevel, allowedUsage, resetTime, suppFeat, resetIds, LimitIdToMonitoringKey, transPolicy, bdtpStatus, SlicePolicyData, BdtData, online, and chfInfo.
- TDoc C3-231149 and TDoc C3-231150 both use references to external schema files for some of their properties, such as UsageMonLevel and SupportedFeatures.
- TDoc C3-231344 defines a type object with properties for self, 5gLanParams, and suppFeat, as well as a required field for 5gLanParams and suppFeat.
- TDoc C3-231345 defines a schema for TscAppSessionContextData and includes responses for HTTP status codes 400, 401, and 403, as well as a header for Retry-After.

Examples from Original TDoc:

- TDoc C3-231149: resetIds includes a type array with items of type string and a minimum of one item required.
- TDoc C3-231149: LimitIdToMonitoringKey includes a description field for what the object contains.
- TDoc C3-231150: SmPolicyDnnDataPatch is a required field in this document but not in TDoc C3-231149.
- TDoc C3-231344: The suppFeat property is a reference to the SupportedFeatures schema defined in TS29571_CommonData.yaml.
- TDoc C3-231345: The Location header is included in the successful response and contains the URI of the created resource.

TDoc C3-231196:

- This TDoc defines the NEF Northbound APIs for interaction with the AF.
- It includes a Table 5.1-1 with API descriptions.
- The introduction explains that these APIs relate to procedures and resources for interaction between the NEF and AF.

Example snippet: "The NEF Northbound APIs are a set of APIs defining the related procedures and resources for the interaction between the NEF and the AF."

TDoc C3-231197:

- This TDoc is from a specific meeting (TSG-CT3 Meeting #127e) held in April 2023.
- It includes changes made during the meeting.

Example snippet: "3GPP TSG-CT3 Meeting #127e C3-231197 E-meeting, 17th - 21st April 2023"

TDoc C3-231198:

- This TDoc includes multiple sections with changes made throughout the document.
- There are several "Next changes" markers throughout the document.

Example snippet: "* Next changes * Next changes * Next changes"

Technical Differences between TDoc C3-231151 and TDoc C3-231194

TDoc C3-231151:

- Provides procedures using the Npcf_SMPolicyControl_Create service operation.
- Supports the creation of a corresponding SM Policy Association with the PCF.
- Allows provisioning of PCC rules.
- Facilitates provisioning of policy control request triggers.
- Supports provisioning of charging related information for a PDU session.
- Allows provisioning of revalidation time.
- Enables policy provisioning and enforcement of authorized AMBR per PDU session.
- Enables policy provisioning and enforcement of authorized default QoS.
- Supports provisioning of PCC rule for Application Detection and Control.
- Supports 3GPP PS Data Off Support.
- Provides IMS Emergency Session Support.
- Facilitates Request Usage Monitoring Control.
- Enables Access Network Charging Identifier report.
- Facilitates Request and report of the successful resource allocation notification.
- Allows negotiation of the QoS flow for IMS signalling.
- Facilitates Notification about Service Data Flow QoS target enforcement.
- Enables Request and report of the result of PCC rule removal.
- Allows Access Network Charging Identifier Request and report.
- Supports Application detection information reporting.

Example snippet from TDoc C3-231151: "Policy provisioning and enforcement of authorized default QoS."

TDoc C3-231194:

- Provides a new GMEC related use case of DNN and S-NSSAI specific group parameters provisioning.
- Does not require defining a new API for any future use case.
- Provides a new NEF parameter provision API.
- However, implementing many APIs for a single stage 2 API is not desirable and not aligned with the service based guidelines defined in TS 23.501.

Example snippet from TDoc C3-231194: "For any future use case, there will be no need to define a new API."

In summary, TDoc C3-231151 provides procedures for policy control and charging management, while TDoc C3-231194 focuses on the support of a new use case of DNN and S-NSSAI specific group parameters provisioning. TDoc C3-231194 does not require defining a new API for any future use case but provides a new NEF parameter provision API, which may lead to the implementation of many APIs for a single stage 2 API, contrary to the service-based guidelines defined in TS 23.501.

3GPP-C3-127-e    Agenda Item 18.30 : CT aspects for the architectural enhancements for 5G Multicast-Broadcast services Phase 2 [5MBS_Ph2]

Summary:

- TDoc C3-231217 defines NEF Northbound APIs for interaction between NEF and AF. It includes API descriptions.
- TDoc C3-231218 describes procedures used by an external/untrusted AF to manage MBS User Services via NEF.
- TDoc C3-231219 describes procedures used by an external/untrusted AF to manage MBS User Data Ingest Session along with its subordinate MBS Distribution Session(s) via NEF. It includes creating, retrieving, updating, and deleting MBS User Data Ingest Session, creating, retrieving, updating, and deleting MBS User Data Ingest Session Status subscription, and managing related MBS User Data Ingest Session Status notifications.
- TDoc C3-231220 includes table 5.2.2.1-1 that shows service operations defined for Nmbsf_MBSUserService service.

Examples:

- TDoc C3-231217: "The NEF Northbound APIs are a set of APIs defining the related procedures and resources for the interaction between the NEF and the AF." (Introduction)
- TDoc C3-231218: "The procedures described in the clauses below are used by an external/untrusted AF (e.g. MBS Application Provider that lies outside the trusted DN) to manage MBS User Services via the NEF..." (Introduction)
- TDoc C3-231219: "The procedures described in the clauses below are used by an external/untrusted AF (e.g. MBS Application Provider that lies outside the trusted DN) to manage an MBS User Data Ingest Session along with its subordinate MBS Distribution Session(s) via the NEF..." (Introduction)
- TDoc C3-231220: "The service operations defined for the Nmbsf_MBSUserService service are shown in table 5.2.2.1-1." (Introduction)

TDoc C3-231221:

- Defines service operations for Nmbsf_MBSUserDataIngestSession service
- Table 5.3.2.1-1 shows the service operations defined for the service

Example snippet: "The service operations defined for the Nmbsf_MBSUserDataIngestSession service are shown in table 5.3.2.1-1."

TDoc C3-231222:

- Describes MBS interworking protocol stack used in Nmb8 reference point with TCP/IP for Object Distribution Method
- Describes MBS interworking protocol stack used in Nmb9 reference point and the MBSTF interworking with the MBS AF/AS the Nmb8 reference point with UDP/IP for Packet Distribution Method with Proxy mode or Forward-only mode
- Describes MBS interworking protocol stack used in Nmb9 reference point and the MBSTF interworking with the MBS AF/AS the Nmb8 reference point with RTP/UDP/IP for Packet Distribution Method with RTP streaming mode
- Depicts the MBS interworking architecture in Figure 20.2-1
- Figure 20.3-2 shows the User Plane Protocol Stack for N6mb (plain IP multicast)

Example snippet: "The MBS interworking protocol stack used in Nmb8 reference point with TCP/IP for Object Distribution Method is described in Figure 20.4-1, with UDP/IP for Packet Distribution Method with Proxy mode or Forward-only mode is described in Figure 20.4-2 with RTP/UDP/IP for Packet Distribution Method with RTP streaming mode is described in Figure 20.4-3."

TDoc C3-231380:

- Specifies the data types defined for the MBSSession API in Table 5.20.5.1-1
- Table 5.20.5.1-2 specifies data types re-used by the MBSSession API from other specifications
- Table 5.20.6-1 shows the supported features for the MBSSession API

Example snippet: "Table 5.20.5.1-1 specifies the data types defined for the MBSSession API. Table 5.20.6-1: Supported Features."

TDoc C3-231403:

- Defines NEF Northbound APIs for interaction between the NEF and the AF
- Table 5.1-1 summarizes the APIs defined in the specification

Example snippet: "Tables 5.1-1 summarizes the APIs defined in this specification."

Technical Differences:

1. The first snippet contains an object with properties related to MBS distribution session, while the second snippet represents additional MBS distribution session parameters for the case of Packet Distribution Method.
Example from TDoc C3-231120:
- PacketDistrMethInfo has a property pckIngMethod that is not present in the first snippet.

2. The first snippet has an array of object acquisition IDs, while the second snippet has an object with an MBStfIngestAddr property.
Example from TDoc C3-231120:
- objAcqIds is an array of object URIs in the first snippet, while ingEndpointAddrs is an object with an array of MBStf ingest addresses in the second snippet.

3. The first snippet includes an object representing an MBS User Data Ingest Session Status Subscription, while the second snippet does not contain any similar objects.
Example from TDoc C3-231120:
- MBSUserDataIngStatSubsc is an object that represents MBS User Data Ingest Session Status Subscription in the first snippet.

4. The first snippet has a required property objRepairUri, while the second snippet does not have any required properties related to repair URIs.
Example from TDoc C3-231120:
- objRepairUri is a required property in the first snippet.

5. The first snippet has a reference to TS29571_CommonData.yaml, while the second snippet has references to TS29581_Nmbstf_DistSession.yaml.
Example from TDoc C3-231120:
- The first snippet has references to CommonData.yaml components, while the second snippet has references to Nmbstf_DistSession.yaml components.


Example snippets from TDoc C3-231120:
- "objAcqIds: type: array items: $ref: 'TS29571_CommonData.yaml#/components/schemas/Uri' minItems: 1"
- "PacketDistrMethInfo: description: > Represents additional MBS Distribution Session parameters for the case of Packet Distribution Method. type: object properties: operatingMode: $ref: 'TS29581_Nmbstf_DistSession.yaml#/components/schemas/PktDistributionOperatingMode' pckIngMethod: $ref: 'TS29581_Nmbstf_DistSession.yaml#/components/schemas/PktIngestMethod' ingEndpointAddrs: $ref: 'TS29581_Nmbstf_DistSession.yaml#/components/schemas/MbStfIngestAddr'"
- "MBSUserDataIngStatSubsc: description: > Represents an MBS User Data Ingest Session Status Subscription."
- "objRepairUri: $ref: 'TS29571_CommonData.yaml#/components/schemas/Uri'"
- "$ref: 'TS29571_CommonData.yaml#/components/responses/307'"
- "$ref: 'TS29581_Nmbstf_DistSession.yaml'"

Technical Differences and Example Snippets:

1. Requesting MBS Session Creation:
- TDoc C3-231119 uses the HTTP POST method to request the creation of an MBS Session.
- The request message body should include the MbsSessionCreateReq data structure with attributes for AF identifier and MBS session characteristics.
- If the request also includes creating a subscription to MBS session status events, the NEF creates a corresponding "Individual MBS Session Subscription" resource and returns a representation of it in the HTTP POST response body.

2. Modifying PCF for MBS Session Binding:
- TDoc C3-231240 uses the HTTP PATCH method to modify the PCF for an MBS Session binding.
- The request should target the URI of the concerned "Individual PCF for an MBS Session Binding" resource with the request body containing the PcfMbsBindingPatch data structure including the requested modifications.
- Upon successful modification, the BSF responds with either an HTTP "200 OK" status code with a representation of the updated "Individual PCF for an MBS Session Binding" resource or an HTTP "204 No Content" status code.
- If an invalid combination of query parameters is contained in the request URI, the BSF responds with an HTTP "400 Bad Request" error code containing "MANDATORY_QUERY_PARAM_MISSING" as application error within the ProblemDetails IE.

Example Snippets:
- TDoc C3-231119: "an AF shall send a Nnef_MBSSession_Create request to the NEF using the HTTP POST method"
- TDoc C3-231119: "the MbsSessionCreateReq data structure that shall contain...the identifier of the AF that is sending the request"
- TDoc C3-231119: "the characteristics of the MBS session that is to be created"
- TDoc C3-231240: "an HTTP PATCH request targeting the URI of the concerned 'Individual PCF for an MBS Session Binding' resource"
- TDoc C3-231240: "the request body containing the PcfMbsBindingPatch data structure including the requested modifications"
- TDoc C3-231240: "an HTTP '200 OK' status code with the response body containing a representation of the updated 'Individual PCF for an MBS Session Binding' resource within the PcfMbsBinding data structure"

3GPP-C3-127-e    Agenda Item 18.31 : CT aspects of System Support for AI/ML-based Services [AIMLsys]

Technical differences among the TDoc snippets:

- TDoc C3-231031: Specifies the data transfer policy control services offered by the PCF and provides corresponding APIs. It also references other documents that constitute provisions of the present document.
- TDoc C3-231032: Defines the resource definition and URI variables for a specific resource.
- TDoc C3-231033: References different documents that constitute provisions of the present document.
- TDoc C3-231034: Provides data structures for different purposes, such as usage monitoring, limit identification, and policy data patch.
- TDoc C3-231039: Provides data structures for different purposes, such as usage monitoring level, allowed usage, and supported features.
- TDoc C3-231041: Provides references to different documents that constitute provisions of the present document and specifies different services and features supported by the API.
- TDoc C3-231185: Provides data structures for ranking criteria, dispersion information, and event reporting requirement.
- TDoc C3-231186: Defines the type PerformanceDataInfo and supported features for the Nnef_EventExposure API.
- TDoc C3-231187: Provides data structures for ranking criteria, dispersion information, and event reporting requirement.
- TDoc C3-231188: Provides data structures for scheduled communication, UE location info, and UE mobility exposure.
- TDoc C

TDoc C3-231423:

- RankingCriterion contains properties highBase and lowBase that reference SamplingRatio from TS29571_CommonData.yaml.
- DispersionInfo contains properties snssai and nsiIds that reference Snssai and NsiId from TS29571_CommonData.yaml and TS29531_Nnssf_NSSelection.yaml respectively.
- EventReportingRequirement contains properties number, variance and skewness that reference Float from TS29571_CommonData.yaml.
- AnalyticsSubscriptionsTransfer contains no unique properties.

TDoc C3-231426:

- Has the same structure and properties as TDoc C3-231423.

TDoc C3-231427:

- Contains property lastOutputTime that references DateTime from TS29571_CommonData.yaml.
- Contains property aggrSubs that references SpecificAnalyticsSubscription from the same TDoc.

TDoc C3-231428:

- Contains property ts that references DateTime from TS29122_CommonData.yaml.
- Contains property recurringTime that references ScheduledCommunicationTime from TS29122_CpProvisioning.yaml.
- Contains property durationVariance that references Float from TS29571_CommonData.yaml.
- Contains property locInfo that references UeLocationInfo, which contains properties anyUeInd, gpsi, and exterGroupId from TS29571_CommonData.yaml and ExternalGroupId from TS29122_CommonData.yaml.
- Contains content for UeMobilityExposure, which references ProblemDetailsAnalyticsInfoRequest from TS29520_Nnwdaf_AnalyticsInfo.yaml.

Example snippets from TDoc C3-231423:

- highBase: $ref: 'TS29571_CommonData.yaml#/components/schemas/SamplingRatio'
- DispersionInfo: description: > Represents the Dispersion information. type: object properties: snssai: $ref: 'TS29571_CommonData.yaml#/components/schemas/Snssai'
- number: $ref: 'TS29571_CommonData.yaml#/components/schemas/Float'
- AnalyticsSubscriptionsTransfer: description: Contains information about a request to transfer analytics subscriptions. type: object properties: NUM_OF_UE:

Example snippets from TDoc C3-231427:

- lastOutputTime: $ref: 'TS29571_CommonData.yaml#/components/schemas/DateTime'
- aggrSubs: type: array items: $ref: '#/components/schemas/SpecificAnalyticsSubscription'

Example snippets from TDoc C3-231428:

- ts: $ref: 'TS29122_CommonData.yaml#/components/schemas/DateTime'
- recurringTime: $ref: 'TS29122_CpProvisioning.yaml#/components/schemas/ScheduledCommunicationTime'
- durationVariance: $ref: 'TS29571_CommonData.yaml#/components/schemas/Float'
- locInfo: type: array items: $ref: '#/components/schemas/UeLocationInfo'
- anyUeInd: type: boolean
- gpsi: $ref: 'TS29571_CommonData.yaml#/components/schemas/Gpsi'
- exterGroupId: $ref: 'TS29122_CommonData.yaml#/components/schemas/ExternalGroupId'
- UeMobilityExposure: description: Represents a UE mobility information. content: application/problem+json: schema: $ref: 'TS29520_Nnwdaf_AnalyticsInfo.yaml#/components/schemas/ProblemDetailsAnalyticsInfoRequest'

Technical differences among the following TDoc:

[TDoc C3-231317]:
- Definition of type AnalyticsEventNotif has a 2nd change
- Definition of type AnalyticsEventFilterSubsc has a 5.6.3.3.6 Type
- Definition of type AnalyticsData has a 5th and 3rd change
- Definition of type AnalyticsEventFilter has a 3rd change
- Features used by AnalyticsExposure API are listed in Table 5.6.4-1

[TDoc C3-231372]:
- Definition of type AnalyticsData has a 5.2.6.2.2 Type
- Supported features for the Nnwdaf_AnalyticsInfo API are listed in Table 5.2.8-1

[TDoc C3-231424]:
- Supported features for the Nnwdaf_AnalyticsInfo API are listed in Table 5.2.8-1

[TDoc C3-231433]:
- No technical differences mentioned

Examples from the original TDocs to support the difference highlighting:

[TDoc C3-231317]:
- In Table 5.6.3.3.4-1, the definition of AnalyticsEventNotif has a 2nd change.
- In Table 5.6.3.3.6-1, the definition of AnalyticsEventFilterSubsc has a 5.6.3.3.6 Type.
- In Table 5.6.3.3.14-1, the definition of AnalyticsData has a 5th and 3rd change.
- In Table 5.6.3.3.13-1, the definition of AnalyticsEventFilter has a 3rd change.
- Table 5.6.4-1 lists the features used by AnalyticsExposure API.

[TDoc C3-231372]:
- In Table 5.2.6.2.2-1, the definition of AnalyticsData has a 5.2.6.2.2 Type.
- Table 5.2.8-1 lists the supported features for the Nnwdaf_AnalyticsInfo API.

[TDoc C3-231424]:
- Table 5.2.8-1 lists the supported features for the Nnwdaf_AnalyticsInfo API.

[TDoc C3-231433]:
- No examples provided.

• TDoc C3-231189:
- If "ServiceExperience" feature is supported and event is "SERVICE_EXPERIENCE", then identification of target UE(s) is provided by "supis", "intGroupIds" or "anyUe" attribute in "tgt-ue" attribute.
- "event-filter" attribute contains event-specific filter information, including slices indication in "anySlice" attribute or identification of network slice(s) with network slice instance(s) if available via "nsiIdInfos" attribute.

Example from the TDoc:
- "Contains information identifying the ML model(s) that the consumer NWDAF is currently subscribing for the analytics" in "modelInfo" array.
- "Contains context information corresponding with a specific context identifier" in "ContextElement" attribute.

• TDoc C3-231316:
- If "ServiceExperience" feature is supported and event is "SERVICE_EXPERIENCE", then identification of target UE(s) is provided by "supis", "intGroupIds" or "anyUe" attribute in "tgt-ue" attribute.
- "event-filter" attribute contains event-specific filter information, including slices indication in "anySlice" attribute or identification of network slice(s) with network slice instance(s) if available via "nsiIdInfos" attribute.
- NF service consumer sends an HTTP GET request on the resource URI to request analytics data according to the query parameter value of the "event-id" attribute.

Example from the TDoc:
- "The transactions dispersion information collected as 'transacInfos' attribute" for transactions dispersion collection.

• TDoc C3-231425:
- For transactions dispersion collection, "transacInfos" attribute contains transactions dispersion information.
- If "RedundantTransmissionExp" feature is supported, then "pduSessInfos" attribute contains information about User Plane status.

Example from the TDoc:
- UE IP address is provided as "ueIpAddr" attribute if it is available and requested in the subscription.

• TDoc C3-231429:
- NWDAF may invoke "Nsmf_EventExposure_Subscribe" service operation by sending an HTTP POST request targeting the resource "SMF Notification Subscriptions" to subscribe to the notification of QFI, IP filter information, DNAI, UPF information, Application ID, DNN, and S-NSSAI.
- If AF is trusted, NWDAF may invoke "Naf_EventExposure_Subscribe" service operation by sending an HTTP POST request targeting the resource "Application Event Subscriptions" to request the service data and performance data from AF directly.
- If AF is untrusted, NWDAF may invoke "Nnef_EventExposure_Subscribe" service operation to the NEF by sending an HTTP POST request targeting the resource "Network Exposure Event Subscriptions", and then NEF invokes "Naf_EventExposure_Subscribe" service operation by sending an HTTP POST request targeting the resource "Application Event Subscriptions".
- If step 6a and step 6b are performed, AF may invoke "Naf_EventExposure_Notify" service operation by sending an HTTP POST request to NWDAF identified by the notification URI received in step 6a.
- If step 1a is performed, NWDAF responds to "Nnwdaf_AnalyticsInfo_Request" service operation as described in clause 5.2.3.1.

Example from the TDoc:
- If SMF decides to buffer the packets, the subscribed event with delivery status "BUFFERED" occurred.
- URI for further AF acknowledgement is provided in the "ackUri" attribute if SMF determines to wait for the AF acknowledgement before activating the new UP path associated with the new DNAI.

3GPP-C3-127-e    Agenda Item 18.32 : Architecture Enhancements for XR and media services [XRM]

[TDoc C3-231384]:
- boolean description indicating EAS rediscovery requirement
- maxAllowedUpLat with reference to 'TS29571_CommonData.yaml#/components/schemas/UintegerRm'
- tfcCorreInfo with reference to 'TS29522_TrafficInfluence.yaml#/components/schemas/TrafficCorrelationInfo'
- nullable AnGwAddress with description and required property
- responses for HTTP status codes 400, 401, and 403 with references to 'TS29571_CommonData.yaml#/components/responses/400', 'TS29571_CommonData.yaml#/components/responses/401', and an ExtendedProblemDetails schema
- headers for Retry-After with a property for startTime and stopTime
- QosNotificationControlInfo with description and indication of QoS targets
- Example snippet: AnGwAddress with description and required property

[TDoc C3-231386]:
- content for successful update of subscription with application/json schema reference
- responses for HTTP status codes 204, 307, 308, 400, 401, and 403 with references to 'TS29122_CommonData.yaml#/components/responses/307', 'TS29122_CommonData.yaml#/components/responses/308', 'TS29122_CommonData.yaml#/components/responses/400', and a ProblemDetailsAsSessionWithQos schema
- headers for Retry-After with a notificationDestination property
- tscQosReq with reference to '#/components/schemas/TscQosRequirementRm'
- events with description and updated list of user plane event(s)
- Example snippet: notificationDestination with schema reference

[TDoc C3-231387]:
- ascReqData with reference to '#/components/schemas/AppSessionContextUpdateData'
- boolean description indicating EAS rediscovery requirement
- maxAllowedUpLat with reference to 'TS29571_CommonData.yaml#/components/schemas/UintegerRm'
- tfcCorreInfo with reference to 'TS29522_TrafficInfluence.yaml#/components/schemas/TrafficCorrelationInfo'
- nullable AnGwAddress with description and required property
- requestBody for deletion of Individual Application Session Context resource with description and reference to '#/components/schemas/EventsSubscReqData'
- responses for HTTP status code 200 with description
- Example snippet: ascReqData with description and reference to AppSessionContextUpdateData

[TDoc C3-231389]:
- required property with type string
- responses for HTTP status codes 400, 401, and 403 with references to 'TS29571_CommonData.yaml#/components/responses/400', 'TS29571_CommonData.yaml#/components/responses/401', and an ExtendedProblemDetails schema
- headers for Retry-After with properties for periodicity, burstArrivalTime, surTimeInNumMsg, surTimeInTime, and burstArrivalTimeWnd
- periodicityRange with reference to '#/components/schemas/PeriodicityRange'
- nullable AppDetectionReport with description indicating start or stop of detected application traffic and application identifier
- Example snippet: headers for Retry-After with properties for periodicity, burstArrivalTime, surTimeInNumMsg, surTimeInTime, and burstArrivalTimeWnd

TDoc C3-231368:
- AF must include a reference to alternative individual QoS related parameter(s) in "altQosParamSetRef" attribute.
- AF must include at least one of the following: guaranteed bandwidth in uplink and downlink, requested packet delay budget, or requested packet error rate (if ExtQoS_5G feature is supported).
- NEF may provision QoS requirements and subscribe to QOS_GUARANTEED and QOS_NOT_GUARANTEED events using Ntsctsf_QoSandTSCAssistance_Create request in 3GPP TS 29.565.
- NEF shall notify the AF with QOS_GUARANTEED event or QOS_NOT_GUARANTEED event and currently applied QoS reference if received.

TDoc C3-231382:
- NF service consumer shall supply source and destination IP addresses and port numbers in "fDescs" attribute for IP type PDU session (if available).
- NF service consumer shall supply Ethernet Packet filters in "ethfDescs" attribute for Ethernet type PDU session (if available).
- If service information is rejected, PCF shall indicate in an HTTP "403 Forbidden" response message with "cause" attribute set to "REQUESTED_SERVICE_NOT_AUTHORIZED".
- NF service consumer shall provide corresponding service information in "medComponents" attribute (if available).
- Subscription to reallocation of credit notification.

TDoc C3-231385:
- AF must include a reference to alternative individual QoS related parameter(s) in "altQosParamSetRef" attribute.
- AF must include at least one of the following: guaranteed bandwidth in uplink and downlink, requested packet delay budget, or requested packet error rate (if ExtQoS_5G feature is supported).
- NEF may provision QoS requirements and subscribe to QOS_GUARANTEED and QOS_NOT_GUARANTEED events using Ntsctsf_QoSandTSCAssistance_Create request in 3GPP TS 29.565.
- NEF shall notify the AF with QOS_GUARANTEED event or QOS_NOT_GUARANTEED event and currently applied QoS reference if received.

TDoc C3-231388:
- AF must include a reference to alternative individual QoS related parameter(s) in "altQosParamSetRef" attribute.
- AF must include at least one of the following: guaranteed bandwidth in uplink and downlink, requested packet delay budget, or requested packet error rate (if ExtQoS_5G feature is supported).
- NEF may provision QoS requirements and subscribe to QOS_GUARANTEED and QOS_NOT_GUARANTEED events using Ntsctsf_QoSandTSCAssistance_Create request in 3GPP TS 29.565.
- NEF shall notify the AF with QOS_GUARANTEED event or QOS_NOT_GUARANTEED event and currently applied QoS reference if received.

Example from TDoc C3-231368:
"If the NEF authorizes the AF request, and if the "TSC_5G" feature is supported, the NEF may provision the received QoS requirements and subscribe with the TSCTSF to "QOS_GUARANTEED" and "QOS_NOT_GUARANTEED" events by invoking the Ntsctsf_QoSandTSCAssistance_Create request as defined in 3GPP TS 29.565."

Example from TDoc C3-231382:
"If service information provided in the body of the HTTP POST request is rejected (e.g. the subscribed guaranteed bandwidth for a particular user is exceeded or the authorized data rate in that slice for a UE is exceeded), the PCF shall indicate in an HTTP "403 Forbidden" response message the cause for the rejection including the "cause" attribute set to "REQUESTED_SERVICE_NOT_AUTHORIZED"."

Example from TDoc C3-231385:
"When the NEF receives the event notification from the TSCTSF, the NEF shall notify the AF with "QOS_GUARANTEED" event or with "QOS_NOT_GUARANTEED" event and the currently applied QoS reference if received."

Example from TDoc C3-231388:
"If the NEF authorizes the AF request, and if the "TSC_5G" feature is supported, the NEF may provision the received QoS requirements and subscribe with the TSCTSF to "QOS_GUARANTEED" and "QOS_NOT_GUARANTEED" events by invoking the Ntsctsf_QoSandTSCAssistance_Create request as defined in 3GPP TS 29.565."

Technical Differences Among TDoc C3-231166, C3-231170, and C3-231324

TDoc C3-231166 and C3-231170:

- Both TDcos contain the same procedures using the Npcf_PolicyAuthorization_Create service operation, which includes initial provisioning of service information, gate control, and initial background data transfer policy indication.
- Both TDcos support various network functions and services such as 5G Residential Gateway, access traffic steering, switching and splitting, charging function, and device-side TSN translator.
- Both TDcos include GPSI (provisioning of TSCAI input information and TSC QoS related data) and provisioning of TSC user plane node management information and port management information.

Example from TDoc C3-231166: "The following procedures using the Npcf_PolicyAuthorization_Create service operation are supported: - Initial provisioning of service information. - Gate control. - Initial Background Data Transfer policy indication."

Example from TDoc C3-231170: "The following procedures using the Npcf_PolicyAuthorization_Create service operation are supported: - Initial provisioning of service information. - Gate control. - Initial Background Data Transfer policy indication."

Example from both TDocs: "GPSI - Provisioning of TSCAI input information and TSC QoS related data. - Provisioning of TSC user plane node management information and port management information."

TDoc C3-231324:

- TDoc C3-231324 updates the Nnef_AFsessionWithQoS_Create service in 3GPP TS 29.122 and PCF services in 3GPP TS 29.512 with CT3 responsibility.
- TDoc C3-231324 impacts PCC signaling flows in 3GPP TS 29.513 with CT3 responsibility.
- TDoc C3-231324 extends the Npcf_PolicyAuthorization service in 3GPP TS 29.514 with Nokia, Nokia Shanghai Bell, and China Mobile CT3 responsibility.
- TDoc C3-231324 supports 5GS information exposure for XR/media enhancements, extends NEF northbound in 3GPP TS 29.522 to expose 5GS information to AF, and extends Nsmf_EventExposure service in 3GPP TS 29.508 with China Mobile CT3 responsibility.
- TDoc C3-231324 also supports power saving optimization and extends NEF northbound in 3GPP TS 29.522 to support AF requirements provision with China Mobile responsibility.

Example from TDoc C3-231324: "Extend NEF northbound in 3GPP TS 29.522 to expose 5GS information to AF (e.g. data rate, congestion information, round trip delay, etc) China Mobile, Huawei CT3 responsibility."

In summary, TDocs C3-231166 and C3-231170 offer similar procedures and network functions, while TDoc C3-231324 focuses on updates and extensions to various services with specific responsibilities assigned to different entities.

3GPP-C3-127-e    Agenda Item 18.34 : CT aspects of Application layer support for Personal IoT Network [PINAPP]

3GPP-C3-127-e    Agenda Item 18.35 : CT aspects on 5G AM Policy [AMP]

3GPP-C3-127-e    Agenda Item 18.38 : CT aspects of Application Data Analytics Enablement Service [ADAES]

3GPP-C3-127-e    Agenda Item 18.39 : CT aspects of Access Traffic Steering, Switching and Splitting support in 5G system – Phase 3 [ATSSS_Ph3]

- The two TDocs share the same content and are identical.
- The TDocs define an object called UpPathChgEvent which contains a notification URI and a notification correlation ID.
- The notification correlation ID is used to set the value of Notification Correlation ID in the notification sent by the SMF.
- Both TDocs define a response code of 308 Permanent Redirect which contains a header called Location.
- The Location header contains the URI of the PCF within the existing PCF binding information stored in the BSF for the same UE ID, S-NSSAI and DNN combination.
- The response also contains an array of InvalidParam items, which indicate the invalid parameters for the reported type(s) of the failed policy decision and/or condition data.
- Both TDocs include a property called altQosParamId which indicates the alternative QoS parameter set that the NG-RAN can guarantee.
- The TDocs reference a common data schema called TS29571_CommonData.yaml for the Uri and InvalidParam properties.

Example snippet from the TDoc:

```
UpPathChgEvent:
description: Contains the UP path change event subscription from the AF.
type: object
properties:
notificationUri:
$ref: 'TS29571_CommonData.yaml#/components/schemas/Uri'
notifCorreId:
type: string
description: >-
It is used to set the value of Notification Correlation ID in the notification sent by the SMF.
required: true
schema: type: string
'308':
description: Permanent Redirect
headers:
Location:
description: >-
Contains the URI of the PCF within the existing PCF binding information stored in the BSF for the same UE ID, S-NSSAI and DNN combination.
array:
items:
$ref: 'TS29571_CommonData.yaml#/components/schemas/InvalidParam'
minItems: 1
description: >-
Indicates the invalid parameters for the reported type(s) of the failed policy decision and/or condition data.
altQosParamId:
type: string
description: >-
Indicates the alternative QoS parameter set that the NG-RAN can guarantee.
```

3GPP-C3-127-e    Agenda Item 18.40 : CT aspects of Personal IoT Network [PIN]

3GPP-C3-127-e    Agenda Item 18.41 : CT aspects of UPF enhancement for exposure and SBA [UPEAS]

TDoc C3-231075:
- Contains instructions related to the processing of notifications.
- Has a property called areas that indicates the Areas of Interest for which processed reports are requested.
- Contains a property called fetchInstruct which includes a list of reports with summarized data from multiple notifications.
- Includes a property called dataNotifCorrId which is the notification correlation identifier.
- Has a component called NdccfDataSubscriptionNotification which represents a notification for a DCCF data subscription.
- Contains a property called anaSpec which is a component that contains data or analytics formatting instructions.

TDoc C3-231076:
- Contains a property called dataSub which is a component that contains a data specification.
- Includes a property called anaNotifications which is a list of analytics subscription notifications.
- Has a component called DataSubscription which contains a data specification.

TDoc C3-231356:
- Contains a component called AsSessionWithQoSSubscription which is a schema for a successful update of the subscription.
- Includes a property called notificationDestination which is a link to the notification destination.
- Contains a component called TscQosRequirementRm which defines the TSC QoS requirements.

TDoc C3-231358:
- Includes a property called EasRediscReq which indicates whether the EAS rediscovery is required.
- Contains a component called TrafficCorrelationInfo which describes the traffic correlation information.
- Includes a property called AnGwAddress which describes the address of the access network gateway control node.

Example snippets:
- minClubbedNotif and maxClubbedNotif are defined using references to schemas in TS29571_CommonData.yaml in TDoc C3-231075.
- The areas property in TDoc C3-231075 is defined as an array of components called NetworkAreaInfo from TS29554_Npcf_BDTPolicyControl.yaml.
- The anaSub property in TDoc C3-231076 is defined using a reference to a schema in TS29520_Nnwdaf_EventsSubscription.yaml.
- The AsSessionWithQoSSubscription component in TDoc C3-231356 is defined using a reference to a schema in TS29122_CommonData.yaml.
- The TrafficCorrelationInfo component in TDoc C3-231358 is defined in TS29522_TrafficInfluence.yaml.

1. TDoc C3-231444 allows the PCF to receive TSC user plane node management information and port management information from the NF service consumer during the lifetime of a PDU session enabling Time Sensitive Communications, Time Synchronization and Deterministic Networking, while TDoc C3-231445 allows the NF service consumer to provision or update the same information at any time.

- TDoc C3-231444: "the PCF may receive from the NF service consumer TSC user plane node management information and/or, when the DS-TT or the NW-TT functions are used, port management information for a port located in DS-TT and/or NW-TT."
- TDoc C3-231445: "the NF service consumer may provision or update, at any time, TSC user plane node management information and/or, when the DS-TT or the NW-TT functions are used, port management information for a port located in DS-TT and/or NW-TT."

2. TDoc C3-231444 specifies the procedures using the Npcf_PolicyAuthorization_Create service operation that are supported for initial provisioning of service information, gate control, and initial Background Data Transfer policy indication, while TDoc C3-231445 lists various policy provisioning and enforcement procedures.

- TDoc C3-231444: "The following procedures using the Npcf_PolicyAuthorization_Create service operation are supported: - Initial provisioning of service information. - Gate control. - Initial Background Data Transfer policy indication."
- TDoc C3-231445: "Policy provisioning and enforcement of AF session with required QoS. - Provisioning of TSCAI input information and TSC QoS related data. - Policy provisioning of QoS Monitoring to assist URLLC Service. - Policy decision and condition data error handling. - Network slice related data rate policy control. - Request of Presence Reporting Area Change Report. - PCC Rule Error Report. - Session Rule Error Report."

3. TDoc C3-231445 includes the forwarding of TSC user plane node management information and port management information received from the TSN AF or TSCTSF, as well as other types of information such as policy control request triggers and session rule error reports.

- TDoc C3-231445: "Forwarding of TSC user plane node management information and port management information received from the TSN AF or TSCTSF. - Provisioning of policy control request triggers. - PCC Rule Error Report. - Session Rule Error Report."

Example snippet from TDoc C3-231444:
"The PCF shall use the Npcf_PolicyAuthorization_Create service operation to perform initial provisioning of service information, gate control, and initial Background Data Transfer policy indication."

Example snippet from TDoc C3-231445:
"The AF uses the Npcf_PolicyAuthorization_Create service operation to provision and enforce an AF session with the required QoS. The PCF shall forward the TSC user plane node management information and port management information received from the TSN AF or TSCTSF within the service information as defined in 3GPP TS 29.514 [17]."

TDoc C3-231357:

- TsnPortNumber, ApplicationDescriptor, and UePolicyContainer are all references to schemas defined in TS29571_CommonData.yaml.
- FlowDirection is a string enum that can take the values DOWNLINK, UPLINK, BIDIRECTIONAL, UNSPECIFIED. It also includes a forward-compatible placeholder enum value that is not used to encode content defined in the present version of the API.
- There are two array items, each referencing the same schema in TS29571_CommonData.yaml. They are used to indicate invalid parameters for failed policy decisions and/or condition data.
- appSvcProvId is a string that indicates the identity of the application service provider. It contains the UMIC.

Example snippets from TDoc C3-231357:

- "TsnPortNumber: $ref: 'TS29571_CommonData.yaml#/components/schemas/Uinteger'"
- "FlowDirection: anyOf: - type: string enum: - DOWNLINK - UPLINK - BIDIRECTIONAL - UNSPECIFIED - type: string description: > This string provides forward-compatibility with future extensions to the enumeration and is not used to encode content defined in the present version of this API."
- "array items: $ref: 'TS29571_CommonData.yaml#/components/schemas/InvalidParam' minItems: 1 description: > Indicates the invalid parameters for the reported type(s) of the failed policy decision and/or condition data."
- "appSvcProvId: type: string description: Indicates the application service provider identity. description: Contains the UMIC."

TDoc C3-231360:

- The content field requires an application/merge-patch+json schema that references the TscAppSessionContextUpdateData schema.
- The responses field includes a successful modification description and a requestBody field that requires a schema referencing TerminationInfo from TS29514_Npcf_PolicyAuthorization.yaml.
- altQosReqs is an array that references a schema in TS29514_Npcf_PolicyAuthorization.yaml. It identifies an ordered list of alternative service requirements that include individual QoS parameter sets.

Example snippets from TDoc C3-231360:

- "content: application/merge-patch+json: schema: $ref: '#/components/schemas/TscAppSessionContextUpdateData'"
- "requestBody: description: > Request of the termination of the Individual TSC Application Session Context required: true content: application/json: schema: $ref: 'TS29514_Npcf_PolicyAuthorization.yaml#/components/schemas/TerminationInfo'"
- "altQosReqs: type: array items: $ref: 'TS29514_Npcf_PolicyAuthorization.yaml#/components/schemas/AlternativeServiceRequirementsData' minItems: 1 description: > Identifies an ordered list of alternative service requirements that include individual QoS parameter sets."

3GPP-C3-127-e    Agenda Item 18.42 : CT aspects of Next Generation Real time Communication services [NG_RTC]

3GPP-C3-127-e    Agenda Item 18.43 : CT Aspect of Further Architecture Enhancement for UAV and UAM [UAS_Ph2]

- TDoc C3-231135 specifies the use of the Naf_Authentication_AuthenticateAuthorize service operation by NF consumers during UUAA-MM and UUAA-SM procedures, as well as C2 authorization.
- TDoc C3-231440 adds a discussion on the use of abbreviations in the document, and defines optional features for the Naf_Authentication API.
- TDoc C3-231135 specifically references TS 23.256, clause 5.2.5.2 for C2 authorization, while TDoc C3-231440 does not specify a clause.
- TDoc C3-231440 includes a table (5.1.8-1) of supported features for the Naf_Authentication API, while TDoc C3-231135 does not.
- TDoc C3-231135 includes references to UAS, UAS-NF, UAV, USS, and UUAA, while TDoc C3-231440 does not.
- TDoc C3-231135 has "End of changes" at the end of the document, indicating that it is a modified version of a previous document, while TDoc C3-231440 has "Next Change" and "Proposed changes" sections, suggesting that it is a working draft.

Example snippets from TDoc C3-231135 to support the highlighted differences:

- "The Naf_Authentication_AuthenticateAuthorize service operation is used by the NF consumers during following procedure: UUAA-MM and UUAA-SM procedures (see TS 23.256 [14], clause 5.2.2 and clause 5.2.3, respectively) - C2 authorization (see TS 23.256 [14], clause 5.2.5.2)"
- "AA Authorization/Authentication AF Application Function NEF Network Exposure Function UAS Uncrewed Aerial System UAS-NF Uncrewed Aerial System Network Function UAV Uncrewed Aerial Vehicle USS UAS Service Supplier UUAA USS UAV Authorization/Authentication"
- "End of changes"

Example snippets from TDoc C3-231440 to support the highlighted differences:

- "For the purposes of the present document, the abbreviations given in TR 21.905"
- "Supported Features"
- "Next Change" and "Proposed changes" sections

- The first TDoc (C3-231138) includes the property "ParamForProSeDd" which represents service parameters for 5G ProSe direct discovery, while the second TDoc (C3-231436) includes the property "ParameterOverUu" which represents configuration parameters for V2X communications over Uu reference point.
- The first TDoc includes the property "EventInfo" which indicates event information, while this property is not present in the second TDoc.
- In both TDocs, there is a property "appDescs" which describes the operation systems and corresponding applications for each operation system. The "additionalProperties" for this property refer to "TS29522_5GLANParameterProvision.yaml#/components/schemas/AppDescriptor."
- Both TDocs include the property "dnns," which is an array matched against the DNN information provided by the application.
- Both TDocs have the property "ethFlowDescs," which is an array for destination information of non-IP traffic in which only ethernet flow description is defined.
- Both TDocs include the property "spatialValidityTais," which is an array that indicates the TAIs in which the route selection parameters apply.

Example snippets from the TDocs:

- From C3-231138: "ParamForProSeDd: description: Represents the service parameters for 5G ProSe direct discovery. EventInfo: description: Indicates the event information."
- From C3-231138: "appDescs: type: object additionalProperties: $ref: 'TS29522_5GLANParameterProvision.yaml#/components/schemas/AppDescriptor' minProperties: 1 description: > Describes the operation systems and the corresponding applications for each operation systems."
- From C3-231436: "ParameterOverUu: description: > Represents configuration parameters for V2X communications over Uu reference point."
- From C3-231436: "dnns: type: array items: $ref: 'TS29571_CommonData.yaml#/components/schemas/Dnn' minItems: 1 description: This is matched against the DNN information provided by the application."
- From C3-231138: "ethFlowDescs: type: array items: $ref: 'TS29514_Npcf_PolicyAuthorization.yaml#/components/schemas/EthFlowDescription' minItems: 1 description: > Descriptor(s) for destination information of non-IP traffic in which only ethernet flow description is defined."
- From C3-231436: "spatialValidityTais: type: array items: $ref: 'TS29571_CommonData.yaml#/components/schemas/Tai' minItems: 1 description: > Indicates the TAIs in which the route selection parameters apply."

TDoc C3-231137:
- In step 2, if the UE does not provide necessary information, the H-PCF retrieves it from the UDR and uses it for determination of ANDSP and/or URSP provisioning.
- In step 1, if the UE does not provide necessary information but supports "UECapabilityIndication" feature, the V-PCF retrieves UE parameters from the H-PCF in step 8 and uses them for determination of ANDSP provisioning.
- The AMF forwards the UE response to the V-PCF using Namf_Communication_N1MessageNotify service operation when receiving the UE Policy container in step 21.

TDoc C3-231139:
- To request policies or update the Notification URI or renegotiate features or update the trace control configuration or request the termination of trace, the NF Service Consumer must provide relevant parameters about the UE context in an HTTP POST request with "{apiRoot}/npcf-ue-policy-control/v1/policies/{polAssoId}/update" as Resource URI and the PolicyAssociationUpdateRequest data structure.
- The PolicyAssociationUpdateRequest data structure includes a new Notification URI encoded in the "notificationUri" attribute or observed Policy Control Request Trigger(s).

TDoc C3-231438:
- Same as TDoc C3-231139.

TDoc C3-231439:
- The AF invokes the Nnef_ServiceParameter_Create service operation to the NEF to provide service-specific parameters (e.g. for URSP influence, V2X, 5G ProSe) to one or more UEs.
- The PCF retrieves service parameters from the UDR, determines UE policies based on them and other factors, and delivers the UE policies (including V2XP and/or 5G ProSeP) to the UE and corresponding V2X N2 PC5 and/or ProSe N2 PC5 policy to the NG-RAN during UE Policy Association Establishment procedure.

The technical differences between the two TDocs can be summarized as follows:

- TDoc C3-231035 includes a property named "multiAccCtrls" with a "type" of "object" and "additionalProperties" that reference a schema in another YAML file. This property identifies a list of multicast address access control information.
- TDoc C3-231437 includes the same "multiAccCtrls" property as TDoc C3-231035.

Example snippets from TDoc C3-231035 that support this difference:

```
multiAccCtrls:
type: object
additionalProperties: $ref: 'TS29522_IPTVConfiguration.yaml#/components/schemas/MulticastAccessControl'
minProperties: 1
description: >
Identifies a list of multicast address access control information.
```

- TDoc C3-231037 includes a property named "policDelivNotifUri" that references a schema in another YAML file.

Example snippets from TDoc C3-231035 that support this difference:

```
policDelivNotifUri: $ref: 'TS29571_CommonData.yaml#/components/schemas/Uri'
```

- TDoc C3-231437 includes the same "policDelivNotifUri" property as TDoc C3-231035.

Example snippets from TDoc C3-231437 that support this difference:

```
policDelivNotifUri: $ref: 'TS29571_CommonData.yaml#/components/schemas/Uri'
```

- Both TDocs include properties named "dnn" and "snssai" that reference schemas in another YAML file.
- Both TDocs include a property named "afAppId" with a "type" of "string".
- Both TDocs include a parameter named "supi" that references a schema in another YAML file.
- Both TDocs include a parameter named "supp-feat" that references a schema in another YAML file.
- Both TDocs include a response with a "schema" that references a schema in another YAML file.

Example snippets from both TDocs that support these similarities:

```
dnn: $ref: 'TS29571_CommonData.yaml#/components/schemas/Dnn'
snssai: $ref: 'TS29571_CommonData.yaml#/components/schemas/Snssai'
afAppId: type: string

- name: supi in: query
description: Identifies a user.
required: false
schema: $ref: 'TS29571_CommonData.yaml#/components/schemas/Supi'

- name: supp-feat in: query
description: Supported Features
required: false
schema: $ref: 'TS29571_CommonData.yaml#/components/schemas/SupportedFeatures'

responses:
'200':
description:
required: false
schema: $ref: 'TS29571_CommonData.yaml#/components/schemas/GroupId'
```

3GPP-C3-127-e    Agenda Item 18.45 : CT aspects for enabling MSGin5G Service phase 2 [5GMARCH_Ph2]

TDoc C3-231160:

- Defines the API for enabling the MSGin5G Service over MSGin5G-2/3/4 interfaces
- Contains the application layer architecture, functional requirements, procedures, and information flows necessary for MSGin5G Service
- Specifies the requirements for MSGin5G in 3GPP TS 22.262

Example snippet from TDoc C3-231160: "The present document specified the Application Programming Interface (API) for enabling the MSGin5G Service over MSGin5G-2/3/4 interfaces."

TDoc C3-231161:

- Specifies the data structures supported by POST request and response bodies on specific resources
- Lists MSGG_L3GDelivery and MSGG_N3GDelivery API specific data types

Example snippet from TDoc C3-231161: "Table 9.2.3.2.2-1: Data structures supported by the POST Request Body on this resource"

TDoc C3-231261:

- Lists services provided by the MSGin5G Message Gateway and corresponding service operations
- Summarizes the corresponding APIs defined in the specification

Example snippet from TDoc C3-231261: "Table 6.1-1 lists the services provided by the MSGin5G Message Gateway and corresponding service operations."

3GPP-C3-127-e    Agenda Item 18.47 : Stage 3 of Network Slicing Phase 3 [eNS_Ph3]

[TDoc C3-231125]:
- The NEF responds with a "404 Not Found" status code and a ProblemDetails data structure containing the "cause" attribute set to the "UE_NOT_FOUND" application error if no SUPI matching the provided UE information is found.
- The NEF retrieves the AF specific UE Identifier using the received SUPI and at least one of the Application Port ID, MTC Provider Information or AF Identifier information by invoking Nudm_SDM_Get service.
- The NEF responds to the AF with the received information, i.e. the AF specific UE Identifier represented as an External Identifier that was received from the UDM.
- If the NEF receives an error response from the UDM, the NEF responds to the AF with a proper error status code.

[TDoc C3-231229]:
- The AF may include packet filter descriptor(s) within the "dddTraDescriptors" attribute and the list of monitoring downlink data delivery status event(s) within the "dddStati" attribute when creating or updating a subscription to the resource "Individual Monitoring Event Subscription".
- The NEF subscribes the events to the appropriate UDM(s) within the network by invoking the Nudm_EventExposure_Subscribe service operation.
- Based on the received AF information and local authorization policy, the NEF derives the LCS client type with a suitable enumeration value for the AF location request.
- The NEF provides the derived LCS client type as the "externalClientType" attribute when invoking the Ngmlc_Location_ProvideLocation service operation to provide location information.
- The NEF allows for the deletion of an existing network slice reporting subscription.

Example snippets from TDoc C3-231125 to support the difference highlighting:
- "the NEF shall respond to the AF with a "404 Not Found" status code with the response body including a ProblemDetails data structure containing the "cause" attribute set to the "UE_NOT_FOUND" application error to indicate that the requested UE address is not found;"
- "the NEF shall interact with the UDM to retrieve the AF specific UE Identifier using the received SUPI and at least one of the Application Port ID, MTC Provider Information or AF Identifier information by invoking Nudm_SDM_Get service"
- "the NEF shall then respond to the AF with the received information, i.e. the AF specific UE Identifier represented as an External Identifier that was received from the UDM;"
- "if the NEF receives an error response from the UDM, the NEF shall respond to the AF with a proper error status code."

Example snippets from TDoc C3-231229 to support the difference highlighting:
- "the AF may additionally include packet filter descriptor(s) within the "dddTraDescriptors" attribute and the list of monitoring downlink data delivery status event(s) within the "dddStati" attribute;"
- "the NEF shall subscribe the events to the appropriate UDM(s) within the network by invoking the Nudm_EventExposure_Subscribe service operation as defined in clause 5.5.2.2 of 3GPP TS 29.503"
- "the NEF shall derive the LCS client type with a suitable enumeration value for the AF location request, to be provided as the "externalClientType" attribute when invoking the Ngmlc_Location_ProvideLocation service operation as defined in clause 6.1 of 3GPP TS 29.515"
- "to delete an existing network slice reporting subscription."

- TDoc C3-231036 specifies the following technical differences:
- The array items are defined as $ref: 'TS29512_Npcf_SMPolicyControl.yaml#/components/schemas/NwdafData'
- The minimum number of items in the array is 1
- The suppFeat property is defined as $ref: 'TS29571_CommonData.yaml#/components/schemas/SupportedFeatures'
- The required properties are notificationUri, suppFeat, and supi
- The PolicyAssociationUpdateRequest object includes a userLoc property defined as $ref: 'TS29571_CommonData.yaml#/components/schemas/UserLocation'
- The allowedSnssais property is an array of allowed S-NSSAIs for 3GPP access
- The pras property is an object containing the presence reporting area(s) for which reporting was requested
- Example snippets from TDoc C3-231036 to support these differences:
- array items: $ref: 'TS29512_Npcf_SMPolicyControl.yaml#/components/schemas/NwdafData' minItems: 1 suppFeat: $ref: 'TS29571_CommonData.yaml#/components/schemas/SupportedFeatures' required: - notificationUri - suppFeat - supi
- userLoc: $ref: 'TS29571_CommonData.yaml#/components/schemas/UserLocation'
- allowedSnssais: description: array of allowed S-NSSAIs for the 3GPP access.
- pras: type: object additionalProperties: $ref: 'TS29571_CommonData.yaml#/components/schemas/PresenceInfoRm'
- TDoc C3-231122 specifies the following technical differences:
- The array items are defined as $ref: 'TS29512_Npcf_SMPolicyControl.yaml#/components/schemas/NwdafData'
- The minimum number of items in the array is 1
- The suppFeat property is defined as $ref: 'TS29571_CommonData.yaml#/components/schemas/SupportedFeatures'
- The required properties are notificationUri, suppFeat, and supi
- The PolicyAssociationUpdateRequest object includes a userLoc property defined as $ref: 'TS29571_CommonData.yaml#/components/schemas/UserLocation'
- The allowedSnssais property is an array of allowed S-NSSAIs for 3GPP access
- The pras property is an object containing the presence reporting area(s) for which reporting was requested
- The object includes two additional properties, UE_SUBSCRIPTION and INSUFFICIENT_RES
- Example snippets from TDoc C3-231122 to support these differences:
- array items: $ref: 'TS29512_Npcf_SMPolicyControl.yaml#/components/schemas/NwdafData' minItems: 1 suppFeat: $ref: 'TS29571_CommonData.yaml#/components/schemas/SupportedFeatures' required: - notificationUri - suppFeat - supi
- userLoc: $ref: 'TS29571_CommonData.yaml#/components/schemas/UserLocation'
- allowedSnssais: description: array of allowed S-NSSAIs for the 3GPP access.
- pras: type: object additionalProperties: $ref: 'TS29571_CommonData.yaml#/components/schemas/PresenceInfoRm'
- UE_SUBSCRIPTION:
- INSUFFICIENT_RES:
- TDoc C3-231123 specifies the following technical differences:
- The array items are defined as $ref: 'TS29512_Npcf_SMPolicyControl.yaml#/components/schemas/NwdafData'
- The minimum number of items in the array is 1
- The suppFeat property is defined as $ref: 'TS29571_CommonData.yaml#/components/schemas/SupportedFeatures'
- The required properties are notificationUri, suppFeat, and supi
- The PolicyAssociationUpdateRequest object includes a pras property defined as an object containing the presence reporting area(s) for which reporting was requested
- The object includes a praStatuses property defined as an object containing the UE presence status for tracking area for which changes of the UE presence occurred
- Example snippets from TDoc C3-231123 to support these differences:
- array items: $ref: 'TS29512_Npcf_SMPolicyControl.yaml#/components/schemas/NwdafData' minItems: 1 suppFeat: $ref: 'TS29571_CommonData.yaml#/components/schemas/SupportedFeatures' required: - notificationUri - suppFeat - supi
- pras: type: object additionalProperties: $ref: 'TS29571_CommonData.yaml#/components/schemas/PresenceInfoRm'
- praStatuses: type: object additionalProperties: $ref: 'TS29571_CommonData.yaml#/components/schemas/PresenceInfo' minProperties: 1

• TDoc C3-231124 and TDoc C3-231231 have identical content.

• Both TDocs make use of the common data schema file TS29571_CommonData.yaml.

• TDoc C3-231124 and TDoc C3-231231 define the TsnPortNumber, ApplicationDescriptor, UePolicyContainer, and FlowDirection fields.

• The FlowDirection field is defined as an anyOf with four string values: DOWNLINK, UPLINK, BIDIRECTIONAL, and UNSPECIFIED. The enum is also described as being for "forward-compatibility with future extensions to the enumeration."

• TDoc C3-231124 defines the UpPathChgEvent field which contains notificationUri and notifCorreId properties. The chgId property is also defined with a nullable value.

• TDoc C3-231230 defines the suppFeat field, which references the SupportedFeatures schema from TS29571_CommonData.yaml. The PolicyAssociationRequest field is also defined, containing a description and praStatuses property.

• The praStatuses property is an object with additionalProperties defined as the PresenceInfo schema from TS29571_CommonData.yaml. It must have at least one property and is described as containing UE presence status for tracking area changes.

• The current applicable values corresponding to the policy control request trigger is reported content: application/json is defined, referencing the AmRequestedValueRep schema.

• TDoc C3-231230 also defines the PolicyAssociationUpdateRequest field, which contains a description and two array items properties, both referencing the InvalidParam schema from TS29571_CommonData.yaml.

Example snippet from TDoc C3-231124 to support the FlowDirection difference:
```
FlowDirection:
anyOf:
- type: string
enum:
- DOWNLINK
- UPLINK
- BIDIRECTIONAL
- UNSPECIFIED
- type: string
description: >
This string provides forward-compatibility with future extensions to the enumeration and is not used to encode content defined in the present version of this API.
```

Example snippet from TDoc C3-231124 to support the UpPathChgEvent difference:
```
UpPathChgEvent:
description: Contains the UP path change event subscription from the AF.
type: object
properties:
notificationUri:
$ref: 'TS29571_CommonData.yaml#/components/schemas/Uri'
notifCorreId:
type: string
description: >
It is used to set the value of Notification Correlation ID in the notification sent by the SMF.
type: object
properties:
chgId:
type: string
description: Univocally identifies the charging control policy data within a PDU session.
nullable:
```

Example snippet from TDoc C3-231230 to support the suppFeat and PolicyAssociationRequest differences:
```
suppFeat:
$ref: 'TS29571_CommonData.yaml#/components/schemas/SupportedFeatures'
required:
- suppFeat

PolicyAssociationRequest:
description: >
Information which the NF service consumer provides when requesting the creation of a policy association.
praStatuses:
type: object
additionalProperties:
$ref: 'TS29571_CommonData.yaml#/components/schemas/PresenceInfo'
minProperties: 1
description: >
Contains the UE presence status for tracking area for which changes of the UE presence occurred.
```

Example snippet from TDoc C3-231230 to support the PolicyAssociationUpdateRequest difference:
```
PolicyAssociationUpdateRequest:
description: >
Represents information that the NF service consumer provides when requesting the update of a policy association.
array items:
$ref: 'TS29571_CommonData.yaml#/components/schemas/InvalidParam'
minItems: 1
```

3GPP-C3-127-e    Agenda Item 18.48 : CT aspects of 5G-enabled fused location service capability exposure [5GFLS]

3GPP-C3-127-e    Agenda Item 18.49.2 : TEI18 for Packet Core

[TDoc C3-231043]:

- The QosMonitoringInformation data structure includes requested QoS Monitoring Parameters, report frequencies, reporting period, delay thresholds, and minimum waiting time between subsequent reports.
- The PCF notifies the NF service consumer using the "EventsNotification" data type and replies to the NF service consumer as described in clauses 5.3.2.5.2 and 5.3.2.2.2, respectively.

[TDoc C3-231071]:

- The umLevel attribute references the UsageMonLevel schema while the allowedUsage attribute references the UsageThreshold schema.
- The resetTime attribute references the DateTime schema.
- The resetIds attribute is an array of strings.
- The LimitIdToMonitoringKey attribute contains the limit identifier and corresponding monitoring key for a given S-NSSAI and DNN.
- The SlicePolicyData attribute contains network slice-specific policy control information.
- The BdtData attribute contains background data transfer data.
- The PCF may include the V2XP attribute in the policy association create or update response in the roaming case.

[TDoc C3-231072]:

- The PCF reports the PC5 capability for V2X communications within the "pc5Capab" attribute.
- The H-PCF may include the V2XP attribute in the policy association create or update response in the roaming case.

[TDoc C3-231091]:

- The PolicyAssociationRequest attribute represents information for requesting the creation of a policy association.
- The praStatuses attribute contains UE presence status for tracking area for which changes of the UE presence occurred.
- The UeRequestedValueRep attribute contains the current applicable values corresponding to the policy control request triggers.

[TDoc C3-231094]:

- The NF service consumer can remove the "Individual Application Session Context" resource or the IP flow within the media component.
- The PCF sets appropriate QoS values for the AF signalling IP flow and installs the corresponding dynamic PCC rule.
- Combining the request for the AF signalling flow with an MPS for DTS invocation/revocation request is not supported.

[TDoc C3-231095]:

- The UE includes the "UE STATE INDICATION" message during initial registration and 5GS registration during UE mobility from EPS to 5GS.
- The WLAN access network selected by the UE with the use of Access Network Discovery & Selection policy may be used for direct traffic offload and for registering to 5GC using the non-3GPP access network selection information.

[TDoc C3-231134]:

- The PCF invokes the Nbsf_Management_Register service operation to create the PDU session binding information for a UE in the BSF and to request notifications from the UDR on changes in the AF influence data.
- The NEF invokes the Npcf_PolicyAuthorization_Update service operation upon receiving the Nnef_TrafficInfluence_Update request.

[TDoc C3-231232]:

- The BSF sets the "event" attribute to "PCF_PDU_SESSION_BINDING_REGISTRATION" or "PCF_PDU_SESSION_BINDING_DEREGISTRATION" and includes the "pcfForPduSessInfos" with the binding information of the detected or removed PDU session.
- The NEF provides means for the Application Functions to securely interact with the Policy framework for policy control to 3GPP network.

[TDoc C3-231233]:

- The BSF replies with an HTTP "200 OK" response containing the corresponding "PcfForUeBinding" data structure(s) and PCF addressing information if the binding resource matching the query parameters exists.
- The NF service consumer sends an HTTP GET request with "{apiRoot}/nbsf-management//pcf-ue-bindings" as Resource URI and "query parameters" that include SUPI and/or GPSI.
- The BSF searches the corresponding binding information and invokes the Nbsf_Management_Discovery service operation to obtain address information of the selected PCF for a UE in the BSF.

[TDoc C3-231235]:

- General PCC abilities can be exposed to a 3rd party application server via the NEF.
- The document lists various procedures, including AF-based service parameter provisioning, background data transfer negotiation, background data transfer policy applying, IPTV configuration provisioning, BDT warning notification, AF traffic routing, QoS monitoring, and AF-triggered dynamically changing AM policies.

[TDoc C3-231234]:

- The NF service consumer invokes the Nbsf_Management_Discovery service operation to obtain the address information of the selected PCF for a certain PDU session.
- The BSF sends an HTTP "200 OK" response to the NF service consumer with the address information of the selected PCF and associated information.
- The PCF instance ID and the SBA binding level can be included in the response.

[TDoc C3-231289]:

- The first octet of the Geographic Location field indicates the type of NG-RAN node and the length of the NG-RAN Node ID.
- The coding of the Geographic Location field follows subclause 9.3.1.5 in 3GPP TS 38.413 for NG-RAN Node ID.
- The coding of the Geographic Location field follows subclause 8.21.8 in 3GPP TS 29.274 for extended eNodeB ID.

[TDoc C3-231291]:

- Predefined PCC rules may be grouped as predefined PCC rule bases within the SMF.
- The PCF can dynamically activate sets of predefined PCC rules.
- The SMF decision logic for interacting with the PCF about an event related to a PCC rule base is up to implementation.
- Predefined PCC rules can be installed, modified, and removed at any time.

[TDoc C3-231396]:

- The values indicate different transmission technologies and RATs.
- WIRELINE-CABLE and WIRELINE-BBF indicate wireline transmission technologies.
- VIRTUAL indicates an unknown RAT.
- WLAN and N3GA indicate specific types of RATs.
- The other values indicate specific RATs, but some are not used in the present specification.

TDoc C3-231237:
- Technical change: Definition of type PolicyAssociationUpdateRequest
- Example snippet: "Table 5.6.2.4-1: Definition of type PolicyAssociationUpdateRequest"
- Supporting text: "It is FFS whether other new attributes need to be added when the PolicyAssociationUpdateRequest data type is used to report the target AMF supported features."

TDoc C3-231397:
- Technical change: Mapping table for IP-CAN types and Access types
- Example snippet: "Table E.2-1: Mapping table for IP-CAN types and Access types values"
- Supporting text: "maps the values of the Access types and RAT types used for N7 interface in 3GPP TS 29.512 with the values of the IP-CAN types and RAT types used in this specification."

TDoc C3-231398:
- Technical change 1: Definition of type PolicyAssociationUpdateRequest
- Example snippet: "Table 5.6.2.4-1: Definition of type PolicyAssociationUpdateRequest"
- Supporting text: "It is FFS whether other new attributes need to be added when the PolicyAssociationUpdateRequest data type is used to report the target AMF supported features."
- Technical change 2: Feature negotiation
- Example snippet: "5.8 Feature negotiation"
- Supporting text: "They shall be negotiated using the extensibility mechanism defined in clause 6.6 of 3GPP TS 29.500."

TDoc C3-231441:
- No technical changes mentioned, only references to other 3GPP TS specifications.

TDoc C3-231092:
- This TDoc discusses northbound APIs applicable for both EPS and 5GS.
- Table 5.3-1 lists the reused APIs for both EPS and 5GS.
- No specific changes are mentioned in this TDoc.

Example snippet: "This clause describes the northbound APIs which are applicable for both EPS and 5GS."

TDoc C3-231236:
- This TDoc proposes changes to Type PolicyAssociationRequest in 5.6.2.3.
- Table 5.6.2.3-1 defines the type PolicyAssociationRequest.
- The proposed changes are not specified.

Example snippet: "Proposed changes: *** 1st Change *** 5.6.2.3 Type PolicyAssociationRequest"

TDoc C3-231290:
- This TDoc proposes changes, but no specific changes are mentioned.
- No specific sections or tables are mentioned.

Example snippet: "Proposed changes: *** 1st Change *** *** End of Changes ***"

3GPP-C3-127-e    Agenda Item 19.1 : Work Plan Review

3GPP-C3-127-e    Agenda Item 19.4 : Calendar