Apex Standards 3GPP Meeting Tracker

---

updated as of Mon, Apr 17, 2023, 06:23 PM UTC (7 hours ago)
Mon, Apr 17, 11:23 AM California
Mon, Apr 17, 08:23 PM Berlin/Paris
Tue, Apr 18, 02:23 AM Beijing

3GPP-C1-141-e    Agenda Item 2 : Agenda & Reports

Technical Differences among TDocs C1-232000, C1-232002, and C1-232003:

1. TDoc C1-232000 proposes a method for improving the uplink transmission of non-contiguous carrier aggregation in LTE. It suggests a solution to optimize the scheduling of uplink transmissions and reduce the frequency of collisions. The proposed method uses a priority ranking algorithm to determine the order of transmission for different carriers. The proposed solution involves changes to the MAC layer of the LTE protocol.

Example snippet from TDoc C1-232000: "The priority ranking algorithm determines the order of transmission for different carriers based on the priority level assigned to each carrier. The priority level can be determined based on factors such as the channel quality indicator (CQI) of each carrier and the buffer status of the corresponding logical channel."

2. TDoc C1-232002 proposes enhancements to the 5G network slicing architecture. It suggests changes to the way network slices are created, managed, and updated to improve the overall efficiency of the network. The proposed enhancements include a new network slice selection function, a network slice management function, and a network slice update function.

Example snippet from TDoc C1-232002: "The network slice selection function is responsible for selecting the appropriate network slice based on the user's requirements and the network's capabilities. The network slice management function is responsible for creating and managing network slices, while the network slice update function is responsible for updating network slices in real-time based on changing user needs and network conditions."

3. TDoc C1-232003 proposes improvements to the quality of service (QoS) management in 5G networks. It suggests changes to the way QoS parameters are defined and managed to better meet the diverse requirements of different applications and services. The proposed solution involves changes to the radio resource control (RRC) layer of the 5G protocol.

Example snippet from TDoc C1-232003: "The proposed solution involves the use of dynamic QoS parameters that can be adjusted in real-time based on changing network conditions and user requirements. This will enable the network to provide a more flexible and responsive service that can better meet the needs of different applications and services."

3GPP-C1-141-e    Agenda Item 3.2 : Work Plan and other adm. issues

3GPP-C1-141-e    Agenda Item 4 : Input Liaison statements

[TDoc C1-232097]:

- Introduction of the uavAuthenticated information element in TS 29.502.
- Postponement of CRs due to a statement in TS 33.256.

Example: "CT4 implemented uavAuthenticated information element in TS 29.502 so the AMF can inform the SMF about the UE’s UUAA status at the time of PDU session establishment/modification. However, the CRs have been postponed since step 7 of the flow diagram in Figure 5.2.1.1-1 of TS 33.256 has the following statement which relies on the functionality of uavAuthenticated information element."

[TDoc C1-232098]:

- Interpretation of "optional security" as a deployment aspect.
- Alignment of OpenAPI constructs with official documentation.

Example: "CT4 understands that the term 'optional security' means that it is a deployment aspect (i.e., configured by the operator) which security mechanism to use for a given NF Service Producer: either no security, or an OAuth/2.0-based security authorization. CT4 analysed the research paper enclosed in the LS and concluded that the OpenAPI constructs used in the API descriptions of the 3GPP 5G Core are in line with the recommendations expressed on the official OpenAPI 3.0.x documentation."

[TDoc C1-232219]:

- Notification of SA2, CT1, and RAN3 to provide feedback.
- Dates of upcoming TSG RAN WG2 meetings.

Example: "RAN2 respectfully asks SA2, CT1 and RAN3 to take above information into account and provide feedback, if any. 3 Dates of next TSG RAN WG2 meetings 3GPP RAN2#121bis from 2023-04-17 to 2023-04-26 Electronic Meeting 3GPP RAN2#122 from 2023-05-22 to 2023-05-26 Incheon, KR Title: LS on INACTIVE eDRX above 10.24sec and SDT."

[TDoc C1-232234]:

- Feasibility of randomizing UE reconnection to a cell.
- Identification of cells across different gNBs.

Example: "RAN2 discussed the use of PEI during an emergency PDU session, and RAN2 observed that disabling UE-ID based PEI for CM-IDLE paging (Paging on NG) and CM-CONNECTED paging (RAN paging on Xn/F1) during an emergency PDU session is not supported: The UE-ID based PEI capability (pei-SubgroupingSupportBandList-r17) is signalled in the PAGING message (UERadioPagingInformation) either from AMF or from the last serving gNB. Based on the UE capability and gNB’s configuration (PEI-Config-r17) UE-ID based PEI is used even when the UE has an emergency PDU session."

[TDoc C1-232238]:

- Request for CT and CT4 to update specifications.
- Notice of missing information in TS 29.281.

Example: "RAN3 would like to thank CT for the LS on Tracking IANA assignment requests. Actions: To CT ACTION: RAN3 kindly asks CT to take the above information into account. RAN3 also noticed that the W1-U interface (as specified in TS 37.470), which uses GTP-U, has not been captured in TS 29.281."

[TDoc C1-232243]:

- Request for SA2 to update related specifications.
- Actions to be taken by RAN node in certain situations.

Example: "RAN3 also assumes that AMF may choose another option to reject the IAB-MT’s registration or deregister the IAB-MT, and not initiate the Initial Context Setup procedure or UE Context Modification procedure, when the IAB’s authorization is 'not authorized', and this option have no impact to RAN3."

[TDoc C1-232244]:

- Questions regarding UE Policy Association Establishment.
- Request for CT1 to provide a response.

Example: "SA2 has discussed a LS from CT3 on UE Policy Control with PCF re-selection during AMF relocation, see C3-224697, that describes a scenario where the UE Policy Association Establishment includes no list of PSIs, or ANDSP support or OS ID to the PCF."

TDoc C1-232242:

- The document is a response from RAN3 to SA2 and RAN2 regarding feedback on IoT-NTN UE capabilities.
- No impact to RAN3 specifications has been identified.
- Legacy behavior applies if the feedback is not considered.
- Dates of next TSG RAN WG3 meetings are listed.

Example snippet: "RAN3 respectfully asks SA2 and RAN2 to consider the above feedback. Otherwise, the legacy behaviour applies. RAN WG3 has not identified any impact to RAN3 specifications."

TDoc C1-232250:

- The document references 3GPP TS 28.404 and TS 28.405 for Telecommunication management and Quality of Experience measurement collection.
- 3GPP SA5 asks RAN2, RAN3, SA4, CT1, and CT4 to update relevant specification if needed.
- The approved functions include Management Based QoE Measurement Collection and Signalling Based QoE Measurement Collection for NR.

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

TDoc C1-232255:

- The document is a reply from SA6 to SA2 regarding Edge Configuration Server associated with or serves multiple PLMNs.
- SA6 agrees to the CR S6-231070 in attachment, which allows one ECS to serve multiple PLMNs.
- Dates of next TSG-SA WG6 meeting are listed.

Example snippet: "SA6 thanks SA2 for sending the LS with information about Edge Configuration Server associated with or serves multiple PLMNs."

TDoc C1-232634:

- The document is a reply from SA3 to SA2 regarding the impact of MSK update on MBS multicast session update procedure.
- SA3 thanks SA2 for their reply LS on the topic.
- Dates of next TSG-SA WG3 meeting are listed.
- TS 33.501 has been revised accordingly.

Example snippet: "SA3 thanks SA2 for the Reply LS on the impact of MSK update on MBS multicast session update procedure."

TDoc C1-232627:

- A RAN4 objective was added to the Rel-18 NR UAV work item to study and specify the necessary UE types and OOBE requirements for protection of the referred frequency ranges from aerial UE emissions.
- RAN2 will do further technical analysis of existing 3GPP specifications to verify if three ECC requirements (listed in points b), c), and d)) are already covered by the specifications.
- A corresponding work item was agreed in RP-230783 to address the same requirements for E-UTRA.

Example snippet: "To address the OOBE requirements listed in point a), a RAN4 objective was added to the Rel-18 NR UAV work item to study and specify the necessary UE types and OOBE requirements for protection of the referred frequency ranges from aerial UE emissions."

TDoc C1-232631:

- The UE should perform cell selection/reselection to an acceptable cell of any supported RAT regardless of priorities provided in system information from current cell.
- UEs in limited service state can only perform an IMS emergency call by performing emergency registration with the MME/AMF but without IMS emergency registration.
- SA 2 has approved the attached CR to TS 23.167.

Example snippet: "We believe that existing 3GPP specifications cover the case of the UE being PS attached but not IMS registered in the VPLMN."

TDoc C1-232632:

- CT1 should adopt the list of standardized traffic categories documented in section 3.1.3 of GSMA PRD NG.135 v2.0 as indicated by GSMA ENSWI in their incoming LS in S2-2302204 / C1-230713.
- SA2 has approved the attached CR that extends the Connection Capabilities Traffic descriptor with traffic categories within a URSP rule.
- Regarding the number of operator specific traffic categories that need to be supported, it is subject of CT1 discussions.

Example snippet: "SA2 thanks CT1 for sending the LS with information on the Stage-3 normative work plan to support standardized and operator specific traffic categories in URSP rules."

TDoc C1-232633:

- An attacker can send reject messages with any specified error causes and trigger the corresponding UE error handling behaviour, which might cause a denial of the expected U2N relay service to the remote UE.
- SA3 will keep CT1 updated, based on the progress on this issue.

Example snippet: "SA3 would like to thank CT1 for the LS on U2N relay direct link setup failure due to RSC mismatch or integrity failure."

Summary of Technical Differences:

1. Energy Efficiency, Energy Saving, and Digital Sobriety:
- Energy Saving: optimization of energy efficiency by network operators
- Digital Sobriety: adoption of best practices by service users and 3GPP
- Use cases and requirements for energy savings identified
- Solutions specified to support these use cases and achieve energy savings

Example from TDoc C1-232245: "Describing use cases / scenarios in which energy savings may be achieved, and related requirements."

2. Protocol Enhancements for Multicast MBS Session Handling:
- Solutions #20 and #21 propose enhancements for mobility registration update procedure
- UE includes PDU session ID and MBS session information container in Registration Request message
- AMF routes multicast MBS session information container to related SMF
- SMF handles joining or leaving multicast MBS session

Example from TDoc C1-232612: "In the solutions, the UE includes multicast MBS session information container, which is information for SM handling, in the MM signalling (i.e. Registration Request and Service Request)."

3. Conformance Tests and Network Selection Modes:
- Conformance tests from 3GPP TS 31.124 become optional if device manufacturer declares support of possible options in table A.1 of the same specification
- UE mandated to support both manual and automatic network selection modes

Examples from TDoc C1-232625: "Further, the necessity to run related conformance tests from 3GPP TS 31.124 (USAT test specification) becomes optional when the device manufacturer declares the support of possible options in table A.1 of 3GPP TS 31.124 (Section 3.3) for the device under test" and "3GPP TS 22.011 Section 3.2.1 (responsibility of 3GPP SA WG1) mandates the UE to support both manual and automatic network selection (modes)."

4. UI/MMI Features for Wearable Form Factors:
- Terminal support of display capability and keypad can be disabled if not supported by wearable device
- Provision to handle devices with limited UI/MMI features

Example from TDoc C1-232625: "Per, 3GPP TS 31.111 (Section 5.2) and ETSI TS 102.223 (Section 5.2), there is a provision to handle devices with limited UI/MMI features."

Overall, the technical differences highlighted in these TDocs cover various aspects of 5G network optimization, including energy efficiency, protocol enhancements for multicast MBS session handling, conformance tests, and UI/MMI features for wearable form factors. Each TDoc provides specific examples and details to support the identified differences.

3GPP-C1-141-e    Agenda Item 13.1 : Rel-13 Mision Critical Work Items and issues:

Technical Differences:

1. TDoc C1-232431 includes a clause that specifies the MCPTT client shall enter the 'U: Pre-established session in use' state upon accepting an incoming call, while TDoc C1-232432 does not have this clause.
2. TDoc C1-232431 specifies that the MCPTT client shall use only the media streams indicated as used in the associated call session Media Streams field if the Connect contains a Media Streams field, whereas TDoc C1-232432 does not have this clause.
3. TDoc C1-232431 specifies the creation of an instance of the 'Floor participant state transition diagram for basic operation' as specified in clause 6.2.4, while TDoc C1-232432 does not have this clause.

Examples from TDoc C1-232431:

- "shall enter the 'U: Pre-established session in use' state"
- "shall use only the media streams of the pre-established session which are indicated as used in the associated call session Media Streams field, if the Connect contains a Media Streams field"
- "shall create an instance of the 'Floor participant state transition diagram for basic operation' as specified in clause 6.2.4"

Examples from TDoc C1-232432:

- No specific examples that highlight the differences from TDoc C1-232431 were provided in the original TDoc.

- TDoc C1-232414, C1-232420, C1-232421, and C1-232423 are all related to the Floor Taken message in MCPTT communication.
- All four TDocs require the inclusion of the granted MCPTT user's ID in the Granted Party's Identity field and may include the functional alias of the granted MCPTT user in the Functional Alias field, if privacy is not requested.
- All four TDocs require the inclusion of a Message Sequence Number field with a value increased by 1.
- All four TDocs require the inclusion of the Floor Indicator field with the G-bit set to '1' (Dual floor).
- TDoc C1-232414 and C1-232420 require the inclusion of appropriate indications in the Floor Indicator field if a group call is a broadcast group call, a system call, an emergency call, an imminent peril call, or a temporary group session.
- TDoc C1-232421 and C1-232423 require the inclusion of the location of the user as specified in clause 6.2.4.3.5.
- TDoc C1-232414 and C1-232420 require starting the T11 (End of RTP dual) timer and entering the state to 'D: Floor Taken' state.
- TDoc C1-232421 and C1-232423 require setting the general state to the 'G: Floor Taken' state and sending the termination instruction to the 'dual floor control operation' state machine.
- TDoc C1-232423 requires the inclusion of Functional Alias.
- If the first bit in the subtype of the Floor Release message is set to '1' (acknowledgement is required) as specified in clause 8.2.2, TDoc C1-232421 and C1-232423 require sending a Floor Ack message.

Example snippets from the original TDocs:

- TDoc C1-232414: "shall include the granted MCPTT user's MCPTT ID in the Granted Party's Identity field and may include the functional alias of the granted MCPTT user in the Functional Alias field, if privacy is not requested;"
- TDoc C1-232420: "shall include the Floor Indicator field with the G-bit set to '1' (Dual floor);"
- TDoc C1-232421: "shall include the location of the user as specified in clause 6.2.4.3.5; 4. shall set the general state to the 'G: Floor Taken' state; and 5. shall send the termination instruction to the 'dual floor control operation' state machine."
- TDoc C1-232423: "shall include the granted MCPTT user's (overriding participant) MCPTT ID in the Granted Party's Identity field; [...] shall include the location of the user as specified in clause 6.2.4.3.5; 4. shall set the general state to the 'G: Floor Taken' state; [...] Functional Alias: *"

The technical differences among the two TDocs are as follows:

1. TDoc C1-232388 includes a step to send the termination instruction to the state machine for dual floor control operation, whereas TDoc C1-232400 does not mention it.
Example from TDoc C1-232388: "5. shall send the termination instruction to the state machine for dual floor control operation."

2. TDoc C1-232400 includes a step for the floor participant to send a Floor Ack message if the first bit in the subtype of the Floor Taken message is set to '1' (Acknowledgment is required), whereas TDoc C1-232388 does not mention it.
Example from TDoc C1-232400: "1. if the first bit in the subtype of the Floor Taken message is set to '1' (Acknowledgment is required) as described in subclause 8.3.2, shall send a Floor Ack message."

3. TDoc C1-232388 does not mention the duration of the Floor Taken message, whereas TDoc C1-232400 mentions that the duration is not specified.
Example from TDoc C1-232400: "Duration: *"

4. TDoc C1-232400 includes the phrase "First Change" in the duration section, which is not present in TDoc C1-232388.
Example from TDoc C1-232400: "Duration: First Change *"

Examples from TDoc C1-232388 to support the differences:

- Example for Point 1: "5. shall send the termination instruction to the state machine for dual floor control operation."
- Example for Point 2: N/A (Not present in TDoc C1-232388)
- Example for Point 3: N/A (Duration not mentioned in TDoc C1-232388)
- Example for Point 4: N/A (Not present in TDoc C1-232388)

Examples from TDoc C1-232400 to support the differences:

- Example for Point 1: N/A (Not present in TDoc C1-232400)
- Example for Point 2: "1. if the first bit in the subtype of the Floor Taken message is set to '1' (Acknowledgment is required) as described in subclause 8.3.2, shall send a Floor Ack message."
- Example for Point 3: "Duration: *"
- Example for Point 4: "Duration: First Change *"

Technical differences among the TDocs:

1. TDoc C1-232425 and C1-232426:
- TDoc C1-232426 includes an additional clause regarding the automatic answer mode for the participating MCPTT function when receiving a SIP INVITE request from the controlling MCPTT function.
- The pre-established session call control specific data fields follow the syntax specified in subclause 8.1.3 in both TDocs.

Example snippet from TDoc C1-232426: "9.3.2.3.3 Receive SIP INVITE request (R: SIP INVITE) Upon receiving a SIP INVITE request from the controlling MCPTT function, if in automatic answer mode..."

2. TDoc C1-232427:
- TDoc C1-232427 is the same as TDoc C1-232426, except it does not include the additional clause regarding the automatic answer mode for the participating MCPTT function.

3. TDoc C1-232429:
- TDoc C1-232429 is the same as TDocs C1-232425, C1-232426, and C1-232427 regarding the handling of incoming calls and the creation of the 'Floor participant state transition diagram for basic operation'.
- The pre-established session call control specific data fields follow the syntax specified in subclause 8.1.3.

Example snippet from TDoc C1-232429: "1. if the MCPTT client accepts the incoming call the MCPTT client: a. shall send the Acknowledgement message with Reason Code field set to 'Accepted'; b. shall use only the media streams of the pre-established session which are indicated as used in the associated call session Media Streams field, if the Connect contains a Media Streams field; . shall create an instance of the 'Floor participant state transition diagram for basic operation' as specified in clause 6.2.4; and . shall enter the 'U: Pre-established session in use' state; or 2..."

3GPP-C1-141-e    Agenda Item 14.1 : Rel-14 Mision Critical Work Items and issues:

Technical differences among the TDoc snippets:

- All the TDocs share the same section, 12.1.2.2 Semantics, which explains the use of certain fmtp attributes in SDP offers and answers.
- The "mc_queueing" fmtp attribute is used to indicate support of the Transmission Request message queueing mechanism.
- The "mc_implicit_request" fmtp attribute indicates that the offerer implicitly requests for media transmission (without the need to send a Transmission Request message).
- The "mc_priority" fmtp attribute indicates the maximum transmission priority that the offerer requests to be used with Transmission Request messages sent by the offerer.
- The "mc_reception_priority" fmtp attribute indicates the maximum reception priority that the offerer requests to be used with Reception Request messages sent by the offerer.
- When the "mc_granted" fmtp attribute is used in an SDP offer, it does not indicate an actual request for the media transmission.
- TDoc C1-232513 includes a list of IETF RFCs related to SIP, including RFCs for conference establishment, service identification, push-to-talk over cellular (PoC) service, request authorization, managing client-initiated connections, and communications resource priority.

Example snippets from the TDoc to support these differences:

- "In an SDP offer and answer, the 'mc_queueing' fmtp attribute is used to indicate support of the Transmission Request message queueing mechanism, as defined in the present specification." (all TDocs)
- "In an SDP offer, the 'mc_implicit_request' fmtp attribute indicates that the offerer implicitly requests for media transmission (without the need to send a Transmission Request message)." (all TDocs)
- "In an SDP offer, the 'mc_priority' fmtp attribute indicates (using an integer value between '1' and '255') the maximum transmission priority that the offerer requests to be used with Transmission Request messages sent by the offerer." (all TDocs)
- "In an SDP offer, the 'mc_reception_priority' fmtp attribute indicates (using an integer value between '1' and '255') the maximum reception priority that the offerer requests to be used with Reception Request messages sent by the offerer." (all TDocs)
- "When the 'mc_granted' fmtp attribute is used in an SDP offer, it does not indicate an actual request for the media transmission." (all TDocs)
- "[TDoc C1-232513]: [37] IETF RFC 5366 (October 2008): 'Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP)'. [14] IETF RFC 6050 (November 2010): 'A Session Initiation Protocol (SIP) Extension for the Identification of Services'. [53] IETF RFC 4354 (January 2006): 'A Session Initiation Protocol (SIP) Event Package and Data Format for Various Settings in Support for the Push-to-Talk over Cellular (PoC) Service'. [32] IETF RFC 4538 (June 2006): ' Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)'. [35] IETF RFC 5626 (October 2009): 'Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)'. [33] IETF RFC 4412 (February 2006): 'Communications Resource Priority for the Session Initiation Protocol (SIP)'. [5]. First Change" (TDoc C1-232513)

[TDoc C1-232473]:
- Transmission control Ack message includes Message Type field set to '0' and Source field set to '0'
- SSRC of granted transmission participant is stored and used in RTP media packets
- Transmission granted notification is provided to the user
- Timer T100 (Transmission Request) is stopped
- 'U: has permission to transmit' state is entered
- Waiting transmission participant fields include SSRC, Queued User ID, and Queue info
- Media transmission notification message content is shown in Table 9.2.13-1
- Available transmission control specific data fields and assigned field IDs are listed in Table 9.2.3.1-1

[TDoc C1-232475]:
- Transmission control Ack message includes Message Type field set to '0' and Source field set to '0'
- SSRC of granted transmission participant is stored and used in RTP media packets
- Transmission granted notification is provided to the user
- Timer T100 (Transmission Request) is stopped
- 'U: has permission to transmit' state is entered
- Media Transmission notification message includes granted MCVideo user's MCVideo ID in User ID field (if privacy not requested), granted MCVideo user's SSRC in SSRC of transmitter field, and Message Sequence Number field with increased value
- Duration is not specified

