Apex Standards 3GPP Meeting Tracker

---

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

3GPP-S6-54-e    Agenda Item 2.0 : Agenda and Chair notes

3GPP-S6-54-e    Agenda Item 3.0 : Report from previous meetings

3GPP-S6-54-e    Agenda Item 4.1 : Incoming LSs

1. Security issues arise when relying on unverified information from UE (S3-223018)
- "SA3 agreed that, in general, it is not desirable for the network to rely on unverifiable/unverified information provided by the UE. SA3 cannot assess these risks"

2. The association between EECID and UE ID is determined and stored in the UDM (Q3)
- "Assuming that the association between EECID and UE ID is stored in the UDM, SA2 would like to point out that allowing queries based on EECID would not only require extending the Nnef_UEId_Get API but would also require extending the Nudm_SDM_Get service operation, the impact of which may be non-negligible."

3. Guaranteeing that the UE is using the correct EECID (Q2)
- "SA2 can only consider this functionality once the points above, including the security aspects, are clarified."

4. Differences between the EDGEAPP scenario assumption and the Edge Node Sharing scenario (S6-231112)
- "GSMA OPG would like to highlight that there are differences between the scenario assumption described by 3GPP for Solution #43 (text highlighted above) and the Edge Node Sharing as described in the Operator Platform requirements."

5. Unclear details regarding the EDGEAPP interfaces involved in EWBI definition (S6-231113)
- "OPAG would like to understand better the details of 3GPP's approach to the EWBI especially which EDGEAPP interfaces are involved and when to use what interface (i.e. for which scenarios and use cases)."