[TDoc C1-232476]:
- Transmission control Ack message includes Message Type field set to '0' and Source field set to '0'
- SSRC of granted transmission participant is stored and used in RTP media packets
- Transmission granted notification is provided to the user
- Timer T102 (Transmission Queue position request) is stopped
- 'U: has permission to transmit' state is entered
- Timer T4 (Transmission Grant) expired logic includes sending Transmission Grant message with granted priority field
- Duration is not specified

Technical differences among the following TDoc:

- TDoc C1-232483, C1-232489, C1-232490, C1-232497 all have identical content in section 12.1.2.2 Semantics.
- The "mc_queueing" fmtp attribute is used to indicate support of the Transmission Request message queueing mechanism.
- The "mc_implicit_request" fmtp attribute indicates that the offerer implicitly requests for media transmission without the need to send a Transmission Request message.
- The "mc_priority" fmtp attribute indicates the maximum transmission priority that the offerer requests to be used with Transmission Request messages sent by the offerer.
- The "mc_reception_priority" fmtp attribute indicates the maximum reception priority that the offerer requests to be used with Reception Request messages sent by the offerer.
- The "mc_granted" fmtp attribute, when used in an SDP offer, does not indicate an actual request for media transmission.

Example snippets from the original TDoc:

- "In an SDP offer and answer, the "mc_queueing" fmtp attribute is used to indicate support of the Transmission Request message queueing mechanism, as defined in the present specification." (section 12.1.2.2 Semantics)
- "In an SDP offer, the "mc_implicit_request" fmtp attribute indicates that the offerer implicitly requests for media transmission (without the need to send a Transmission Request message)." (section 12.1.2.2 Semantics)
- "In an SDP offer, the "mc_priority" fmtp attribute indicates (using an integer value between '1' and '255') the maximum transmission priority that the offerer requests to be used with Transmission Request messages sent by the offerer." (section 12.1.2.2 Semantics)
- "In an SDP offer, the "mc_reception_priority" fmtp attribute indicates (using an integer value between '1' and '255') the maximum reception priority that the offerer requests to be used with Reception Request messages sent by the offerer." (section 12.1.2.2 Semantics)
- "When the "mc_granted" fmtp attribute is used in an SDP offer, it does not indicate an actual request for the media transmission." (section 12.1.2.2 Semantics)

Technical differences among the TDocs are:

1. TDoc C1-232528:
- The TDoc refers to IETF RFC 6809, which is about indicating support of features and capabilities in SIP.
- It also refers to IETF RFC 7462, which is about URNs for the Alert-Info header field in SIP.
- Additionally, it mentions IETF RFC 6050, which is an extension for identifying services in SIP.
- The TDoc also includes references to IETF RFC 5366, which is about conference establishment using request-contained lists in SIP, IETF RFC 4538, which is about request authorization through dialog identification in SIP, and IETF RFC 5626, which is about managing client-initiated connections in SIP.

2. TDoc C1-232529:
- The TDoc has the same references as TDoc C1-232528.

3. TDoc C1-232530:
- The TDoc has the same references as TDoc C1-232528 and C1-232529.

4. TDoc C1-232531:
- The TDoc has the same references as TDoc C1-232528, C1-232529, and C1-232530.

Example snippets from the original TDoc to support the difference highlighting are not provided.

3GPP-C1-141-e    Agenda Item 17.2.29 : MINT

3GPP-C1-141-e    Agenda Item 18.1.1 : Work Item Descriptions

TDoc C1-232068 - CT6 Objectives:

- The objective is to update relevant CT6 specifications to support stage 2 requirements for handling signalling overload and UE power savings due to DC.
- This includes potential configuration of wait range upon return to coverage and power saving parameters during out-of-coverage period.
- Updates to relevant internal and external network interfaces are also included, such as provisioning coverage availability information in the AF and updates to NEF exposure procedure for provisioning satellite coverage availability information from the AF.

Example snippet: "The objective of the normative phase is to update the relevant CT6 specifications to support the stage 2 requirements for handling of signalling overload and for UE power savings due to DC..."

TDoc C1-232086 - CT4 Objectives:

- The objective is to provide stage 3 support for the solution to KI#1 (Multicast MBS data reception in RRC Inactive state) which may include defining MBS Assistance Information and AF provisions to UDM via NEF.
- The objective is to update the 5GMM potentially due to receiving multicast MBS session data in the RRC inactive state.
- Stage 3 support is also provided for the solution to KI#5 (Coexistence with existing power saving mechanisms for capability-limited devices) with updates for coexistence of UE power saving functions.
- MBS Assistance Information should be part of the MBS subscription data in UDM and retrieved from UDM by SMF.
- Stage 3 support is provided for the solution to KI#2 (5MBS MOCN Network Sharing) with the definition of the Associated Session ID and its encoding.

Example snippet: "CT4 - Stage 3 support for the solution to KI#1 (Multicast MBS data reception in RRC Inactive state), which possibly implies the following..."

CT3 Objectives:

- The objective is to update relevant CT3 specifications to support stage 2 requirements.
- Objectives are defined based on conclusions of the stage 2 study, stage 2 WID, and stage 2 normative CRs agreed upon until now.
- There may be further CT3 impacts based on existing stage 2 requirements.

Example snippet: "CT3 objectives: The objective of the normative phase is to update the relevant CT3 specifications to support the stage 2 requirements."

Overall Technical Differences:

- CT6 focuses on updates to support handling of signalling overload and UE power savings due to DC while also updating relevant internal and external network interfaces.
- CT4 provides stage 3 support for various solutions, including defining MBS Assistance Information, updating the 5GMM, and providing updates for UE power saving functions.
- CT3 focuses on updating relevant specifications to support stage 2 requirements as defined by the stage 2 study, WID, and normative CRs.

TDoc C1-232126:

- Provisioning of DetNet configuration from the DetNet controller to 5GS
- Potential extension of the flow description (PCF) to include the IPv6 flow label and IPsec SPI
- Updates of the PCC procedures to describe the provisioning of DetNet configuration into 5GS
- 5GS DetNet node reporting
- Updates of the PCC procedures and/or API impacts to cover the report of 5GS DetNet node information

Example snippets from TDoc C1-232126:

- "Potential extension of the flow description (PCF) to include the IPv6 flow label and IPsec SPI"
- "Updates of the PCC procedures to describe the provisioning of DetNet configuration into 5GS"
- "Updates of the PCC procedures and/or API impacts to cover the report of 5GS DetNet node information"

TDoc C1-232176:

- Enhance CT1 stage 2 specifications to support HPLMN provided prioritization information of VPLMNs
- Define when the home network provides the SOR-enhanced information to the UE
- Potential enhancements to UDR to store the enhanced-SOR information

Example snippets from TDoc C1-232176:

- "Enhance CT1 stage 2 specifications to support HPLMN provided prioritization information of VPLMNs"
- "Define when the home network provides the SOR-enhanced information to the UE"
- "Potential enhancements to UDR to store the enhanced-SOR information"

TDoc C1-232196:

- Define NAS protocol enhancements to indicate the capability of the UE supporting SOR-enhanced for Slice-based PLMN Selection
- Define how to indicate the capability of the UE supporting SOR-enhanced for Slice-based PLMN Selection to the network
- Define the information transferred from the network to the UE which is used for Slice-based PLMN selection
- Enhancements to UDM and SoR-AF to generate, deliver and update the enhanced-SOR information

Example snippets from TDoc C1-232196:

- "Define NAS protocol enhancements to indicate the capability of the UE supporting SOR-enhanced for Slice-based PLMN Selection"
- "Define how to indicate the capability of the UE supporting SOR-enhanced for Slice-based PLMN Selection to the network"
- "Define the information transferred from the network to the UE which is used for Slice-based PLMN selection"
- "Enhancements to UDM and SoR-AF to generate, deliver and update the enhanced-SOR information"

TDoc C1-232361:

- Define the protocol aspects of the new features of Release 18 listed in clause 3 based on Stage 2 technical specifications
- Enhancements related to issues identified in any of the ETSI plug-tests for MC services
- Location enhancements for on-network and off-network
- Preconfigured group enhancements

Example snippets from TDoc C1-232361:

- "Define the protocol aspects of the new features of Release 18 listed in clause 3 based on Stage 2 technical specifications"
- "Enhancements related to issues identified in any of the ETSI plug-tests for MC services"
- "Location enhancements for on-network and off-network"
- "Preconfigured group enhancements"

Technical differences among the TDocs:

[TDoc C1-232318]:

- Stage 3 for EDGE-1, EDGE-4 reference points.
- Usage of SEAL services (e.g. Notification Management Service).
- Primary classification is not specified.
- Dependency on non-3GPP (draft) specification: None.

[TDoc C1-232358]:

- Defining APIs exposed by the SEALDD server.
- Potential enhancement of APIs provided by the SEAL servers.
- Enhancements to MSGin5G service to use SEAL data delivery management.
- Enhancements to support the SEALDD server with transport layer service continuity capability.

[TDoc C1-232359]:

- Specifying the technical enhancements and necessary changes to the 3GPP Northbound and Application Layer interfaces and APIs.
- Consolidation of the common protocol aspects.
- Protocol and interface enhancements and optimizations.
- Corrections and/or changes missed in the previous 3GPP releases.

[TDoc C1-232365]:

- Enhancements to the V2X application enabler (VAE) layer protocol for V5-AE and V1-AE.
- Enhancements to the service enabler architecture layer for verticals (SEAL) layer protocols for supporting advanced V2X services.
- Service requirements provided by SA WG1 in TS 22.185 and TS 22.186.

Example snippets from the original TDocs:

- "CT WGs need to define protocol aspects of the architecture for enabling edge applications, usage of SEAL services and related APIs."
- "The following areas of work will include the following (non-exhaustive, additional areas can be identified based on the progress in the normative stage-2 work in SA WG6)."
- "3GPP application layer interfaces and APIs (e.g. ProSe PC2 reference point defined in 3GPP TS 29.343, UAE Server APIs defined in 3GPP TS 29.257, EDGEAPP APIs defined in 3GPP TS 29.558, etc.) are also specified in 3GPP to enable the support and exposure of application layer frameworks/services and their interactions with the 3GPP network services."
- "The stage-3 work shall be started only after the applicable normative stage-2 requirements are available."

[TDoc C1-232007]:

- CT3 focuses on supporting enhanced mobility for idle and connected mode mobility between SNPNs without new network selection.
- CT4 highlights possible impacts on AMF communication service, specifically populating the target SNPN NID during idle mode inter AMF mobility procedures.
- CT3 also includes support for providing access to localized services, which involves enhancements to automatic network selection and CP-SOR.

[TDoc C1-232030]:

- The objective of this work item is to specify solutions in CT WG1 remit to support the attach procedure completion in sparse LEO constellations with limited ground stations.
- Modifications to the NAS EMM protocol layer are needed to support the initial attach procedure for IoT NTN deployments.
- This work item focuses on addressing the challenges of providing sufficient service to delay-tolerant IoT devices in sparse LEO constellations with limited ground stations.

[TDoc C1-232105]:

- This work item proposes enhancements to PLMN and SNPN selection procedures to support selecting an underlay network in a specific deployment that requires an SLA/agreement.
- The current PLMN selection parameter only considers the SLA/agreement between PLMNs for roaming services and does not consider an agreement/SLA between subscribed SNPNs and VPLMNs.
- The goal is to provide access to non-public network services when the UE is camping in the NG-RAN of a PLMN, by obtaining IP connectivity and discovering/connecting to an N3IWF in the Stand-alone Non-Public Network.

3GPP-C1-141-e    Agenda Item 18.1.2 : CRs and Discussion Documents related to new or revised Work Items

TDoc C1-232029:

- IoT NTN deployments may have sparse LEO constellations and limited ground stations
- Satellites may not have connection to NTN GW on the ground in their current position
- Architectural changes or enhancements for S&F operation mode may be needed in Rel-19
- New WID proposal on Attach suspend/resume for satellite IoT devices submitted to CT1#141e
- Minimum requirement for Rel-18 is to support initial attach

Example snippet: "To support those IoT NTN deployments from Rel-18, the minimum requirement is to have a support for initial attach."

TDoc C1-232032:

- UE operating in single-registration mode sets additional 5GMM state and 5GS update status
- Configuration of radio transceiver for specific RAT is out of scope
- UE stores PLMN identity and current geographical location in list of "PLMNs not allowed to operate"
- ATTACH REJECT message triggers timer T3346

Example snippet: "If the ATTACH REJECT message is not integrity protected, the UE shall start timer T3346 with a random value from the default range specified in 3GPP TS 24.008."

TDoc C1-232069:

- Protocol used over user plane between UE and external server for satellite coverage availability information may not be standardized
- Satellite coverage availability information refers to location and time information related to expected coverage availability of satellite/satellite constellation
- Standardization of format of satellite coverage availability information is necessary for effectiveness
- AMF may use satellite coverage availability information to support satellite access by UEs
- Definition of satellite coverage availability information application to UE and AMF is FFS

Example snippet: "To be effective, the format of the satellite coverage availability information needs to be standardized."

TDoc C1-232106:

- UE may access stand-alone non-public network services via PLMN
- UE may register with SNPN via PLMN User Plane using SNPN credentials
- PDU Session continuity between PLMN and SNPN may be supported using Handover of a PDU Session procedures

Example snippet: "To access SNPN services, a UE that has successfully registered with a PLMN over 3GPP access may perform another registration via the PLMN User Plane with an SNPN."

TDoc C1-232107:

- MS shall stop applying signal level enhanced network selection if received signal quality is below "Operator controlled signal threshold per access technology"
- PLMNs offering access to RLOS may be selected based on preferred PLMNs and disaster conditions
- PLMN broadcasting disaster related indication may also be selected

Example snippet: "The MS shall stop applying signal level enhanced network selection and repeat the network selection procedure as specified in clause 4.4.3.1."

TDoc C1-232175:

- New WID in CT1 remit to support providing VPLMN network slice information to roaming UE
- HPLMN shall provide UE with prioritization information of VPLMNs with which UE may register for network slice

Example snippet: "For a roaming UE activating a service/application requiring a network slice not offered by the serving network but available in the area from other network(s), the HPLMN shall be able to provide the UE with prioritization information of the VPLMNs with which the UE may register for the network slice."

Technical differences among the TDocs:

- TDoc C1-232195 discusses the SA1 requirement for providing prioritization information of the VPLMNs with which a roaming UE may register for a network slice, but only if the serving network cannot offer the network slice related to the service/application being activated/requested by the UE.
- TDoc C1-232309 outlines the steps a UE should take if it did not receive steering of roaming information during initial registration or if security check fails, including performing PLMN selection with the current VPLMN as the lowest priority.
- TDoc C1-232335 suggests potential solutions for handling UE authentication failures due to lack of communication with the ground station, such as reducing retry attempts or introducing new timers.
- TDoc C1-232615 breaks down key issues that need to be discussed in scope of slice-based PLMN selection, including the semantics of the new prioritization information provided to the UE.

Examples from the original TDocs supporting the differences highlighted:

- TDoc C1-232195: "In other words, the SA1 requirement does not recommend providing all roaming UEs with the prioritization information of the VPLMNs if the serving network can offer the network slice related to the service/application that is being activated (or) requested by the UE."
- TDoc C1-232309: "If the UE receives steering of roaming information in the REGISTRATION ACCEPT or DL NAS TRANSPORT message and the security check to verify that the steering of roaming information is provided by HPLMN is successful, the UE shall remove the current selected PLMN from the list of 'PLMNs where registration was aborted due to SOR'."
- TDoc C1-232335: "For example, reducing the number of retries by setting the attach attempt counter to 5 after the expiration of T3410 and T3411, implementing a new time value for T3402, or introducing a new timer could all be potential solutions."
- TDoc C1-232615: "The mapping of the scenario that the SA1 requirement addresses onto protocol-level specifics; namely: application requiring a network slice not offered by the serving network."

Technical Differences between TDocs:

TDoc C1-232046:
- SNPN identity for NR is specified in 3GPP TS 38.331 [65].
- Provisioning information for SNPN selection for localized services in SNPN is provided by an MS supporting access for localized services in SNPN, consisting of either a prioritized list of preferred SNPNs, a prioritized list of preferred GINs, or both.
- N1 mode capability refers to the UE's capability associated with an N1 NAS signalling connection between the UE and network.

Example Snippets:
- "for NR, see the broadcast information as specified in 3GPP TS 38.331 [65]."
- "Provisioning information for SNPN selection...consisting of: a) a "credentials holder controlled prioritized list of preferred SNPNs for access for localized services in SNPN", where each entry contains an SNPN identity and a validity information consisting of time validity information; b) a "credentials holder controlled prioritized list of preferred GINs for access for localized services in SNPN", where each entry contains a GIN and a validity information consisting of time validity information; or c) both of the above."
- "Capability of the UE associated with an N1 NAS signalling connection between the UE and network."

TDoc C1-232585:
- CT1 needs to define a new protocol for SEAL data delivery management based on normative stage-2 work being developed in 3GPP TS 23.433 [4].
- The development includes an overall application framework/enabling layer platform architecture for application data delivery.
- The functionalities include application support functions, supporting different application data characteristics, and coordination with EEL.

Example Snippets:
- "CT1 needs to define a new protocol for SEAL data delivery management in 3GPP TS 24.543."
- "includes to develop a suitable overall application framework/enabling layer platform architecture for application data delivery considering the following aspects: 1) how to integrate all the 3GPP application data delivery (e.g., potentially integrating with MSGin5G, potentially integrating MBSF-U for data delivery over 5G MBS); and 2) define new capabilities including..."
- "c. SEALDD coordination with EEL."

TDoc C1-232607:
- CT1 is working on providing stage-3 work on SEAL data delivery enabler for vertical applications.
- SEALDD WID needs to be updated and impacts CT1 enabling Edge applications specification.
- An analysis of the CR and related stage-2 requirements shows that SEALDD impacts CT1 enabling Edge applications specification.

Example Snippets:
- "CT1 is working on providing the stage-3 work on SEAL data delivery enabler for vertical applications."
- "This specification is currently not listed as impacted in the approved SEALD WID."
- "An analysis of this CR and related stage-2 requirements show that SEALDD impacts the CT1 enabling Edge applications specification."

TDoc C1-232108:

- The MS stops applying signal level enhanced network selection if the received signal quality from none of the candidate PLMN(s) or PLMN/access technology combination(s) is equal to or greater than the "Operator controlled signal threshold per access technology" stored in the USIM.
- The MS repeats the network selection procedure as specified in clause 4.4.3.1.
- Example snippet: "If the received signal quality from none of the candidate PLMN(s) or PLMN/access technology combination(s) is equal to or greater than the "Operator controlled signal threshold per access technology" stored in the USIM, the MS shall stop applying signal level enhanced network selection and repeat the network selection procedure as specified in clause 4.4.3.1."

TDoc C1-232109:

- The MS attempts registration on SNPNs based on MS implementation specific order if more than one SNPN broadcast the same GIN.
- The MS selects an SNPN which is identified by an SNPN identity that is included neither in the SNPN selection parameters of the entries of the "list of subscriber data" nor in the SNPN selection parameters associated with the PLMN subscription, which does not broadcast a GIN which is included in the credentials holder controlled prioritized list of GINs, and which broadcasts an indication that the SNPN allows registration attempts from MSs that are not explicitly configured to select the SNPN.
- If LR failure prevents registration on available SNPNs, the MS selects one of those SNPNs again and enters a limited service state.
- Example snippet: "If there were one or more SNPNs which were available, allowable, and identified by an SNPN identity in an entry of the "list of subscriber data" in the ME but an LR failure made registration on those SNPNs unsuccessful, the MS selects one of those SNPNs again and enters a limited service state."

TDoc C1-232308:

- Components that can be used in a solution are identified including UE needed services/applications, URSP rules, prioritization information of the VPLMNs with which the UE may register for network slices (SaSoRI), visible PLMNs, and legacy prioritized PLMN lists.
- HPLMN is able to provide the UE with prioritization information of the VPLMNs with which the UE may register for the network slice when a roaming UE activates a service/application requiring a network slice not offered by the serving network but available in the area from other network(s).
- The UE identifies the needed services/application and evaluates URSP rules that results in one or more matches to determine the most appropriate VPLMN to select.
- Example snippet: "For a roaming UE activating a service/application requiring a network slice not offered by the serving network but available in the area from other network(s), the HPLMN shall be able to provide the UE with prioritization information of the VPLMNs with which the UE may register for the network slice."

TDoc C1-232389:

- The UE performs items a), b) and c) of the procedure for steering of roaming in clause 4.4.6 if a "Steering of Roaming" of type is included and neither a SOR-CMCI is included nor the UE is configured with the SOR-CMCI.
- The UE releases the current N1 NAS signalling connection locally and attempts to obtain service on a higher priority PLMN as specified in clause 4.4.3.3 if the UE has a list of available and allowable PLMNs in the area and based on this list or any other implementation specific means the UE determines that there is a higher priority PLMN than the selected VPLMN, or the UE does not have a list of available and allowable PLMNs in the area and is unable to determine whether there is a higher priority PLMN than the selected VPLMN using any other implementation specific means and the UE is in automatic network selection mode.
- Example snippet: "If the UE has a list of available and allowable PLMNs in the area and based on this list or any other implementation specific means the UE determines that there is a higher priority PLMN than the selected VPLMN; or the UE does not have a list of available and allowable PLMNs in the area and is unable to determine whether there is a higher priority PLMN than the selected VPLMN using any other implementation specific means; and the UE is in automatic network selection mode, then the UE shall either: i) release the current N1 NAS signalling connection locally and then attempt to obtain service on a higher priority PLMN as specified in clause 4.4.3.3 by acting as if timer T that controls periodic attempts has expired."

3GPP-C1-141-e    Agenda Item 18.1.3 : Status of other Work Items

3GPP-C1-141-e    Agenda Item 18.2 : WIs for common and EPS/5GS

3GPP-C1-141-e    Agenda Item 18.2.1. : SAES18 WIs

3GPP-C1-141-e    Agenda Item 18.2.1.1 : SAES18

3GPP-C1-141-e    Agenda Item 18.2.1.3 : SAES18-non3GPP

3GPP-C1-141-e    Agenda Item 18.2.2. : 5GProtoc18 Wis

- TDoc C1-232374 and C1-232375 describe the behavior of the UE when receiving a non-integrity-protected REGISTRATION REJECT message, with C1-232375 additionally describing the behavior when the UE is operating in SNPN access operation mode.
- C1-232374:
- If the REGISTRATION REJECT message is not integrity protected, the UE shall memorize the current TAI was stored in the list of "5GS forbidden tracking areas for roaming" for non-integrity protected NAS reject message.
- If the UE is operating in SNPN access operation mode, the UE shall store the current TAI in the list of "5GS forbidden tracking areas for roaming" for the current SNPN and, if the UE supports access to an SNPN using credentials from a credentials holder, equivalent SNPNs or both, the selected entry of the "list of subscriber data" or the selected PLMN subscription, and enter the state 5GMM-DEREGISTERED.LIMITED-SERVICE or optionally 5GMM-DEREGISTERED.PLMN-SEARCH.
- Otherwise, the UE shall store the current TAI in the list of "5GS forbidden tracking areas for roaming" for the current SNPN and, if the UE supports access to an SNPN using credentials from a credentials holder, equivalent SNPNs or both, the selected entry of the "list of subscriber data" or the selected PLMN subscription.
- C1-232375:
- If the REGISTRATION REJECT message is not integrity protected, the UE shall memorize the current TAI was stored in the list of "5GS forbidden tracking areas for roaming" for non-integrity protected NAS reject message.
- If the UE is operating in SNPN access operation mode, the UE shall store the current TAI in the list of "5GS forbidden tracking areas for roaming" for the current SNPN and, if the UE supports access to an SNPN using credentials from a credentials holder, equivalent SNPNs or both, the selected entry of the "list of subscriber data" or the selected PLMN subscription, and enter the state 5GMM-DEREGISTERED.LIMITED-SERVICE.
- The UE shall reset the registration attempt counter and store the SNPN identity in the "permanently forbidden SNPNs" list for the specific access type for which the message was received and, if the UE supports access to an SNPN using credentials from a credentials holder, equivalent SNPNs or both, the selected entry of the "list of subscriber data" or the selected PLMN subscription.
- C1-232376 describes the behavior of the UE when receiving a CONFIGURATION UPDATE COMMAND message with the MPS indicator bit in the Priority indicator IE set to "Access identity 1 valid".
- If received via 3GPP access or non-3GPP access when the UE is registered to the same PLMN or SNPN over 3GPP access and non-3GPP access, the UE shall act as a UE with access identity 1 configured for MPS in all NG-RAN of the registered PLMN/SNPN and its equivalent PLMNs/SNPNs.
- If the UE receives the CAG information list IE in the CONFIGURATION UPDATE COMMAND message and the UE is operating in SNPN access operation mode, the UE shall ignore the content of CAG information list IE.
- C1-232412 describes the behavior of the UE when the AMF includes a new configured NSSAI in the CONFIGURATION UPDATE COMMAND message and the subscription information includes the NSSRG information.
- If the UE has set the NSSRG bit in the 5GMM capability IE of the REGISTRATION REQUEST message to "NSSRG supported", then the AMF shall include the NSSRG information in the CONFIGURATION UPDATE COMMAND message.
- If the UE has set the NSSRG bit to "NSSRG not supported", then the configured NSSAI shall include one or more S-NSSAIs each of which is associated with all the NSSRG value(s) of the default S-NSSAI(s), or the configured NSSAI shall include, based on the indication received from the UDM, as specified in 3GPP TS 23.501.
- If a new allowed NSSAI information or AMF re-configuration of supported S-NSSAIs requires an AMF relocation, the AMF shall indicate "registration requested" in the Registration requested bit of the Configuration update indication IE and include the Allowed NSSAI IE in the CONFIGURATION UPDATE COMMAND message.

Technical Differences among TDoc C1-232404 and TDoc C1-232405:

1. Timer T3502:
TDoc C1-232404: The default value of timer T3502 can be used by UE in various scenarios. Additionally, the value of this timer can be sent by the network to the UE in the REGISTRATION REJECT message during initial registration.
TDoc C1-232405: The default value of timer T3502 can be used by UE in various scenarios. Moreover, the UE shall apply this value in all tracking areas of the registration area assigned to the UE, until a new value is received.

Example from TDoc C1-232405: "The UE shall apply this value in all tracking areas of the registration area assigned to the UE, until a new value is received."

2. New PLMN/SNPN Entry:
TDoc C1-232404: If a new PLMN which is not in the list of equivalent PLMNs or a new SNPN has been entered, the initial registration procedure fails, the registration attempt counter is equal to 5 and no REGISTRATION REJECT message was received from the new PLMN or SNPN, the UE uses the default value of timer T3502.
TDoc C1-232405: If a new PLMN which is not in the list of equivalent PLMNs or a new SNPN has been entered, the initial registration procedure fails, the registration attempt counter is equal to 5 and no REGISTRATION REJECT message was received from the new PLMN or SNPN, the UE shall apply the default value of timer T3502 in all tracking areas of the registration area assigned to the UE until a new value is received.

Example from TDoc C1-232404: "a new PLMN which is not in the list of equivalent PLMNs or a new SNPN has been entered, the initial registration procedure fails, the registration attempt counter is equal to 5 and no REGISTRATION REJECT message was received from the new PLMN or SNPN."

3. Network Indicates Timer Deactivation:
TDoc C1-232404: If the network indicates that timer T3502 is "deactivated", the UE uses the default value of this timer.
TDoc C1-232405: If the network indicates that timer T3502 is "deactivated", the UE shall apply the default value of this timer in all tracking areas of the registration area assigned to the UE until a new value is received.

Example from TDoc C1-232404: "the network indicates that the timer is 'deactivated'."

4. Registration Accept Message Received:
TDoc C1-232404: If the UE receives a REGISTRATION ACCEPT message without a value specified, the UE uses the default value of timer T3502.
TDoc C1-232405: If the UE receives a REGISTRATION ACCEPT message without a value specified, the UE shall apply the default value of timer T3502 in all tracking areas of the registration area assigned to the UE until a new value is received.

Example from TDoc C1-232404: "REGISTRATION ACCEPT message is received without a value specified."

5. UE Does Not Have a Stored Value for Timer:
TDoc C1-232404: If the UE does not have a stored value for timer T3502, the UE uses the default value.
TDoc C1-232405: If the UE does not have a stored value for timer T3502, the UE shall apply the default value of timer T3502 in all tracking areas of the registration area assigned to the UE until a new value is received.

Example from TDoc C1-232404: "the UE does not have a stored value for this timer."

3GPP-C1-141-e    Agenda Item 18.2.2.2. : 5GProtoc18-non3GPP

TDoc C1-232017:

- MUSIM UE is capable of initiating and maintaining simultaneous separate registration states over 3GPP access with PLMN(s) using identities and credentials associated with those USIMs.
- Supports one or more of the N1 NAS signalling connection release, the paging indication for voice services, the reject paging request, the paging restriction, and the paging timing collision control.
- Onboarding SUPI can have the SUPI format "network specific identifier" containing a network specific identifier or the SUPI format "IMSI" containing an IMSI.
- The creation of the access stratum connection for trusted non-3GPP access used by the UE corresponds to the UE reception of an EAP-request/5G-start via NWt reference point.
- S-NSSAI applicable in the HPLMN without any further mapping by the network.

Example snippet from original TDoc: "MUSIM UE with multiple valid USIMs is capable of initiating and maintaining simultaneous separate registration states over 3GPP access with PLMN(s) using identities and credentials associated with those USIMs."

TDoc C1-232157:

- UE shall select a route selection descriptor with the next smallest precedence value which has not yet been evaluated.
- If the selected route selection descriptor contains a non-seamless non-3GPP offload indication and information on the non-3GPP access outside of a PDU session is available, it shall be provided to the upper layers.
- If the UE accepts URSP rules signalled by a non-subscribed SNPN that the UE accesses using credentials from a credential holder, the non-subscribed SNPN(s) signalled URSP shall be stored per non-subscribed SNPN and associated with the selected entry of the "list of subscriber data" or the selected PLMN subscription.
- If the PDU session establishment is successful, the UE NAS layer shall provide information (e.g. PDU address) of the successfully established PDU session to the upper layers.

Example snippet from original TDoc: "If the selected route selection descriptor contains a non-seamless non-3GPP offload indication and information on the non-3GPP access outside of a PDU session is available, it shall be provided to the upper layers."

TDoc C1-232066 and TDoc C1-232137 both discuss the technical differences among different PLMN Lists used by WLANs. The following bullet points summarize the differences:

- TDocs C1-232066 and C1-232137 both state that the format of the PLMN List with S2a information element is identical to the format of the PLMN List defined in H.2.4.2. This suggests that these two PLMN Lists are essentially the same.

- Both TDocs also mention the PLMN List with trusted 5G connectivity information element, which is used by WLANs to indicate the PLMNs for which they provide connectivity to a 5GCN using trusted non-3GPP access. The format of the PLMN List with trusted 5G connectivity-without-NAS information element is identical to the format of the PLMN List defined in H.2.4.2. The PLMN List with trusted 5G IE is different from the S2a PLMN List in that it specifically indicates connectivity to a 5GCN using non-3GPP access.

- TDoc C1-232066 also mentions the PLMN List with AAA connectivity to 5GC information element, which is identical in format to the PLMN List defined in H.2.4.2. This PLMN List indicates connectivity to a 5GCN using AAA (authentication, authorization, and accounting) functionality.

- Overall, the technical differences among these PLMN Lists seem to be related to the type of connectivity they indicate (S2a, trusted non-3GPP access to a 5GCN, or AAA-based connectivity), rather than differences in format.

Example snippets from TDoc C1-232066 that support these differences include:

- "The format of the PLMN List with S2a information element is identical to the format of the PLMN List defined in H.2.4.2."
- "The PLMN List with trusted 5G connectivity information element is used by the WLAN to indicate the PLMNs for which the WLAN provides connectivity to a 5GCN, using trusted non-3GPP access."
- "The format of the PLMN List with AAA connectivity to 5GC information element is identical to the format of the PLMN List information element defined in H.2.4.2."

3GPP-C1-141-e    Agenda Item 18.2.3 : NBI18

The first TDoc (C1-232463) contains:

- An ACServiceKPIs object with various properties such as connection bandwidth, requested rate, response time, availability, compute resources, schedule, geographical service area, and supported service contexts.
- An EasDetail object used to provide information about EAS (Emergency Alert System) details.
- A simInactTime property used to specify the duration of time that the AC remains inactive.
- An eass property which is an array of EAS information with a minimum of one item.
- An eecSvcContSupp property which is an array of ACRScenario objects used to specify the supported service contexts for the AC.

Example snippet: "acSvcContSupp: type: array items: $ref: 'TS29558_Eecs_EESRegistration.yaml#/components/schemas/ACRScenario' description:"

The second TDoc (C1-232467) contains:

- An object with various properties such as connection bandwidth, requested rate, response time, availability, compute resources, endpoints, and unfulfilled AC profiles.
- An ACProfile object used to provide ECS (Enhanced Charging Service) provisioning response information.
- A simInactTime property used to specify the duration of time that the AC remains inactive.
- An eass property which is an array of EAS information with a minimum of one item.
- An eecSvcContSupp property which is an array of ACRScenario objects used to specify the supported service contexts for the EEC (Enhanced Enterprise Communication) service.
- A reason property used to specify the reason why an AC profile is unfulfilled.

Example snippet: "unfulfilledAcProfs: $ref: '#/components/schemas/UnfulfilledAcProfile'"

3GPP-C1-141-e    Agenda Item 18.2.4 : SENSE

- TDoc C1-232336: Signal level enhanced network selection applies only to NB-IoT, GERAN EC-GSM-IoT and Category M1 or M2 of E-UTRA.
Example snippet: "Signal level enhanced network selection applies only to NB-IoT, GERAN EC-GSM-IoT and Category M1 or M2 of E-UTRA."

- TDoc C1-232339: Same as TDoc C1-232336.

- TDoc C1-232454: MS can be configured with an "Operator controlled signal threshold per access technology" stored in the USIM.
Example snippet: "The MS can be configured with an "Operator controlled signal threshold per access technology" stored in the USIM."

- TDoc C1-232336 and TDoc C1-232339 specify that the MS must be in automatic PLMN selection mode for signal level enhanced network selection to apply.
Example snippet: "The MS is in automatic PLMN selection mode."

- TDoc C1-232336 and TDoc C1-232339 specify that the MS must support the "Operator controlled signal threshold per access technology" functionality as specified in 3GPP TS 22.011.
Example snippet: "The MS supports the "Operator controlled signal threshold per access technology" as specified in 3GPP TS 22.011."

- TDoc C1-232454 specifies that the "Operator controlled signal threshold per access technology" must be configured in the USIM.
Example snippet: "The "Operator controlled signal threshold per access technology" is configured in the USIM."

- All three TDocs specify that the usage of the "Operator controlled signal threshold per access technology" is intended only for IoT stationary devices.
Example snippet: "The usage of the "Operator controlled signal threshold per access technology" is intended only for IoT stationary devices (see 3GPP TS 22.011)."

First Higher Priority PLMN search is disabled.

- TDoc C1-232034 specifies that if no value for T (timer) is stored in the SIM, a default value of 72 hours is used. It also mentions that if the MS is not using EC-GSM-IoT, Category M1, or Category NB1 at the time of starting timer T, the MS can attempt to select a PLMN/access technology combination that is higher priority than the current serving PLMN and belongs to the same country as the current serving PLMN, when timer TD, TE, TF, TG or TH expires. This is defined in Annex B. Periodic attempts may be postponed while the MS is receiving eMBMS transport service in idle mode. Example: "If no value for T is stored in the SIM, a default value of 72 hours is used."

- TDoc C1-232035 mentions that if the MS is in a VPLMN not registered for disaster roaming services, it shall periodically attempt to obtain service on its HPLMN or one of its EHPLMNs or a higher priority PLMN/access technology combination listed in "user controlled PLMN selector" or "operator controlled PLMN selector" by scanning in accordance with the requirements applicable to i), ii), and iii) as defined in the Automatic Network Selection Mode. If no value for T is stored in the SIM, a default value of 60 minutes is used for T. For an MS that only supports EC-GSM-IoT, Category M1, or Category NB1, Fast First Higher Priority PLMN search is disabled. Example: "If the MS is in a VPLMN not registered for disaster roaming services, the MS shall periodically attempt to obtain service on its HPLMN or one of its EHPLMNs or a higher priority PLMN/access technology combination listed in "user controlled PLMN selector" or "operator controlled PLMN selector" by scanning in accordance with the requirements applicable to i), ii), and iii) as defined in the Automatic Network Selection Mode."

3GPP-C1-141-e    Agenda Item 18.2.6. : SUECR

3GPP-C1-141-e    Agenda Item 18.2.7 : 5WWC_Ph2

TDoc C1-232067:
- UE selects HPLMN and checks preference parameter in HPLMN's N3AN node selection information entry for ePDG preference
- If home ePDG identifier configuration is provisioned in N3AN node configuration information:
- UE uses IP address of home ePDG identifier configuration as ePDG IP address if available
- UE uses FQDN of home ePDG identifier configuration as ePDG FQDN if IP address is not available
- If home ePDG identifier configuration is not provisioned in N3AN node configuration information:
- UE constructs ePDG FQDN based on FQDN format of HPLMN's N3AN node selection information entry using PLMN ID of HPLMN stored on USIM

TDoc C1-232163:
- UE follows procedure in clause 7.2.5 bullet a) if in home country of selected entry in "list of subscriber data" and entry is valid
- If SSID is included in received TNAN information IE:
- UE connects to TNAN based on received SSID
- If TNGF ID is included in received TNAN information IE:
- UE constructs NAI taking received TNGF ID into account as specified in 3GPP TS 23.003

TDoc C1-232499:
- FQDN format (operator identifier or tracking area identity based) determined from FQDN format of HPLMN's N3AN node selection information entry
- If extended home N3IWF identifier configuration or Slice-specific N3IWF prefix configuration is not provisioned in N3AN node configuration information:
- If home N3IWF identifier configuration is provisioned in N3AN node configuration information and contains IP address:
- UE uses IP address of home N3IWF identifier configuration as N3IWF IP address
- If home N3IWF identifier configuration is not provisioned in N3AN node configuration information:
- UE constructs N3IWF FQDN based on FQDN format of HPLMN's N3AN node selection information entry using PLMN ID of HPLMN stored on USIM

Examples from TDoc C1-232067:
- "if the preference parameter in the HPLMN's N3AN node selection information entry of the N3AN node selection information indicates that ePDG is preferred"
- "if the home ePDG identifier configuration is provisioned in the N3AN node configuration information and contains an IP address, the UE shall use the IP address of the home ePDG identifier configuration as the IP address of the ePDG"
- "if the home ePDG identifier configuration is not provisioned in the N3AN node configuration information, the UE shall construct an ePDG FQDN based on the FQDN format of HPLMN's N3AN node selection information entry in the N3AN node selection information using the PLMN ID of the HPLMN stored on the USIM"

Examples from TDoc C1-232163:
- "If the UE is in the home country of the selected entry in "list of subscriber data" and the entry is considered as valid"
- "if the SSID is included in the received TNAN information IE, the UE connect to a TNAN based on the received SSID"
- "if the TNGF ID is included in the received TNAN information IE, the UE construct a NAI taking the received TNGF ID into account as specified in clause xxy of 3GPP TS 23.003"

Examples from TDoc C1-232499:
- "FQDN format (operator identifier or tracking area identity based) is determined from the FQDN format of the HPLMN's N3AN node selection information entry in the N3AN node selection information"
- "if the home N3IWF identifier configuration is provisioned in the N3AN node configuration information and contains an IP address, the UE shall use the IP address of the home N3IWF identifier configuration as the IP address of the N3IWF"
- "if the home N3IWF identifier configuration is not provisioned in the N3AN node configuration information, the UE shall construct an N3IWF FQDN based on the FQDN format of the HPLMN's N3AN node selection information entry in the N3AN node selection information using the PLMN ID of the HPLMN stored on the USIM as specified in 3GPP TS 23.003"

3GPP-C1-141-e    Agenda Item 18.2.8 : TEI18_SDNAEPC

3GPP-C1-141-e    Agenda Item 18.2.11. : TRS_URLLC (CT3)

Technical differences among the TDocs:

1. Condition for UE to go back to 5GMM-CONNECTED mode: TDoc C1-232131 specifies three conditions for the UE(s) in 5GMM-IDLE mode or 5GMM-CONNECTED mode with RRC inactive indication to go back to 5GMM-CONNECTED mode.

- Example snippet: "There are 3 conditions for the UE(s) in 5GMM-IDLE mode or 5GMM-CONNECTED mode with RRC inactive indication to go back to 5GMM-CONNECTED mode"

2. Access attempt mapping to access categories: TDoc C1-232131 lists all the rules of access attempt mapping to access categories, and for the UE NAS initiated 5GMM connection management procedure, only the access attempt for MO data is defined.

- Example snippet: "Table 4.5.2.2 lists all the rules of access attempt mapping to access categories, for the UE NAS initiated 5GMM connection management procedure, only the access attempt for MO data is defined."

3. Triggering service request procedure for clock quality information: TDoc C1-232132 specifies different scenarios for triggering the service request procedure for the UE(s) in 5GMM-IDLE mode and 5GMM-CONNECTED mode with RRC inactive indication to retrieve the latest available clock quality information.

- Example snippet: "For the UE(s) in 5GMM-IDLE mode to transition to 5GMM-CONNECTED mode to retrieve the latest available clock quality information, the service request procedure is triggered, hence the Access Category 3 (MO_sig) is used for the access attempt for the UE(s) in 5GMM-IDLE mode to transition to 5GMM-CONNECTED mode; For the UE(s) in 5GMM-CONNECTED mode with RRC inactive indication to retrieve the latest available clock quality information, CT1 considers that it is more efficient for the UE(s) to specify in RRC the access category and access identity for this case to trigger the UAC in RRC directly."

4. UAC barring check: TDoc C1-232132 specifies performing UAC barring check with the Access Category "MO signalling" in NAS for the UE(s) in 5GMM-IDLE mode to transition to 5GMM-CONNECTED mode and retrieve the latest available clock quality information via RRC signaling.

- Example snippet: "Hence, for the UE(s) in 5GMM-IDLE mode to transition to 5GMM-CONNECTED mode to retrieve the latest available clock quality information via RRC signaling, the service request procedure is triggered as specified in 24.501 subclause 5.6.1.1 bullet q) which includes performing UAC barring check with the Access Category "MO signalling" in NAS."

Overall, the TDocs provide specific technical details on different aspects of the 5GMM connection management procedure, including conditions for transitioning from 5GMM-IDLE to 5GMM-CONNECTED mode, access attempt mapping to access categories, triggering the service request procedure, and UAC barring check.

TDoc C1-232133:
- UE uses MPS indicator bit of 5GS network feature support IE to determine validity of access identity 1 when in HPLMN or EHPLMN and USIM file EFUAC_AIC does not indicate configuration for access identity 1
- UE uses MCS indicator bit of 5GS network feature support IE to determine validity of access identity 2 when in HPLMN or EHPLMN and USIM file EFUAC_AIC does not indicate configuration for access identity 2
- USIM file EFUAC_AIC is not applicable when UE is not in HPLMN or EHPLMN

TDoc C1-232134:
- If UE is not in NB-N1 mode and has set RACS bit to "RACS supported" in 5GMM Capability IE of REGISTRATION REQUEST message:
- If REGISTRATION ACCEPT message includes UE radio capability ID deletion indication IE set to "Network-assigned UE radio capability IDs deletion requested", UE shall delete any network-assigned UE radio capability IDs associated with RPLMN or RSNPN and, if UE supports access to an SNPN using credentials from a credentials holder, equivalent SNPNs or both, selected entry of "list of subscriber data" or selected PLMN subscription stored at the UE, then initiate registration procedure for mobility and periodic registration update as specified in subclause 5.5.1.3.2 over existing N1 NAS signalling connection
- If REGISTRATION ACCEPT message includes UE radio capability ID IE, UE shall store UE radio capability ID as specified in annex C