6. Enhancement of dynamic EAS instantiation triggering (KI#9)
- "In the TR it has been specified that the EES may invoke EAS dynamic instantiation, e.g. considering EEC service characteristics such as location."

7. A method of rearranging the composite EAS context may be required to provide a continuous service of the composite EASs (KI#9)
- "In the TR it is mentioned that when ACR occurs due to UE mobility, a method of rearranging the composite EAS context may be required to provide a continuous service of the composite EASs."

TDoc S6-231121:
- SA4 is considering starting a new Work Item specifying a generalised service-based architecture and API for AS management that can be referenced by any 3GPP specification in which a set of AS instances is managed by an AF.
- The management relationship between an AS instance and an AF is compared with the similar relationship that exists within the 5G System between an AF instance and the Network Repository Function (NRF).
- SA4 requests SA2 to comment on the proposal to define a generic, reusable service-based architecture and API for AS instance management by an AF.
- The study identifies the usefulness of an AS instance periodically reporting its health and load to its managing AF after first registering with that AF.

TDoc S6-231253:
- In the latest draft of MEC 011, the Annex C analysis has been updated to indicate that there’s “No existing MEC attribute defined” for easId.
- ETSI ISG MEC asks 3GPP CT3 to provide comment on MEC’s interpretation of the easId attribute within the EASProfile, particularly in relation to the endPt attribute present in the same data type.
- The description of easId in 3GPP TS 29.558 was updated to provide URI and FQDN as example values for easId.
- All Edge SA6Video Servers will share the same EASID”.

TDoc S6-231419:
- SA6 has discussed the LS from 5G-ACIA, and has identified gaps and limitations potentially relevant for SA6.
- SA3 has discussed the LS from 5G-ACIA with a focus on gaps G.1, G.3 and limitation L.6, which have been identified as being potentially relevant for SA3.
- Security events and logging information include information relating to successful and unsuccessful authentications of UE and information relating to applied protection of user plane traffic.
- SA6 has specified Network Resource Management service in 3GPP TS 23.434 which specifies procedures and APIs which can be used for monitoring device connectivity, including the connection’s QoS.

TDoc S6-231420:
- The "EVEX framework" currently described in the stage 2 specification TS 26.531 and stage 3 specification TS 26.532 defines the detailed procedures and associated APIs for the generic UE data collection and reporting functionality.
- TSG SA asks whether SA4 is willing to maintain and enhance the technical specifications that comprise the "EVEX framework" and fulfill any changes necessary based on requirements from other WGs in Rel.18 and future releases that fall within the existing scope of the framework.
- If SA4 is not willing to do changes in the "EVEX framework" for UE data collection, TSG SA will discuss further whether the architecture and related procedures are transferred and maintained by another WG (SA2 or SA6).

TDoc S6-231115:

- Performance measurements are provided in 3GPP TS 28.552, including UL packet delay between NG-RAN and PSA UPF in clause 5.4.7.1.
- SA5 release 18 includes work item on 5G performance measurements and KPIs phase 3 (UID: 960025) for defining new performance measurements and KPIs in 3GPP TS 28.552 and 3GPP TS 28.554.
- "E2E delay for network slice" refers to the delay between UE and AS when UPF and AS are co-located in the same node (with no application server processing time considered).
- E2E network slicing management and orchestration is specified by 3GPP SA5, including RAN, TN, and CN.

TDoc S6-231118:

- Q1 refers to similar KPIs provided by 2 or more EDNs in their common geographical service area.
- Q2 refers to ensuring 2 or more bundled EASs (possibly from different ASPs) are deployed in the same EDN and registered on the same or different EES.
- AffinityEAS in affinityAntiAffinity attribute can be provided to ESCP management system to indicate deploying requirements with other EASs on the same EDN.
- EAS registration to EES is controlled by EAS, as described in TS 23.558 clause 8.4.3 EAS Registration.
- KPIs for 2 EDNs may not be similar if the EASs are completely separated.

TDoc S6-231119:

- Energy Saving (ES) is the optimization of energy efficiency for 5G network entities by the network operator.
- Digital Sobriety (DS) is the adoption of best practices by service users to help save energy in the 5G network.
- Digital sobriety may also include how 3GPP can help save energy in the 5G network by designing eco-friendly solutions.

TDoc S6-231252:

- GSMA OPG has published new versions of several documents and a new document for User-Network Interface APIs.
- GSMA PRD OPG.02 Operator Platform Telco Edge Requirements version 4.0, GSMA PRD OPG.03 Southbound Interface Network Resources APIs version 2.0, GSMA PRD OPG.04 East-Westbound Interface APIs version 2.0, and GSMA PRD OPG.05 User-Network Interface APIs are all available.
- GSMA OPG requests that the information be taken into consideration.

- TDoc S6-231114: Switch from MBSUserServAnmt to UserServiceDescription data structure for encoding of MBS User Service Announcement
- TDoc S6-231117: SA5 looking into solutions for east/west bound interface and network slice management capability exposure, correction to SA5 response needed
- TDoc S6-231120: Authorization token for APIs accessed by Client (Consumer) represents granular access authorizations, details on OAuth2 protocol and Client Credentials needed
- TDoc S6-231421: ITU-T SG 11 LS on consent of draft new Recommendation ITU-T Q.3647 'Signaling requirements for emergency service in IMS roaming environment', TSG SA thanks for LS and takes information into account

Example snippets:
- TDoc S6-231114: "CT3 agreed the attached CR to 3GPP TS 29.580 to switch to the usage of the UserServiceDescription data structure for the encoding of the MBS User Service Announcement"
- TDoc S6-231117: "SA5 would like to correct the above statement as follows “SA5 is looking into solutions to support requirements on east/west bound interface including edge federation in the edge computing management work (eECM) and network slice management capability exposure work (FS_NSCE)"
- TDoc S6-231120: "SA5 would like to mention the following: SA5 is working the E/WBI API requirements as part of eECM and FS_MEC_ECM WID and SID respectively"
- TDoc S6-231421: "TSG SA would like to thank ITU-T SG 11 for their LS to SA6 on the consent of draft new Recommendation ITU-T Q.3647 'Signaling requirements for emergency service in IMS roaming environment'"

3GPP-S6-54-e    Agenda Item 4.2 : Outgoing LSs

3GPP-S6-54-e    Agenda Item 6.0 : Rel-16 Work Items

3GPP-S6-54-e    Agenda Item 7.0 : Rel-17 Work Items

One technical difference between the two TDocs is that TDoc S6-231264 describes the S-EES initiating ACT between the S-EAS and T-EAS through the ACR management notification for the "ACT start" event, while TDoc S6-231265 describes the S-EES sending an ACR parameter information request to the T-EES if the ACR request includes ACR parameters such as prediction expiration time. This difference highlights different methods of initiating ACT and providing ACR parameters.

Another difference is that TDoc S6-231264 mentions the S-EES sending the target information notification to the EEC based on T-EAS selection information received from the S-EAS, while TDoc S6-231265 mentions the S-EES sending an ACR information notification (ACR complete) message to the EEC when the ACR type is service continuity planning and the UE has moved to the predicted/expected location with a successful ACT status. This difference highlights different scenarios in which ACR notifications are sent and the criteria for sending them.

Additionally, TDoc S6-231264 mentions the S-EAS depending on receiving UE location notifications from the S-EES to detect the need for an ACR, while TDoc S6-231265 mentions that the S-EES may monitor UE mobility to determine when to send ACR information notifications. This difference highlights different methods of detecting the need for ACR and determining when to send notifications.

Example snippets from TDoc S6-231264 to support the differences highlighted:

- "The S-EES may apply the AF traffic influence with the N6 routing information of the T-EAS in the 3GPP Core Network (if applicable) and sends the ACR management notification for the "ACT start" event to the S-EAS, as described in clause 8.6.3, to initiate ACT between the S-EAS and the T-EAS." (highlighting the method of initiating ACT through ACR management notification)
- "Based on the T-EAS selection information received from the S-EAS, the S-EES sends the target information notification to the EEC as described in clause 8.8.3.5.3." (highlighting the sending of target information notification based on selection information received from the S-EAS)
- "The S-EAS may also depend on the receipt of UE location notification from the S-EES as described in clause 8.6.2.2.3, to detect the need for an ACR." (highlighting the dependence on UE location notifications to detect the need for ACR)

Example snippets from TDoc S6-231265 to support the differences highlighted:

- "If the ACR request in step 6 includes ACR parameters, e.g. Prediction expiration time, the S-EES performs ACR parameter information procedure by sending the ACR parameter information request to the T-EES as described in clause 8.8.3.9." (highlighting the method of providing ACR parameters through ACR parameter information procedure)
- "when the ACR type is service continuity planning. The S-EES may apply the AF traffic influence with the N6 routing information of the T-EAS in the 3GPP Core Network (if applicable) and sends the ACR management notification for the "ACT start" event to the S-EAS, as described in clause 8.6.3, to initiate ACT between the S-EAS and the T-EAS." (highlighting the method of initiating ACT through ACR management notification and sending ACR information notification only in service continuity planning case with specific criteria)
- "For the service continuity planning case, if it is EES monitors the UE mobility, then only when S-EES detects the UE has moved to the predicted/expected UE location or Expected AC Geographical Service Area and the status in step 12 indicates a successful ACT, then the S-EES sends ACR information notification (ACR complete) message to the EEC when the ACR type is service continuity planning." (highlighting the criteria for sending ACR information notification in service continuity planning case with UE mobility monitoring)

Technical Differences:

1. TDoc S6-231262 and TDoc S6-231263 are different documents with different document numbers.
- Example from TDoc S6-231262: "#54e S6-231262 17th – 26th April 2023 (revision of S6-23xxxx)"
- Example from TDoc S6-231263: "#54e S6-231263 17th – 26th April 2023 (revision of S6-23xxxx)"

2. TDoc S6-231262 and TDoc S6-231263 have the same Table 8.6.3.3.4-1, but they are presented in different meetings.
- Example from TDoc S6-231262: "3GPP TSG-SA WG6 Meeting"
- Example from TDoc S6-231263: "3GPP TSG-SA WG6 Meeting"

3. The information elements for an ACR management event notification from the EES to the EAS are described in Table 8.6.3.3.4-1.
- Example from TDoc S6-231262: "Table 8.6.3.3.4-1 describes the information elements for an ACR management event notification from the EES to the EAS."
- Example from TDoc S6-231263: "Table 8.6.3.3.4-1 describes the information elements for an ACR management event notification from the EES to the EAS."

4. Both TDocs have an "End of changes" section.
- Example from TDoc S6-231262: "* * * End of changes * * *"
- Example from TDoc S6-231263: "* * * End of changes * * *"

5. Both TDocs have a "Change 1" section.
- Example from TDoc S6-231262: "Change 1"
- Example from TDoc S6-231263: "Change 1"

3GPP-S6-54-e    Agenda Item 8.1 : NSCALE - Network Slice Capability Exposure for Application Layer Enablement

Technical Differences among TDoc:

1. Performance Data Retrieving Procedures: The performance data retrieving procedures in TDoc S6-231184 follows the steps in clause 9.7.2, and NSCE server retrieves the alarms of network slice instances from OAM system via the procedures defined in clause 6.1, TS 28.545[x]. The alarms are defined in clause 4.1.1.1, TS 32.111-1[y], and they include the fault of communication, environmental, equipment, processing error, QoS for device/resource/file/functionality/smallest.

2. Correlating Applications, Services, and Network Resources: NSCE server correlates the applications, services, and the network resources of specific network slice instances which supports the applications and services with the S-NSSAI, NSI ID, Application Identifier to diagnose the causes of the fault of the applications or services by analyzing the fault information from different sources.

3. Slice Verification and Alignment Capability Exposure: Table 9.X.4.1-1 illustrates the APIs for the network slice verification and alignment capability exposure, and the VAL server sends a slice requirements verification and alignment request to NSCE server to check whether the slice requirements match the real network slice usage status.

4. Network Slice Information Delivery Request: The subclause 9.y.2.1 in TDoc S6-231216 describes the procedure of the Network Slice Information delivery to the VAL server via NSCE server when the VAL server requests the Network Slice Information after registration.

5. Network Slice Allocation: The NSCE server performs the Network Slice Allocation operation on behalf of VAL Server as specified in TS 28.531 [8], delivers the Network Slice Allocation result, and delivers the allocated Network Slice Information to NSCE client of VAL UEs based on the VAL UE's ID list from step 2 in case the Network Slice Allocation is successful.

6. Coordinated PLMN and PNI-NPN Slice Resource Optimization Procedures: This procedure is specified in clause 9.10 in TDoc S6-231258, and it helps to adapt the network slice for the VAL application.

7. Slice API Configuration and Translation: This functionality is provided to the vertical application specific layer and configures the exposure of APIs in a slice-tailored manner.

8. Predictive Slice Modification in Edge-Based NSCE Deployments: This feature helps to address scenarios where the NSCE server is deployed at the edge, and the migration to different Data Network requires that the ongoing slice is supported at the target area to ensure meeting the application session requirements.

9. Network Slice Related Performance and Analytics Report Subscription and Report: The VAL server triggers the procedure by sending the network slice related performance and analytics report subscription to NSCE server, and the NSCE server reports the performance and analytics report after the subscription is successful.

10. Network Slice Related Performance and Analytics Monitoring Request: The VAL server triggers the procedure by sending the network slice related performance and analytics monitoring request to NSCE server, and NSCE server correlates and analyzes the performance data of network slice instance, the analytics data of group of UEs and the KQI/QoE data to generate the performance data and analytics data report as required by VAL server.

Examples from Original TDoc:

1. TDoc S6-231184: The performance data retrieving procedures follows the steps in clause 9.7.2. 3. NSCE server retrieves the alarms of network slice instances from OAM system via the procedures defined in clause 6.1, TS 28.545[x], and the alarms are defined in clause 4.1.1.1, TS 32.111-1[y], e.g., the fault of communication, environmental, equipment, processing error, QoS for device/resource/file/functionality/smallest.

2. TDoc S6-231184: NSCE server correlates the applications, services and the network resources of the specific network slice instances which supports the applications and services with the S-NSSAI, NSI ID (nSInstanceId defined in TS 28.541[10]), Application Identifier (defined in 23.501[16]), and then diagnoses the causes of the fault of the applications or services by analyzing the fault information from different sources.

3. TDoc S6-231184: Table 9.X.4.1-1 illustrates the APIs for the network slice verification and alignment capability exposure. The VAL server sends a slice requirements verification and alignment request to NSCE server to check whether the slice requirements (by configuring the attributes of serviceProfile) matches the real network slice usage status.

4. TDoc S6-231216: The subclause 9.y.2.1 describes the procedure of the Network Slice Information delivery to the VAL server via NSCE server when the VAL server requests the Network Slice Information after registration.

5. TDoc S6-231246: The NSCE server performs the Network Slice Allocation operation on behalf of VAL Server as specified in TS 28.531 [8], delivers the Network Slice Allocation result, and delivers the allocated Network Slice Information to NSCE client of VAL UEs based on the VAL UE's ID list from step 2 in case the Network Slice Allocation is successful.

6. TDoc S6-231258: This procedure is specified in clause 9.10, and it helps to adapt the network slice for the VAL application.

7. TDoc S6-231258: This functionality is provided to the vertical application specific layer and configures the exposure of APIs in a slice-tailored manner.

8. TDoc S6-231258: This feature helps to address scenarios where the NSCE server is deployed at the edge, and the migration to different Data Network requires that the ongoing slice is supported at the target area to ensure meeting the application session requirements.

9. TDoc S6-231260: The VAL server triggers the procedure by sending the network slice related performance and analytics report subscription to NSCE server, and the NSCE server reports the performance and analytics report after the subscription is successful.

10. TDoc S6-231260: The VAL server triggers the procedure by sending the network slice related performance and analytics monitoring request to NSCE server, and NSCE server correlates and analyzes the performance data of network slice instance, the analytics data of group of UEs and the KQI/QoE data to generate the performance data and analytics data report as required by VAL server.

Technical differences among the TDocs are as follows:

[TDoc S6-231336]:
- Proposed expiration time for the subscribe.
- Information elements specified in the Table 9.5.3.17-1 for Policy harmonization subscribe response.
- Information elements specified in the Table 9.5.3.16-1 for Policy harmonization subscribe request.
- Information elements specified in the Table 9.5.3.18-1 for Policy harmonization subscribe notify.
- The NSCE server checks policy conflicts with service profile and pre-configured policy.
- NSCE server may determine parameters for harmonizing policies.
- Request shall contain policy ID and policy modification details.

[TDoc S6-231337]:
- Table 9.12.3.2-1 for slice related communication service creation request.
- Information elements specified in the Table 9.12.3.5-1 for Slice Information delivery request and response.
- Information elements specified in the Table 9.12.3.2-1 and 9.12.3.2-2 for slice related communication service creation request and response.

[TDoc S6-231339]:
- Report provided by NSCE server to VAL server as per the request.
- Information elements specified in Table 9.5.3.3-1 for AF policyVAL Policy provisioning response.
- Information elements specified in Table 9.5.3.10-1 for AF policyVAL Policy usage reporting data notification.
- Information elements specified in Table 9.5.3.12-1 for Network slice optimization subscription response.
- Information elements specified in Table 9.5.3.13-1 for Network slice optimization notification.
- Information elements specified in Table 9.5.3.7-1 for AF policyVAL Policy delete response.
- Reporting interval and scheduling period.

[TDoc S6-231340]:
- Information elements specified in Table 9.x.3.5-1 for Network slice and VAL service mapping update response.
- Information elements specified in Table 9.x.3.3-1 for Network slice and VAL service mapping response.
- Mapping information retrieval procedure illustrated in Figure 9.x.2.3-1.

Examples from the original TDoc to support the differences highlighting:
- "The information elements specified in the Table 9.5.3.17-1 is used for the Policy harmonization subscribe response sent from the NSCE server to the VAL server." (TDoc S6-231336)
- "Table 9.12.3.2-1 describes information elements for slice related communication service creation request and response between the VAL server and the NSCE server." (TDoc S6-231337)
- "Table 9.5.3.3-1 describes the information elements for the AF policyVAL Policy provisioning response from the NSCE server to the VAL server." (TDoc S6-231339)
- "Information elements specified in Table 9.x.3.5-1 for Network slice and VAL service mapping update response." (TDoc S6-231340)

Technical Differences among TDoc S6-231169 and S6-231338:

1. TDoc S6-231169 proposes the introduction of information flows and APIs for existing predictive inter-PLMN slice service continuity procedure, while TDoc S6-231338 defines various network slice related abbreviations and terms.
- TDoc S6-231169: "This pCR propose to introduce information flows and APIs for existing predictive inter-PLMN slice service continuity procedure."
- TDoc S6-231338: "Add the abbreviations used in this TS."

2. TDoc S6-231169 focuses on predictive inter-PLMN slice service continuity, while TDoc S6-231338 covers various aspects of network slicing including network slice templates, management functions, and quality indicators.
- TDoc S6-231169: "Information flows for predictive inter-PLMN slice service continuity."
- TDoc S6-231338: "Generic Network Slice Template", "Network Slice Management Function", "Key Performance Indicator", "Quality of Experience".

3. TDoc S6-231169 is related to the SEAL application enabler, while TDoc S6-231338 defines terms and abbreviations for the entire document.
- TDoc S6-231169: "The NSCE is part of application enabler/SEAL."
- TDoc S6-231338: "For the purposes of the present document."

4. TDoc S6-231169 proposes a change to an existing procedure, while TDoc S6-231338 defines terms for the entire document.
- TDoc S6-231169: "The existing procedure does not have information flows and APIs described."
- TDoc S6-231338: "Add the abbreviations used in this TS."

5. TDoc S6-231169 focuses on inter-PLMN slice service continuity, while TDoc S6-231338 defines terms related to network slicing for various operators and services.
- TDoc S6-231169: "Predictive inter-PLMN slice service continuity procedure."
- TDoc S6-231338: "Mobile Network Operator", "Network Slice as a Service", "Network Operator".

Example snippets from TDoc S6-231169:

1. "This pCR propose to introduce information flows and APIs for existing predictive inter-PLMN slice service continuity procedure."
2. "The existing procedure does not have information flows and APIs described."
3. "The NSCE is part of application enabler/SEAL."
4. "Predictive inter-PLMN slice service continuity procedure."

Example snippets from TDoc S6-231338:

1. "Add the abbreviations used in this TS."
2. "Generic Network Slice Template."
3. "Network Slice Management Function."
4. "Key Performance Indicator."
5. "Quality of Experience."
6. "Mobile Network Operator."
7. "Network Slice as a Service."
8. "Network Operator."

- TDoc S6-231135 proposes new specific procedures, information flows, and APIs for requesting and receiving information on experienced service degradation.
- This is because the vertical/ASP using the VAL server has estimated bad QoE for a mobile user or service, either reported or detected by the application.
- The VAL server can identify specific events where the application experienced service degradation.
- TDoc S6-231259 specifies general requirements for the NSCE architecture to support network slice capability enablement services for application layers.
- The NSCE server should be able to communicate with one or more VAL servers and one or more other NSCE servers.
- The APIs interactions between the vertical application server(s) and NSCE server(s) should conform to CAPIF as specified in 3GPP TS 23.222.
- The NSCE architecture should support interactions with 3GPP network management system(s) to consume network slice management services provided by MNO(s).
- The NSCE does not have a database to store specific slice events, but can use ADAES to assist with deriving specific information about observed events.
- One example of a specific event is application fallback due to network slice communication service timeout.

Example snippets from the original TDoc:
- "The VAL server has identified there is specific event where the application has experienced service degradation (reported errors from VAL client for degraded service (bad quality), reported errors from application (downgrade of communication, detected communication errors))." (TDoc S6-231135)
- "[AR-6.2-1] The NSCE architecture shall support the NSCE server to communicate with the VAL server with one or more applications." (TDoc S6-231259)
- "The NSCE architecture shall support the NSCE server to communicate with one or more other NSCE server(s)." (TDoc S6-231259)
- "NSCE can assist with deriving specific about the observed events with the help of ADAES. There was application fallback due to network slice communication service timeout." (TDoc S6-231135)

3GPP-S6-54-e    Agenda Item 8.12 : EDGEAPP_EXT - Edge Application Standards in 3GPP and alignment with External Organizations

The first TDoc (S6-231163) describes the Mp1 reference point between the MEC platform and MEC applications, which provides service registration, discovery, and communication support. It also mentions multi-access system reference architecture variants for deployment in an NFV environment and MEC federation. The MEC platform is comprised of essential functionalities required to run MEC applications on a particular virtualization infrastructure and enables them to provide and consume MEC services. The application registration procedure allows an authorized MEC application instance to provide its information to the MEC platform.

The second TDoc (S6-231268) mentions the ETSI MEC specification, which includes endpoint information (e.g., URI, FQDN, IP address) of the application server, which is part of the application functionalities. The Mp3 reference point between MEC platforms is used for control communication between MEC platforms, with a separate application mobility service being provided in support of mobility of users between MEC hosts within a MEC system.

Some specific examples of differences between the two TDocs include:

- TDoc S6-231163 mentions multi-access system reference architecture variants for deployment in an NFV environment and MEC federation, while TDoc S6-231268 does not.
- TDoc S6-231268 mentions endpoint information of the application server, which is not specifically discussed in TDoc S6-231163.
- TDoc S6-231163 discusses application availability, session state relocation support procedures, traffic rules and DNS rules activation, access to persistent storage, and time of day information, which are not mentioned in TDoc S6-231268.
- TDoc S6-231268 mentions a separate application mobility service being provided in support of mobility of users between MEC hosts within a MEC system, which is not specifically discussed in TDoc S6-231163.

Additionally, both TDocs mention that certain information elements (IEs) are not applicable in application registration in ETSI MEC, including the List of N6 Traffic Routing requirements, EAS Availability Reporting Period, EAS Service continuity support, and EAS service permission level.

TDoc S6-231138:

- The document provides details about alignment EDGE-3/Mp1and EDGE-9/Mp3 reference points.
- References in the document can be specific or non-specific.
- A non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
- The reason for the change is to align EDGE-3/Mp1 and EDGE-9/Mp3 reference points.
- ETSI GS MEC 003 (V3.1.1) is referenced in the document.

Example from TDoc S6-231138: "This pCR provides the alignment of EDGE-3/Mp1 and EDGE-9/Mp3 reference points so that the two architectures can coexist in an operator network."

TDoc S6-231267:

- The document proposes a clause in 3GPP TR 23.958 v0.3.1 to capture the EDGEAPP and ETSI MEC aligned deployment.
- The reason for the change is to align EDGEAPP and ETSI MEC in R18.
- The document captures different deployment possibilities of aligned EDGEAPP and ETSI MEC in an operator network.
- EDGEAPP architecture and ETSI ISG MEC aligned deployment is shown in Figure 7.2-1.

Example from TDoc S6-231267: "This paper proposes a clause in 3GPP TR 23.958 v0.3.1 to capture the EDGEAPP and ETSI MEC aligned deployment as per conclusion of the FS_eEDGEAPP study in TR 23.700-98."

- The document captures deployment of EDGEAPP and ETSI MEC architecture as an aligned edge system in an operator network.
- The document references TS 23.558.
- The document shows EDGEAPP architecture and ETSI ISG MEC aligned deployment in Figure 7.2-1.

Example from TDoc S6-231267: "These sections capture deployment of EDGEAPP and ETSI MEC architecture as an aligned edge system in an operator network, their architectural requirements etc. Figure 7.2-1: EDGEAPP architecture and ETSI ISG MEC aligned deployment."

3GPP-S6-54-e    Agenda Item 8.13 : UASAPP_Ph2 - Architecture for UAS Applications, Phase 2

Technical Differences:

1. The first TDoc snippet (S6-231142) describes the information flow between the UAE server, client, and UAS application specific server, while the second TDoc snippet (S6-231271) focuses on the UAE layer and its support for different communication modes.
2. S6-231142 involves the transmission of DAA client event information from the UAE client to the UAE server, while S6-231271 talks about the switch between different communication modes, including Network-Assisted C2, Direct C2, and UTM-Navigated C2 communication.
3. S6-231142 mentions the recording of DAA client event information with current timestamps, while S6-231271 discusses the capture of PC5 availability/feasibility and the inclusion of a preference/priority of the C2 operation mode in the feasibility report.
4. S6-231142 highlights the provision of the DAA application policy by the UAE server to the UAE client as a pre-condition, while S6-231271 does not mention any pre-conditions.
5. S6-231142 involves the provision of consolidated information from the UAS application specific server to the UAS client by the UAE client, while S6-231271 does not mention any such provision.

Example Snippets:

1. "The UAE server shall record the DAA client event information with current timestamp." (S6-231142)
2. "The PC5 availability/feasibility can be captured at the UAV/UAV-C, e.g., the UAV-C can periodically broadcast signals in different frequencies, and upon reception of an ACK from the UAV to understand (based on the received signal) whether direct C2 is possible." (S6-231271)
3. "The UAE client shall send a DAA client event information to the UAE server with information about one or more UAVs in proximity as detected in step 1." (S6-231142)
4. "The UAE server shall send a DAA client event information acknowledge to the UAE client..." (S6-231142)
5. "The UAS application specific server may include more information in the acknowledgement (e.g., other UAVs detected information by UAS application layer mechanisms)." (S6-231142)

3GPP-S6-54-e    Agenda Item 8.14 : SEALDD - SEAL data delivery enabler for vertical applications

- The TDoc outlines the SEALDD interaction procedure for notifying the server about the address/port used for SEALDD traffic transfer if it differs from the control plane interaction.
- The TDoc describes the information flow for data storage query and management requests, including data type and length identification.
- The SEALDD enabled regular transmission request table describes the information flow for requesting regular application transmission service and includes a result element indicating success or failure.
- The architecture for SEAL Data Delivery Service uses service-based interfaces for interactions and includes communication with the control plane of the 3GPP core network via N33/N5 interface.
- The TDoc outlines procedures for transmission optimization based on E2E transmission measurement results and data storage and rate control/adaptation to improve service experience.
- The SEALDD server can obtain the endpoint for SEALDD-Uu user plane and send AF traffic influence to request 5GC to maintain simultaneous connectivity.
- The TDoc outlines the information flow for requesting SEALDD traffic descriptor for redundant transmission and mapping between application and SEALDD traffic.
- Transmission quality measurement results, including latency, jitter, bitrate, and packet loss rate, can be obtained and reported to the VAL server via notification message.
- The SEALDD layer can provide differentiated data delivery service with different bandwidth experience according to the VAL user's bandwidth limit and UE's current network status.

[TDoc S6-231296]:
- The S-SEALDD server can generate transmission quality measurement reports and determine whether the current transmission quality can satisfy QoS requirements.
- The S-SEALDD server can trigger the data transmission quality guarantee procedure based on QoS monitoring and measurement.
- The SEALDD server can send a Sdd_TransmissionQualityQuery request to obtain transmission quality measurement results.
- Figure 9.9.2.1-1 shows the SEALDD enabled transmission quality guarantee procedure by switching SEALDD servers.

[TDoc S6-231298]:
- SEALDD server 1 includes SEALDD IP replacement information in the AF traffic influence if SEALDD server 2 supports transportation layer service continuity.
- Application data is sent via the SEALDD flow between the VAL Client and VAL Server 1.
- Detailed information flows in SEALDD context pull and push are still being developed.

[TDoc S6-231334]:
- Table 9.2.3.x1-1 describes the information flow from the VAL server to the SEALDD server for provisioning the SEALDD server and client policy.
- Table 9.2.3.x4-1 describes the information flow from the SEALDD client to the SEALD server for acknowledging the SEALDD client policy reception.
- Table 9.2.3.x3-1 describes the information flow from the SEALDD server to the SEALD client for forwarding the SEALDD client policy.
- Table 9.2.3.x2-1 describes the information flow from the SEALDD server to the VAL server to provide the SEALDD policy provisioning complete response.

[TDoc S6-231367]:
- The SEALDD server may subscribe to CN analytics and further notify data delivery status based on analytics result if the DD policy specifies failure detection report.
- Table 9.2.3.5-1 describes the information flow from the SEALDD server to the SEALDD client or VAL server for requesting/notifying the SEALDD connection establishment.
- Figure 9.2.2.3-1 shows the policy enforced by SEALDD server for connectivity.

TDoc S6-231293:

- SEALDD flow ID is used to identify different VAL application traffic of the same SEALDD client.
- SEALDD server ID identifies the SEAL data delivery server.
- SEALDD client ID is a globally unique value that identifies the SEAL data delivery client.
- Identifies and commonly used values for SEALDD are listed in clauses 8.1 and 8.2X.

Example snippet: "The identities and common values of SEALDD service are needed to be completed based on the current specified contents."

TDoc S6-231330:

- Definitions of terms, symbols, and abbreviations are provided in the document.
- A term defined in the present document takes precedence over the definition of the same term in 3GPP TR 21.905.
- Symbols are defined for the purposes of the present document.

Example snippet: "This contribution provides editorial cleanup."

Overall proposal:

- Add a copy of clause 9.x.4 APIs for each procedure, adding a title, a general description, information flows, and the procedure.
- Skip clause 9.x.4 APIs if the procedure under 9.x does not require specification of APIs.

1. SEALDD server reports data transmission quality measurement results to VAL server via notification message, considering spatial and temporal conditions.
2. SEALDD client encapsulates UL monitoring packet with local time T2 and T3 and sends to SEALDD server.
3. VAL server sends SEALDD transmission quality measurement subscription request to SEALDD server.
4. Other consumers can send SEALDD transmission quality query request to SEALDD server.
5. SEALDD enabled data transmission quality guarantee with redundant transport is used to meet connection reliability requirements.
6. SEALDD server allocates address/port of SEALDD server to receive packets from VAL server for application data transfer.
7. SEALDD server sends SEALDD traffic descriptor for redundant transmission to SEALDD client.
8. SEALDD client responds with a SEALDD service response.
9. S-SEALDD server can generate transmission quality measurement report and determine to trigger data transmission quality guarantee procedure based on QoS monitoring and measurement.
10. Reporting granularity is specified in Table 9.7.3.3-1, 9.7.3.x1-1, 9.7.3.x2-1, 9.7.3.x4-1, and 9.7.3.x5-1.

Example snippet from TDoc S6-231365: "The SEALDD server reports the data transmission quality measurement results (e.g. latency, jitter, bitrate, packet loss rate) to the VAL server via the notification message."

Example snippet from TDoc S6-231366: "Table 9.7.3.3-1 describes the information flow from the SEALDD client to the SEALDD server for notifying the transmission quality measurement reports."

Example snippet from TDoc S6-231395: "Upon receiving the request, the SEALDD server sends SEALDD traffic descriptor for redundant transmission of the SEALDD server side (i.e. the addresses or ports for the redundant transmission paths allocated in step 2 and the transport protocol used for the SEALDD traffic) to SEALDD client."

Example snippet from TDoc S6-231396: "The S-SEALDD server (i.e., SEALDD server#1) can generate the transmission quality measurement report according to the SEALDD enabled transmission quality measurement procedure in clause 9.7.2.1."

3GPP-S6-54-e    Agenda Item 8.16 : ADAES - Application Data Analytics Enablement Service

TDoc S6-231257:

- Stats can be about load in terms of number of EAS or EES connections, average edge computational resource usage, EDN total resource availability, EDN overload/high load indication events, probability of EAS/EES unavailability due to high load, etc.
- Information flow of edge data collection subscription on edge load analytics is specified about requesting and responding to the A-DCCF.
- Table 8.8.3.5-1 describes information elements for the Data collection subscription response from the edge Data Producer at the EDN (or the A-DCCF) to the ADAE server based on performance analytics received per DN or load analytics per DNAI/UPF.
- Result includes derived analytics based on performance analytics received and measurements on computational or RAN resource load or number of connections for the EES/EASs active at the EDN.

TDoc S6-231261:

- Information flow of data collection subscription on application performance analytics is specified about requesting and responding to the Data Producer (e.g., A-DCCF).
- Procedure on VAL server performance analytics is illustrated in Figure 8.2.2-1 where the VAL server performance analytics are performed based on data collected from ongoing VAL sessions and data from the DN (VAL server, DN database or networking stack at the DN).
- ADAES sends a data collection subscription request to the Data Producers (at the DN side or UE side) with the respective Data Collection Event ID and the requirement for data collection.
- ADAES sends the analytics to the consumer, where analytics include the VAL server 1 predicted or statistic performance for a given area and time horizon, including also the confidence level, whether offline/online analytics were used.
- ADAES abstracts or correlates the data based on the analytics event and the data collection configuration.

TDoc S6-231309:

- Information flows are specified for edge load analytics based on 8.8.2.
- Table 8.8.3.2-1 describes information elements for the edge analytics subscription request from the VAL server / Consumer to the ADAE server.
- Table 8.8.3.5-1 describes information elements for the Data collection subscription response from the edge Data Producer (or the A-DCCF) to the ADAE server.
- Table 8.8.3.4-1 describes information elements for the edge data collection subscription request from the ADAE server to the Data Producer at the EDN or the A-DCCF.
- Figure 8.8.2.2-1 illustrates the procedure for the analytics consumer to request analytics data of the application server(s) from the ADAE server.
- Result includes ADAES collected analytics data (e.g. predictive or statistical parameter) of the application servers (i.e. EAS) and the result of the edge data collection subscription request (positive or negative acknowledgement).

TDoc S6-231136

- Specifies information flows for network slice usage pattern analytics based on 8.7.2
- Defines information elements for the network slice usage pattern analytics subscription request from the analytics consumer to the ADAE server
- Provides a procedure for network slice usage pattern analytics, where the analytics consumer sends a subscription request to ADAES and provides target S-NSSAI, DNN, area of interest, historical data period, required confidence level, and offline/online analytics needs
- Describes information elements for the network slice usage pattern analytics notification from the ADAE server to the analytics consumer.

Example snippet: "The analytics consumer of the ADAES sends a subscription request to ADAES and provides the target S-NSSAI, DNN, area of the interest, interest time period of the historical data (e.g., last year), the required confidence level, whether offline and/or online analytic are needed etc."

TDoc S6-231137

- Proposes clarifying the general clause of slice specific application performance analytics that the procedure introduced in 8.7.3 can be used for retrieving slice specific application performance statistics data
- Notes that the ADAES architecture stores historical data in A-ADRDF, but lacks a procedure and service flows to extract such data if specific statistics are needed for a certain time window in the past for network slice statistics
- Describes the procedure for supporting slice-tailored application performance analytics
- States that once the ADAES service consumer subscribes for slice specific application performance analytics, it can receive notifications according to its subscription.

Example snippet: "Once ADAES service consumer (can be NSCE server) subscribes for slice specific application performance analytics, it can receive notifications according to its subscription."

TDoc S6-231168

- Exhibits the service-based interfaces for providing and consuming application data analytics enablement services
- Shows the architecture for application data analytics enablement utilizing the 5GS network services based on the 5GS SBA specified in 3GPP TS 23.501
- Depicts the application data analytics enablement architecture in the non-roaming case, using the reference point representation showing how various entities interact with each other.

Example snippet: "The VAL server(s) communicates with the application data analytics enablement server over the ADAE-S reference point."

TDoc S6-231270

- Defines the procedure for network slice usage pattern analytics, where the analytics consumer sends a subscription request to ADAES and provides target S-NSSAI, DNN, area of interest, historical data period, required confidence level, offline/online analytics needs, and identifier for the target VAL server for which the analytics subscription applies (for procedure in 8.2.2)
- Describes information elements for the network slice usage pattern analytics subscription request from the analytics consumer to the ADAE server
- Depicts the application data analytics enablement architecture in the non-roaming case, using the reference point representation showing how various entities interact with each other.

Example snippet: "If consumer is different from the VAL server, this identifier shows the target VAL server for which the analytics subscription applies (for procedure in 8.2.2)."

3GPP-S6-54-e    Agenda Item 8.17 : 5GFLS - 5G-enabled fused location service capability exposure

TDoc S6-231226 and TDoc S6-231227 are two technical documents that differ in a few key ways. These differences are highlighted in the snippets from the original TDoc below:

1. The number of "Next Change" bullet points: TDoc S6-231226 has two "Next Change" bullet points, whereas TDoc S6-231227 has three "Next Change" bullet points. This suggests that TDoc S6-231227 has more changes or updates than TDoc S6-231226.

Example from TDoc S6-231226:
* Next Change
* Next Change

Example from TDoc S6-231227:
* Next Change
* Next Change
* Next Change

2. The use of asterisks to denote the end of changes: Both TDocs use asterisks to denote the end of changes, but TDoc S6-231227 has more asterisks than TDoc S6-231226. This could indicate a longer or more detailed list of changes in TDoc S6-231227.

Example from TDoc S6-231226:
* * End of Changes

Example from TDoc S6-231227:
* * * End of Changes

3. The number of blank lines after the "End of Changes" line: TDoc S6-231226 has ten blank lines after the "End of Changes" line, while TDoc S6-231227 has twelve blank lines. This is a subtle difference, but it could suggest that TDoc S6-231227 is a longer or more complex document overall.

Example from TDoc S6-231226:
* * End of Changes
* * * * * * * * * *

Example from TDoc S6-231227:
* * * End of Changes
* * * * * * * * * * * *

In summary, TDoc S6-231226 and TDoc S6-231227 differ in the number of "Next Change" bullet points, the use of asterisks to denote the end of changes, and the number of blank lines after the "End of Changes" line. These differences suggest that TDoc S6-231227 may be longer or more detailed than TDoc S6-231226.

Example from TDoc S6-231226:
* Next Change
* Next Change
* * End of Changes
* * * * * * * * * *

Example from TDoc S6-231227:
* Next Change
* Next Change
* Next Change
* * * End of Changes
* * * * * * * * * * * *

Technical Differences between TDoc S6-231224 and TDoc S6-231229:

1. TDoc S6-231224 discusses the information flow from the VAL server to the location management server and/or from the location management server to the location management client for requesting an immediate location information report. TDoc S6-231229, on the other hand, talks about the support for location management functions provided by the location management client to the VAL client(s) over LMC reference point.

Example from TDoc S6-231224: "Table 9.3.2.3-1 describes the information flow from the VAL server to the location management server and/or from the location management server to the location management client for requesting an immediate location information report."

Example from TDoc S6-231229: "The location management client provides the support for location management functions to the VAL client(s) over LMC reference point."

2. TDoc S6-231224 mentions the security aspects for LM-Uu and LM-S in relation to the VAL service ID that need to be coordinated with SA3. TDoc S6-231229, on the other hand, provides a definition of the VAL system and the VAL stream.

Example from TDoc S6-231224: "Editor's Note: It's FFS the security aspects for LM-Uu and LM-S in relation to the VAL service ID that need to be coordinated with SA3. whether and how the LMS need to identify the VAL service when the VAL UE ID is used for location request."

Example from TDoc S6-231229: "VAL system: The collection of applications, services, and enabling capabilities required to support a VAL service. VAL stream: A time sensitive communication stream is used to transport a time sensitive data flow, and is defined by a stream specification (which identifies a source and destination of the data flow) and a traffic specification (which defines the characteristics of the data flow)."

3. TDoc S6-231224 provides a table (Table 9.3.2.3-1) that describes the information flow from the VAL server to the location management server and/or from the location management server to the location management client for requesting an immediate location information report. TDoc S6-231229, on the other hand, discusses the fused location function, which may select one or more location sources and location methods based on the requested location QoS obtained from the location management server.

Example from TDoc S6-231224: "Table 9.3.2.3-1: Location information request"

Example from TDoc S6-231229: "The fused location function may select one or more location sources and location methods based on the requested location QoS which obtained from the location management server."

4. TDoc S6-231224 mentions that the location management server communicates with the SCEF via T8 reference point to obtain location information from the underlying 3GPP network system. TDoc S6-231229, on the other hand, discusses the location management server obtaining location information from the GMLC via Le reference point and from the NEF via N33 reference point.

Example from TDoc S6-231224: "The location management server communicates with the SCEF via T8 reference point to obtain location information from the underlying 3GPP network system."

Example from TDoc S6-231229: "The location management server may obtain location information from the GMLC via Le reference point defined in clause 4.4.1 of 3GPP TS 23.273[50]. The location management server obtains location information from the NEF via N33 reference point by mechanism defined in clause 5.2.6.2 of 3GPP TS 23.502."

1. TDoc S6-231230 focuses on supporting Mission Critical Data (MCData), while TDoc S6-231371 focuses on MCData, Mission Critical Video (MCVideo), and V2X services.
- Example from TDoc S6-231230: [6] 3GPP TS 23.282: "Functional architecture and information flows to support Mission Critical Data (MCData); Stage 2".
- Example from TDoc S6-231371: [5] 3GPP TS 23.281: "Functional architecture and information flows to support Mission Critical Video (MCVideo); Stage 2". [7] 3GPP TS 23.286: "Application layer support for V2X services; Functional architecture and information flows".

2. TDoc S6-231230 and S6-231371 have some overlap in terms of standards, but S6-231230 includes support for Uncrewed Aerial Systems (UAS) connectivity, identification and tracking, while S6-231371 includes architecture enhancements for 5G System (5GS) to support network data analytics services.
- Example from TDoc S6-231230: [52] 3GPP TS 23.256 "Support of Uncrewed Aerial Systems (UAS) connectivity, identification and tracking; Stage 2".
- Example from TDoc S6-231371: [34] 3GPP TS 23.288: "Architecture enhancements for 5G System (5GS) to support network data analytics services".

3. TDoc S6-231230 and S6-231371 both include standards related to Service Enabler Architecture Layer for Verticals (SEAL), but S6-231230 specifically focuses on the Data Delivery enabler for vertical applications, while S6-231371 does not specify a particular SEAL standard.
- Example from TDoc S6-231230: [48] 3GPP TS 23.433: "Service Enabler Architecture Layer for Verticals (SEAL); Data Delivery enabler for vertical applications".
- Example from TDoc S6-231371: [48] 3GPP TS 23.433: "Service Enabler Architecture Layer for Verticals (SEAL); Data Delivery enabler for vertical applications".

4. TDoc S6-231230 and S6-231371 both include standards related to security aspects for verticals, but S6-231371 specifies a particular standard for Service Enabler Architecture Layer (SEAL), while S6-231230 does not.
- Example from TDoc S6-231230: [29] 3GPP TS 33.434: "Service Enabler Architecture Layer (SEAL); Security aspects for Verticals".
- Example from TDoc S6-231371: [48] 3GPP TS 23.433: "Service Enabler Architecture Layer for Verticals (SEAL); Data Delivery enabler for vertical applications".

5. TDoc S6-231230 and S6-231371 both include standards related to common functional architecture to support mission critical services, but S6-231230 focuses specifically on MCData, while S6-231371 includes standards for MCData, MCVideo and V2X services.
- Example from TDoc S6-231230: [4] 3GPP TS 23.280: "Common functional architecture to support mission critical services; Stage 2".
- Example from TDoc S6-231371: [5] 3GPP TS 23.281: "Functional architecture and information flows to support Mission Critical Video (MCVideo); Stage 2". [7] 3GPP TS 23.286: "Application layer support for V2X services; Functional architecture and information flows".

TDoc S6-231223:

- Table 9.3.2.23-1 describes the information flow from the location management client to the location management server for registration of the location service.
- This TDoc includes revisions of a previous TDoc (S6-23xxxx).
- No examples provided.

TDoc S6-231225:

- The Cancel_Trigger_Location_Reporting operation API cancels the trigger to report location information.
- The Subscribe_Location_Monitoring API operation enables the VAL server to receive the UE's location information from the location management server over LM-S.
- Table 9.4.1-1 illustrates the SEAL APIs for location management.
- This TDoc includes several changes, but no examples are provided for them.

TDoc S6-231228:

- Table 9.3.2.1-1 describes the information flow from the location management server to the location management client for the location reporting configuration.
- This TDoc includes several changes, but no examples are provided for them.

Example snippets from the original TDoc:

- TDoc S6-231223: No examples provided.
- TDoc S6-231225: No examples provided for the changes.
- TDoc S6-231228: No examples provided for the changes.

3GPP-S6-54-e    Agenda Item 8.18 : MC_AHGC - Mission Critical ad hoc group Communications

Technical Differences Among TDocs:

[TDoc S6-231240]:
- Describes the process of initiating an ad hoc group emergency alert in MC service.
- MC service server checks criteria for entering an ad hoc group emergency alert and sends response to confirm.
- MC service client initiates ad hoc group emergency alert request.
- MC service server checks authorization for initiation of ad hoc group emergency alerts and request support.

[TDoc S6-231242]:
- Contains tables for MCVideo user profile configuration data required for on-network and off-network MCVideo service.
- MCVideo server obtains user profile configuration data from the user database.
- Data in tables can be configured offline using the CSC-11 reference point.
- User profile configuration data is stored in the MCVideo user database.

[TDoc S6-231244]:
- Adds a process for leaving an ad hoc group emergency alert in MC service.
- MC service server checks criteria for the ad hoc group emergency alert and sends response to confirm cancellation.
- Functional alias of the MC service user initiating the ad hoc group emergency alert and additional information related to the alert may be displayed.

[TDoc S6-231256]:
- Similar to TDoc S6-231244, but with no indication of leaving an ad hoc group emergency alert.
- Functional alias of the MC service user initiating the ad hoc group emergency alert and additional information related to the alert may be displayed.

[TDoc S6-231343]:
- Describes the process of compiling a list of participants for an ad hoc group call in MCPTT.
- MCPTT server compiles list of participants from primary and partner MC systems based on criteria for determining the participants.
- MCPTT server sends request to MCPTT server of partner MC system to involve them in the process.
- Some users may belong to MCPTT server of partner MC system.
- Initiating MCPTT user may be notified of all MCPTT users who acknowledged and joined the ad hoc group call.

[TDoc S6-231344]:
- Similar to TDoc S6-231343, but for MCVideo rather than MCPTT.
- MCVideo server compiles list of participants from primary and partner MC systems based on criteria for determining the participants.
- MCVideo server sends request to MCVideo server of partner MC system to involve them in the process.
- Some users may belong to MCVideo server of partner MC system.
- Initiating MCVideo user may be notified of all MCVideo users who acknowledged and joined the ad hoc group call.

Examples from TDocs:
- TDoc S6-231240: "MC service server acquires the latest information of the MC service user at the MC service client and checks whether the criteria for initiating an ad hoc group emergency alert to the MC service client are met."
- TDoc S6-231242: "Tables A.3-1 and A.3-3 contain the MCVideo user profile configuration required to support the use of off-network MCVideo service."
- TDoc S6-231244: "The receiving MC service client sends the ad hoc group emergency alert cancel response to the MC service server to acknowledge that the ad hoc group emergency alert is cancelled for this MC service user."
- TDoc S6-231256: "The functional alias of the MC service user initiating the ad hoc group emergency alert and additional information related to the alert may be displayed."
- TDoc S6-231343: "The MCPTT server 1 may notify the initiating MCPTT user of all MCPTT users who acknowledged the ad hoc group call request and joined the ad hoc group call."
- TDoc S6-231344: "The MCVideo server 1 determines the list of participants from both primary and partner system to be invited for the ad hoc group call based on the information present in the information element Criteria for determining the participants."

Technical Differences among TDocs:

1. MCPTT Server 1 and MCVideo Server 1 compile the list of participants to be invited for the ad hoc group call, including participants from both primary and partner MC systems. They determine the list of participants based on the information present in the information element Criteria for determining the participants.

Example: "The MCPTT server 1 determines the list of participants from both primary and partner system to be invited for the ad hoc group call based on the information present in the information element Criteria for determining the participants." - TDoc S6-231373

2. MCPTT Server 1 and MCVideo Server 1 send the ad hoc group call get userlist request to the respective partner servers if they need to involve the partner system, based on the agreement and the criteria for determining the participants list.

Example: "MCVideo server 1 if it needs to involve the partner system based on the agreement and based on the criteria for determining the participants list, sends the ad hoc group call get userlist request to the MCVideo server 2." - TDoc S6-231375

3. MCData Server generates the MCData ad hoc group ID and determines the list of participants based on the criteria received from MCData client 1. If the ad hoc group data session request is not authorized, MCData server and client 1 shall not proceed with the rest of the steps.

Example: "The MCData client 1 initiates the ad hoc group data communication by sending the ad hoc group data session request containing the details of the criteria to be applied by the MCData server for determining the participants list." - TDoc S6-231376

4. MCPTT Server notifies the partner MC system about the ad hoc group call release to stop determining the participants by the partner MC system.

Example: "This procedure, in particular, describes how the partner MC system is notified about ad hoc group call release to cease the determining of the participants by the partner MC system." - TDoc S6-231381

Example snippets from the original TDocs:

- "The MCPTT server 1 sends the ad hoc group call response to MCPTT client 1 through the signalling path to inform about successful call establishment." - TDoc S6-231373
- "The MCVideo server 1 may notify the initiating MCVideo user of all MCVideo users who acknowledged the ad hoc group call request and joined the ad hoc group call." - TDoc S6-231375
- "If the MCData user of MCData client 1 has selected a functional alias, then the ad hoc group data session request contains that functional alias." - TDoc S6-231376
- "Table 10.19.2.1-1 describes the information flow ad hoc group call request from the MCPTT client to the MCPTT server." - TDoc S6-231381

Note: The above snippets are not exhaustive, and there may be other parts of the TDocs that highlight the technical differences.

The technical differences among the three TDocs are as follows:

TDoc S6-231342:
- Contains six changes in total, with the last two being listed first.
- The changes are listed in a nested bullet point format, with multiple levels of indentation.
- Includes an example snippet related to an ad hoc group emergency alert request.

Example snippet: "10.10.3.2.1 Ad hoc group emergency alert request (MC service client – MC service server)"

TDoc S6-231379:
- Contains one change, listed at the beginning of the document.
- The change is listed in a single bullet point format.
- Includes a revision date of the document.

Example snippet: "First Change * 3GPP TSG-SA WG6 Meeting #54-e S6-231379 17th – 26th April 2023 (revision of S6-23xxxx)"

TDoc S6-231380:
- Contains one change, listed at the beginning of the document.
- The change is listed in a single bullet point format.
- Includes a revision date of the document.

Example snippet: "First Change * 3GPP TSG-SA WG6 Meeting #54-e S6-231380 17th – 26th April 2023 (revision of S6-23xxxx)"

- TDoc S6-231243 relates to MCData user profile configuration, while TDoc S6-231247 relates to MCPTT user profile configuration, TDoc S6-231248 relates to MCVideo user profile configuration, and TDoc S6-231249 also relates to MCData user profile configuration.
- Tables A.3-1 and A.3-2 contain both on and off-network configuration data for MCData and MCPTT, while for MCVideo, the on-network configuration data is only contained in Table A.3-2.
- Tables A.3-1 and A.3-3 contain off-network configuration data for MCData, MCPTT, and MCVideo.
- The MCData server obtains the MCData user profile configuration data from the MCData user database, while the MCPTT and MCVideo servers obtain their respective user profile configuration data from the MCPTT-2 and MCVideo-2 user databases.
- Data in Tables A.3-1 and A.3-3 for MCData, MCPTT, and MCVideo can be configured offline using the CSC-11 reference point.
- The general aspects of MC service user profile configuration data are specified in 3GPP TS 23.280.
- The MCData, MCPTT, and MCVideo user profile configuration data are stored in their respective user databases (MCData-2, MCPTT-2, and MCVideo-2).

Example snippets from the original TDoc to support the difference highlighting:
- From TDoc S6-231243: "Tables A.3-1 and A.3-2 contain the MCData user profile configuration required to support the use of on-network MCData service. Table A.3-2: MCData user profile configuration data (on network) Tables A.3-1 and A.3-3 contain the MCData user profile configuration required to support the use of off-network MCData service."
- From TDoc S6-231247: "Tables A.3-1 and A.3-2 contain the MCPTT user profile configuration required to support the use of on-network MCPTT service. Tables A.3-1 and A.3-3 contain the MCPTT user profile configuration required to support the use of off-network MCPTT service."
- From TDoc S6-231248: "Tables A.3-1 and A.3-2 contain the MCVideo user profile configuration required to support the use of on-network MCVideo service. Tables A.3-1 and A.3-3 contain the MCVideo user profile configuration required to support the use of off-network MCVideo service."
- From TDoc S6-231249: "Tables A.3-1 and A.3-2 contain the MCData user profile configuration required to support the use of on-network MCData service. Tables A.3-1 and A.3-3 contain the MCData user profile configuration required to support the use of off-network MCData service."

3GPP-S6-54-e    Agenda Item 8.19 : PINAPP - Application layer support for Personal IoT Network

TDoc S6-231151:
- PIN discovery with assistance of PIN server via PEGC involves application interaction towards the PEGC.
- PIN discovery request includes security credentials of UE or PIN client and may include UE identifier such as GPSI.
- PIN server may determine PIN which accords with filter information in PIN discovery request.
- Location information of UE can also be included.

TDoc S6-231154:
- All information is used by PIN elements to access 5G or other applications outside of PIN.
- PIN server or PEMC can decide access control information in certain PEGC.
- PIN creation request includes security credentials of UE or PINE-1 and may include UE identifier such as GPSI.
- PEMC can request to create a PIN including details of other PIN elements that have established connection with it.

TDoc S6-231155:
- PIN discovery request includes security credentials of UE or PIN client and may include UE identifier such as GPSI.
- PEGC identifies received message as PIN join/discovery request and determines PINE is not registered and authorized.
- PEMC sends PIN discovery response to PIN element including configuration information of PINs which offer services requested by PINE.

TDoc S6-231156:
- Information flows specified for PIN communication include Create/Update/Remove request and response.
- Tables provided for informational elements in each request and response.

TDoc S6-231157:
- PIN Service Discovery Request sent by PIN Element to PEMC to discover candidate PINEs that can provide certain PIN service.
- PIN Service Discovery Response sent by PEMC to PINE to list candidate PINEs that can provide target PIN service.
- Application layer architecture shall provide mechanisms for PINE/PEGC/PIN server to receive changes in PIN status information of PIN from PEMC.

TDoc S6-231158:
- Information flows specified for PIN profile retrieval include PIN Profile Query request and response.
- Procedure describes how PEMC queries PIN server to obtain information of PIN that is pre-configured or dynamically created by PEMC.

TDoc S6-231159:
- Application layer architecture shall provide mechanisms for application client to publish its KPIs to operate effectively within PIN or application level requirements.
- Application layer architecture shall provide mechanisms for PEGC to publish its KPIs that PEGC supports or gateway requirements.
- Subscription and notification mechanisms must be provided for PINE/PEGC/PIN server to receive changes in PIN status information of PIN from PEMC.

TDoc S6-231160:
- PEMC sends PIN delete notification request to PEGC containing PIN ID of deleted PIN.
- PEGC sends PIN delete notification response to acknowledge receipt of notification and disables 5GS connection permission and access control information for PIN elements in this PIN.

TDoc S6-231166:
- Information flows specified for AS discovery include AS discovery request and response, AS registration request and response.
- Tables provided for informational elements in each request and response.

TDoc S6-231206:
- PEMC sends PIN status notification Request to PIN server containing details of new PIN client that joined PIN, including PIN client ID and GPSI.
- PEMC sends PIN status notification Request to PEGC/PIN server containing details of PIN client that requested to leave PIN.
- PIN server/PEGC sends PIN status notification Response to PEMC to acknowledge receipt of notification.
- PEMC sends PIN status notification Request to PEGC/PIN server containing details of PIN client that was removed from PIN.

TDoc S6-231207:

- PIN delete notification request sent from PEMC to PIN server when PIN is deleted locally
- Pre-conditions: PIN successfully created and in use, PEMC decides to delete the PIN
- PIN server validates request and verifies security credentials
- PIN elements in the PIN send delete notification response to acknowledge receipt
- PEGC disables 5GS connection permission and access control for PIN elements in the PIN

TDoc S6-231235:

- PIN PEMC role takeover request sent from current PEMC to another PIN element with PEMC capability
- PEMC-1 identifies new PEMC-2 and sends takeover request with PIN and PEMC-2 identifier
- PIN PEMC role takeover response sent from requested element to current PEMC
- PEMC and PIN server update dynamic profile information with details of new PEMC-2

TDoc S6-231238:

- 5G system supports creation, removal, and management of PIN
- PEMC requests PIN server to activate PIN with identifier, PINE-3 identifier, and duration
- PIN server activates PIN and sends response to PEMC
- PEMC notifies all attached/joined/registered PIN elements that PIN is being deactivated
- Procedure introduced for activation and deactivation of PIN with flexibility for owner to configure validity

TDoc S6-231241:

- List of services for PIN can include unique ID, description, and availability duration
- PEMC checks PIN profile to ensure PINE-1 is allowed to register new services
- PIN server, PEMC, and PEGC update dynamic information to remove or add details of services
- PIN services registration request sent by PIN element to PEMC to register for new services offered

Example snippets from TDoc S6-231207:

- "PEMC sends the PIN delete notification request to the PIN server that the PIN is deleted locally and this notification request contains the PIN ID of the deleted PIN."
- "The PEMC of the PIN decides to delete the PIN which could be based on the request from the authorized user or for any other reason which are implementation specific."
- "Upon receiving the request, the PIN server validates the PIN delete request and verifies the security credentials."
- "The PEGC sends the PIN delete notification response to acknowledge the receipt of the notification and disables the 5GS connection permission and access control information for the PIN elements in this PIN."
- "The PIN elements in this PIN sends the PIN delete notification response to acknowledge the receipt of the notification."

Example snippets from TDoc S6-231235:

- "Table 8.5.10.3.6-1 shows the informational elements of the PIN PEMC role takeover request sent from current PEMC of the PIN to another PIN element with PEMC capability."
- "The PEMC-1 looks into the PIN dynamic profile information to identify the new PINE which can take up the role of PEMC (here PEMC-2 PIN element) and requests PEMC-2 to take the role of PEMC by sending PIN PEMC role takeover request which includes the PIN identifier, PIN element identifier of PEMC-2."
- "Table 8.5.10.3.7-1 shows the informational elements of the PIN PEMC role takeover response sent from requested PIN element to the current PEMC."
- "The PEMC and PIN server updates the PIN dynamic information with the relevant details of PEGC-2."

Example snippets from TDoc S6-231238:

- "The 5G system shall support mechanisms for a network operator or authorized 3rd party (e.g., a PIN User) to create, remove and manage a PIN..."
- "PEMC requests the PIN server to activate the PIN and this request contains the PIN ID, PIN Element ID/PINAPP ID of PINE-3, duration of the PIN to be in active state etc."
- "PEMC (PINE-3) on receiving the PIN deactivation success response from the PIN server notifies all the PIN elements which are currently attached/joined/registered to the PIN that PIN is being deactivated."
- "This proposal introduces the procedure for activation and deactivation of PIN for effective management of the PIN considering and also provides flexibility for the PIN owner to configure validity of the PIN as recurring."

Example snippets from TDoc S6-231241:

- "The list of services can include a unique service id, human readable description of the service and may also contain time duration of when the service is available etc."
- "PEMC (PINE-4) on receiving the PIN services registration request checks whether the PINE-1 is allowed to register new service(s) and whether these services are allowed to be offered by the PIN by checking the PIN profile."
- "PIN server, PEMC and PEGC updates the PIN dynamic information to remove the details of the service(s) being de-registered."
- "PIN server, PEMC and PEGC updates the PIN dynamic information with the details of the new service(s) being offered and the PINE which is offering it."

TDoc S6-231179:

- Technical differences related to PIN Management PEGC Service Continuity request, response, and update
- Table 8.9.3.2-1, 8.9.3.3-1, and 8.9.3.7-1 describe information elements for these procedures respectively.
- Information elements include requestor identifier, security credentials, PIN identifier, PINE identifier, source PEGC identifier, application client identifier, and application session descriptor.
- The application session descriptor is optional.
- The PIN Management PEGC Configuration response includes the identifier of the application server and the application session descriptor as an option.
- Example from the TDoc: "Application client identifier M Identifier of the application client."

TDoc S6-231180:

- Technical differences related to PIN status information notification
- The PIN modification, PINE join/leave, and PIN profile update are included in the notification.
- The PEMC sends a PIN status unsubscribe response when the processing of the request is successful.
- Example from the TDoc: "The PEMC includes the parameters about the newly assigned PEMCs and PEGCs in the PIN status update request."

TDoc S6-231233:

- Technical differences related to the PEMC substituting the PINE/PEGC to register into the PIN server.
- The pre-conditions include the availability of UE Identifier or PIN client Identifier and the authorization of the PEMC to communicate with the PIN server.
- The PEGC identifies the received message as a PIN join/discovery request and returns a rejection message to the PINE.
- Example from the TDoc: "The PEGC returns the PIN join/discovery reject message to the PINE."

TDoc S6-231237:

- Technical differences related to Application KPIs and PIN client profile
- Minimum KPIs required by each application and capabilities of the PIN client are included.
- The PIN client profile includes the list of services the PINE is providing and allowed to be accessed.
- Example from the TDoc: "The unique identity of the PIN client within PIN Name of the device."

Technical Differences and Example Snippets from TDoc:

1. Ppemc_ConfigurationServiceSwitchConfigure_Request vs Ppine_ManagementServiceSwitchConfigure_Request vs Ppegc_ManagementServiceSwitchConfigure_Request
- These are different API operation names for requesting a service switch configuration operation from different PIN clients (PIN management client, PIN client, and PIN gateway client).
- Example snippet: "The consumer requests a service switch configuration operation from the PIN management client" (for Ppemc_ConfigurationServiceSwitchConfigure_Request)

2. UE Location
- This feature identifies where the UE is connected to the network or the position of the UE.
- Example snippet: "Following values are examples of UE locations that can be used: Cell Identity, Tracking Area Identity, GPS Coordinates or civic addresses"

3. PIN Subscriptions
- These requirements relate to PIN subscription service.
- Example snippet: "The application layer architecture shall provide subscription and notification mechanisms enabling to receive PIN modification information changes"

4. Access Control and Security Mechanisms
- This clause specifies the security requirements for access control, authentication, mutual authentication, message integrity protection, replay protection, confidentiality protection, communication protection, and privacy protection.
- Example snippet: "Access control mechanisms for authorizing interactions between functional entities of the application layer architecture shall be provided"

3GPP-S6-54-e    Agenda Item 8.2 : TEI18 - Technical Enhancements and Improvements for Release 18

3GPP-S6-54-e    Agenda Item 8.3 : MCGWUE - Gateway UE function for Mission Critical Communication

3GPP-S6-54-e    Agenda Item 8.4 : enh4MCPTT - Enhanced Mission Critical Push-to-talk architecture phase 4

Technical Differences among TDoc:

1. MCPTT server initiates a private call request for the call to MCPTT client 2, including MCPTT ID and functional alias of the calling MCPTT user. MCPTT server sends a first-to-answer call request to each potential target recipient, including MCPTT ID and functional alias of the calling MCPTT user at MCPTT client 1. [TDoc S6-231123]

2. MCPTT server confirms the authorization of MCPTT users for the call and whether the MCPTT user at MCPTT client 1 is authorized to initiate a first-to-answer call. MCPTT server responds with a functional alias resolution response message that contains the resolved MCPTT ID back to MCPTT client 1. [TDoc S6-231123]

3. MCPTT server checks the authorization of MCPTT client 1 to initiate a preconfigured regroup procedure and resolves the group identities of the MCPTT groups requested in step 1. The authorized user of MCPTT client 1 initiates the regroup procedure, specifying the list of MCPTT groups to be regrouped, the MCPTT group ID of the regroup group (if available), and the MCPTT group ID of the group from which configuration information for the regroup group is to be taken. [TDoc S6-231134]

4. Location management client 1 sends a location reporting trigger to the location management server to activate a periodic location reporting procedure that shall retrieve the location information of the MC service users sharing the contained functional alias. The location management server sends location report responses to location management client 1 containing the provided location information for each location management client using the given functional alias. [TDoc S6-231164]

5. MC service server, e.g., MCPTT server, may use the MBMS bearer to inform the status of a group communication (indicating the group call is ongoing or not) when the group call is set up on unicast bearers. The group management server checks whether the MC service user is authorized to perform the query. [TDoc S6-231208, S6-231213]

6. MC service server utilizes the elevated priority when requesting resources for new or existing MC service communication. The priority level identified is above the level of priority that the MC service server 1 can utilize without centralized priority arbitration. The procedure defined below provides the necessary coordination between MC service servers to manage high priority levels. [TDoc S6-231213]

7. MC service server checks that MC service client 1 is authorized to initiate a preconfigured group regroup procedure and resolves the group identities of the MC service groups requested in step 1. Pre-conditions: MC service client 1 is authorized to initiate a preconfigured regroup procedure, and is receiving MC service in the primary MC system of MC service client 1. In order to be aware of whether the group is regrouped, the MC service server within the same MC system is subscribed to the group configuration in the GMS. [TDoc S6-231215]

Example Snippets from TDoc:

- "The MCPTT server includes information that it communicates using MCPTT service, offers the same media types or a subset of the media types contained in the initial received request and sends an MCPTT private call request for the call to MCPTT client 2, including the MCPTT ID and, if available, the functional alias of the calling MCPTT user 1." [TDoc S6-231123]
- "The MCPTT server confirms that MCPTT users are authorized for the call and whether the MCPTT user at MCPTT client 1 is authorized to initiate a first-to-answer call. The MCPTT server responds with a functional alias resolution response message that contains the resolved MCPTT ID back to MCPTT client 1." [TDoc S6-231123]
- "The authorized user of MCPTT client 1 initiates the regroup procedure, specifying the list of MCPTT groups to be regrouped (MCPTT groups 1 and 2), the MCPTT group ID of the regroup group (if available) and the MCPTT group ID of the group from which configuration information for the regroup group is to be taken." [TDoc S6-231134]
- "Location management client 1 sends a location reporting trigger, limited to one MC service at the time, to the location management server to activate a periodic location reporting procedure which shall retrieve the location information of the MC service users sharing the contained functional alias. The location management server sends location report responses to location management client 1 containing the provided location information for each location management client using the given functional alias." [TDoc S6-231164]
- "The MC service server, e.g., MCPTT server, may use the MBMS bearer to inform the status of a group communication (indicating the group call is on-going or not) when the group call is set up on unicast bearers. The group management server checks whether the MC service user is authorized to perform the query." [TDoc S6-231208, S6-231213]
- "The MC service server utilizes the elevated priority when requesting resources for new or existing MC service communication. The priority level identified is above the level of priority that the MC service server 1 can utilise without centralized priority arbitration. The procedure defined below provides the necessary coordination between MC service servers to manage high priority levels." [TDoc S6-231213]
- "MC service server checks that MC service client 1 is authorized to initiate a preconfigured group regroup procedure and resolves the group identities of the MC service groups requested in step 1. Pre-conditions: MC service client 1 is authorized to initiate a preconfigured regroup procedure, and is receiving MC service in the primary MC system of MC service client 1. In order to be aware of whether the group is regrouped, the MC service server within the same MC system is subscribed to the group configuration in the GMS." [TDoc S6-231215]

- TDoc S6-231218:
- The MC service server checks authorization and resolves group identities for regrouping.
- Pre-conditions include MC service client 1 being authorized and subscribed to the group configuration in the GMS.
- The partner MC service server can send a regroup reject to the primary MC service server.
- TDoc S6-231220:
- Pre-conditions include belonging to the same MC system and previously affiliating to the group.
- The group management server may notify the MC service server about group creation and group members.
- Dynamic data associated with a group may be subscribed to by the group management server.
- TDoc S6-231222:
- The MC service server announces the MBMS bearer and resolves functional aliases.
- The MC service user obtains necessary security parameters from 3GPP TS 33.180.
- The authorized user initiates a user regroup procedure, specifying users, group IDs, and configuration information.
- TDoc S6-231322:
- MC service group affiliation can be achieved explicitly or implicitly.
- Pre-conditions for deaffiliation include explicit request or MC service server action.
- An authorized user may modify another user's MC service group affiliation remotely.

Example snippets from the original TDoc include:
- In TDoc S6-231218, "Pre-conditions" are explicitly stated with bullet points.
- TDoc S6-231220 specifies that the "group management server may conditionally notify the MC service server" and lists pre-conditions for group affiliation.
- TDoc S6-231222 describes the process for obtaining security parameters and initiating a regroup procedure with specific IDs and information.
- TDoc S6-231322 distinguishes between explicit and implicit affiliation and includes examples of pre-conditions for deaffiliation.

In TDoc S6-231232:

- Procedure Figure 10.16.5.4-1 presents a generic private communication procedure from MC service user 1 towards a migrated MC service user 2 where the MC system A is the primary MC system of MC service user 2 before migration, and the MC system B is the MC system that the MC service user 2 has migrated.
- Pre-conditions for the procedure include that MC system A and MC system B are interconnected.

Example snippet: "Figure 10.16.5.4-1 presents a generic private communication procedure from MC service user 1 towards a migrated MC service user 2 where the MC system A is the primary MC system of MC service user 2 before migration, and the MC system B is the MC system that the MC service user 2 has migrated"

In TDoc S6-231245:

- The location management system over 5GS shall support inter-system RAT changes event triggering and report as described in clause 7.3.3.9.1.
- This is an enhancement to the location management functions defined in 3GPP TS 23.280.

Example snippet: "In addition to the location management functions defined in 3GPP TS 23.280 [3], the location management system over 5GS shall support the following enhancement: - Inter-system RAT changes event triggering and report as described in clause 7.3.3.9.1."

In TDoc S6-231345:

- There are three tables (10.15.2.1-1, 10.15.2.2-1, and 10.15.2.3-1) that describe preconfigured regroup request information elements.
- Each of the tables describes a different information flow scenario for preconfigured regroup request between MC service clients and servers.

Example snippet: "Table 10.15.2.3-1 describes the information flow preconfigured regroup request from the MC service server to the MC service server. Table 10.15.2.1-1 describes the information flow preconfigured regroup request from the MC service client to the MC service server. Table 10.15.2.2-1 describes the information flow preconfigured regroup request from the MC service server to the MC service client."

3GPP-S6-54-e    Agenda Item 8.5 : IRail - Interconnection and Migration Aspects for Railways

Technical Differences:

1. The TDoc S6-231234 discusses the on-network functional model for the application plane of MCPTT service, while TDoc S6-231236 discusses the on-network functional model for the application plane of MCVideo service for on-network operations.

2. TDoc S6-231234 includes Figure 7.3.1-1, which shows the functional model for the application plane of the MCPTT service. On the other hand, TDoc S6-231236 includes Figure 6.1.1-1, which shows the functional model for the application plane of MCVideo service for on-network operations.

3. The MCPTT server is an instantiation of a MC service server in accordance with 3GPP TS 23.280, as stated in TDoc S6-231234. However, no such statement exists in TDoc S6-231236.

Example Snippets:

1. TDoc S6-231234: "Figure 7.3.1-1: Functional model for application plane of the MCPTT service"

2. TDoc S6-231236: "Figure 6.1.1-1 shows the functional model for the application plane of MCVideo service for on-network operations."

3. TDoc S6-231234: "The MCPTT server is an instantiation of a MC service server in accordance with 3GPP TS 23.280"

Overall, the main technical differences between the two TDocs relate to the specific services being discussed and the corresponding functional models for their application planes. Additionally, TDoc S6-231234 includes a statement about the MCPTT server being an instantiation of a MC service server in accordance with a specific TS, which is not mentioned in TDoc S6-231236.

TDoc S6-231348:
- The procedure is a generic private communication procedure from MC service user 1 to a migrated MC service user 2, with MC system A being the primary system before migration and MC system B being the system of migration.
- Pre-conditions include the interconnection of MC system A and MC system B.
- The MC service server A sends a private call redirection to MC service client 1 to inform them of the migration and the new MC service ID of MC service user 2.
- MC service client 1 initiates a private call towards MC service user 2, using the obtained MC service ID, and performs the communication procedures as described in 3GPP TS 23.379.

TDoc S6-231358:
- The procedure is a generic private communication procedure from MC service user 1 to a migrated MC service user 2, with MC system A being the primary system before migration and MC system B being the system of migration.
- Pre-conditions include the interconnection of MC system A and MC system B, the awareness of MC service server A of the migration and the MC service ID provided by MC system B, and MC system A being the primary system before migration.
- The MC service server A sends a private call redirection to MC service client 1 to inform them of the migration and the new MC service ID of MC service user 2.
- Figure 10.16.5.3-1 is added, which shows the MC private call towards a migrated MC service user.

Example snippets from TDoc S6-231348:
- "Figure 10.16.5.4-1 presents a generic private communication procedure from MC service user 1 towards a migrated MC service user 2 where the MC system A is the primary MC system of MC service user 2 before migration, and the MC system B is the MC system that the MC service user 2 has migrated."
- "The MC service client 1 initiates a private call towards MC service user 2, including the MC service ID of MC service user 2 obtained from MC system."
- "The initiated private call can either be an MCPTT private call, an MCVideo private call, or a corresponding one-to-one MCData communication, and shall perform the procedures as described in 3GPP TS 23.379."

Example snippets from TDoc S6-231358:
- "Figure 10.16.5.4-1 presents a generic private communication procedure from MC service user 1 towards a migrated MC service user 2 where the MC system A is the primary MC system of MC service user 2 before migration, and the MC system B is the MC system that the MC service user 2 has migrated."
- "The MC service server A sends a private call redirection towards the MC service client 1, to inform MC service user 1 that MC service user 2 has migrated and its new MC service ID of MC service user 2 assigned by the migrated MC system."
- "The MC service server A is aware that MC service user 2 has migrated and is informed of its MC service ID provided by MC system B, as described in clause 10.6.3.3."
- "MC system A is the primary MC system of MC service user 2 before migration."

3GPP-S6-54-e    Agenda Item 8.6 : FFAPP - Application layer support for Factories of the Future (FF)

3GPP-S6-54-e    Agenda Item 8.7 : eSEAL2 - Enhanced Service Enabler Architecture Layer for Verticals Phase 2

[TDoc S6-231209]:

- 3GPP TS 23.282 is for supporting Mission Critical Data (MCData)
- 3GPP TS 23.281 is for supporting Mission Critical Video (MCVideo)
- 3GPP TS 23.433 is for Service Enabler Architecture Layer for Verticals (SEAL) and data delivery enabler for vertical applications
- 3GPP TS 23.286 is for Application layer support for V2X services
- IEEE Std 802.1Qcc-2018 is for Stream Reservation Protocol (SRP) Enhancements and Performance Improvements
- 3GPP TS 23.288 is for Architecture enhancements for 5G System (5GS) to support network data analytics services
- 3GPP TS 33.434 is for Service Enabler Architecture Layer (SEAL) and security aspects for Verticals

[TDoc S6-231251]:

- No technical differences mentioned

[TDoc S6-231303]:

- No technical differences mentioned

[TDoc S6-231307]:

- No technical differences mentioned

[TDoc S6-231313]:

- Table 10.4.1-1 illustrates the SEAL APIs for group management
- Proposed changes include an API for communication between VAL server and group management server for querying and modifying group information

[TDoc S6-231314]:

- No technical differences mentioned

[TDoc S6-231323]:

- Information flow for multicast/broadcast resource update request and response is described in tables 14.3.2.42-1 and 14.3.2.43-1
- First changes include a new table for multicast/broadcast resource update response from NRM server to VAL server

TDoc S6-231369:

- Interconnection API publish request information flow is described in Table 8.25.2.1-1 from CAPIF core function to CAPIF core function.
- Service API update request information flow is described in Table 8.6.2.1-1 from API publishing function to CAPIF core function.
- Service API publish request information flow is described in Table 8.3.2.1-1 from API publishing function to CAPIF core function.

Example snippet from TDoc S6-231369: "Table 8.25.2.1-1: Interconnection API publish request"

TDoc S6-231370:

- Abbreviations defined in the present document take precedence over the definition of the same abbreviation in 3GPP TR 21.905.
- Various abbreviations are listed such as CNC, GPSI, NR, TSC, and VAL.

Example snippet from TDoc S6-231370: "3.2 Abbreviations"

TDoc S6-231378:

- Create notification channel response information flow is described in Table 17.3.2.2-1 from notification management server to notification management client.

Example snippet from TDoc S6-231378: "Table 17.3.2.2-1: Create notification channel response"

TDoc S6-231408:

- Lists various 3GPP TS documents related to functional architecture, information flows, and protocols.

Example snippet from TDoc S6-231408: "[6] 3GPP TS 23.282: 'Functional architecture and information flows to support Mission Critical Data (MCData); Stage 2'."

Technical differences among the following TDocs:

1. TDoc S6-231406
- No changes listed

2. TDoc S6-231409
- Lists revisions of S6-23xxxx
- Provides meeting dates (17th - 26th April 2023)

3. TDoc S6-231410
- Lists revisions of S6-23xxxx
- Provides meeting dates (17th - 26th April 2023)
- Includes a period after the "END of Changes" statement

4. TDoc S6-231412
- Lists revisions of S6-23xxxx
- Provides meeting dates (17th - 26th April 2023)
- Includes a "Next Change" statement before the "First Change" statement

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

- TDoc S6-231409: "17th - 26th April 2023 (revision of S6-23xxxx)"
- TDoc S6-231410: "17th - 26th April 2023 (revision of S6-23xxxx)."
- TDoc S6-231412: "17th - 26th April 2023 (revision of S6-23xxxx)"; "Next Change" before "First Change".

[TDoc S6-231255]:
- Notification management server sends Create Notification Channel response with endpoint URLs and valid duration for usage.
- Delivery method of PUSH via PUSH notification server is sent to OEM Push server.
- Notification management client requests PUSH notification service with specific protocol.
- The type of notification channel to be used is decided by UE capability.

[TDoc S6-231326]:
- Procedure for coordinated QoS provisioning operation in network assisted UE-to-UE communications.
- Ensures end-to-end application QoS requirement fulfillment.
- NRM server sends end-to-end QoS management response with positive or negative acknowledgement.
- NRM server may send notification to NRM client about end-to-end QoS management initiation.

[TDoc S6-231368]:
- VAL server sends Monitoring Events Subscription request to NRM server.
- NRM server subscribes to UE analytics events and UE monitoring events.
- Procedure for VAL server subscribing to NRM server to monitor VAL UE(s).

[TDoc S6-231405]:
- Functional architecture for service enabler architecture layer (SEAL) is specified.
- VAL system is the collection of applications, services, and enabling capabilities required to support a VAL service.
- SEAL service is a generic name for a common service that can be utilized by multiple vertical applications.
- The following SEAL services are supported towards the vertical application layer: location management, group management, configuration management, identity management, key management, network resource management, data delivery, notification management, network slice capability enablement, and application data analytics enablement.
- Generic functional model for SEAL is organized into functional entities to address application layer support for vertical applications.

3GPP-S6-54-e    Agenda Item 8.8 : 5GMARCH_Ph2 - New WID on support of the MSGin5G Service phase 2

MSGin5G Gateway UE is an MSGin5G UE that constructs and sends MSGin5G messages upon receiving a request with required application-specific data from the Application Client on the Constrained UE (without MSGin5G Client).

MSGin5G message is a message that is exchanged between MSGin5G Service endpoints under the MSGin5G Service.

Message Gateway is an entity in MSGin5G Service that supports interworking with Non-3GPP UEs, Legacy 3GPP UEs, and delivery of broadcast messages.

Legacy 3GPP Message Gateway is an entity in MSGin5G Service that supports interworking with Legacy 3GPP UEs.

Broadcast Message Gateway is an entity in MSGin5G Service that supports delivery of broadcast messages to Legacy 3GPP UEs, Non-3GPP UEs, and MSGin5G UEs.

MSGin5G Client provides client-side functionality for UE Application Clients with sending and receiving messages via the MSGin5G Service to/from Application Servers and/or other MSGin5G Service endpoints.

Functionalities of MSGin5G Client include exposing MSGin5G APIs to enable Application Clients to use an MSGin5G Service, supporting registration of an MSGin5G Client to an MSGin5G Server to use MSGin5G Service, supporting configuration of an MSGin5G Client required to use MSGin5G Service, construction of MSGin5G message when requested by a native application or Application Client, delivery of MSGin5G message payload to the targeted native application or Application Client, support MSGin5G message segmentation and re-assembly, and support MSGin5G message aggregation and segregation.

Constrained UE is a UE (with or without MSGin5G Client) that is used for group messaging with message delivery that originates at a UE or an Application Server and is terminated at all members of the group.

Legacy 3GPP UE is a UE that supports legacy 3GPP services and does not utilize MSGin5G Client in MSGin5G Service.

Non-3GPP refers to entities that are not based on 3GPP standards.

Example snippets from the original TDoc supporting the difference highlighting are:

- "MSGin5G Gateway UE: an MSGin5G UE which constructs and sends MSGin5G message upon receiving request along with required application specific data from the Application Client on the Constrained UE (without MSGin5G Client)."
- "Legacy 3GPP Message Gateway: the entity in MSGin5G Service to support interworking with Legacy 3GPP UEs."
- "MSGin5G Client(s) interacts with SEAL Clients over the SEAL-C reference point specified for each SEAL service."
- "Constrained UE: a UE (with or without MSGin5G Client) which Group messaging: message delivery that is originated at a UE or an Application Server and is terminated at all members of the group."
- "Non-3GPP refers to entities that are not based on 3GPP standards."

- TDoc S6-231173:
- Forwarding of Messaging Topic subscription and unsubscription requests from MSGin5G Server 1 to MSGin5G Server 2
- Mod.B handling of Messaging Topic subscription requests if Messaging Topic is not included in MSGin5G Server 2's list
- Clause 8.8.4.1 specifies the behavior of MSGin5G Server 1
- Example snippet: "upon receiving a Messaging Topic subscription request from MSGin5G Client or Application Server, if the Messaging Topic is not included in the Messaging Topic list of MSGin5G Server 2, the MSGin5G Server 1 handles the Messaging Topic subscription request as specified in clause 8.8.1."

- TDoc S6-231219:
- Forwarding of Messaging Topic subscription requests from MSGin5G Server 1 to MSGin5G Server 2 if Messaging Topic is included in list
- Mod.B handling of Messaging Topic subscription requests if Messaging Topic is not included in MSGin5G Server 2's list
- MSGin5G Server 1 includes different information elements in Table 8.8.4.3-1 instead of Table 8.8.1-1 for Messaging Topic subscription procedure
- Example snippet: "upon receiving a Messaging Topic subscription request from MSGin5G Client or Application Server if the Messaging Topic is not included in the Messaging Topic list of MSGin5G Server 2, the MSGin5G Server 1 handles the Messaging Topic subscription request as specified in clause 8.8.1."

- Difference between TDoc S6-231173 and TDoc S6-231219:
- TDoc S6-231173 forwards both messaging topic subscription and unsubscription requests from MSGin5G Server 1 to MSGin5G Server 2, while TDoc S6-231219 only forwards subscription requests
- TDoc S6-231219 specifies different information elements to be included in MSGin5G Server 1 for Messaging Topic subscription procedure
- Example snippet from TDoc S6-231173: "upon receiving a Messaging Topic unsubscription request from MSGin5G Client or Application Server, and if the Messaging Topic is included in the Messaging Topic list of MSGin5G Server 2, the MSGin5G Server 1 forwards the Messaging Topic unsubscription request to MSGin5G Server 2"
- Example snippet from TDoc S6-231219: "If the MSGin5G Server 1 works in Mod.B (see clause 8.8.4.1), upon receiving a Messaging Topic subscription request from MSGin5G Client or Application Server if the Messaging Topic is not included in the Messaging Topic list of MSGin5G Server 2, the MSGin5G Server 1 handles the Messaging Topic subscription request as specified in clause 8.8.1."

3GPP-S6-54-e    Agenda Item 8.9 : SNAAPP - Application enablement aspects for subscriber-aware northbound API access

3GPP-S6-54-e    Agenda Item 9.2 : FS_MCShAC - Study on sharing of administrative configuration between interconnected MC service systems

TDoc S6-231126 describes a solution that uses the interconnection interface and reference points specified in TS 23.280 for the transfer of administrative configuration information between two MC systems. The solution provides a generic ACMX functional model, with the Administrative Configuration Management Client (ACMC) acting as a user client controlling and performing transactions for administrative configurations and information exchange with an Administrative Configuration Management Server (ACMS). The ACMS supports requests from the ACMC, processes, validates, accepts, forwards or rejects administrative configuration exchange, and provides the necessary functionalities to control and perform required transactions to exchange administrative configurations and/or information between partner MC system(s).

TDoc S6-231127 highlights that the configuration and download of the MC service user profile data used by the ACM client and the ACM server is defined in TS 23.280. The ACM client can communicate and is authorized to access the ACM server at the primary MC system, and the connectivity between ACM servers in a primary MC system and a partner MC system can be defined using existing mechanisms. The ACMC of an authorized user requires authorization from the primary ACMS prior to any exchange with the partner MC system.

TDoc S6-231129 addresses key issue 3, change user configuration, and describes the information flow of the user configuration request sent from the primary ACMC to the partner ACMS(s) and relevant partner ACMC(s). The pre-conditions include the successful configuration and authorization of the primary and partner MC system(s) to accept connections from relevant ACMCs via the respective ACMSs, and the access of the primary ACMC(s) to the MC service user database in the primary MC system. A successful authorization check results in the user configuration request being forwarded to the relevant partner ACMS, with the primary ACMS sending the user configuration response to the primary ACMC.

Overall, the technical differences among the TDocs focus on the specific aspects addressed by each solution and the information flows involved in the exchange of administrative configuration information, with TDoc S6-231126 providing a generic functional model and TDocs S6-231127 and S6-231129 describing specific aspects such as the authorization and configuration of the MC system(s) and the information flow of user configuration requests. The use of existing mechanisms and the transformation of new entities into new roles of the existing MC entities are also discussed. Example snippets from the original TDocs support these differences, highlighting the specific functionalities and processes involved in each solution.

Technical Differences Among TDoc S6-231128, S6-231130, S6-231131, and S6-231132

1. TDoc S6-231128 introduces a procedure for group membership updates by an authorized user from a partner MC system. The ACM server of MC system A forwards/send the group membership update request to the ACM server of MC system B, the primary MC system of the interconnection group. In contrast, the other TDocs discuss removing a user configuration, updating an MC service user profile, and providing group information to an authorized user of a partner system.

2. TDoc S6-231128 involves the ACMS of MC system B sending a process indication to MC system A, and storing, verifying and assessing the incoming request. This step is not applicable in the other TDocs.

3. According to TDoc S6-231131, pre-conditions for updating the MC service user profile include the relevant ACMC(s) and ACMS connection authorizations being established successfully, and the authorized user at the primary MC system needing to update the MC service user profile for an MC service user already migrated and receiving services in a partner MC system. This scenario is not mentioned in the other TDocs.

4. TDoc S6-231130 notes that if the target MC service user in the primary MC system is not logged into the primary MC system at the time of the response being sent, a notification is generated to the target MC service user at a later time (notifying the user of the response) once the target MC service user is available. In addition, if the target MC service user in the partner MC system was not logged into the partner MC system at the time of the request being sent, a notification is generated to the target MC service user at a later time (notifying the user of the request) once the target MC service user is available. This notification process is not described in the other TDocs.

Example Snippets from TDocs

1. TDoc S6-231128:

- "The ACM server of MC system A forwards the group membership update request to the ACM server of MC system B, the primary MC system of the interconnection group."
- "The ACMS of MC system B sends a process indication to MC system A, and stores, verifies and assesses the incoming request."
- "The ACM server of MC system A forwards the group membership update response to the ACM client of MC system A."
- "The ACM server of MC system B, the primary MC system of the interconnection group, stores the group membership update request."

2. TDoc S6-231130:

- "If the target MC service user in the primary MC system is not logged into the primary MC system at the time of the response being sent, a notification is generated to the target MC service user at a later time (notifying the user of the response) once the target MC service user is available."
- "If the target MC service user in the partner MC system was not logged into the partner MC system at the time of the request being sent, a notification is generated to the target MC service user at a later time (notifying the user of the request) once the target MC service user is available."
- "The ACM server in the primary MC system validates whether the MC service user is authorized for the request."
- "The ACM client of the partner MC system sends a remove user configuration response to the ACM server in the partner MC system."
- "The target of this response is the original MC service user in the primary MC system that sent the remove user configuration request."

3. TDoc S6-231131:

- "Pre-conditions - The primary and partner MC system(s) are configured to accept connections from relevant ACMCs via the respective ACMSs in each of the connected MC service system(s) and have been configured and authorized successfully to allow exchange of administrative configuration information."
- "The relevant ACMC(s) and ACMS connection authorizations have been established successfully."
- "The authorized user at the primary MC system needs to update the MC service user profile, for an MC service user already migrated and receiving services in a partner MC system."
- "When a functional alias is used as the target of the request by an ACM client in the primary MC system, it is required that the primary ACM server has subscribed to the MC service functional alias controlling server within the primary MC system, and that the partner ACM server has subscribed to the MC service functional alias controlling server within the partner MC system."
- "The partner ACMS sends a process indication to the primary MC system, and stores, verifies and assesses the incoming request."

4. TDoc S6-231132:

- "The ACM client in the primary MC system sends a group information provision request to the ACM server in the primary MC system, providing a list of interconnection group IDs and the ID of the selected authorized user in the partner MC system."
- "The ACM server of the partner MC system forwards the group information provision response to the ACM server in the primary MC system."
- "The ACM server of the primary MC system stores the group information provision response."
- "The ACM server of the primary MC system forwards the group information provision request to the ACM server in the partner MC system."
- "The ACM server of the partner MC system forwards the stored group information provision request to the ACM client of the partner MC system."
- "The ACM client of the partner MC system sends a group information provision response to the ACM server of the partner MC system."
- "MC service user profile M."

3GPP-S6-54-e    Agenda Item 9.4 : FS_NSCALE - Study on Network Slice Capability Exposure for Application Layer Enablement

3GPP-S6-54-e    Agenda Item 9.6 : FS_ACE_IOT - Study on Application Capability Exposure for IoT Platforms

3GPP-S6-54-e    Agenda Item 10.0 : Future work / New WIDs / Revised WIDs (including related contributions)

3GPP-S6-54-e    Agenda Item 11.0 : Work Plan review