TDoc C1-232135:
- If UE is not in NB-N1 mode and has set RACS bit to "RACS supported" in 5GMM Capability IE of REGISTRATION REQUEST message:
- If REGISTRATION ACCEPT message includes UE radio capability ID deletion indication IE set to "Network-assigned UE radio capability IDs deletion requested", UE shall delete any network-assigned UE radio capability IDs associated with RPLMN or RSNPN and, if UE supports access to an SNPN using credentials from a credentials holder, equivalent SNPNs or both, selected entry of "list of subscriber data" or selected PLMN subscription stored at the UE, then initiate registration procedure for mobility and periodic registration update as specified in subclause 5.5.1.3.2 over existing N1 NAS signalling connection
- If REGISTRATION ACCEPT message includes UE radio capability ID IE, UE shall store UE radio capability ID as specified in annex C

Example snippets from TDoc C1-232133:
- "When the UE is in the country of its HPLMN or in an EHPLMN (if the EHPLMN list is present), and the USIM file EFUAC_AIC does not indicate the UE is configured for access identity 1, the UE uses the MPS indicator bit of the 5GS network feature support IE in the REGISTRATION ACCEPT message or of the Priority indicator IE in the CONFIGURATION UPDATE COMMAND message to determine if access identity 1 is valid."
- "When the UE is in the country of its HPLMN or in an EHPLMN (if the EHPLMN list is present), and the USIM file EFUAC_AIC does not indicate the UE is configured for access identity 2, the UE uses the MCS indicator bit of the 5GS network feature support IE in the REGISTRATION ACCEPT message to determine if access identity 2 is valid."
- "When the UE is not in the country of its HPLMN or in an EHPLMN (if the EHPLMN list is present), the contents of the USIM file EFUAC_AIC are not applicable."

Example snippets from TDoc C1-232134:
- "If the UE is not in NB-N1 mode, the UE has set the RACS bit to "RACS supported" in the 5GMM Capability IE of the REGISTRATION REQUEST message and the REGISTRATION ACCEPT message includes: a) a UE radio capability ID deletion indication IE set to "Network-assigned UE radio capability IDs deletion requested", the UE shall delete any network-assigned UE radio capability IDs associated with the RPLMN or RSNPN and, if the UE supports access to an SNPN using credentials from a credentials holder, equivalent SNPNs or both, the selected entry of the "list of subscriber data" or the selected PLMN subscription stored at the UE, then the UE shall, after the completion of the ongoing registration procedure, initiate a registration procedure for mobility and periodic registration update as specified in subclause 5.5.1.3.2 over the existing N1 NAS signalling connection; or b) a UE radio capability ID IE, the UE shall store the UE radio capability ID as specified in annex C."
- "5.5.1.3.4 in the initial registration procedure is FFS."

Example snippets from TDoc C1-232135:
- "If the UE is not in NB-N1 mode, the UE has set the RACS bit to "RACS supported" in the 5GMM Capability IE of the REGISTRATION REQUEST message and the REGISTRATION ACCEPT message includes: a) a UE radio capability ID deletion indication IE set to "Network-assigned UE radio capability IDs deletion requested", the UE shall delete any network-assigned UE radio capability IDs associated with the RPLMN or RSNPN and, if the UE supports access to an SNPN using credentials from a credentials holder, equivalent SNPNs or both, the selected entry of the "list of subscriber data" or the selected PLMN subscription stored at the UE, then the UE shall, after the completion of the ongoing registration procedure, initiate a registration procedure for mobility and periodic registration update as specified in subclause 5.5.1.3.2 over the existing N1 NAS signalling connection; or b) a UE radio capability ID IE, the UE shall store the UE radio capability ID as specified in annex C."
- "5.5.1.3.4 in the initial registration procedure is FFS."

3GPP-C1-141-e    Agenda Item 18.2.12. : DetNet (CT3)

3GPP-C1-141-e    Agenda Item 18.2.13. : eUEPO (CT3)

[TDoc C1-232022]:

- If a PDN connection is configured with a certain APN, services provided through that connection should work without protocol configuration options in the PDN CONNECTIVITY REQUEST message.
- If the UE supports URSP provisioning in EPS and the PDN CONNECTIVITY REQUEST message is for the default APN or for an APN where URSP provisioning is supported, the UE performs procedures for URSP provisioning in EPS.
- If the UE supports URSP provisioning in EPS, the PDN connection being established is for an IP PDN type, and the UE is in WB-S1 mode, the UE does not include the UE policy container in ePCO IE of PDN CONNECTIVITY REQUEST message.

[TDoc C1-232061] and [TDoc C1-232063]:

- If the 5G-RG or W-AGF finds a traffic descriptor in a non-default URSP rule matching the application information and there is one or more PDU sessions, the 5G-RG associates the application to a PDU session accordingly.
- If no non-default matching URSP rule can be found, and local configuration of the 5G-RG for the application is available, the 5G-RG shall perform the association of the application to a PDU session accordingly.
- The URSP can only be used if the SUPI from the USIM matches the SUPI stored in the non-volatile memory of the ME.

[TDoc C1-232161]:

- If the UE operating in single-registration mode performs an inter-system change from S1 mode to N1 mode and has one or more stored UE policy sections identified by a UPSI with the PLMN ID part indicating the HPLMN or the selected PLMN, the UE shall set the Payload container type IE to "UE policy container" and include the UE STATE INDICATION message in the Payload container IE of the REGISTRATION REQUEST message.
- If the UE has neither allowed NSSAI nor configured NSSAI for the current PLMN or SNPN and has a default configured NSSAI, the UE shall include the S-NSSAI(s) in the Requested NSSAI IE of the REGISTRATION REQUEST message using the default configured NSSAI, and include the Network slicing indication IE with the Default configured NSSAI indication bit set to "Requested NSSAI created from default configured NSSAI" in the REGISTRATION REQUEST message.
- For case zi), the UE shall not include the Paging restriction IE in the REGISTRATION REQUEST message.

[TDoc C1-232022] highlights the requirement for services to work without protocol configuration options and the procedures for URSP provisioning in EPS, while also noting the exclusion of the UE policy container in ePCO IE of PDN CONNECTIVITY REQUEST message under certain conditions. [TDoc C1-232061] and [TDoc C1-232063] emphasize the association of non-default URSP rules to PDU sessions and the requirement for matching SUPIs. Finally, [TDoc C1-232161] outlines the inclusion of UE STATE INDICATION message and NSSAI-related IEs in the REGISTRATION REQUEST message.

TDoc C1-232018:
- UE can access SNPN using credentials from a credentials holder, equivalent SNPNs, or both.
- 5GMM parameters should be stored in non-volatile memory in the ME per subscribed SNPN or PLMN subscription.
- Subscriber identifier can be configured in the entry of the "list of subscriber data" associated with the SNPN identity, or with the SUPI from the USIM if no subscriber identifier is configured.
- Reference to 3GPP TS 23.122 [5].

TDoc C1-232194:
- UE-initiated UE state indication procedure delivers UPSI(s) of UE policy section(s).
- UPSI identified by PLMN ID part indicating HPLMN, selected PLMN, or SNPN identity with associated NID.
- UE indicates support for ANDSP and URSP provisioning in EPS.
- UE delivers one or more OS IDs to the PCF.
- UE provides PCF with a list of stored UE policy section identifiers (UPSIs).
- Reference to UE policy classmark information element.

TDoc C1-232584:
- No significant difference from TDoc C1-232194, except for the addition of UE policy classmark information element.

TDoc C1-232622:
- UE-initiated UE state indication procedure delivers UPSI(s) of UE policy section(s).
- UPSI identified by PLMN ID part indicating HPLMN, selected PLMN, or SNPN identity with associated NID.
- UE indicates support for ANDSP and URSP provisioning in EPS.
- UE delivers one or more OS IDs to the PCF.
- UE provides PCF with a list of stored UE policy section identifiers (UPSIs).
- Reference to UE policy classmark information element.

Examples from TDoc C1-232018:
- "if the UE has a valid USIM"
- "configured in the ME"
- "if the UE supports access to an SNPN using credentials from a credentials holder, equivalent SNPNs, or both"
- "PLMN subscription together with the SUPI from the USIM which is associated with the PLMN subscription"

Examples from TDoc C1-232194:
- "identified by a UPSI with the PLMN ID part indicating the HPLMN or the selected PLMN"
- "identified by a UPSI with the PLMN ID part indicating the PLMN ID part of the SNPN identity of the selected SNPN and associated with the NID of the selected SNPN"
- "deliver the UE's one or more OS IDs"
- "UE policy classmark information element"
- "using one or more UE policy sections"

Examples from TDoc C1-232584:
- "identified by a UPSI with the PLMN ID part indicating the HPLMN or the selected PLMN"
- "identified by a UPSI with the PLMN ID part indicating the PLMN ID part of the SNPN identity of the selected SNPN and associated with the NID of the selected SNPN"
- "deliver the UE's one or more OS IDs"
- "UE policy classmark information element"
- "using one or more UE policy sections"

Examples from TDoc C1-232622:
- "identified by a UPSI with the PLMN ID part indicating the HPLMN or the selected PLMN"
- "identified by a UPSI with the PLMN ID part indicating the PLMN ID part of the SNPN identity of the selected SNPN and associated with the NID of the selected SNPN"
- "deliver the UE's one or more OS IDs"
- "UE policy classmark information element"
- "using one or more UE policy sections"

3GPP-C1-141-e    Agenda Item 18.2.14. : UASAPP_Ph2

3GPP-C1-141-e    Agenda Item 18.2.17 : SEAL_Ph3

3GPP-C1-141-e    Agenda Item 18.2.19. : 5G_eLCS_Ph3 (CT4)

Technical Differences Among TDocs:

1. TDoc C1-232154: This document specifies the transport protocol for location service messages over the user plane. It includes abbreviations for different terms used in the document, such as FQDN, LCS, LMF, and LPP.

2. TDoc C1-232224: This document discusses the UL NAS TRANSPORT message, which can only be sent in connected mode. The established user plane connection between UE and LMF is maintained, and the AMF stores the user plane connection context as part of UE context.

3. TDoc C1-232225: This document specifies the handling of DL NAS TRANSPORT message in different scenarios, based on the payload container type IE. The UE forwards the content of the Payload container IE to the SMS stack entity, upper layer location services application, or UDM based on the payload container type.

4. TDoc C1-232226: This document specifies the actions to be taken by the UE upon receiving a message that has been successfully integrity checked by the NAS. It also specifies the handling of EMM parameters and entering the state of 5GMM-DEREGISTERED for non-3GPP access.

5. TDoc C1-232300: This document specifies the handling of unknown, unforeseen, and erroneous protocol data. It proposes to reduce the TS to a specification of one protocol that can separate transported protocols by specifying its procedures, messages, and/or information elements.

6. TDoc C1-232301: This document specifies the user plane protocol to support location services in the 5G system. It defines the message format, message contents, error handling, and system parameters applied by the protocols for the user plane protocol for supporting LCS in 5GS.

7. TDoc C1-232302: This document proposes the addition of a dedicated clause for security under the LS-UPP general clause to cover the security aspects of LS-UPP. It also proposes to add editor's notes for the scope of the security clause.

8. TDoc C1-232303: This document proposes the addition of a dedicated clause for PDU session establishment under the LS-UPP general clause.

9. TDoc C1-232304: This document proposes the addition of dedicated clauses for UE-initiated transport procedure and LMF-initiated procedure under the LS-UPP procedures clause.

10. TDoc C1-232305: This document proposes the addition of a general timer description and timer tables for LS-UPP under the list of system parameters.

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

- TDoc C1-232154: Abbreviations given in 3GPP TR 21.905
- TDoc C1-232224: "The UL NAS TRANSPORT message can only be sent in the connected mode."
- TDoc C1-232225: "The UE shall forward the content of the Payload container IE to the SMS stack entity."
- TDoc C1-232226: "The UE shall handle the EMM parameters EMM state, EPS update status, 4G-GUTI, last visited registered TAI, TAI list and eKSI."
- TDoc C1-232300: "It is proposed to reduce the TS to the specification of one protocol."
- TDoc C1-232301: "The present document specifies the user plane protocol to support the Location Services (LCS) in the 5G System (5GS)."
- TDoc C1-232302: "The security aspects of LS-UPP are not covered in the 24.572 structure."
- TDoc C1-232303: "The establishment of a PDU session is a pre-requisite for use of LS-UPP."
- TDoc C1-232304: "To transport LPP messages and Location services messages between UE and LMF via user plane using LS-UPP."
- TDoc C1-232305: "The timers of a protocol are captured under system parameters and specific tables for each side/entity of the protocol."

[TDoc C1-232228]:
- If UE performs an inter-system change from S1 mode to N1 mode and has stored UE policy sections with HPLMN or selected PLMN, set Payload container type IE to "UE policy container" and include UE STATE INDICATION message in Payload container IE of REGISTRATION REQUEST message
- If UE has default configured NSSAI and no allowed/configured NSSAI for current PLMN/SNPN, include S-NSSAI(s) in Requested NSSAI IE using default configured NSSAI and include Network slicing indication IE with Default configured NSSAI indication bit set to "Requested NSSAI created from default configured NSSAI"
- For case zi), do not include Paging restriction IE in REGISTRATION REQUEST message

[TDoc C1-232397]:
- Same as TDoc C1-232228

[TDoc C1-232398]:
- Adds 5GC NF (e.g., NWDAF) in scope of user plane positioning protocol in 3GPP TS 24.572 v0.1.0 for supporting LCS in 5GS
- Defines message format, contents, error handling, and system parameters for User plane protocol
- Reason for change: Addition of a particular type of LCS consumer in Rel-18

[TDoc C1-232510]:
- For case g) in subclause 5.4.5.2.1, set Payload container type IE to "Location services message container", Payload container IE to Location services message payload, and Additional information IE to routing information if provided by upper layer location services application
- For case c) in subclause 5.4.5.2.1, set Payload container type IE to "LTE Positioning Protocol (LPP) message container", Payload container IE to LPP message payload, and Additional information IE to routing information provided by upper layer location services application
- For case f) in subclause 5.4.5.2.1, set Payload container type IE to "UE parameters update transparent container" and set contents of Payload container IE to UE acknowledgement due to successful reception of UE parameters update data

Examples from TDoc C1-232228:
- "If the UE has neither allowed NSSAI for the current PLMN or SNPN nor configured NSSAI for the current PLMN or SNPN and has a default configured NSSAI"
- "the UE shall include the S-NSSAI(s) in the Requested NSSAI IE of the REGISTRATION REQUEST message using the default configured NSSAI"
- "include the Network slicing indication IE with the Default configured NSSAI indication bit set to 'Requested NSSAI created from default configured NSSAI'"
- "For case zi), the UE shall not include the Paging restriction IE in the REGISTRATION REQUEST message"

Examples from TDoc C1-232398:
- "adds 5GC NF (e.g., NWDAF) in the scope of the user plane positioning protocol in 3GPP TS 24.572 v0.1.0."
- "defines the message format, message contents, error handling and system parameters applied by the protocols for the User plane protocol for supporting LCS in 5GS."

Examples from TDoc C1-232510:
- "set the Payload container type IE to 'Location services message container';"
- "set the Payload container IE to the Location services message payload;"
- "set the Additional information IE to the routing information, if provided by the upper layer location services application."

Technical Differences and Example Snippets:

1. TDoc C1-232247 includes a heading indicating the first set of changes, while TDoc C1-232256 has the first set of changes listed after the meeting information.

Example from TDoc C1-232247: "***************1st changes***************"

2. TDoc C1-232247 has a heading for the end of changes, while TDoc C1-232256 does not have a specific heading for this.

Example from TDoc C1-232247: "***************End of changes***************"

3. TDoc C1-232247 and TDoc C1-232256 have different document numbers and meeting dates.

Example from TDoc C1-232247: "3GPP TSG-CT WG1 Meeting #141e C1-232247 Online 17– 21 April 2023"

Example from TDoc C1-232256: "3GPP TSG-CT WG1 Meeting #141e C1-232256 Online 17– 21 April 2023"

4. TDoc C1-232247 and TDoc C1-232256 both include multiple sets of changes, indicating that they are likely revisions of the same document.

Example from both TDocs: "***************2nd changes***************"

Example from both TDocs: "***************3rd changes***************"

Overall, the main technical differences among TDoc C1-232247 and TDoc C1-232256 are related to headings and document details. TDoc C1-232247 includes headings for the first set of changes and end of changes, while TDoc C1-232256 does not. Additionally, the document numbers and meeting dates are different. However, both TDocs include multiple sets of changes, suggesting that they are revisions of the same document.

Technical Differences among TDocs:

1. TDoc C1-232544:
- Includes 14 different parameters for NG-RAN LCS, including molr-Type, lcs-QoS, lcsServiceTypeID, ageOfLocationInformation, locationType, mlc-Number, lcsClientExternalID, pseudonymIndicator, supportedGADShapes, multiplePositioningProtocolPDUs, locationEstimate, h-gmlc-address, decipheringKeys, and scheduledLocTime.
- MultiplePositioningProtocolPDUs IE is added to the MO-LR Request to allow for passing multiple UE positioning information LPP messages to the LMF for NG-RAN LCS.

2. TDoc C1-232587:
- Routing information associated with the LMF is transported as the Additional information IE in UL/DL NAS TRANSPORT message or CONTROL PLANE SERVICE REQUEST message for Location services messages that are transported between the UE and the LMF.
- Both downlink and uplink LPP messages are supported.
- Immediate routing identifier transported as the Additional Information IE is the Correlation ID, which is allocated by the AMF and can be used in the UL/DL NAS TRANSPORT message.

3. TDoc C1-232588:
- Provides content of General for TS 24.572 2.
- References are either specific or non-specific, with subsequent revisions not applying for specific references.
- Latest version applies for non-specific references.

4. TDoc C1-232635:
- Includes 14 different parameters for NG-RAN LCS, including molr-Type, lcs-QoS, lcsServiceTypeID, ageOfLocationInformation, locationType, mlc-Number, lcsClientExternalID, pseudonymIndicator, supportedGADShapes, multiplePositioningProtocolPDUs, locationEstimate, h-gmlc-address, decipheringKeys, and scheduledLocTime.
- MultiplePositioningProtocolPDUs IE is added to the MO-LR Request to allow for passing multiple UE positioning information LPP messages to the LMF for NG-RAN LCS.

Examples from TDocs to support the difference highlighting:
- TDoc C1-232544 notes the addition of multiplePositioningProtocolPDUs IE for passing multiple UE positioning information LPP messages to the LMF for NG-RAN LCS.
- TDoc C1-232587 highlights the transport of routing information as the Additional information IE in UL/DL NAS TRANSPORT message or CONTROL PLANE SERVICE REQUEST message for Location services messages.
- TDoc C1-232588 provides content of General for TS 24.572 2 and emphasizes the latest version applying for non-specific references.
- TDoc C1-232635 notes the addition of multiplePositioningProtocolPDUs IE for passing multiple UE positioning information LPP messages to the LMF for NG-RAN LCS.

3GPP-C1-141-e    Agenda Item 18.2.20. : EDGEAPP_Ph2

[TDoc C1-232042]:

- The TDoc includes the following elements: expTime, eecSvcContSupp, connInfo, notificationDestination, and requestTestNotification.
- The eecSvcContSupp element indicates if the EEC supports service continuity or not, and which ACR scenarios are supported by the EEC.
- The connInfo element is a list of connectivity information for the UE.
- The notificationDestination element is a URI reference to the destination for notifications.
- The requestTestNotification element is a boolean that, when true, requests the ECS to send a test notification.
- The TDoc references external YAML files for certain elements, such as TS29122_CommonData.yaml and TS29558_Eecs_EESRegistration.yaml.

Example snippet from the TDoc:

```
eecSvcContSupp:
type: array
items: $ref: 'TS29558_Eecs_EESRegistration.yaml#/components/schemas/ACRScenario'
description: > Indicates if the EEC supports service continuity or not, also indicates which ACR scenarios are supported by the EEC.
```

[TDoc C1-232415]:

- The TDoc includes the following elements: requestBody, prefEcsps, reqGrapComp, and eecCntxId.
- The requestBody element contains parameters to replace the existing registration.
- The prefEcsps element is a list of ECSPs that are preferred for the AC.
- The reqGrapComp element specifies the graphical compute resources required by the AC.
- The eecCntxId element is an identifier of the EEC context obtained from a previous registration.
- The TDoc references external JSON schema files for certain elements, such as EECRegistration and EECRegistrationPatch.

Example snippet from the TDoc:

```
prefEcsps:
type: array
items: type: string
description: Indicates to the ECS which ECSPs are preferred for the AC.
```

- TDoc C1-232261 deals with the EAS discovery subscription request, while TDoc C1-232262 deals with service provisioning information request.
- TDoc C1-232261 involves the EES verifying whether the EEC is registered and authorized to subscribe to information of the requested EAS(s) from EES. If the EEC is not registered, and the ECSP policy requires the EEC to perform EEC registration prior to EAS discovery, the EES rejects the request message by sending an HTTP response to the EEC with a status code set to 403 Forbidden and may indicate the "REGISTRATION_REQUIRED" error in the "cause" attribute of the "ProblemDetails" structure. On the other hand, TDoc C1-232262 involves the ECS identifying the EES(s) based on the UE-specific service information at the ECS and the UE location or by applying the ECSP policy (e.g. based on the UE location) if AC profiles(s) are not provided.
- TDoc C1-232261 may obtain the UE's location as specified in clause 5.3 of 3GPP TS 29.122 while TDoc C1-232262 may also determine other information that needs to be provisioned, e.g. identification of the EDN, EDN service area, EES endpoints.
- TDoc C1-232261 may cache the EAS information (e.g. EAS endpoint) for subsequent use and avoid the need to repeat this procedure while TDoc C1-232262 may return an HTTP "200 OK" status code response with the response body including the ECSServProvResp data structure which may include the lifetime of the provided EDN configuration information. If the lifeTime attribute is included in the service provisioning response, then the EEC may cache and reuse the service provisioning information only for the duration specified by the lifeTime attribute.

Example snippets from the original TDoc:

- TDoc C1-232261: "b) if the EEC is not registered with the EES, and if ECSP policy requires the EEC to perform EEC registration prior to EAS discovery, the EES shall reject the request message by sending an HTTP response to the EEC with a status code set to 403 Forbidden and may indicate the "REGISTRATION_REQUIRED" error in the "cause" attribute of the "ProblemDetails" structure;"
- TDoc C1-232262: "ii. ECS identifies the EES(s) by applying the ECSP policy (e.g. based on the UE location); the ECS also determines other information that needs to be provisioned, e.g. identification of the EDN, EDN service area, EES endpoints; and d) if the ECS is able to determine service provisioning information using the inputs in service provisioning request, UE-specific service information at the ECS or the ECSP's policy, then the ECS returns an HTTP "200 OK" status code response with the response body including the ECSServProvResp data structure which may include the lifetime of the provided EDN configuration information."

[TDoc C1-232041]:
- Defines a "ServProvNotification" object that represents notification information of a service provisioning event.
- Includes a "dnais" property that represents a list of data network access identifiers.
- Requires the properties "eecId" and "supportedFeatures".
- References schemas from the TS29122_CommonData.yaml and TS29571_CommonData.yaml files.

[TDoc C1-232379]:
- Defines an "ACProfile" object that represents ECS service provisioning response information.
- Includes a "reqComp" property that represents the compute resources required by the AC.
- Requires the properties "eecId" and "unfulfilledAcProfs".
- References schemas from the TS29571_CommonData.yaml and TS29122_CommonData.yaml files, as well as the TS29558_Eees_EASRegistration.yaml file.

[TDoc C1-232382]:
- Defines a "ECSServProvResp" object that represents ECS service provisioning response information.
- Includes a "snssai" property that represents the slice-specific network slice selection assistance information.
- References schemas from the TS29571_CommonData.yaml and TS29122_CommonData.yaml files.

[TDoc C1-232610]:
- Defines a "ServProvNotification" object that represents notification information of a service provisioning event.
- Includes a "dnais" property that represents a list of data network access identifiers.
- References schemas from the TS29122_CommonData.yaml and TS29571_CommonData.yaml files.

Example snippets:
- TDoc C1-232041: The "dnais" property is defined as follows: "dnais: type: array items: $ref: 'TS29571_CommonData.yaml#/components/schemas/Dnai' description: Represents list of Data network access identifier."
- TDoc C1-232379: The "reqComp" property is defined as follows: "reqComp: type: string description: The compute resources required by the AC."
- TDoc C1-232382: The "snssai" property is defined as follows: "snssai: $ref: 'TS29571_CommonData.yaml#/components/schemas/Snssai'"
- TDoc C1-232610: The "dnais" property is defined as follows: "dnais: type: array items: $ref: 'TS29571_CommonData.yaml#/components/schemas/Dnai' description: Represents list of Data network access identifier."

TDoc C1-232380:

- The TDoc defines several properties and references for the Eees Application Context Relocation Service, including easId, tEasEndpoint, sEasEndpoint, prevTEasEndpoint, routeReq, simInactTime, easNotifInd, prevEasNotifInd, eecCtxtReloc, and AcrDecReq.
- The easId property is of type string.
- The tEasEndpoint, sEasEndpoint, and prevTEasEndpoint properties all reference the EndPoint schema from TS29558_Eees_EASRegistration.yaml.
- The routeReq property references the RouteToLocation schema from TS29571_CommonData.yaml.
- The simInactTime property references the DurationSec schema from TS29122_CommonData.yaml.
- The easNotifInd and prevEasNotifInd properties are both of type boolean and have a default value of false.
- The eecCtxtReloc property references the EecCtxtReloc schema within the same TDoc.
- The AcrDecReq property is an object that includes the properties ueId, acId, tEasId, and tEasEndpoint.
- The ueId property of AcrDecReq references the Gpsi schema from TS29571_CommonData.yaml.
- The acId and tEasId properties of AcrDecReq are both of type string.
- The tEasEndpoint property of AcrDecReq references the EndPoint schema from TS29558_Eees_EASRegistration.yaml.
- The requestorId, tEasEndpoint, and easNotifInd properties are all required.

TDoc C1-232611:

- The TDoc is nearly identical to C1-232380, with the same properties and references for the Eees Application Context Relocation Service.
- The only difference is the version number in the description, which is "1.1.0-alpha.1" instead of unspecified.
- This suggests that the two TDocs are likely different versions of the same specification.

3GPP-C1-141-e    Agenda Item 18.2.21 : UAS_Ph2

TDoc C1-232139:

- Defines terms and definitions for Global Cable Identifier (GCI), GUAMI, IMEI, IMEISV, IMSI, PEI, SUPI, SUCI, CAG selection, CAG-ID, country, EHPLMN, HPLMN, onboarding services, registered SNPN, selected PLMN, selected SNPN, shared network, SNPN identity, steering of roaming (SOR), SOR-CMCI, steering of roaming information, subscribed SNPN, suitable cell, VPLMN
- References 3GPP TS 23.122 [5] for the definitions

TDoc C1-232140:

- References various technical specifications such as IEEE Std 802.11™-2016, ITU-T Recommendation E.212, 3GPP TS 23.503, 3GPP TS 24.193, ISO 8601:2004, 3GPP TS 24.588
- These technical specifications cover topics such as policy and charging control framework, access traffic steering, switching and splitting, V2X services, and international identification plan for public networks and subscriptions

TDoc C1-232141:

- Specifies certain conditions for PDU session establishment and modification, such as support for Ethernet, non-IP PDN type, authorized QoS flow descriptions, and 3GPP PS data off UE status
- References the creation of the access stratum connection for wireline access used by the 5G-RG via the Y4 reference point

TDoc C1-232142:

- Specifies procedures for secondary DN authentication and authorization over EPC, including the SDNAEPC support indicator and DN-specific identity set to DN-specific identity of the UE complying with network access identifier (NAI) format as specified in IETF RFC 7542
- Describes how the UE stores session-AMBR and QoS rule(s) for use during inter-system change from S1 mode to N1 mode if received in the Protocol configuration options IE or the Extended protocol configuration options IE
- Specifies that the network shall disable C2 communication for the PDN connection if the pairing of UAV and UAV-C is revoked

TDoc C1-232199:

- Specifies procedures for establishing a PDU session for the C2 communication by providing the CAA-level UAV ID and the C2 authorization payload, including determination of authorization requirements based on the DNN and S-NSSAI combination of the PDU session and the CAA-level UAV ID included in the request
- Specifies that the network shall disable C2 communication for the PDU session if the pairing of UAV and UAV-C is revoked

TDoc C1-232200:

- Specifies conditions for PDU session establishment and modification, such as support for Ethernet, non-IP PDN type, and authorized QoS flow descriptions
- Specifies that the UE shall send a PDU SESSION MODIFICATION REQUEST message to delete the QoS flow description which lacks at least one of the mandatory parameters and the associated QoS rule(s), if any, with 5GSM cause #84 "syntactical error in the QoS operation" if the parameters list field of one or more authorized QoS flow descriptions received in the Authorized QoS flow descriptions IE of the PDU SESSION ESTABLISHMENT ACCEPT message contains an EPS bearer identity (EBI)

TDoc C1-232201:

- Specifies procedures for requesting DNS server addresses in the PDU SESSION MODIFICATION REQUEST message when in S1 mode, after an inter-system change from S1 mode to N1 mode, and if the UE is a UE operating in single-registration mode in a network supporting N26 interface and supports receiving DNS server addresses in protocol configuration options and has not previously successfully performed the UE-requested PDU session modification to indicate this support
- Specifies that the UE shall include the Service-level-AA container IE in the PDU SESSION MODIFICATION REQUEST message when requesting to modify an established PDU session for C2 communication

TDoc C1-232213:

- Proposes changes to 3GPP TS 24.577 to introduce a definition section for A2X communication, BRID, DAA, and Direct C2 communication according to the stage-2 requirements specified in TS 23.256

TDoc C1-232214:

- Proposes multiple changes to 3GPP TS 24.77

Technical differences among the listed TDocs are not clear based on the given information. The provided TDocs only contain changes and proposals for changes to existing specifications without providing any details on the technical differences from the original specification. Therefore, it is not possible to summarize technical differences among the listed TDocs using a bullet point list.

[TDoc C1-232211]:
- Provides a version numbering system for the document based on its approval status
- References other documents that are considered part of the present document
- Includes a section on procedures
- Defines terms, symbols, and abbreviations used in the document
- Contains a scope section

[TDoc C1-232212]:
- Provides a version numbering system for the document based on its approval status
- References other documents that are considered part of the present document
- Defines terms, symbols, and abbreviations used in the document
- Notes that the document is subject to change following formal TSG approval

[TDoc C1-232327]:
- Describes a specific scenario and the actions that the UE should take in that scenario
- Includes references to specific messages and information elements used in the procedure
- Notes that a specific subclause related to the procedure is FFS (For Further Study)

[TDoc C1-232332]:
- Describes a specific scenario and the actions that the UE should take in that scenario
- Includes references to specific messages and information elements used in the procedure
- Notes that the UE should not request to perform handover in certain cases

Example snippets:
- "2 References The following documents contain provisions which, through reference in this text, constitute provisions of the present document." (TDoc C1-232211, C1-232212)
- "3.1 Terms For the purposes of the present document, the terms given in 3GPP TR 21.905 [1] and the following apply." (TDoc C1-232211, C1-232212)
- "If the UE is not in NB-N1 mode, the UE has set the RACS bit to 'RACS supported' in the 5GMM Capability IE of the REGISTRATION REQUEST message and the REGISTRATION ACCEPT message includes..." (TDoc C1-232327)
- "For a PDN connection established when in S1 mode, after an inter-system change from S1 mode to N1 mode, and if the UE is a UE operating in single-registration mode in a network supporting N26 interface, and the UE supports receiving DNS server addresses in protocol configuration options and the UE has not previously successfully performed the UE-requested PDU session modification to indicate this support, the UE shall include the Extended protocol configuration options IE in the PDU SESSION MODIFICATION REQUEST message and..." (TDoc C1-232332)

Summary of Technical Differences among TDocs:

TDoc C1-232143:

- This document provides content for Provisioning of parameters for A2X configuration in 3GPP TS 24.577 related to the UAS_Ph2 work item.
- It defines abbreviations for the purposes of the present document, which take precedence over definitions in 3GPP TR 21.905.
- It includes provisions from reference documents.
- The reason for change is to define provisioning based on SA2 requirements.

TDoc C1-232144:

- This document provides content for A2X communication over PC5 and the A2X PC5 unicast link establishment procedure in 3GPP TS 24.577 related to the UAS_Ph2 work item.
- It defines abbreviations for the purposes of the present document, which take precedence over definitions in 3GPP TR 21.905.
- It includes provisions from reference documents.
- The reason for change is to define A2X communication based on SA2 requirements.

TDoc C1-232147:

- This document provides content for Broadcast mode A2X communication over PC5 in 3GPP TS 24.577 related to the UAS_Ph2 work item.
- It includes provisions from reference documents.
- The reason for change is to define broadcast mode A2X communication based on SA2 requirements.

TDoc C1-232198:

- This document specifies a general section for authorization of direct C2 communication in 3GPP TS 24.577 related to the UAS_Ph2 work item.
- The reason for change is to enable implementation of stage-2 requirements and procedures from TS 23.256 in stage-3 TS 24.577.
- It includes proposals for changes to 3GPP TS 24.577.

Example snippets from TDoc C1-232143 to support technical differences:

- Defines abbreviations for the purposes of the present document (3.3)
- Provides content for Provisioning of parameters for A2X configuration (5)
- Includes provisions from reference documents (2)
- Defines abbreviations that take precedence over definitions in 3GPP TR 21.905 (2)

Example snippets from TDoc C1-232144 to support technical differences:

- Provides content for A2X communication over PC5 and A2X PC5 unicast link establishment procedure (Introduction)
- Defines abbreviations for the purposes of the present document (3.3)
- Includes provisions from reference documents (2)
- Defines abbreviations that take precedence over definitions in 3GPP TR 21.905 (2)

Example snippets from TDoc C1-232147 to support technical differences:

- Provides content for Broadcast mode A2X communication over PC5 (Introduction)
- Includes provisions from reference documents (2)

Example snippets from TDoc C1-232198 to support technical differences:

- Specifies a general section for authorization of direct C2 communication (Introduction)
- Includes proposals for changes to 3GPP TS 24.577 (Conclusions)

3GPP-C1-141-e    Agenda Item 18.2.22. : VMR

3GPP-C1-141-e    Agenda Item 18.2.23 : Ranging_SL

- TDoc C1-232251: Specifies actions for a UE switching from S1 mode to N1 mode, including setting the Payload container type IE to "UE policy container" and including the UE STATE INDICATION message in the Payload container IE of the REGISTRATION REQUEST message.
- TDoc C1-232275: Specifies actions for a UE if it is not in NB-N1 mode, including deleting network-assigned UE radio capability IDs associated with the RPLMN or RSNPN and initiating a registration procedure for mobility and periodic registration update.
- TDoc C1-232276: Specifies actions for a UE in a non-allowed area, including setting the service type IE in the SERVICE REQUEST message to "elevated signalling" for a change of 3GPP PS data off UE status for a PDU session.
- TDoc C1-232576: Provides an overview of the solution for Ranging_SL and refers to 3GPP TS 24.571 for details of LCS signalling.
- TDoc C1-232251: Includes the S-NSSAI(s) in the Requested NSSAI IE of the REGISTRATION REQUEST message using the default configured NSSAI if the UE has neither allowed NSSAI for the current PLMN or SNPN nor configured NSSAI for the current PLMN or SNPN and has a default configured NSSAI.
- TDoc C1-232275: Stores the UE radio capability ID as specified in annex C. 5.5.1.3.4 in the initial registration procedure if a UE radio capability ID IE is included in the REGISTRATION ACCEPT message.
- TDoc C1-232276: Does not initiate service request procedure except for emergency services, high priority access or responding to paging or notification if the UE is in a non-allowed area or is not in an allowed area as specified in subclause 5.3.5.
- TDoc C1-232576: Will be re-released by the TSG with an identifying change of release date and an increase in version number if the contents of the present document are modified by the TSG.

Overall, the technical differences among the TDocs relate to specific actions and procedures for UEs in different situations, such as switching between modes or being in non-allowed areas, and the inclusion or exclusion of certain information in messages. The TDocs also provide an overview of the solution for Ranging_SL and specify procedures for handling unknown, unforeseen, and erroneous signalling protocol data, as well as providing a scope for the specification.

TDoc C1-232151:

- Protocol aspects of User Equipment (UE) to V2X control function are covered in 3GPP TS 24.386.
- Security aspects of 3GPP support for advanced Vehicle-to-Everything (V2X) services are addressed in 3GPP TS 33.536.
- UE procedures in Idle mode and RRC Inactive state are defined in 3GPP TS 38.304.
- Architecture enhancements for 5G System (5GS) to support Vehicle-to-Everything (V2X) services are provided in 3GPP TS 23.287.
- Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in idle mode are specified in 3GPP TS 23.122.
- Aircraft-to-Everything (A2X) services in 5G System (5GS) protocol aspects are outlined in 3GPP TS 24.577.
- A vocabulary for 3GPP Specifications is defined in 3GPP TR 21.905.

TDoc C1-232153:

- IEEE Std 802.11™-2016 covers the Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications.
- ITU-T Recommendation E.212 provides the international identification plan for public networks and subscriptions.
- Policy and Charging Control Framework for the 5G System; Stage 2 is specified in 3GPP TS 23.503.
- UE policies for 5GS include URSP, ANDSP, V2XP, and ProSeP, as listed in 3GPP TS 23.503.
- Access Traffic Steering, Switching and Splitting; Stage 3 is covered in 3GPP TS 24.193.

TDoc C1-232162:

- Support of Uncrewed Aerial Systems (UAS) connectivity, identification and tracking; Stage 2 is provided in 3GPP TS 23.256.
- Wireless and wireline convergence access support for the 5G System (5GS) is defined in 3GPP TS 23.316.
- Characteristics of the Universal Subscriber Identity Module (USIM) application are outlined in 3GPP TS 31.102.
- Secured packet structure for (Universal) Subscriber Identity Module (U)SIM Toolkit applications are specified in 3GPP TS 31.115.
- NR Medium Access Control (MAC) Protocol specification is given in 3GPP TS 38.321.
- Special conformance testing functions for User Equipment (UE) are defined in 3GPP TS 38.509.
- NR Packet Data Convergence Protocol (PDCP) specification is provided in 3GPP TS 36.323.
- IP Multimedia Subsystem (IMS) emergency sessions are outlined in 3GPP TS 23.167.

TDoc C1-232277:

- UE procedures in Idle mode and RRC Inactive state are specified in 3GPP TS 38.304.
- Protocol aspects of User Equipment (UE) to V2X control function are covered in 3GPP TS 24.386.
- Aircraft-to-Everything (A2X) services in 5G System (5GS) protocol aspects are outlined in 3GPP TS 24.577.
- Security aspects of 3GPP support for advanced Vehicle-to-Everything (V2X) services are addressed in 3GPP TS 33.536.
- Architecture enhancements for 5G System (5GS) to support Vehicle-to-Everything (V2X) services are provided in 3GPP TS 23.287.
- Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in idle mode are specified in 3GPP TS 23.122.
- A vocabulary for 3GPP Specifications is defined in 3GPP TR 21.905.

TDoc C1-232152:

- Defines various terms and definitions related to cable identifiers, network selection, roaming, and network identity.
- References 3GPP TS 23.122 and TS 23.003 for definitions and provisions.
- Provides a list of terms and definitions, including Global Cable Identifier (GCI), GUAMI, IMEI, IMEISV, IMSI, PEI, SUPI, SUCI, CAG selection, Country EHPLMN, HPLMN, Onboarding services in SNPN, Registered SNPN, Selected PLMN, Selected SNPN, Shared network, SNPN identity, Steering of Roaming (SOR), Steering of roaming connected mode control information (SOR-CMCI), Steering of Roaming information, Subscribed SNPN, Suitable cell, VPLMN, Non-public network, Disaster Roaming, satellite, and NG-RAN.

Example snippet: "For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.122 [5] apply: CAG selection, CAG-ID authorized based on 'Allowed CAG list', Country EHPLMN, HPLMN, Onboarding services in SNPN, Registered SNPN, Selected PLMN, Selected SNPN, Shared network, SNPN identity, Steering of Roaming (SOR), Steering of roaming connected mode control information (SOR-CMCI), Steering of Roaming information, Subscribed SNPN, Suitable cell, VPLMN."

TDoc C1-232284:

- Specifies the requirement for UE requested policy provisioning for ranging and SL positioning in 5G system.
- Lists the types of policy/parameters that can be requested, including policy/parameters for ranging/SL positioning, located UE, and target UE.
- References 3GPP TS 23.273 and TS 23.586 for provisions and definitions.

Example snippet: "In TS 23.586, there is the following requirement on UE requested policy provisioning: - Indicating UE Policy Provisioning Request in UE Policy Container for UE triggered Ranging/SL Positioning Policy provisioning, which requests one or multiple types of policies/parameters as listed below: - Policy/parameters for Ranging/SL Positioning over PC5; - Policy/parameters for Located UE; - Policy/parameters for Target UE in addition to the functions defined in TS 23.273."

TDoc C1-232577:

- Provides content for the scope of the new 3GPP TS 24.514 specification for ranging-based service and sidelink positioning in 5G system.
- References 3GPP TR 21.801 for drafting rules and procedures.
- Specifies that a non-specific reference to a 3GPP document implicitly refers to the latest version of that document in the same release as the present document.

Example snippet: "The scope clause needs to be defined for new specification as per drafting rules defined in 3GPP TR 21.801."

3GPP-C1-141-e    Agenda Item 18.2.25. : 5GFLS

Technical Differences:

1. TDoc C1-232598 mentions "Online 17-21 April 2023" before the meeting information, whereas TDoc C1-232600 mentions it after the meeting information.

Example from TDoc C1-232598: "Online 17-21 April 2023 3GPP TSG-CT WG1 Meeting #141e C1-232598"

2. TDoc C1-232598 uses a hyphen (-) to separate the dates of the meeting, whereas TDoc C1-232600 uses an en dash (–) to separate the dates.

Example from TDoc C1-232598: "Online 17-21 April 2023 3GPP TSG-CT WG1 Meeting #141e C1-232598"

3. TDoc C1-232598 includes a space before the meeting number (#141e), whereas TDoc C1-232600 does not include a space before the meeting number.

Example from TDoc C1-232598: "3GPP TSG-CT WG1 Meeting #141e C1-232598"

4. TDoc C1-232600 includes the meeting information before the "End of changes" statement, whereas TDoc C1-232598 includes the meeting information after the "End of changes" statement.

Example from TDoc C1-232600: "3GPP TSG-CT WG1 Meeting #141e C1-232600 Online 17– 21 April 2023 * * * * * * * * * * * End of changes * First Change"

5. TDoc C1-232600 uses asterisks (*) to separate the "End of changes" statement from the meeting information, whereas TDoc C1-232598 uses hyphens (-) to separate the "End of changes" statement from the meeting information.

Example from TDoc C1-232600: "* * * * * * * * * * * End of changes * First Change * 3GPP TSG-CT WG1 Meeting #141e C1-232600 Online 17– 21 April 2023"

6. TDoc C1-232600 includes a space before and after the asterisks (*) in the "End of changes" statement, whereas TDoc C1-232598 does not include spaces before or after the hyphens (-) in the "End of changes" statement.

Example from TDoc C1-232600: "* * * * * * * * * * * End of changes * First Change * 3GPP TSG-CT WG1 Meeting #141e C1-232600 Online 17– 21 April 2023"

Example from TDoc C1-232598: "- - - - - - - - - - End of changes First Change Online 17-21 April 2023 3GPP TSG-CT WG1 Meeting #141e C1-232598"

7. TDoc C1-232598 includes spaces between the hyphens (-) in the "End of changes" statement, whereas TDoc C1-232600 does not include spaces between the asterisks (*) in the "End of changes" statement.

Example from TDoc C1-232598: "- - - - - - - - - - End of changes First Change Online 17-21 April 2023 3GPP TSG-CT WG1 Meeting #141e C1-232598"

Example from TDoc C1-232600: "* * * * * * * * * * * End of changes * First Change * 3GPP TSG-CT WG1 Meeting #141e C1-232600 Online 17– 21 April 2023"

Overall, the technical differences between TDoc C1-232598 and TDoc C1-232600 include differences in the order and formatting of the meeting information and the "End of changes" statement. TDoc C1-232598 includes the meeting information after the "End of changes" statement and uses hyphens to separate the "End of changes" statement from the meeting information, while TDoc C1-232600 includes the meeting information before the "End of changes" statement and uses asterisks to separate the "End of changes" statement from the meeting information. There are also differences in the use of spaces and punctuation between the two TDocs.

3GPP-C1-141-e    Agenda Item 18.2.26. : PINAPP

Technical Differences Among TDocs:

1. PIN server discovery procedure is specified in clause 8.3 of TS 23.542 v0.2.0.
Example from TDoc C1-232555: "Some of the PIN management procedures need the PIN server to help. So, the PINE should receive the PIN server endpoint address first and then trigger the other procedures, e.g. the PIN creation procedure."

2. Abbreviations for PIN Registration to PIN server procedure are defined in the present document, taking precedence over TR 21.905.
Example from TDoc C1-232556: "An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905 [1] and the following apply."

3. Different scenarios for PEMC requesting creation of PIN are specified in clause 8.5.2 of TS 23.542 v0.2.0.
Example from TDoc C1-232558: "After the PINE acquires the role of PEMC and receives the address of PIN server, the PEMC can trigger a creation of PIN towards PIN server. In this case, the PEMC can trigger creation of PIN with these PIN elements in group."

4. PIN enable 5GS communication is introduced with a general description.
Example from TDoc C1-232561: "The general description of PIN enable 5GS communication is introduced."

Supporting examples from the original TDocs are highlighted in italics.

Technical Differences:

1. Configuration related to duration of PIN:
- TDoc C1-232559 states that the PEMC can delete the PIN locally when the duration of the PIN expires, without authorization from the PIN server.
- TDoc C1-232560 does not mention this configuration.

Example from TDoc C1-232559: "Since the configuration related to the duration of the PIN is available with PEMC and when the duration of the PIN expires, the PEMC can directly delete the PIN locally and without having to be authorized by the PIN server."

2. Deletion of PIN:
- TDoc C1-232559 states that the PEMC or PIN server can decide to delete the PIN, but the PIN server accepts the request and deletes the PIN.
- TDoc C1-232560 does not mention who decides to delete the PIN.

Example from TDoc C1-232559: "If the PIN is configured to exist for a particular duration and if it continues to exist post the duration the PIN server can decide to delete the PIN and release the resources associated with the PIN. The PIN server accepts the request and deletes the PIN."

3. PIN discovery:
- TDoc C1-232560 specifies two ways in which the PIN elements can discover the available PIN, while TDoc C1-232559 does not mention this.

Example from TDoc C1-232560: "There are two situations that the PIN elements can discover the PIN as following: if the PIN elements can have an application layer communication with the PEMC which manages a PIN, the PIN elements can receive the PIN ID, PIN description and the PIN service that a PIN can provide, and decides whether to join the PIN; the PEGC can be set as open access and the PIN element can communicate with PIN server to receive the PIN ID, PIN description and the PIN service that a PIN can provide from PIN server via the PEGC."

4. PINE join into the PIN:
- TDoc C1-232560 states that the PINE should discover the available PIN before joining, while TDoc C1-232559 does not mention this.

Example from TDoc C1-232560: "Before the PINE triggers the PINE join into the PIN, the PINE should discover the available PIN."

Overall, TDoc C1-232559 focuses more on the deletion of PIN and the configuration related to its duration, while TDoc C1-232560 focuses more on the discovery of available PINs and the procedure for joining them.

Technical differences among the following TDocs:

TDoc C1-232554:
- The document provides an overview of PINAPP.
- The reason for change is that the overview of PINAPP is missing.
- No technical details or changes are provided in the document.
- The proposal is to agree on the changes to 3GPP TS 24.583 v0.0.0.

Example snippet from the original TDoc to support the difference highlighting:
- "4.1 General - Reason for Change: The overview of PINAPP is missing."

TDoc C1-232557:
- The document provides a skeleton of PIN Management procedure.
- The reason for change is that the skeleton of PIN Management is missing.
- The proposal is based on clause 8.5 of TS 23.542 v0.2.0.
- No technical details or changes are provided in the document.
- The proposal is to agree on the changes to 3GPP TS 24.583 v0.0.0.

Example snippet from the original TDoc to support the difference highlighting:
- "5.4 PIN Management - The proposal is based on clause 8.5 of TS 23.542 v0.2.0."

3GPP-C1-141-e    Agenda Item 18.2.27 : PIN

- The TDoc C1-232024 outlines the use of Non-3GPP QoS Assistance Information (N3QAI) to enable a PEGC to perform QoS differentiation for PINEs in the non-3GPP access network.
- The TDoc C1-232344 and C1-232349 also mention the use of N3QAI for QoS differentiation in non-3GPP access networks.
- All three TDocs mention the end-to-end QoS requirement for each PINE over PINE-to-PINE indirect communication, which includes the QoS requirement in both 3GPP and non-3GPP access networks.
- A UE acting as a PEGC enables PINEs behind it to connect to the network when it is registered for 5GS services in all three TDocs.
- If the UE supports providing the non-3GPP delay budget, it may provide the network with the non-3GPP delay budget for one or more QoS flows associated with PDU sessions for a PIN during the PDU session establishment or modification procedure, as defined in subclause 6.4.1 or 6.4.2.
- TDoc C1-232024 specifies that the non-3GPP delay refers to the delay budget between the PEGC and the PINE in the non-3GPP access network.
- TDoc C1-232344 mentions that each PIN contains something, but the details are not specified.

Example snippets from the original TDocs:

- TDoc C1-232024: "The Non-3GPP QoS Assistance Information (N3QAI) is introduced to enable a PEGC to perform the QoS differentiation for the PINEs in the non-3GPP access network."
- TDoc C1-232344: "Each PIN contains something."
- TDoc C1-232349: "First Change"

TDoc C1-232249:

- The SMF removes a UE from multicast MBS sessions by including the multicast MBS session IDs that the UE is removed from in the Received MBS container IE in the PDU SESSION MODIFICATION COMMAND message and setting the MBS decision to "Remove UE from multicast MBS session".
- When a UE-requested PDU session modification procedure is used to indicate a change in 3GPP PS data off UE status for a PDU session, the UE includes the Extended protocol configuration options IE in the PDU SESSION MODIFICATION REQUEST message and sets the 3GPP PS data off UE status to the authorized QoS flow descriptions of the PDU session in the PDU SESSION MODIFICATION COMMAND message.

Example snippet: "If: a) the SMF wants to remove joined UE from one or more multicast MBS sessions; or b) the network-requested PDU session modification procedure is triggered by a UE-requested PDU session modification procedure and the UE has included the Requested MBS container IE in the PDU SESSION MODIFICATION REQUEST message with the MBS operation set to "Leave multicast MBS session", the SMF shall include the multicast MBS session IDs that the UE is removed from, if any, in the Received MBS container IE in the PDU SESSION MODIFICATION COMMAND message and shall set the MBS decision to "Remove UE from multicast MBS session" for each of those Received MBS information."

TDoc C1-232347:

- The UE selects a route selection descriptor with the next smallest precedence value which has not yet been evaluated.
- If the selected route selection descriptor contains a non-seamless non-3GPP offload indication and information on the non-3GPP access outside of a PDU session is available, it is provided to the upper layers and the UE stops selecting a route selection descriptor matching the application information.
- The PDU session type and preferred access type or multi-access preference, if included in the route selection descriptor, are considered in determining the route selection.

Example snippet: "II) otherwise: 1) the UE shall select a route selection descriptor with the next smallest precedence value which has not yet been evaluated; 2) if: i) the selected route selection descriptor contains a non-seamless non-3GPP offload indication: A) if the information on the non-3GPP access outside of a PDU session is available, it shall be provided to the upper layers and the UE shall stop selecting a route selection descriptor matching the application information. D) the PDU session type of the route selection descriptor; E) preferred access type or multi-access preference, if the preferred access type or the multi-access preference is in the route selection descriptor; NOTE 6: If a preferred access type or a multi-access preference is included in the route selection descriptor of a URSP rule, it is recommended that the UE establishes a PDU session based on the preferred access type or the multi-access preference. The UE shall stop selecting a route selection descriptor matching the application information."

3GPP-C1-141-e    Agenda Item 18.2.28 : 5GMARCH_Ph2

TDoc C1-232178:
- No specific technical differences highlighted in the snippet provided.

TDoc C1-232179:
- The TDoc is identical to C1-232178 except for the document number.
- Example snippet: "End of Changes * First Change"

TDoc C1-232181:
- The TDoc is identical to C1-232179 except for the document number.
- Example snippet: "3GPP TSG CT WG1 Meeting#141e C1-232180"

TDoc C1-232182:
- The TDoc is identical to C1-232181 except for the absence of the "3GPP TSG CT WG1 Meeting#141e" label.
- Example snippet: "Online 17 – 21 April 2023"

Technical Differences among TDoc C1-232171 and C1-232172:

TDoc C1-232171:
- Specifies group creation, configuration management, and membership for the MSGin5G service.
- Includes a list of VAL user IDs or VAL UE IDs which do not have group management client on the UE, and the MSGin5G server initiates the group creation notification toward those UEs.
- Clarifies that upon receiving Group Creation notification as specified in clause 6.2.2 of 3GPP TS 24.544, the MSGin5G Client and MSGin5G Server utilize group management service procedures of SEAL to support MSGin5G Service.
- Refers to 3GPP TS 24.544 3GPP TSG-CT WG1 Meeting #141e C1-232171 First Change.

Example snippet from TDoc C1-232171:
"For list of VAL user IDs or VAL UE IDs which does not have group management client on the UE (e.g. Legacy 3GPP UEs or Non-3GPP UEs), the MSGin5G server initiate the group creation notification towards those UEs."

TDoc C1-232172:
- Describes the aspects that can be provided by means of using the MSGin5G-1, MSGin5G-5, and MSGin5G-6 interfaces.
- MSGin5G-1 interface allows for MSGin5G UE registration and de-registration towards the MSGin5G Server, MSGin5G message delivery, and messaging topic subscription.
- MSGin5G-5 interface allows for constrained UE registration and de-registration towards the MSGin5G Gateway UE and the exchanging of message and message delivery status report between Constrained UE and MSGin5G Server by using MSGin5G Gateway UE.
- MSGin5G-6 interface allows for constrained UE registration and de-registration towards the MSGin5G Server by using MSGin5G Relay UE and the exchanging of MSGin5G message and MSGin5G message delivery status report between Constrained UE and MSGin5G Server by using MSGin5G Relay UE.
- Refers to an out-of-scope document (17) and (2).

Example snippet from TDoc C1-232172:
"By means of using the MSGin5G-1 interface, the following aspects can be provided: a) MSGin5G UE registration and de-registration towards the MSGin5G Server; b) MSGin5G message delivery and MSGin5G message delivery status report; and c) Messaging Topic Subscription."

Technical Differences:

1. TDocs C1-232173 and C1-232174 are two different TDocs with different document numbers.
2. Both TDocs include the same set of 3GPP TS specifications and IETF RFC.
3. TDoc C1-232174 includes two additional lines "First Change" and "Next Change" which are not present in TDoc C1-232173.

Example Snippets:

1. TDoc C1-232173 and C1-232174 both include the 3GPP TS 24.546 specification for Configuration Management - Service Enabler Architecture Layer for Verticals (SEAL); Protocol specification.
2. TDoc C1-232173 and C1-232174 both include the 3GPP TS 24.545 specification for Location Management - Service Enabler Architecture Layer for Verticals (SEAL); Protocol specification.
3. TDoc C1-232173 and C1-232174 both include the 3GPP TS 24.547 specification for Identity Management - Service Enabler Architecture Layer for Verticals (SEAL); Protocol specification.
4. TDoc C1-232173 and C1-232174 both include the 3GPP TS 24.548 specification for Network Resource Management - Service Enabler Architecture Layer for Verticals (SEAL); Protocol specification.
5. TDoc C1-232173 and C1-232174 both include the 3GPP TS 24.544 specification for Group Management - Service Enabler Architecture Layer for Verticals (SEAL); Protocol specification.
6. TDoc C1-232173 and C1-232174 both include the IETF RFC 7641 specification for Observing Resources in the Constrained Application Protocol (CoAP).
7. TDoc C1-232174 includes additional lines "First Change" and "Next Change" which are not present in TDoc C1-232173.

3GPP-C1-141-e    Agenda Item 18.2.30. : ATSSS_Ph3

Technical differences among the TDoc snippets are as follows:

- TDoc C1-232164 specifies the ATSSS request information field to be set to "ATSSS Low-Layer functionality with any steering mode supported" in the ATSSS_REQUEST Notify payload. It also specifies the network-initiated and UE-initiated PDU session release procedures to be initiated in certain scenarios.
- TDoc C1-232293 also specifies the ATSSS request information field to be set to "ATSSS Low-Layer functionality with any steering mode supported" in the ATSSS_REQUEST Notify payload. It additionally specifies the behavior of the UE if it does not receive an IKE_AUTH response message including the ATSSS_RESPONSE Notify payload.
- TDoc C1-232294 specifies the IP addresses, port numbers, and types of MPTCP and MPQUIC proxies in the UPF, as well as the ATSSS rules to be used. It also specifies that MPTCP and MPQUIC functionalities with any steering mode and ATSSS-LL functionality with only active-standby steering mode should not be enabled for Ethernet type MA PDU sessions.

Examples from the original TDocs supporting the above differences are:

- TDoc C1-232164: "the UE shall set the ATSSS request information field of the ATSSS_REQUEST Notify payload to 'ATSSS Low-Layer functionality with any steering mode supported'"; "the network needs to release the user-plane resources, if any, established on 3GPP access of the MA PDU session, the network shall initiate the network-requested PDU session release procedure"; "the UE needs to release the user-plane resources, if any, established on 3GPP access of the MA PDU session, the UE shall initiate the UE-requested PDU session release procedure."
- TDoc C1-232293: "the UE shall set the ATSSS request information field of the ATSSS_REQUEST Notify payload to 'ATSSS Low-Layer functionality with any steering mode supported'"; "no IKE_AUTH response message including the ATSSS_RESPONSE Notify payload; the UE shall consider that the MA PDU session is not established and the PDN connection over untrusted non-3GPP access network is not established as a user-plane resource of the MA PDU session."
- TDoc C1-232294: "the IP address, port number, and the type of one or more MPTCP proxies in the UPF"; "the IP address, port number, and the type of one or more MPQUIC proxies in the UPF"; "one or more ATSSS rules including one ATSSS rule for non-MPTCP and non-MPQUIC traffic which is composed of a precedence with value '255', a 'match-all type' traffic descriptor, an 'ATSSS-LL functionality' steering functionality and an 'active-standby' steering mode"; "When the MA PDU session is Ethernet type, the network shall not enable the MPTCP functionality nor the MPQUIC functionality with any steering mode and the ATSSS-LL functionality with only active-standby steering mode"; "When the MA PDU session is Ethernet type, the network shall not enable the MPTCP functionality nor the MPQUIC functionality with any steering mode and the ATSSS-LL functionality with any steering mode."

TDoc C1-232484:

- The UE must be in NB-N1 mode.
- The UE must have set the RACS bit to "RACS supported" in the 5GMM Capability IE of the REGISTRATION REQUEST message.
- The REGISTRATION ACCEPT message includes:
- A UE radio capability ID deletion indication IE set to "Network-assigned UE radio capability IDs deletion requested": The UE must delete any network-assigned UE radio capability IDs associated with the RPLMN or RSNPN, and initiate a registration procedure for mobility and periodic registration update after the completion of the ongoing registration procedure.
- A UE radio capability ID IE: The UE must store the UE radio capability ID.

Example snippet from TDoc C1-232484: "If the UE is not in NB-N1 mode, the UE has set the RACS bit to "RACS supported" in the 5GMM Capability IE of the REGISTRATION REQUEST message and the REGISTRATION ACCEPT message includes:"

TDoc C1-232485:

- The SMF selection must be successful.
- The AMF must store a PDU session routing context for the PDU session ID and the UE and set the SMF ID of the PDU session routing context to the SMF ID of the selected SMF.
- The AMF must send the 5GSM message, the PDU session ID, the old PDU session ID, the S-NSSAI, the mapped S-NSSAI (in roaming scenarios), the DNN, the request type, the MA PDU session information and UE presence in LADN service area (if DNN received corresponds to an LADN DNN) towards the SMF identified by the SMF ID of the PDU session routing context for the PDU session ID and the UE.
- The MA PDU session information must be sent towards the SMF if the DNN received corresponds to an LADN DNN.
- The AMF shall send the content of the Payload container IE to the UDM.

Example snippet from TDoc C1-232485: "If the SMF selection is successful:"

TDoc C1-232486:

- The selected PDU session type of the PDU session must be "Ethernet".
- The UE must support inter-system change from N1 mode to S1 mode.
- The UE must not support establishment of a PDN connection for the PDN type set to "non-IP" in S1 mode.
- The UE, the network, or both of them must not support Ethernet PDN type in S1 mode.
- The parameters list field of one or more authorized QoS flow descriptions received in the Authorized QoS flow descriptions IE of the PDU SESSION ESTABLISHMENT ACCEPT message must contain an EPS bearer identity (EBI).
- The UE shall locally remove the EPS bearer identity (EBI) from the parameters list field of such one or more authorized QoS flow descriptions.
- If the above conditions are not met, the UE shall send a PDU SESSION MODIFICATION REQUEST message to delete the QoS flow description which lacks at least one of the mandatory parameters and the associated QoS rule(s), if any, with 5GSM cause #84 "syntactical error in the QoS operation" in the PDU SESSION ESTABLISHMENT ACCEPT message.

Example snippet from TDoc C1-232486: "If the selected PDU session type of the PDU session is "Ethernet", the UE supports inter-system change from N1 mode to S1 mode, the UE does not support establishment of a PDN connection for the PDN type set to "non-IP" in S1 mode..."

TDoc C1-232487:

- The MCS indicator bit in the 5GS network feature support IE provided in the REGISTRATION ACCEPT message is valid in non-3GPP access of the registered SNPN and its equivalent SNPNs until:
- The UE receives a REGISTRATION ACCEPT message with the MCS indicator bit set to "Access identity 2 not valid" via non-3GPP access.
- The UE receives a REGISTRATION ACCEPT message with the MCS indicator bit set to "Access identity 2 not valid" via 3GPP access, and the UE is registered to the same SNPN over 3GPP access and non-3GPP access.
- The UE selects a non-equivalent SNPN over non-3GPP access.
- During ongoing active PDU sessions that were set up relying on the MCS indicator bit being set to "Access identity 2 valid", if the network indicates in a registration update that the MCS indicator bit is reset to "Access identity 2 not valid", then the UE shall no longer act as a UE with access identity 2 configured for MCS unless the unified access control configuration in the "list of subscriber data" stored in the ME.

Example snippet from TDoc C1-232487: "The MCS indicator bit in the 5GS network feature support IE provided in the REGISTRATION ACCEPT message is valid in non-3GPP access of the registered SNPN and its equivalent SNPNs until..."

1. The ATSSS feature enables multi-access PDU connectivity service using one 3GPP access network and one non-3GPP access network.
- "The ATSSS feature enables a multi-access PDU connectivity service, which can exchange PDUs between the UE and a data network by simultaneously using one 3GPP access network and one non-3GPP access network."
- "The multi-access PDU connectivity service is realized by establishing a multi-access PDU session, i.e. a PDU session that can have user-plane resources on two access networks."
- "The detailed description of the procedures for ATSSS between the UE and the network across one 3GPP access network and one non-3GPP access network are specified in 3GPP TS 24.193"
- "The UE can request an MA PDU session when the UE is registered via both 3GPP and non-3GPP accesses, or when the UE is registered via one access only."
- "The ATSSS feature is an optional feature that may be supported by the UE and the 5GCN."

2. The SMF may include the Ethernet header compression configuration IE if certain conditions are met.
- "The SMF may include the Ethernet header compression configuration IE if: - the network accepts an Ethernet PDU session type; - control plane CIoT 5GS optimization is selected; and - the UE provided the Ethernet header compression configuration IE in the PDU SESSION ESTABLISHMENT REQUEST message."

3. The EAP message is included when the external DN successfully performed authentication and authorization of the UE using EAP.
- "This IE is included when the external DN successfully performed authentication and authorization of the UE using EAP."

4. The S-NSSAI IE is included when certain conditions are met.
- "This IE shall be included in the message when the SMF received from the AMF an S-NSSAI together with the PDU SESSION ESTABLISHMENT REQUEST message, the PDU session is a non-emergency PDU session and the UE is not registered for onboarding services in SNPN."

5. The 5GSM cause IE is included when the selected PDU session type is different from the one requested by the UE.
- "This IE is included when the selected PDU session type is different from the PDU session type requested by the UE."

6. The 5GSM network feature support IE is included when the network needs to indicate support of 5GSM network features.
- "This IE is included when the network needs to indicate support of 5GSM network features. See table 8.3.2.1.1."

7. The DNN IE is present in the PDU session establishment request message.
- "DNN" is not explicitly mentioned in the TDoc, but it is implied as it is a standard IE in PDU session establishment messages.

3GPP-C1-141-e    Agenda Item 18.2.31. : UEConfig5MBS

- TDoc C1-232049 analyzes potential impacts to CT1 and provides an analysis of the status of the work under the UEConfig5MBS work within the Rel-18 version of 3GPP specifications.
- CT1 impacts for UEConfig5MBS involve completing the stage-3 specification on the UE pre-configuration MO in Rel-18.
- TDoc C1-232504 outlines the information configured for each PLMN in the UE pre-configuration, including PLMN ID, RAN info, TMGI, USD info, DNN and S-NSSAI pair.
- TDoc C1-232608 identifies the need for corrections and additional work to complete the UE pre-configuration MO work started by CT1.
- The corrections and additional work include aligning the scope with the approved work item and contents of the specification, resolving an editor's note on the need of a TMGI leaf for the DNN+S-NSSAI, adding the missing DDF of the UE pre-configuration MO, correcting the format of certain nodes, and removing an unnecessary node.
- CT1 impacts for UEConfig5MBS involve completing the already existing stage-3 specification on the UE pre-configuration MO in Rel-18.

TDoc C1-232052:
- Occurrence: OneOrMore
- Format:
- Access Types: Get, Replace
- Values: N/A
Example snippet from TDoc: N/A

- Occurrence: One
- Format: int
- Access Types: Get, Replace
- Values:
Example snippet from TDoc: /PLMNList//PDUInfo/PDUInfoList//S-NSSAI

- Occurrence: One
- Format: chr
- Access Types: Get, Replace
- Values:
Example snippet from TDoc: /PLMNList//PDUInfo//DNN

TDoc C1-232505:
- Occurrence: ZeroOrOne
- Format: node
- Access Types: Get, Replace
- Values: N/A
Example snippet from TDoc: UE pre-configuration MO structure

- Occurrence: OneOrMore
- Format: node
- Access Types: Get, Replace
- Values: N/A
Example snippet from TDoc: /PLMNList//TMGIConfiguration/TMGIListForSA/

TDoc C1-232506:
- Occurrence: One
- Format:
- Access Types: Get, Replace
- Values: N/A
Example snippet from TDoc: TMGIConfiguration node acts as a placeholder for the TMGI configuration

- Occurrence: ZeroOrOne
- Format: node
- Access Types: Get, Replace
- Values: N/A
Example snippet from TDoc: /PLMNList//TMGIConfiguration/TMGIListForService/

TDoc C1-232507:
- Occurrence: OneOrMore
- Format:
- Access Types: Get, Replace
- Values: N/A
Example snippet from TDoc: /PLMNList//PDUInfo//DNN

- Occurrence: One
- Format: int
- Access Types: Get, Replace
- Values:
Example snippet from TDoc: /PLMNList//PDUInfo//S-NSSAI

- Occurrence: One
- Format: chr
- Access Types: Get, Replace
- Values:
Example snippet from TDoc: /PLMNList//PDUInfo/

TDoc C1-232050
- Specifies UE pre-configuration for receiving broadcast communication service data (3GPP TS 23.247)
- Defines a management object (MO) with nodes and leaves for conveying pre-configuration parameters
- MO is compatible with OMA Device Management (DM) protocol specifications, version 1.2 and upwards
- MO is defined using the OMA DM device description framework (DDF) as described in Enabler Release Definition OMA-ERELD-DM-V1_2

Example snippet: "The present document specifies UE pre-configuration in order to receive the data of broadcast communication service as specified in 3GPP TS 23.247"

TDoc C1-232503
- Same as TDoc C1-232050, but with changes made
- Changes not specified in the summary

Example snippet: "The MO consists of nodes and leaves conveying UE pre-configuration parameters used for broadcast communication service selection and data reception."

TDoc C1-232508
- UE pre-configuration includes PLMN list with PLMN ID, RAN information based on NR-ARFCN, and list of TMGI with USD information for MBS broadcast service
- USD leaf provides MBS service announcement information for MBS service announcement service for broadcast communication service
- UE may support pre-configuration of information for services using MBS

Example snippet: "The UE pre-configuration contains a list of PLMNs in which for each PLMN, the following information is configured: a) PLMN ID of the PLMN for which the configuration applies; b) RAN information based on NR-ARFCN on which the broadcast communication service is available; c) list of TMGI, on which the broadcast communication service is available, associated user service description (USD) information for the MBS broadcast service."

3GPP-C1-141-e    Agenda Item 18.2.32 : 5GSAT_Ph2

Technical Differences among TDocs:

1. If UE operating in single-registration mode performs inter-system change from S1 mode to N1 mode and has stored UE policy sections, then it includes UE STATE INDICATION message in the Payload container IE of the REGISTRATION REQUEST message. [TDoc C1-232148]
2. If UE is not in NB-N1 mode and the UE supports RACS, then it sets the RACS bit to "RACS supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. [TDoc C1-232149, C1-232291, C1-232299]
3. If UE is in EMM-IDLE mode and needs to inform network for UE radio capability information update, then it indicates "periodic updating" or "TA updating" in the EPS update type IE depending upon the reason for initiating the normal and periodic tracking area updating procedure. [TDoc C1-232292]
4. If UE receives a REGISTRATION ACCEPT message with the MCS indicator bit set to "Access identity 2 not valid", then it no longer acts as a UE with access identity 2 configured for MCS unless the unified access control configuration in the "list of subscriber data" stored in the ME permits. [TDoc C1-232297]
5. Depending upon the case, UE performs new registration procedure as specified in subclause 5.5.1.3.2, 5.5.1.3.5 or 5.6.1.5 upon an indication from lower layers that the access stratum connection has been released. [TDoc C1-232298]

Examples from TDocs:

1. In TDoc C1-232148, it is mentioned that "If the UE operating in the single-registration mode performs inter-system change from S1 mode to N1 mode and has one or more stored UE policy sections identified by a UPSI with the PLMN ID part indicating the HPLMN or the selected PLMN, the UE shall set the Payload container type IE to "UE policy container" and include the UE STATE INDICATION message (see annex D) in the Payload container IE of the REGISTRATION REQUEST message."
2. In TDocs C1-232149, C1-232291, and C1-232299, it is mentioned that "For all cases except case b, when the UE is not in NB-N1 mode and the UE supports RACS, the UE shall set the RACS bit to "RACS supported" in the 5GMM capability IE of the REGISTRATION REQUEST message."
3. In TDoc C1-232292, it is mentioned that "If case b) is the only reason for initiating the normal and periodic tracking area updating procedure, the UE shall indicate "periodic updating" in the EPS update type IE; otherwise the UE shall indicate "TA updating"."
4. In TDoc C1-232297, it is mentioned that "The MCS indicator bit in the 5GS network feature support IE provided in the REGISTRATION ACCEPT message is valid in non-3GPP access of the registered SNPN and its equivalent SNPNs until the UE receives a REGISTRATION ACCEPT message with the MCS indicator bit set to "Access identity 2 not valid"."
5. In TDoc C1-232298, it is mentioned that "Depending upon the case, UE performs new registration procedure as specified in subclause 5.5.1.3.2, 5.5.1.3.5 or 5.6.1.5 upon an indication from lower layers that the access stratum connection has been released."

TDoc C1-232326:

- UE must be in NB-N1 mode.
- UE has set RACS bit to "RACS supported" in 5GMM Capability IE.
- REGISTRATION ACCEPT message includes either UE radio capability ID deletion indication IE or UE radio capability ID IE.

Example snippet: "If the UE is not in NB-N1 mode, the UE has set the RACS bit to "RACS supported" in the 5GMM Capability IE of the REGISTRATION REQUEST message"

TDoc C1-232428:

- UE is operating in the single-registration mode and performs inter-system change from S1 mode to N1 mode.
- UE has stored UE policy sections identified by a UPSI with the PLMN ID part indicating the HPLMN or the selected PLMN.
- UE includes UE STATE INDICATION message and Payload container type IE in REGISTRATION REQUEST message.
- UE includes Requested NSSAI IE and Network slicing indication IE in REGISTRATION REQUEST message if no allowed NSSAI is configured and default configured NSSAI is present.

Example snippet: "If the UE operating in the single-registration mode performs inter-system change from S1 mode to N1 mode and has one or more stored UE policy sections identified by a UPSI with the PLMN ID part indicating the HPLMN or the selected PLMN"

TDoc C1-232593:

- AMF sets MPS indicator bit in REGISTRATION ACCEPT message based on MPS priority information in user's subscription context.
- UE acts as a UE with access identity 1 configured for MPS upon receiving REGISTRATION ACCEPT message with MPS indicator bit set to "Access identity 1 valid".
- S-NSSAI associated with active PDN connections is included in allowed NSSAI if UE included UE status IE in REGISTRATION REQUEST message and AMF supports N26 interface.
- Support for unavailability period is negotiated in registration procedure.

Example snippet: "Based on operator policy, the AMF sets the MPS indicator bit in the REGISTRATION ACCEPT message based on the MPS priority information in the user's subscription context obtained from the UDM"

TDoc C1-232594:

- UE must not be in NB-N1 mode.
- UE has set RACS bit to "RACS supported" in 5GMM Capability IE.
- REGISTRATION ACCEPT message includes either UE radio capability ID deletion indication IE or UE radio capability ID IE.

Example snippet: "If the UE is not in NB-N1 mode, the UE has set the RACS bit to "RACS supported" in the 5GMM Capability IE of the REGISTRATION REQUEST message"

3GPP-C1-141-e    Agenda Item 18.2.33. : 5MBS_Ph2

3GPP-C1-141-e    Agenda Item 18.2.34 : GMEC

Technical differences among the following TDocs:

[TDoc C1-232129]:
- The purpose of the UE-requested PDU session establishment procedure is to establish a new PDU session with a DN, to perform handover of an existing PDU session between 3GPP access and non-3GPP access, to transfer an existing PDN connection in the EPS to the 5GS, to transfer an existing PDN connection in an untrusted non-3GPP access connected to the EPC to the 5GS, or to establish an MA PDU session to support ATSSS, or to relay the service associated with the RSC for 5G ProSe layer-3 UE-to-network relay.
- The PDU session enables exchange of PDUs between the UE and the DN.

[TDoc C1-232130]:
- The SMF may release the PDU session for LADN if the UE has not returned to the LADN service area after a period of time according to operator's policy.
- The UE is allowed to initiate the UE-requested PDU session release procedure to release a PDU session for LADN or to initiate the UE-requested PDU session modification procedure to indicate a change of 3GPP PS data off UE status.

[TDoc C1-232221]:
- If the UE has set the RACS bit to "RACS supported" in the 5GMM Capability IE of the REGISTRATION REQUEST message and the REGISTRATION ACCEPT message includes a UE radio capability ID deletion indication IE set to "Network-assigned UE radio capability IDs deletion requested", then the UE shall delete any network-assigned UE radio capability IDs associated with the RPLMN or RSNPN and initiate a registration procedure for mobility and periodic registration update.
- The AMF may include operator-defined access category definitions in the REGISTRATION ACCEPT message.

[TDoc C1-232222]:
- If the UE has set the RACS bit to "RACS supported" in the 5GMM Capability IE of the REGISTRATION REQUEST message and the REGISTRATION ACCEPT message includes a UE radio capability ID deletion indication IE set to "Network-assigned UE radio capability IDs deletion requested", then the UE shall delete any network-assigned UE radio capability IDs associated with the RPLMN or RSNPN and, after the completion of the ongoing registration procedure, initiate a registration procedure for mobility and periodic registration update.
- The UE shall store the UE radio capability ID as specified in annex C.

Examples from the original TDocs:
- [TDoc C1-232129]: "The purpose of the UE-requested PDU session establishment procedure is to establish a new PDU session with a DN... or to relay the service associated with the RSC for 5G ProSe layer-3 UE-to-network relay."
- [TDoc C1-232130]: "The SMF may release the PDU session for LADN if the UE has not returned to the LADN service area after a period of time according to operator's policy."
- [TDoc C1-232221]: "If the UE has set the RACS bit to 'RACS supported' in the 5GMM Capability IE of the REGISTRATION REQUEST message and the REGISTRATION ACCEPT message includes a UE radio capability ID deletion indication IE set to 'Network-assigned UE radio capability IDs deletion requested', then the UE shall delete any network-assigned UE radio capability IDs associated with the RPLMN or RSNPN and initiate a registration procedure for mobility and periodic registration update."
- [TDoc C1-232222]: "If the UE has set the RACS bit to 'RACS supported' in the 5GMM Capability IE of the REGISTRATION REQUEST message and the REGISTRATION ACCEPT message includes a UE radio capability ID deletion indication IE set to 'Network-assigned UE radio capability IDs deletion requested', then the UE shall delete any network-assigned UE radio capability IDs associated with the RPLMN or RSNPN and, after the completion of the ongoing registration procedure, initiate a registration procedure for mobility and periodic registration update."

3GPP-C1-141-e    Agenda Item 18.2.35 : Other Rel-18 issues (TEI18)

[TDoc C1-232085]:

- The MS removes a PLMN from the "forbidden PLMNs" list if a successful LR is performed after a subsequent manual selection of that PLMN, timer T3245 expires, or timer T3247 expires and the PLMN-specific attempt counter value is greater than zero and less than the MS implementation specific maximum value.
- The MS should maintain a list of PLMNs where the N1 mode capability was disabled due to receipt of a reject from the network with 5GMM cause #27 "N1 mode not allowed".

[TDoc C1-232123]:

- The port management capability information element informs the TSN AF of the port parameters supported by the DS-TT or NW-TT.
- To initiate the TSN AF-requested port management procedure, the TSN AF must encode the necessary information and include it in a MANAGE PORT COMMAND message.

[TDoc C1-232165]:

- The UE must allocate an EPTI value, create a PMF UAD PROVISIONING message with DL distribution information, and start timer T106 to initiate a UE assistance data provisioning procedure over an access of an MA PDU session.
- If the PC5 signalling protocol cause value in the PROSE DIRECT LINK ESTABLISHMENT REJECT message is #15 "security procedure failure of 5G ProSe UE-to-network relay" and the initiating UE has included the UE identity IE set to SUCI in the PROSE DIRECT LINK ESTABLISHMENT REQUEST message, then the initiating UE shall initiate the UE-to-network relay reselection procedure as specified in clause 8.2.3.

[TDoc C1-232167]:

- If the target UE is acting as a 5G ProSe layer-3 UE-to-network relay UE, and the relay service code used in the 5G ProSe direct link establishment corresponds to a DNN and/or S-NSSAI for which the NAS level session management congestion is activated, and the target UE needs to perform the PDU session establishment procedure for the DNN and/or S-NSSAI or the PDU session modification procedure for the DNN and/or S-NSSAI, then the target UE shall send a PROSE DIRECT LINK ESTABLISHMENT message.
- If the PC5 signalling protocol cause value in the PROSE DIRECT LINK ESTABLISHMENT REJECT message is #15 "security procedure failure of 5G ProSe UE-to-network relay", and initiating UE has included the UE identity IE set to SUCI in the PROSE DIRECT LINK ESTABLISHMENT REQUEST message, then the initiating UE shall initiate the UE-to-network relay reselection procedure.

[TDoc C1-232183]:

- If more than one ATTACH REQUEST message is received without an ATTACH ACCEPT or ATTACH REJECT message being sent, and the information elements in the messages differ, the previously initiated attach procedure shall be aborted, and a new procedure shall be executed. Otherwise, the network shall continue with the previous attach procedure.
- If a lower layer failure occurs before the message ATTACH COMPLETE has been received from the UE, the network shall locally abort the attach procedure, enter state EMM-DEREGISTERED, and shall not resend the message ATTACH ACCEPT.

[TDoc C1-232184]:

- If a lower layer failure occurs before the REGISTRATION COMPLETE message has been received from the UE and timer T3550 is running, the AMF shall locally abort the registration procedure for initial registration, enter state 5GMM-REGISTERED, and shall not resend the REGISTRATION ACCEPT message.
- If one or more of the information elements in the REGISTRATION REQUEST message with 5GS registration type IE set to "initial registration" differs from the ones received within the previous REGISTRATION REQUEST message with 5GS registration type IE set to "initial registration", the previously initiated the registration procedure for initial registration shall be aborted, and the new the registration procedure for initial registration shall be executed.

[TDoc C1-232230]:

- The parameter indicates the LADN information for one or more LADNs, where each LADN consists of a DNN and a tracking area identity list. The is encoded as the value part of the LADN information information element in 3GPP TS 24.501.
- If the parameter is omitted in the execution command, it indicates a request to the network for LADN information for all LADN(s) available in the current registration area.

[TDoc C1-232231]:

- The network must include the Service-level-AA container IE when it receives the Service-level-AA payload or the UUAA-MM result from the UAS-NF during the UUAA-MM procedure or the UUAA revocation procedure.
- The network must also include the Service-level-AA container IE if it receives from the UAS-F, the CAA-Level UAV ID as part of the UUAA-MM procedure.

[TDoc C1-232232]:

- The mapped EPS bearer contexts information element indicates a set of EPS bearer contexts for a PDU session.
- The mapped EPS bearer contexts information element is coded as shown in figure 9.11.4.8.1, figure 9.11.4.8.2, figure 9.11.4.8.3, and table 9.11.4.8.1.

[TDoc C1-232124]:

- InterWorking Function N5CW Non 5G Capable over WLAN
- N5GC Non-5G Capable
- NAI Network Access Identifier
- NAS Non Access Stratum
- NID Network Identifier
- NSWO Non-Seamless WLAN Offload
- PCF Policy control Function
- PDU Protocol Data Unit
- QFI QoS Flow Identifier
- RQI Reflective QoS Indicator
- SA Security Association
- SNPN Stand-alone Non-Public Network
- SPI Security Parameters Index
- SUPI Subscription Permanent Identifier
- SUCI Subscription Concealed Identifier
- TCP Transmission Control Protocol
- TNAN Trusted Non-3GPP Access Network
- TNAP Trusted Non-3GPP Access Point
- TNGF Trusted Non-3GPP Gateway Function
- TWAN Trusted WLAN Access Network
- TWAP Trusted WLAN Access Point
- TWIF Trusted WLAN Interworking Function
- UL Uplink
- UP User Plane
- UPF User Plane Function
- V-PCF A PCF in the VPLMN
- WLAN Wireless Local Area Network
- WLANSP WLAN Selection Policy

Example snippet supporting the difference highlighting: "The WLANSP determines whether a WLAN is authorized for use by the UE and/or the network. The WLANSP is used to select a WLAN and select the appropriate TWIF."

[TDoc C1-232447]:

- IETF RFC 6050: "A Session Initiation Protocol (SIP) Extension for the Identification of Services"
- 3GPP TS 24.546: "Configuration management - Service Enabler Architecture Layer for Verticals (SEAL); Protocol specification"
- 3GPP TS 23.434: "Service Enabler Architecture Layer for Verticals (SEAL); Functional architecture and information flows"
- 3GPP TS 24.547: "Identity management - Service Enabler Architecture Layer for Verticals (SEAL); Protocol specification"
- 3GPP TS 24.545: "Location Management - Service Enabler Architecture Layer for Verticals (SEAL); Protocol specification"
- IETF RFC 7959: "Block-Wise Transfers in the Constrained Application Protocol (CoAP)"
- IETF RFC 8610: "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures"

Example snippet supporting the difference highlighting: "The SEAL also provides a common framework for the management of network entities, such as policy control functions (PCFs), application servers, and other types of proxies, as well as the exposure of network capabilities and resources."

[TDoc C1-232628]:

- IETF RFC 6050: "A Session Initiation Protocol (SIP) Extension for the Identification of Services"
- 3GPP TS 24.546: "Configuration management - Service Enabler Architecture Layer for Verticals (SEAL); Protocol specification"
- 3GPP TS 23.434: "Service Enabler Architecture Layer for Verticals (SEAL); Functional architecture and information flows"
- 3GPP TS 24.547: "Identity management - Service Enabler Architecture Layer for Verticals (SEAL); Protocol specification"
- 3GPP TS 24.545: "Location Management - Service Enabler Architecture Layer for Verticals (SEAL); Protocol specification"
- IETF RFC 7959: "Block-Wise Transfers in the Constrained Application Protocol (CoAP)"
- IETF RFC 8610: "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures"

Example snippet supporting the difference highlighting: "The SEAL provides a modular and flexible architecture for the delivery of services and applications to vertical domains, which may have specific requirements in terms of functionality, performance, and security."

[TDoc C1-232629]:

- IETF RFC 6050: "A Session Initiation Protocol (SIP) Extension for the Identification of Services"
- 3GPP TS 24.546: "Configuration management - Service Enabler Architecture Layer for Verticals (SEAL); Protocol specification"
- 3GPP TS 23.434: "Service Enabler Architecture Layer for Verticals (SEAL); Functional architecture and information flows"
- 3GPP TS 24.547: "Identity management - Service Enabler Architecture Layer for Verticals (SEAL); Protocol specification"
- 3GPP TS 24.545: "Location Management - Service Enabler Architecture Layer for Verticals (SEAL); Protocol specification"
- IETF RFC 7959: "Block-Wise Transfers in the Constrained Application Protocol (CoAP)"
- IETF RFC 8610: "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures"

Example snippet supporting the difference highlighting: "The SEAL provides a modular and flexible architecture for the delivery of services and applications to vertical domains, which may have specific requirements in terms of functionality, performance, and security."

Technical Differences Among TDoc Snippets:

1. TDoc C1-232286:

- This TDoc discusses an abnormal case where a UE receives a MANAGE UE POLICY COMMAND message with a PTI set to the same value as a previously received message.
- In this case, the UE shall set the UE policy delivery service cause to #111 (Protocol error, unspecified) for the instruction in the UE policy section management result IE of the MANAGE UE POLICY COMMAND REJECT message.
- However, considering the network-initiated UE policy delivery procedure complete as a result of this abnormal case does not cause the UE to revert the execution of the instructions included in the MANAGE UE POLICY COMMAND message and successfully processed by the UE.

2. TDoc C1-232366:

- This TDoc discusses the substate 5GMM-DEREGISTERED.LIMITED-SERVICE, which is chosen in the UE when a selected cell for 3GPP access or TA for non-3GPP access is unable to provide normal service.
- This can occur if the selected cell over 3GPP access is in a forbidden PLMN or SNPN, is in a forbidden tracking area or TA for non-3GPP access is forbidden, or if the selected cell is a CAG cell for which none of CAG-ID(s) is authorized based on the "Allowed CAG list" in the entry of the "CAG information list" for the PLMN.
- Additionally, the selected cell is a non-CAG cell in a PLMN for which there exists an "indication that the UE is only allowed to access 5GS via CAG cells" in the entry of the "CAG information list" for the PLMN.

3. TDoc C1-232438:

- This TDoc discusses the presentation of CAG-ID authorization to the user for each presented CAG-ID, based on the "Allowed CAG list" stored in the UE.
- Additionally, it discusses the PLMN/access technology combination without a list of CAG-IDs, if there is an available NG-RAN cell which is not a CAG cell for the PLMN.
- This TDoc also covers the scenario where one or more PLMNs offering access to RLOS has been found, registration cannot be achieved on any PLMN, and the MS is in limited service state.

4. TDoc C1-232512:

- This TDoc discusses the encoding of network steering functionalities information, which contains addressing information for the ATSSS capable UE acting as the client for a functionality, and addressing and type information for the proxy for that functionality.
- The network steering functionalities information is either MPTCP network steering functionalities information or MPQUIC network steering functionalities information and is identified by ATSSS parameter identifier as encoded in table 6.1.2-1.
- This TDoc also covers the scenario where the UE indicates support for MPTCP functionality with any steering mode and the ATSSS-LL functionality with any steering mode, and the network accepts to enable these functionalities for an MA PDU session of IP type in the UPF as specified in the clause 5.32.2 of 3GPP TS 23.501.

Some examples from the original TDocs to support the differences highlighted above are:

- "The UE shall set the UE policy delivery service cause to #111 (Protocol error, unspecified) for the instruction in the UE policy section management result IE of the MANAGE UE POLICY COMMAND REJECT message." (TDoc C1-232286)
- "This can occur if the selected cell over 3GPP access is in a forbidden PLMN or SNPN, is in a forbidden tracking area or TA for non-3GPP access is forbidden, or if the selected cell is a CAG cell for which none of CAG-ID(s) is authorized based on the 'Allowed CAG list' in the entry of the 'CAG information list' for the PLMN." (TDoc C1-232366)
- "This TDoc discusses the presentation of CAG-ID authorization to the user for each presented CAG-ID, based on the 'Allowed CAG list' stored in the UE." (TDoc C1-232438)
- "The network steering functionalities information contains addressing information for the ATSSS capable UE acting as the client for a functionality, and addressing and type information for the proxy for that functionality." (TDoc C1-232512)

The first technical difference among the TDoc snippets is the DFType element, which indicates the type of the DF property. In TDoc C1-232014, the DFType is defined as MIME, specifically text/plain, while in TDoc C1-232155, the DFType is defined as DDFName.

Example from TDoc C1-232014:
text/plain

Example from TDoc C1-232155:



The second technical difference is the DFFormat element, which specifies the format of the data associated with the DF property. In TDoc C1-232014, the DFFormat is defined as bool, while in TDoc C1-232155, the DFFormat is defined as node.

Example from TDoc C1-232014:


Example from TDoc C1-232155:



The third technical difference is the Occurrence element, which defines how many times the DF property can occur within the parent node. In TDoc C1-232014, the Occurrence is defined as ZeroOrOne or OneOrMore, while in TDoc C1-232155, the Occurrence is defined as ZeroOrMore or One.

Example from TDoc C1-232014:


Example from TDoc C1-232155:



The fourth technical difference is the Scope element, which indicates the scope of the management object or parameter. In TDoc C1-232014, the Scope is defined as Dynamic, while in TDoc C1-232155, there is no Scope element defined.

Example from TDoc C1-232014:


Example from TDoc C1-232155:
N/A


The fifth technical difference is the content of the DFTitle element, which describes the purpose of the DF property. In TDoc C1-232014, the DFTitle describes the behavior of a timer for a specific use case, while in TDoc C1-232155, the DFTitle describes radio parameters and authorization for V2X communication.

Example from TDoc C1-232014:
Timer_T3245_Behaviour for a UE in the SNPN identified by the SNPN_identifier leaf

Example from TDoc C1-232155:
Radio parameters for V2X communication over PC5 when not served by E-UTRAN for V2X communication.

3GPP-C1-141-e    Agenda Item 18.3.1 : MCProtoc18

TDoc C1-232039:
- Participating MCPTT function rejects SIP MESSAGE request with SIP 404 (Not Found) response if public user identity and MCPTT ID binding not found or validity period of existing binding expired.
- SIP MESSAGE request for transfer private call requires element set to "transfer-private-call-request" and element to be present in requesting MCPTT user's MCPTT user profile document.

TDoc C1-232119:
- Participating MCVideo function rejects SIP MESSAGE request with SIP 404 (Not Found) response if public user identity and MCVideo ID binding not found or validity period of existing binding expired.
- element in application/vnd.3gpp.mcvideo-info+xml MIME body of SIP MESSAGE request must be set to "fa-group-binding-req" and element must be present in MCVideo user profile document.
- element contains URI with temporary group identity identifying the regroup.

TDoc C1-232120:
- Participating MCData function rejects SIP MESSAGE request with SIP 404 (Not Found) response if public user identity and MCData ID binding not found or validity period of existing binding expired.
- application/vnd.3gpp.mcdata-info+xml MIME body of SIP MESSAGE request containing element set to "store-comms-in-msgstore-ctrl-req" requires element to be present in MCData user profile document.
- element contains URI with temporary group identity identifying the regroup.

TDoc C1-232314:
- Implicit floor request indicated if required.
- element of element must be set to "true" in MCPTT user profile document for inclusion of element in application/vnd.3gpp.mcptt-location-info+xml MIME body.
- SIP INVITE request sent towards MCPTT server according to 3GPP TS 24.229.
- Private calls supported between two users.
- element in MCPTT user profile document must exist and be set to "true" for call forwarding feature.

Example snippets from TDoc C1-232039:
- "3) if the participating MCPTT function cannot find a binding between the public user identity and an MCPTT ID or if the validity period of an existing binding has expired, then the participating MCPTT function shall reject the SIP MESSAGE request with a SIP 404 (Not Found) response with the warning text set to '141 user unknown to the participating function' in a Warning header field as specified in clause 4.4, and shall not continue with the rest of the steps;"
- "4) if: a) the 'SIP MESSAGE request for transfer private call for originating participating MCPTT function' contains the element set to a value of 'transfer-private-call-request'; and b) if the element of the element is not present in the requesting MCPTT user's MCPTT user profile document (see the MCPTT user profile document in 3GPP TS 24.484"

Example snippets from TDoc C1-232119:
- "3) if the participating MCVideo function cannot find a binding between the public user identity and an MCVideo ID or if the validity period of an existing binding has expired, then the participating MCVideo function shall reject the SIP MESSAGE request with a SIP 404 (Not Found) response with the warning text set to '141 user unknown to the participating function' in a Warning header field as specified in clause 4.4, and shall not continue with any of the remaining steps;"
- "4) if the element in the application/vnd.3gpp.mcvideo-info+xml MIME body of the SIP MESSAGE request is set to a value of 'fa-group-binding-req' and: element of the element is not present in the MCVideo user profile document (see the MCVideo user profile document in 3GPP TS 24.484 The element shall contain a URI containing the temporary group identity identifying the regroup."

Example snippets from TDoc C1-232120:
- "3) if the participating MCData function cannot find a binding between the public user identity and an MCData ID or if the validity period of an existing binding has expired, then the participating MCData function shall reject the SIP MESSAGE request with a SIP 404 (Not Found) response with the warning text set to '141 user unknown to the participating function' in a Warning header field and shall not continue with any of the remaining steps;"
- "4) if the application/vnd.3gpp.mcdata-info+xml MIME body of the SIP MESSAGE request containing element set to a value of 'store-comms-in-msgstore-ctrl-req' and: a) the element of the element is not present in the MCData user profile document (see the MCData user profile document in 3GPP TS 24.484 The element shall contain a URI containing the temporary group identity identifying the regroup."

Example snippets from TDoc C1-232314:
- "16) if an implicit floor request is required, shall indicate this as specified in clause 6.4 and a) if the element of the element of the MCPTT user profile document identified by the MCPTT ID of the calling MCPTT user (see the MCPTT user profile document in 24.[50]) is set to a value of 'true', shall include an application/vnd.3gpp.mcptt-location-info+xml MIME body with a element included in the root element;"
- "17) shall send the SIP INVITE request towards the MCPTT server according to 3GPP TS 24.229"
- "1) the element exists in the MCPTT user profile document, and the value is set to 'true' (see the MCPTT user profile document in 3GPP TS 24.484"

Technical Differences among TDoc C1-232110 and TDoc C1-232112:

• TDoc C1-232110 deals with the SIP INVITE request for non-controlling MCPTT function of an MCPTT group, whereas TDoc C1-232112 is about SIP INVITE request for inviting a new MCPTT user to an MCPTT group.

• TDoc C1-232110 requires setting the Request-URI to the public service identity of the controlling MCPTT function based on the element received in the SIP INVITE request. In contrast, TDoc C1-232112 demands setting the Request-URI to the public service identity of the terminating participating MCPTT function associated with the MCPTT ID of the MCPTT user to be invited.

• TDoc C1-232110 mandates including the public service identity of the non-controlling MCPTT function in the P-Asserted-Identity header field, whereas TDoc C1-232112 requires an Accept-Contact header field containing the g.3gpp.mcptt media feature tag along with the "require" and "explicit" header field parameters according to IETF RFC 3841 and omits the refresher parameter.

• TDoc C1-232110 includes the Session-Expires header field according to rules and procedures of IETF RFC 4028, while TDoc C1-232112 does not have any such requirement.

• TDoc C1-232110 specifies that the public service identity can identify the controlling MCPTT function in the local MCPTT system or in an interconnected MCPTT system, whereas TDoc C1-232112 notes that the public service identity can identify the terminating participating MCPTT function in the primary MCPTT system or in a partner MCPTT system.

Example Snippets from TDoc C1-232110:

• "[9] in the SIP INVITE request"

• "shall set the Request-URI to the public service identity of the controlling MCPTT function based on the element received in the SIP INVITE request"

• "shall include the public service identity of the non-controlling MCPTT function in the P-Asserted-Identity header field"

• "should include the Session-Expires header field according to rules and procedures of IETF RFC 4028"

• "NOTE 1: The public service identity can identify the controlling MCPTT function in the local MCPTT system or in an interconnected MCPTT system."

Example Snippets from TDoc C1-232112:

• "shall set the Request-URI to the public service identity of the terminating participating MCPTT function associated to the MCPTT ID of the MCPTT user to be invited"

• "shall include an Accept-Contact header field containing the g.3gpp.mcptt media feature tag along with the "require" and "explicit" header field parameters according to IETF RFC 3841"

• "The refresher parameter shall be omitted"

• "if the received SIP INVITE request contained an application/vnd.3gpp.mcptt-info+xml MIME body containing an element and: a) if the Priv-Answer-Mode header field specified in IETF RFC 5373 [6]"

• "NOTE 1: The public service identity can identify the terminating participating MCPTT function in the primary MCPTT system or in a partner MCPTT system."

3GPP-C1-141-e    Agenda Item 18.3.3 : IMSProtoc18

3GPP-C1-141-e    Agenda Item 18.3.5 : MCOver5MBS

TDoc C1-232092:

- element contains sub-element for location reporting trigger.
- element has attribute with "Full" and "Update" values.
- AnyEXT elements available for the element.

TDoc C1-232093:

- sub-element available in element.
- element has , , , , and sub-elements with "Normal" type attributes and sub-elements for .
- element available for the element.

TDoc C1-232094:

- element contains sub-element for location reporting trigger.
- element has attribute with "Full" and "Update" values.
- AnyEXT elements available for the element.

Example from TDoc C1-232092:

- "The element contains the , and sub-elements, of which only one can be present."
- "The element contains the following sub-elements: I) , an optional element specifying what cell changes trigger location reporting."
- "The element contains the following sub-elements: a) , an optional element specifying what cell changes trigger location reporting."
- "AnyEXT elements for the Configuration element"

Example from TDoc C1-232093:

- " sub-element of the , element contains the unencrypted value of the MBSFN area the MCVideo is located in."
- "The 'type' attributes associated with the , , , , and sub-elements of the element have the value 'Normal' and the sub-elements of ."
- " element containing: a) an element where the sub-element is coded as in clause 6.3 in 3GPP TS 23.032"

Example from TDoc C1-232094:

- "The element contains the following sub-elements: a) , an optional element specifying what cell changes trigger location reporting."
- " element has a attribute that can assume the values 'Full' and 'Update'."
- "AnyEXT elements for the Configuration element."

Technical Differences Among TDoc C1-232091 and C1-232095:

TDoc C1-232091:

- Focuses on Mission Critical Services (MCS) configuration management, signalling control, group management, and identity management.
- Includes protocol specifications for MCS services.
- Covers functional architecture and information flows to support Mission Critical Data (MCData) Stage-2.
- References IETF RFC 4976 for relay extensions in the Message Session Relay Protocol (MSRP).
- References IETF RFC 6135 for an alternative connection model in MSRP.
- Includes Internet Protocol Version 6 (IPv6) specification.

Example snippets from TDoc C1-232091:

- "The present document specifies the stage 3 protocol specifications of Mission Critical Services (MCS) Configuration Management, which are independent of the access technology."
- "The present document specifies the stage 3 protocol specifications of Mission Critical Services (MCS) Signalling Control, which are independent of the access technology."
- "This TS specifies the stage 3 protocol specifications of Mission Critical Services (MCS) Group Management."
- "This TS specifies the stage 3 protocol specifications of Mission Critical Services (MCS) Identity Management."
- "TS 23.282 defines the functional architecture and information flows to support Mission Critical Data (MCData) Stage 2."
- "This document specifies the Relay Extensions for the Message Session Relay Protocol (MSRP), which is used for sending instant messages and other data in a multimedia communication session."

TDoc C1-232095:

- Focuses on Mission Critical Data (MCData) signalling control interworking with LMR systems.
- Includes protocol specifications for MCData services.
- References IETF RFC 4354 for a Session Initiation Protocol (SIP) event package and data format for push-to-talk over cellular service.
- References IETF RFC 6050 for a SIP extension for identification of services.
- References IETF RFC 4538 for request authorization through dialog identification in SIP.
- References IETF RFC 4412 for communications resource priority in SIP.
- Covers functional architecture and information flows to support Mission Critical Data (MCData) Stage-2.

Example snippets from TDoc C1-232095:

- "This TS specifies the protocol for Mission Critical Data (MCData) signalling control interworking with LMR systems."
- "This TS specifies the protocol for Mission Critical Data (MCData) services."
- "This document specifies an event package and data format for various settings in support of the Push-to-Talk over Cellular (PoC) service."
- "This document specifies a SIP Extension for the Identification of Services (IS) that allows users to be identified by what service they are using."
- "This document defines a mechanism for Request Authorization through Dialog Identification (RAID) in the Session Initiation Protocol (SIP)."
- "This document defines an extension to the Session Initiation Protocol (SIP) that enables the specification of priorities for communications resources."

3GPP-C1-141-e    Agenda Item 18.3.6 : eMCSMI_IRail

3GPP-C1-141-e    Agenda Item 18.3.8 : NG_RTC

TDoc C1-232100:

- Specifies provisions contained in referenced documents
- Distinguishes between specific and non-specific references
- Latest version of non-specific references applies
- Applies to 3GPP documents
- Defines scope clause for new specification
- Proposal to change 3GPP TS 24.186 to include scope

Example snippets: "The following documents contain provisions which, through reference in this text, constitute provisions of the present document." "In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document." "This p-CR provides content of scope for new TS 24.186."

TDoc C1-232101:

- Defines abbreviations and terms for new specification
- References 3GPP TR 21.905 for definitions
- Abbreviations and terms defined in present document take precedence

Example snippets: "For the purposes of the present document, the abbreviations given in 3GPP TR 21.905." "This p-CR provides content of definitions for the new 3GPP TS 24.186 specification." "An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 3GPP TR 21.905."

TDoc C1-232102:

- Specifies provisions contained in referenced documents
- Distinguishes between specific and non-specific references
- Latest version of non-specific references applies
- Applies to 3GPP documents
- Defines general description clause for new specification
- Proposal to change 3GPP TS 24.186 to include general description

Example snippets: "The following documents contain provisions which, through reference in this text, constitute provisions of the present document." "In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document." "This p-CR provides content of general description in clause 4 for new TS 24.186."

3GPP-C1-141-e    Agenda Item 18.3.9 : Other Rel-18 IMS & MC issues (TEI18)

3GPP-C1-141-e    Agenda Item 19 : Output Liaison Statements

TDoc C1-232045:

- The SOR counter and UE parameter update counter can be stored in EF5GAUTHKEYS or NVM.
- If Service n°133 is available in EFUST, these parameters can be stored in EF5GAUTHKEYS, otherwise they are stored in NVM.
- If the USIM is re-inserted in ME-1, outdated previously stored counters may be applied.
- The parameters stored in NVM are considered valid after power up if the stored SUPI is equal to the SUPI of the inserted USIM.
- New SOR messages may be ignored due to outdated counter values stored in NVM if the USIM has been used in a different ME-2 in the meantime.

Example snippet from TDoc C1-232045: "The parameters stored in NVM are considered as valid after power up, if the stored SUPI is equal to the SUPI of the inserted USIM."

TDoc C1-232227:

- UL NAS TRANSPORT message is used by the UE to carry "UP Positioning Initiation" to the AMF for the UE initiated user plane connection establishment.
- After taking other protocol details into account, CT1 agreed to use the SERVICE REQUEST message instead of the UL NAS TRANSPORT message to carry "UP Positioning Initiation" to the AMF.
- UL NAS TRANSPORT message is mainly used to transport the payload/container information which is transparent to the AMF.
- "UP Positioning Initiation" is not transparent to the AMF and is used by the AMF to perform LMF selection and request the LMF to set up the user plane connection.

Example snippet from TDoc C1-232227: "CT1 finally agreed the attached CR to use the SERVICE REQUEST message to carry 'UP Positioning Initiation' to the AMF for the UE initiated user plane connection establishment for user plane positioning."

TDoc C1-232396:

- The AMF is aware of the timer and the case for which the on-demand S-NSSAI needs to be de-registered.
- CT1 requests SA2 to remove the requirements on UE implementing the deregistration inactivity timer.
- UE behaviors on the de-registration inactivity timer are not necessary to specify.

Example snippet from the TDoc: "Note the AMF has been required to maintain the deregistration inactivity timer per on-demand S-NSSAI to achieve the network slice usage control."

TDoc C1-232444:

- The NAS layer forwards the S-NSSAI location availability information to the AS layer.
- The AS layer indicates whether the UE is inside or outside an NS-AoS to the NAS layer.

Example snippet from the TDoc: "Since the NAS layer of a UE has never handled cell-level information, CT1 agreed that: the NAS layer forwards the S-NSSAI location availability information to the AS layer."

TDoc C1-232521:

- CT1 thanks SA2 for the LS on re-establishment of the MBS context during mobility registration update or service request procedure.
- CT1 believes that how the SMF sends the MBS session related context information to the NG-RAN is in remit of SA2 and RAN3.

Example snippet from the TDoc: "CT1 has discussed the questions from SA2 and would like to provide the following answers: A1: CT1 believes that how the SMF sends the MBS session related context information to the NG-RAN is in remit of SA2 and RAN3."

TDoc C1-232246:
- CT1 discusses the handling of UPSI (User Plane Session Information) at the UE.
- Clarifies the UE behavior for the scenario where the PCF (Policy Control Function) provides a Policy Section that only contains PSI (Policy Set Identifier) and there is no Policy Section stored in the UE with that PSI.
- Two possible options were discussed, and CT1 agrees with Option A as logical UE behavior.
- The UE considers the policy instruction associated with the PSI not stored in the UE as an error and sends MANAGE UE POLICY REJECT.
- The UE discards the policy instruction associated with the PSI if there is no policy section content for the PSI in the MANAGE UE POLICY COMMAND and there is no corresponding PSI stored in the UE, and the UE shall not diagnose an error.

TDoc C1-232402:
- The UE includes multicast MBS (Multimedia Broadcast Service) session information container in the MM (Mobility Management) signaling.
- The current Rel-17 MBS multicast handling is based only on SM (Session Management) signaling.
- CT1 answers a question from SA2 regarding the possibility and desirability for the SMF (Session Management Function) to handle the procedure as described in the two solutions.
- The MBS session information is considered SM-related handling, and sending it in MM message breaks the design principle.

TDoc C1-232411:
- CT1 answers a scenario question by SA2 regarding how the UE reacts when the PCF provides a Policy Section that only contains PSI and there is no Policy Section stored in the UE with that PSI.
- If the UE checks first 1) then 2), then the UE will ignore the received UPSI.
- If the UE checks first 2) then 1), then the UE will ignore the received UPSI.

TDoc C1-232436:
- CT1 is working on stage 2 implementation for a stage 1 requirement.
- The HPLMN (Home Public Land Mobile Network) should provide the UE with prioritization information of the VPLMNs (Visited Public Land Mobile Networks) with which the UE may register for the network slice.
- CT1 answers questions from SA1 group regarding the requirement's implications and the possibility of multiple network slices being required for services/applications activated in a UE.

TDoc C1-232186:

- GSMA is asking for an explanation of the lack of checking of UE Additional Security Capabilities in specifications and the expected MME behavior in relation to invalid, unacceptable or missing 5GS security capabilities.
- CT1 thanks GSMA for their LS C1-230735 on potential 5G and 4G Bidding Down Attacks and states that mandatory security algorithms are defined in the SA3 specification and have not been changed for many releases.
- CT1 asks GSMA to consider their responses and review the reference to "mandatory" security capabilities when SA3 decides to change the set of mandatory security algorithms.
- CT1 believes it is convenient for implementation and testing to keep such a reference.

Example snippet from TDoc: "CT1 kindly asks GSMA to consider above responses into consideration. We can review the reference to “mandatory” security capabilities when SA3 decides to change the set of mandatory security algorithms. It is very convenient for implementation and testing to keep such a reference."

TDoc C1-232307:

- 5G security algorithm support is not required in EPS, but specific 5G security algorithms can be assessed and activated in parts of the network where they are used.
- The 5G security information is transparently transported in the network and can be assessed where used.
- CT1 agrees that MME is not mandated to check/verify UE indicated supported 5G security algorithms.
- CT1 has discussed "Finding 2 - Security Capabilities handling in MME" in their remit.

Example snippet from TDoc: "CT1 agrees that MME is not mandated to check/verify the UE indicated supported 5G security algorithms. CT1 has discussed “Finding 2 - Security Capabilities handling in MME” which is in CT1 remit and would like to provide the following feedback."