S2 Meeting #S2-148E DRAFT REPORT

15 - 22 November, 2021 - Electronic meeting

Source: Secretary of S2

Title: Draft Auto-Generated Report of S2 meeting #S2-148E

Document for: Information

Status: This Report Generated 24-11-2021, 09:23

# 0 Definitions

Noted: A document is "noted" to indicate that its content was made available to the meeting, but that the document itself was not agreed or endorsed by the meeting. Any agreements or actions resulting from discussion of the document are explicitly indicated in the meeting report.

Approved: A document "approved" in this report refers to the status within the WG. For some document types (e.g. CR, WID/SID), the final status of documents are determined at the TSG level, whereas this report always uses "approved", which may be translated in the 3GU document lists as "agreed" (e.g. for CRs).

Agreed (in parallel session): A document is "agreed" at a parallel or drafting session to indicate it's temporary status until the closing WG plenary sessions. The final status is determined in WG plenary sessions or via an e-mail approval process.

IPR Call Reminder:

The Chairman of the meeting made the following call for IPRs, and asked ETSI members to check the latest version of ETSI's policy available on the web server:

The attention of the delegates to the meeting of this Technical Specification Groupwas drawn to the fact that 3GPP Individual Members have the obligation underthe IPR Policies of their respective Organizational Partners to inform theirrespective Organizational Partners of Essential IPRs they become aware of.

The delegates were asked to take note that they were thereby invited:

- to investigate whether their organization or any other organization owns IPRs which wereor were likely to become Essential in respect of the work of 3GPP.

- to notify their respective Organizational Partners of all potential IPRs e.g. for ETSIby means of the IPR Information Statement and the Licensing declaration forms (https://www.3gpp.org/3gpp-calendar/89-call-for-ipr-meetings).

Antitrust declaration:

The Chairman of the meeting made the following Antitrust declaration:

The attention of the delegates to the meeting was drawn to the fact that 3GPP activities were subject to antitrust and competition laws and that compliance with said laws was therefore required by any participant of the meeting including the Chairman and Vice-Chairmen and were invited to seek any clarification needed with their legal counsel. The present meeting would be conducted with strict impartiality and in the interests of 3GPP. Delegates were reminded that timely submission of work items in advance of TSG/WG meetings was important to allow for full and fair consideration of such matters.

# 1.1 Opening of the meeting

Opening e-mail from the SA WG2 Chair:
Dear All,
This email is to kick off the SA2#148E e-meeting.
Please see the e-meeting deadlines below -
Revisions by 17 Nov 2021 (Wednesday) 1600 UTC
Final Comments 18 Nov 2021 (Thursday) 1600 UTC
Close of e-meeting 22 Nov 2021 (Monday) 1700 UTC
Upload Approved docs 23 Nov 2021 (Tuesday) 1700 UTC
The latest agenda is available here - https://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_148E_Electronic_2021-11/Agenda/S2-2108249_SA2-148E-Agenda_v4.zip
The latest Chair-s notes with UTC timestamp 11-15-0000 are available here - https://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_148E_Electronic_2021-11/INBOX/Chair_Notes
Please note the documents exceeding the quota will not be handled and are marked as NOT HANDLED in the Chair-s notes.
Please read the e-meeting process provided in S2-2108249 carefully and kindly follow it during the SA2#148E e-meeting.
Kind Reminder -
- Each email SHALL start with <<START>>/<<END>> tag as shown below
Tag Format:
Comment for notes <<START>>
YourName (YourCompanyName) <Comment for Chairman's Notes>
<<END>>
<comments to the document >
- Please ensure that tags are formatted correctly, including when you are copying/pasting tags from other emails.
Best regards,
Puneet

# 2 Agenda

TD S2-2108249 (AGENDA) SA WG2 #148E Meeting Agenda. (Source: SA WG2 Chair).
Document for: Approval.
Abstract: The meeting agenda.

Comment:

Approved.

Discussion and conclusion:

-

Status:

Approved.

# 2.1 IPR Call and Antitrust Reminder

See under Definitions, above

# 3 SA2#147E Meeting report

TD S2-2108250 (REPORT) Auto-Generated Report of SA WG2 meeting #147E. (Source: SA WG2 Secretary).
Document for: Approval.
Abstract: Auto-Generated Report of meeting S2#147E.

Comment:

Approved.

Discussion and conclusion:

-

Status:

Approved.

# 4 General

This agenda item was convened by Tao Sun (China Mobile).

# 4.1 Common issues and Incoming LSs

TD S2-2108251 (LS IN) LS from SA WG6: Reply LS on IP address to GPSI translation. (Source: SA WG6 (S6-211082)).
Document for: Action.
Abstract: SA WG6 thanks SA WG2 for the reply LS on IP address to GPSI translation. SA WG6 would like to express the following view for GPSI: On SA WG2's question #1: In SA WG6's understanding, although GPSI is a public identifier, a user may not be willing to share the GPSI with AFs in the form of MSISDN, due to its potential misuse (e.g. SMS spam). SA WG3 recognized this concern in their LS to SA WG6 and SA WG2 in S6-210012/ S2-2100044. On SA WG2's question #2 and #3: If GPSI is designed to be in the form of an External Identifier per AF and is also temporary (based on e.g. temporal validity or invalidated on a request by the subscriber), it will help in preventing the tracking of user's behaviour across AFs. Action: SA WG6 kindly requests SA WG2 and SA WG3 to consider the above information when designing the required features.

Comment:

Revision of S2-2106990 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

Tao(VC) suggest to NOTE this LS since there seems no specific action needed and be postponed for 3 meetings since May this year.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108256 (LS IN) Reply LS on IP address to GPSI translation. (Source: SA WG3 (S3-212355)).
Document for: Action.
Abstract: SA WG3 would like to thank SA WG2 for the LS reply on IP address to GPSI translation (S3-211392 / S2-2101307). SA WG2 asked in their LS that A GPSI can be either an MSISDN or an External Identifier. The GPSI in either form is used for the same purposes in the 5G System. SA WG2 would like to understand whether there would be different privacy considerations on sending external identifier to an AF possibly depending on if the GPSI takes the form of an MSISDN or an External Identifier. SA WG2 would also like to understand the following: 1. Are there privacy concerns (and do you see any difference) with exposing to an AF that may be external the GPSI in the form of MSISDN or the GPSI in the form of External Identifier? SA WG3 would like to inform SA WG2 and SA WG6 that SA WG3 sees some privacy issues with the usage of GPSI in the form of MSISDN. SA WG2 also asked the following follow-up questions: If the GPSI in either form does not meet the privacy requirements: 2. Should a new exposed subscription identifier be permanent or temporary? If such new exposed subscription identifier is temporary, what is its temporal validity? SA WG2 assumes that it is then up to the 5GC operator (e.g. NEF) to define this validity. SA WG3 has not yet concluded that the use of a temporary identifiers justifies the gain. SA WG2 is recommended to proceed with the use of permanent identifiers only at this stage for this feature. SA WG3 will inform SA WG2 if SA WG3 later concludes on the use of temporary identifiers and the desired properties of such temporary identifiers. 3. Should such new exposed subscription identifier be 'global' or per AF? SA WG3 agrees on that a mechanism to support 'GPSI per AF' helps to prevent possible tracking of users among AFs. SA WG3 would like to also inform SA WG2 and SA WG6 that SA WG3 considers that this LS reply also covers the issues raised in the Reply LSes (S3-211391 / S2-2009339) and (S3-211424 / S6-211082). Action: SA WG3 kindly asks SA WG2 and SA WG6 to take the above into account.

Comment:

Revision of S2-2107003 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

Tao(VC) suggest to NOTE this LS since there seems no specific action needed. It lasted in SA2 for 3 meetings and can be referred later on if needed.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108257 (LS IN) LS from GSMA 5GJA: LS on Traffic Categories in URSP. (Source: GSMA 5GJA (5GJA17_104)).
Document for: Action.
Abstract: GSMA NG 5GJA has profiled the use of URSP in GSMA PRD NG.114 and NG.113 based on the currently supported URSP functionality in 3GPP TS 23.503 and in 3GPP TS 24.526. GSMA NG 5GJA has discussed the need to support standardized and MNO-specific traffic categories in the traffic descriptor in URSP. Examples of traffic categories to be standardized are: - Enterprise: traffic from one or more applications related to Enterprise service - Gaming: traffic from one or more applications related to Gaming service, e.g., with low latency requirement - Video Streaming: traffic from one or more applications related to Video Streaming, e.g., HD video streaming, 4K video streaming Standardized traffic categories could be defined by 3GPP or by GSMA. MNO-specific traffic categories should be represented by a number of octets (flexible format to allow any string). A given traffic category can be used by more than one application simultaneously, and one application can simultaneously use more than one traffic category. Action: GSMA NG 5GJA kindly requests SA WG2 to consider the above requirements and to provide feedback to GSMA on how to support traffic categories.

Comment:

Revision of S2-2107006 from S2#147E. Response drafted in S2-2108979. Postponed.

Discussion and conclusion:

-

Status:

Postponed.

TD S2-2108979 (LS OUT) [DRAFT] Reply LS to GSMA NG 5GJA on Traffic Categories in URSP. (Source: Apple).
Document for: Approval.
Abstract: To: GSMA NG 5GJA. CC:

Comment:

Response to S2-2108257. Noted.

Discussion and conclusion:

-

e-mail discussion:

Haiyang (Huawei) provides r01
Krisztian (Apple) provides r02.
Chia-Lin (MediaTek) suggest to postpone LS
==== Revisions Deadline ====
Krisztian (Apple) proposes to send this LS as an interim update on the SA2 progress. SA2 can further update GSMA with new information, once available.
Tao (VC) check can we go with r02
Chia-Lin (MediaTek) still think no rush to send LS OUT to GSMA and sugges to send out a LS to SA to ask SA to handle this feedbeack to GSMA once SA has done with all the Rel-18 SID prioritization
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108268 (LS IN) LS from CT WG4: LS on creating a new stage 2 TS for SMS-SBI. (Source: CT WG4 (C4-214540)).
Document for: Action.
Abstract: According to LS (SP-191362 and CP-193301), CT WGs take responsibility for the study on service-based support for SMS in 5GC. CT WG4 has discussed the way for SBI-based SMS since CT WG4#99e, and has reached a consensus basically. But after discussion, CT WG4 believes that a new stage 2 TS for SMS-SBI should be created, where all SMS-SBI services and procedures are described in detail. CT WG4 would be glad to take the responsibility of this TS, based on the former studies on SMS-SBI. CT WG4 kindly ask SA WG2/CT WG1 to confirm the creation of a new stage 2 TS for SMS-SBI, and also CT WG4's responsibility of this TS. Action: CT WG4 kindly ask SA WG2/CT WG1 to confirm the creation of a new stage 2 TS for SMS-SBI, and also CT WG4's responsibility of this TS.

Comment:

Revision of S2-2107033 from S2#147E. Final response in S2-2109340.

Discussion and conclusion:

CC#2: A response LS was requested by Nokia to answer this LS. [S2-210xxxxr03 (LS reply to CT WG4 on new SMS SBI spec).zip] Huawei agreed that this issue had been discussed at the previous meeting and a response could be sent. CT WG1 should be moved to CC:. This was allocated to S2-2109340. Final response in S2-2109340.

e-mail discussion:

Tao(VC) asked people view whether we confirm this with response or we NOTE this LS.
==== Revisions Deadline ====
Hannu (Nokia) comments that CT4 depends on answers from the other groups, CT1 have already replied in S2-2108275 and SA2 DRAFT reply with similar contents was already shared but not processed due to lack of time in SA2 #147E. Hannu shares draft LS out that was already technically reviewed last time and proposes that a tdoc number should be assigned to it so that it can be handled in CC#2.
Leo (Deutsche Telekom) supports Nokia's proposal. SA2 should send a reply LS at this SA2 meeting. The version in the DRAFTS folder is fine and can be approved.
==== Comments Deadline ====
Hannu (Nokia) requests LS In S2-2108268 to be marked up for CC in order to assign a tdoc number for the proposed reply.

Status:

Replied to.

TD S2-2109340 (LS OUT) Reply LS on creating a new stage 2 TS for SMS-SBI. (Source: SA WG2).
Document for: Approval.
Abstract: To: CT WG4. CC: CT WG1.

Comment:

Created at CC#2. Response to S2-2108268. This LS was approved.

Discussion and conclusion:

CC#2: Created at CC#2. Response to S2-2108268. This LS was approved.

Status:

Approved.

TD S2-2108272 (LS IN) LS from RAN WG3: Reply LS on RACS capability detection with S1 and NG handover. (Source: RAN WG3 (R3-214373)).
Document for: Action.
Abstract: RAN WG3 thanks SA WG2 for their LS on RACS capability detection with S1 and NG handover. RAN WG3 has discussed the topic and will continue discussing solutions for Rel-17 to generalise the communication between target and source RAN node at handover via CN nodes regarding protocol support at the target RAN node. Action: RAN WG3 asks SA WG2 to take the above reply into account.

Comment:

Revision of S2-2107052 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

Alessio (Nokia): We propose to not this incoming LS. we have corresponding CR in AI#7.12 'Optimisations on UE radio capability signalling (RACS)'
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108275 (LS IN) Reply LS on creating a new stage 2 TS for SMS-SBI. (Source: CT WG1 (C1-216043)).
Document for: Information.
Abstract: CT WG1 thanks CT WG4 for the LS on creating a new stage 2 TS for SMS-SBI informing CT WG1 and SA WG2 of the CT WG4 preference to create a new stage 2 TS for SMS-SBI, where all SMS-SBI services and procedures are described in detail: CT WG4 kindly ask SA WG2/CT WG1 to confirm the creation of a new stage 2 TS for SMS-SBI, and also CT WG4's responsibility of this TS. CT WG1 discussed the CT WG4 proposal and agrees that a new stage 2 TS for SMS-SBI under CT WG4 responsibility should be created. Furthermore, CT WG1 expects that updates in 3GPP TS 23.040 for linkage between existing SMS stage 2 functionalities and the new TS for SMS-SBI will be needed and this will be done in the CT WG1 scope of SMS_SBI WI.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Hannu (Nokia) proposes to note the LS in.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108289 (LS IN) LS from ETSI TC LI: Reply LS on PSCELL ID availability in SGW CDR. (Source: ETSI TC LI (LI(21)P58049r1)).
Document for: Information.
Abstract: ETSI TC LI would like to thank SA WG5 for the LS (S5-214069) on PSCELL ID availability in SGW CDR replying to ETSI TC LI request in providing the same capability in allowing the CSPs to comply with the Retained Data Regulations. ETSI TC LI gladly confirms that the above added functionality fulfils the Retained Data related requirements by allowing the CSPs to have access to the PSCELL ID information at a later time.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Hannu (Nokia) proposes to note the LS in as there is no SA2 action remaining.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108291 (LS IN) LS from APT Wireless Group: APT REPORT ON EMERGING CRITICAL APPLICATIONS & USE CASES OF IMT FOR INDUSTRIAL, SOCIETAL AND ENTERPRISE USERS. (Source: APT Wireless Group (AWG28_OUT03 (Rev.1))).
Document for: Information.
Abstract: The AWG is developing a working document towards an APT Report on 'EMERGING CRITICAL APPLICATIONS & USE CASES OF IMT FOR INDUSTRIAL, SOCIETAL AND ENTERPRISE USERS' The scope of the report is on new/emerging critical applications and use cases of IMT-Advanced and IMT-2020 for industrial, societal and enterprise users, both 4G LTE and NR. Current draft working document being developed in the AWG is enclosed for reference. As SA WG6 (SA WG6) is the application enablement and critical communication applications group for critical applications of IMT, AWG would kindly invite the 3GPP to provide relevant materials, use cases and any other related material that would facilitate in completion of this Report. AWG would appreciate 3GPP to provide any feedback before the next 29th APT Wireless Group (AWG-29) meeting, scheduled in March/April 2022, if any. For technical queries please contact: Mr. Bharat Bhatia ITU-APT Foundation of India +91 9810173737 Email: Bharat.bhatia@itu-apt.org AWG will keep 3GPP informed of the progress and outcomes of relevant studies in future AWG meetings.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108293 (LS IN) LS from SA WG5: Reply LS to GSMA on new whitepaper E2E Network Slicing Architecture. (Source: SA WG5 (S5-215083)).
Document for: Information.
Abstract: SA WG5 would like to thank GSMA NG for their LS on New Whitepaper: 'E2E Network Slicing Architecture'. SA WG5 supports the intention of the whitepaper to show guidance of the entire industry ecosystem, for operators, vendors and service providers to be able to consider common solutions of network slicing. SA WG5 provides the following feedback on the whitepaper: - Regarding 2.4 SLA/SLS attributes for Network Slicing o Besides the alignment work of attributes between Service Profile in 3GPP TS 28.541 and GST NG.116 is proceeding at the present time, Service Profile can be translated to corresponding requirements for dedicated domains. For example, 5GC SliceProfile is used to carry 5GC domain requirements, NG-RAN SliceProfile is used to carry NG-RAN domain requirements, and TN requirements are translated and provided to TN domain. Please see 3GPP TS 28.541 for further information on the relation between GSMA GST, ServiceProfile and SliceProfile. - Regarding the figure of High level diagram of O&M domain in 5.4 O&M o Why is there TMF638 Inventory Mgmt illustrated in RAN Mgmt domain and CN Mgmt Domain? SA WG5 thinks the intent of TMF638 Inventory Mgmt API is to provide a consistent/standardized mechanism to query and manipulate the Service inventory in E2E Network & Service Mgmt Domain, not for a dedicated domain like RAN Mgmt domain or CN Mgmt domain. - Regarding the figure of 3GPP NRM for 5G network in 5.4.1 SA WG5 o JSON is listed as one kind of Solution Sets in the figure. However, in SA WG5 Rel-17 work, JSON has been replaced by YAML. 3GPP NRM Stage 3 Solution Sets are YAML and YANG.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Peter (Ericsson) propose to note the incoming LS
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108295 (LS IN) LS from SA WG6: LS on network slice management service consumption. (Source: SA WG6 (S6-212460)).
Document for: Information.
Abstract: The ongoing Rel-18 study in FS_NSCALE (TR 23.700-99) is investigating the services and functions of SA WG6 enablement layer to ensure the efficient network slice capability exposure. That needs SA WG6 enablement layer act as trusted 3rd party or consumer to invoke control and management plane capabilities from SA WG2 and SA WG5 pertaining to network slicing. SA WG6 would like to get clarification about the following related to the network slice management service: - Is SA WG5 planning to provide an interface to an AF for slice management by a trusted third-party?

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Peter (Ericsson) propose to note the incoming LS
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108312 (DISCUSSION) Discussion of Open-Source-Defined Multi-Access Edge Computing. (Source: Xidian University).
Document for: Discussion.
Abstract: Discusses the architecture and the principles of open-source-defined multi-access edge computing, include the network decoupling and reconfiguration of the network functions and resources.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Juan Zhang (Qualcomm) clarifies that the discussion paper was not from Qualcomm.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108986 (DISCUSSION) NRF Profile documentation. (Source: Nokia, Nokia Shanghai-Bell).
Document for: Discussion.
Abstract: NRF Profile documentation.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Josep (DT) prefers option 2.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108384 (DISCUSSION) Documentation Handling on NF profile.. (Source: Ericsson).
Document for: Agreement.
Abstract: This paper proposes to capture the parameters of NF profile in 23.502 and provide a reference to 23.502 in clause 6.2.6.2 of 23.501.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108385 (CR) 23.501 CR3369 (Rel-17, 'F'): Documentation handling for description of NF profile. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: Add a note that additional parameters in the NF profile, refer to clause 5.2.7.2.2 of TS 23.502.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Josep (DT) thinks that this is a bad idea. Option 2 in 8986 is a better way.
Judy (Ericsson) asks Josep (DT) for clarification and comments
Josep (DT) replies.
Shabnam (Ericsson) replies
Josep (DT) replies. Better current duplication than partial duplication
Judy (Ericsson) provides r01 and comment
Devaki (Nokia) objects to the CR and its revisions. This CR is basically introducing text to state that the section is 'incomplete' thus unnecessary, furthermore, it disregards NF registration using OA&M.
Judy (Ericsson) is not sure how Devaki (Nokia) concludes 'the section is 'incomplete' thus unnecessary'. The intent of the CR is to state that 6.2.6 is incomplete, and we complete it trying to avoid duplication. Please see a revision in r02 and request Devaki (Nokia) to reconsider.
==== Revisions Deadline ====
Devaki (Nokia) comments that the crux of our concern is in the statement quoted by Judy 'The intent of the CR is to state that 6.2.6 is incomplete' (as our preference is to complete it), open to rediscuss the split between different specs until January meeting.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108386 (CR) 23.502 CR3135R1 (Rel-17, 'F'): SMF+PGW-C assigned PDU Session ID. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: View-1 is assumed: Add a note the scenario of SMF+PGW-C assigning same PDU Sessions for muultiple PDN connection is not seen in real deployment. .

Comment:

Revision of (Postponed) S2-2107164 from S2#147E. Source to WG incorrect. CC#2: Noted.

Discussion and conclusion:

CC#2: Ericsson commented that two solution had been discussed and would like to try to set a working agreement. This was detailed in a slide: S2-2108386-working assumption.pptx
https://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_148E_Electronic_2021-11/INBOX/CCs/CC%232_2021-11-19_1330UTC/S2-2108386-working%20assumption.pptx
Scenario example:
- UE establishes PDN connection-1 towards APN1 via MME, default EBI is 5, and SMF+PGW-C allocated PSID 69 (PSID = default EBI + 64);
- UE handovers PDN connection-1 to EPC/ePDG, MME release the EBI of PDN. PSID 69 continues to be used;
- UE then establishes PDN connection-2 towards APN2 via MME, MME may assign EBI 5 to default bearer. SMF+PGW-C also allocated PSID 69 (PSID = default EBI + 64); This cause PSID collision
Proposals
- Option-A: 8386r07: At PDN connection establishment, SMF+PGW-C first checks with UDM for PDU Session ID(s) registered for the UE
- Option-B: 8386r00: Do thing, (adding a note that the scenario is not seen in deployments)
Support for Option A: S2-2108386r07: 10
Objections: 2
Support for Option B: S2-2108386r00: 5
Objections: 4
S2-2108386 was then noted.

e-mail discussion:

Judy (Ericsson) provide r01 based on the discussion in 8267 thread.
Susan (Huawei) provides comments.
Irfan (Cisco) raises technical concern with r01.
Zhendong (ZTE): provides response.
Irfan (Cisco) retracts his previous comment on r01.
Zhendong (ZTE): provides r02
Susan (Huawei) replies to Zhendong (ZTE).
Irfan (Cisco) provides r03
Laurent (Nokia): provides r04
Judy (Ericsson) provide r05
Zhendong (ZTE): provides r06
Zhendong (ZTE): provides r07
Susan (Huawei) objects to all revisions of this CR, i.e. r01 to r07, can accept the original one.
Laurent (Nokia): answers
==== Revisions Deadline ====
Tao(VC) check whether r00 agreeable or not.
Judy (Ericsson) accepts r00, r01, r02, r05, r07 and object to other revisions, and responds to Laurent (Nokia)
Irfan (Cisco) accepts r07
Sebastian (Qualcomm) objects to r00
Sebastian (Qualcomm) proposes to establish a WA based on r07 in CC#2
Zhendong (ZTE): accept r07
Laurent (Nokia): supports a WA at CC2 based on R07
Judy (Ericsson) responds to Laurent (Nokia)
==== Comments Deadline ====
Zhuoyi (China Telecom) proposes to postpone this CR.
Irfan (Cisco) proposes to atleast technically endorse r07.

Status:

Noted.

TD S2-2108412 (CR) 23.501 CR2385R6 (Rel-17, 'C'): Support of the mapping from IP addressing information provided to an AF to the user identity. (Source: [Nokia, Nokia Shanghai Bell], Ericsson).
Document for: Approval.
Abstract: Summary of change: In this case the 5GC first needs to retrieve the Permanent identifier of the UE before trying to fulfil the AF request. The 5GC may need to determine the Permanent identifier of the UE based on: the UE address as provided by the AF, the corresponding DNN and/or S-NSSAI information: this may have been provided by the AF or determined by the NEF using the identity of the AF;

Comment:

Revision of (Postponed) S2-2107653 from S2#147E. r05 agreed. Revised to S2-2109140, merging S2-2108923.

Discussion and conclusion:

-

e-mail discussion:

Laurent (Nokia): provides r01
Dario (Qualcomm) privides r02
Magnus O (Ericsson) provides r03
Jari (NTT DOCOMO) questions for clarification
Saso (Intel) seeks clarification on UE address.
Magnus O (Ericsson) provides r04
Jari (NTT DOCOMO) comments
Magnus O (Ericsson) replies
Laurent (Nokia): answers and provides r05
Magnus O (Ericsson) is fine with r05
==== Revisions Deadline ====
Dario (Qualcomm) is OK with r05
Hui (Huawei) is OK with r05
==== Comments Deadline ====.

Status:

Revised to S2-2109140, merging S2-2108923.

TD S2-2109140 (CR) 23.501 CR2385R8 (Rel-17, 'C'): Support of the mapping from IP addressing information provided to an AF to the user identity. (Source: Nokia, Nokia Shanghai Bell, Ericsson).
Document for: Approval.
Abstract: Summary of change: In this case the 5GC first needs to retrieve the Permanent identifier of the UE before trying to fulfil the AF request. The 5GC may need to determine the Permanent identifier of the UE based on: the UE address as provided by the AF, the corresponding DNN and/or S-NSSAI information: this may have been provided by the AF or determined by the NEF using the identity of the AF;

Comment:

Revision of S2-2108412r05, merging S2-2108923. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108413 (CR) 23.502 CR2926R3 (Rel-17, 'B'): AF specific UE ID retrieval. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: A new procedure is added for the AF to retrieve the AF specific GPSI (in the form of external id as defined in TS 23.003). The Event Exposure and Parameter Provisioning (targetting an individual) UE are updated to support requests with UE addressing information.

Comment:

Revision of (Postponed) S2-2107248 from S2#147E. r06 agreed. Revised to S2-2109141, merging S2-2108924.

Discussion and conclusion:

-

e-mail discussion:

Laurent (Nokia): provides r01
Magnus O (Ericsson) comments
Saso (Intel) seeks clarification on UE address.
Dario (Qualcomm) provides r02 and asks further questions.
Hyesung (Samsung) provides r03 and asks questions.
Magnus O (Ericsson) provides r04
Jari (NTT DOCOMO) comments
Magnus O (Ericsson) replies
Dario (Qualcomm) provides r05
Saso (Intel) comments.
Laurent (Nokia): provides r06 = r05+ support of MAC address
Florin(Broadcom) supports having the support for the MAC address and as a result r06 provided by Laurent.
Magnus O (Ericsson) is fine with r06
Hui (Huawei) fine with supporting MAC address.
==== Revisions Deadline ====
Laurent (Nokia): I have concerns with not supporting MAC address and thus prefers MUCH r06 wrt R04 or R05
Hyesung (Samsung) is fine with r04, r05, 06
Dario (Qualcomm) is OK with r06
==== Comments Deadline ====.

Status:

Revised to S2-2109141, merging S2-2108924.

TD S2-2109141 (CR) 23.502 CR2926R4 (Rel-17, 'B'): AF specific UE ID retrieval. (Source: Ericsson, Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: A new procedure is added for the AF to retrieve the AF specific GPSI (in the form of external id as defined in TS 23.003). The Event Exposure and Parameter Provisioning (targetting an individual) UE are updated to support requests with UE addressing information.

Comment:

Revision of S2-2108413r06, merging S2-2108924. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108267 (LS IN) LS from CT WG3: LS on PDU Session ID assignment for the Interworking scenario. (Source: CT WG3 (C3-214527)).
Document for: Action.
Abstract: CT WG3 is studying an issue of PDU Session ID assignment in the following scenario: 1) UE firstly establishes a PDN connection via MME and MME assigns a Default EPS bearer ID1 to the PDN connection. The SMF+PGW-C will calculate a PDU Session ID1 with the value of 64 + Default EPS bearer ID1 according to Table 5.4.2-1 of TS 29.571, e.g. if Default EPS bearer ID is 5, then the calculated PDU Session ID1 is 69. And then the SMF+PGW-C sends the PDU Session ID1 to the PCF as a parameter to identify the PDU session for the SUPI, DNN and S-NSSAI. 2) UE handovers to the ePDG and the ePDG assigns a new Default EPS bearer ID2. The Default EPS bearer ID2 may be the same as the Default EPS bearer ID1 or different from the Default EPS bearer ID1. CT WG3 understands the SMF+PGW-C doesn't calculate a new PDU session ID, since there is no explicit requirement to do so. 3) UE may establish an additional PDU connection to the same DNN and S-NSSAI via MME while the UE keeps the PDN connection via ePDG. As the MME may assign the same value of Default EPS bearer ID3 as the Default EPS bearer ID1, the SMF+PGW-C would allocate the same PDU session ID3 as the PDU session ID1 (i.e. the Default EPS bearer ID3 is 5, and the PDU Session ID3 will be 69). When the SMF+PGW-C sends the PDU Session ID3 to the PCF, PCF can't identify this is a different PDU Session than PDU Session ID1 and may reject the request from the SMF+PGW-C incorrectly. CT WG3 would like to ask the following questions to SA WG2: Question 1: Is it correct understanding that SMF+PGW-C doesn't calculate a new PDU session ID at UE handover from MME to ePDG, and vice-versa? Question 2: If answer to Q1 is yes, how to resolve the issue raised in bullet 3)? Question 3: If answer to Q1 is no, can the SMF+PGW-C update the PDU session ID to the PCF with new calculated value?. Action: CT WG3 kindly asks SA WG2 to answer the questions above and amend the SA WG2 specifications accordingly, where appropriate.

Comment:

Revision of S2-2107031 from S2#147E. Responses drafted in S2-2108589 and S2-2108853. Postponed.

Discussion and conclusion:

-

e-mail discussion:

Judy (Ericsson) follows Zhendong suggestion to use this thread to discuss different proposals (in e.g. 8486, 8591 and 8386).
Zhendong (ZTE): provides the response
Judy (Ericsson) responds to Zhendong (ZTE).
Zhendong (ZTE): provides the repsonse
Zhendong (ZTE): ask for clarification
Susan (Huawei) provides comments.
Laurent (Nokia): Comments
Irfan (Cisco) comments, supports UDM based approach
Sebastian (Qualcomm) comments that the scenario at hand is realistic and supports a UDM based approach
Judy (Ericsson) provide r01 based on the discussion in 8267 thread.
Zhendong (ZTE): provides clarification
Zhendong (ZTE): provides comments.
Judy (Ericsson) clarifies
Zhendong (ZTE): provides response
Judy (Ericsson) asks Tao (chair) to ignore r01 which is not intended for this paper (but for 8386), and responds to Zhendong (ZTE).
Zhendong (ZTE): respond to judy
Susan (Huawei): Cannot agree with the UDM based solution.
Judy (Ericsson) responds to Susan (Huawei)
Susan (Huawei) responds to Judy (Huawei)
Laurent (Nokia): we can easily live with Judy's approach !!
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Postponed.

TD S2-2108589 (LS OUT) [DRAFT] Reply LS on PDU Session ID assignment for the Interworking scenario. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Reply LS on PDU Session ID assignment for the Interworking scenario to CT WG3.

Comment:

Revision of (Postponed) S2-2107485 from S2#147E. Response to S2-2108267. Noted.

Discussion and conclusion:

-

e-mail discussion:

Laurent (Nokia): Objects to any revision of this Tdoc
Zhendong (ZTE): simillar concern,and propose to discuss in 8267
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108853 (LS OUT) [DRAFT] LS on PDU Session ID assignment for the Interworking scenario. (Source: Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: [draft] LS on PDU Session ID assignment for the Interworking scenario.

Comment:

Response to S2-2108267. Noted.

Discussion and conclusion:

-

e-mail discussion:

Judy (Ericsson) prepared two revisions: r01 replies with a solution, and r02 replies that no consensus reached on the solution
==== Revisions Deadline ====
Tao(VC) check whether r01 or r02 agreeable based on the discussion under 8267
Judy (Ericsson) assumes we can go for r01 if any revision of 8386 can be agreed, otherwise r02 if we don't want to delay the response further.
Tao(VC) let's check r01 agreeable or not then
Sebastian (Qualcomm) is ok with r01 but objects to r02; we need to solve this issue
Zhendong (ZTE): agree with r01
Susan (Huawei) is ok with r02, object to r01 unless r00 of S2-2108386 can be agreeable.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108486 (CR) 23.502 CR3249 (Rel-17, 'F'): PDU Session ID assignment for non N1-NAS UEs. (Source: Cisco Systems, Nokia, Nokia Shanghai Bell, ZTE).
Document for: Approval.
Abstract: Summary of change: The UDM assigns PDU Session ID for UEs that do not support N1 NAS and are anchored on SMF+PGW-C.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Judy (Ericsson) has major concern on the proposal that UDM allocate PDU Session ID, explained
Zhendong (ZTE): propose to discuss in the 8267
==== Revisions Deadline ====
Susan (Huawei) objects to this CR.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108497 (DISCUSSION) Discussion and proposal on PDU session ID issue in CT WG3 LS.. (Source: ZTE, Nokia, Nokia Shanghai Bell, Cisco Systems).
Document for: Discussion.
Abstract: This discussion paper discusses the issue raised by CT WG3 LS, analyses the potential solution, and give the proposal.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108590 (DISCUSSION) Discussion on PDU Session ID assignment for interworking scenario.. (Source: Huawei, HiSilicon).
Document for: Agreement.
Abstract: This discussion paper aims at comparing solutions for resolving PDU Session ID conflict in interworking scenario and proposing way forward.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108591 (CR) 23.502 CR3190R1 (Rel-16, 'F'): Correction on PDU Session ID assignment by SMF+PGW-C. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: SMF+PGW-C updates the allocated PDU Session ID for the UE that does not support 5GC NAS when the PDN connection handovers between 3GPP access and Non-3GPP access.

Comment:

Revision of (Postponed) S2-2107486 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

Laurent (Nokia): Objects to any revision of this Tdoc
Zhendong (ZTE): simillar concern, and propose to discuss in 8267
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108592 (CR) 23.502 CR3191R1 (Rel-17, 'A'): Correction on PDU Session ID assignment by SMF+PGW-C. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: SMF+PGW-C updates the allocated PDU Session ID for UE that does not support 5GC NAS when the PDN connection handovers between 3GPP access and Non-3GPP access.

Comment:

Revision of (Postponed) S2-2107487 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

Laurent (Nokia): Objects to any revision of this Tdoc
Zhendong (ZTE): simillar concern, and propose to discuss in 8267
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108923 (CR) 23.501 CR2385R7 (Rel-17, 'F'): Support of the mapping from IP addressing information provided to an AF to the user identity. (Source: Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: In this case the 5GC first needs to retrieve the Permanent identifier of the UE before trying to fulfil the AF request. The 5GC may need to determine the Permanent identifier of the UE based on: the UE address as provided by the AF, the corresponding DNN and/or S-NSSAI information: this may have been provided by the AF or determined by the NEF using the identity of the AF;

Comment:

Revision of (Postponed) S2-2107653 from S2#147E. Merged into S2-2109140.

Discussion and conclusion:

-

e-mail discussion:

Laurent (Nokia): asks 8923 (my Tdoc) to be merged in 8412
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Merged into S2-2109140.

TD S2-2108924 (CR) 23.502 CR2329R5 (Rel-17, 'F'): Support of the mapping from IP addressing information provided to an AF to the user identity. (Source: Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: An AF may request (via the NEF) information exposure or parameter provisioning targetting an individual UE, identifying the target UE by providing UE addressing information. In this case the 5GC (NEF) first needs to retrieve a Permanent Identifier of the UE Then the NEF Event exposure or the parameter provisioning may apply as defined in R16. Nnef_EventExposure_Subscribe, Nnef_Location_LocationUpdateNotify and Nnef_ParameterProvision operations are modified accordingly. The NEF may deliver back to the AF an UE external Identifier for an Application. This UE external Identifier for an Application may later on be used by the AF to issue further requests about the same UE.

Comment:

Revision of (Postponed) S2-2107654 from S2#147E. Merged into S2-2109141.

Discussion and conclusion:

-

e-mail discussion:

Magnus O (Ericsson) propose to merge into 8413
Laurent (Nokia): Oups I forgot to tell my willingness to merge, yes ok to merge
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Merged into S2-2109141.

TD S2-2108296 (LS IN) LS from GSMA NRG: LS from NRG to 3GPP on Emergency Communication Improvement. (Source: GSMA NRG (NRG_012_200)).
Document for: Information.
Abstract: Legal authorities are requesting Mobile operators to provide access to emergency services through emergency communication also to roamers regardless of the used service (Voice, SMS , video,-). European Commission is mandated to adopt a Delegated Act to ensure effective access to emergency services through emergency communications, defining major improvements regarding emergency communication. The Delegated Act should be adopted by 21 December 2022. A consultation activity will be held between October and December 2021. The objective of the initiative is to ensure that regardless of the means of emergency communications - calls, SMS, application, real time text, video - end-users benefit from effective access to emergency services, everywhere in EU, especially in roaming conditions. Major improvements regarding emergency communication are listed below: 1. Access to emergency services through emergency communications to the most appropriate PSAP should be ensured. The scope of emergency communications could be broadened from voice to SMS, video and other types of interpersonal communication services. Emergency communications should be free of charge for end-users. More effective emergency communications would allow reliable and efficient access to the most appropriate PSAP, shorter call processing times and enable shorter 'on scene' arrival times of emergency services. 2. Ensure equivalent access to emergency services for end-users with disabilities throughout the EU (including roaming cases), coherent implementation of accurate and reliable caller location and adaptation of routing protocols to an all-IP environment. 3. The caller location is the single most essential contextual data; the more accurate the localisation, the swifter the emergency intervention can be. New technologies or mixes of technologies allow more accurate and reliable caller location that should be available both in domestic and cross border (roaming) context. Delivery of both network-based and handset-derived caller location should be delivered without delay to the most appropriate PSAP. More information could be read using the following link: https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/13183-Emergency-communications-improving-access-through-the-single-European-emergency-number-'112'_en. Proposed axis of improvement Based on EU request (and other local authorities), GSMA NG/NRG believes that emergency services could be improved on the following aspects: - Service extension: Emergency should be accessible regardless of the service used (voice, SMS, video, ,-). - Roaming extension: All emergency services shall be provided and supported in roaming conditions, and routed to the appropriate PSAP directly by the visited network (tromboning via the home network should be avoided). - Location improvement: Caller location should be improved, using in a standard way the terminal and network location. Requests: GSMA NG/NRG requests 3GPP to study the following questions related to the 3 axis (service, coverage, location) : - Service extension: Emergency service should be enhanced to SMS (specially for end-users with disabilities). Is it possible to define a standard emergency SMS service using IMS for example? - Roaming extension: Emergency service should be available in roaming condition. Is it possible to use data LBO for all standard emergency services (voice, SMS, video,), in order to connect to the visited PSAP ? - Location improvement: Caller location should be provided whatever the service (voice, SMS, video), whatever the coverage (domestic, roaming), using in a standard way the terminal and network location. Is it possible to standardise more in detail terminal location provided to PSAP, typically like AML (Advanced Mobile Location) solutions ? GSMA NG/NRG requests 3GPP to study the 2 following service evolutions: - Emergency service should be enhanced to SMS (in R18), - AML should be integrated in 3GPP spec in further releases.

Comment:

Response drafted in S2-2108981. Noted.

Discussion and conclusion:

-

e-mail discussion:

Leo (Deutsche Telekom) proposes to Note the incoming LS.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108981 (LS OUT) [DRAFT] Reply LS on Emergency Communication Improvement. (Source: Orange).
Document for: Approval.
Abstract: Reply to GSMA NRG on Emergency Communication Improvement.

Comment:

Response to S2-2108296. Noted.

Discussion and conclusion:

-

e-mail discussion:

Leo (Deutsche Telekom) proposes to Note this reply LS.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108980 (SID NEW) New WID on Study on Emergency Short Message Service .. (Source: Orange).
Document for: Approval.
Abstract: Per request from GSMA (S2-2108296), study the architectural evolutions of the 3GPP System to support Emergency SMS, based on the requirements specified in TS 22.101 during SA WG1#96-e.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Antoine (Orange) proposes to Note this WID.
Leo (Deutsche Telekom) agrees to Note this WID.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2109006 (LS IN) LS from RAN WG3: LS On Source IP address clarifications . (Source: RAN WG3 (R3-216139)).
Document for: Information.
Abstract: RAN WG3 is carrying out work to support ACL in NG-RAN. A definition of the ACL functionality can be found in TS36.413 and it is reported below for convenience: ACL functionality: A functionality controlling the access to network nodes. In case of Access Control Lists (ACL) functionality is applied in a network node the network node may only accept connections from other peer network nodes once the source addresses of the sending network node is already known in the target node. As part of the work on ACL, RAN WG3 needs to specify how to signal the source IP address(es) used for DL forwarding traffic within one GTP-U tunnel. In order for RAN WG3 to progress, RAN WG3 would like to ask CT WG4 whether DL forwarding traffic contained within a GTP-U DL forwarding tunnel can be transmitted by more than one source IP address.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2109007 (LS IN) LS from RAN WG3: Reply to Reply LS On ACL support for Indirect Data Forwarding . (Source: RAN WG3 (R3-216140)).
Document for: Action.
Abstract: RAN WG3 thanks SA WG2 for the reply LS on ACL support Indirect Data Forwarding. SA WG2 asked RAN WG3 to provide their view on whether the source address for a normal Iu-U/N3 tunnel (for example, during Service request procedure from CM_IDLE to CM_CONNECTED) needs to be provided to RAN for ACL support or it can be made aware to RAN by other means. RAN WG3 discussed this use case and agreed that the source address for a normal Iu-U/N3 tunnel may be configured at the RAN. Hence this use case is considered of lower priority and a solution for it is not needed. RAN WG3 would like to point out that the case of indirect data forwarding is different because the UP GW responsible for data forwarding may be different from the UP GW serving the Iu-U/N3 tunnel. RAN WG3 would like to ask SA WG2 to confirm whether this understanding is correct and whether the UP GW selection for data forwarding is subject to any limitations. Action: RAN WG3 kindly asks SA WG2 to take the above into account.

Comment:

Postponed.

Discussion and conclusion:

-

e-mail discussion:

Qian (Ericsson) proposes to POSTPONE the paper since no action can be agreed.
==== Comments Deadline ====.

Status:

Postponed.

TD S2-2109010 (LS IN) LS from RAN WG3: Reply LS on Guidelines on Port Allocation for New 3GPP Interfaces. (Source: RAN WG3 (R3-216233)).
Document for: Information.
Abstract: RAN WG3 thanks CT WG4 for the latest information and status report on the port number allocation solutions. Solutions #1-4, 8 all have varying impacts on implementations and/or deployments, and have dependencies on the operator's infrastructure, including transport infrastructure. In general, they are not considered feasible. Solutions #3, 5 which affect the transport network layer, including SCTP, are also unfeasible. RAN WG3 prefers not to impact transport layer implementations, given that SCTP is today the basis for all RAN WG3-defined interfaces. We acknowledge the possible drawback of Solution #6, as described in Sec. 4.4.3 of TR 29.941. RAN WG3 understands that implementations are responsible for resolving any collisions. We would ask CT WG4 to keep us informed of any updates on this. RAN WG3 confirms that static port number allocation by 3GPP (Solution #6 in TR 29.941) and port allocation via OAM (Solution #7 in TR 29.941) shall be the way forward.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

# 4.2 P-CRs/CRs related to use of inclusive language in 3GPP

TD S2-2108884 (CR) 23.501 CR3313R2 (Rel-17, 'F'): Corrections on TSCTSF selection and residence time calculation. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Align the description between H.2 and clause 5.27.1.2.2.2 to clarify the suffix is added/deleted to both Sync message for one-step operation and Follow_Up message for two-step operation. Correct the reference and clarify the calculating of residence time in UE2UE scenario.

Comment:

Revision of (Agreed) S2-2108138 from S2#147E. Approved.

Discussion and conclusion:

-

Status:

Agreed.

# 5 Pre-Rel-17 Maintenance (excluding all 5G topics)

This agenda item was convened by Andy Bennett (Samsung).

# 5.1 3GPP Packet Access Maintenance

TD S2-2108352 (CR) 23.032 CR0020 (Rel-16, 'F'): Introducing new high accuracy GAD shape with scalable uncertainty. (Source: Ericsson, T-Mobile USA).
Document for: Approval.
Abstract: Summary of change: Introducing two high accuracy GAD shapes where uncertainty range can be configured to align with existing shapes or align with uncertainty ranges of LPPe.

Comment:

r03 agreed. Revised to S2-2109024.

Discussion and conclusion:

-

e-mail discussion:

Guillaume (MediaTek Inc.) provides r01.
Richard (Ericsson) provides r02.
Richard (Ericsson) provides r03.
==== Revisions Deadline ====
Stephen (Qualcomm) comments the r03 is fine with us
==== Comments Deadline ====.

Status:

Revised to S2-2109024.

TD S2-2109024 (CR) 23.032 CR0020R1 (Rel-16, 'F'): Introducing new high accuracy GAD shape with scalable uncertainty. (Source: Ericsson, T-Mobile USA).
Document for: Approval.
Abstract: Summary of change: Introducing two high accuracy GAD shapes where uncertainty range can be configured to align with existing shapes or align with uncertainty ranges of LPPe.

Comment:

Revision of S2-2108352r03. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108353 (CR) 23.032 CR0021 (Rel-17, 'A'): Introducing new high accuracy GAD shape with scalable uncertainty. (Source: Ericsson, T-Mobile USA).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: Introducing two high accuracy GAD shapes where uncertainty range can be configured to align with existing shapes or align with uncertainty ranges of LPPe.

Comment:

r00 agreed. Revised to S2-2109025.

Discussion and conclusion:

-

e-mail discussion:

Guillaume (MediaTek Inc.) provides r01.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109025.

TD S2-2109025 (CR) 23.032 CR0021R1 (Rel-17, 'A'): Introducing new high accuracy GAD shape with scalable uncertainty. (Source: Ericsson, T-Mobile USA).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: Introducing two high accuracy GAD shapes where uncertainty range can be configured to align with existing shapes or align with uncertainty ranges of LPPe.

Comment:

Revision of S2-2108353r00. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108767 (CR) 23.303 CR0330R1 (Rel-17, 'F'): TS 23.303 corrections discovered when working on 5G ProSe. (Source: Nokia, Nokia Shanghai Bell, LG Electronics).
Document for: Approval.
Abstract: Summary of change: In clause 5.1.1.5.2, figure# is corrected. There are no references to this Fig. In clause 5.1.2.2, the EN is removed. In clause 5.4.4.3, the message names in the description part are aligned with ones in Figure 5.4.4.3-1. In clause 5.4.4.5, the message name is corrected. In clause 5.4.5.4, reference is corrected to point to Figure 5.4.5.4-1. In clause 5.6.2, reference is corrected to point to Figure 5.6.2-1. In clause B.1, figure# is corrected. There are no external references outside of clause B.1 to this figure. - This CR includes the clauses not referred by TS 23.304, so not related to 5G_ProSe features but purely for EPS ProSe features. r01 is revised according to SA WG2 #147E feedback and all changes in clause 5.4.4.3 are reversed.

Comment:

Revision of (Postponed) S2-2107565 from S2#147E. r02 agreed. Revised to S2-2109026.

Discussion and conclusion:

-

e-mail discussion:

Judy (Ericsson) comments and provide r01
LaeYoung (LGE) provide r02.
Judy (Ericsson) is fine with r02
Hannu (Nokia) supports r02
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109026.

TD S2-2109026 (CR) 23.303 CR0330R2 (Rel-17, 'F'): TS 23.303 corrections discovered when working on 5G ProSe. (Source: Nokia, Nokia Shanghai Bell, LG Electronics, Ericsson).
Document for: Approval.
Abstract: Summary of change: In clause 5.1.1.5.2, figure# is corrected. There are no references to this Fig. In clause 5.1.2.2, the EN is removed. In clause 5.4.4.5, the message name is corrected. In clause 5.4.5.4, reference is corrected to point to Figure 5.4.5.4-1. In clause 5.5.7, fix the hanging line in step 5c of Figure 5.5.7-1 In clause 5.6.2, reference is corrected to point to Figure 5.6.2-1. In clause B.1, figure# is corrected. There are no external references outside of clause B.1 to this figure. - This CR includes the clauses not referred by TS 23.304, so not related to 5G_ProSe features but purely for EPS ProSe features.

Comment:

Revision of S2-2108767r02. Approved.

Discussion and conclusion:

-

Status:

Agreed.

# 5.2 QoS and PCC Maintenance

TD S2-2108346 (CR) 23.503 CR0671 (Rel-16, 'F'): Access network information request without PCC rules. (Source: Ericsson, AT&T, Deutsche Telekom, Telecom Italia).
Document for: Approval.
Abstract: Summary of change: Allow the request of access network information at PDU session level, decoupling it of PCC rules.

Comment:

r04 agreed. Revised to S2-2109027.

Discussion and conclusion:

-

e-mail discussion:

Pallab (Nokia) comments.
Belen (Ericsson) replies to comments.
Mirko (Huawei) comments.
Belen (Ericsson) accpets the proposal to use predefined PCC Rules
Belen (Ericsson) provides r01
Pallab (Nokia) provides r02
Belen (Ericsson) cannot accept r02, provides r03
Pallab (Nokia) is OK with r03
Mirko (Huawei) provides r04.
Pallab (Nokia) is OK with r04 and would like to co-sign.
Belen (Ericsson) okay with r04.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109027.

TD S2-2109027 (CR) 23.503 CR0671R1 (Rel-16, 'F'): Access network information request without PCC rules. (Source: Ericsson, AT&T, Deutsche Telekom, Telecom Italia, Nokia).
Document for: Approval.
Abstract: Summary of change: Clarify that Netloc information for SMS over IP can be achieved using predefined or dynamic PCC Rules.

Comment:

Revision of S2-2108346r04. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108347 (CR) 23.203 CR1137 (Rel-16, 'F'): Access network information request without PCC rules. (Source: Ericsson, AT&T, Deutsche Telekom, Telecom Italia).
Document for: Approval.
Abstract: Summary of change: Allow the request of access network information at IP-CAN session level, decoupling it of PCC rules.

Comment:

r02 + changes agreed. Revised to S2-2109332.

Discussion and conclusion:

-

e-mail discussion:

Pallab (Nokia) has same comments as in 8346.
Belen (Ericsson) suggests to discuss S2-2108346 first and reuse the same text here.
Belen (Ericsson) provides r01.
Belen (Ericsson) provides r02
==== Revisions Deadline ====
Pallab (Nokia) comments on r02
Belen (Ericsson) ask to add this CR to CC#2
==== Comments Deadline ====.

Status:

Revised to S2-2109332.

TD S2-2109332 (CR) 23.203 CR1137R1 (Rel-16, 'F'): Access network information request without PCC rules. (Source: Ericsson, AT&T, Deutsche Telekom, Telecom Italia).
Document for: Approval.
Abstract: Summary of change: Clarify that Netloc information for SMS over IP can be achieved using predefined or dynamic PCC Rules.

Comment:

Revision of S2-2108347r02 + changes. Approved.

Discussion and conclusion:

CC#2: Nokia asked to replace PCF by PCRF and PDU session by PDN connection in r02. This was agreed and S2-2109332 was approved.

Status:

Agreed.

TD S2-2108348 (CR) 23.503 CR0672 (Rel-17, 'A'): Access network info request without PCC rules. (Source: Ericsson, AT&T, Deutsche Telekom, Telecom Italia).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: Allow the request of access network information at PDU session level, decoupling it of PCC rules.

Comment:

r00 agreed. Revised to S2-2109028.

Discussion and conclusion:

-

e-mail discussion:

Belen (Ericsson) suggests to discuss S2-2108346 first and reuse the same text here.
Belen (Ericsson) provides r01.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109028.

TD S2-2109028 (CR) 23.503 CR0672R1 (Rel-17, 'A'): Access network info request without PCC rules. (Source: Ericsson, AT&T, Deutsche Telekom, Telecom Italia).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: Clarify that Netloc information for SMS over IP can be achieved using predefined or dynamic PCC Rules.

Comment:

Revision of S2-2108348r00. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108349 (CR) 23.203 CR1138 (Rel-17, 'A'): Access network information request without PCC rules. (Source: Ericsson, AT&T, Deutsche Telekom, Telecom Italia).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: Allow the request of access network information at IP-CAN session level, decoupling it of PCC rules.

Comment:

r01 + changes agreed. Revised to S2-2109333.

Discussion and conclusion:

-

e-mail discussion:

Belen (Ericsson) suggests to discuss S2-2108346 first and reuse the same text here.
Belen (Ericsson) provides r01.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109333.

TD S2-2109333 (CR) 23.203 CR1138R1 (Rel-17, 'A'): Access network information request without PCC rules. (Source: Ericsson, AT&T, Deutsche Telekom, Telecom Italia).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: Clarify that Netloc information for SMS over IP can be achieved using predefined or dynamic PCC Rules.

Comment:

Revision of S2-2108349r01 + changes. Approved.

Discussion and conclusion:

CC#2: This will be updated as an exact mirror of S2-2109332. This was agreed and S2-2109333 was approved.

Status:

Agreed.

TD S2-2108350 (DISCUSSION) Support for LI in SMS and Location Retrieval.. (Source: Ericsson).
Document for: Agreement.
Abstract: This paper proposes introducing support for location retrieval decoupling it of PCC rules (for example for SMS over IP).

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108387 (CR) 23.401 CR3670 (Rel-17, 'F'): Correction to MME handling EPS bearer QoS. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: Change 'NOTE 8' to 'NOTE 9'.

Comment:

r01 agreed. Revised to S2-2109029.

Discussion and conclusion:

-

e-mail discussion:

Mirko (Huawei) provides r01.
Judy (Ericsson) thanks Mirko (Huawei) for the revision and is fine with r01
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109029.

TD S2-2109029 (CR) 23.401 CR3670R1 (Rel-17, 'F'): Correction to MME handling EPS bearer QoS. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: Change 'NOTE 8' to 'NOTE 9'.

Comment:

Revision of S2-2108387r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

# 5.3 Non-3GPP Access Maintenance

# 5.4 IMS and IMS-Related Maintenance

# 6 Rel-15/Rel-16 Maintenance for 5G (only related to 5GS_Ph1 Work Item)

This agenda item was convened by Andy Bennett (Samsung).

# 6.1 General aspects, concepts and reference models

TD S2-2108298 (LS IN) LS from GSMA 5GJA: Reply LS from 5GJA to CT WG4 and SA WG3 on Using N32 for Interconnect Scenarios. (Source: GSMA 5GJA (5GJA#18 a Doc 112_r2)).
Document for: Action.
Abstract: GSMA 5GJA thanks CT WG4 for the LS on using N32 for Interconnect Scenarios, as provided in C4-214533 / 5GJA18_104. GSMA 5GJA expects that use of N32 can be applied for any inter-PLMN service based signalling, and while most of the use case discussed up to now is related to roaming, 5GJA believes N32 to be used for interconnect that includes Service based SMS and inter-PLMN mobility. GSMA 5GJA also believes that enabling SEPPs to allow/disallow a specific service based signalling over N32 is useful in the case when two PLMNs have limited relationship. In such case, exchanging unnecessary service based signalling can be avoided between the NFs of such PLMNs, and encourage 3GPP to take the above into account in their solutions. 2.1 Actions to CT WG4, SA WG3, and SA WG2 GSMA 5GJA kindly asks CT WG4, SA WG3, and SA WG2 to take the above response into account.

Comment:

Response drafted in S2-2109015. Final response in S2-2109334.

Discussion and conclusion:

-

e-mail discussion:

Leo (Deutsche Telekom): proposes to change the 'Result' for this TD from 'OPEN' to 'Replied to' when S2-2109015 is approved.
==== Comments Deadline ====.

Status:

Replied to.

TD S2-2109015 (LS OUT) [DRAFT] Reply LS on Using N32 for Interconnect Scenarios. (Source: NTT DOCOMO).
Document for: Approval.
Abstract: To: GSMA NG/5GJA. CC: SA WG3, CT WG4. Attachments: TS 23.501 CR3460, CR3461, CR3462.

Comment:

Created at CC#1. Response to S2-2108298. r01 agreed. Revised to S2-2109334.

Discussion and conclusion:

-

e-mail discussion:

Leo (Deutsche Telekom) provides r01.
Atsushi (NTT Docomo) is fine with r01.
==== Revisions Deadline ====
Laurent (Nokia): Comments
==== Comments Deadline ====.

Status:

Revised to S2-2109334.

TD S2-2109334 (LS OUT) Reply LS on Using N32 for Interconnect Scenarios. (Source: SA WG2).
Document for: Approval.
Abstract: To: GSMA NG/5GJA, SA WG3, CT WG4. Attachments: TS 23.501 CR3461, CR3462.

Comment:

Revision of S2-2109015r01. Approved.

Discussion and conclusion:

-

Status:

Approved.

TD S2-2108796 (CR) 23.501 CR3429 (Rel-17, 'F'): Clarification on rejected S-NSSAI andEquivalent PLMNs TAIs in the RA. (Source: Nokia, Nokia Shanghai Bell.).
Document for: Approval.
Abstract: Summary of change: clarifies that the rejected S-NSSAI is considered rejected inside the RA whichver the cell the UE is camping on, but it is considered rejected outside the RA only in the cells of the RPLMN which indicated the rejected S-NSSAI.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Peter (Ericsson) provides comments and propose to note the CR and focus on the NSAC issue as done by other CRs in 8.4
Jinguo(ZTE) agree with Peter. Lets focus on the LS from CT1
==== Revisions Deadline ====
alessio(Nokia) it is a pity this was requested to be noted. no one questions the network side sends for the current PLMN but then if it includes TAIs of other PLMNs in RA the UE behavior is not specified.
alessio(Nokia) BTW if Ericsson or ZTE prefer to continue discussing this now I am ok. we need to eventually have some text like this one.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108962 (CR) 23.501 CR3460 (Rel-15, 'F'): Clarifications on SEPP. (Source: Deutsche Telekom).
Document for: Approval.
Abstract: Summary of change: The description of reference point N32 in Clause 4.2.7, TS 23.501 is changed to: N32: Reference point between a SEPP in one PLMN and a SEPP in another PLMN.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Laurent (Nokia): provides r01 and is not sure this is FASMO
Fenqin (Huawei): comments
Leo (Deutsche Telekom): move to AI#6.1
Leo (Deutsche Telekom): is fine to NOTE the CR for Rel-15 and do error correction from Rel-16 onwards
Peter Hedman (Ericsson) provides r05
Leo (Deutsche Telekom) clarifies that the proposed changes are in S2-2108964r05
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108964 (CR) 23.501 CR3461 (Rel-16, 'A'): Clarifications on SEPP. (Source: Deutsche Telekom).
Document for: Approval.
Abstract: Rel-16 mirror CR: Summary of change: The description of reference point N32 in Clause 4.2.7, TS 23.501 is changed to: N32: Reference point between a SEPP in one PLMN and a SEPP in another PLMN.

Comment:

r05 agreed. Revised to S2-2109030.

Discussion and conclusion:

-

e-mail discussion:

Laurent (Nokia): provides R01 and r02 (same content but small 'r' in zip name)
Leo (Deutsche Telekom): move to AI#6.1
Leo (Deutsche Telekom): comments and provides r03
Leo (Deutsche Telekom): provides r04
Leo (Deutsche Telekom): is fine with r05 provided by Ericsson
==== Revisions Deadline ====
Leo (Deutsche Telekom): r05 shall be approved. It is no longer a mirror, it is now a CAT-F CR.
==== Comments Deadline ====.

Status:

Revised to S2-2109030.

TD S2-2109030 (CR) 23.501 CR3461R1 (Rel-16, 'F'): Clarifications on SEPP. (Source: Deutsche Telekom, Nokia, Nokia Shanghai Bell, Ericsson).
Document for: Approval.
Abstract: Summary of change: The description of reference point N32 in Clause 4.2.7, TS 23.501 is changed to: N32: Reference point between a SEPP in one PLMN and a SEPP in another PLMN.

Comment:

Revision of S2-2108964r05. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108970 (CR) 23.501 CR3462 (Rel-17, 'A'): Clarifications on SEPP. (Source: Deutsche Telekom).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: The description of reference point N32 in Clause 4.2.7, TS 23.501 is changed to: N32: Reference point between a SEPP in one PLMN and a SEPP in another PLMN.

Comment:

r01 agreed. Revised to S2-2109031.

Discussion and conclusion:

-

e-mail discussion:

Qianghua (Huawei) provides comments
Leo (Deutsche Telekom) provides r01 which is no longer a mirror.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109031.

TD S2-2109031 (CR) 23.501 CR3462R1 (Rel-17, 'F'): Clarifications on SEPP. (Source: Deutsche Telekom, Nokia, Nokia Shanghai Bell, Ericsson).
Document for: Approval.
Abstract: Summary of change: The description of reference point N32 in Clause 4.2.7, TS 23.501 is changed to: N32: Reference point between a SEPP in one PLMN or SNPN and a SEPP in another PLMN or SNPN; or between a SEPP in a SNPN and a SEPP in a CH/DCS, where the CH/DCS contains a UDM/AUSF.

Comment:

Revision of S2-2108970r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

# 6.2 Common Access Control, RM and CM functions and procedure flows

TD S2-2108374 (CR) 23.502 CR3150R2 (Rel-17, 'F'): Clarification on rerouted Registration Request message. (Source: Ericsson, Huawei, HiSilicon, NEC).
Document for: Approval.
Abstract: Summary of change: Adding clarificaiton on the re-routed Registration Request message between AMFs for rerouting possibilities.

Comment:

Revision of (Endorsed) S2-2107865 from S2#147E. Technically endorsed.

Discussion and conclusion:

-

e-mail discussion:

Alessio(Nokia) proposes to postpone this CR till we receive reply LS from SA3. if it comes in this week we can check it (not sure we will get one). for now it should remain with same status as last meeting.
==== Revisions Deadline ====
Qian (Ericsson) propose to mark it as Technically Endorsed (same as last meeting) due to lack of LS response.
==== Comments Deadline ====.

Status:

Endorsed.

TD S2-2108442 (CR) 23.502 CR3237 (Rel-17, 'F'): UE SM context fetch in registration procedure during inter-network mobility. (Source: Samsung).
Document for: Approval.
Abstract: Summary of change: In case of UE mobility b/w different SNPNs or PLMNs; On receiving SM context, the new AMF doesn't try the PDU session re-activation so that may inform the old AMF to let the SMF(s) release locally the SM context.

Comment:

CC#2: Postponed.

Discussion and conclusion:

CC#2: Samsung proposed replacing S2-2108442r01 with the content of an unhandled CR. This was not accepted and this CR was postponed.

e-mail discussion:

Youngkyo(Samsung) provides a revision r01.
Myungjune (LGE) proposes to merge this CR into S2-2108462 (AI#8.2).
Youngkyo(Samsung) replies and proposes to merge S2-2108462 (AI#8.2) into this CR.
Peter Hedman (Ericsson) provides comments and technically prefer 08642.
Qianghua (Huawei) prefers S2-2108462
Hannu (Nokia) is OK to merge this CR into S2-2108462 and would have comments if 8442 is expected to continue
Youngkyo(Samsung) is okay to merge this CR into S2-2108462.
==== Revisions Deadline ====
Youngkyo(Samsung) requests to take all the proposal of S2-2108462r03(AI#8.2) into the S2-2108462, which is marked as merged into S2-2108462 .
Myungjune (LGE) supports Youngkyo's suggestion
==== Comments Deadline ====.

Status:

Postponed.

TD S2-2108470 (CR) 23.502 CR3245 (Rel-17, 'F'): Updating AMF with new Routing Indicator Data if re-registration is not triggered. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: When the updated Routing Indicator value is also supported by the same UDM instance/group/set where the UE is currently registered, the UDM also notifies SMF and SMSF about the updated Routing Indicator value. When the updated Routing Indicator value is also supported by the same UDM instance/group/set where the UE is currently registered, the UDM the requests the AMF/SMF/SMSF to reallocate its registration to a UDM instance corresponding to the new Routing Indicator. This involves AMF/SMF/SMSF to register and subscribe to Subscription Data Management procedures with a UDM instance corresponding to the updated Routing Indicator. In the case of AMF, the AMF shall also trigger a re-authentication procedure so that a new Kausf is established at a AUSF instance corresponding to the updated Routing Indicator too.

Comment:

Postponed.

Discussion and conclusion:

-

e-mail discussion:

Susan (Huawei) provides comments and r01.
Fei (OPPO) asks questions.
Josep (DT) prefers the approach in r01. Provides r02 adding AUSF
Peter Hedman (Ericsson) provides replies and comments that r01 does not work
Susan (Huawei) replies to Peter Hedman (Ericsson).
==== Revisions Deadline ====
Peter Hedman (Ericsson) provides reply
Susan (Huawei) replies to Peter Hedman (Ericsson) and propose to postpone the CR to next meeting.
Hannu (Nokia) supports the proposal to postpone.
Peter Hedman (Ericsson) provides replies that error then remains in the TS
==== Comments Deadline ====.

Status:

Postponed.

TD S2-2108613 (CR) 23.502 CR3262 (Rel-16, 'F'): AMF re-allocation during inter PLMN mobility. (Source: ZTE).
Document for: Approval.
Abstract: Summary of change: It is clarified that the target AMF may trigger AMF re-allocation when Mobility Registration Update is performed after the UE enters CM-IDLE state, as described in clause 4.2.2.2.3.

Comment:

r01 agreed. Revised to S2-2109335.

Discussion and conclusion:

-

e-mail discussion:

Fenqin (Huawei) comments
Jinguo(ZTE) response and suggest to take majority views.
Alessio(Nokia) proposes this CR can be used as basis of a simple clarification where we say that there is no reallocation in connected mode. this may need to go back to the earlier releases too.
Jinguo(ZTE) provides r01
==== Revisions Deadline ====
Fenqin (Huawei) We can only accept the r01+ cover page update. The cover page of this CR need be updated to align with 8615r01.
alessio (Nokia) ok with r01
Jinguo(ZTE) asks for CC#2.
==== Comments Deadline ====.

Status:

Revised to S2-2109335.

TD S2-2109335 (CR) 23.502 CR3262R1 (Rel-16, 'F'): AMF re-allocation during inter PLMN mobility. (Source: ZTE).
Document for: Approval.
Abstract: Summary of change: Remove the wrong sentence.

Comment:

Revision of S2-2108613r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108614 (CR) 23.501 CR3402 (Rel-16, 'F'): AMF re-allocation in CM connected state. (Source: ZTE).
Document for: Approval.
Abstract: Summary of change: Existing mechanism for modification of the Set of Network Slice(s) for a UE is reused to resolve this issue, i.e. the AMF can send indication to UE to perform a Registration procedure without including the GUAMI or 5G-S-TMSI in the access stratum signalling after entering CM-IDLE state.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Alessio(Nokia) proposes to note the paper or to update it with the detail to ALWAYS include NSSAI in the RRC connection establishment MSG 5.
Jinguo(ZTE) asks question
Alessio(Nokia) comments
Jinguo(ZTE) response
==== Revisions Deadline ====
Jinguo(ZTE) suggests to approve r01
Jinguo(ZTE) suggests to approve r00, the original version. There is no r01
Fenqin(Huawei)propose to Note this paper
alessio(Nokia) proposes a way forward to approve the original document after removing in CC#2 'and/or new UE requested NSSAI received from UE in CM Connected state,'
Jinguo(ZTE) agree with alessio(Nokia), lets check at CC#2
==== Comments Deadline ====
Fenqin(Huawei) comments.

Status:

Noted.

TD S2-2108615 (CR) 23.502 CR3263 (Rel-17, 'F'): AMF re-allocation during inter PLMN mobility. (Source: ZTE).
Document for: Approval.
Abstract: Summary of change: It is clarified that the target AMF may trigger AMF re-allocation when Mobility Registration Update is performed as described in clause 4.2.2.2.3 after the UE enters CM-IDLE state.

Comment:

r01 agreed. Revised to S2-2109336.

Discussion and conclusion:

-

e-mail discussion:

Fenqin (Huawei) comments
Jinguo(ZTE) provides r01
==== Revisions Deadline ====
alessio (Nokia) ok with r01
==== Comments Deadline ====.

Status:

Revised to S2-2109336.

TD S2-2109336 (CR) 23.502 CR3263R1 (Rel-17, 'A'): AMF re-allocation during inter PLMN mobility. (Source: ZTE).
Document for: Approval.
Abstract: Summary of change: Remove the wrong sentence.

Comment:

Revision of S2-2108615r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108616 (CR) 23.501 CR3403 (Rel-17, 'F'): AMF re-allocation in CM connected state. (Source: ZTE).
Document for: Approval.
Abstract: Summary of change: Existing mechanism for modification of the Set of Network Slice(s) for a UE is reused to resolve this issue, i.e. the AMF can send indication to UE to perform a Registration procedure without including the GUAMI or 5G-S-TMSI in the access stratum signalling after entering CM-IDLE state.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Fenqin(Huawei)propose to Note this paper
alessio(Nokia) proposes a way forward to approve the original document after removing in CC#2 'and/or new UE requested NSSAI received from UE in CM Connected state,'
Jinguo(ZTE) agree with alessio(Nokia). Lets check it at CC#2. I can remove 'and/or new UE requested NSSAI received from UE in CM Connected state,' and update the cover page accordingly.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108676 (CR) 23.502 CR3271 (Rel-17, 'F'): Inter PLMN handover procedure. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: The initial AMF reselects the target AMF based on the recieved the S-NSSAI(s) from the source AMF during preperation phase.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Qian (Ericsson) comments
Fenqin (Huawei) responds
Jinguo (ZTE) comments
Qian (Ericsson) responds
Alessio(Nokia) proposes to note this CR and handle this topic in rel-18
Fenqin (Huawei) I agree that this need some change at the existing specification. But this is R17 :) .
==== Revisions Deadline ====
Qian (Ericsson) propose to NOTE the paper and go with the decision in 8615 .
==== Comments Deadline ====.

Status:

Noted.

# 6.3 Session management and continuity functions and flows

TD S2-2108388 (DISCUSSION) Service Request and PCF interaction.. (Source: Ericsson).
Document for: Agreement.
Abstract: This paper discusses the issues related to policy control in service request and propose a resolution.

Comment:

Postponed.

Discussion and conclusion:

-

e-mail discussion:

Fenqin (Huawei) comments
Judy (Ericsson) responds to Fenqin (Huawei)
Fenqin (Huawei) responds
Myungjune (LGE) provides comments.
Judy (Ericsson) responds to Myungjune (LGE) and Fenqin (Huawei)
Jinguo (ZTE) provides comments.
Judy (Ericsson) responds to Jinguo (ZTE)'s that his comments are addressed in the paper as well as in previous responses.
Fenqin (Huawei) comments.
Judy (Ericsson) ask Fenqin (Huawei) for clarification
Fenqin (Huawei) comments and propose to postpone this issue.
Laurent (Nokia): we support Fenqin's request to postpone
==== Revisions Deadline ====
Judy (Ericsson) is OK to postpone to allow more time for discussion.
==== Comments Deadline ====.

Status:

Postponed.

TD S2-2108389 (CR) 23.502 CR3230 (Rel-16, 'F'): Service Request and PCF interaction. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: In clause 4.2.3.2, move the reporting of PCRT 'Change of Access Type' to the same step (i.e. step 16) when other PCRTs (e.g. Location Change) are reported. In clause 4.23.4.3, for I-SMF change/insertion, I-SMF informs SMF of UP activation in Operation Type and add new indications of UP activated from I-SMF to the anchor SMF.

Comment:

Postponed.

Discussion and conclusion:

-

e-mail discussion:

Fenqin (Huawei) comments
==== Revisions Deadline ====
Laurent (Nokia): we support Fenqin's request to postpone
==== Comments Deadline ====.

Status:

Postponed.

TD S2-2108390 (CR) 23.502 CR3231 (Rel-17, 'A'): Service Request and PCF interaction. (Source: Ericsson).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: In clause 4.2.3.2, move the reporting of PCRT 'Change of Access Type' to the same step (i.e. step 16) when other PCRTs (e.g. Location Change) are reported. In clause 4.23.4.3, for I-SMF change/insertion, I-SMF informs SMF of UP activation in Operation Type and add new indications of UP activated from I-SMF to the anchor SMF.

Comment:

Postponed.

Discussion and conclusion:

-

e-mail discussion:

Fenqin (Huawei) comments
==== Revisions Deadline ====
Laurent (Nokia): we support Fenqin's request to postpone
==== Comments Deadline ====.

Status:

Postponed.

TD S2-2108512 (CR) 23.501 CR3382 (Rel-17, 'F'): Supplementation of L2TP tunnel applicable senario. (Source: China Mobile).
Document for: Approval.
Abstract: Summary of change: Clarification applicable senario of L2TP tunnel.

Comment:

r03 agreed. Revised to S2-2109032.

Discussion and conclusion:

-

e-mail discussion:

Laurent (Nokia): provides r
Laurent (Nokia): provides r01
Stefan (Ericsson) supports r01
Haris(Qualcomm) provides r02
Dan(China Mobile) is ok with r02 and provide r03 to clear the text.
==== Revisions Deadline ====
Laurent (Nokia): objects to R00 and R02,
Dan (China Mobile): suggest to go with r03
==== Comments Deadline ====.

Status:

Revised to S2-2109032.

TD S2-2109032 (CR) 23.501 CR3382R1 (Rel-17, 'F'): Supplementation of L2TP tunnel applicable senario. (Source: China Mobile).
Document for: Approval.
Abstract: Summary of change: Clarification applicable senario of L2TP tunnel.

Comment:

Revision of S2-2108512r03. Approved.

Discussion and conclusion:

-

Status:

Agreed.

# 6.4 Security related functions and flows

# 6.5 QoS concept and functionality

# 6.6 Policy and charging control

TD S2-2108269 (LS IN) LS from CT WG6: LS to SA2 on mandatory SSC modes supported by UE. (Source: CT WG6 (C6-210258)).
Document for: Action.
Abstract: CT WG6 seeks additional clarity in specification 3GPP TS 23.501, clause 5.6.9.2 regarding the SSC modes 1, 2, 3 currently defined. It's our understanding that supporting SSC mode 1 is mandatory, while the support of SSC modes 2 and 3 is optional. The support of SSC modes 2 and 3 is dependent on the type of device, and can be defined by the device manufacturer. However, for CT WG6 the existing definition in 3GPP TS 23.501 seems to be not very clear. If for example a 5G capable device is built for a very specific application and with 'only a specific URSP rule' configured for that application (for the lifetime of this device), we assume that such a device does not need SSC modes 2 and 3 to be implemented. Although the mechanism to handle 'unsupported' SSC modes is defined in 3GPP TS 24.526, clause 4.2.2 (CT WG1 Rel-16, C1-196422), there is no clear indication what SSC modes can be treated as optional for Rel 15 and Rel 16 devices. Action: CT WG6 kindly asks SA WG2 to take the above concern into consideration and to reply to the following questions: 1) Is it correct, if we handle SSC modes 2 and 3 as optional? 2) Is it possible to modify 3GPP TS 23.501 to explicitly state which SSC modes have to be supported? 3) If the support of SSC mode 2 and/or 3 is not optional but conditional, can you please specify the conditions?

Comment:

Revision of S2-2107035 from S2#147E. Responses drafted in S2-2108322, S2-2108368, S2-2108583 and S2-2108782. Final response in S2-2109345.

Discussion and conclusion:

-

Status:

Replied to.

TD S2-2108322 (LS OUT) [DRAFT] LS Reply to CT WG6 on mandatory SSC modes supported by UE. (Source: T-Mobile USA Inc.).
Document for: Approval.
Abstract: Reply to CT WG6 answering questions on mandatory/optional use of SSC modes.

Comment:

Response to S2-2108269 To be Merged into S2-2109345.

Discussion and conclusion:

-

e-mail discussion:

Pallab (Nokia) suggests to move the LSOut discussion to a single email thread in S2-2108368.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Merged into S2-2109345.

TD S2-2108368 (LS OUT) [DRAFT] Reply LS on mandatory SSC modes supported by UE. (Source: Ericsson).
Document for: Approval.
Abstract: This is a proposed reply to LS from CT WG6 on SSC modes (C6-210258 / S2-2108269).

Comment:

Response to S2-2108269. CC#2: r10 agreed. Revised to S2-2109345, merging S2-2108322, S2-2108583 and S2-2108782.

Discussion and conclusion:

S2-2108368r10 was proposed by Ericsson. This was agreed and revised to S2-2109345. S2-2108322, S2-2108583 and S2-2108782 were considered merged into S2-2109345.

e-mail discussion:

Hui (Huawei) asks for clarification.
Pallab (Nokia) comments and suggests that we discuss the LS Response in this thread.
Dan (China Mobile) provide consideration.
Irfan (Cisco) provides comments.
Irfan (Cisco) adds Dan's comment to this thread to keep discussion one thread
Fei (OPPO) comments.
Haris(Qualcomm) objects to this LS response since it is not supported by stage-3 text and would create UE impacts in frozen releases
Haris (Qualcomm) provides comments.
Guillaume (MediaTek Inc.) comments.
Stefan (Ericsson) provides questions to Haris
Haris(Qualcomm) comments
Irfan (Cisco) provides response to Harris
Haris(Qualcomm) replies
Krisztian (Apple) supports Qualcomm's and Mediatek's view that currently all SSC modes are considered optional for the UE to support. We have no problem to make SSC mode 1 mandatory for all UEs. We can't accept making SSC modes 2 and 3 mandatory for the UE to support.
Guillaume (MediaTek) adds further comments
Irfan (Cisco) comments on SSC Mode 2 optional for UE
Hui(Huawei) comments
Haris(Qualcomm) comments and provides r01
Guillaume (MediaTek Inc.) replies to Pallab (Nokia).
Magnus H (Ericsson) comments
Saso (Intel) comments
Stefan (Ericsson) comments
Irfan (Cisco) comments and provides r02
Pallab (Nokia) responds to Irfan (Cisco) and requests for clarification
Irfan (Cisco) responds to Pallab (Nokia)
Magnus H (Ericsson) provides r03
Dan (China Mobile) object to any version which one without saying the SSC mode 1 should be mandatory supported by UE
Haris(Qualcomm) provides r04
Serge (T-Mobile USA) supports r03 or r04 and comments
Saso (Intel) replies to Magnus H (Ericsson) on N26
Magnus H (Ericsson) withdraws comment on N26
Magnus H (Ericsson) comment related to no N26 support.
Dan (China Mobile) provide r05
Haris(Qualcomm) is ok but if we go with r05 we should also approve a CR to back up our assertions
Pallab (Nokia) asks for clarification on r05.
Irfan (Cisco) is also OK with r05
Pallab (Nokia) agrees with Fei (OPPO).
Pallab (Nokia) provides r06
Guillaume (MediaTek Inc.) provides r07
==== Revisions Deadline ====
Stefan (Ericsson) cannot agree r07. Uploaded r08 and r09 in DRAFTS folder. Another alternative is to postpone the LS.
Irfan (Cisco) supports r08
Haris(Qualcomm) indicates that is ok with r08 and comments on suggestion from Irfan
Guillaume (MediaTek Inc.): ok with r08
Fei (OPPO) ok with r09 or postpone the LS.
Hui (Huawei) ok with r09 or postpone the LS.
Haris(Qualcomm) objects to r09
Stefan (Ericsson) OK with r08, r09 or postponing the LS
==== Comments Deadline ====
Stefan (Ericsson) uploaded r08 to CC#2 folder.

Status:

Revised to S2-2109345, merging S2-2108322, S2-2108583 and S2-2108782.

TD S2-2109345 (LS OUT) Reply LS on mandatory SSC modes supported by UE. (Source: SA WG2).
Document for: Approval.
Abstract: To: CT WG6, CT WG1.

Comment:

Revision of S2-2108368r10, merging S2-2108322, S2-2108583 and S2-2108782. Approved.

Discussion and conclusion:

-

Status:

Approved.

TD S2-2108583 (LS OUT) [DRAFT] Reply LS to SA WG2 on mandatory SSC modes supported by UE. (Source: OPPO).
Document for: Approval.
Abstract: Reply LS of S2-2108269.

Comment:

Response to S2-2108269 To be Merged into S2-2109345.

Discussion and conclusion:

-

e-mail discussion:

Pallab (Nokia) suggests to move the LSOut discussion to a single email thread in S2-2108368.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Merged into S2-2109345.

TD S2-2108782 (LS OUT) [DRAFT] Reply LS to SA WG2 on mandatory SSC modes supported by UE. (Source: Qualcomm).
Document for: Approval.
Abstract: To: CT WG6. CC: CT WG1.

Comment:

Response to S2-2108269 To be Merged into S2-2109345.

Discussion and conclusion:

-

e-mail discussion:

Pallab (Nokia) suggests to move the LSOut discussion to a single email thread in S2-2108368.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Merged into S2-2109345.

TD S2-2108320 (DISCUSSION) Mandatory SSC Modes.. (Source: T-Mobile USA).
Document for: Discussion.
Abstract: This discussion paper summarizes the SA WG2 specifications that require specific SSC modes for certain services.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108890 (DISCUSSION) Mandatory SSC Mode Support for UE.. (Source: Cisco Systems).
Document for: Discussion.
Abstract: Discusses this topic in light of the LS sent by CT WG6 (S2-2108269).

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108891 (CR) 23.501 CR3452 (Rel-16, 'F'): SSC Mode support by UE. (Source: Cisco Systems).
Document for: Approval.
Abstract: Summary of change: State that SSC Mode 1 and 2 are mandatory for UE to support along with the key ramifications. SSC Mode 3 is optional for UE to support.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Josep (DT) asks a question for clarification.
Irfan (Cisco) responds and provides r01
Haris (Qualcomm) objects to the CR (all revisions)
Hui(Huawei) provides comments
Krisztian (Apple) also objects this CR. We can't accept making SSC mode 2 mandatory for all UEs to support.
Pallab (Nokia) provides r02.
Stefan (Ericsson) comments and provides r03
Pallab (Nokia) comments on r03.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108892 (CR) 23.501 CR3453 (Rel-17, 'A'): SSC Mode support by UE. (Source: Cisco Systems).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: State that SSC Mode 1 and 2 are mandatory for UE to support along with the key ramifications. SSC Mode 3 is optional for UE to support.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108629 (DISCUSSION) SSC modes and optional functionalities in URSP.. (Source: Qualcomm Incorporated).
Document for: Agreement.
Abstract: Discusses the support for SSC modes and in general support for optional functionalities declared in URSP.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108645 (CR) 23.501 CR3412 (Rel-15, 'F'): Support for SSC modes. (Source: Qualcomm Incorporated).
Document for: Approval.
Abstract: Summary of change: Clarifies that SSC mode 1 is mandatory for the UE to support and SSC modes 2 and 3 optional.

Comment:

Postponed.

Discussion and conclusion:

-

e-mail discussion:

Irfan (Cisco) corrects the tdoc number and provides r01
Haris(Qualcomm) cannot accept r01 since it creates ambiguity re the requirement for SSC mode 2
Pallab (Nokia) provides r02.
Hui (Huawei) provides r03.
Irfan (Cisco) provide r03 based on update to r01
Chris (Vodafone) prefers r03 to r0, but expects that further work is needed.
Haris(Qualcomm) objects to r03
Magnus H (Ericsson) suggest further work needed
Guillaume (MediaTek Inc.): ok with r03
==== Revisions Deadline ====
Irfan (Cisco) uploads r04 to draft folder. Cisco is ok with r03 or r04 (in drafts folder)
Haris(Qualcomm) comments on r04
Stefan (Ericsson) proposes to postpone the CR
Haris(Qualcomm) comments and proposes a WF
Hui (Huawei) fine with postpone the CR
Fei (OPPO) is fine with r04 and r00
Stefan (Ericsson) comments on WF and uploaded LS revisions on the 8368 thread
Hui (Huawei) asks to postpone the CR.
==== Comments Deadline ====.

Status:

Postponed.

TD S2-2108772 (CR) 23.501 CR3425 (Rel-16, 'A'): Support for SSC modes. (Source: Qualcomm Incorporated).
Document for: Approval.
Abstract: Rel-16 mirror CR: Summary of change: Clarifies that SSC mode 1 is mandatory for the UE to support and SSC modes 2 and 3 optional.

Comment:

Postponed.

Discussion and conclusion:

-

Status:

Postponed.

TD S2-2108780 (CR) 23.501 CR3426 (Rel-17, 'A'): Support for SSC modes. (Source: Qualcomm Incorporated).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: Clarifies that SSC mode 1 is mandatory for the UE to support and SSC modes 2 and 3 optional.

Comment:

Postponed.

Discussion and conclusion:

-

Status:

Postponed.

TD S2-2108554 (CR) 23.503 CR0676 (Rel-15, 'F'): Clarifications on SSC mode 3. (Source: Samsung).
Document for: Approval.
Abstract: Summary of change: The bold text is added in the note in Clause 6.6.2.3, TS 23.503: - -.the UE can take the PDU Session Address Lifetime value into account when selecting the PDU Session for the existing traffic flow as specified in Clause 4.3.5.2 in TS 23.502.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Belen (Ericsson) asks question for clarification
Dongeun (Samsung) clarifies.
Chia-Lin (MediaTek) considers this is not essential correction and Rel-15 has been frozen for a long time. The CR is not needed.
Belen (Ericsson) is okay with the clarifications, ask a question.
Dongeun (Samsung) provides r01 (also for and replies to Belen (Ericsson) and Chia-Lin (MediaTek)
Chia-Lin (MediaTek) provides comments and still considers the CR is not needed
Dongeun (Samsung) replies to Chia-Lin (MediaTek)
==== Revisions Deadline ====
Chia-Lin (MediaTek) suggest to note the CR
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108562 (CR) 23.503 CR0677 (Rel-16, 'A'): Clarifications on SSC mode 3. (Source: Samsung).
Document for: Approval.
Abstract: Rel-16 mirror CR: Summary of change: The bold text is added in the note in Clause 6.6.2.3, TS 23.503: - -.the UE can take the PDU Session Address Lifetime value into account when selecting the PDU Session for the existing traffic flow as specified in Clause 4.3.5.2 in TS 23.502.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Dongeun (Samsung) provides r01
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108584 (CR) 23.503 CR0679 (Rel-17, 'A'): Clarifications on SSC mode 3. (Source: Samsung).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: The bold text is added in the note in Clause 6.6.2.3, TS 23.503: - -.the UE can take the PDU Session Address Lifetime value into account when selecting the PDU Session for the existing traffic flow as specified in Clause 4.3.5.2 in TS 23.502.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Dongeun (Samsung) provides r01
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108902 (CR) 23.502 CR3305 (Rel-16, 'F'): Selecting the same PCF for all UE PDU Sessions to a DNN, S-NSSAI when SSC mode 3 applies. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: - A change of SMF for a PDU Session with SSC mode 3 applies transfers the PCF ID for the Old PDU Session ID that is stored in the PDU Session Context at the SMF. - PCF Selection Assistance Information in UDM is extended to indicate per DNN,S-NSSAI if the same PCF is selected for all PDU Sessions (for usage monitoring). - PDU Session establishment includes an additional check in the AMF to set the Same PCF Selection Indication to the SMF, and include the PCF ID stored in the PDU Session Context for this DNN,S-NSSAI.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Susan (Huawei) provides comments and don't think this CR is needed.
Dongeun (Samsung) comments.
Belen (Ericsson) states that the CR is needed to cover the case of SMF relocation and same PCF.
Susan (Huawei) replies and is not convinced why the changes in this CR are needed.
Belen (Ericsson) responds to Samsung
Dongeun (Samsung) comments again.
Belen (Ericsson) replies to Samsung and Huawei
==== Revisions Deadline ====
Belen (Ericsson) aks if r00 is acceptable by Samsung and Huawei
Dongeu (Samsung) suggests to postpone the CR.
Susan (Huawei) replies to Belen (Ericsson) and asks questions for clarification.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108903 (CR) 23.502 CR3306 (Rel-17, 'A'): Selecting the same PCF for all UE PDU Sessions to a DNN, S-NSSAI when SSC mode 3 applies. (Source: Ericsson).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: - A change of SMF for a PDU Session with SSC mode 3 applies transfers the PCF ID for the Old PDU Session ID that is stored in the PDU Session Context at the SMF. - PCF Selection Assistance Information in UDM is extended to indicate per DNN,S-NSSAI if the same PCF is selected for all PDU Sessions (for usage monitoring). - PDU Session establishment includes an additional check in the AMF to set the Same PCF Selection Indication to the SMF, and include the PCF ID stored in the PDU Session Context for this DNN,S-NSSAI.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Susan (Huawei) provides comments and don't think this CR is needed.
Belen (Ericsson) states that the CR is needed to cover the case of SMF relocation and same PCF.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108913 (CR) 23.502 CR3308 (Rel-17, 'F'): SM policy association in SSC mode #3. (Source: NTT DOCOMO).
Document for: Approval.
Abstract: Summary of change: It is proposed to fix the issues above by: (a) Transferring the PCF ID and SM Policy Association ID from the old SMF to the new SMF by including these parameters ('Session continuity information with SSC mode 3') in the SM context that the new SMF retrieves from the old SMF in SSC mode #3. (b) If an SM policy is influenced by a Npcf_PolicyAuthorization_Create Request, the PCF indicates to the SMF in the PCC rules that, in case of PCF change, it is required to notify the AF of the 'PCF change'. (c) If the new SMF selects the old PCF, the SMF uses _Update service operation instead of _Create, to indicate the change of the SMF to the PCF. (d) If the new SMF selects a new PCF, the SMF notifies the AF. Upon receiving the 'PCF change' notification, the AF re-creates the AF session in the new PCF by sending a new Npcf_PolicyAuthorization_Create Request. (e) The new SMF notifies the old SMF for the result of the session transfer. The new SMF indicates whether the old SM policy association is used in the new PDU Session. In this case the old SMF does not release the SM policy association with the PCF, when the old PDU Session is released.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Susan (Huawei) provides comments and don't think this CR is needed.
Pallab (Nokia) requests for clarification.
Belen (Ericsson) provides comments
Riccardo (NTT DOCOMO) replies to Susan, provides revision 1 and clarifies the need for it.
Riccardo (NTT DOCOMO) replies to Pallab.
Riccardo (NTT DOCOMO) replies to Belen.
Pallab (Nokia) replies to Riccardo (NTT DOCOMO) and asks for further clarification.
Riccardo (NTT DOCOMO) replies to Pallab (Nokia).
Susan (Huawei) replies to Riccardo.
Pallab (Nokia) responds to Riccardo (NTT DOCOMO) and still not convinced that the CR is needed.
Riccardo (NTT DOCOMO) replies to Susan.
Riccardo (NTT DOCOMO) responds to Pallab (Nokia).
Pallab (Nokia) responds to Riccardo (NTT DOCOMO) and proposes to NOTE the CR.
Riccardo (NTT DOCOMO) asks clarifications to Pallab (Nokia)
Pallab (Nokia) responds to Riccardo (NTT DOCOMO).
Belen (Ericsson) replies to DOCOMO and also thinks the CR can be POSTPONE
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108914 (CR) 23.503 CR0690 (Rel-17, 'F'): SM policy association in SSC mode #3. (Source: NTT DOCOMO).
Document for: Approval.
Abstract: Summary of change: If an SM policy is influenced by a Npcf_PolicyAuthorization_Create Request, the PCF indicates to the SMF in the PCC rules that, in case of PCF change, it is required to notify the AF of the 'PCF change'.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Susan (Huawei) provides comments and don't think this CR is needed.
Pallab (Nokia) has same comments as in 8913
Riccardo (NTT DOCOMO) replies to Susan and clarify the need for this CR.
Riccardo (NTT DOCOMO) replied in the 8913 thread.
Pallab (Nokia) proposes to NOTE the CR as commented in 8913
Riccardo (NTT DOCOMO) commented in 8913
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108736 (CR) 23.503 CR0685 (Rel-17, 'D'): Alignment of PCC input parameter documentation. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: The description of the parameters that are provided by several NFs as input for PCC decisions is updated by adding a reference to 23.502 whereever possible.

Comment:

Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108649 (CR) 23.503 CR0683 (Rel-16, 'F'): Clarifications on Support for Application Functions supporting Rx interface. (Source: Samsung).
Document for: Approval.
Abstract: Summary of change: - Corrected clause references.

Comment:

Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108663 (CR) 23.503 CR0684 (Rel-17, 'A'): Clarifications on Support for Application Functions supporting Rx interface. (Source: Samsung).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: - Corrected clause references.

Comment:

Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108420 (CR) 23.502 CR3234 (Rel-17, 'F'): BSF service update for session binding information update. (Source: China Mobile).
Document for: Approval.
Abstract: Summary of change: Adding BSF notify AF with session binding information update.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Pallab (Nokia) requests for clarification
Dan (China Mobile) provide response
Belen (Ericsson) asks questions for clarification
Pallab (Nokia) responds to Dan (China Mobile)
Dan (China Mobile) responds to Pallab and Belen
Pallab (Nokia) responds to Dan (China Mobile) and questions the need for the CR
Dan (China Mobile) reply
Pallab (Nokia) requests for further clarification
Dan (China Mobile) response
Pallab (Nokia) comments and proposes to NOTE the CR
Dan (China Mobile) response and suggest whether we can endorse this one
Belen (Ericsson) proposes to NOTE or POSTPONE this CR
Belen (Ericsson) replies to Dan
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108421 (CR) 23.503 CR0673 (Rel-17, 'F'): BSF service update for session binding information update. (Source: China Mobile ).
Document for: Approval.
Abstract: Summary of change: Adding BSF notify AF with session binding information update.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Pallab (Nokia) has same comments as in 8420
Pallab (Nokia) proposes to NOTE the CR as commented in 8420
dan (China mobile) proposes whether we can endorse this one and see further update in next emeeting
Belen (Ericsson) supports to NOTE or POSTPONE this CR, it cannot accept to endorse it
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

# 6.7 3GPP access specific functionality and flows

TD S2-2108375 (CR) 23.501 CR3367 (Rel-17, 'F'): NG-RAN location report clarification in RRC Inactive. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: Clarify the behaviour of location reporting handling in case of RAN paging failure. The detailed handling is referred to 23.502 clause 4.10.

Comment:

Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108376 (CR) 23.502 CR3229 (Rel-17, 'F'): NG-RAN location report clarification in RRC Inactive. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: Clarify the behaviour of location reporting handling in case of RAN paging failure.

Comment:

Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108377 (CR) 23.401 CR3669R1 (Rel-17, 'C'): ACL support for S1 HO with Indirect Data Forwarding. (Source: Ericsson, Deutsche Telekom).
Document for: Approval.
Abstract: Summary of change: Adding the changes for target CN to provide the source address information of the indirect data forwarding tunnel at CN side and provide it to target RAN in a S1AP message during HO preparation phase.

Comment:

Revision of (Noted) S2-2107770 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

Fenqin (Huawei) suggest to postpone this paper.
Laurent (Nokia): has concerns with the approach in this Tdoc
Juan Zhang (Qualcomm) shares the same concern with Laurent (Nokia).
Qian (Ericsson) provides comments and asks quesitons.
Fenqin (Huawei) shares the same view as Juan and Laurent.
==== Revisions Deadline ====
Laurent (Nokia): objects to any version of this Tdoc
Fenqin (Huawei): Propose to note this paper
Juan Zhang (Qualcomm) Proposes to note this paper
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108378 (CR) 23.502 CR3218R1 (Rel-17, 'C'): ACL support for NGAP HO with Indirect Data Forwarding. (Source: Ericsson, Deutsche Telekom).
Document for: Approval.
Abstract: Summary of change: Adding the changes for target CN to provide the source address information of the indirect data forwarding tunnel at CN side and provide it to target NG-RAN in a NGAP message during HO preparation phase.

Comment:

Revision of (Noted) S2-2107771 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

Fenqin (Huawei) suggest to postpone this paper.
Laurent (Nokia): has concerns with the approach in this Tdoc
Juan Zhang (Qualcomm) shares the same concern with Laurent (Nokia).
Qian (Ericsson) provides comments and asks question.
Fenqin (Huawei) share the same view as Laurent and Juan
Juan Zhang (Qualcomm) replies to Qian (Ericsson)
==== Revisions Deadline ====
Laurent (Nokia): objects to any version of this Tdoc
Fenqin (Huawei): Propose to note this paper
Juan Zhang (Qualcomm) Proposes to note this paper
==== Comments Deadline ====.

Status:

Noted.

TD S2-2109008 (LS IN) LS on indication of direct data forwarding availability. (Source: RAN WG3 (R3-216176)).
Document for: Action.
Abstract: RAN WG3 has agreed that for intra-5GS NG based handover, it would be useful for the target NG-RAN node to know whether direct data forwarding or indirect data forwarding is applied so as to enable to use different IP address space for forwarding accordingly. Therefore, RAN WG3 has agreed the attached CR to enable the SMF to indicate to the target gNB whether it has decided direct forwarding for the intra-5GS NG based handover after receiving the Direct Forwarding Path Availability in the Handover Required message. Action: RAN WG3 respectfully asks SA WG2 to take the above into account and update the specification accordingly.

Comment:

Postponed.

Discussion and conclusion:

-

e-mail discussion:

Qian (Ericsson) proposes to Postpone the paper since no contribution submitted on this in the meeting
==== Comments Deadline ====.

Status:

Postponed.

# 6.8 Specific services support

TD S2-2108869 (CR) 23.502 CR3301 (Rel-17, 'F'): TAU with active flag in case the entire PDU session is rejected. (Source: Qualcomm Incorporated).
Document for: Approval.
Abstract: Summary of change: Add clarification that the UE need to send TAU and the option that TAU includes active flag in case of redirection to EPS.

Comment:

r02 agreed. Revised to S2-2109033.

Discussion and conclusion:

-

e-mail discussion:

Hannu (Nokia) asks question to understand what is being proposed and suggests that a revision would be needed to clarify when the new text applies?
Haris(Qualcomm) provides r01
Hannu (Nokia) replies to Haris and provides r02
==== Revisions Deadline ====
Qian (Ericsson) prefer r01
Hannu (Nokia) can either agree r02 or postpone the CR. The previous revisions are not acceptable as they do not work.
Qian (Ericsson) comments.
Haris(Qualcomm) commments
==== Comments Deadline ====
Hannu (Nokia) thanks Haris for explanation. I still prefer r01 but based on your explanation I can now live with r02 which leads to the correct outcome even if the reader of the QoS flow rejection text fails to see the new text added in this CR.

Status:

Revised to S2-2109033.

TD S2-2109033 (CR) 23.502 CR3301R1 (Rel-17, 'F'): TAU with active flag in case the entire PDU session is rejected. (Source: Qualcomm Incorporated).
Document for: Approval.
Abstract: Summary of change: Add clarification that the UE need to send TAU and the option that TAU includes active flag in case of redirection to EPS.

Comment:

Revision of S2-2108869r02. Approved.

Discussion and conclusion:

-

Status:

Agreed.

# 6.9 Interworking and Migration

TD S2-2108303 (CR) 23.501 CR3355 (Rel-17, 'F'): Clarification on mobility from NG-RAN to GERAN/UTRAN. (Source: Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: Clarifies that when a UE moves from NG-RAN to GERAN/UTRAN, the AMF for 3GPP access is deregistered by the HSS+UDM.

Comment:

Confirm CR Number - CR states 3335! Postponed.

Discussion and conclusion:

-

e-mail discussion:

Qian (Ericsson) provides comments and express concerns.
Alessio(Nokia) provides r01
Alessio(Nokia) hopes r01 clarified the questions by Ericsson
Qian (Ericsson) provides further comments
Qian (Ericsson) comments
alessio (nokia) comments
Qian (Ericsson) responds
Alessio(Nokia) comments
Qian (Ericsson) comments further
Haris(Qualcomm) re 'providing UE service' asks if there are implications in T-ADS if we don't approve the CR
Qian (Ericsson) responds to Haris (Qualcomm)
Fenqin (Huawei) share the similar view as Qian
alessio(nokia) asks a question
alessio(Nokia) requests to escalate this to CC#2 if ericsson does not graciously agree that SR applies when the UE moves to 2/3G.
==== Revisions Deadline ====
Alessio (Nokia) proposes to mark this as postponed as clearly this is not approvable at this meeting. we will work offline with interested companies till SA2#149e
==== Comments Deadline ====.

Status:

Postponed.

TD S2-2108624 (CR) 23.502 CR3265 (Rel-16, 'F'): EPS fallback for a UE moving from EPS to 5GS with a bearer for IMS voice .. (Source: Samsung).
Document for: Approval.
Abstract: Summary of change: The SMF informs the AMF that the EPS fallback should be triggered after registration procedure completes.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Zhendong (ZTE): provides the comments
Qian (Ericsson) asks questions
Alessio(Nokia) agrees with ZTE we can note this CR as the scenario that underlies it is incorrect.
Haris(Qualcomm) proposes to note the CR
Myungjune (LGE) proposes to note the CR
DongYeon (Samsung) replies to Zhendong (ZTE), Qian (Ericsson), Alessio (Nokia), Haris (Qualcomm), and Myungjune (LGE).
Fenqin (Huawei) comments
DongYeon (Samsung) replies to Fenqin (Huawei).
Fenqin (Huawei) responds.
Myungjune (LGE) comments
DongYeon (Samsung) provides r01, and r02 as way forward.
Myungjune (LGE) comments on r01/r02
DongYeon (Samsung) provides r03 above r01, and replies to Myungjune (LGE).
Myungjune (LGE) proposes to note this CR
==== Revisions Deadline ====
DongYeon (Samsung) asks if we can agree Rel-17 CR(S2-2108625r01) with updated as same as S2-2108624r03, and provides S2-2108625r01.
Qian (Ericsson) supports to NOTE the paper.
DongYeon (Samsung) proposes to postpone this CR.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108625 (CR) 23.502 CR3266 (Rel-17, 'A'): EPS fallback for a UE moving from EPS to 5GS with a bearer for IMS voice .. (Source: Samsung).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: The SMF informs the AMF that the EPS fallback should be triggered after registration procedure completes.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

DongYeon (Samsung) asks if we can agree Rel-17 CR(S2-2108625r01) with updated as same as S2-2108624r03, and provides S2-2108625r01.
Myungjune (LGE) comments
Qian (LGE) comments and suggests to NOTE the paper.
Qian (Ericsson) comments and suggests to NOTE the paper. Qian also indicates the source should be 'Ericsson' in previous comment (instead of LGE).
DongYeon (Samsung) asks if we can agree r01 with update the if not approved field as: Voice calls served by the EPS fallback can be dropped when the UE goes into idle mode and the UE comes back to 5GS.
DongYeon (Samsung) asks if we can agree r01 with update the if not approved field as: Voice calls served by the EPS fallback can be dropped when the UE goes into idle mode and the UE comes back to 5GS and, revise the note as: The E-UTRAN can be configured to set a longer timer for the UE with a dedicated bearer for IMS voice, so that the UE does not become RRC_IDLE.
DongYeon (Samsung) comments.
Myungjune (LGE) propose to Note this CR
Qian (Ericsson) provides comments.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108631 (DISCUSSION) Discussion on EPS fallback for a UE moving from EPS to 5GS with a bearer for IMS voice.. (Source: Samsung).
Document for: Agreement.
Abstract: This contribution discusses how to handle the EPS fallback for a UE moving from EPS to 5GS with a bearer for IMS voice to avoid voice call dropping when the response from the callee is delayed.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Alessio(Nokia) proposes to note this paper with a remark the described scenario seems unclear and actually not something Nokia believes can happen and deserve handling.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108677 (CR) 23.502 CR3272 (Rel-17, 'F'): Tunnel info release for inter system mobility with N26. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: The SMF+PGW-C holds the CN tunnel info for both side until the PDU session or its corresponding PDN connection releases.

Comment:

r02 agreed. Revised to S2-2109034.

Discussion and conclusion:

-

e-mail discussion:

Qian (Ericsson) provides comments
Fenqin (Huawei) responds
Qian (Ericsson) provides further comments
alessio(Nokia) requests to note this CR and all is revisions
Fenqin (Huawei) responds and provides r01
Alessio(nokia) thinks r01 also is not agreeable.
Fenqin (Huawei) responds and provides r02
==== Revisions Deadline ====
Fenqin (Huawei) suggest to go with r02
Qian (Ericsson) is ok with r02
==== Comments Deadline ====.

Status:

Revised to S2-2109034.

TD S2-2109034 (CR) 23.502 CR3272R1 (Rel-17, 'F'): Tunnel info release for inter system mobility with N26. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Remove the description that CN tunnel info need be released at the Idle state mobility.

Comment:

Revision of S2-2108677r02. Approved.

Discussion and conclusion:

-

Status:

Agreed.

# 6.10 Non-3GPP access specific functionality and flows

TD S2-2108728 (CR) 23.501 CR3419 (Rel-16, 'F'): R16 23.501 Clarification on security mechanism applied for non-3GPP access. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: N1 NAS signalling over non-3GPP accesses shall be protected with the same security mechanism but different NAS connection identifier defined in TS 33501[x] applied for N1 over a 3GPP access.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Stefano (Qualcomm) suggests noting this paper since it is not FASMO
==== Revisions Deadline ====
Laurent (Nokia): we support stefano (non FASMO) and object to any version of this tdoc
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108729 (CR) 23.501 CR3420 (Rel-17, 'A'): R17 23.501 Clarification on security mechanism applied for non-3GPP access. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: N1 NAS signalling over non-3GPP accesses shall be protected with the same security mechanism but different NAS connection identifier defined in TS 33501[x] applied for N1 over a 3GPP access.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Stefano (Qualcomm) suggests noting this paper since it is not FASMO
==== Revisions Deadline ====
Laurent (Nokia): we support Stefano (non FASMO) and object to any version of this tdoc
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108733 (CR) 23.502 CR3282 (Rel-17, 'A'): Correction on handover procedure and non-3GPP access. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: Correction on step 0 in procedure of handover from 5GS to EPC/ePDG; Correction on typo of N3IWF.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Laurent (Nokia): Suggests to merge this typos correction in 8927 that updates the same clauses
Marco (Huawei): we prefer to keep separate since the scope is different even if they modify the same clause and the change are not overallaping
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108734 (CR) 23.502 CR3283 (Rel-16, 'F'): Correction on handover procedure and non-3GPP access. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Correction on step 0 in procedure of handover from 5GS to EPC/ePDG; Correction on typo of N3IWF.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Laurent (Nokia): Suggests to merge this typo corrections in 8927 that updates the same clauses
Apostolis (Lenovo) comments that this CR corrects editorial errors and could be merged into 8926.
Hualin (Huawei) disagree to merge and question why changes in the same clause should be merged?
==== Revisions Deadline ====
Laurent (Nokia): objects to this Typo correction in a frozen release (I suggested to merge..)
Hualin(Huawei) question why Typo correction can' be correct.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108860 (CR) 23.501 CR3441 (Rel-16, 'F'): Layer below IPsec to enable NAT traversal for TNGF/N3IWF access. (Source: Nokia, Nokia Shanghai Bell, Lenovo, Motorola Mobility,).
Document for: Approval.
Abstract: Summary of change: The definition at the clause ¨ 8.3.2 specifying the user plane stack is the reference (as other clauses describe the location information that can be derived from the stack) and thus other clauses need to align to this clause.

Comment:

r01 agreed. Revised to S2-2109035.

Discussion and conclusion:

-

e-mail discussion:

Marco (Huawei) comments and provides r01
Fenqin (Huawei) provides r01 with an attempt to merge suggestion from 8977r01
Thomas (Nokia) comments that new version is incomplete and split into two versions not possible
suggest to focus the discussion in the 8977 thread
Laurent (Nokia): warns for a thread mismatch
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109035.

TD S2-2109035 (CR) 23.501 CR3441R1 (Rel-16, 'F'): Layer below IPsec to enable NAT traversal for TNGF/N3IWF access. (Source: Nokia, Nokia Shanghai Bell, Lenovo, Motorola Mobility,).
Document for: Approval.
Abstract: Summary of change: The definition at the clause ¨ 8.3.2 specifying the user plane stack is the reference (as other clauses describe the location information that can be derived from the stack) and thus other clauses need to align to this clause.

Comment:

Revision of S2-2108860r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108861 (CR) 23.501 CR3442 (Rel-17, 'A'): Layer below IPsec to enable NAT traversal for TNGF/N3IWF access. (Source: Nokia, Nokia Shanghai Bell, Lenovo, Motorola Mobility,).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: The definition at the clause ¨ 8.3.2 specifying the user plane stack is the reference (as other clauses describe the location information that can be derived from the stack) and thus other clauses need to align to this clause.

Comment:

r00 agreed. Revised to S2-2109036.

Discussion and conclusion:

-

Status:

Revised to S2-2109036.

TD S2-2109036 (CR) 23.501 CR3442R1 (Rel-17, 'A'): Layer below IPsec to enable NAT traversal for TNGF/N3IWF access. (Source: Nokia, Nokia Shanghai Bell, Lenovo, Motorola Mobility,).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: The definition at the clause ¨ 8.3.2 specifying the user plane stack is the reference (as other clauses describe the location information that can be derived from the stack) and thus other clauses need to align to this clause.

Comment:

Revision of S2-2108861r00. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108862 (CR) 23.502 CR3298 (Rel-16, 'F'): Layer below IPsec to enable NAT traversal for TNGF/N3IWF access. (Source: Nokia, Nokia Shanghai Bell, Lenovo, Motorola Mobility,).
Document for: Approval.
Abstract: Summary of change: The clause (23.501 ¨ 8.3.2) specifying the user plane stack is the reference (as other clauses describe the location information that can be derived from the stack) and thus other clauses need to align to this clause. Clause 5.2.2.5.4 is thus updated.

Comment:

r01 agreed. Revised to S2-2109037.

Discussion and conclusion:

-

e-mail discussion:

Stefan (Ericsson) provides r01
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109037.

TD S2-2109037 (CR) 23.502 CR3298R1 (Rel-16, 'F'): Layer below IPsec to enable NAT traversal for TNGF/N3IWF access. (Source: Nokia, Nokia Shanghai Bell, Lenovo, Motorola Mobility,).
Document for: Approval.
Abstract: Summary of change: The clause (23.501 ¨ 8.3.2) specifying the user plane stack is the reference (as other clauses describe the location information that can be derived from the stack) and thus other clauses need to align to this clause. Clause 5.2.2.5.4 is thus updated.

Comment:

Revision of S2-2108862r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108863 (CR) 23.502 CR3299 (Rel-17, 'A'): Layer below IPsec to enable NAT traversal for TNGF/N3IWF access. (Source: Nokia, Nokia Shanghai Bell, Lenovo, Motorola Mobility,).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: The clause (23.501 ¨ 8.3.2) specifying the user plane stack is the reference (as other clauses describe the location information that can be derived from the stack) and thus other clauses need to align to this clause. Clause 5.2.2.5.4 is thus updated.

Comment:

r00 agreed. Revised to S2-2109038.

Discussion and conclusion:

-

Status:

Revised to S2-2109038.

TD S2-2109038 (CR) 23.502 CR3299R1 (Rel-17, 'A'): Layer below IPsec to enable NAT traversal for TNGF/N3IWF access. (Source: Nokia, Nokia Shanghai Bell, Lenovo, Motorola Mobility,).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: The clause (23.501 ¨ 8.3.2) specifying the user plane stack is the reference (as other clauses describe the location information that can be derived from the stack) and thus other clauses need to align to this clause. Clause 5.2.2.5.4 is thus updated.

Comment:

Revision of S2-2108863r00. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108925 (DISCUSSION) Corrections to to procedures for Handover of a PDU Session between 3GPP and untrusted non-3GPP access.. (Source: Nokia, Nokia Shanghai Bell).
Document for: Discussion.
Abstract: Introduction to the 2 CR (cat F/ cat A) with the same title.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108926 (CR) 23.502 CR3310 (Rel-16, 'F'): Corrections to procedures for Handover of a PDU Session between 3GPP and untrusted non-3GPP access. (Source: Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: the SMF shall (7b) responds to the AMF with an Nsmf_PDUSession_UpdateSMContext response What the SMF shall not do is the SMF shall not execute step 11 of clause 4.3.4.2 (The SMF invokes Nsmf_PDUSession_SMContextStatusNotify to notify AMF that the SM context for this PDU Session is released) of clause 4.3.4.2.

Comment:

Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108927 (CR) 23.502 CR3311 (Rel-17, 'A'): Corrections to Handover of a PDU Session procedure between 3GPP and untrusted non-3GPP access. (Source: Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: the SMF shall (7b) responds to the AMF with an Nsmf_PDUSession_UpdateSMContext response What the SMF shall not do is the SMF shall not execute step 11 of clause 4.3.4.2 (The SMF invokes Nsmf_PDUSession_SMContextStatusNotify to notify AMF that the SM context for this PDU Session is released) of clause 4.3.4.2.

Comment:

Confirm CR Number - CR states 3310! Approved.

Discussion and conclusion:

-

e-mail discussion:

Laurent (Nokia): provides r01
Apostolis (Lenovo) notes that is a mirror to 8926 but it has a different title than 8926.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Agreed.

# 6.11 Framework functions

TD S2-2108316 (CR) 23.502 CR3221 (Rel-15, 'F'): Missing UDM service operations. (Source: Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: 'Table 5.2.3-1: NF services provided by UDM' is updated with the missing service operations. New sub-clauses are added for Nudm_SDM_ModifySubscription service operation and Nudm_EventExposure_ModifySubscription service operation.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Fenqin (Huawei) Propose to note this paper.
Pallab (Nokia) responds to Fenqin (Huawei)
Pallab (Nokia) OK to NOTE the CR. The corresponding mirror from R17 will be changed to Cat F
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108317 (CR) 23.502 CR3222 (Rel-16, 'A'): Missing UDM service operations (Mirror). (Source: Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Rel-16 mirror CR: Summary of change: 'Table 5.2.3-1: NF services provided by UDM' is updated with the missing service operations. New sub-clauses are added for Nudm_SDM_ModifySubscription service operation and Nudm_EventExposure_ModifySubscription service operation.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Fenqin (Huawei) Propose to note this paper.
Pallab (Nokia) OK to NOTE the CR. The corresponding mirror from R17 will be changed to Cat F
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108318 (CR) 23.502 CR3223 (Rel-17, 'A'): Missing UDM service operations (Mirror). (Source: Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: 'Table 5.2.3-1: NF services provided by UDM' is updated with the missing service operations. New sub-clauses are added for Nudm_SDM_ModifySubscription service operation and Nudm_EventExposure_ModifySubscription service operation.

Comment:

r01 agreed. Revised to S2-2109039.

Discussion and conclusion:

-

e-mail discussion:

Fenqin (Huawei) Propose to update this paper.
Pallab (Nokia) provides r01 with cover page changes only. CR category changed from A to F as related R15/16 CRs are not agreed.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109039.

TD S2-2109039 (CR) 23.502 CR3223R1 (Rel-17, 'F'): Missing UDM service operations. (Source: Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: 'Table 5.2.3-1: NF services provided by UDM' is updated with the missing service operations. New sub-clauses are added for Nudm_SDM_ModifySubscription service operation and Nudm_EventExposure_ModifySubscription service operation.

Comment:

Revision of S2-2108318r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

# 7 Rel-16 Maintenance for 5G (excluding 5GS_Ph1

# 7.1 Architecture enhancements for 3GPP support of advanced V2X services (eV2XARC)

This agenda item was convened by Andy Bennett (Samsung).

TD S2-2108340 (CR) 23.287 CR0170 (Rel-17, 'F'): V2X Policy provisioning request. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: - Include that the UE may send the list of stored PSIs, that includes V2X PSIs. - Add references to 23.503 where PSI handling both at PCF, UDR and the UE is described. - Remove the explict request for V2X policies from the UE at Registration.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

LaeYoung (LGE) proposes to discuss this issue first under AI#8.8 with the related tdocs to derive agreement/outcome.
Belen (Ericsson) agrees with LGE proposal
==== Revisions Deadline ====
LaeYoung (LGE) proposes to NOTE this CR at this stage. If some updates are deemed necessary, let's do it in the next meeting.
Belen (Ericsson) replies to LGE that if no conclusion is reached on this topic all related CRs should be noted.
LaeYoung (LGE) responds to Belen (Ericsson).
LaeYoung (LGE) replies to Belen (Ericsson).
Leo (Deutsche Telekom) agrees to to NOTE this CR at this stage. When necessary, it can be done in the next meeting
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108581 (CR) 23.287 CR0174 (Rel-17, 'F'): UE Policy Container with V2X Policy Provisioning Request. (Source: OPPO).
Document for: Approval.
Abstract: Summary of change: The description of the V2X Policy provisioning from Registration procedure is removed.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

LaeYoung (LGE) proposes to discuss this issue first under AI#8.8 with the related tdocs to derive agreement/outcome.
Fei (OPPO) is fine to discuss this issue in AI#8.8 first.
Steve (Huawei) comments on relationship with discussion in S2-2108284.
LaeYoung (LGE) answers to Steve (Huawei).
==== Revisions Deadline ====
LaeYoung (LGE) proposes to NOTE this CR at this stage. If some updates are deemed necessary, let's do it in the next meeting.
Leo (Deutsche Telekom) agrees to to NOTE this CR at this stage. When necessary, let's do it in the next meeting.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108415 (CR) 23.502 CR3233 (Rel-17, 'F'): Update to Nnrf_NFManagement_NFRegister service operation. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: Add missing V2X capability in PCF profile and PCF discovery Editorial change.

Comment:

r02 agreed. Revised to S2-2109040.

Discussion and conclusion:

-

e-mail discussion:

Steve (Huawei) asks questions
LaeYoung (LGE) provides r01.
Judy (Ericsson) provides r02 based on r00+'may' and responds to LaeYoung (LGE) and Steve (Huawei)
==== Revisions Deadline ====
LaeYoung (LGE) is fine with r02.
Steve (Huawei) is ok with r02.
==== Comments Deadline ====.

Status:

Revised to S2-2109040.

TD S2-2109040 (CR) 23.502 CR3233R1 (Rel-17, 'F'): Update to Nnrf_NFManagement_NFRegister service operation. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: Add missing V2X capability in PCF profile and PCF discovery Editorial change.

Comment:

Revision of S2-2108415r02. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108673 (CR) 23.287 CR0175 (Rel-17, 'F'): Correction to UE triggered Policy provisioning Procedure for V2X. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: 1. The UE sends the UE Policy Container including the UE Policy provisioning request to the AMF. 2. The AMF sends the Namf_Communication_N1MessageNotify to the PCF including the UE Policy Container received from UE.

Comment:

Covered by S2-2108392.

Discussion and conclusion:

-

e-mail discussion:

LaeYoung (LGE) proposes to merge this CR into S2-2108392 (Ericsson).
Judy (Ericsson) support LaeYoung (LGE)'s proposal and comment this is a mirror CR
LiMeng (Huawei) agrees with the merging proposal.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108674 (CR) 23.287 CR0176 (Rel-16, 'F'): Correction to UE triggered Policy provisioning Procedure for V2X. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: 1. The UE sends the UE Policy Container including the UE Policy provisioning request to the AMF. 2. The AMF sends the Namf_Communication_N1MessageNotify to the PCF including the UE Policy Container received from UE.

Comment:

Covered by S2-2108391.

Discussion and conclusion:

-

e-mail discussion:

LaeYoung (LGE) proposes to merge this CR into S2-2108391 (Ericsson).
Judy (Ericsson) support LaeYoung (LGE)'s proposal to merge this paper to 8391 and comments
LiMeng (Huawei) is fine with the merging proposal.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108391 (CR) 23.287 CR0171 (Rel-16, 'F'): Correction to UE triggered Policy provisioning Procedure. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: Correct the description related to UE Policy provisioning request. When AMF receives UL NAS TRANSPORT message carrying UE Policy container, the AMF sends Namf_Communication_N1MessageNotify instead of Npcf_UEPolicyControl_Update to PCF.

Comment:

Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108392 (CR) 23.287 CR0172 (Rel-17, 'A'): Correction to UE triggered Policy provisioning Procedure. (Source: Ericsson).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: Correct the description related to UE Policy provisioning request. When AMF receives UL NAS TRANSPORT message carrying UE Policy container, the AMF sends Namf_Communication_N1MessageNotify instead of Npcf_UEPolicyControl_Update to PCF.

Comment:

Approved.

Discussion and conclusion:

-

Status:

Agreed.

# 7.2 Wireless and Wireline Convergence for the 5G system architecture (5WWC)

TD S2-2108290 (LS IN) LS from BBF: Reply to your liaison S2-2106577. (Source: BBF (LIAISE-474)).
Document for: Information.
Abstract: Dear colleagues, The following hopefully will bring some clarity to the questions raised in your liaison S2-2106577. Q1: The scenario we envision is that for a combined AGF-UPF, the combined AGF/UPF will have local means of determining the MTU of the access link, and the 5G-RG will have the same information as a result of RFC 4638 procedures which we are documenting in issue 2 of TR-456. An FN-RG will typically default on the basis of protocol suite. In which case: - The N3 MTU is irrelevant in the downstream direction. So the combined AGF/UPF can simply assume the locally determined access MTU is the value to use for downstream traffic. - The SMF advertised value in PCO to the 5G-RG is compared with the locally determined MTU of the access link, and the 5G-RG can use the lower of the two values as the actual constraint for upstream traffic without needing to know the serving AGF/UPF deployment configuration. It can also use existing procedures to advertise this value to non-3GPP devices attached to the home network. This avoids the scenario where the N3 MTU imposes an unacceptable constraint when it is smaller than the access MTU and will be irrelevant for locally anchored PDU sessions. Local processing at the FN-RG or 5G-RG and combined AGF/UPF can address the case where the N3 MTU is greater than the access MTU. This does require the SMF to have knowledge that the given PDU session will only ever be single access, and is served by a combined AGF/UPF such that it may be locally configured to provide an appropriate MTU value. We suspect this could be achieved on the basis of selected DNN, or potentially by other means. We had anticipated the answer to Q2 and saw this as the most painless way forward in the near term to address the sensibilities of our operator community. Q2: We appreciated being advised of any developments in this area. Q3: The BBF desire to use an optional modifier to the GLI for specific FN-RG support cases will meet our needs and be transparent to 3GPP within the constraints outlined in your liaison reply. Q4: SA WG2's understanding that an FN-RG PPPoE session can only access a single DNN/Slice is correct. We cannot envision a scenario whereby other than a 1:1 cardinality of PPPoE sessions to PDU sessions could be supported. Therefore a unique session per DNN/Slice is required. We have documented procedures to extend FN-RG support to permit more than one IP session to be supported (corresponding to the same number of PDU sessions). Our use case would treat the realm portion of the NAI as the selected DNN, which we believe is aligned with TS23.003 clause 9. The username portion of the NAI is not used for this purpose. With this clarification, we reiterate our support for removing restrictions with respect to the simultaneous use of a DNN in both a URSP match descriptor and route selection descriptor. We understand this restriction has been removed, can you please confirm. Q5 & Q6: Noted. We look forward to continuing our fruitful relationship. Thanks, Lincoln Lavoie Broadband Forum Technical Committee Chair.

Comment:

Response drafted in S2-2108362. Final response in S2-2109041.

Discussion and conclusion:

-

Status:

Replied to.

TD S2-2108362 (LS OUT) [DRAFT] Reply LS on MTU and other topics. (Source: Ericsson).
Document for: Approval.
Abstract: This is a proposed reply to the BBF LS in (LIAISE-474 / S2-2108290).

Comment:

Response to S2-2108290. r00 agreed. Revised to S2-2109041.

Discussion and conclusion:

-

Status:

Revised to S2-2109041.

TD S2-2109041 (LS OUT) Reply LS on MTU and other topics. (Source: SA WG2).
Document for: Approval.
Abstract: To: BBF. CC: CT WG4, Cablelabs. Attachment: TS 23.316 CR2061 (S2-2109042).

Comment:

Revision of S2-2108362r00. Approved.

Discussion and conclusion:

-

Status:

Approved.

TD S2-2108361 (CR) 23.316 CR2061 (Rel-17, 'F'): MTU value for wireline access. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: Clarify that existing procedures for assigning MTU value applies also for wireline access, and that a suitable MTU value may be configured e.g. for a DNN used for only wireline access.

Comment:

r01 agreed. Revised to S2-2109042.

Discussion and conclusion:

-

e-mail discussion:

Laurent (Nokia): provides r01
Stefan (Ericsson) is OK with r01
Marco (Huawei) provides r02
==== Revisions Deadline ====
Laurent (Nokia): I MUCH prefer r01 and have issues with r02 and r00 that are too limitative
Stefan (Ericsson) suggest to agree r01
Marco (Huawei) I prefer r02 but I can survive to r01
==== Comments Deadline ====.

Status:

Revised to S2-2109042.

TD S2-2109042 (CR) 23.316 CR2061R1 (Rel-17, 'F'): MTU value for wireline access. (Source: Ericsson, Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: Clarify that existing procedures for assigning MTU value applies also for wireline access, and that a suitable MTU value may be configured e.g. for a DNN used for only wireline access.

Comment:

Revision of S2-2108361r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108299 (LS IN) LS from BBF: EAP-5G changes. (Source: BBF (LIAISE-477)).
Document for: Information.
Abstract: Dear colleagues, During the course of our deliberations, we have come to realize that the use of EAP-5G over PPP for W-CP initiation is an unsuitable choice for 5G-RG support over wireline. The issue we have identified is that EAP over PPP does not provide a fragmentation mechanism, and previous liaisons have advised us that the wireline MTU will be inadequate to communicate some SUCI encodings without fragmentation and reassembly support. As such we have modified our call flows to initiate the VSNP procedures to establish reliable NAS transport with fragmentation and reassembly support earlier in the call flow sequence, and communicate the key elements of the EAP-5G exchange as part of W-CP initiation dialog within our framework of VSNP messaging. We note the above change will have a number of impacts on TS23.316. We will document the updated procedures in issue 2 of TR-456, which is currently in straw ballot. We look forward to continuing our fruitful relationship. Thanks, Lincoln Lavoie Broadband Forum Technical Committee Chair.

Comment:

Response drafted in S2-2108363. Final response in S2-2109043.

Discussion and conclusion:

-

Status:

Replied to.

TD S2-2108363 (LS OUT) [DRAFT] Reply LS on EAP-5G changes. (Source: Ericsson).
Document for: Approval.
Abstract: This is a proposed reply to the BBF LS in (LIAISE-477 / S2-2108299).

Comment:

Response to S2-2108299. r00 agreed. Revised to S2-2109043.

Discussion and conclusion:

-

e-mail discussion:

Marco (Huawei) provides comments and r01
Apostolis (Lenovo) asks questions on r01
Marco (Huawei) answers to Apostolis (Lenovo)
Stefan (Ericsson) comments
Marco answers to Stefan (Ericsson) and Apostolis (Lenovo)
Stefan (Ericsson) provides r02, but prefers r00
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109043.

TD S2-2109043 (LS OUT) Reply LS on EAP-5G changes. (Source: SA WG2).
Document for: Approval.
Abstract: To: BBF. CC: CT WG4, CT WG1.

Comment:

Revision of S2-2108363r00. Approved.

Discussion and conclusion:

-

Status:

Approved.

TD S2-2108833 (CR) 23.502 CR3294 (Rel-16, 'F'): Providing UE's address to AMF during registration via trusted Non-3GPP access. (Source: Lenovo, Motorola Mobility, Nokia, Nokia Shanghai Bell, Broadcom).
Document for: Approval.
Abstract: Summary of change: In the N2 message sent in step 6b, the TNGF includes a 'null' IP address (e.g., 0.0.0.0). After the UE is assigned an IP address, the TNGF may include this address in a subsequent N2 message, e.g., in step 14.

Comment:

r01 agreed. Revised to S2-2109044.

Discussion and conclusion:

-

e-mail discussion:

Marco (Huawei) asks clarification
Apostolis (Lenovo) responds to Marco (Huawei).
Stefan (Ericsson) provides r01
Apostolis (Lenovo) is fine with r01
Marco (Huawei) comments further Apostolis (Lenovo) is fine with r01
Errata Corrige last comment: Marco (Huawei) comments further Apostolis (Lenovo)
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109044.

TD S2-2109044 (CR) 23.502 CR3294R1 (Rel-16, 'F'): Providing UE's address to AMF during registration via trusted Non-3GPP access. (Source: Lenovo, Motorola Mobility, Nokia, Nokia Shanghai Bell, Broadcom, Ericsson).
Document for: Approval.
Abstract: Summary of change: In the N2 message sent in step 6b, the TNGF includes a 'null' IP address (e.g., 0.0.0.0). After the UE is assigned an IP address, the TNGF may include this address in a subsequent N2 message, e.g., in step 14.

Comment:

Revision of S2-2108833r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108848 (CR) 23.502 CR3295 (Rel-17, 'A'): Providing UE's address to AMF during registration via trusted Non-3GPP access. (Source: Lenovo, Motorola Mobility, Nokia, Nokia Shanghai Bell, Broadcom).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: In the N2 message sent in step 6b, the TNGF includes a 'null' IP address (e.g., 0.0.0.0). After the UE is assigned an IP address, the TNGF may include this address in a subsequent N2 message, e.g., in step 14.

Comment:

r00 agreed. Revised to S2-2109045.

Discussion and conclusion:

-

e-mail discussion:

Apostolis (Lenovo) provides r01.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109045.

TD S2-2109045 (CR) 23.502 CR3295R1 (Rel-17, 'A'): Providing UE's address to AMF during registration via trusted Non-3GPP access. (Source: Lenovo, Motorola Mobility, Nokia, Nokia Shanghai Bell, Broadcom, Ericsson).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: In the N2 message sent in step 6b, the TNGF includes a 'null' IP address (e.g., 0.0.0.0). After the UE is assigned an IP address, the TNGF may include this address in a subsequent N2 message, e.g., in step 14.

Comment:

Revision of S2-2108848r00. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108929 (CR) 23.316 CR2062 (Rel-17, 'F'): Applicability of ATSSS to 5G-RG in Rel-17. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Restrict the support of ATSSS by 5G-RG to Rel-16 version of specifications.

Comment:

r01 agreed. Revised to S2-2109046.

Discussion and conclusion:

-

e-mail discussion:

Apostolis (Lenovo) asks for clarification.
Marco (Huawei) answers to Apostolis (Lenovo)
Stefan (Ericsson) provides comments
Marco (Huawei) answers to Stefan (Ericsson)
Stefan (Ericsson) replies to Marco and provides r01
Marco (Huawei) replies to Stefan (Ericsson)
Apostolis (Lenovo) asks questions.
Marco (Huawei) answers to Apostolis (Lenovo).
Apostolis (Lenovo) asks question for clarification.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109046.

TD S2-2109046 (CR) 23.316 CR2062R1 (Rel-17, 'F'): Applicability of ATSSS to 5G-RG in Rel-17. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Restrict the support of ATSSS by 5G-RG to Rel-16 version of specifications when connect to NG RAN and to Rel-17 when conenct to EPC.

Comment:

Revision of S2-2108929r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

# 7.3 Access Traffic Steering, Switch and Splitting support in the 5G system architecture (ATSSS)

TD S2-2108732 (CR) 23.501 CR3423 (Rel-16, 'F'): Correction on PMF protocol stack for non-3GPP access. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Add PMF protocol stack for trusted non-3GPP access; Add Inner IP protocol to PMF protocol stack for untrusted non-3GPP access.

Comment:

r01 agreed. Revised to S2-2109047.

Discussion and conclusion:

-

e-mail discussion:

Dario S. Tonesi (Qualcomm) asks if this is a FASMO CR and why?
Hualin(Huawei) replied to Dario S. Tonesi (Qualcomm).
Dario (Qualcomm) asks about mirror Rel-17 CR agreed in October currently marked as Cat. F
Marco (Huawei) answer to Dario (Qualcomm)
Dario (Qualcomm) replies to Marco.
Marco (Huawei) agreed to approve this R16 and to proposed a revision of last meeting approved R17 to align and to make CR 'A' directly to SA plenary as company contribution
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109047.

TD S2-2109047 (CR) 23.501 CR3423R1 (Rel-16, 'F'): Correction on PMF protocol stack for non-3GPP access. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Add PMF protocol stack for trusted non-3GPP access; Add Inner IP protocol to PMF protocol stack for untrusted non-3GPP access.

Comment:

Revision of S2-2108732r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

# 7.4 Cellular IoT support and evolution for the 5G System (5G_CIoT)

# 7.5 Enablers for Network Automation for 5G (eNA)

TD S2-2108531 (CR) 23.288 CR0473 (Rel-16, 'F'): Add the description of Wrong destination address. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: - Added the description of Expected UE Behaviour parameters of 'Wrong destination address' in Table 6.7.5.1-2; - NFs for mobility related data collection are changed from 'AMF' to 'AMF, AF, OAM', and NFs for communication related data collection are changed from 'SMF' to 'SMF, AF, UPF'; - fix the empty column in Table 6.7.5.3-3.

Comment:

r04 agreed. Revised to S2-2109048.

Discussion and conclusion:

-

e-mail discussion:

Zhang (Ericsson) ask for clarification
Wang Yuan (Huawei) replies to Zhang(Ericsson).
Zhang (Ericsson) ask further clarification
Yannick (Nokia): Nokia provides comments.
Wang Yuan (Huawei) replies to Zhang(Ericsson)/Yannick(Nokia) and provides r01.
Yannick (Nokia): Nokia questions the change in r01.
Wang Yuan (Huawei) replies to Zhang(Ericsson) and Yannick (Nokia), and provides r02.
Zhang (Ericsson) provides comments
Wang Yuan (Huawei) replies to Zhang(Ericsson), and provides r04.
Zhang (Ericsson) is OK with r04
Yannick (Nokia): Nokia is ok with r04 but also understands that the use case of wrong destination address detection is not fully specified in TS 23.288.
==== Revisions Deadline ====
Wang Yuan (Huawei) replies to Zhang(Ericsson)/Yannick(Nokia).
==== Comments Deadline ====.

Status:

Revised to S2-2109048.

TD S2-2109048 (CR) 23.288 CR0473R1 (Rel-16, 'F'): Add the description of Wrong destination address. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: - Remove the third cloumn in the Table 6.7.5.1-2; - fix the empty column in Table 6.7.5.3-3.

Comment:

Revision of S2-2108531r04. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108532 (CR) 23.288 CR0474 (Rel-17, 'A'): Add the description of Wrong destination address. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: - Added the description of Expected UE Behaviour parameters of 'Wrong destination address' in Table 6.7.5.1-2; - NFs for mobility related data collection are changed from 'AMF' to 'AMF, AF, OAM', and NFs for communication related data collection are changed from 'SMF' to 'SMF, AF, UPF'; - fix the empty column in Table 6.7.5.3-3.

Comment:

r00 agreed. Revised to S2-2109049.

Discussion and conclusion:

-

e-mail discussion:

Wang Yuan (Huawei) provides r01 (the mirror CR) based on S2-2108531r04.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109049.

TD S2-2109049 (CR) 23.288 CR0474R1 (Rel-17, 'A'): Add the description of Wrong destination address. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: - Remove the third cloumn in the Table 6.7.5.1-2; - fix the empty column in Table 6.7.5.3-3.

Comment:

Revision of S2-2108532r00. Approved.

Discussion and conclusion:

-

Status:

Agreed.

# 7.6 Enhancement to the 5GC Location Services (5G_eLCS)

TD S2-2108354 (CR) 23.273 CR0193R2 (Rel-16, 'F'): Clarification on use of service type and service identity in MO-LR procedure. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: - Clarify in clause 6.2 that between UE and HGMLC, 'Service Type' is signaled and that HGMLC maps this parameter to 'Service Identity' before signaling to LCS Client or AF (Via NEF). - The Ngmlc_Location_LocationUpdate service operation is ammended to include both Service Type' and 'Service Identity' as optional input. - Clause 6.2 Step 8 is corrected such HGMLC address may be retrieved from NRF. - Clause 6.2 Step 8 is corrected such information is received from AMF.

Comment:

Revision of (Endorsed) S2-2107864 from S2#147E. r01 agreed. Revised to S2-2109050.

Discussion and conclusion:

-

e-mail discussion:

Yunjing (CATT) provides r01.
Cai Simon (Nokia) provides comments
Runze (Huawei) supports Simon(Nokia)'s View
Æke (Ericsson) provides clarification to Simon and Runze
==== Revisions Deadline ====
Cai Simon (Nokia) provides further comments
Stephen (Qualcomm) prefers the r01 and comments on Service Type vs Service Identity
Æke (Ericsson) Also prefers r01
Runze(Huawei)thanks Ake for the clarification, and supports r01.
Æke (Ericsson) supports r01
==== Comments Deadline ====
Cai Simon (Nokia) prefers to note the CR.

Status:

Revised to S2-2109050.

TD S2-2109050 (CR) 23.273 CR0193R3 (Rel-16, 'F'): Clarification on use of service type and service identity in MO-LR procedure. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: - Clarify in clause 6.2 that between UE and HGMLC, 'Service Type' is signaled and that HGMLC maps this parameter to 'Service Identity' before signaling to LCS Client or AF (Via NEF). - The Ngmlc_Location_LocationUpdate service operation is ammended to include both Service Type' and 'Service Identity' as optional input. - Clause 6.2 Step 8 is corrected such HGMLC address may be retrieved from NRF. - Clause 6.2 Step 8 is corrected such information is received from AMF.

Comment:

Revision of S2-2108354r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108355 (CR) 23.273 CR0194R1 (Rel-17, 'A'): Clarification on use of service type and service identity in MO-LR procedure. (Source: Ericsson).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: - Clarify in clause 6.2 that between UE and HGMLC, 'Service Type Identity' is signaled and that HMLC maps this parameter to 'Service Identity' before signaling to LCS Client or AF (Via NEF). - The Ngmlc_Location_LocationUpdate service operation is ammended to include both Service Type Identity' and 'Service Identity' as optional input. - Clause 6.2 Step 8 is corrected such HGMLC address may be retrieved from NRF. - Clause 6.2 Step 8 is corrected such information is received from AMF.

Comment:

Revision of (Postponed) S2-2107125 from S2#147E. r00 agreed. Revised to S2-2109051.

Discussion and conclusion:

-

Status:

Revised to S2-2109051.

TD S2-2109051 (CR) 23.273 CR0194R2 (Rel-17, 'A'): Clarification on use of service type and service identity in MO-LR procedure. (Source: Ericsson).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: - Clarify in clause 6.2 that between UE and HGMLC, 'Service Type Identity' is signaled and that HMLC maps this parameter to 'Service Identity' before signaling to LCS Client or AF (Via NEF). - The Ngmlc_Location_LocationUpdate service operation is ammended to include both Service Type Identity' and 'Service Identity' as optional input. - Clause 6.2 Step 8 is corrected such HGMLC address may be retrieved from NRF. - Clause 6.2 Step 8 is corrected such information is received from AMF.

Comment:

Revision of S2-2108355r00. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108837 (CR) 23.273 CR0214 (Rel-16, 'F'): Update MO-LR procedure. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Update the MO-LR procedure, to add the interaction between the AMF and UDM.

Comment:

r04 agreed. Revised to S2-2109052.

Discussion and conclusion:

-

e-mail discussion:

Æke (Ericsson) Comments CR is not needed.
Runze (Huawei) replies to Ake (Ericsson) and provides r01
Æke (Ericsson) Comments CR still not needed and r02 incorrect
Runze (Huawei) replies to Ake, and provides r03.
Æke (Ericsson) acknowledge need of clarification and provides r04
==== Revisions Deadline ====
Runze (Huawei) supports r04
==== Comments Deadline ====.

Status:

Revised to S2-2109052.

TD S2-2109052 (CR) 23.273 CR0214R1 (Rel-16, 'F'): Update MO-LR procedure. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Update the MO-LR procedure, to addclarification that AMF determines whether the UE is allowed to access the requested MO-LR services by checking the Mobile Originated data retrived from UDM during the UE Registration Procedure, as defined in TS 23.502[19] clause 4.2.2.2.2.

Comment:

Revision of S2-2108837r04. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108838 (CR) 23.273 CR0215 (Rel-17, 'A'): Update MO-LR procedure. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: Update the MO-LR procedure, to add the interaction between the AMF and UDM.

Comment:

r00 agreed. Revised to S2-2109053.

Discussion and conclusion:

-

Status:

Revised to S2-2109053.

TD S2-2109053 (CR) 23.273 CR0215R1 (Rel-17, 'A'): Update MO-LR procedure. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: Update the MO-LR procedure, to addclarification that AMF determines whether the UE is allowed to access the requested MO-LR services by checking the Mobile Originated data retrived from UDM during the UE Registration Procedure, as defined in TS 23.502[19] clause 4.2.2.2.2.

Comment:

Revision of S2-2108838r00. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108356 (CR) 23.273 CR0203 (Rel-16, 'F'): Remove SUPI in response to Nudm_SDM. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: - In in clause 6.1.2 step 2, delete SUPI as returned parameter.- In in clause 6.1.2 step 3, add GPSI as allowed input parameter.

Comment:

Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108357 (CR) 23.273 CR0204 (Rel-17, 'A'): Remove SUPI in response to Nudm_SDM. (Source: Ericsson).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: - In in clause 6.1.2 step 2, delete SUPI as returned parameter.- In in clause 6.1.2 step 3, add GPSI as allowed input parameter.

Comment:

Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108751 (CR) 23.273 CR0207 (Rel-16, 'F'): Correct the allowed access type for event report. (Source: CATT).
Document for: Approval.
Abstract: Summary of change: Correct the allowed access types for event report.

Comment:

Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108752 (CR) 23.273 CR0208 (Rel-17, 'A'): Correct the allowed access type for event report. (Source: CATT).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: Correct the allowed access types for event report.

Comment:

Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108754 (CR) 23.273 CR0210 (Rel-16, 'F'): Update the location service operations to add service identity and service type. (Source: CATT).
Document for: Approval.
Abstract: Summary of change: Update Namf_Location_ProvidePositioningInfo to add service type as the input (optional) parameter and update Nnef_Location_LocationUpdateNotify to add the service identity as the input (optional) parameter.

Comment:

Confirm Specification Number - CR states 23.502!. Confirm Spec version used - CR states 16.10.0! r01 agreed. Revised to S2-2109054.

Discussion and conclusion:

-

e-mail discussion:

Æke (Ericsson) provides r01
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109054.

TD S2-2109054 (CR) 23.502 CR3315 (Rel-16, 'F'): Update the location service operations to add service identity and service type. (Source: CATT, Ericsson).
Document for: Approval.
Abstract: Summary of change: Update Namf_Location_ProvidePositioningInfo to add service type as the input (optional) parameter and update Nnef_Location_LocationUpdateNotify to add the service identity as the input (optional) parameter. Rename 'External Client' to 'LCS Client'.

Comment:

Revision of S2-2108754r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108755 (CR) 23.273 CR0211 (Rel-17, 'A'): Update the location service operations to add service identity and service type. (Source: CATT).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: Update Namf_Location_ProvidePositioningInfo to add service type as the input (optional) parameter and update Nnef_Location_LocationUpdateNotify to add the service identity as the input (optional) parameter.

Comment:

Confirm Specification Number - CR states 23.502! Revised to S2-2109055.

Discussion and conclusion:

-

Status:

Revised to S2-2109055.

TD S2-2109055 (CR) 23.502 CR3316 (Rel-17, 'A'): Update the location service operations to add service identity and service type. (Source: CATT).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: Update Namf_Location_ProvidePositioningInfo to add service type as the input (optional) parameter and update Nnef_Location_LocationUpdateNotify to add the service identity as the input (optional) parameter. Rename 'External Client' to 'LCS Client'.

Comment:

Revision of S2-2108755. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108835 (CR) 23.273 CR0212 (Rel-16, 'F'): Replacing NR-RAN with ng-eNB in case of EDT reporting of LCS event. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Replace NG-RAN with ng-eNB in the procedure of 'Event Reporting with no change of LMF'.

Comment:

r01 agreed. Revised to S2-2109056.

Discussion and conclusion:

-

e-mail discussion:

Stephen (Qualcomm) provides comments and an r01
Æke (Ericsson) Support r01 provided by Qualcomm
Stephen (Qualcomm) provide a correction for AI#7.6
Runze (Huawei) supports R01.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109056.

TD S2-2109056 (CR) 23.273 CR0212R1 (Rel-16, 'F'): Replacing NR-RAN with ng-eNB in case of EDT reporting of LCS event. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Replace NG-RAN with ng-eNB in the procedure of 'Event Reporting with no change of LMF'.

Comment:

Revision of S2-2108835r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108836 (CR) 23.273 CR0213 (Rel-17, 'A'): Replacing NR-RAN with ng-eNB in case of EDT reporting of LCS event. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: Replace NG-RAN with ng-eNB in the procedure of 'Event Reporting with no change of LMF'.

Comment:

WI Code should be 5G_eLCS for mirror CR. r00 agreed. Revised to S2-2109057.

Discussion and conclusion:

-

Status:

Revised to S2-2109057.

TD S2-2109057 (CR) 23.273 CR0213R1 (Rel-17, 'A'): Replacing NR-RAN with ng-eNB in case of EDT reporting of LCS event. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: Replace NG-RAN with ng-eNB in the procedure of 'Event Reporting with no change of LMF'.

Comment:

Revision of S2-2108836r00. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108839 (CR) 23.273 CR0216 (Rel-16, 'F'): Clarification on support of SNPN for R16 LCS. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: It is worth to clarify that LCS features defined in this specification are applicable to PLMN(s) and to SNPN(s).

Comment:

CC#2: Noted.

Discussion and conclusion:

CC#2: Deutsche Telekom sustained their objection to all revisions of this Rel-16 CR as there are no location-based requirements in Rel-16. This was then noted.

e-mail discussion:

Yunjing (CATT) provides comments.
Josep (DT) comments.
Walter Dees (Philips) requests clarification
Yunjing (CATT) replies to Walter Dees (Philips).
Stephen (Qualcomm) provides comments
Josep (DT) objects to this CR.
Runze (Huawei) replies to Josep.
==== Revisions Deadline ====
Josep (DT) replies that there is no problem to solve for R16.
Cai Simon (Nokia) agrees with Stephen (Qualcomm) for precise R17 only statement
Runze (Huawei) proposes a revision, and the content aligns with the R17 CR 2108753r05
Yunjing (CATT) is fine with r01.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108840 (CR) 23.273 CR0217 (Rel-17, 'A'): Clarification on support of SNPN for R16 LCS. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: It is worth to clarify that LCS features defined in this specification are applicable to PLMN(s) and to SNPN(s).

Comment:

CC#2: Noted.

Discussion and conclusion:

CC#2: This mirror CR was noted.

e-mail discussion:

Josep (DT) objects to this (mirror) CR.
==== Revisions Deadline ====
Runze (Huawei) proposes to merge this CR into S2-2108357.
Yunjing (CATT) is fine to merge this CR into S2-2108753.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108843 (CR) 23.273 CR0219 (Rel-16, 'F'): Removal of description that LMF ID is provided by UE. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Propose to remove the case LMF ID can be provided by UE.

Comment:

r02 agreed. Revised to S2-2109058.

Discussion and conclusion:

-

e-mail discussion:

Æke (Ericsson) Suggest CR not needed
Runze (Huawei) replies to Ake.
Stephen (Qualcomm) provides comments
Runze (Huawei) provides r01
Stephen (Qualcomm) can agree the r01
Æke (Ericsson) Provide r02 with editorial improvements
Runze (Huawei) agrees with R02
==== Revisions Deadline ====
Stephen (Qualcomm) can agree the r02
==== Comments Deadline ====.

Status:

Revised to S2-2109058.

TD S2-2109058 (CR) 23.273 CR0219R1 (Rel-16, 'F'): Removal of description that LMF ID is provided by UE. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Clarify the scenario UE provides LMF ID is not relevant to LMF selection. It is for routing the LPP message to LMF by AMF. Redundant texts are removed for LMF selection.

Comment:

Revision of S2-2108843r02. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108844 (CR) 23.273 CR0220 (Rel-17, 'A'): Removal of description that LMF ID is provided by UE. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: Propose to remove the case LMF ID can be provided by UE.

Comment:

r00 agreed. Revised to S2-2109059.

Discussion and conclusion:

-

Status:

Revised to S2-2109059.

TD S2-2109059 (CR) 23.273 CR0220R1 (Rel-17, 'A'): Removal of description that LMF ID is provided by UE. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: Clarify the scenario UE provides LMF ID is not relevant to LMF selection. It is for routing the LPP message to LMF by AMF. Redundant texts are removed for LMF selection.

Comment:

Revision of S2-2108844r00. Approved.

Discussion and conclusion:

-

Status:

Agreed.

# 7.7 5GS Enhanced support of Vertical and LAN Services (Vertical_LAN)

TD S2-2108307 (CR) 23.501 CR3356 (Rel-16, 'F'): Deletion of selected enrties in UMIC/PMIC data structures. (Source: Intel, NTT DOCOMO).
Document for: Approval.
Abstract: Summary of change: Clarifies the use of PMIC and UMIC for the deletion of selected entries in the UMIC/PMIC data structures that are lists of variable size.

Comment:

r03 agreed. Revised to S2-2109060.

Discussion and conclusion:

-

e-mail discussion:

Devaki (Nokia) comments and wonders if this CR is really FASMO for Rel-16?
Saso (Intel) replies to Devaki (Nokia); provides r01.
Sang-Jun (Samsung) asks for clarification whether S2-2107615 in reason for change is also applied to Rel-16.
Saso (Intel) replies to Sang-Jun (Samsung).
Sebastian (Qualcomm) comments
Saso (Intel) provides r02.
Zhendong (ZTE): ask qusetion for clarification
Saso (Intel) replie to Zhendong (ZTE); provides r03
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109060.

TD S2-2109060 (CR) 23.501 CR3356R1 (Rel-16, 'F'): Deletion of selected enrties in UMIC/PMIC data structures. (Source: Intel, NTT DOCOMO).
Document for: Approval.
Abstract: Summary of change: Clarifies the use of PMIC and BMIC for the deletion of selected entries in the UMIC/PMIC data structures that are lists of variable size.

Comment:

Revision of S2-2108307r03. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108319 (CR) 23.501 CR3360 (Rel-16, 'F'): Mapping TSCAI between TSN GM clock and 5GS clock. (Source: NTT DOCOMO).
Document for: Approval.
Abstract: Summary of change: Clarify in clause 5.27.2 that the SMF provisions the UPF to report the clock drifting between 5G clock and the TSN clock of the TSN time domain number that is configured to the NW-TT. In the case of clock drifting between TSN GM clock of the configured TSN time domain number and 5G clock, the UPF sends a report to the SMF.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Chunshan (Tencent) provides comments.
Devaki (Nokia) objects as this CR is NOT a FASMO CR, also proposal seems unnecessary.
Jari (NTT DOCOMO responds.
Jari (NTT DOCOMO) responds and disagrees with Devaki
Devaki (Nokia) replies.
Jari (NTT DOCOMO) responds to Devaki.
Chunshan (Tencent) responses to Jari (NTT DOCOMO) and comments that the proposed solution cannot work.
Chunshan (Tencent) response to Jari (NTT DOCOMO)
Jari (NTT DOCOMO) responds to Chunshan
Chunshan (Tencent) asks Jari (NTT DOCOMO) to check further.
Sebastian (Qualcomm) comments
Chunshan (Tencent) responses to Sebastian (Qualcomm) comments.
Sebastian (Qualcomm) replies to Tencent
Chunshan (Tencent) responses to Sebastian (Qualcomm) .
Sebastian (Qualcomm) replies to Chunshan
Jari (NTT DOCOMO) replies to Chunshan
Chunshan (Tencent) responses to Jari (NTT DOCOMO) .
Shabnam (Ericsson) supports position explained by Qualcomm and DoCoMo delegates in this discussion.
Zhendong (ZTE): provides comments
Jari (NTT DOCOMO) replies to Zhendong
==== Revisions Deadline ====
Chunshan (Tencent) objects this CR and all revisions.
Jari (NTT DOCOMO) seeks clarification from Chunshan
Chunshan (Tencent) responses to Jari (NTT DOCOMO).
Jari (NTT DOCOMO) proposes to discuss this in CC#2, responds to Chunshan
Jari (NTT DOCOMO )responds to Chunshan
Chunshan (Tencent) responses inline to Jari (NTT DOCOMO) .
Jari (NTT DOCOMO) responds to Chunshan.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108695 (CR) 23.501 CR3414 (Rel-17, 'F'): Mapping TSCAI between TSN GM clock and 5GS clock. (Source: NTT DOCOMO).
Document for: Approval.
Abstract: Summary of change: In clause 5.27.2.3: Clarify that the AF provides to the TSCTSF a Burst Arrival Time or Periodicity without corresponding Time Domain, the TSCTSF sets the Time Domain = '5GS' in the TSC Assistance Container. In clause 5.27.2.4: Clarify that if Time Domain information is not provided in the TSC Assistance Container, and if the SMF has not provisioned the clock drift reports to the UPF, the SMF provisions the UPF to report the clock drifting between 5G clock and the TSN clock for the TSN time domain number that is configured to the NW-TT (Case: TSN AF). Clarify that if a Time Domain is provided in the TSC Assistance Container, and if the SMF has not provisioned the clock drift reports to the UPF for the given Time Domain, the SMF provisions the UPF to report the clock drifting between 5G clock and the TSN clock for the given Time Domain number (Case: TSCTSF) Clarify that if the Time Domain in the clock drift report matches with the Time Domain in the TSC Assistance Container (Case: TSCTSF), or Time Domain information is not provided in the TSC Assistance Container (Case: TSN AF), then SMF may adjust the TSCAI information so that it reflects the 5GS Clock. Clarify that if the Time Domain in the TSC Assistance Container is set to a value = '5GS', then the TSCAI information will be used without adjustment (Case: TSCTSF).

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Chunshan (Tencent) provides the same comments on the S2-2108319, let us discuss the same issues in S2-2108319.
Shabnam (Ericsson) provides r01, to add 'For TSN' in the newly added text.
Jari (NTT DOCOMO) comments
Jari (NTT DOCOMO) provides r02
==== Revisions Deadline ====
Chunshan (Tencent) objects this CR and all revisions.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108321 (CR) 23.502 CR3224 (Rel-16, 'F'): Mapping TSCAI between TSN GM clock and 5GS clock. (Source: NTT DOCOMO).
Document for: Approval.
Abstract: Summary of change: In 4.4.3.1 (N4 Association Setup Procedure), the SMF may indicate a TSN time domain number = 'configured' in the clock drift report request; in this case the UPF shall report the clock drift for the TSN time domain that is configured to the NW-TT. Add a possibility for the SMF to omit the TSN time domain number in the clock drift request; in this case the UPF shall report the clock drift for all TSN time domains the UPF is connected to (this is alignment with Stage 3). In 4.4.3.2 (N4 Association Update Procedure), add a reference to clause 4.4.3.1 for provisioning the clock drift reports. When provisioning the clock drift reports to UPF in clause F.1, replace 'one or more TSN working domains' with the TSN time domain number = 'configured'.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Chunshan (Tencent) provides the same comments on the S2-2108319, let us discuss the same issues in S2-2108319.
Devaki (Nokia) objects as this CR is NOT a FASMO CR, also proposal seems unnecessary. Same reason as for 8319
Shabnam (Ericsson) thinks it is useful clarification to have, specially seeing the discussion in parallel for 23.501 CR, which shows there is potential for error.
Shabnam (Ericsson) provides r01, correcting TSN working domain to TSN time domain in one place and cosigning.
==== Revisions Deadline ====
Chunshan (Tencent) objects this CR and all revisions.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108323 (CR) 23.502 CR3225 (Rel-17, 'A'): Mapping TSCAI between TSN GM clock and 5GS clock. (Source: NTT DOCOMO).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: In 4.4.3.1 (N4 Association Setup Procedure), the SMF may indicate a TSN time domain number = 'configured' in the clock drift report request; in this case the UPF shall report the clock drift for the TSN time domain that is configured to the NW-TT. Add a possibility for the SMF to omit the TSN time domain number in the clock drift request; in this case the UPF shall report the clock drift for all TSN time domains the UPF is connected to (this is alignment with Stage 3). In 4.4.3.2 (N4 Association Update Procedure), add a reference to clause 4.4.3.1 for provisioning the clock drift reports. When provisioning the clock drift reports to UPF in clause F.1, replace 'one or more TSN working domains' with the TSN time domain number = 'configured'.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Devaki (Nokia) objects as this CR is NOT a FASMO CR, also proposal seems unnecessary also for Rel-17 in our view. Same reason as for 8319/21.
Jari (NTT DOCOMO) disagrees with Devaki, the same reason as for 8319/21.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108459 (CR) 23.502 CR3241 (Rel-16, 'F'): RID Update for SNPN UEs. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: The CP procedure for UE Parameter Update is updated so that it is possible to update the Routing Indicator in the ME.

Comment:

r02 agreed. Revised to S2-2109061.

Discussion and conclusion:

-

e-mail discussion:

Devaki (Nokia) provides r01, supportive of the proposal.
Fei (OPPO) provides r02.
Peter Hedman (Ericsson) provides comment
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109061.

TD S2-2109061 (CR) 23.502 CR3241R1 (Rel-16, 'F'): RID Update for SNPN UEs. (Source: Ericsson, Nokia, Nokia Shanghai Bell, OPPO).
Document for: Approval.
Abstract: Summary of change: The CP procedure for UE Parameter Update is updated so that it is possible to update the Routing Indicator in the ME.

Comment:

Revision of S2-2108459r02. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108460 (CR) 23.502 CR3242 (Rel-17, 'A'): RID Update for SNPN UEs. (Source: Ericsson).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: The CP procedure for UE Parameter Update is updated so that it is possible to update the Routing Indicator in the ME.

Comment:

r00 agreed. Revised to S2-2109062.

Discussion and conclusion:

-

e-mail discussion:

Devaki (Nokia) supports the CR, wish to cosign.
Peter Hedman (Ericsson) provides r01
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109062.

TD S2-2109062 (CR) 23.502 CR3242R1 (Rel-17, 'A'): RID Update for SNPN UEs. (Source: Ericsson, Nokia, Nokia Shanghai Bell, OPPO).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: The CP procedure for UE Parameter Update is updated so that it is possible to update the Routing Indicator in the ME.

Comment:

Revision of S2-2108460r00. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108565 (CR) 23.501 CR3392 (Rel-16, 'F'): Correction for CAG restrictions with emergency services. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: For normally registered UEs that have an emergency PDU session established, if UE access is not allowed, then all non-emergency PDU Sessions are released and the UE behaves as registered for emergency services.

Comment:

r04 agreed. Revised to S2-2109063.

Discussion and conclusion:

-

e-mail discussion:

George Foti (Ericsson) provides r01. Minor clarifications and co-signed as well
Fei (OPPO) provides r02.
Devaki (Nokia) comments.
Qianghua (Huawei) provides r03
George (Ericsson) provides r04. Did some minor editorial linguistic changes. The sentence is too long.
Fei (OPPO) is fine with r04.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109063.

TD S2-2109063 (CR) 23.501 CR3392R1 (Rel-16, 'F'): Correction for CAG restrictions with emergency services. (Source: Huawei, HiSilicon, Ericsson, OPPO, Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: For normally registered UEs that have an emergency PDU session established, if UE access is not allowed, then all non-emergency PDU Sessions are released and the UE behaves as registered for emergency services.

Comment:

Revision of S2-2108565r04. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108566 (CR) 23.501 CR3393 (Rel-17, 'A'): Correction for CAG restrictions with emergency services. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: For normally registered UEs that have an emergency PDU session established, if UE access is not allowed, then all non-emergency PDU Sessions are released and the UE behaves as registered for emergency services.

Comment:

r00 agreed. Revised to S2-2109064.

Discussion and conclusion:

-

Status:

Revised to S2-2109064.

TD S2-2109064 (CR) 23.501 CR3393R1 (Rel-17, 'A'): Correction for CAG restrictions with emergency services. (Source: Huawei, HiSilicon, Ericsson, OPPO, Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: For normally registered UEs that have an emergency PDU session established, if UE access is not allowed, then all non-emergency PDU Sessions are released and the UE behaves as registered for emergency services.

Comment:

Revision of S2-2108566r00. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108567 (CR) 23.502 CR3255 (Rel-16, 'F'): Correction for CAG restrictions with emergency services. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: For normally registered UEs that have an emergency PDU session established, if UE access is not allowed, then all non-emergency PDU Sessions are released and the UE behaves as registered for emergency services.

Comment:

r01 agreed. Revised to S2-2109065.

Discussion and conclusion:

-

e-mail discussion:

Devaki (Nokia) comments that this CR is not needed as existing Note 3 covers the scenario already.
Qianghua (Huawei) replies
Haris(Qualcomm) provides r01
Qianghua (Huawei) OK with r01
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109065.

TD S2-2109065 (CR) 23.502 CR3255R1 (Rel-16, 'F'): Correction for CAG restrictions with emergency services. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: For normally registered UEs that have an emergency PDU session established, if UE access is not allowed, then all non-emergency PDU Sessions are released and the UE behaves as registered for emergency services.

Comment:

Revision of S2-2108567r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108568 (CR) 23.502 CR3256 (Rel-17, 'A'): Correction for CAG restrictions with emergency services. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: For normally registered UEs that have an emergency PDU session established, if UE access is not allowed, then all non-emergency PDU Sessions are released and the UE behaves as registered for emergency services.

Comment:

r00 agreed. Revised to S2-2109066.

Discussion and conclusion:

-

e-mail discussion:

Devaki (Nokia) comments that this CR is not needed as existing Note 3 covers the scenario already. Same comment as 8567.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109066.

TD S2-2109066 (CR) 23.502 CR3256R1 (Rel-17, 'A'): Correction for CAG restrictions with emergency services. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: For normally registered UEs that have an emergency PDU session established, if UE access is not allowed, then all non-emergency PDU Sessions are released and the UE behaves as registered for emergency services.

Comment:

Revision of S2-2108568r00. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108846 (CR) 23.501 CR3437 (Rel-16, 'F'): Adding AdminCycleTimeExtension and PSFPAdminCycleTimeExtension to PMIC. (Source: Qualcomm).
Document for: Approval.
Abstract: Summary of change: Clause 5.28.3.1: Add AdminCycleTimeExtension and PSFPAdminCycleTimeExtension to Table 5.28.3.1-1; correct reference for AdminControlListLength in Table 5.28.3.1-1.

Comment:

Approved.

Discussion and conclusion:

-

e-mail discussion:

Devaki (Nokia) wonders if the CR is FASMO really as the added parameters are extension parameters and it could be added from Rel-17 only?
Sebastian (Qualcomm) explains why the CR is FASMO
Zhendong (ZTE): provides comments.
Sebastian (Qualcomm) replies to ZTE
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Agreed.

TD S2-2108864 (CR) 23.501 CR3443 (Rel-17, 'A'): Adding AdminCycleTimeExtension and PSFPAdminCycleTimeExtension to PMIC. (Source: Qualcomm).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: Clause 5.28.3.1: Add AdminCycleTimeExtension and PSFPAdminCycleTimeExtension to Table 5.28.3.1-1; correct reference for AdminControlListLength in Table 5.28.3.1-1.

Comment:

Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108867 (CR) 23.501 CR3444 (Rel-16, 'F'): Time conversion for Tick granularity and PSFPTickGranularity. (Source: Qualcomm).
Document for: Approval.
Abstract: Summary of change: Clause 5.28.1: - Clarify that DS-TT and NW-TT report Tick granularity and PSFPTickGranularity to the TSN AF relative to the time base of the TSN GM clock (identified by the TSN time domain number received in PMIC). - Clarify that notifications for changes if Tick granularity and PSFPTickGranularity are based on TickGranularityDelayDeltaThreshold and PSFPTickGranularityDelayDeltaThreshold. This is to avoid too frequent updates to TSN AF, e.g. if the tick granularity changes as a result of the time conversion from 5GS time to TSN time (i.e. due to a change of the cumulative rate ratio). Clause 5.28.3.1: Add TickGranularityDelayDeltaThreshold and PSFPTickGranularityDelayDeltaThreshold to Table 5.28.3.1-1.

Comment:

Postponed.

Discussion and conclusion:

-

e-mail discussion:

Chunshan (Tencent) have some questions.
Jari (NTT DOCOMO) proposes to note
Sebastian (Qualcomm) replies to Tencent
Chunshan (Tencent) responses to Sebastian (Qualcomm)
Sebastian (Qualcomm) replies to Jari and provides r01
Chunshan (Tencent) responses to Sebastian (Qualcomm).
==== Revisions Deadline ====
Devaki (Nokia) proposes to postpone the paper (objects to the revisions).
Sebastian (Qualcomm) replies to Nokia
==== Comments Deadline ====.

Status:

Postponed.

TD S2-2108870 (CR) 23.501 CR3445 (Rel-17, 'A'): Time conversion for Tick granularity and PSFPTickGranularity. (Source: Qualcomm).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: Clause 5.28.1: - Clarify that DS-TT and NW-TT report Tick granularity and PSFPTickGranularity to the TSN AF relative to the time base of the TSN GM clock (identified by the TSN time domain number received in PMIC). - Clarify that notifications for changes if Tick granularity and PSFPTickGranularity are based on TickGranularityDelayDeltaThreshold and PSFPTickGranularityDelayDeltaThreshold. This is to avoid too frequent updates to TSN AF, e.g. if the tick granularity changes as a result of the time conversion from 5GS time to TSN time (i.e. due to a change of the cumulative rate ratio). Clause 5.28.3.1: Add TickGranularityDelayDeltaThreshold and PSFPTickGranularityDelayDeltaThreshold to Table 5.28.3.1-1.

Comment:

Postponed.

Discussion and conclusion:

-

Status:

Postponed.

TD S2-2108871 (CR) 23.501 CR3446 (Rel-16, 'F'): Bridge delay calculation and TSCAI calculation if UE-DS-TT residence time has not been provided. (Source: Qualcomm Incorporated).
Document for: Approval.
Abstract: Summary of change: Clause 5.27.2: Clarify that 'If the UE-DS-TT residence time has not been provided by the UE, then the SMF uses a locally configured UE-DS-TT residence time for the correction of the Burst Arrival Time ' Clause 5.27.5: If the UE-DS-TT residence time has not been provided by the UE, then the TSN AF uses a locally configured minimum UE-DS-TT residence time for the calculation of independentDelayMin and a locally configured maximum UE-DS-TT residence time for the calculation of independentDelayMax.

Comment:

r02 agreed. Revised to S2-2109067.

Discussion and conclusion:

-

e-mail discussion:

Devaki (Nokia) objects to the CR as assuming per UE configuration in the network would be wrong.
Sebastian (Qualcomm) responds to Nokia and clarifies that the CR does not propose per UE configuration
Jari (NTT DOCOMO) comments
Sebastian (Qualcomm) replies to NTT DOCOMO
Devaki (Nokia) replies.
Sebastian (Qualcomm) replies to Nokia
Sebastian (Qualcomm) replies and provides r01
Devaki (Nokia) fine with r01.
Zhendong (ZTE): provides comments
Qianghua (Huawei) comments
Sebastian (Qualcomm) replies to ZTE
Sebastian (Qualcomm) replies to Huawei and provides r02
Sebastian (Qualcomm) replies to Devaki
==== Revisions Deadline ====
Qianghua (Huawei) fine with r02
==== Comments Deadline ====.

Status:

Revised to S2-2109067.

TD S2-2109067 (CR) 23.501 CR3446R1 (Rel-16, 'F'): Bridge delay calculation and TSCAI calculation if UE-DS-TT residence time has not been provided. (Source: Qualcomm Incorporated).
Document for: Approval.
Abstract: Summary of change: Clause 5.27.2: Clarify that ' How the SMF corrects the Burst Arrival Time if the UE-DS-TT residence time has not been provided by the UE is up to SMF implementation ' Clause 5.27.5: If the UE-DS-TT residence time has not been provided by the UE, then the TSN AF uses a locally configured minimum UE-DS-TT residence time for the calculation of independentDelayMin and a locally configured maximum UE-DS-TT residence time for the calculation of independentDelayMax.

Comment:

Revision of S2-2108871r02. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108872 (CR) 23.501 CR3447 (Rel-17, 'A'): Bridge delay calculation and TSCAI calculation if UE-DS-TT residence time has not been provided. (Source: Qualcomm Incorporated).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: Clause 5.27.2: Clarify that 'If the UE-DS-TT residence time has not been provided by the UE, then the SMF uses a locally configured UE-DS-TT residence time for the correction of the Burst Arrival Time ' Clause 5.27.5: If the UE-DS-TT residence time has not been provided by the UE, then the TSN AF uses a locally configured minimum UE-DS-TT residence time for the calculation of independentDelayMin and a locally configured maximum UE-DS-TT residence time for the calculation of independentDelayMax.

Comment:

r00 agreed. Revised to S2-2109068.

Discussion and conclusion:

-

e-mail discussion:

Devaki (Nokia) objects to the CR, same reason as 8871.
Sebastian (Qualcomm) provides r01
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109068.

TD S2-2109068 (CR) 23.501 CR3447R1 (Rel-17, 'A'): Bridge delay calculation and TSCAI calculation if UE-DS-TT residence time has not been provided. (Source: Qualcomm Incorporated).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: Clause 5.27.2: Clarify that 'How the SMF corrects the Burst Arrival Time if the UE-DS-TT residence time has not been provided by the UE is up to SMF implementation'. Clause 5.27.5: If the UE-DS-TT residence time has not been provided by the UE, then the TSN AF uses a locally configured minimum UE-DS-TT residence time for the calculation of independentDelayMin and a locally configured maximum UE-DS-TT residence time for the calculation of independentDelayMax.

Comment:

Revision of S2-2108872r00. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108873 (CR) 23.502 CR3302 (Rel-16, 'F'): Include TSN time domain into bridge information reporting procedure. (Source: Qualcomm).
Document for: Approval.
Abstract: Summary of change: Annex F.1 Add Step 3 (TSN AF provides the TSN Time domain number to DS-TT and optionally to NW-TT. - Add ' Tick granularity, PSFPTickGranularity ' in Step 4. - Add note to reflect that it is assumed that distribution of TSN GM time towards NW-TT and DS-TT for the TSN time domain is activated before TSN AF retrieves txPropagationDelay, Tick granularity and PSFPTickGranularity so that DS-TT and NW-TT can convert these parameters from 5GS time to TSN time before reporting them to TSN AF.'.

Comment:

r02 agreed. Revised to S2-2109069.

Discussion and conclusion:

-

e-mail discussion:

Devaki (Nokia) comments.
Sebastian (Qualcomm) provides r02 (please ignore r01)
==== Revisions Deadline ====
Devaki (Nokia) comments that chair notes should be updated to ask 'r02 for approval'.
Sebastian (Qualcomm) confirms that r02 should be marked for approval
==== Comments Deadline ====.

Status:

Revised to S2-2109069.

TD S2-2109069 (CR) 23.502 CR3302R1 (Rel-16, 'F'): Include TSN time domain into bridge information reporting procedure. (Source: Qualcomm).
Document for: Approval.
Abstract: Summary of change: Annex F.1 Add Step 3 (TSN AF provides the TSN Time domain number to DS-TT and optionally to NW-TT. - Add note to reflect that it is assumed that distribution of TSN GM time towards NW-TT and DS-TT for the TSN time domain is activated before TSN AF retrieves txPropagationDelay so that DS-TT and NW-TT can convert txPropagationDelay from 5GS time to TSN time before reporting txPropagationDelay to TSN AF.'.

Comment:

Revision of S2-2108873r02. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108874 (CR) 23.502 CR3303 (Rel-17, 'A'): Include TSN time domain into bridge information reporting procedure. (Source: Qualcomm).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: Annex F.1 Add Step 3 (TSN AF provides the TSN Time domain number to DS-TT and optionally to NW-TT. - Add ' Tick granularity, PSFPTickGranularity ' in Step 4. - Add note to reflect that it is assumed that distribution of TSN GM time towards NW-TT and DS-TT for the TSN time domain is activated before TSN AF retrieves txPropagationDelay, Tick granularity and PSFPTickGranularity so that DS-TT and NW-TT can convert these parameters from 5GS time to TSN time before reporting them to TSN AF.'.

Comment:

r00 agreed. Revised to S2-2109070.

Discussion and conclusion:

-

Status:

Revised to S2-2109070.

TD S2-2109070 (CR) 23.502 CR3303R1 (Rel-17, 'A'): Include TSN time domain into bridge information reporting procedure. (Source: Qualcomm).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: Annex F.1 Add Step 3 (TSN AF provides the TSN Time domain number to DS-TT and optionally to NW-TT. - Add note to reflect that it is assumed that distribution of TSN GM time towards NW-TT and DS-TT for the TSN time domain is activated before TSN AF retrieves txPropagationDelay so that DS-TT and NW-TT can convert txPropagationDelay from 5GS time to TSN time before reporting txPropagationDelay to TSN AF.'.

Comment:

Revision of S2-2108874r00. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2109004 (LS IN) LS from RAN WG3: Reply LS on Clarification of UE with CAG information in UE subscription. (Source: RAN WG3 (R3-216064)).
Document for: Action.
Abstract: RAN WG3 thanks SA WG2 for the LS on Clarification of UE with CAG information in UE. RAN WG3 has agreed to include the supported CAG list of the target CAG cell in the HANDOVER REQUEST ACKNOWLEDGE message to align with SA WG2's agreement. The agreed CR for TS 38.413 is attached for reference. Action: RAN WG3 kindly asks SA WG2 group to take the above RAN WG3 decision into account.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Qianghua (Huawei) proposes to note this LS, this is for information, no action requires for SA2
==== Comments Deadline ====.

Status:

Noted.

# 7.8 Enhancements to the Service-Based 5G System Architecture (5G_eSBA)

# 7.9 Architecture enhancements for the support of Integrated access and backhaul (IABARC)

# 7.10 Enhancement of URLLC supporting in 5GC (5G_URLLC)

# 7.11 Enhancement of Network Slicing (eNS)

TD S2-2108468 (CR) 23.502 CR3243 (Rel-16, 'F'): SUPI in Notifications from NSSAAF. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: Add the supi attribute in the NSSAA Reauthentication and Revocation Requests. The NSSAAF gets the SUPI included in the response of the Nudm_UECM_Get from the UDM.

Comment:

Postponed.

Discussion and conclusion:

-

e-mail discussion:

Haiyang (Huawei) comments and show concerns.
Josep (DT) comments.
Alessio(Nokia) also thinks this is not a category F CR, rather a category B CR. We do not agree to this additional feature as it seems there is no problem to solve ..
==== Revisions Deadline ====
Josep (DT) proposes to at least postpone.
Peter Hedman (Ericsson) provides replies
Haiyang (Huawei) agrees with Josep (DT), suggests to note/postpone this paper.
==== Comments Deadline ====.

Status:

Postponed.

TD S2-2108469 (CR) 23.502 CR3244 (Rel-17, 'A'): SUPI in Notifications from NSSAAF. (Source: Ericsson).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: Add the supi attribute in the NSSAA Reauthentication and Revocation Requests. The NSSAAF gets the SUPI included in the response of the Nudm_UECM_Get from the UDM.

Comment:

Postponed.

Discussion and conclusion:

-

e-mail discussion:

Haiyang (Huawei) comments and show concerns.
Alessio(Nokia) also thinks this is not a category F CR, rather a category B CR. We do not agree to this additional feature as it seems there is no problem to solve ..
==== Revisions Deadline ====
Peter Hedman (Ericsson) provides replies
Haiyang (Huawei) suggests to note/postpone this CR.
==== Comments Deadline ====.

Status:

Postponed.

TD S2-2108709 (CR) 23.502 CR3276 (Rel-17, 'F'): The update for Nnrf_NFDiscovery_Request service operation. (Source: China Mobile).
Document for: Approval.
Abstract: Summary of change: To add new optional inputs when the target NF is NSSAAF.

Comment:

r01 agreed. Revised to S2-2109071.

Discussion and conclusion:

-

e-mail discussion:

Aihua (CMCC) provides r01 based on offline discussion.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109071.

TD S2-2109071 (CR) 23.502 CR3276R1 (Rel-17, 'C'): The update for Nnrf_NFDiscovery_Request service operation. (Source: China Mobile).
Document for: Approval.
Abstract: Summary of change: To add new optional inputs when the target NF is NSSAAF.

Comment:

Revision of S2-2108709r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

# 7.12 Optimisations on UE radio capability signalling (RACS)

TD S2-2108304 (CR) 23.501 CR2524R1 (Rel-16, 'F'): On alignment of RACS capability detection with RAN WG3. (Source: Nokia, Nokia Shanghai bell, Qualcomm Inc., Ericsson).
Document for: Approval.
Abstract: Summary of change: The text not aligned with RAN WG3 TS is removed.

Comment:

Revision of (Postponed) S2-2100063 from S2#143E. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108305 (CR) 23.401 CR3617R1 (Rel-16, 'F'): On alignment of RACS capability detection with RAN WG3. (Source: Nokia, Nokia Shanghai Bell,Qualcomm Inc, Ericsson).
Document for: Approval.
Abstract: Summary of change: The text not aligned with RAN WG3 is removed.

Comment:

Revision of (Postponed) S2-2100064 from S2#143E. Approved.

Discussion and conclusion:

-

Status:

Agreed.

# 7.13 Enhanced IMS to 5GC Integration (eIMS5G_SBA)

TD S2-2108297 (LS IN) LS from GSMA 5GJA: LS to 3GPP on IMS Data Channel Architecture. (Source: GSMA 5GJA (5GJA18_109r1)).
Document for: Action.
Abstract: Background: GSMA NG 5GJA Data Channel Task Force (DCTF) has completed the NG.129 IMS Data Channel whitepaper which is up for GSMA approval, means it is not yet publicly available. The white paper aims to provide the first complete analysis of IMS data channel technology, educate the industry about IMS data channel capabilities, and identify any outstanding issues. It is based on the IMS Data Channel defined in 3GPP TS 26.114 (Release 16). This LS is sent to SA WG2/SA WG4 in order to address some open questions raised by the Data Channel Task Force members. Annex A DCS Architecture of the GSMA NG.129 - IMS Data Channel White Paper will be publicly available for further information once the document is approved and published by GSMA. Discussion: GSMA NG.129 elaborates on IMS data channel architectural details. The relationships between 3GPP network functions are shown in Figure 1 and use some terms which are still to be specified by the appropriate standardisation organisation. The GSMA NG 5GJA DCTF concluded that: - The Data Channel control function (part of the Data Channel Server) acts as the control function for IMS Data Channel for the data channel bootstrap and e2e media. - The DC control function can also terminate the media endpoint for IMS Data Channel media. - The Data Channel Media function (DCM/MRF) relays the media to/from the Data Channel control function. - Either - a new new interface (IF1) handling the interaction between the Data Channel control function and the Data Channel media function is needed, or - a new Network Function encompassing functionalities from different existing entities, for example, from MRF, IMS AS, Data Channel control function is needed. - The Data Channel Media function (DCM/MRF) relays the Data Channel media between Mb interface and IF1 interface. - The Data Channel Control Function is not acting as SIP AS. The GSMA NG 5GJA DCTF has not been able to come to a conclusion on the following aspects: Question-1- Is there a need for a new IMS Data Channel media function (realized by a new NF named as DCM-Data Channel Media) or can the existing MRF be enhanced to meet all the requirements for IMS data channel media? NOTE: It's assumed that when the definition of MRF is enhanced to support the Data Channel media function, it does not mean that any deployed MRF would need to be enhanced. Instead an MRF for the IMS Data Channel media can be deployed alongside an existing MRF handling RTP (audio/video) media. Question-2- If a new NF is defined, should the IMS AS be enhanced to support SBI (not shown in the DC architecture Figure 1) to enable the interaction between the Data Channel Control Function and the Data Channel Media function (DCM/MRF) via an IMS AS? Question-3- Is the assumption correct that IF6 (DC Control API) and IF1 (DC media) between Operator IMS and the DCS would not need to be defined in 3GPP, and thus could be defined in another standardization body?. Action: GSMA NG 5GJA kindly asks SA WG2 and SA WG4 to provide answers to the above questions.

Comment:

Responses drafted in S2-2108901 and S2-2108907. Postponed.

Discussion and conclusion:

-

e-mail discussion:

Leo (Deutsche Telekom) proposes to postpone the LS to the next SA2 meeting.
==== Comments Deadline ====.

Status:

Postponed.

TD S2-2108907 (LS OUT) [DRAFT] Reply LS on IMS Data Channel Architecture. (Source: China Mobile).
Document for: Approval.
Abstract: Reply LS on IMS architecture supporting data channel to GSMA NG 5GJA.

Comment:

Response to S2-2108297. Postponed.

Discussion and conclusion:

-

e-mail discussion:

Leo (Deutsche Telekom) provides r01.
Chia-Lin (MediaTek) suggest to postpone LS
==== Revisions Deadline ====
Leo (Deutsche Telekom) agrees to postpone the reply LS to the next SA2 meeting.
==== Comments Deadline ====.

Status:

Postponed.

# 7.14 User Data Interworking and Coexistence (UDICoM)

# 7.15 Enhancing Topology of SMF and UPF in 5G Networks (ETSUN)

TD S2-2108364 (CR) 23.501 CR3365 (Rel-16, 'F'): V-SMF change at inter-PLMN mobility. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: Add missing N38 interface in reference architecture figures and clarify that it may be inter-PLMN and intra-PLMN interface. Clarify that V-SMF relocation as defined by ETSUN can be performed at both intra-PLMN and inter-PLMN mobility.

Comment:

Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108365 (CR) 23.501 CR3366 (Rel-17, 'A'): V-SMF change at inter-PLMN mobility. (Source: Ericsson).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: Add missing N38 interface in reference architecture figures and clarify that it may be inter-PLMN and intra-PLMN interface. Clarify that V-SMF relocation as defined by ETSUN can be performed at both intra-PLMN and inter-PLMN mobility.

Comment:

Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108366 (CR) 23.502 CR3226 (Rel-16, 'F'): V-SMF change at inter-PLMN mobility. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: Clarify that V-SMF relocation as defined by ETSUN can be performed at both intra-PLMN and inter-PLMN mobility.

Comment:

r02 agreed. Revised to S2-2109072.

Discussion and conclusion:

-

e-mail discussion:

Laurent (Nokia): provides r01
Stefan (Ericsson) provides r02
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109072.

TD S2-2109072 (CR) 23.502 CR3226R1 (Rel-16, 'F'): V-SMF change at inter-PLMN mobility. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: Clarify that V-SMF relocation as defined by ETSUN can be performed at both intra-PLMN and inter-PLMN mobility.

Comment:

Revision of S2-2108366r02. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108367 (CR) 23.502 CR3227 (Rel-17, 'A'): V-SMF change at inter-PLMN mobility. (Source: Ericsson).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: Clarify that V-SMF relocation as defined by ETSUN can be performed at both intra-PLMN and inter-PLMN mobility.

Comment:

r00 agreed. Revised to S2-2109073.

Discussion and conclusion:

-

Status:

Revised to S2-2109073.

TD S2-2109073 (CR) 23.502 CR3227R1 (Rel-17, 'A'): V-SMF change at inter-PLMN mobility. (Source: Ericsson).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: Clarify that V-SMF relocation as defined by ETSUN can be performed at both intra-PLMN and inter-PLMN mobility.

Comment:

Revision of S2-2108367r00. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108678 (CR) 23.502 CR3273 (Rel-17, 'F'): N9 forwarding tunnel between ULCLs controlled by I-SMF. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: A new procedure to support simultaneous change of UL CL/BP and L-PSA, in which N9 forwarding tunnel between target and source UL CL is supported. Reference to the new procedure to indicate that the new procedure is added.

Comment:

Postponed.

Discussion and conclusion:

-

e-mail discussion:

Laurent (Nokia): Comments
Fenqin (Huawei): Comments
Laurent (Nokia): answers to Fenqin
Laurent (Nokia): provides r01
Fenqin (Huawei): provides r02
Stefan (Ericsson) provides question
Laurent (Nokia): proposes to postpone 8678
Fenqin (Huawei) responds
Stefan (Ericsson) supports to postone
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Postponed.

TD S2-2108856 (CR) 23.502 CR2894R1 (Rel-16, 'F'): L-PSA and I-SMF release during mobiity procedure with I-SMF change or removal. (Source: Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: The Source I-SMF releases any resource associated with a PDU Session when both following events have taken place: - (if indirect data forwarding applies) the expiry of the data forwarding timer, - the completion of all the N4 release procedures initiated by the SMF to release the local UPF(s) the Source I-SMF is controlling. NOTE1: The SMF remains responsible of any traffic forwarding (involving source I-UPF(s)) related with keeping the same EAS for the traffic of applications that do not support mobility (see Figure 4.3.5.7-1).

Comment:

Revision of (Merged and Agreed) S2-2105353 from S2#146E. Postponed.

Discussion and conclusion:

-

e-mail discussion:

Fenqin (Huawei) propose to note this paper
Laurent (Nokia): provides r01
Fenqin (Huawei): propose to Note this paper
Stefan (Ericsson) supports to note this rel-16 CR and only do change in rel-17
Laurent (Nokia): OK note or withdraw this rel-16 CR and only do change in rel-17
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Postponed.

TD S2-2108857 (CR) 23.502 CR2895R1 (Rel-17, 'A'): L-PSA and I-SMF release during mobiity procedure with I-SMF change or removal. (Source: Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Rel-17 mirror CR: Summary of change: The Source I-SMF releases any resource associated with a PDU Session when both following events have taken place: - (if indirect data forwarding applies) the expiry of the data forwarding timer, - the completion of all the N4 release procedures initiated by the SMF to release the local UPF(s) the Source I-SMF is controlling. NOTE1: The SMF remains responsible of any traffic forwarding (involving source I-UPF(s)) related with keeping the same EAS for the traffic of applications that do not support mobility (see Figure 4.3.5.7-1).

Comment:

Revision of (Postponed) S2-2105354 from S2#146E. Postponed.

Discussion and conclusion:

-

e-mail discussion:

Fenqin (Huawei) comment and suggest to merge this paper to 8678
Laurent (Nokia): provides r01
Fenqin (Huawei): propose to postpone 8857
Stefan (Ericsson) supports to postpone
Laurent (Nokia): Let's postpone both 8678 and 8857 then
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Postponed.

# 7.16 5GS Transfer of Policies for Background Data Transfer (xBDT)

# 7.17 Single radio voice continuity from 5GS to 3G (5G_SRVCC)

# 8 Rel-17 WID

# 8.1 Enablers for Network Automation for 5G - phase 2 (eNA_Ph2)

This agenda item was convened by Andy Bennett (Samsung).

## General

TD S2-2108647 (CR) 23.288 CR0481 (Rel-17, 'F'): Term alignment of Target of Analytics Reporting and Analytics Filter Information. (Source: China Mobile).
Document for: Approval.
Abstract: Summary of change: Align the term of Target of Analytics Reporting and Analytics Filter Information.

Comment:

r01 agreed. Revised to S2-2109074.

Discussion and conclusion:

-

e-mail discussion:

Yannick (Nokia): Nokia provides r01.
Aihua(China Mobile) replies to Yannick(Nokia).
Yannick (Nokia): Nokia replies to China Mobile.
Aihua(China Mobile) replies to Nokia.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109074.

TD S2-2109074 (CR) 23.288 CR0481R1 (Rel-17, 'F'): Term alignment of Target of Analytics Reporting and Analytics Filter Information. (Source: China Mobile).
Document for: Approval.
Abstract: Summary of change: Align the term of Target of Analytics Reporting and Analytics Filter Information.

Comment:

Revision of S2-2108647r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108682 (CR) 23.288 CR0467R3 (Rel-17, 'F'): Miscellaneous corrections for TS 23.288 on eNA_ph2. (Source: Vivo, Huawei, Ericsson, Nokia, LG Electronics, CATT, Intel).
Document for: Approval.
Abstract: Summary of change: 1. Clarify the descriptions of data collection coordination and delivery functional. 2. Correct 'Analytics Id' or 'analytics ID' or 'Analytic ID' into 'Analytics ID'. 3. Change the 'target for analytics' as the 'Target of Analytics Reporting'. 4. Figure 6.2.2.2-1 is updated. 5. Move the ADRF procedures to new clause 6.2B. 6. Replace the original reference to 6.15 with a reference to 6.2B. 7. Correct the typo 'NMWDAF' in Note 3 of clause 5.1; 8. Correct the typo 'Area Of Interest' to 'Area of Interest'.

Comment:

Revision of (Agreed) S2-2107803 from S2#147E. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108683 (CR) 23.501 CR3320R2 (Rel-17, 'F'): Miscellaneous correction for eNA Ph2 on TS 23.501. (Source: Vivo, Huawei, HiSilicon, Nokia, LG Electronics, Intel).
Document for: Approval.
Abstract: Summary of change: Rename the Analytics Filter information for the ML model provisioning as 'ML model Filter information' for alignment.

Comment:

Revision of (Agreed) S2-2107804 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

Yannick (Nokia): Nokia notes that this CR is identical to SA2#147E agreed CR, and comments that there is also another revision for the SA2#147E agreed CR in S2-2108711.
Vivian (vivo) reply to Yannick(Nokia) and propose to focus on S2-2108683.
Yannick (Nokia): Nokia replies to Vivo.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108684 (CR) 23.502 CR3196R1 (Rel-17, 'F'): Miscellaneous correction for eNA_Ph2 on TS 23.502. (Source: Vivo, Huawei, HiSilicon, LG Electronics).
Document for: Approval.
Abstract: Summary of change: Rename the Analytics Filter information for the ML model provisioning as 'ML model Filter information' for alignment. Correct 'Analytics Id' or 'Analytic ID' to 'Analytics ID'. This paper is further revised since SA WG2#147E in case there are miscellaneous correction(s).

Comment:

Revision of (Agreed) S2-2107596 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

Yannick (Nokia): Nokia understands that this CR is identical to SA2#147E agreed CR, and comments that there is also another revision for the SA2#147E agreed CR in S2-2108714.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108685 (CR) 23.503 CR0664R1 (Rel-17, 'F'): Miscellaneous correction for eNA_Ph2 on TS 23.503. (Source: Vivo, Huawei, HiSilicon, LG Electronics).
Document for: Approval.
Abstract: Summary of change: Correct 'Analytic ID' or 'analytic ID' to 'Analytics ID'.

Comment:

Revision of (Agreed) S2-2107597 from S2#147E. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108711 (CR) 23.501 CR3320R3 (Rel-17, 'F'): Miscellaneous correction for eNA_Ph2 on TS 23.501. (Source: Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: Rename the Analytics Filter information for the ML model provisioning as 'ML model Filter information' for alignment.

Comment:

Revision of (Agreed) S2-2107804 from S2#147E. r04 agreed. Revised to S2-2109075.

Discussion and conclusion:

-

e-mail discussion:

Wang Yuan (Huawei) comments that this CR should be aligned with the outcome of S2-2108537/8538/8707.
Yannick (Nokia): Nokia provides r01 to address comments from Ericsson on other proposal in S2-2108714. Changes in the CR are related to discussion on S2-2108537/8538 (Huawei), S2-2108707 (Nokia) and S2-2108708 (Lenovo).
Wang Yuan (Huawei) cosigns this CR and provide r02.
Soohwan (ETRI) provides r03.
Yannick (Nokia): Nokia provides r04. Suggests to limit changes in TS 23.501 to the minimum and refer to clause 5.2 from TS 23.288.
Wang Yuan (Huawei) is fine with r04 and confirms the cosign of this CR.
==== Revisions Deadline ====
Soohwan (ETRI) okay with r04.
==== Comments Deadline ====.

Status:

Revised to S2-2109075.

TD S2-2109075 (CR) 23.501 CR3320R4 (Rel-17, 'F'): Miscellaneous correction for eNA_Ph2. (Source: Vivo, Huawei, HiSilicon, Nokia, Nokia Shanghai Bell, Intel).
Document for: Approval.
Abstract: Summary of change: Rename the Analytics Filter information for the ML model provisioning as 'ML model Filter information' for alignment.

Comment:

Revision of S2-2108711r04. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108714 (CR) 23.502 CR3196R2 (Rel-17, 'F'): Miscellaneous correction for eNA_Ph2 on TS 23.502. (Source: Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: Rename the Analytics Filter information for the ML model provisioning as 'ML model Filter information' for alignment. Correct 'Analytics Id' or 'Analytic ID' to 'Analytics ID'.

Comment:

Revision of (Agreed) S2-2107596 from S2#147E. r04 agreed. Revised to S2-2109076.

Discussion and conclusion:

-

e-mail discussion:

Zhang (Ericsson) provides comments
Wang Yuan (Huawei) comments that the last three changes in the CR should be aligned with the outcome of S2-2108537/8538/8707.
Yannick (Nokia): Nokia provides r01 to address comments from Ericsson.
Zhang (Ericsson) is OK with r01
Wang Yuan (Huawei) cosigns this CR and provide r02.
Soohwan (ETRI) provides r03.
Yannick (Nokia): Nokia provides r04. Suggests to limit changes in TS 23.502 to the minimum and refer to clause 5.2 from TS 23.288.
Wang Yuan (Huawei) is fine with r04 and confirms the cosign of this CR.
==== Revisions Deadline ====
Soohwan (ETRI) is okay with r04.
Zhang (Ericsson) is OK with r04 and co-sign
==== Comments Deadline ====.

Status:

Revised to S2-2109076.

TD S2-2109076 (CR) 23.502 CR3196R3 (Rel-17, 'F'): Miscellaneous correction for eNA_Ph2. (Source: Vivo, Huawei, HiSilicon, Nokia, Nokia Shanghai Bell, Ericsson).
Document for: Approval.
Abstract: Summary of change: Rename the Analytics Filter information for the ML model provisioning as 'ML model Filter information' for alignment. Correct 'Analytics Id' or 'Analytic ID' to 'Analytics ID'.

Comment:

Revision of S2-2108714r04. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108966 (CR) 23.288 CR0492 (Rel-17, 'F'): Resolve normative wording in notes. (Source: Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: Resolve issue by: Replace normative wording 'may' into 'might' or 'can' Change NOTE to regular normative text Delete NOTE in 5A.1 as it is not needed Move NOTE3 in 6.1.3 to become normative text in clause '6.1A.3.1 Procedure for analytics aggregation' as the text is describing how an aggregator NWDAF should react when receiving Time when analytics information is needed from the analytics consumer with the value greater than or equal to its Supported Analytics Delay.

Comment:

r02 agreed. Revised to S2-2109078.

Discussion and conclusion:

-

e-mail discussion:

Zhang (Ericsson) provides r01
Mehrdad (Samsung) comments on all revisions and suggests to remove changes of clause 6.1.3 and 6.1A.3.1 from this CR in case it will be handled.
Gerald (Nokia): Nokia provides r02
Zhang (Ericsson) is fine with r02 and co-sign
Mehrdad (Samsung) comments on r02 and asks for clarification from Ericsson.
Zhang (Ericsson) provides comments
Gerald (Nokia): Nokia clarifies to Samsung
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109078.

TD S2-2109078 (CR) 23.288 CR0492R1 (Rel-17, 'F'): Resolve normative wording in notes. (Source: Nokia, Nokia Shanghai Bell, Ericsson).
Document for: Approval.
Abstract: Summary of change: Resolve issue by: Replace normative wording 'may' into 'might' or 'can' Change NOTE to regular normative text Delete NOTE in 5A.1 as it is not needed.

Comment:

Revision of S2-2108966r02. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108952 (CR) 23.288 CR0491 (Rel-17, 'F'): Clarification on interaction between timers and supported analytics Delay. (Source: Samsung).
Document for: Approval.
Abstract: Summary of change: 1) Clause 6.1.3: - NOTE 2 definition is updated to align with the definition in TS 23.501. - NOTE 3 is removed and instead it is elaborated in 6.1A.3.1. 2) Clause 6.1A.3.1 - Clarification is added to steps of the procedure on the roles of 'Time when analytics information is needed' and Supported Analytics Delay associated per the Analytics ID.

Comment:

r06 agreed. Revised to S2-2109077.

Discussion and conclusion:

-

e-mail discussion:

Antoine (Orange) provides r01.
Chi (China Unicom) asks question for clarification.
Mehrdad (Samsung) is OK with r01 and replies to China Unicom.
Chi (China Unicom) provides further comments.
Mehrdad (Samsung) replies to China Unicom and provides r02 and r03. Please ignore r02 as it has typo.
Gerald (Nokia): Nokia comments on r03 and asks for clarification
Mehrdad (Samsung) replies to Nokia and provides r04.
Chi (China Unicom) asks question on 'revised waiting time'.
Mehrdad (Samsung) replies to China Unicom and provides r05.
Zhang (Ericsson) provides comments
Mehrdad (Samsung) replies to Ericsson and provides r06.
Mehrdad (Samsung) replies to Ericsson.
Zhang (Ericsson) is OK with r06
==== Revisions Deadline ====
Chi (China Unicom) is ok with r06.
Gerald (Nokia): Nokia is okay with r05 and r06
==== Comments Deadline ====.

Status:

Revised to S2-2109077.

TD S2-2109077 (CR) 23.288 CR0491R1 (Rel-17, 'F'): Clarification on interaction between timers and supported analytics Delay. (Source: Samsung).
Document for: Approval.
Abstract: Summary of change: 1) Clause 6.1.3: - NOTE 2 definition is updated to align with the definition in TS 23.501. - NOTE 3 is removed and instead it is elaborated in 6.1A.3.1. 2) Clause 6.1A.3.1 - Clarification is added to steps of the procedure on the roles of 'Time when analytics information is needed' and Supported Analytics Delay associated per the Analytics ID.

Comment:

Revision of S2-2108952r06. Approved.

Discussion and conclusion:

-

Status:

Agreed.

## KI#1

TD S2-2108537 (DISCUSSION) Discussion on ML Model Filter Information during the NWDAF containing MTLF registration.. (Source: Huawei, HiSilicon).
Document for: Agreement.
Abstract: This contribution proposes to discussion on the ML Model Filter Information during the NWDAF containing MTLF registration.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108538 (CR) 23.288 CR0477 (Rel-17, 'F'): Clarify the ML Model Filter Information during the NWDAF containing MTLF registration. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Clarify the ML Model Filter Information includes e.g. S-NSSAI and/or Area of Interest during the NWDAF containing MTLF registration.

Comment:

Merged into S2-2109079.

Discussion and conclusion:

-

e-mail discussion:

Wang Yuan (Huawei) confirms that this CR is merged into S2-2108707
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Merged into S2-2109079.

TD S2-2108650 (CR) 23.288 CR0461R2 (Rel-17, 'F'): Clarify the NWDAF (MTLF) and NWDAF (AnLF). (Source: China Mobile, Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: Change the 'NWDAF (MTLF)' and 'NWDAF (AnLF)' as 'NWDAF containing MTLF' and 'NWDAF containing AnLF' respectively.

Comment:

Revision of (Agreed) S2-2107805 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

Yannick (Nokia): Nokia comments that this CR is related to discussion on other CRs in S2-2108538 from Huawei, S2-2108708 from Lenovo and S2-2108707 from Nokia.
Aihua(CMCC) replies to Yannick(Nokia) and provides r01.
==== Revisions Deadline ====
Yannick (Nokia): Nokia proposes to note this document under the assumption that a revision for S2-2108707 would be approved in this meeting.
Aihua(China Mobile) suggests to agree r01.
Yannick (Nokia): Nokia prefers to note this CR.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108707 (CR) 23.288 CR0486 (Rel-17, 'F'): Corrections to discovery for NWDAF containing MTLF. (Source: Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: Discovery of MWDAF containing MTLF is simplified.

Comment:

r09 agreed. Revised to S2-2109079, merging S2-2108538 and S2-2108708.

Discussion and conclusion:

-

e-mail discussion:

Zhang (Ericsson) provides comments
Wang Yuan (Huawei) provides comments.
Yannick (Nokia): Nokia provides r01. Nokia notes that there are three CRs on the same issue, S2-2108538 (Huawei), S2-2108708 (Lenovo) and S2-2108707 (Nokia).
Wang Yuan (Huawei) replies to Yannick (Nokia) and provides r03.
Soohwan (ETRI) provides r04.
Malla (NTT DOCOMO) provided r05.
Yannick (Nokia): Nokia provides r06.
Dimitris (Lenovo) provides r07
Yannick (Nokia): Nokia is fine with r07.
Yannick (Nokia): Nokia suggests a wording for NOTE Y.
Wang Yuan (Huawei) provides r08 and co-signs this CR.
Yannick (Nokia): Nokia is ok with r08
Malla (NTT DOCOMO) provided r09
Yannick (Nokia): Nokia is ok with r09.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109079, merging S2-2108538 and S2-2108708.

TD S2-2109079 (CR) 23.288 CR0486R1 (Rel-17, 'F'): Corrections to discovery for NWDAF containing MTLF. (Source: Nokia, Nokia Shanghai Bell, Huawei, NTT DOCOMO, Lenovo, Motorola Mobility).
Document for: Approval.
Abstract: Summary of change: Discovery of MWDAF containing MTLF is simplified.

Comment:

Revision of S2-2108707r09, merging S2-2108538 and S2-2108708. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108708 (CR) 23.288 CR0487 (Rel-17, 'F'): ML model provisioning information in NRF. (Source: Lenovo, Motorola Mobility).
Document for: Approval.
Abstract: Summary of change: Clarifying that when a trained model is available the MTLF stores in the NRF the analytics ID associated to the model and optionally model filter information. When a consumer (i.e. an NWDAF supporting an AnLF) needs to discover the MTLF the consumer includes in the request to the NRF the Analytics ID of the model required. The NRF returns a list of instances containing the model associated with the analytics ID. If the NRF also contains model information the NRF also includes such information in the response. Given that in this release it was agreed that a NWDAF supporting AnLF is pre-configured with a (list of) NWDAF supporting MTLF that model information is retrieved clarifying that the Consumer selects an MTLF instance based on the MTLF ID(s) the consumer is pre-configured to obtain trained ML models.

Comment:

Merged into S2-2109079.

Discussion and conclusion:

-

e-mail discussion:

Yannick (Nokia): Nokia provides comments. Nokia notes that there are three CRs on the same issue, S2-2108538 (Huawei), S2-2108708 (Lenovo) and S2-2108707 (Nokia).
Dimitris (Lenovo) is ok to use S2-2108707 as the basis for this discussion
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Merged into S2-2109079.

## KI#2

TD S2-2108436 (CR) 23.288 CR0448R1 (Rel-17, 'F'): CR to resolve conflicts in ML model transferring. (Source: ETRI, Huawei?, Nokia?).
Document for: Approval.
Abstract: Summary of change: This CR proposes to delete ML model information in input parameter of Nnwdaf_AnalyticsSubscription as well as clarifies the conditions that target NWDAF subscribes ML model(s) for the provided MTLF IDs from source NWDAF, and removes target NWDAF directly retrives ML model with ML model information over the procedures in clause 6.1B2.2 and 6.1B.3. Rev1 proposes to add NOTE 3 in caluse 6.1B.2.2 to describe how target NWDAF retreive the same Model as used in source NWDAF from the indicated MTLF by source NWDAF.

Comment:

Revision of (Postponed) S2-2107321 from S2#147E. Confirm Sources! Postponed.

Discussion and conclusion:

-

e-mail discussion:

Xiaoyan (CATT) objects to r00 (the original CR) and provides r01.
Soohwan (ETRI) objects to r01 and proposes a way forward
Malla (NTT DOCOMO) asks whether this CR is considered as merged into S2-2108536
Gerald (Nokia): Nokia clarifies that this CR is not merged into S2-2108536. Disagrees with r01.
Soohwan provides r02 and comments.
Xiaoyan (CATT) provides r03.
Xiaoyan (CATT) objects to r02.
Soohwan (ETRI) provides r04 and r05 based on the discussion and Soohwan (ETRI) prefers to go with r05.
Gerald (Nokia): Nokia disagrees with r03, r04. Asks whether r04 and r05 also merge 8713r04?
Soohwan (ETRI) confirms that r04 and r05 capture the content in 8713r04.
Xiaoyan (CATT) objects to r05 and r04 too, based on the discussions in S2-2108536 and this thread.
Dimitris (Lenovo) comments
Gerald (Nokia): Nokia responds to Lenovo. Proposes alternative.
Soohwan (ETRI) objects to r03 and the futher revisions which include ML model file address(es) without proposed NOTE and normative text in r04.
==== Revisions Deadline ====
Soohwan (ETRI) proposes to postpone this CR
Xiaoyan (CATT) suggests that this CR be marked as merged to S2-2108713.
Soohwan (ETRI) disagrees to merge this CR into S2-2108713 and asks to postpone.
==== Comments Deadline ====.

Status:

Postponed.

TD S2-2108536 (DISCUSSION) Discussion on ML model transferring during the analytics context transfer.. (Source: Huawei, HiSilicon, ETRI).
Document for: Agreement.
Abstract: This contribution proposes to discussion on the ML model transferring during the analytics context transfer from source NWDAF to target NWDAF.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Wang Yuan (Huawei) provides r01 based on offline discussions.
Xiaoyan (CATT) propose to note this discussion paper and focus on discussions in S2-2108436 thread.
Soohwan (ETRI) supports proposal 1 and concerns with proposal 2.
Gerald (Nokia): Nokia disagrees with proposal 2 in r00 and r01
Dimitris (Lenovo) suggests to agree first on the ML model transfer procedure then work on the related CRs
Xiaoyan (CATT) disagrees with the view of Gerald(Nokia).
Wang Yuan (Huawei) also support proposal 1 based on the R17 conclusion for ML model sharing.
Xiaoyan (CATT) provides comments to the proposals.
Gerald (Nokia): Nokia responds to earlier CATT response
Xiaoyan (CATT) provides clarification to Gerald(Nokia).
Dimitris (Lenovo) comments
Xiaoyan (CATT) responds to Dimitris (Lenovo).
Gerald (Nokia): Nokia responds to Xiaoyan (CATT)
Dimitris (Lenovo) responds to Xiaoyan (CATT)
Soohwan (ETRI) provides comments
Xiaoyan (CATT) responds to Gerald (Nokia).
Xiaoyan (CATT) replies to Soohwan (ETRI).
Soohwan (ETRI) replies to Xiaoyan.
Wang Yuan (Huawei) replies to earlier CATT questions.
Xiaoyan (CATT) replies to Wang Yuan (Huawei).
Soohwan (ETRI) asks any way forward.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108551 (CR) 23.288 CR0478 (Rel-17, 'F'): Clarification on external triggers and clean up the UE mobility analytics. (Source: CATT).
Document for: Approval.
Abstract: Summary of change: Add a note to clarify how NWDAF determines that it may not be able to continue to provide analytics service under the external trigger condition of UE mobility. Put the description of application ID as a note in the Table 6.7.2.2-2. Correct typos.

Comment:

r07 agreed. Revised to S2-2109080.

Discussion and conclusion:

-

e-mail discussion:

Zhang (Ericsson) provides comments
Jiahui (China Telecom) provides comments
Gerald (Nokia): Nokia provides comments on original
Yingying(CATT) replies to Zhang Fu(Ericsson) and Jiahui (China Telecom), and provides r01.
Yingying(CATT) replies to Gerald (Nokia), and provides r02.
Gerald (Nokia): Nokia comments on r02
Yingying(CATT) agrees with Zhang(Ericsson) and provides r03.
Gerald (Nokia): Nokia comments on r03
Yingying(CATT) replies to Gerald (Nokia) and provides r04.
Zhang (Ericsson) provides r05
Gerald (Nokia): Nokia objects to r05, is okay with r04
Zhang (Ericsson) provides comments and r06
Gerald (Nokia): Nokia disagrees with r06 and provides r07
Yingying(CATT) agrees with Gerald (Nokia), is okay with r07, and provides r08.
Gerald (Nokia): Nokia replies to Zhang (E///)
Yingying(CATT) replies to Zhang (Ericsson).
Yingying(CATT) provides clarification to Zhang (Ericsson) .
Zhang (Ericsson) provides comments and r09
Yingying(CATT) provides r10 and prefers to r04 or r08, is okay with r07.
Gerald (Nokia): Nokia comments on r09 and r10
Yingying(CATT) provides r11.
==== Revisions Deadline ====
Gerald (Nokia): Nokia is okay with r04/r08 and r07; objects to other revisions and original
Zhang (Ericsson) is OK with r07; objects to other versions
==== Comments Deadline ====.

Status:

Revised to S2-2109080.

TD S2-2109080 (CR) 23.288 CR0478R1 (Rel-17, 'F'): Clarification on external triggers and clean up the UE mobility analytics. (Source: CATT, Ericsson).
Document for: Approval.
Abstract: Summary of change: Put the description of application ID as a note in the Table 6.7.2.2-2. Correct typos.

Comment:

Revision of S2-2108551r07. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108664 (CR) 23.288 CR0463R2 (Rel-17, 'F'): Clarify the UE aggregated mobility analytics exposure to NF. (Source: China Mobile).
Document for: Approval.
Abstract: Summary of change: - Clarify the UE aggregated mobility analytics exposure to NF - Clarify that the NWDAF may provide the requested aggregated analytics for the UE ID list within the UE(s) in the Target of Analytics Reporting.

Comment:

Revision of (Agreed) S2-2107813 from S2#147E. r02 agreed. Revised to S2-2109081.

Discussion and conclusion:

-

e-mail discussion:

Gerald (Nokia): Nokia does not see need for this CR revision
Aihua(China Mobile) replies to Antoine (Orange) and Gerald (Nokia).
Gerald (Nokia): Nokia responds to China Mobile
Aihua(China Mobile) replies to Gerald (Nokia) and provides r01.
Gerald (Nokia): Nokia responds to Aihua (China Mobile) and comments on r01
Aihua(China Mobile) replies to Gerald (Nokia) and provides r02.
==== Revisions Deadline ====
Gerald (Nokia): Nokia is okay with r02
==== Comments Deadline ====.

Status:

Revised to S2-2109081.

TD S2-2109081 (CR) 23.288 CR0463R3 (Rel-17, 'F'): Clarify the UE aggregated mobility analytics exposure to NF. (Source: China Mobile).
Document for: Approval.
Abstract: Summary of change: - Clarify the UE aggregated mobility analytics exposure to NF - Clarify that the NWDAF may provide the requested aggregated analytics for the UE ID list within the UE(s) in the Target of Analytics Reporting.

Comment:

Revision of S2-2108664r02. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108713 (CR) 23.288 CR0488 (Rel-17, 'F'): Clarification of transferring ML model during analytics transfer. (Source: Lenovo, Motorola Mobility).
Document for: Approval.
Abstract: Summary of change: Clarifying that during analytics transfer the source NWDAF provides the NWDAF ID(s) of the MTLFs that provided the trained models. If the target NWDAF can obtain model information from the provided NWDAF ID(s) then the target NWDAF subscribes to one of the NWDAF in the list to obtain model information. If the target NWDAF is configured to obtain trained model information from other NWDAF supporting MTLF then the target NWDAF discovers from the NRF the NWDAF supporting MTLF that can provide the trained model and subscribes accordingly to receive updated trained models.

Comment:

Postponed.

Discussion and conclusion:

-

e-mail discussion:

Soohwan (ETRI) asks to have discussion regarding on this CR in S2-2108546 thread.
Xiaoyan (CATT) suggest that this CR be merged into S2-2108436.
Dimitris (Lenovo) provides r01
Gerald (Nokia): Nokia comments on r01
Dimitris (Lenovo) provides r02
Xiaoyan (CATT) provides r03.
Gerald (Nokia): Nokia provides r04
Soohwan (ETRI) proposes to merge this CR into S2-2108436.
Dimitris (Lenovo) suggests to keep CRs separate for now
Soohwan (ETRI) replies to Dimitris.
Xiaoyan (CATT) objects to r04.
Dimitris (Lenovo) provides r05
Gerald (Nokia): Nokia comments on r05
Dimitris (Lenovo) provides r06
==== Revisions Deadline ====
Soohwan(ETRI) proposes to postpone this CR.
Xiaoyan (CATT) support r06 with small modifications to address Soohwan (ETRI) comments.
Soohwan (ETRI) objects to approve this CR.
Xiaoyan (CATT) clarifies to Soohwan (ETRI) and support approving r06 with small modifications.
Dimitris (Lenovo) is ok with r04 or r06 with the modifications proposed by Xiaoyan (CATT). Propose to discuss in CC2
Dimitris (Lenovo) suggests to go with r04 or r06 if acceptable
Soohwan (ETRI) disagrees to approve r04 and r06.
Gerald (Nokia): Nokia is only okay with r04, otherwise suggests to POSTPONE
Dimitris (Lenovo) asks Soohwan (ETRI) to reconsider agreeing r04
Soohwan (ETRI) revokes the objection on r04 and confirms that r04 is okay to us. Also, Soohwan (ETRI) asks to add ETRI as co-source company in r04.
Wang Yuan (Huawei) is fine with r04.
Xiaoyan (CATT) can only accept r06 or r05 with small modifications, objects to other revisions (including r00); otherwise fine to postpone.
Dimitris (Lenovo) requests clarification from Xiaoyan (CATT)
Xiaoyan (CATT) replies to Dimitris (Lenovo).
==== Comments Deadline ====.

Status:

Postponed.

TD S2-2108735 (CR) 23.288 CR0490 (Rel-17, 'F'): Alignment and corrections related to prepared analytics transfer. (Source: OPPO).
Document for: Approval.
Abstract: Summary of change: Change 'Nnwdaf_AnalyticsInfo_Transfer' to 'Nnwdaf_AnalyticsInfo_ContextTransfer' Delete step 6, move the step 5 to step 6, move step 8 to step 5.

Comment:

r03 agreed. Revised to S2-2109082.

Discussion and conclusion:

-

e-mail discussion:

Gerald (Nokia): Nokia disagrees with CR
Jungshin (Samsung) asks for clarification.
Boren (OPPO) replies to Nokia and Samsung.
Gerald (Nokia): Nokia responds to OPPO
Boren (OPPO) replies to Nokia and provides a r01.
Gerald (Nokia): Nokia provides r02
Boren (OPPO) provides r03.
Gerald (Nokia): Nokia is okay with r03
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109082.

TD S2-2109082 (CR) 23.288 CR0490R1 (Rel-17, 'F'): Alignment and corrections related to prepared analytics transfer. (Source: OPPO, Nokia).
Document for: Approval.
Abstract: Summary of change: Change 'Nnwdaf_AnalyticsInfo_Transfer' to 'Nnwdaf_AnalyticsInfo_ContextTransfer'. Clarify that step 8 may take place any time after step 4.

Comment:

Revision of S2-2108735r03. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108984 (CR) 23.288 CR0457R2 (Rel-17, 'F'): Clarifications on transfer of analytics context and analytics subscription. (Source: CATT, Samsung).
Document for: Approval.
Abstract: Summary of change: Clarify that the transfer of analytics context and analytics subscripton also applies to analytics subscriptions related to specific NF(s). Correct the descriptions regarding how the the source NWDAF discovers that the analytics consumer may change. Remove descriptions related to the parameter 'Analytics subscription aggregation information' from the procedure in clause 6.1B.2.2. Correct the description about new/old subscription Id in the procedure to align with the Nnwdaf_AnalyticsSubscription_Notify service operation definition. Move the NOTE related to 'Notification correlation information' to step 6 for the procedure in clause 6.1B.2.2. Clarify the descriptions only applying to analytics context/subscription transfer for UE related analytics. In clause 6.1B.4, fix the format of 'Aggregation related information' and 'Model related information' in the listed output information, to show they are part of the analytics context information. In clause 6.1B.4, the text 'Information allowing to identify an anlytics context' is replaced by the 'a list of context identifier(s)'.

Comment:

Revision of (Agreed) S2-2107810 from S2#147E. r04 agreed. Revised to S2-2109083. CC#4: CATT sustained objection to r04. Postponed.

Discussion and conclusion:

CC#4: CATT sustained objection to r04. Ericsson only accept r04. CATT suggested taking r04 and changing text as proposed by Samsung. This was postponed. The reserved revision in S2-2109083 was then withdrawn.

e-mail discussion:

Aihua(China Mobile) provides r01.
Gerald (Nokia): Nokia provides r02
Aihua(China Mobile) provides comments and r03.
Jungshin (Samsung): We can accept both r02 and r03.
Gerald (Nokia): Nokia comments on r03 and provides r04.
Aihua(China Mobile) comments and provides r05.
==== Revisions Deadline ====
Gerald (Nokia): Nokia prefers r04
Aihua(China Mobile) clarifies and thinks r05 is correct.
Xiaoyan (CATT) prefers r05.
Gerald (Nokia): Nokia clarifies the issue in r05. Prefers r04. Okay to stay with previous revision S2-2107810 agreed in last meeting.
Gerald (Nokia): Nokia replies to CATT
Zhang (Ericsson) asks for clarification
Aihua(China Mobile) proposes rewording.
Xiaoyan (CATT) replies to Nokia.
Aihua(China Mobile) clarifies to Zhang (Ericsson).
Xiaoyan (CATT) provides clarification to Zhang (Ericsson).
Zhang (Ericsson) provides comments
Gerald (Nokia): Nokia replies to China Mobile
Zhang (Ericsson) prefers r04 and object r05
Gerald (Nokia): Nokia objects r05.
Xiaoyan (CATT) objects r04.
==== Comments Deadline ====
Jungshin (Samsung) proposes a revised text
Aihua(CMCC) can live with the revised text from Jungshin.

Status:

Postponed.

TD S2-2109083 (CR) 23.288 CR0457R3 (Rel-17, 'F'): Clarifications on transfer of analytics context and analytics subscription. (Source: CATT, Samsung).
Document for: Approval.
Abstract: Summary of change: Clarify that the transfer of analytics context and analytics subscripton also applies to analytics subscriptions related to specific NF(s). Correct the descriptions regarding how the the source NWDAF discovers that the analytics consumer may change. Remove descriptions related to the parameter 'Analytics subscription aggregation information' from the procedure in clause 6.1B.2.2. Correct the description about new/old subscription Id in the procedure to align with the Nnwdaf_AnalyticsSubscription_Notify service operation definition. Move the NOTE related to 'Notification correlation information' to step 6 for the procedure in clause 6.1B.2.2. Clarify the descriptions only applying to analytics context/subscription transfer for UE related analytics. In clause 6.1B.4, fix the format of 'Aggregation related information' and 'Model related information' in the listed output information, to show they are part of the analytics context information. In clause 6.1B.4, the text 'Information allowing to identify an anlytics context' is replaced by the 'a list of context identifier(s)'.

Comment:

Revision of S2-2108984r04. CC#2: WITHDRAWN.

Discussion and conclusion:

-

Status:

Withdrawn.

## KI#4

TD S2-2108425 (CR) 23.288 CR0472 (Rel-17, 'F'): Clarification on input and output of slice load level analytics. (Source: China Telecom).
Document for: Approval.
Abstract: Summary of change: 1. Add the maximum number of UEs and maximum number of PDU sessions per network slice as input data in 6.3.2A, 6.3.4; 2. Add the UE ratio and PDU session ratio as output analysis for network slice in 6.3.3A; 3. Add NSACF as a consumer NF in 6.3.1.

Comment:

Postponed.

Discussion and conclusion:

-

e-mail discussion:

Belen (Ericsson) provides comments
Jiahui (China Telecom) replies to Belen (Ericsson)
Jiahui (China Telecom) provides r02.
==== Revisions Deadline ====
Belen (Ericsson) objects, given that its comments are not addressed. Propose to POSTPONE
Jiahui (China Telecom) agrees to POSTPONE and asks for clarification.
==== Comments Deadline ====.

Status:

Postponed.

TD S2-2108534 (CR) 23.288 CR0476 (Rel-17, 'F'): Clarify the resource usage for a network slice instance. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: - Remove the 'optional' limitation for the 'NF resource usage' in the NF load analytics. - Clarify the 'crossing' for the Resource usage threshold crossings and the Resource usage threshold crossings time period for the Slice load level analytics is 'are met or exceeded or crossed'. Also 'Crossed' in the Crossed Reporting Threshold(s) in the QoS sustainability analytics can be also 'crossed'. - Clarify that the 'Number of UE Registrations' and the 'Number of PDU Sessions establishment' in both the statistics and the predictions for the Network Slice Instance load/Network Slice load can also be maximum or minimum.

Comment:

r01 agreed. Revised to S2-2109084.

Discussion and conclusion:

-

e-mail discussion:

Belen (Ericsson) provides comments
David (Samsung) provides r01 and comments
Wang Yuan (Huawei) replies to Belen (Ericsson) and David (Samsung), and provides r02.
==== Revisions Deadline ====
Antoine (Orange) asks a question.
Wang Yuan (Huawei) replies to Antoine(Orange).
Belen (Ericsson) asks to POSPONE given that comments were not addressed.
Wang Yuan (Huawei) suggest to approve r01 which addressed Belen(Ericsson)'s comments.
Belen (Ericsson) is okay with r01
David (Samsung) would also like to co-source r01. Thanks.
==== Comments Deadline ====.

Status:

Revised to S2-2109084.

TD S2-2109084 (CR) 23.288 CR0476R1 (Rel-17, 'F'): Clarify the resource usage for a network slice instance. (Source: Huawei, HiSilicon, Ericsson, Samsung).
Document for: Approval.
Abstract: Summary of change: - Remove the 'optional' limitation for the 'NF resource usage' in the NF load analytics. - Clarify the 'crossing' for the Resource usage threshold crossings and the Resource usage threshold crossings time period for the Slice load level analytics is 'are met or exceeded or crossed'. Also 'Crossed' in the Crossed Reporting Threshold(s) in the QoS sustainability analytics can be also 'crossed'. - Clarify that the 'Number of UE Registrations' and the 'Number of PDU Sessions establishment' in both the statistics and the predictions for the Network Slice Instance load/Network Slice load can also be maximum or minimum.

Comment:

Revision of S2-2108534r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

## KI#8

TD S2-2108285 (LS IN) LS from CT WG3: LS on question and feedback about the EVEX Work Item. (Source: CT WG3 (C3-215316)).
Document for: Information.
Abstract: CT WG3 would like to thank SA WG4 for sharing the LS and EVEX WID, also asking whether CT WG3 has any questions or other feedback about the EVEX Work Item. After discussion, CT WG3 has below CT WG3 observations, with the related questions(Q) and feedbacks(F) about the EVEX Work Item and specifications: {. . .}.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Yannick (Nokia): Nokia provides comments.
Juan Zhang (Qualcomm) replies to Yannick (Nokia).
Mehrdad (Samsung) replies to Nokia and Qualcomm.
Yannick (Nokia): Nokia replies to Qualcomm and Samsung. Agrees that no LS reply is needed, we can follow-up in SA2 once SA4 has made some progress.
==== Revisions Deadline ====
Juan Zhang (Qualcomm) proposes to note the LS.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2109022 (LS IN) LS from SA WG4: Reply LS to CT3 Questions and Feedback on EVEX. (Source: SA WG4 (S4-211647)).
Document for: Information.
Abstract: SA WG4 thanks CT WG3 for reviewing and responding to SA WG4 LS in S4-210961 and the associated EVEX WID. We wish to provide the following responses to the CT WG3 observations, related questions, and feedback on the EVEX Work Item. Please note that in the following, for clearer distinction, inputs from CT WG3 are copied as is from CT WG3 LS where the SA WG4 replies are shown in green font. {. . .}.

Comment:

Postponed.

Discussion and conclusion:

-

e-mail discussion:

Yannick (Nokia): Nokia suggests to postpone this LS from SA4 which was received during our meeting.
==== Comments Deadline ====.

Status:

Postponed.

TD S2-2109023 (LS IN) LS from SA WG4: Reply LS to SA WG2 on UE Data Collection and Reporting. (Source: SA WG4 (S4-211648)).
Document for: Action.
Abstract: SA WG4 thanks SA WG2 for the reply LS on UE data collection and reporting, especially for the replies to SA WG4's questions in our previous LS to SA WG2. We wish to provide the following feedback, as shown in blue font, to SA WG2 responses to some of the original SA WG4 questions. {. . .} In addition to the above, as SA WG4 has responded in reply LS to CT WG3, we think that it may be useful in the near future to hold a trilateral conference call between CT WG3, SA WG2 and SA WG4 to better coordinate on the matters of these recent LS exchanges between SA WG2, CT WG3 and SA WG4. Since all three WGs will hold their e-meetings in mid-November 2021, with subsequent e-meetings in January/February 2022, early-to-mid December timeframe would seem opportune for such discussion. ACTION 1: SA WG4 asks SA WG2 to take the above SA WG4 feedback into account, review the latest draft versions of TS 26.531 and TS 26.532, and kindly inform SA WG4 whether SA WG2 has further questions or related comments. ACTION 2: SA WG4 asks SA WG2 to respond on your interest and availability to hold a 3-way teleconference among SA WG2, SA WG4 and CT WG3 on event exposure and UE data collection and reporting services and APIs on Thursday, December 9th, with a meeting start time of 6:00 am PST/3 pm CET/10 pm CST and duration of one hour.

Comment:

Postponed.

Discussion and conclusion:

-

e-mail discussion:

Yannick (Nokia): Nokia agrees to postpone this LS from SA4 which was received during our meeting. The LS is for action to SA2. The proposal from SA4 on a 3-way teleconference among SA2, SA4 and CT3 can probably be answered outside of LS exchange considering the proposed date of December 9th.
==== Comments Deadline ====.

Status:

Postponed.

TD S2-2108597 (CR) 23.502 CR3258 (Rel-17, 'F'): Update to NF services for UE data collection. (Source: CATT).
Document for: Approval.
Abstract: Summary of change: Add UE IPv4 address, UE IPv6 prefix, and 'any UE' as possible parameters for Target of Event Reporting in the Nnef_EventExposure_Subscribe. Add an indication on supporting mapping between UE IP address and UE ID to the NF profile of trusted AF or untrusted AF (via the NEF) for Nnrf_NFManagement_NFRegister. Editorial modification for the parameter Target of Event Reporting in the Naf_EventExposure_Subscribe service operation definition.

Comment:

Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108598 (CR) 23.288 CR0479 (Rel-17, 'F'): Clarifications for UE data collection. (Source: CATT).
Document for: Approval.
Abstract: Summary of change: Add Correlation information for data collected from 5GC NF and UE Application. Modify the procedure for Data Collection from UE, including clarifying 'UE data collection input data', etc. Move clause 6.2.8.2.4a behind clause 6.2.8.2.4.4.

Comment:

r03 agreed. Revised to S2-2109085.

Discussion and conclusion:

-

e-mail discussion:

Antoine (Orange) provides r01.
Yannick (Nokia): Nokia provides r02.
Mehrdad (Samsung) comments on original version and all revisons.
Xiaoyan (CATT) provides r03.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109085.

TD S2-2109085 (CR) 23.288 CR0479R1 (Rel-17, 'F'): Clarifications for UE data collection. (Source: CATT).
Document for: Approval.
Abstract: Summary of change: Add Correlation information for data collected from 5GC NF and UE Application. Modify the procedure for Data Collection from UE, including clarifying 'UE data collection input data', etc. Move clause 6.2.8.2.4a behind clause 6.2.8.2.4.4.

Comment:

Revision of S2-2108598r03. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108696 (CR) 23.288 CR0455R2 (Rel-17, 'F'): Restriction for 5GC to provide UE IP address to untrusted AF. (Source: OPPO).
Document for: Approval.
Abstract: Summary of change: The 5GC NF shall provide AF in untrusted domain only with the IPv4 address or IPv6 prefix serving the untrusted AF (i.e. no IPv4 addresses or IPv6 prefixes serving other AF(s) are provided to the untrusted AF). To align the terminology, the additional change to newly added sentence in SA WG2#148e: - Change 'AF for data collection' to 'AF'; - Change 'DCAF' to 'Data Collection AF'.

Comment:

Revision of (Agreed) S2-2107818 from S2#147E. r03 agreed. Revised to S2-2109086.

Discussion and conclusion:

-

e-mail discussion:

Yannick (Nokia): Nokia provides r01.
Belen (Ericsson) provides r02
Juan Zhang (Qualcomm) prefers r01.
Yang (OPPO) also prefer r01. Provides a clean-up version r03 based on r01.
==== Revisions Deadline ====
Juan Zhang (Qualcomm) proposes to approve r03.
==== Comments Deadline ====.

Status:

Revised to S2-2109086.

TD S2-2109086 (CR) 23.288 CR0455R3 (Rel-17, 'F'): Restriction for 5GC to provide UE IP address to untrusted AF. (Source: OPPO).
Document for: Approval.
Abstract: Summary of change: The 5GC NF shall provide AF in untrusted domain only with the IPv4 address or IPv6 prefix serving the untrusted AF (i.e. no IPv4 addresses or IPv6 prefixes serving other AF(s) are provided to the untrusted AF). To align the terminology, the additional change to newly added sentence in SA WG2#148e: - Change 'AF for data collection' to 'AF'; - Change 'DCAF' to 'Data Collection AF' - Change 'UE IP addresses' to 'UE IP address'.

Comment:

Revision of S2-2108696r03. Approved.

Discussion and conclusion:

-

Status:

Agreed.

## KI#10

TD S2-2108665 (CR) 23.288 CR0462R1 (Rel-17, 'F'): Clarify the Redundant Transmission Experience related analytics. (Source: China Mobile, Huawei).
Document for: Approval.
Abstract: Summary of change: Clarify the Redundant Transmission Experience related analytics. And some editorial corrections.

Comment:

Revision of (Postponed) S2-2107536 from S2#147E. Postponed.

Discussion and conclusion:

-

e-mail discussion:

Zhang (Ericsson) provides comments
Susan (Huawei) provides r01.
Hyunsook (LGE) provides comments
Susan (Huawei) replies.
Susan (Huawei) further clarifies.
Susan (Huawei) replies to Hyunsook (LGE).
Gerald (Nokia): Nokia provides comments
Susan (Huawei): replies and provides r02.
Susan (Huawei) provides r03.
Gerald (Nokia): Nokia asks for clarification
Susan (Huawei) replies to Gerald (Nokia).
Gerald (Nokia): Nokia comments on r03
Susan (Huawei) replies to Gerald (Nokia) and provides r04.
==== Revisions Deadline ====
Hyunsook (LGE) prefers to keep ''Observed/Predicted Redundant Transmission Experience value', and have a concern on r04 removing it.
Susan (Huawei) propose to move forward with r03 for this meeting.
Gerald (Nokia): Nokia suggests to POSTPONE
Zhang (Ericsson) is OK with r03 or postpone
Hyunsook (LGE) is OK with r03 or postpone.
==== Comments Deadline ====.

Status:

Postponed.

## KI#11

TD S2-2108533 (CR) 23.288 CR0475 (Rel-17, 'F'): Clarifications for Ndccf services and Nnwdaf_DataManagement services. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: - Clarify the 5G System architecture allows NWDAF, DCCF, MFAF to request data or analytics from an NWDAF which supports the Nnwdaf_DataManagement services as defined in clause 7.4. - Reverse the order of the Figure 4.2.0-3 and Figure 4.2.0-4; - Some others editorial changes.

Comment:

r01 agreed. Revised to S2-2109087.

Discussion and conclusion:

-

e-mail discussion:

Yannick (Nokia): Nokia provides r01.
Wang Yuan (Huawei) agree r01.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109087.

TD S2-2109087 (CR) 23.288 CR0475R1 (Rel-17, 'F'): Clarifications for Ndccf services and Nnwdaf_DataManagement services. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: - Clarify the 5G System architecture allows NWDAF, DCCF, MFAF to request data or analytics from an NWDAF which supports the Nnwdaf_DataManagement services as defined in clause 7.4. - Reverse the order of the Figure 4.2.0-3 and Figure 4.2.0-4; - Some others editorial changes.

Comment:

Revision of S2-2108533r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108686 (CR) 23.288 CR0482 (Rel-17, 'F'): Adding a list to enumerate NF services for enhanced procedures data collection. (Source: Vivo).
Document for: Approval.
Abstract: Summary of change: Add a table in clause 6.2.6.0 to enumerate all the NF services and corresponding references for enhanced procedures data collection.

Comment:

r01 agreed. Revised to S2-2109088.

Discussion and conclusion:

-

e-mail discussion:

Zhang (Ericsson) provides comments
Vivian(vivo) replies to Zhang(Ericsson) and provides r01.
Zhang (Ericsson) is OK with r01
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109088.

TD S2-2109088 (CR) 23.288 CR0482R1 (Rel-17, 'F'): Adding a list to enumerate NF services for enhanced procedures data collection. (Source: Vivo).
Document for: Approval.
Abstract: Summary of change: Add a table in clause 6.2.6.0 to enumerate all the NF services and corresponding references for enhanced procedures data collection.

Comment:

Revision of S2-2108686r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108687 (CR) 23.288 CR0483 (Rel-17, 'F'): Clarification for MFAF to be deployed or trusted by the operator. (Source: Vivo).
Document for: Approval.
Abstract: Summary of change: Add a note in clause 4.2.1 to clarify that the MFAF should be deployed or trusted by the operator.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Antoine (Orange) doesn't see the need for this CR.
Zhang (Ericsson) provides comments
Vivian (vivo) replies to Zhang(Ericsson) and Antoine(Orange)
Yannick (Nokia): Nokia comments on r00 and r01.
Malla (NTT DOCOMO) agrees with Antoine (Orange) and we also see no need for this CR.
Yannick (Nokia): Nokia provides comments.
Malla (NTT DOCOMO) object the CR.
Vivian (vivo) replies to all comments and agrees to note this CR.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

## KI#12

TD S2-2108273 (LS IN) LS from SA WG6: Reply LS on RAT type for network monitoring. (Source: SA WG6 (S6-212146)).
Document for: Action.
Abstract: SA WG6 thanks SA WG2 for the reply LS on RAT type for network monitoring. Related to SA WG2 question: - SA WG2 would like to understand which other analytics would need to be provided per RAT type beyond the two examples (QoS sustainability, congestion information) provided by SA WG6. SA WG6 would like to inform that, other analytics beyond the two examples (QoS sustainability, congestion information) are not contained in the network monitoring information. Related to SA WG2 question: - Also, SA WG2 would like to better understand the use case from SA WG6 and how such analytics on a per RAT type basis would be used by the VAE server, and what is referred exactly by VAE server assisting on V2V communication mode switch, considering that instructions sent by the VAE server to the UE shall not interfere with operator related camping policies configured in and by the NG RAN. SA WG6 would like to address that, the VAE server may determine to receive network monitoring information from EPC or 5GC or both considering the RAT type provided by the UE. The VAE server may refer to the V2X application service requirements, the network monitoring information received from SCEF and/or NEF/NWDAF, and application level information acquired from the UE when assisting on V2V communication mode switch. SA WG6 would also confirm that the instructions sent by the VAE server to the UE do not interfere with the operator defined camping policies configured in and by the NG RAN. Action: SA WG6 kindly asks SA WG2 to take the above information into account.

Comment:

Revision of S2-2107075 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

Yannick (Nokia): Nokia proposes to note this incoming LS.
Jungshin (Samsung) proposes to note the LS.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108314 (CR) 23.503 CR0656R1 (Rel-17, 'F'): Clarification on PCF behaviour based on OSE analytics. (Source: China Telecom, Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: This CR: [Change -1] clause 6.1.1.3 - Editorial changes - Clarify the PCF may use the 'Service Experience' analytics per RAT type and/or frequency for each application in use as input to determine if change the RFSP Index value is needed. - Add an example to clarify that the PCF may update the UE's RFSP index value when it finds the service experience for the application used by the UE in a RAT type or Frequency exceeds or does not meet the Reporting Threshold.

Comment:

Revision of (Agreed) S2-2107224 from S2#147E. Postponed.

Discussion and conclusion:

-

e-mail discussion:

Yannick (Nokia): Nokia provides comments.
Belen (Ericsson) provides comments.
Zhuoyi (China Telecom) China Telecom replies to Yannick and Belen, and provide r01.
Belen (Ericsson) asks China Telecom for clarifications
Zhuoyi (China Telecom) replies to Ericsson's question.
Belen (Ericsson) asks questions and think the CR needs futher work.
Zhuoyi (China Telecom) replies to Ericsson.
Belen (Ericsson) asks to POSTPONE this CR
==== Revisions Deadline ====
Zhuoyi (China Telecom) agrees to POSTPONE this CR
==== Comments Deadline ====.

Status:

Postponed.

TD S2-2108443 (CR) 23.288 CR0453R2 (Rel-17, 'F'): Clarification on Per-UE Service Experience Request Procedure. (Source: Tencent, Tencent Cloud, Huawei, Nokia).
Document for: Approval.
Abstract: Summary of change: Update the clause title to make it clear that the procedure is to request service experience for an application per UE. Also make some changes to clarify the description.

Comment:

Revision of (Agreed) S2-2107824 from S2#147E. Approved.

Discussion and conclusion:

-

e-mail discussion:

Belen (Ericsson) asks what the changes are compared with the agreed CR
Yannick (Nokia): Nokia clarifies that the CR revision is only for coversheet updates.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Agreed.

TD S2-2108716 (CR) 23.288 CR0489 (Rel-17, 'F'): Clarification on including location information for OSE analytics. (Source: Lenovo, Motorola Mobility).
Document for: Approval.
Abstract: Summary of change: Clarifying that UE location information is included in the analytic output when consumer includes in the analytics request: - A Target Area - A single target UE - A user has provided consent to use location data for the target UE.

Comment:

Postponed.

Discussion and conclusion:

-

e-mail discussion:

Wang Yuan (Huawei) comments on original and provides r01.
Gerald (Nokia): Nokia is okay with r00, comments on r01 and responds to Huawei
Belen (Ericsson) provides comments.
Dimitris (Lenovo) responds and provides r02
Malla (NTT DOCOMO) provided suggestions for note.
David (Samsung) provides r03, disagrees to aspects of r02.
Dimitris (Lenovo) responds to David (Samsung)
Belen (Ericsson) cannot accept restrictions to 1 UE only.
Belen (Ericsson) asks about r03, prefers r02
David (Samsung) asks for clarifications from Ericsson, still disagrees to r02 .
Belen (Ericsson) clarifies to Samsung
David (Samsung) comments.
Gerald (Nokia): Nokia prefers r02 over r03
Dimitris (Lenovo) provides r04 with a compromise proposal to include Group of UEs
Gerald (Nokia): Nokia provides r05
Belen (Ericsson) respond to Samsung, and comments on r04.
David (Samsung) provides r06
Belen (Ericsson) prefers r05, r06 cannot be accepted since the use of the Analytics subset is already defined.
Dimitris (Lenovo) prefers r05
==== Revisions Deadline ====
David (Samsung) objects to r05, r04 and r02. Samsung cannot understand why r06 is not agreeable.
Dimitris (Lenovo) can agree r06 but further clarifications would be needed on the next meeting
David (Samsung) agrees with Lenovo to work on clarifications needed for next meeting
Belen (Ericsson) objects to r06, is okay to work for next meeting.
David (Samsung) is OK to completely remove the change of cl. 6.4.1 in r06
Gerald (Nokia): Nokia proposes to POSTPONE
Dimitris (Lenovo) comments
==== Comments Deadline ====.

Status:

Postponed.

## KI#15

TD S2-2108995 (LS IN) LS from SA WG3: Reply LS on NTN specific User Consent . (Source: SA WG3 (S3-214349)).
Document for: Information.
Abstract: SA WG3 would like to thank RAN WG2 for their LS on NTN specific user consent. Depending on the local jurisdiction and its regulations, NTN specific user consent may be needed before gNB can configure the UE to report the UE location information. SA WG3 is currently introducing new requirements to TS 33.501 for user consent handling. Although such requirements are generic, they may need to be complemented in order to cover the different use cases, such as, in this context, the handling of user consent for UE location information for NTNs. SA WG3 has not yet studied how this user consent handling can be used specifically for the NTN use case.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108254 (LS IN) LS from SA WG3: LS on User consent . (Source: SA WG3 (S3-212123)).
Document for: Action.
Abstract: SA WG3 would like to inform SA WG2 on the work status of user consent study in TR 33.867 regarding user consent and revocation. In the context of eNA, data is processed for specific purposes and provided to external applications. Thus, a solution for user consent is important to have in Rel-17 along with the normative eNA feature currently progressed by SA WG2. SA WG3 has so far identified key issue #2 on 'User consent for UE data collection' and key issue #3 'Modification or revocation of user consent' in TR 33.867, for which solutions also related to eNA are needed. SA WG3 would like to mention: user consent requirements vary across regulatory environments, thus, the mechanisms for user consent do not need to be specified as 'shall'. Instead a wording such as 'depending on local regulatory requirements, - shall -' is sufficient. It is not in the remit of SA WG3 to decide in detail which data (raw data, analytics reports, models, etc.) might be subject to user consent in certain legal jurisdictions, therefore, requirements and recommendations given below are for 'data subject to user consent'. The final interpretation can only be provided by legal proceedings in courts. {. . .} Action: SA WG3 asks SA WG2 to take this information into account and keep SA WG3 informed of its progress.

Comment:

Revision of S2-2107001 from S2#147E. Response drafted in S2-2108969. Final response in S2-2109089.

Discussion and conclusion:

-

e-mail discussion:

Belen (Ericsson) asks to NOTE
==== Comments Deadline ====.

Status:

Replied to.

TD S2-2108969 (LS OUT) [DRAFT] LS Reply on user consent. (Source: Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: To: SA WG3. CC:

Comment:

Response to S2-2108254. r02 agreed. Revised to S2-2109089.

Discussion and conclusion:

CC#2: Nokia commented that the editor's note should be removed from the LS. The editor's note should be removed from the revision in S2-2109089, which remained approved.

e-mail discussion:

Malla (NTT DOCOMO) pointed that LS out text need to align with the approved CRs.
Gerald (Nokia): Nokia will provide a revision today afternoon
Gerald (Nokia): Nokia provides r01. R02 is expected based on outcome of the KI#15 discussions.
Gerald (Nokia): Nokia provides r02. Additional changes might be required based on final outcome of this meeting.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109089.

TD S2-2109089 (LS OUT) Reply LS on user consent. (Source: SA WG2).
Document for: Approval.
Abstract: To: SA WG3.

Comment:

Revision of S2-2108969r02. CC#2: Remove Editor's note. Approved.

Discussion and conclusion:

-

Status:

Approved.

TD S2-2108599 (CR) 23.288 CR0480 (Rel-17, 'F'): User consent for analytics and model training. (Source: CATT).
Document for: Approval.
Abstract: Summary of change: Add descriptions on NWDAF checking user consent before collecting user data for model (re)training. Add descriptions that the NWDAF rejects the request for analytics or ML model related to only one user if the user consent is not granted. Clarify that the NWDAF should also check user consent before collecting user data from an NF as described in clause 6.2.6.

Comment:

r12 agreed. Revised to S2-2109090.

Discussion and conclusion:

-

e-mail discussion:

Xiaoyan (CATT) provides r01 to merge changes in clause 6.2.9 of S2-2108689 into this CR.
Gerald (Nokia): Nokia supports the CR and provides r02
Mehrdad (Samsung) comments on original version r01 and r02.
Xiaoyan (CATT) provides r03.
Vivian(vivo) replies to Xiaoyan (CATT) and provides r04 and asks for co-sign.
Gerald (Nokia): Nokia provides r05
Malla (NTT DOCOMO) asks for clarification and raise a concern.
Mehrdad (Samsung) comments on r05
Xiaoyan (CATT) replies to Malla (NTT DOCOMO).
Xiaoyan (CATT) provides r06.
Xiaoyan (CATT) provides additional clarification to Malla (NTT DOCOMO).
Vivian (vivo) provides comment about Xiaoyan's(CATT) considering below and provides r07.
Wang Yuan (Huawei) has concerns for r07, provides r08 and also cosigns this CR.
Malla (NTT DOCOMO) provided comment.
Vivian(vivo)replies to Wang Yuan (Huawei) and provides r09.
Belen (Ericsson) provides r10, objects to previous revisions and initial document
Malla (NTT DOCOMO) provides r11
Gerald (Nokia): Nokia comments on r10 and r11
Belen (Ericsson) is okay with r11.
Gerald (Nokia): Nokia comments on r11
Xiaoyan (CATT) provides r12 to fix the editorial as commented by Gerald (Nokia).
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109090.

TD S2-2109090 (CR) 23.288 CR0480R1 (Rel-17, 'F'): User consent for analytics and model training. (Source: CATT, Nokia, vivo, Huawei).
Document for: Approval.
Abstract: Summary of change: Add descriptions that the NWDAF containing MTLF stops ML model (re)training if the user revokes user consent for analytics or model training. Clarify that the NWDAF should also check user consent before collecting user data from an NF as described in clause 6.2.6.

Comment:

Revision of S2-2108599r12. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108688 (CR) 23.288 CR0484 (Rel-17, 'F'): Termination request or rejection of NWDAF data managment service due to user consent not granted. (Source: Vivo).
Document for: Approval.
Abstract: Summary of change: Add a clarification that if user consent is not granted, then the NWDAF shall send an error response to the consumer in Nnwdaf_DataManagment _Response indicating the data subscription is not accepted due to user consent not granted Add a clarification that if user consent is revoked, then the NWDAF shall send a termination request in Nnwdaf_DataManagment _Notify to requests consumer to terminate the data subscription.

Comment:

r04 agreed. Revised to S2-2109091.

Discussion and conclusion:

-

e-mail discussion:

Gerald (Nokia): Nokia comments on original
Vivian (vivo) replies to Gerald's (Nokia) comments and provides r01.
Malla (NTT DOCOMO) provided comment.
Vivian(vivo) replies to Malla's (NTT DOCOMO) comment.
Vivian(vivo) apologizes for the wrong r02 and provides r03.
Gerald (Nokia): Nokia provides r04
==== Revisions Deadline ====
Vivian(vivo) thanks to Gerald (Nokia) and is OK with r04
==== Comments Deadline ====.

Status:

Revised to S2-2109091.

TD S2-2109091 (CR) 23.288 CR0484R1 (Rel-17, 'F'): Termination request or rejection of NWDAF data managment service due to user consent not granted. (Source: Vivo).
Document for: Approval.
Abstract: Summary of change: Add a clarification that if user consent is not granted, then the NWDAF shall send an error response to the consumer in Nnwdaf_DataManagment _Response indicating the data subscription is not accepted due to user consent not granted Add a clarification that if user consent is revoked, then the NWDAF shall send a termination request in Nnwdaf_DataManagment _Notify to requests consumer to terminate the data subscription.

Comment:

Revision of S2-2108688r04. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108689 (CR) 23.288 CR0485 (Rel-17, 'F'): Termination request or rejection of NWDAF ML model provision service due to user consent not granted. (Source: Vivo).
Document for: Approval.
Abstract: Summary of change: Add a clarification that before collecting data to do ML model training, the NWDAF may also need to check user consent information; If user consent is not or no longer granted, then NWDAF stops generation of new model and rejects/stops providing affected model to consumers (NWDAF containing AnLF).

Comment:

Not Handled.

Discussion and conclusion:

-

e-mail discussion:

XIaoyan (CATT) provides r01.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Not Handled.

TD S2-2108967 (CR) 23.288 CR0493 (Rel-17, 'B'): DCCF-based user consent checking. (Source: Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: Extend DCCF-related procedures in clause 6.2.6.3 with steps for DCCF to check if user consent for data to be collected is needed and available. If yes, DCCF will subscribe to changes on user consent from UDM. In case user consent is revoked, UDM will inform the DCCF and DCCF will update/terminate affected subscriptions and terminate data collection related to this user.

Comment:

r01 agreed. Revised to S2-2109092.

Discussion and conclusion:

-

e-mail discussion:

Vivian (vivo) comments on original.
Gerald (Nokia): Nokia is okay with r01
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109092.

TD S2-2109092 (CR) 23.288 CR0493R1 (Rel-17, 'B'): DCCF-based user consent checking. (Source: Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: Extend DCCF-related procedures in clause 6.2.6.3 with steps for DCCF to check if user consent for data to be collected is needed and available. If yes, DCCF will subscribe to changes on user consent from UDM. In case user consent is revoked, UDM will inform the DCCF and DCCF will update/terminate affected subscriptions and terminate data collection related to this user.

Comment:

Revision of S2-2108967r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108968 (CR) 23.288 CR0446R1 (Rel-17, 'B'): Tracking of distribution and usage of data subject to user consent. (Source: Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: New service Nadrf_DataTracking service with StorageRequest, RetrievalRequest, Delete service operations. Extend procedures where analytics/data is being provided by NWDAF/DCCF to data/analytics consumer with a NOTE to create a data tracking record in ADRF using Nadrf_DataTracking_Storage Request. This step is conditional to data being related to a user and depending on local policy and regulations. Clarify, in several procedures, that NWDAF or DCCF send a response to the consumer indicating that user consent for data collection was not granted. New procedure in clause 6.2.9.X specifying the usage of the Nadrf_DataTracking service operations.

Comment:

Revision of (Postponed) S2-2107295 from S2#147E. r02 agreed. Revised to S2-2109093. CC#2: Postponed.

Discussion and conclusion:

CC#2: China Mobile suggested postponing this to the next meeting. S2-2108968 was postponed. The reserved revision in S2-2109093 was withdrawn.

e-mail discussion:

Malla (NTT DOCOMO) provided comment and proposed that ADRF tracking functionality is studied in R18.
Vivian(vivo) provides comments.
Belen (Ericsson) objects to this contribution.
Gerald (Nokia): Nokia provides r01
Belen (Ericsson) objects to r01, initial version too.
Gerald (Nokia): Nokia disagrees with E// view on CatB CRs. Provides r02
==== Revisions Deadline ====
Aihua (CMCC): suggests to postpone this CR.
Gerald (Nokia): Nokia clarifies that r02 was changed to Cat. F
Aihua (CMCC): replies and suggests to postpone this CR.
==== Comments Deadline ====.

Status:

Postponed.

TD S2-2109093 (CR) 23.288 CR0446R2 (Rel-17, 'B'): Tracking of distribution and usage of data subject to user consent. (Source: Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: New service Nadrf_DataTracking service with StorageRequest, RetrievalRequest, Delete service operations. Extend procedures where analytics/data is being provided by NWDAF/DCCF to data/analytics consumer with a NOTE to create a data tracking record in ADRF using Nadrf_DataTracking_Storage Request. This step is conditional to data being related to a user and depending on local policy and regulations. Clarify, in several procedures, that NWDAF or DCCF send a response to the consumer indicating that user consent for data collection was not granted. New procedure in clause 6.2.9.X specifying the usage of the Nadrf_DataTracking service operations.

Comment:

Revision of S2-2108968r02. CC#2: WITHDRAWN.

Discussion and conclusion:

-

Status:

Withdrawn.

## KI#18

## KI#19

TD S2-2108535 (CR) 23.288 CR0450R2 (Rel-17, 'F'): Clarify the content of ML model provisioning. (Source: Huawei, HiSilicon, Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: - Rename the target for the ML model provisioning as 'Target of ML model Reporting', and add the description of ML model Reporting Information. - Do some alignment for the ML model related terminologies.

Comment:

Revision of (Agreed) S2-2107827 from S2#147E. r06 agreed. Revised to S2-2109094.

Discussion and conclusion:

-

e-mail discussion:

Zhang (Ericsson) provides r01 and co-sign
Wang Yuan (Huawei) replies to Zhang (Ericsson) and provides r02.
Soohwan (ETRI) provides r03.
Zhang (Ericsson) provides comments
Gerald (Nokia): Nokia provides r04
Wang Yuan (Huawei) replies to Zhang(Ericsson)/Gerald(Nokia) and provides r05.
Zhang (Ericsson) is OK with r05
Gerald (Nokia): Nokia prefers r04 over r05
Wang Yuan (Huawei) provides r06 based on Gerald(Nokia)'s comments.
Zhang (Ericsson) is OK for both r05 and r06
==== Revisions Deadline ====
Gerald (Nokia): Nokia is okay with r06
==== Comments Deadline ====.

Status:

Revised to S2-2109094.

TD S2-2109094 (CR) 23.288 CR0450R3 (Rel-17, 'F'): Clarify the content of ML model provisioning. (Source: Huawei, HiSilicon, Nokia, Nokia Shanghai Bell, Ericsson, CATT).
Document for: Approval.
Abstract: Summary of change: - Rename the target for the ML model provisioning as 'Target of ML model Reporting', and add the description of ML model Reporting Information. - Do some alignment for the ML model related terminologies.

Comment:

Revision of S2-2108535r06. Approved.

Discussion and conclusion:

-

Status:

Agreed.

# 8.2 Enhanced support of Non-Public Networks (eNPN)

This agenda item was convened by Puneet Jain (Intel).

TD S2-2108264 (LS IN) LS from CT WG1: LS on the scope of applying Network Slicing feature in Rel-17 and Rel-16. (Source: CT WG1 (C1-215137)).
Document for: Action.
Abstract: CT WG1 is now working on support of Network Slicing feature in Rel-17 for both PLMN and SNPN, however corresponding stage2 requirements on NSAC and NSSRG for SNPN are not found in SA WG2 specifications. Thus, CT WG1 would like to ask SA WG2 whether NSAC and NSSRG are applicable to SNPN in Rel-17 or not. In addition, CT WG1 had assumed that NSSAA can be performed in an SNPN throughout Rel-16. However, since Figure 5.30.2.9.3-1 of 3GPP TS 23.501 does not show NSSAAF, it was questioned whether NSSAA can be performed in an SNPN. Thus, CT WG1 would like to ask SA WG1 and SA WG2 to clarify whether there is a requirement to enable NSSAA in an SNPN. Action: CT WG1 kindly asks SA WG2 to confirm whether NSAC and NSSRG are applicable to SNPN in Rel-17 or not. In addition, CT WG1 would appreciate SA WG2's feedback on NSSAA in an SNPN.

Comment:

Revision of S2-2107026 from S2#147E. Responses drafted in S2-2108829 and S2-2108905. Postponed.

Discussion and conclusion:

-

Status:

Postponed.

TD S2-2108829 (LS OUT) [DRAFT] Reply LS on the scope of applying Network Slicing feature in Rel-17 and Rel-16. (Source: MediaTek Inc.).
Document for: Approval.
Abstract: Draft LS OUT to S2-2108264 (C1-215137) on the scope of applying Network Slicing feature in Rel-17 and Rel-16.

Comment:

Response to S2-2108264. Noted.

Discussion and conclusion:

-

e-mail discussion:

Devaki (Nokia) comments.
Josep (DT) requires clarifications to make the answer clearer, provides r01.
Chia-Lin (MediaTek) provides r02 on only change of 'a' to 'an' SNPN
==== Revisions Deadline ====
Devaki (Nokia) supports the LS out, any version is good. (sorry my earlier comment was for 8876 URSP LS out).
Peter Hedman (Ericsson) provides comments and objects to r01 and r02, and proposes a simple change.
Josep (DT) asks the reasoning behind the proposed change (removal of 'within').
Josep (DT) objects to r00.
Peter Hedman (Ericsson) provides reply
Josep (DT) states that NSSAA as part of CH has not been agreed.
Peter Hedman (Ericsson) provides reply that NSSAA in subscribed network is the only reasonable option for NSSAA
==== Comments Deadline ====
Yi (China Mobile) accept r02, objects r00 and r03.

Status:

Noted.

TD S2-2108905 (LS OUT) [DRAFT] Reply LS on the scope of applying Network Slicing feature in Rel-17 and Rel-16. (Source: China Mobile).
Document for: Approval.
Abstract: Reply LS on the scope of applying Network Slicing feature in Rel-17 and Rel-16 to CT WG1.

Comment:

Response to S2-2108264. Noted.

Discussion and conclusion:

-

e-mail discussion:

Peter (Ericsson) provides comments, and propose to use S2-2108829 as basis
==== Revisions Deadline ====
Devaki (Nokia) is not aligned with SoH outcome on Monday, objects to the LS out.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108265 (LS IN) LS from CT WG1: LS on network slice admission control for SNPN onboarding. (Source: CT WG1 (C1-215159)).
Document for: Action.
Abstract: For onboarding of UEs for SNPN, when the onboarding network is an SNPN, CT WG1 noted that the configuration information in the UE does not include any S-NSSAI used for onboarding, the UE does not include a Requested NSSAI to the AMF during the registration for onboarding and the S-NSSAI included in the AMF Onboarding Configuration Data is used for onboarding. For onboarding of UEs for SNPN, when the onboarding network is a PLMN, CT WG1 noted that the subscription data of a UE shall contain the DNN/S-NSSAI used for onboarding. CT WG1 also noted the Network Slice Admission Control Function (NSACF) has provided the admission control per network slice under eNS_Ph2, including maximum number of UEs per network slice and maximum number of PDU sessions per network slice. CT WG1 would like to ask SA WG2 when the UE is registering or registered for onboarding services in SNPN or PLMN, whether the network slice admission control needs to be performed for slice(s) used for onboarding or not?. Action: CT WG1 kindly asks SA WG2 to answer above question.

Comment:

Revision of S2-2107028 from S2#147E. Response drafted in S2-2108571. Final response in S2-2109257.

Discussion and conclusion:

-

Status:

Replied to.

TD S2-2108571 (LS OUT) [DRAFT] Reply LS on network slice admission control for SNPN onboarding. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Reply LS on network slice admission control for SNPN onboarding.

Comment:

Revision of (Postponed) S2-2107415 from S2#147E. Response to S2-2108265. r02 agreed. Revised to S2-2109257.

Discussion and conclusion:

-

e-mail discussion:

Antoine (Orange) provides r01.
Qianghua (Huawei) provides r02
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109257.

TD S2-2109257 (LS OUT) Reply LS on network slice admission control for SNPN onboarding. (Source: SA WG2).
Document for: Approval.
Abstract: To: CT WG1. Attachments: 23.501 CR#3241 (S2-2109035).

Comment:

Revision of S2-2108571r02. Approved.

Discussion and conclusion:

-

Status:

Approved.

TD S2-2108277 (LS IN) LS from CT WG1: Reply LS on limited service availability of an SNPN. (Source: CT WG1 (C1-216096)).
Document for: Information.
Abstract: CT WG1 thanks RAN WG2 for their LS on limited service availability of an SNPN. CT WG1 would like to provide the following feedback based on RAN WG2's question in their LS: RAN WG2 Question: Can CT WG1/SA WG2 to confirm that the R17 SNPN-capable UEs that are not in SNPN Access Mode and R17 Non-SNPN capable UEs cannot camp on an SNPN cell supporting emergency services to obtain emergency services via any SNPN. Yes. Based on the requirements specified in TS 24.501 and TS 23.122, CT WG1 understands that R17 SNPN-capable UEs that are not in SNPN Access Mode and R17 Non-SNPN capable UEs cannot camp on an SNPN cell and cannot obtain emergency services via any SNPN.

Comment:

Response drafted in S2-2108330. Final response in S2-2109254.

Discussion and conclusion:

-

Status:

Replied to.

TD S2-2108330 (LS OUT) [DRAFT] Reply LS on limited service availability of an SNPN. (Source: Qualcomm).
Document for: Approval.
Abstract: Replies to LS C1-216096.

Comment:

Response to S2-2108277. r00 agreed. Revised to S2-2109254.

Discussion and conclusion:

-

Status:

Revised to S2-2109254.

TD S2-2109254 (LS OUT) Reply LS on limited service availability of an SNPN. (Source: SA WG2).
Document for: Approval.
Abstract: To: CT WG1, RAN WG2. CC: SA WG1. Attachments: CR 3314 to TS 23.501.

Comment:

Revision of S2-2108330r00. Approved.

Discussion and conclusion:

-

Status:

Approved.

TD S2-2108282 (LS IN) LS from CT WG1: LS on PCF in case of SNPN with CH using AUSF/UDM for primary auth. (Source: CT WG1 (C1-216294)).
Document for: Action.
Abstract: CT WG1 has been working on the NAS layer protocol regarding the 5GS architecture for SNPN with CH using AUSF and UDM for primary authentication and authorization depicted in Figure 5.30.2.9.3-1 of 3GPP TS 23.501, which does not show a PCF in the CH domain. CT WG1 agreed that a URSP can be pre-configured in a UE for each of the subscribed SNPN and HPLMN. In addition, CT WG1 is discussing: a) for a UE which can access both a PLMN (when not operating in SNPN access mode) and an SNPN using the PLMN subscription (when operating in SNPN access mode), whether: i) Common URSP: the UE is expected to be (pre-)configured with one URSP applicable regardless whether the UE accesses a PLMN or an SNPN; or ii) Two URSPs: the UE is expected to be (pre-)configured with one URSP applicable when the UE accesses a SNPN and the other URSP applicable when the UE accesses a PLMN. b) how a UE associates URSP signaled via a registered SNPN when the UE has registered to the SNPN using credentials from a CH which is a PLMN or an SNPN, i.e., whether the signaled URSP via the registered SNPN should be associated with the registered SNPN or the CH. CT WG1 has not reached consensus on these two issues. Action: CT WG1 respectfully asks SA WG2 to provide feedback to the issues identified above.

Comment:

Responses drafted in S2-2108827 and S2-2108876. Postponed.

Discussion and conclusion:

-

Status:

Postponed.

TD S2-2108827 (LS OUT) [DRAFT] Reply LS on PCF in case of SNPN with CH using AUSF/UDM for primary auth.. (Source: MediaTek Inc.).
Document for: Approval.
Abstract: Draft LS OUT to S2-2108282 (C1-216294) on PCF in case of SNPN with CH using AUSF/UDM for primary auth.

Comment:

Response to S2-2108282. Noted.

Discussion and conclusion:

-

e-mail discussion:

Josep (DT) assumes that the discussion thread is S2-2108876.
Sebastian (Qualcomm) objects to the LS for reasons given for S2-2108828
==== Revisions Deadline ====
Chia-Lin (MediaTek) proposes this LS to be merged to S2-2108876 for easier maintaining discussion
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108876 (LS OUT) [DRAFT] Reply LS on PCF in case of SNPN with CH using AUSF/UDM for primary auth. (Source: Qualcomm).
Document for: Approval.
Abstract: -

Comment:

Response to S2-2108282. Noted.

Discussion and conclusion:

-

e-mail discussion:

Devaki (Nokia) comments.
Josep (DT) disagrees that dynamic policies and CH were in scope of the TR. Provides r01
Peter Hedman (Ericsson) provides comments
Josep (DT) replies.
Peter Hedman (Ericsson) provides reply
Antoine (Orange) provides r02.
Sebastian (Qualcomm) provides r03 and objects to r01 and r02
Antoine (Orange) provides r04.
Chia-Lin (MediaTek) provides comments on r04
Sebastian (Qualcomm) objects to r04
Antoine (Orange) provides r05.
Sebastian (Qualcomm) provides r06
==== Revisions Deadline ====
Antoine (Orange) comments on r06.
Devaki (Nokia) comments against r06, believes answer to Q1 is wrong, no common understanding.
Chia-Lin (MediaTek) cannot accept r06 and other versions including the original one since no agreements are made for two questions
Josep (DT) comments. Agrees that there seems to be no agreement.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108328 (CR) 23.501 CR3314R1 (Rel-17, 'F'): Support for emergency calls in limited service state. (Source: Qualcomm Incorporated).
Document for: Approval.
Abstract: Summary of change: Aligns text for emergency service in limited service state with TS 23.122.

Comment:

Revision of (Noted) S2-2107528 from S2#147E. r07 agreed. Revised to S2-2109259, merging S2-2108595.

Discussion and conclusion:

-

e-mail discussion:

Rainer (Nokia) provides r01.
Peter Hedman (Ericsson) provides r02
Peter Hedman (Ericsson) provides correct link to the r02
Hualin(Huawei) comments.
Huan(vivo) merge S2-2108595 and provides r03.
Josep (DT) co-signs, provides r04 with minor editorials.
Haris(Qualcomm) asks question for text removal in r03 and r04
Josep (DT) comments, provides r05.
Huan (vivo) provides feedback and willing to cosign
Jianning (Xiaomi) provide r06, and co-sign
Rainer (Nokia) is ok with r05.
Josep (DT) provides r07 with minor (English) editorials.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109259, merging S2-2108595.

TD S2-2109259 (CR) 23.501 CR3314R2 (Rel-17, 'F'): Support for emergency calls in limited service state. (Source: Qualcomm Incorporated, Ericsson, Deutsche Telekom, Xiaomi, vivo).
Document for: Approval.
Abstract: Summary of change: Aligns text for emergency service in limited service state with TS 23.122.

Comment:

Revision of S2-2108328r07, merging S2-2108595. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108444 (DISCUSSION) Discussion on UE ID of SNPN UE used for accessing emergency services in PLMN. (Source: vivo).
Document for: Agreement.
Abstract: Discussion on UE ID of SNPN UE used for accessing emergency services in PLMN.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108445 (CR) 23.501 CR3371 (Rel-17, 'F'): Correct the UE ID of SNPN UE used for accessing emergency services in PLMN. (Source: Vivo).
Document for: Approval.
Abstract: Summary of change: Correct the UE ID of SNPN UE used for accessing emergency services in PLMN.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

George Foti (Ericsson) provides comments. It is not clear what problem the CR is solving. What breaks if the ES is treated like a UE in limited service with no UICC. Will such a session not be established. This additional complexity is not required
Xiaowan(vivo) replies George Foti (Ericsson) and thinks S2-2108444 discussion slides can help to understand the problem
Kisuk (Samsung) agree with Ericsson's comments
Fei (OPPO) asks questions.
Xiaowan vivo(vivo) replies to Fei (OPPO) and seek further clarification.
Fei (OPPO) responds to Xiaowan (vivo)
Josep (DT) asks questions for clarification.
Rainer (Nokia) comments that the scenario is unclear.
Jianning (Xiaomi) provides view
Haris (Qualcomm) proposes to note the CR
Xiaowan (vivo) replies and provides r01
Josep (DT) comments. Proposes to formulate as a NOTE.
Rainer (Nokia) proposes to note 8445.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108446 (CR) 23.502 CR3238 (Rel-17, 'F'): Correct the UE ID of SNPN UE used for accessing emergency services in PLMN. (Source: Vivo).
Document for: Approval.
Abstract: Summary of change: Correct the UE ID of SNPN UE used for accessing emergency services in PLMN.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

George Foti (Ericsson) please see comments on 8445
Xiaowan(vivo) replies George Foti (Ericsson) and thinks S2-2108444 discussion slides can help to understand the problem
Rainer (Nokia) same as for 8445.
Haris(Qualcomm) proposes to note the CR
Xiaowan replies to Haris(Qualcomm)
Haris(Qualcomm) comments
Xiaowan(vivo) replies to Haris(Qualcomm) and also seek view from Antoine (ORANGE) whether authentication is possible or not when a SNPN UE access to PLMN for emergency service
Antoine (Orange) provides view.
Xiaowan(vivo) provides r01 and replies
Haris(Qualcomm) comments on r01
Josep (DT) proposes to send an LS to CT1 to clarify the behavior.
George (Ericsson) comments. What is the purpose of the LS. It is clear that this case can be treated like a UE without UICC. Is there anything else needed. Or are U proposing to send an LS with this clarification?
Xiaowan(vivo) provides Haris(Qualcomm)
Xiawan(vivo) doubts 'this case can be treated like a UE without UICC.' and thinks a LS to SA3 is helpful
Josep (DT) clarifies.
Fei (OPPO) comments.
==== Revisions Deadline ====
Antoine (Orange) asks a question.
Josep (DT) comments. Proposes to postpone.
Haris(Qualcomm) objects to this CR (all revisions)
Rainer (Nokia) proposes to note 8446.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108461 (CR) 23.501 CR3256R2 (Rel-17, 'F'): UE onboarding architecture. (Source: Ericsson, Nokia, Nokia Shanghai Bell, Qualcomm, Lenovo, Motorola Mobility, Huawei).
Document for: Approval.
Abstract: Summary of change: Editor's note removed and the ON-SNPN architecture with DCS updated. Updated NSSAAF description. Rev2 Update the NOTEs under onboarding architecture figures. Remove the N59 reference between UDM and NSSAAF in the figure Figure 5.30.2.10.2.2-2. Change vPCF in the figure to PCF.

Comment:

Revision of (Agreed) S2-2108095 from S2#147E. Not Handled.

Discussion and conclusion:

-

Status:

Not Handled.

TD S2-2108462 (CR) 23.502 CR3137R1 (Rel-17, 'F'): PDU session handling for inter-AMF mobility. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: Add generic reason for triggering of step 10 in clause 4.2.2.2.2, and change the network slice related scenario as one example.

Comment:

Revision of (unhandled) S2-2107186 from S2#147E. Not Handled.

Discussion and conclusion:

-

e-mail discussion:

Youngkyo(Samsung) proposes to merge this CR into S2-2108442 (AI#6.2).
Peter Hedman (Ericsson) provides comments and technically prefer 08642.
Youngkyo(Samsung) is okay to have this CR as a baseline and provides a r01.
Qianghua (Huawei) comments
Youngkyo(Samsung) replies to Qianghua(Huawei).
Devaki (Nokia) comments.
Youngkyo(Samsung) provides a revision r02.
Peter Hedman (Ericsson) provides r03
==== Revisions Deadline ====
Youngkyo(Samsung) prefers r02 but is okay with r03.
Youngkyo(Samsung) requests to take all the proposal of S2-2108462r03 into the S2-2108462, which is marked as merged into S2-2108462(AI#6.2) .
==== Comments Deadline ====.

Status:

Not Handled.

TD S2-2108465 (CR) 23.501 CR3257R2 (Rel-17, 'D'): Rapporteur's editorial cleanup for eNPN. (Source: Ericsson, [Nokia, Nokia Shanghai Bell, vivo, Deutsche Telekom]).
Document for: Approval.
Abstract: Summary of change: Usage of PVS instead of provisioning server. Removes the assumption that the PDU Session used for UP Remote Provisioning of credentials for NSSAA or secondary authentication is restricted. Put Note 2 to void about PLMN deregistration timer in clause 5.30.2.10.2.7 and added the same Note in clause 5.30.2.10.3.2 which is about PLMN selection and registration. Corrected cut and paste error in D.3 Replaces the PDU Session Establishment Request message with the Nsmf_PDUSession_CreateSMContext Request message when AMF provides the PVS IP address/FQDN to SMF in clause 5.30.2.10.4.2. - To replace 'remote provisioning of UE via User Plane', 'UP Remote Provisioning', 'user plane remote provisioning'with 'User Plane Remote Provisioning' - replace 'UE default credential' with 'Default UE credentials' Rev2: Change 'User Plan' to 'User Plane' Change 'Default UE Credentials' to 'Default UE credentials' Remove 'Default UE credentials' when the onboarding network is referring to ONN which includes both ON-SNPN and ON-PLMN.

Comment:

Revision of (Agreed) S2-2108090 from S2#147E. r02 agreed. Revised to S2-2109256.

Discussion and conclusion:

-

e-mail discussion:

Josep (DT) provides r01.
Josep (DT) forgot to format one bullet point. Provides r02
Jianning (Xiaomi) provides comment
Josep (DT) replies.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109256.

TD S2-2109256 (CR) 23.501 CR3257R3 (Rel-17, 'D'): Rapporteur's editorial cleanup for eNPN. (Source: Ericsson, Nokia, Nokia Shanghai Bell, vivo, Deutsche Telekom).
Document for: Approval.
Abstract: Summary of change: Usage of PVS instead of provisioning server. Removes the assumption that the PDU Session used for UP Remote Provisioning of credentials for NSSAA or secondary authentication is restricted. Put Note 2 to void about PLMN deregistration timer in clause 5.30.2.10.2.7 and added the same Note in clause 5.30.2.10.3.2 which is about PLMN selection and registration. Corrected cut and paste error in D.3 Replaces the PDU Session Establishment Request message with the Nsmf_PDUSession_CreateSMContext Request message when AMF provides the PVS IP address/FQDN to SMF in clause 5.30.2.10.4.2. - To replace 'remote provisioning of UE via User Plane', 'UP Remote Provisioning', 'user plane remote provisioning'with 'User Plane Remote Provisioning' - replace 'UE default credential' with 'Default UE credentials' Rev2: Change 'User Plan' to 'User Plane' Change 'Default UE Credentials' to 'Default UE credentials' Remove 'Default UE credentials' when the onboarding network is referring to ONN which includes both ON-SNPN and ON-PLMN. Formatted the list of features and functionalities that are not supported for SNPNs (5.30.2.0) as a list to improve readability. Moved line regarding Idle mobility one paragraph up to also improve readability.

Comment:

Revision of S2-2108465r02. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108466 (CR) 23.501 CR3373 (Rel-17, 'F'): Corrections for CH using AUSF/UDM. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: NOTE 3 in section 5.30.2.3 is clarified accordingly. The normative statement NOTE 3 relates too is also updated to refer only to the case of CH using AUSF/UDM as in the case of CH using AAA, none of the dependent NOTEs are relevant. Clarify that the SNPN support for UE access with credentials owned by a Credentials Holder using AUSF/UDM is related to the case where a UE from an SNPN or a PLMN get access and services via a SNPN different from the SNPN or PLMN it is subscribed to.

Comment:

r05 agreed. Revised to S2-2109260, merging S2-2108811.

Discussion and conclusion:

-

e-mail discussion:

Kisuk (Samsung) comments.
Huan (vivo) comments and ask for clarifications
Josep (DT) asks questions for clarification.
Jianning (Xiaomi) provides comment
Qianghua (Huawei) provides comments
Sebastian (Qualcomm) provides r01
Josep (DT) provides r02.
Peter Hedman (Ericsson) provides replies
Antoine (Orange) provides r03.
Jianning (Xiaomi) provides r04
Peter Hedman (Ericsson) provides r05
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109260, merging S2-2108811.

TD S2-2109260 (CR) 23.501 CR3373R1 (Rel-17, 'F'): Corrections for CH using AUSF/UDM. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: NOTE 3 in section 5.30.2.3 is clarified accordingly. The normative statement NOTE 3 relates too is also updated to refer only to the case of CH using AUSF/UDM as in the case of CH using AAA, none of the dependent NOTEs are relevant.

Comment:

Revision of S2-2108466r05, merging S2-2108811. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108467 (CR) 23.501 CR3374 (Rel-17, 'F'): Correction to AMF Onboarding Configuration Data. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: Clarified the AMF Onboarding Configuration data. Correct the User Plane Remote Provisioning reference to ON-SNPN clause.

Comment:

r03 agreed. Revised to S2-2109261.

Discussion and conclusion:

-

e-mail discussion:

Rainer (Nokia) provides r01.
Jihoon (ETRI) provides r02.
Jianning (Xiaomi) provides comment
Peter Hedman (Ericsson) provides reply
Jianning (Xiaomi) replies to Peter (Ericsson),
Peter Hedman (Ericsson) provides r03
==== Revisions Deadline ====
Jianning (Xiaomi) is ok with r03
Rainer (Nokia) is ok with r03.
Jihoon (ETRI) is also ok with r03.
==== Comments Deadline ====.

Status:

Revised to S2-2109261.

TD S2-2109261 (CR) 23.501 CR3374R1 (Rel-17, 'F'): Correction to AMF Onboarding Configuration Data. (Source: Ericsson, ETRI).
Document for: Approval.
Abstract: Summary of change: Clarified the AMF Onboarding Configuration data. Correct the User Plane Remote Provisioning reference to ON-SNPN clause.

Comment:

Revision of S2-2108467r03. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108472 (CR) 23.501 CR3241R1 (Rel-17, 'F'): Network slice admission control for SNPN onboarding. (Source: Ericsson, MediaTek Inc, Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: Clarified that network slice admission control is optionally, depending on operator policies, applied to slice(s) used for onboarding and emergency services and 24.501 describes how the UE associates the rejected S-NSSAI with the usage of SNPN Onboarding or emergency service as to avoid that the UE makes same request again.

Comment:

Revision of (Postponed) S2-2107118 from S2#147E. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108473 (CR) 23.501 CR3240R1 (Rel-17, 'F'): Network Slicing scope in relation to SNPNs. (Source: Ericsson, Qualcomm, MediaTek Inc, Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: It is that network slicing is applicable to SNPNs as well and that NSAC, NSSRG and NSSAA are generic optional network slicing functionality that also can be used by SNPNs.

Comment:

Revision of (Noted) S2-2107116 from S2#147E. CC#2: r01 agreed. Revised to S2-2109346.

Discussion and conclusion:

CC#2: S2-2108473r01 was proposed. S2-2108473r01 was agreed and was revised in S2-2109346.

e-mail discussion:

Josep (DT) objects to r00. Provides r01
Peter Hedman (Ericsson) provides comments
Yi (China Mobile) objects to the CR and ask for clarification.
Hualin(Huawei) comments this CR should also consider the Discussion paper S2-2108918.
Devaki (Nokia) responds to Hualin.
Chia-Lin (MediaTek) provides r02
Hualin(Huawei) provides r03 and r04.
Chia-Lin (MediaTek) cannot accept r04 and has concerns on r03
Fei (OPPO) comments on r03.
Rainer (Nokia) comments.
Hualin(Huawei) object r02, r01 and the original version.
==== Revisions Deadline ====
Josep (DT) objects to r00, r02, r03, r04, r05.
Devaki (Nokia) supports r00, r02, can live with r03 as well.
Haris(Qualcomm) prefers r00, can live with r01 (better than nothing), suggests WF for r03
Josep (DT) is OK to document in the minutes 'Prose is not supported for SNPNs'.
Chia-Lin (MediaTek) prefers with r00 and r02 and supports WF for r03. Can live with r01 since this aligns with the LS in S2-2108829
Fei (OPPO) is also ok to document in the minutes 'ProSe is not supported for NPNs'
Haris(Qualcomm) proposes to agree to r01 instead of noting the CR
Chia-Lin (MediaTek) supports Haris's suggestion to agree on r01
Peter Hedman (Ericsson) CR is related to the SoH at CC#1, i.e. proposes to agree e.g. r03 or try a WA, and if not possible ok with r01
Hualin (Huawei) can live with r01 in this meeting.
==== Comments Deadline ====.

Status:

Revised to S2-2109346.

TD S2-2109346 (CR) 23.501 CR3240R2 (Rel-17, 'F'): Network Slicing scope in relation to SNPNs. (Source: Ericsson, Qualcomm, MediaTek Inc, Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: It is that network slicing is applicable to SNPNs as well and that NSAC, NSSRG and NSSAA are generic optional network slicing functionality that also can be used by SNPNs.

Comment:

Revision of S2-2108473r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108569 (CR) 23.501 CR3394 (Rel-17, 'F'): Clarification for QoS differentiation for User Plane IPsec Child SA in underlay network. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Clarify that the PCF/SMF installs PCC rules/N4 rules for handling of packets corresponding to the detected DSCP value, in the case of network initiated QoS.

Comment:

Postponed. CC#2: r02 agreed. Revised to S2-2109352.

Discussion and conclusion:

CC#2: Huawei suggested r02. This was agreed and S2-2108569r02 was revised to S2-2109352.

e-mail discussion:

Peter (Ericsson) provides comments and r01
Qianghua (Huawei) replies
Qianghua (Huawei) provides r02
Peter Hedman (Ericsson) provides reply
==== Revisions Deadline ====
Devaki (Nokia) comments.
Devaki (Nokia) prefers to go with r01.
Qianghua (Huawei) prefers to go with r02 and replies
Peter Hedman (Ericsson) propose to POSTPONE the CR
Qianghua (Huawei) proposes to go r02 and replies
==== Comments Deadline ====.

Status:

Revised to S2-2109352.

TD S2-2109352 (CR) 23.501 CR3394R1 (Rel-17, 'F'): Clarification for QoS differentiation for User Plane IPsec Child SA in underlay network. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Clarify that the PCF/SMF installs new PCC rules/N4 rules for handling of packets corresponding to the User Plane IPsec Child SA based on the detected DSCP value, in the case of network initiated QoS.

Comment:

CC#2: Revision of S2-2108569r02. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108570 (LS OUT) [DRAFT] LS on support of DCS variants in UE Onboarding Architecture. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Inform SA WG3 about SA WG2 progress on support of DCS variants in UE Onboarding Architecture.

Comment:

r06 agreed. Revised to S2-2109258.

Discussion and conclusion:

-

e-mail discussion:

Rainer (Nokia) proposes to note the LS in 8570.
Qianghua (Huawei) replies
Rainer (Nokia) replies and asks for clarification.
Peter Hedman (Ericsson) provides comment that the SA3 is aware and no need for any LS
Rainer (Nokia) provides r01.
Qianghua (Huawei) provides r02
Fei (OPPO) provides r03.
Saso (Intel) provides r04.
Rainer (Nokia) provides r05.
Peter Hedman (Ericsson) provides r06
Rainer (Nokia) replies, is ok with r06.
==== Revisions Deadline ====
Megha (Intel) provides comments.
Qianghua (Huawei) OK with r06
Megha (Intel) OK with r06.
Fei (OPPO) is fine with r06.
==== Comments Deadline ====.

Status:

Revised to S2-2109258.

TD S2-2109258 (LS OUT) LS on support of DCS variants in UE Onboarding Architecture. (Source: SA WG2).
Document for: Approval.
Abstract: To: SA WG3.

Comment:

Revision of S2-2108570r06. Approved.

Discussion and conclusion:

-

Status:

Approved.

TD S2-2108572 (CR) 23.501 CR3395 (Rel-17, 'F'): Clarification for SNPN access using CH credentials and NSAC for onboarding slice. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Calrify that Network Slice Admission Control maybe supported for S-NSSAI used for onboarding based on operator policies in the onbarding network. Clarify that the AMF always selects the SMF in the SNPN regardless of Subscription information from UDM, i.e. bullet f) of clause 6.3.2.

Comment:

Covered by S2-2108472.

Discussion and conclusion:

-

e-mail discussion:

Peter (Ericsson) provides comments
Devaki (Nokia) objects to the first change in this paper, proposes to merge second change with 8472 thus the CR can be noted or partially merged.
Qianghua (Huawei) replies
Antoine (Orange) comments and asks a question.
Qianghua (Huawei) replies and agrees to merge this paper into 08472
==== Revisions Deadline ====
Devaki (Nokia) comments, proposes to consider the paper merged.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108595 (CR) 23.501 CR3397 (Rel-17, 'F'): Correction on emergency service support in SNPN access mode. (Source: Vivo).
Document for: Approval.
Abstract: Summary of change: Describe that if the UE is in limited service state, the UE shall attempt to camp on an acceptable cell of any available SNPN supporting emergency calls (irrespective of SNPN ID or GIN) or on any available PLMN supporting emergency calls (irrespective of PLMN ID) as defined in TS 23.122 [17]. Delete the reference to the clause itself. Correct the clause reference.

Comment:

Merged into S2-2109259.

Discussion and conclusion:

-

e-mail discussion:

Peter (Ericsson) provides comments and propose to mark CR as merged into 108328
Huan(vivo) is OK to merge S2-2108595 into 108328.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Merged into S2-2109259.

TD S2-2108596 (CR) 23.501 CR3398 (Rel-17, 'F'): Clarification of access PLMN service via SNPN and vice versa. (Source: Vivo).
Document for: Approval.
Abstract: Summary of change: To access PLMN services, a UE in SNPN access mode that has successfully registered with an SNPN (using the credentials of that SNPN) may perform another registration via the SNPN User Plane with a PLMN (using the credentials of that PLMN). And vice versa.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Sebastian (Qualcomm) objects to the CR
Myungjune (LGE) proposes to note the CR
Kisuk (Samsung) proposes to note the CR
Huan (vivo) clarify and do not think the scenarios proposed by Qualcomm are within the scope of R16 and R17 NPN
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108704 (CR) 23.501 CR3417 (Rel-17, 'F'): Correction on realm part of SNPN NAI SUPI. (Source: Deutsche Telekom).
Document for: Approval.
Abstract: Summary of change: Removal of of the text in TS 23.501 referring to the optional inclusion of NID in the real part of the NAI. TS 23.003 is referenced one sentence before and thus said statement can be removed ('[-] takes the form of a Network Access Identifier (NAI) using the NAI RFC 7542 [20] based user identification as defined in clause 28.7.2 of TS 23.003 [19]').

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Devaki (Nokia) provides r01.
Jianning (Xiaomi) prefers r01, rather than deleting the existing requirement.
Josep (DT) can live with the proposed r01. Provides r02 with fixed cover sheet fitting r01 changes
Sebastian (Qualcomm) objects to the CR; all versions
Kisuk (Samsung) agrees with Qualcomm's opinion.
Peter Hedman (Ericsson) provides comments
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108706 (CR) 23.501 CR3256R3 (Rel-17, 'F'): UE onboarding architecture. (Source: [Ericsson, ]Nokia, Nokia Shanghai Bell[, Qualcomm, Lenovo, Motorola Mobility, Huawei]).
Document for: Approval.
Abstract: Summary of change: Editor's note removed and the ON-SNPN architecture with DCS updated. Updated NSSAAF description.

Comment:

Revision of (Agreed) S2-2108095 from S2#147E. Postponed.

Discussion and conclusion:

-

e-mail discussion:

Huan (vivo) comments and ask for clarifications
Rainer (Nokia) replies to Huan (vivo).
Haris(Qualcomm) asks question for clarification
Rainer (Nokia) replies.
Haris(Qualcomm) provides r01
Rainer (Nokia) provides r02.
Haris(Qualcomm) replies to Huan (vivo)
Megha (Intel) provides r03 and comments
Peter Hedman (Ericsson) provides comment and propose to notet he CR as it seems it would not work to support both DCS options with same HNI.
Fei (OPPO) agree with Peter (Ericsson).
Fei (OPPO) comments and provides r04.
Haris(Qualcomm) comments on r04 and asks whether to ask this question to SA3
Qianghua (Huawei) replies
Fei (OPPO) responds
Peter Hedman (Ericsson) provides comments
Megha (Intel) provides r05 and comments
Megha (Intel) provides comments
Huan (vivo) provides comments
Hualin (Huawei) comments.
Peter Hedman (Ericsson) provides comment that LS to SA3 would be useful
==== Revisions Deadline ====
Peter Hedman (Ericsson) proposes to postpone THIS CR revision
Megha (Intel) proposes to postpone this CR.
Rainer (Nokia) is ok to postpone 8706.
==== Comments Deadline ====.

Status:

Postponed.

TD S2-2108710 (CR) 23.501 CR3274R2 (Rel-17, 'F'): ENPN corrections to clarify use of DNN and S-NSSAI for onboarding, AUSF discovery. (Source: Nokia, Nokia Shanghai Bell, Ericsson, Samsung, ZTE).
Document for: Approval.
Abstract: Summary of change: Clarify that DNN and S-NSSAI used for onboarding are only used in the context of UE onboarding in case of ON-PLMN.Onboarding network is a SNPN: Introduce an onboarding indication which the AMF may provide to the SMF together with DNN/S-NSSAI and the SMF to the PCF, when a PDU Session for remote provisioning is established. Refer to 5.30.2.3 for UE configuration assumption. Onboarding network is a PLMN: Clarify that UE may request PVS address information via PCO for the subscribed DNN/S-NSSAI used for onboarding.

Comment:

Revision of (Agreed) S2-2108101 from S2#147E. CC#2: r02 agreed. Revised to S2-2109349.

Discussion and conclusion:

CC#2: Nokia suggested to reconsider r01. This was not acceptable. Nokia then suggested considering r02 and making an alignment change to S2-2108783. ZTE clarified that this would be removing the change to step 1. S2-2108710r02 was agreed and revised in S2-2109349.

e-mail discussion:

Qianghua (Huawei) provides r01
Huan (vivo) comments and provides r02
Rainer (Nokia) cannot accept r02.
Rainer (Nokia) is ok with r01.
Fei (OPPO) shares concern raised by Huan (vivo).
Rainer (Nokia) replies.
Fei (OPPO) can live with it.
Huan (vivo) comments and ask whether need to be discussed in CC
==== Revisions Deadline ====
Huan (vivo) comments and can only accept r02
Qianghua (Huawei) replies and suggests for r01
Huan (vivo) asks for clarfication
Rainer (Nokia) prefers r01.
Huan (vivo) provides comments
Ashok (Samsung) requests for clarification from Huan (vivo) and also prefers r01
Peter Hedman (Ericsson) prefers r01
==== Comments Deadline ====.

Status:

Revised to S2-2109349.

TD S2-2109349 (CR) 23.501 CR3274R3 (Rel-17, 'F'): ENPN corrections to clarify use of DNN and S-NSSAI for onboarding, AUSF discovery. (Source: Nokia, Nokia Shanghai Bell, Ericsson, Samsung, ZTE).
Document for: Approval.
Abstract: Summary of change: Onboarding network is a SNPN: Introduce an onboarding indication which the AMF may provide to the SMF together with DNN/S-NSSAI and the SMF to the PCF, when a PDU Session for remote provisioning is established. Refer to 5.30.2.3 for UE configuration assumption.

Comment:

Revision of S2-2108710r02. CC#2: Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108715 (CR) 23.503 CR0661R2 (Rel-17, 'F'): Clarification for PVS address formats. (Source: Nokia, Nokia Shanghai Bell, Ericsson, Samsung, ZTE).
Document for: Approval.
Abstract: Summary of change: Clarify that Provisioning Server address(es) may include IP address(es) and FQDN(s). Also, clarify that DNS address(es) are locally configured at the PCF. Clarify that SMF provides onboarding indication to PCF for PDU sessions used for onboarding.

Comment:

Revision of (Agreed) S2-2108107 from S2#147E. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108726 (CR) 23.502 CR3280 (Rel-17, 'F'): 23.502 Clarification on NF discovery by NRF in Onboarding or external authentication scenario. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Add a new clause to describe the NF/NF service discovery by NF service consumer in the same SNPN.

Comment:

r03 agreed. Revised to S2-2109262.

Discussion and conclusion:

-

e-mail discussion:

Josep (DT) proposes to NOTE.
Hualin(Huawei) replied to Josep (DT) and provide r01.
Peter Hedman (Ericsson) provides r02
Josep (DT) comments, provides r03.
Hualin(Huawei) is ok with r03.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109262.

TD S2-2109262 (CR) 23.502 CR3280R1 (Rel-17, 'F'): 23.502 Clarification on NF discovery by NRF in Onboarding or external authentication scenario. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Add a new clause to describe the NF/NF service discovery by NF service consumer in the same SNPN.

Comment:

Revision of S2-2108726r03. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108727 (CR) 23.502 CR3281 (Rel-17, 'F'): 23.502 Update procedure of Registration with Onboarding SNPN. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Provide separate call flow for each architecture since different entities are involved in different Onboarding architectures. Specify the local configuration in AUSF.

Comment:

r04 agreed. Revised to S2-2109263.

Discussion and conclusion:

-

e-mail discussion:

Rainer (Nokia) provides r01.
Jianning (Xiaomi) provides comment
Hualin(Huawei) replied to Jianning (Xiaomi).
Peter Hedman (Ericsson) provides r02
Jianning (Xiaomi) provide comment
Hualin(Huawei) provide r03 based on the comments.
Rainer (Nokia) replies, cannot accept r03.
Hualin(Huawei) provide r04.
==== Revisions Deadline ====
Rainer (Nokia) replies.
Hualin(Huawei) replies.
Rainer (Nokia) is ok with r04.
Peter Hedman (Ericsson) ok with r04
==== Comments Deadline ====.

Status:

Revised to S2-2109263.

TD S2-2109263 (CR) 23.502 CR3281R1 (Rel-17, 'F'): 23.502 Update procedure of Registration with Onboarding SNPN. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Update call flow for registration with Onboarding SNPN to cover two cases i.e. DCS with AAA server and DCS with AUSF/UDM.

Comment:

Revision of S2-2108727r04. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108783 (CR) 23.502 CR3206R2 (Rel-17, 'F'): Adding PVS information as imput to SMF and PCF sevice operation.. (Source: ZTE, Nokia, Nokia Shanghai Bell, Ericsson).
Document for: Approval.
Abstract: Summary of change: In Nsmf_PDUSession_CreateSMContext service operation, the AMF may provides the PVS address and Onboarding indication to SMF. In the Npcf_SMPolicyControl_Create service operation, the SMF may provides the PVS address and Onboarding indication to PCF. When Onboarding Network is a PLMN, UE may request PVS address information via PCO for the subscribed DNN/S-NSSAI used for onboarding.

Comment:

Revision of (Agreed) S2-2108106 from S2#147E. CC#2: Revised to remove the change to Step 1 in S2-2109350.

Discussion and conclusion:

CC#2: S2-2108783 was revised to remove the change to Step 1, to S2-2109350.

e-mail discussion:

Ashok (Samsung) comments
==== Revisions Deadline ====
Zhendong (ZTE): provides the repsonse
==== Comments Deadline ====.

Status:

Revised to remove the change to Step 1 in S2-2109350.

TD S2-2109350 (CR) 23.502 CR3206R3 (Rel-17, 'F'): Adding PVS information as imput to SMF and PCF sevice operation.. (Source: ZTE, Nokia, Nokia Shanghai Bell, Ericsson, Samsung).
Document for: Approval.
Abstract: Summary of change: In Nsmf_PDUSession_CreateSMContext service operation, the AMF may provide the PVS address and Onboarding indication to SMF. In the Npcf_SMPolicyControl_Create service operation, the SMF may provide the PVS address and Onboarding indication to PCF.

Comment:

CC#2: Revision of S2-2108783, removing change to Step 1. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108810 (CR) 23.501 CR3431 (Rel-17, 'F'): Correction for switching 3GPP access between SNPN and PLMN. (Source: Xiaomi).
Document for: Approval.
Abstract: Summary of change: For Switch between SNPN and PLMN, to add description for 'access mode is switched and network selection is performed'with one NOTE to explain that it is up to application and implementation to trigger the access mode For switch between SNPNs, to add description for'network selection is performed'.

Comment:

Confirm CR Number - CR states 8810! r03 agreed. Revised to S2-2109264.

Discussion and conclusion:

-

e-mail discussion:

Devaki (Nokia) comments that the CR seems unnecessary, also do not see the need to introduce non-SNPN AM for PLMN case.
Youngkyo(Samsung) shares the same view with Devaki (Nokia).
Josep (DT) supports this CR, provides r01 and co-signs.
Jianning (Xiaomi) is fine with r01, and replies to Youngkyo(Samsung) and Devaki (Nokia)
Sebastian (Qualcomm) objects to the CR; all versions
Jianning (Xiaomi) replies to Sebastian (Qualcomm)
Josep (DT) fully agrees with Jianning (Xiaomi).
Jianning (Xiaomi) provides r02
Peter Hedman (Ericsson) provides r03
==== Revisions Deadline ====
Jianning (Xiaomi) can live with r03
Dieter (Deutsche Telekom) comments. Can update following below still? Otherwise it is not consistent and may be interpreted incorrect? We can also do it next meeting, i.e. can postpone for this meeting.
Jianning (Xiaomi) replies to Dieter (DT), propose to approve r03 + add 'the network selection is performed as specified in TS 23.122[17],' in second paragraph as Dieter suggested, in CC#2
Dieter (Deutsche Telekom) that is agreeable.
==== Comments Deadline ====.

Status:

Revised to S2-2109264.

TD S2-2109264 (CR) 23.501 CR3431R1 (Rel-17, 'F'): Correction for switching 3GPP access between SNPN and PLMN. (Source: Xiaomi, Deutsche Telekom).
Document for: Approval.
Abstract: Summary of change: For Switch between SNPN and PLMN, to add description for 'network selection is performed as specified in TS 23.122[17]'with one NOTE 'NOTE: When the UE moves its 3GPP access between SNPN and PLMN, it is up to UE implementation to activate/deactivate SNPN access mode' For switch between SNPNs, to add description for'network selection is performed as specified in TS 23.122[17]'.

Comment:

Revision of S2-2108810r03. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108811 (CR) 23.501 CR3432 (Rel-17, 'F'): Clarification for Credential Holder. (Source: Xiaomi).
Document for: Approval.
Abstract: Summary of change: Add NOTE 'NOTE X: PLMN is possible as role of Credentials Holder.'.

Comment:

Merged into S2-2109260.

Discussion and conclusion:

-

e-mail discussion:

Devaki (Nokia) provides r01 (although need for the CR is unclear, if it remains, r01 proposes correction to the statement).
Kisuk (Samsung) comments.
Jianning (Xiaomi) is fine with r01
Qianghua (Huawei) comments
Sebastian (Qualcomm) proposes to merge with S2-2108466
Peter Hedman (Ericsson) agree that 108466 is more complete i.e. better to mark this as merged into 108466
Jianning (Xiaomi) is fine to merge with 8466
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Merged into S2-2109260.

TD S2-2108828 (CR) 23.503 CR0688 (Rel-17, 'F'): URSP associatied to registered SNPN. (Source: MediaTek Inc.).
Document for: Approval.
Abstract: Summary of change: In case of UE registering to SNPN, it clarifies the URSP is provided by the PCF of the subscribed SNPN or of the registered SNPN (when accessed by the UE using the credentials from Credential Holder (CH)) and is associated with the registered SNPN.

Comment:

Postponed.

Discussion and conclusion:

-

e-mail discussion:

Devaki (Nokia) provides r01.
Josep (DT) objects to this CR.
Jianning (Xiaomi) provides view
Antoine (Orange) replies.
Jianning (Xiaomi) replies
Chia-Lin (MediaTek) replies and provides r02
Josep (DT) comments, provides r03.
Chia-Lin (MediaTek) provides more clarification
Antoine (Orange) provides r04.
Josep (DT) agrees with r04.
Sebastian (Qualcomm) objects to the CR (all versions)
Antoine (Orange) .
Devaki (Nokia) comments.
Chia-Lin (MediaTek) provides comments and r05
Josep (DT) supports to postpone.
Sebastian (Qualcomm) replies to Josef
Josep (DT) replies.
==== Revisions Deadline ====
Chia-Lin (MediaTek) provides to postpone the CR since we cannot have any consensus on this
Chia-Lin (MediaTek) provides the understadng from our side and hope we can some feedback on this for next meeting
Josep (DT) comments.
==== Comments Deadline ====
Chia-Lin (MediaTek) provides the reference content from TS 24.526 below.

Status:

Postponed.

TD S2-2108887 (CR) 23.501 CR3451 (Rel-17, 'F'): Update architecture figure for access to SNPNs using credentials from Credentials Holder using AUSF and UDM. (Source: Qualcomm).
Document for: Approval.
Abstract: Summary of change: Add PCF in the CH domain in Figure 5.30.2.9.3-1 in TS 23.501.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Josep (DT) objects to this CR.
Antoine (Orange) objects to this CR.
Sebastian (Qualcomm) asks a question
Antoine (Orange) replies.
Devaki (Nokia) supports the CR (thought I had commented earlier, seems my email was lost!).
Josep (DT) comments.
Sebastian (Qualcomm) replies
Peter Hedman (Ericsson) provides comments and supports the CR
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108906 (CR) 23.501 CR3308R2 (Rel-17, 'F'): Network slicing support for SNPN. (Source: China Mobile).
Document for: Approval.
Abstract: Summary of change: It is calrified that NSSAA, NSAC and NSSRG features are not supported for SNPN.

Comment:

Revision of (Noted) S2-2107501 from S2#147E. Confirm CR Revision - CR states 1! Noted.

Discussion and conclusion:

-

e-mail discussion:

Peter (Ericsson) provides comments and propose to note this CR
==== Revisions Deadline ====
Devaki (Nokia) is not aligned with SoH outcome on Monday, objects to the CR.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108908 (CR) 23.228 CR1249 (Rel-17, 'F'): Correction on IMS service provided to SNPN by independent IMS provider. (Source: China Mobile).
Document for: Approval.
Abstract: Summary of change: Clarify that all SNPNs serving for a Credentials Holder have same agreement with the same ISH.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Rainer (Nokia) provides r01.
Haris(Qualcomm) asks question for clarification
Rainer (Nokia) replies to Haris (Qualcomm), agrees that 8908 is not needed.
Yi (China Mobile) replies to Haris and provides r02.
Antoine (Orange) also agrees that the CR is not needed.
==== Revisions Deadline ====
Yi (China Mobile) replies to Antoine.
Antoine (Orange) objects this CR (all versions).
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108916 (CR) 23.501 CR3256R4 (Rel-17, 'F'): UE onboarding architecture. (Source: [Ericsson, Nokia, Nokia Shanghai Bell, Qualcomm, Lenovo, Motorola Mobility, Huawei],Intel).
Document for: Approval.
Abstract: Summary of change: Editor's note removed and the ON-SNPN architecture with DCS updated. Updated NSSAAF description.

Comment:

Revision of (Agreed) S2-2108095 from S2#147E. CC#2: Postponed.

Discussion and conclusion:

CC#2: S2-2108916r03, adding AUSF and an editor's note was proposed by Intel. Qualcomm did not agree that reflects the SA WG3 solution. Intel replied that this is built upon the SA WG3 LS and the version of the CR agreed at SA WG2#147E would need to be 'unagreed' or will be subject to an update at TSG SA. Ericsson suggested using 'progressed' instead of 'checked' in the proposed Editor's Note. Qualcomm commented that figure 3 is incorrect. This was then postponed and S2-2108095 from S2#147E was also postponed.
Intel provided the following Objection: <Text from Intel (Saso)>.

e-mail discussion:

Peter (Ericsson) provides a questions and a comment
Qianghua (Huawei) provides comments
Rainer (Nokia) comments.
Megha (Intel) provides r01 and comments
Rainer (Nokia) asks for clarification.
Peter Hedman (Ericsson) prefers that there is an understanding of how the changes works before accepting them.
Qianghua (Huawei) replies
Hualin(Huawei) provide comments.
Rainer (Nokia) replies.
Saso (Intel) replies.
Haris(Qualcomm) comments
Haris(Qualcomm) provides r02
Saso (Intel) comments on r02
Rainer (Nokia) cannot accept r02.
Haris(Qualcomm) asks question on the SA3 agreement
Peter Hedman (Ericsson) provides comments and propose to add the questions raised here to the LS to SA3
Hualin(Huawei) is confused and comments.
Megha (Intel) provides r03 and comments
Peter Hedman (Ericsson) provides question
Megha (Intel) provides further comments
==== Revisions Deadline ====
Haris(Qualcomm) objects to this CR (all revisions inc the one I provided)
Saso (Intel) points out that Haris's (Qualcomm) comment is misleading. Proposes to approve r03.
Peter Hedman (Ericsson) provides comments and propose to postpone the CR and mark that SA2 alignment with SA3 is to be done at the next SA2 meeting
Haris(Qualcomm) reiterates objection
Saso (Intel) replies to Peter Hedman (Ericsson) and Haris (Qualcomm); reiterates to approved r03 based on the provided clarifications.
Megha (Intel) requests to mark this document for CC#2.
==== Comments Deadline ====
Haris(Qualcomm) suggests revision to be discussed in CC#2.

Status:

Postponed.

TD S2-2108918 (DISCUSSION) Support of 5G ProSe in PNI NPNs.. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: 5G_ProSe does not support PNI-NPN and SNPNs and therefore it needs to be clarified that 5G_ProSe and eNPN cannot work together.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Josep (DT) asks questions for clarification.
Marco (Huawei) answers to Josep (DT)
Peter Hedman (Ericsson) provides comments
Josep (DT) comments.
Haris(Qualcomm) comments
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2109020 (LS IN) LS from SA WG3: LS on conclusions of authentication methods for initial access for onboarding.. (Source: SA WG3 (S3-214334)).
Document for: Action.
Abstract: SA WG3 would like to inform SA WG2 about conclusions drawn for authentication of UE's requesting initial access for onboarding. The conclusions can be found in attached document. Action: SA WG3 kindly asks SA WG2 to take above conclusions into account and provide any feedback, if needed.

Comment:

Postponed.

Discussion and conclusion:

-

Status:

Postponed.

# 8.3 Enhancement of support for Edge Computing in 5GC (eEDGE_5GC)

This agenda item was convened by Puneet Jain (Intel).

## General

TD S2-2108294 (LS IN) LS from SA WG6: Reply LS on the definition of EAS and EAS context. (Source: SA WG6 (S6-212391)).
Document for: Information.
Abstract: SA WG6 would like to thank SA WG4 for their LS in S4-211231/S6-212356, seeking clarifications related to Application Context and Application Context Relocation. SA WG6 has discussed the questions and below are the SA WG6 responses: {. . .}.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Dario S. Tonesi (Qualcomm) suggests to note this LS.
Hui (Huawei) support to note this LS.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108719 (CR) 23.548 CR0018R2 (Rel-17, 'F'): Mega CR for minor fixes to TS 23.548. (Source: Huawei (Rapporteur)).
Document for: Approval.
Abstract: Summary of change: Mutliple editorial/minor corrections and cleanup to TS 23.548.

Comment:

Revision of (Agreed) S2-2108108 from S2#147E. r01 agreed. Revised to S2-2109265.

Discussion and conclusion:

-

e-mail discussion:

Hui (Huawei) provides r01
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109265.

TD S2-2109265 (CR) 23.548 CR0018R3 (Rel-17, 'F'): Mega CR for minor fixes to TS 23.548. (Source: Huawei (Rapporteur)).
Document for: Approval.
Abstract: Summary of change: Mutliple editorial/minor corrections and cleanup to TS 23.548.

Comment:

Revision of S2-2108719r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

## EAS discovery

TD S2-2108408 (CR) 23.548 CR0001R2 (Rel-17, 'F'): Correction related to uniqueness of Update related to a buffered DNS message in EASDF. (Source: Ericsson, Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: Unique message identifier in DNS message handling rule.

Comment:

Revision of (Endorsed) S2-2108111 from S2#147E. r02 agreed. Revised to S2-2109266.

Discussion and conclusion:

-

e-mail discussion:

Xinpeng(Huawei) provides r02.
Tingfang Tang (Lenovo) provides r01.
==== Revisions Deadline ====
Tingfang Tang (Lenovo) is OK with r01, r02, object r00.
Magnus H (Ericsson) we are ok with r02 as proposed by chairman
==== Comments Deadline ====.

Status:

Revised to S2-2109266.

TD S2-2109266 (CR) 23.548 CR0001R3 (Rel-17, 'F'): Correction related to uniqueness of Update related to a buffered DNS message in EASDF. (Source: Ericsson, Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: Unique message identifier in DNS message handling rule.

Comment:

Revision of S2-2108408r02. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108422 (CR) 23.548 CR0017R2 (Rel-17, 'F'): Updates on EAS Discovery Procedure with EASDF. (Source: Huawei, HiSilicon,Nokia, Nokia Shanghai Bell, Lenovo, Motorola Mobility, Ericsson, Tencent, Samsung, China Mobile,).
Document for: Approval.
Abstract: Summary of change: Some updates on EAS Discovery Procedure with EASDF as described above.

Comment:

Revision of (Agreed) S2-2108116 from S2#147E. CC#2: r05 + changes agreed. Revised to S2-2109267, merging S2-2108621.

Discussion and conclusion:

CC#2: China Mobile proposed S2-2108422r05 with changes: 1) Not showing the 6.2.3.4 and 6.2.3.4.1 in the CR to avoid the misunderstanding; 2) In Table 6.2.3.4-1,change 'External Group Identifier' to 'External Group Identifier/Internal Group Identifier'. This was agreed and the revision in S2-2109267 was approved.

e-mail discussion:

Magnus H (Ericsson) provides r01
Dan(China Mobile) provides r02
Xinpeng(Huawei) provides r03.
Magnus H (Ericsson) comments
Dan (China Mobile) ask a question
Tingfang Tang (Lenovo) replies and provides r04
Magnus H (Ericsson) provides r05
==== Revisions Deadline ====
Dan(China Mobile) is OK with r05
Xinpeng(Huawei) agrees with r05.
Laurent (Nokia): we shall remove the 5th change in the final version
Dan(China Mobile) request Laurent to maybe provide the exact part which we should correct
Magnus H (Ericsson) agrees with r05, but the indicated deletion under 5th change of clause 6.2.3.4.1 is not to be done. We see this as an editorial cleanup of the CR since CR has an updated part of 6.2.3.4.1 under second change
Xinpeng(Huawei) based on r05, suggests to change 'External Group Identifier' to 'External Group Identifier/Internal Group Identifier' in Table 6.2.3.4-1 Description of EAS Deployment Information.
Dan(China Mobile) understand the meaning of the 5th change now, the 6.2.3.4 and 6.2.3.4.1 will not be shown in the CR to avoid the misunderstanding in final version. Also request to change 'External Group Identifier' to 'External Group Identifier/Internal Group Identifier' in Table 6.2.3.4-1 .If needed we can do this in CC#2. Just small correction.
==== Comments Deadline ====.

Status:

Revised to S2-2109267, merging S2-2108621.

TD S2-2109267 (CR) 23.548 CR0017R4 (Rel-17, 'F'): Updates on EAS Discovery Procedure with EASDF. (Source: Huawei, HiSilicon,Nokia, Nokia Shanghai Bell, Lenovo, Motorola Mobility, Ericsson, Tencent, Samsung, China Mobile,).
Document for: Approval.
Abstract: Summary of change: Some updates on EAS Discovery Procedure with EASDF as described above.

Comment:

CC#2: Revision of S2-2108422r05 + changes, merging S2-2108621. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108621 (CR) 23.548 CR0017R3 (Rel-17, 'F'): Updates on EAS Discovery Procedure with EASDF. (Source: Huawei, HiSilicon, Nokia, Nokia Shanghai Bell, Lenovo, Motorola Mobility, Ericsson, Tencent, Samsung).
Document for: Approval.
Abstract: Summary of change: Some updates on EAS Discovery Procedure with EASDF as described above. Rename BaselineDNSHandlingInformation to BaselineDNSPattern.

Comment:

Revision of (Agreed) S2-2108116 from S2#147E. Merged into S2-2109267.

Discussion and conclusion:

-

e-mail discussion:

Hui (Huawei) suggests to merge this paper to S2-2108422.
Laurent (Nokia): suggests merging 8422 and 8621 that are revisions of the same CR from last meeting.
==== Revisions Deadline ====
Xinpeng(Huawei) confirms 8621 is merged into 8422.
==== Comments Deadline ====.

Status:

Merged into S2-2109267.

TD S2-2108622 (CR) 23.501 CR3299R2 (Rel-17, 'F'): 501 EASDF Service correction. (Source: Huawei, HiSilicon, Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: Change Neasdf_ BaselineDNSHandingInfo to Neasdf_ BaselineDNSPattern.

Comment:

Revision of (Agreed) S2-2108118 from S2#147E. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108790 (CR) 23.502 CR3185R2 (Rel-17, 'F'): Update Nnef_EASDeployment services. (Source: Tencent, Tencent Cloud, Nokia, Nokia Shanghai Bell, Huawei, Hisilicon, Ericsson, CATT, Lenovo, Motorola Mobility, China Mobile).
Document for: Approval.
Abstract: Summary of change: Correction of the Nnef_EASDeployment services in clause 5.2.6.26. Inserting data keys and data subkeys for EAS deployment information. Correcting Nnef_EASDeployment service. Other editorial corrections. Adding External/Internal Group ID in EAS deployment information related service operation.

Comment:

Revision of (Agreed) S2-2108119 from S2#147E. CC#2: r03 + changes agreed. Revised to S2-2109268.

Discussion and conclusion:

CC#2: S2-2108790r03 with some modifications was proposed by China Mobile. This was agreed and the revision in S2-2109268 was approved.

e-mail discussion:

Laurent (Nokia): provides r01
Xinpeng(Huawei) provides r02.
Magnus H (Ericsson) provides r03
==== Revisions Deadline ====
Dan (China Mobile) is OK with r03
Xinpeng(Huawei) only agrees with r03, and not ok for any other revisions.
Laurent (Nokia): I have a slight concern with R02 and R03 (removal of EAS Deployment Information reference)
Xinpeng(Huawei) replies to Laurent(Nokia).
Magnus H (Ericsson) comments
Xinpeng(Huawei) provides comments.
Magnus H (Ericsson) update previous comment
Xinpeng(Huawei) replies.
Tingfang Tang (Lenovo) asks question about r02 and r03 about EAS Deployment Information reference .
Magnus H (Ericsson) answers Tingfang (Lenovo)
Dan (China Mobile) request this for CC#2 with updating 5.2.6.26.4 by moving 'S-NSSAI, DNN' from input optional to input required.
Xinpeng(Huawei) replies to Magnus H (Ericsson).
Xinpeng(Huawei) provides further comments.
Tingfang Tang (Lenovo) comments .
Laurent (Nokia): Comments. I have reached my goal, the Tdoc needs a small update
Dan(China Mobile) provide an update summary
Magnus H (Ericsson) concludes that we are still discussing and that it would be best if CR is postponed to next meeting
==== Comments Deadline ====
Dan(China Mobile) do not agree to postpond this paper, and I would like to point it, your discussion is not related with what we want to do for group level EDI,postpond this paper the original cr will be sent to SA plenary as well.
Laurent (Nokia): suggests we approve 8790r03 with SA2 meeting notes that tell that work on the EDI API parameters (e.g. which parameters are Mandatory and which optional ) may take place at next meeting.

Status:

Revised to S2-2109268.

TD S2-2109268 (CR) 23.502 CR3185R3 (Rel-17, 'F'): Update Nnef_EASDeployment services. (Source: Tencent, Tencent Cloud, Nokia, Nokia Shanghai Bell, Huawei, Hisilicon, Ericsson, CATT, Lenovo, Motorola Mobility, China Mobile).
Document for: Approval.
Abstract: Summary of change: Correction of the Nnef_EASDeployment services in clause 5.2.6.26. Inserting data keys and data subkeys for EAS deployment information. Correcting Nnef_EASDeployment service. Other editorial corrections. Adding External/Internal Group ID in EAS deployment information related service operation.

Comment:

CC#2: Revision of S2-2108790r03 + changes. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108978 (CR) 23.502 CR3313 (Rel-17, 'F'): Corrections to AF Requests and Notification Procedures. (Source: Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: removes EAS Deployment information in step 6 of figure 4.3.6.2-1, and corrects reference to clause 6.2.3.4.3 of TS 23.548 adds: 'may indicate capability of supporting EAS IP replacement in 5GC' to steps 2a and 4c.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Tingfang Tang (Lenovo) provides r01.
Shubhranshu (Nokia) provides r02
Tingfang Tang (Lenovo) replies to Shubhranshu.
Shubhranshu (Nokia) provides r03
==== Revisions Deadline ====
Hui (Huawei) fine with r03
Magnus H (Ericsson) objects to all revisions except r01
Tingfang Tang (Lenovo) objects r02, accepts r01, can live with r03.
Shubhranshu (Nokia) proposes to agree r03
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108409 (CR) 23.548 CR0036 (Rel-17, 'F'): Improvements and correction to annex C. (Source: Ericsson, Nokia, Nokia Shanghai Bell, Qualcomm incorporated).
Document for: Approval.
Abstract: Summary of change: The following is changed: - Extend Annex C to describe how 5GC can monitor UE not using operator provided DNS server - Text improvements - Corrections related to trigger re-discovery, and in when referred to. - Corrections related to split UE.

Comment:

r06 agreed. Revised to S2-2109269.

Discussion and conclusion:

-

e-mail discussion:

Hui (Huawei) provides r01.
Dario (Qualcomm) asks question on r01
Changhong (Intel) comments.
Tingfang Tang (Lenovo) provides r02.
Magnus H (Ericsson) comments
Hui (Huawei) replies to Dario
Magnus H (Ericsson) provides r03
Changhong (Intel) provides r04
Hui (Huawei) supports r04
Dario (Qualcomm) provides r05
Magnus H (Ericsson) provides r06
==== Revisions Deadline ====
Dario (Qualcomm) is OK with r06
==== Comments Deadline ====.

Status:

Revised to S2-2109269.

TD S2-2109269 (CR) 23.548 CR0036R1 (Rel-17, 'F'): Improvements and correction to annex C. (Source: Ericsson, Nokia, Nokia Shanghai Bell, Qualcomm incorporated).
Document for: Approval.
Abstract: Summary of change: The following is changed: - Extend Annex C to describe how 5GC can monitor UE not using operator provided DNS server - Text improvements - Corrections related to trigger re-discovery, and in when referred to. - Corrections related to split UE.

Comment:

Revision of S2-2108409r06. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108411 (CR) 23.548 CR0005R1 (Rel-17, 'F'): Not all EC scenarios requires EASDF. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: Fixing when operator DNS settings are required.

Comment:

Revision of (unhandled) S2-2107239 from S2#147E. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108508 (CR) 23.548 CR0038 (Rel-17, 'F'): Change of DNS server address during EPC IWK. (Source: Samsung).
Document for: Approval.
Abstract: Summary of change: It is proposed to clarify the UE implementation when receiving the new DNS server address that is different from the one received from the EPC during EPC to 5GC handover.

Comment:

r02 agreed. Revised to S2-2109270.

Discussion and conclusion:

-

e-mail discussion:

Dario S. Tonesi (Qualcomm) asks question
Jicheol answers to the question of Dario (Qualcomm).
Magnus H (Ericsson) ask questions
Hui (Huawei) provide comments
Changhong (Intel) comments.
Jicheol explains the scenario.
Jicheol comment.
Hui (Huawei) provides r01.
Jicheol (Samsung) is okay with r01.
Dario (Qualcomm) provides r02
==== Revisions Deadline ====
Jicheol (Samsung) is okay with r02.
==== Comments Deadline ====.

Status:

Revised to S2-2109270.

TD S2-2109270 (CR) 23.548 CR0038R1 (Rel-17, 'F'): Change of DNS server address during EPC IWK. (Source: Samsung).
Document for: Approval.
Abstract: Summary of change: It is proposed to clarify the UE implementation when receiving the new DNS server address that is different from the one received from the EPC during EPC to 5GC mobility without N26.

Comment:

Revision of S2-2108508r02. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108511 (CR) 23.548 CR0039 (Rel-17, 'F'): Alignment of EASDF functional description. (Source: Samsung).
Document for: Approval.
Abstract: Summary of change: It is proposed to clarify EASDF functional description to align with the existing functionalites.

Comment:

r05 agreed. Revised to S2-2109271.

Discussion and conclusion:

-

e-mail discussion:

Hui (Huawei) asks for clarification
Xinpeng(Huawei) Provides r01.
Magnus H (Ericsson) provides r02
Xinpeng(Huawei) ask for clarification.
Magnus H (Ericsson) comments
Dario (Qualcomm) provides r04 and asks to ignore r03.
Xinpeng(Huawei) provides r05.
Hui(Huawei) provides r06.
==== Revisions Deadline ====
Xinpeng(Huawei) only agrees with r05, and objects to any other revisions.
Magnus H (Ericsson) r05 is OK
==== Comments Deadline ====.

Status:

Revised to S2-2109271.

TD S2-2109271 (CR) 23.548 CR0039R1 (Rel-17, 'F'): Alignment of EASDF functional description. (Source: Samsung).
Document for: Approval.
Abstract: Summary of change: It is proposed to clarify EASDF functional description to align with the existing functionalites.

Comment:

Revision of S2-2108511r05. Approved.

Discussion and conclusion:

-

Status:

Agreed.

## Usage of MNO DNS related

TD S2-2108775 (CR) 23.548 CR0030R2 (Rel-17, 'C'): EAS rediscovery: Edge DNS Client based EAS (re-)discovery. (Source: Qualcomm Incorporated, Vodafone, Deutsche Telekom, Telefonica, Verizon, NTT DoCoMo, Telecom Italia, AT&T, Charter, Telstra, KDDI, Matrixx, Convida Wireless, InterDigital, T-Mobile USA, Rogers, Facebook, Orange, Rakuten Mobile, KPN, TNO, Ericsson, China Mo).
Document for: Approval.
Abstract: Summary of change: Added the description of the EDC (Edge DNS Client) functionality that enables the UE to send the DNS query to the EASDF/DNS resolver/DNS server indicated by the MNO.

Comment:

Revision of (Endorsed) S2-2108177 from S2#147E. CC#2: r33 agreed. Revised to S2-2109347, merging S2-2108865.

Discussion and conclusion:

CC#2: Qualcomm proposed S2-2108775r33 with modifications on r29. This was agreed and was revised in S2-2109347.

e-mail discussion:

Hui (Huawei) suggests to take this paper to discuss basic EDC solution.
Hui (Huawei) provides r01 based on offline discussion.
Dario (Qualcomm) provides r02
Riccardo (NTT DOCOMO) provides r02.
Saso (Intel) comments on r03.
Dario (Qualcomm) comments on r03
Hui(Huawei) provides summary for further discussion
Zhuoyun (Tencent) comments.
Riccardo (NTT DOCOMO) replies on r03.
Tingfang Tang (Lenovo) provides r04 and r05.
Saso (Intel) replies to Riccardo.
Riccardo (NTT DOCOMO) replies to Saso.
Huazhang (vivo) ask a question.
Riccardo (NTT DOCOMO) replies to Huazhang and Saso.
Sudeep (Apple) provides r07.
Saso (Intel) comments that r04 and r06/r07 are two competing proposals.
Dario (Qualcomm) comments and provide r08.
Hui (Huawei) provides r10 based on r08.
Dario (Qualcomm) provides r11
Zhuoyun (Tencent) provides r12.
Huazhang (vivo) provides r13 based on r12 and merge the content from paper 8547
Hui (Huawei) comments to r11
Hui (Huawei) asks question to Zhuoyun.
Zhuoyun (Tencent) replies to Hui.
Hui (Huawei) replies to Zhuoyun.
Riccardo (NTT DOCOMO) is fine with r11 and does not like r12/r13.
Yang (OPPO) support Tencent's comment and ask question to Huawei.
Huazhang (vivo) provide r14 based on r11
Hui(Huawei) responses and proposes a way forward.
Yang (OPPO) further comments.
Susana (Vodafone) comments and provides r15 on the top of r11.
Yang (OPPO) uploads r17 removing 'force' indication.
Sudeep (Apple) comments on r15.
Huazhang (vivo) don't accept to remove the UE capability of support EDC in this paper
Riccardo (NTT DOCOMO) comments on Hui's proposed way forward
Svante (Sony) comments on r15
Huazhang (vivo) provides r19 based on r10, to add the EDC function is a UE capability
Josep (DT) asks for clarification whether r18, r19 are unclaimed, proposes wording for NOTE 4.
Hui (Huawei) provides r20
Susana (Vodafone) replies to Svante and Sudeep
Dario (Qualcomm) provides r22 and r23
Hui(Huawei) suggests to continue the discussion using r20.
Zhuoyun (Tencent) provides r24.
Tingfang Tang (Lenovo) comments and provides r25.
Huazhang (vivo) provides r26 to combine 22,23 and 20, and move forward, r26 is a minimum sets of our agreements in EDC to end this long long discussions. but R24 is also ok to me. I didn't find r25 in email.
Zhuoyun (Tencent) provides r28.
Dario (Qualcomm) provides r29
==== Revisions Deadline ====
Yang (OPPO) doubt the value of voting in CC until the technical concern can be resolved. Object r29 and any version including 'force' indication
Hui(Huawei) provides draft r30v1 for discussion.
Zhuoyun (Tencent) objects all the versions with introducing the feature of forcing the EDC usage for all the applications within certain PDU session. We prefer r12, is also fine with r04, r16, r17, r24, r26, r28, and object other versions.
Riccardo (NTT DOCOMO) prefers r23 and can accept r29/r30. Objects: r12, r13, r16, r17, r24, r26, r28.
Sudeep (Apple) comments on draftr30v1.
Huazhang (vivo) can only accept r14, objects any version.
But Huazhang can live with r26 r28 r29 and r30 add this sentence:
A UE that hosts EDC function may indicate this UE capability in the PCO during the PDU session establishment procedure that the 5GC determines the DNS query triggered in this PDU session is guaranteed to be sent to DNS server indicated by MNO. And the EDC functionality includes the following functionalities: XXXXX
Xiaobo Yu (Alibaba) can live with r12 and objects to any other revision.
Dario (Qualcomm) provides r31 for discussion in CC#2
Yang (OPPO) comments.
Dario (Qualcomm) provides r31b to be used with r31 in CC#2.
Svante (Sony) provide additional comments and accept r31b, r28 and r24. We object to r29, r26, r23, r22 and all other versions there the UE enforce that the application uses the EDC.
==== Comments Deadline ====
Xiaobo Yu (Alibaba) provides r31c base on the r31 for CC#2.
Yang (OPPO) provides 31d and responds to Xiaobo and Riccardo.
Riccardo (NTT DOCOMO) is positive on r31c.
Susana (Vodafone) can live with r31c
Hui (Huawei) thanks Xiaobo and Yang for the compromise proposal and asks whether we can go with r31c.
Jinhua(Xiaomi) agree with Yang, we prefer 8775r31d, Both 8775r31d and 8775r31c are OK for us.
Zhuoyun (Tencent) prefers r31d, can also go with r31c.
Sudeep (Apple) comments on r31c.
Huazhang (vivo) prefers r31d, can also go with r31c to finally solve the EDC issues in this year
Svante (Sony) Thanks for the compromised versions. We accepts the r31c version to be able to move forward.
Yang (OPPO) thanks for people's work and can live with r33.

Status:

Revised to S2-2109347, merging S2-2108865.

TD S2-2109347 (CR) 23.548 CR0030R4 (Rel-17, 'C'): EAS rediscovery: Edge DNS Client based EAS (re-)discovery. (Source: Qualcomm Incorporated, Vodafone, Deutsche Telekom, Telefonica, Verizon, NTT DoCoMo, Telecom Italia, AT&T, Charter, Telstra, KDDI, Matrixx, Convida Wireless, InterDigital, T-Mobile USA, Rogers, Facebook, Orange, Rakuten Mobile, KPN, TNO, Ericsson, China Mobile, Nokia, Nokia Shanghai Bell, Reliance Jio, China Unicom, Huawei, HiSilicon, NEC, Sandvine, Amdocs, SK Telekom, Xiaomi).
Document for: Approval.
Abstract: Summary of change: Added the description of the EDC (Edge DNS Client) functionality that enables the UE to send the DNS query to the EASDF/DNS resolver/DNS server indicated by the MNO.

Comment:

CC#2: Revision of S2-2108775r33, merging S2-2108865. Approved.

Discussion and conclusion:

Qualcomm thanked all companies for their discussions and cooperation for reaching a final compromise on this CR.

Status:

Agreed.

TD S2-2108694 (DISCUSSION) Way forward for criteria to use the EDC functionality. (Source: NTT DOCOMO).
Document for: Agreement.
Abstract: This discussion paper proposes a way forward to address an Editor's Note related to defining the criteria to use the EDC functionality in the UE.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Dario S. Tonesi (Qualcomm) comments
Riccardo (NTT DOCOMO) clarifies this is a DP.
Dario (Qualcomm) thanks Riccardo and withdraws his previous comment.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108865 (CR) 23.548 CR0030R3 (Rel-17, 'C'): EAS rediscovery: Edge DNS Client based EAS (re-)discovery. (Source: NTT DOCOMO).
Document for: Approval.
Abstract: Summary of change: Added the description of the EDC (Edge DNS Client) functionality that enables the UE to send the DNS query to the EASDF/DNS resolver/DNS server indicated by the MNO. Rev 03 - Remove EN 'The detailed criteria for when the EDC functionality is to be used are FFS' and resolve it by adding a statement in 5.X.1 to specify that 'The UE uses the EDC functionality only for the network interfaces realized by PDU sessions for which the SMF indicates to the UE that the provided DNS server configuration is required to be used'. - Include text in 6.2.3.2.2 and 6.2.3.2.3 about the SMF indicating to the UE that the provided DNS server configuration is required to be used. Include NOTE on regulatory requirements.

Comment:

Revision of (Endorsed) S2-2108177 from S2#147E Merged into S2-2109347.

Discussion and conclusion:

-

e-mail discussion:

Hui (Huawei) suggests to consider this paper as merged into S2-2108775.
Riccardo (NTT DOCOMO) is fine to merge this tdoc into S2-2108775.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Merged into S2-2109347.

TD S2-2108776 (DISCUSSION) Considerations on trigger conditions for EDC usage.. (Source: Qualcomm Incorporated).
Document for: Endorsement.
Abstract: This contribution elaborates on the conditions that trigger the usage of the EDC functionality in the UE.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Hui (Huawei) proposes to note this discussion paper.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108777 (CR) 23.548 CR0031R2 (Rel-17, 'F'): UE authorization for 5GC assisted EAS discovery. (Source: Qualcomm Incorporated, Vodafone, Telstra, NTT DoCoMo, Deutsche Telekom, T-Mobile USA, AT&T, Verizon, Orange, Matrixx, Rakuten Mobile, KPN, TNO, China Mobile, Amdocs).
Document for: Approval.
Abstract: Summary of change: Added the description of an authorization step based on UE subscription needed in order to carry out the EAS discovery procedure.

Comment:

Revision of (Endorsed) S2-2108110 from S2#147E. r03 agreed. Revised to S2-2109272.

Discussion and conclusion:

-

e-mail discussion:

Tingfang Tang (Lenovo) provides r01.
Magnus O (Ericsson) comments
Dario (Qualcomm) provides r02 to address Magnus' comments.
Sudeep (Apple) comments on r02.
Magnus O (Ericsson) provides r03
Dario (Qualcomm) is OK with r03
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109272.

TD S2-2109272 (CR) 23.548 CR0031R3 (Rel-17, 'F'): UE authorization for 5GC assisted EAS discovery. (Source: Qualcomm Incorporated, Vodafone, Telstra, NTT DoCoMo, Deutsche Telekom, T-Mobile USA, AT&T, Verizon, Orange, Matrixx, Rakuten Mobile, KPN, TNO, China Mobile, Amdocs).
Document for: Approval.
Abstract: Summary of change: Added the description of an authorization step based on UE subscription needed in order to carry out the EASDF based EAS discovery procedure.

Comment:

Revision of S2-2108777r03. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108547 (CR) 23.548 CR0041 (Rel-17, 'F'): A new UE capability to support EDC. (Source: Vivo).
Document for: Approval.
Abstract: Summary of change: Define a new UE capability to support EDC and MNO DNS service.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Dario S. Tonesi (Qualcomm) comments
Huazhang (vivo) reply to Dario(QC)
Dario (Qualcomm) replies to Huazhang.
Huazhang (vivo) replies to Dario that the content of this paper has been reflected in 8775r13
==== Revisions Deadline ====
Dario (Qualcomm) objects this CR
Huazhang (vivo) merge this CR to S2-2108775 that the UE capability has been written in 8775
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108548 (CR) 23.502 CR3254 (Rel-17, 'F'): A new UE capability to support EDC. (Source: Vivo).
Document for: Approval.
Abstract: Summary of change: Define a new UE capability to support EDC and MNO DNS service.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Dario S. Tonesi (Qualcomm) think that, as for 8547, 8548 is not needed.
Huazhang (vivo) replys to Dario and provide r01
==== Revisions Deadline ====
Dario (Qualcomm) objects to r00 and r01
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108506 (CR) 23.548 CR0037 (Rel-17, 'F'): EAS re-discovery indication and its procedure performed by EDC. (Source: Samsung).
Document for: Approval.
Abstract: Summary of change: It is proposed to clarify the EDC functionality when the UE receives the EAS re-discovery indication.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Dario S. Tonesi (Qualcomm) comments
Jicheol (Samsung) comments
Tingfang Tang (Lenovo) comments.
Susana (Vodafone) agrees with Lenovo and Qualcomm that nothing needs to be added. Proposal to note this document
Dario (Qualcomm) supports to note this paper.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108544 (CR) 23.548 CR0020R1 (Rel-17, 'B'): Provision of DNS server IP address to applications independent of UE OS capability. (Source: Vivo).
Document for: Approval.
Abstract: Summary of change: 5GC provides the MNO DNS configuration to AF via SBI interface or CAPIF architeture. AF communicates with the UE via N6 reference point as defined in TS 23.501, and AF delivers the MNO DNS configuration to applicaton client.

Comment:

Revision of (Postponed) S2-2107537 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

Dario S. Tonesi (Qualcomm) asks questions for clarification.
Huazhang (vivo) response to Dario and provide r01
Magnus H (Ericsson) comments: Not comfortable with cat B CR at this point in time
Huazhang (vivo) clarify the reason to Magnus(Ericsson)
Dario (Qualcomm) asks an additional question
Huazhang (vivo) reply to Dario and provide r02
Changhong (Intel) comments.
Huazhang (vivo) replys to Changhong
Huazhang (vivo) reply to Magnus and provide r03, put the details to Annex, I don't want to put forward such new features
Huazhang (vivo) provides r04
==== Revisions Deadline ====
Dario (Qualcomm): all revisions (including r0) have problems and that he cannot be accepted.
Magnus H (Ericsson) objects to this CR
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108971 (LS OUT) [DRAFT] LS on Defining test cases for E2E verification of Edge Application Server Discovery. (Source: Apple).
Document for: Approval.
Abstract: To: RAN WG5. CC:

Comment:

r00 agreed. Revised to S2-2109255.

Discussion and conclusion:

-

Status:

Revised to S2-2109255.

TD S2-2109255 (LS OUT) Defining test cases for E2E verification of Edge Application Server Discovery. (Source: SA WG2).
Document for: Approval.
Abstract: To: RAN WG5. Attachments: CR 0030 for TS 23.548 in S2-2109347.

Comment:

Revision of S2-2108971r00. Approved.

Discussion and conclusion:

-

Status:

Approved.

## Edge Relocation

TD S2-2108311 (CR) 23.548 CR0035 (Rel-17, 'F'): Corrections on enabling EAS IP Replacement procedure by AF. (Source: China Unicom).
Document for: Approval.
Abstract: Summary of change: Changing the Step4 and Step5 of Figure 6.3.3.1.1-1, i.e. Step4 'AF Influence procedure (SMF reconfigures UL CL and Local PSA) or UE Mobility ' is changed to Step4a 'AF triggering procedure (SMF reconfigures UL CL and Local PSA) ' and Step5 'Early/Late Notification with enhancement described in clause 6.3.3.2.2' is changed to Step4b 'Due to UE Mobolity, Early/Late Notification with enhancement triggered'. Some description is corrected to be consistence with Figure 6.3.3.1.1-1 corrections.

Comment:

r02 agreed. Revised to S2-2109273.

Discussion and conclusion:

-

e-mail discussion:

Changhong (Intel) provides r01 and cosigns.
Shubhranshu (Nokia) comments
Tianqi (China Unicom) provides r02.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109273.

TD S2-2109273 (CR) 23.548 CR0035R1 (Rel-17, 'F'): Corrections on enabling EAS IP Replacement procedure by AF. (Source: China Unicom, Intel).
Document for: Approval.
Abstract: Summary of change: Changing the Step4 and Step5 of Figure 6.3.3.1.1-1, i.e. Step4 'AF Influence procedure (SMF reconfigures UL CL and Local PSA) or UE Mobility ' is changed to Step4a 'AF triggering procedure (SMF reconfigures UL CL and Local PSA) ' and Step5 'Early/Late Notification with enhancement described in clause 6.3.3.2.2' is changed to Step4b 'Due to UE Mobolity, Early/Late Notification with enhancement triggered'. Some description is corrected to be consistence with Figure 6.3.3.1.1-1 corrections.

Comment:

Revision of S2-2108311r02. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108351 (CR) 23.501 CR3363 (Rel-17, 'F'): Additional information/parameter for AF Influence request. (Source: Oracle).
Document for: Approval.
Abstract: Summary of change: In 23.501 5.6.7.1 Add a new attribute to AF Influence request. This attribute will be called 'Reason for the AF Influence request'. Add corresponding description/explanation.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Shubhranshu (Nokia) asks for clarifications
Tingfang Tang (Lenovo) asks questions.
Changhong (Intel) comments.
Magnus H (Ericsson) comments
Hui (Huawei) comments
Tingfang Tang (Lenovo) comments.
==== Revisions Deadline ====
Changhong (Intel) has concern with this paper.
Shubhranshu (Nokia) also has concerns and do not agree to this CR
Changhong (Intel) also proposes to NOTE the CR, we need more time to think about it.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108410 (CR) 23.548 CR0006R1 (Rel-17, 'F'): Correction related to AF request for simultaneous connectivity over source and target PSA at edge relocation. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: Add information in Clause 6.3.4 on how simultaneous connectivity over Source and Target PSA may be provided at Edge relocation when Distributed anchor or Multiple Sessions connectivity models are applied in 5GS.

Comment:

Revision of (Noted) S2-2107240 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

Dario S. Tonesi (Qualcomm) asks question for clarification
Changhong (Intel) comments.
Dan (China Mobile) support Changhong's comments.
Magnus H (Ericsson) provides r01
Susana (Vodafone) asks question for clarification
Hui (Huawei) don't think we need this CR.
Magnus H (Ericsson) comments
Hui (Huawei) provides further comments and proposes to note the paper.
Magnus H (Ericsson) comment and proposes not to note this paper.
Hui (Huawei) replies.
==== Revisions Deadline ====
Magnus H (Ericsson) replies to Hui
Hui (Huawei) replies to Magnus
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108545 (CR) 23.548 CR0040 (Rel-17, 'F'): Added the situation of AF relocation to uplink Packet Buffer. (Source: Vivo, NTT DOCOMO).
Document for: Approval.
Abstract: Summary of change: Add some clarification of AF changes into the procedure of Packet buffering for low packet loss if EAS relocation also implies AF relocation.

Comment:

r03 agreed. Revised to S2-2109274.

Discussion and conclusion:

-

e-mail discussion:

Shubhranshu (Nokia) asks for clarifications
Huazhang (vivo) reply to Shubhranshu and provides r01
Magnus O (Ericsson) comments
Huazhang (vivo) provide r02 and response to Magnus
Shubhranshu (Nokia) provides r03
Huazhang(vivo) reply to Shubhranshu (Nokia) r03 is ok
==== Revisions Deadline ====
Huazhang(vivo) is ok to go ahead with r03
Magnus O (Ericsson) is ok with r03
==== Comments Deadline ====.

Status:

Revised to S2-2109274.

TD S2-2109274 (CR) 23.548 CR0040R1 (Rel-17, 'F'): Added the situation of AF relocation to uplink Packet Buffer. (Source: Vivo, NTT DOCOMO).
Document for: Approval.
Abstract: Summary of change: Add some clarification of AF changes into the procedure of Packet buffering for low packet loss if EAS relocation also implies AF relocation.

Comment:

Revision of S2-2108545r03. Approved.

Discussion and conclusion:

-

Status:

Agreed.

## Local Exposure

TD S2-2108549 (DISCUSSION) Unclear issues in local NEF discovery and way forward. (Source: vivo).
Document for: Information.
Abstract: Unclear issues in local NEF discovery and way forward.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108546 (CR) 23.548 CR0022R1 (Rel-17, 'F'): Local NEF selection. (Source: Vivo).
Document for: Approval.
Abstract: Summary of change: Firstly, when AF request QoS establishment to NEF, AF can add an indication, or define a separate edge event for AF(i.e.: QoS monitoring for edge), the NEF can select a local NEF according to the new AF request or the indication. Secondly, give the procedure of how NEF gathers the parameters for local NEF selection, via BSF or UDM to get UE location. At last, the buffer of local NEF with mapping table of UE location, AF location and etc are added, to reduce the long procedure of local NEF discovery.

Comment:

Revision of (Noted) S2-2107539 from S2#147E. Merged into S2-2109348.

Discussion and conclusion:

-

e-mail discussion:

Haiyang (Huawei) suggests to use S2-2108675 as baseline (i.e. mark this paper merged into 8675 or noted)
Laurent (Nokia): suggests to take this paper 8546 as the baseline
Laurent (Nokia): provides r01
Magnus H (Ericsson) provides r02
Haiyang (Huawei) suggests to note this CR (all revisions)
Huazhang (vivo) replys to Haiyang, and could you please clarify the technique reason of why you don't like the procedure
Yang (OPPO) consider the procedure is needed
Haiyang (Huawei) replies to Yang (OPPO)
Laurent (Nokia): answers
==== Revisions Deadline ====
Huazhang (vivo) merge this paper to 8675, due to we will go ahead on 8675 of local NEF selection
==== Comments Deadline ====.

Status:

Merged into S2-2109348.

TD S2-2108675 (CR) 23.548 CR0042 (Rel-17, 'F'): Local NEF selection. (Source: China Mobile).
Document for: Approval.
Abstract: Summary of change: Clarify how the NEF can discover a local NEF if the AF request for local QoS monitoring exposure.

Comment:

CC#2: r09 + changes agreed. Revised to S2-2109348, merging S2-2108546 and S2-2108858.

Discussion and conclusion:

CC#2: S2-2108675r09 with changes was proposed by China Mobile. This was agreed and was revised in S2-2109348.

e-mail discussion:

Haiyang (Huawei) provides r01.
Laurent (Nokia): Comments and suggests to take either 8546 or 8858 as baseline for this topic
Huazhang (vivo): Comments and suggests to take either 8546 or 8858 as baseline for this topic
Dan (China Mobile)response
Laurent (Nokia): answers, proposes to merge in this paper into 8546 (not mine)
Dan(China Mobile)provide r02
Magnus H (Ericsson) provides r03
Haiyang (Huawei) can only accept r01.
Huazhang (vivo) replys and provide r04 based on r03, move some of the content in 8546 into r04. Also, provides the unsolved things in local NEF selection, which we can't avoid and don't solve.
Dan (China Mobile) provide r05 based on r01
Huazhang (vivo) provide r06 based on r05
Haiyang (Huawei) provides r07 based on r06
Huazhang (vivo) provides r08 based on r07
Laurent (Nokia): answers with concerns
Haiyang (Huawei) provides r09
Laurent (Nokia): provides r11 and r12
Haiyang (Huawei) comments
Dan(China Mobile) provide r13 based on r11 with changing internal/external to trust/untrust.
Haiyang (Huawei) comments if it is trusted AF, there is no need for NEF at all based on current specs
Laurent (Nokia): provides r14
Dan(China Mobile) provide r14 to reflect Haiyang's comment
Dan(China Mobile) provide r15 to reflect Haiyang's comment
Dan(China Mobile) provide r16 based on R14 laurent provide with some correction for AF
Haiyang (Huawei) comments that even if the AF cannot provide DNAI, the NEF could get it based on local configuration.
Dan (China Mobile) ask,
Huazhang(vivo) provide r17 based on R16 as compromise
Haiyang(Huawei) replies to Dan(China Mobile)
==== Revisions Deadline ====
Haiyang(Huawei) can only accept r01, r07 or r09, and objects to all other versions.
Huazhang (vivo) propose we go with r09 because this topic has been discussed so long and no results, firstly we can reach some agreements in some area.
Dan (China Mobile) OK we go with r09
Laurent (Nokia): objects to R00, R01, R03, R04, R05, R06, R07, R08, R09, R15
Magnus H (Ericsson) prefers r09 over the non objected revisions (r01 and r07).
Dan (China Mobile) check all the versions, I would like to let people to check whether r14 is OK , we can accept r14
Dan (China Mobile) take it back the previous email, and suggest people to check r11.
Huazhang (vivo) can accept r14
Magnus H (Ericsson) cannot accept r14, if we are not going with r09, r03 is proposed.
Dan (China Mobile) would like to clarify something and suggest to endorse r09
Laurent (Nokia): We need to discuss this at CC2
Dan(China Mobile): agree that we should work together and in CC#2, with a suitable NOTE adding, maybe we can get consensus.
==== Comments Deadline ====
Huazhang (vivo): provides r18 based on r09 to move forward for the trigger of local NEF selection and AF request redirect. I delete all of the controversal parts to move ahead.
Dan (China Mobile) suggest we can move forward based on Huazhang r18.

Status:

Revised to S2-2109348, merging S2-2108546 and S2-2108858.

TD S2-2109348 (CR) 23.548 CR0042R1 (Rel-17, 'F'): Local NEF selection. (Source: China Mobile).
Document for: Approval.
Abstract: Summary of change: Clarify how the NEF can discover a local NEF if the AF request for local QoS monitoring exposure.

Comment:

CC#2: Revision of S2-2108675r09 + changes, merging S2-2108546 and S2-2108858. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108858 (CR) 23.548 CR0025R1 (Rel-17, 'F'): Procedure for local NEF selection. (Source: Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: Overall procedural description of local NEF selection is provided in this CR: Figure 6.4.2.2 describes how an initially selected NEF may redirect the AF to a suitable local NEF. A companion CR to 23.502 updates services:

Comment:

Revision of (Noted) S2-2107646 from S2#147E. Merged into S2-2109348.

Discussion and conclusion:

-

e-mail discussion:

Haiyang (Huawei) suggests to use S2-2108675 as baseline (i.e. mark this paper merged into 8675 or noted)
Laurent (Nokia): Suggests to take 8546 (not mine) as a baseline so merges 8858 into 8546
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Merged into S2-2109348.

TD S2-2108859 (CR) 23.502 CR3204R1 (Rel-17, 'F'): Procedure for local NEF selection. (Source: Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: Overall procedural description of local NEF selection is provided in a CR to 23.548. This CR to 23.502 updates services to match the 23.548 CR: it Adds SMF instance ID as output of Nbsf_Management_Discovery, and as input of Nbsf_Management_Register.

Comment:

Revision of (Noted) S2-2107647 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

Haiyang (Huawei) suggests to note this paper.
Magnus H (Ericsson) comments
Laurent (Nokia): answers
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

## Service specific information provisioning

TD S2-2108503 (CR) 23.502 CR3155R2 (Rel-17, 'B'): Correction of UE Policies delivery notification. (Source: Samsung).
Document for: Approval.
Abstract: Summary of change: It is proposed to clarify the outcome of the UE Policies delivery and when it is reported in particularily when the PCF is notified about the failure notification from the AMF. It is also proposed to clarify the existing UE policy delivery procedure to clarify that the PCF can re-try the procedure when the UE becomes CONNECTED.

Comment:

Revision of (Agreed) S2-2108113 from S2#147E. r01 agreed. Revised to S2-2109275, merging S2-2108976.

Discussion and conclusion:

-

e-mail discussion:

Shubhranshu (Nokia) provides r01
Jicheol (Samsng) provide r02. Jicheol (Samsung) is okay with both r01 and r02.
Shubhranshu (Nokia) is NOT ok to r02 and r00
==== Revisions Deadline ====
Hui(Huawei) fine with r01
==== Comments Deadline ====.

Status:

Revised to S2-2109275, merging S2-2108976.

TD S2-2109275 (CR) 23.502 CR3155R4 (Rel-17, 'B'): Correction of UE Policies delivery notification. (Source: Samsung, Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: It is proposed to clarify the outcome of the UE Policies delivery and when it is reported in particularily when the PCF is notified about the failure notification from the AMF. It is also proposed to clarify the existing UE policy delivery procedure to clarify that the PCF can re-try the procedure when the UE becomes CONNECTED. Also, it is clarified that the proposed reporting is for cases where the AF request targets a single UE.

Comment:

Revision of S2-2108503r01, merging S2-2108976. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108976 (CR) 23.502 CR3155R3 (Rel-17, 'B'): Correction of UE Policies delivery notification. (Source: Nokia, Nokia Shanghai Bell, [Samsung?]).
Document for: Approval.
Abstract: Summary of change: It is proposed to clarify the outcome of the UE Policies delivery and when it is reported in particularily when the PCF is notified about the failure notification from the AMF. It is also proposed to clarify the existing UE policy delivery procedure to clarify that the PCF can re-try the procedure when the UE becomes CONNECTED. Also, it is clarified that the proposed reporting is for cases where the AF request targets a single UE.

Comment:

Revision of (Agreed) S2-2108113 from S2#147E. Confirm Sources! Merged into S2-2109275.

Discussion and conclusion:

-

e-mail discussion:

Jicheol (Samsung) asks a question for clarification
Jicheol (Samsung) also suggests to merge (or discuss) this CR in S2-2108503 since the proposal is conflicted.
Shubhranshu (Nokia) responds
Shubhranshu (Nokia) is ok to merge this paper into S2-2108503
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Merged into S2-2109275.

## DNAI-based (I-)SMF selection

TD S2-2108717 (CR) 23.502 CR3277 (Rel-17, 'F'): I-SMF removal triggered by removal of target DNAI. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: To support I-SMF removal triggered by removal of DNAI in the PCC rules: SMF decides no target DNAI should be used based on received PCC rule(s) from PCF. SMF sends target DNAI information without including target DNAI to AMF. If the AMF receive target DNAI information without including target DNAI, the AMF may remove the existing I-SMF.

Comment:

CC#2: r04 + changes agreed. Revised to S2-2109276.

Discussion and conclusion:

CC#2: S2-2108717r04 with modifications was proposed by Huawei. This was agreed and the revision in S2-2109276.

e-mail discussion:

Tingfang Tang (Lenovo) provides r01.
Shubhranshu (Nokia) comments and asks for clarifications
Hui (Huawei) replies and prefers to r00.
Tingfang Tang (Lenovo) comments.
Yuan Tao (CATT) comments.
Yuan Tao responds to Tingfang Tang (Lenovo).
Hui(Huawei) supports Yuan's view.
Tingfang Tang (Lenovo) replies and can accept the original version.
Magnus O (Ericsson) comments
Hui (Huawei) provides r02
Shubhranshu (Nokia) provides r03
Hui (Huawei) provides r04
Shubhranshu (Nokia) asks for clarification
==== Revisions Deadline ====
Hui (Huawei) replies.
Yuan Tao (CATT) replies to Hui (Huawei).
Yuan Tao (CATT) replies.
Hui (Huawei) provides r05 and asks for discussing on CC#2.
==== Comments Deadline ====.

Status:

Revised to S2-2109276.

TD S2-2109276 (CR) 23.502 CR3277R1 (Rel-17, 'F'): I-SMF removal triggered by removal of target DNAI. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: To support I-SMF removal triggered by removal of DNAI in the PCC rules: SMF decides no target DNAI should be used based on received PCC rule(s) from PCF. SMF sends target DNAI information without including target DNAI to AMF. If the AMF receive target DNAI information without including target DNAI, the AMF may remove the existing I-SMF.

Comment:

CC#2: Revision of S2-2108717r04 + changes. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108718 (CR) 23.501 CR3418 (Rel-17, 'F'): I-SMF removal triggered by removal of target DNAI. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Add descriptions that SMF decides no target DNAI should be used and sends AMF a target DNAI information without including target DNAI.

Comment:

r03 agreed. Revised to S2-2109277.

Discussion and conclusion:

-

e-mail discussion:

Tingfang Tang (Lenovo) provides r01.
Shubhranshu (Nokia) comments
Hui (Huawei) still prefers to r00 and replies.
Tingfang Tang (Lenovo) replies and can accept the original version.
Magnus O (Ericsson) comments
Hui (Huawei) replies to Magnus O (Ericsson)
Shubhranshu (Nokia) provides r02
Hui (Huawei) fine with r02
Magnus O (Ericsson) comments again
Hui (Huawei) provides r03
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109277.

TD S2-2109277 (CR) 23.501 CR3418R1 (Rel-17, 'F'): I-SMF removal triggered by removal of target DNAI. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Add descriptions that SMF decides no target DNAI should be used and sends AMF a target DNAI information without including target DNAI.

Comment:

Revision of S2-2108718r03. Approved.

Discussion and conclusion:

-

Status:

Agreed.

## ECS provisioning

TD S2-2108778 (CR) 23.502 CR3212R2 (Rel-17, 'F'): Correction of ECS Address Configuration Information. (Source: Qualcomm Incorporated, Nokia, Nokia Shanghai Bell, Ericsson).
Document for: Approval.
Abstract: Summary of change: Removed '- a Presence Reporting Area' from Table 4.15.6.3d-1. Removed the second sentence in the description cell of Table 4.15.6.3d-2 Rev.1 Removed the second paragraph in clause 4.15.6.3d because inconsistent with the table defintion. Rev.2 Clarified that the Spatial Validity Condition can apply to the multiple servers indicated in the ECS Address Configuration Information. In Spatial Validity Condition, replaces geographical area with Geographical Service Area (define in TS 23.558).

Comment:

Revision of (Agreed) S2-2108120 from S2#147E. Approved.

Discussion and conclusion:

-

Status:

Agreed.

# 8.4 Enhancement of Network Slicing Phase 2 (eNS_Ph2)

This agenda item was convened by Tao Sun (China Mobile).

## LS in/LS out

TD S2-2108286 (LS IN) LS from CT WG4: Reply LS on back-off timer handling when NSSAA is not completed. (Source: CT WG4 (C4-215491)).
Document for: Information.
Abstract: CT WG4 would like to thank CT WG1 for the LS C1-214887. Regarding to the quoted text below from TS29.526, CT WG4 agrees with CT WG1's opinion that the quoted AMF behaviour (i.e. the AMF may set a back-off timer to prevent UE from sending REGISTRATION REQUEST message) is NAS procedure related and shall be under CT WG1 responsibility. {. . .}.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Jinguo(ZTE) suggest to note this LS since it is for information
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108789 (DISCUSSION) Discussion on NSAC for Network Slice Subject to NSSAA.. (Source: Xiaomi).
Document for: Agreement.
Abstract: Proposed correction of NSAC for Network Slice Subject to NSSAA.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Alessio (Nokia) proposes to note this paper with no specific agreement reached other than the current text in the TS is enough
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108335 (LS OUT) [DRAFT] LS on order of NSSAA and NSAC procedure. (Source: Ericsson).
Document for: Approval.
Abstract: Replying to SA WG3 question on the order of NSSAA and NSAC that was not answered in previous reply.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Iskren (NEC) - the answer in the LS is in conflict with the SA2 spec.
Peter Hedman (Ericsson) provides reply
George (Ericsson) provides a comment to Iskren. The yellow text does not mandate whether NSAC is done before NSSAA or after. In this case, there is UCU and as such the yellow text does not apply; there is no Registration response with an Allowed S-NSSAI; where the highlighted yellow text applies . So U extending the interpretation. If what U are saying is true then we would not have received an LS asking clarification.
Iskren (NEC) answers George
George (Ericsson) comment. The yellow text does not cover the NSSAA. That's all I said. Otherwise why are CT groups seeking clarification.
Iskren (NEC) answers George.
George (Ericsson) comments. We agree to disagree.
Alessio(Nokia) provides r01
George (Ericsson) comments. This LS is the right approach and we should stop this discussion. It is going nowhere.
Jinhua(Xiaomi) comments. 8335r01 is OK for me, and we can revise the state in 502 e.g.'the AMF can be configured to trigger NSSAA before or after NSAC, when EAC active' , same as Peter's proposal.
Iskren (NEC) - the original and r01 are not acceptable as they do not interpret correctly the order between the NSAC and NSSAA defined in the SA2 spec.
==== Revisions Deadline ====
Jinhua replies to Iskren, propose to state the order can be decided by AMF as the operator decision
Peter Hedman (Ericsson) provides question why r00 is not acceptable by NEC, while we are fine with r01 as well as main purpose is to ask whether SA3 has any concerns as such
Iskren (NEC) answers Peter Hedman (Ericsson)
Tao(VC) then let's try to agree r00 with the condition 8886 r06 approved.
George (Ericsson) comments . R06 can only be Ok with the changes Peter requested. That was clear
alessio(nokia) can only agree r01 as the spec clearly says that NSAC does not happen till after UE configuration update when EAC is not active.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108786 (CR) 23.502 CR3178R1 (Rel-17, 'F'): TS23.502 Correction of NSAC for network slice subject to NSSAA. (Source: NEC(?), Ericsson(?), Xiaomi).
Document for: Approval.
Abstract: Summary of change: Clarified the order of the NSAC when NSSAA is applied for the S-NSSAI It is proposed to add the following description in clause 4.2.11.2 of the TS23.502: 'If the UE requested a registration for a network slice subject to NSAC which is also subject to NSSAA, the AMF does not trigger the Number of UEs per network slice availability check and update procedure with the NSACF before or after the Registration Accept message but the AMF interacts with the NSACF before or after the UE Configuration Update message of the NSSAA procedure as stated above.'.

Comment:

Revision of (Postponed) S2-2107427 from S2#147E. Confirm Sources! Noted.

Discussion and conclusion:

-

e-mail discussion:

Peter (Ericsson) provides comments and r01
Iskren (NEC) - this CR shall be considered as merged to S2-2108886
Fenqin (Huawei) ask a question for clarification
Ashok (Samsung) comments
Jinhua (Xiaomi) proposes to merge 8786 into 8886 for further discussion.
Jinhua(Xiaomi) replies to Ashok Fenqin and Peter,
Fenqin (Huawei) responds
alessio(nokia) requests to note this CR.
Jinhua(Xiaomi) replies to Alessio, 8786 was merged into 8886 for further discussion.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108886 (CR) 23.502 CR3178R2 (Rel-17, 'F'): TS23.502 Correction of NSAC for network slice subject to NSSAA. (Source: NEC, Huawei, NTT DOCOMO).
Document for: Approval.
Abstract: Summary of change: It is proposed to add the following description in clause 4.2.11.2 of the TS23.502: 'If the UE requested a registration for a network slice subject to NSAC which is also subject to NSSAA, depending on the EAC mode the AMF interacts with the NSACF before or after the UE Configuration Update message of the NSSAA procedure rather than before or after the Registration Accept '.

Comment:

Revision of (Postponed) S2-2107427 from S2#147E. Confirm CR Revision - CR states 1! Noted.

Discussion and conclusion:

-

e-mail discussion:

Stefano (Qualcomm) provides r01
Jinhua (Xiaomi) provides comments, and proposes to merge 8786 into 8886 for further discussion.
Peter (Ericsson) provides comments
George (Ericsson) Just one additional comment. If the NSAC is done after UE configuration update and the slice was congested, then AMF would have to undo everything and we would have wasted radio resources.
Iskren (NEC) answers question from George (Ericsson)
Iskren (NEC) provides r02
George (Ericsson) comments.
George (Ericsson) comments. We are not OK with r02.
Jinhua (Xiaomi) provides r03.
George (Ericsson) comments. This can't be a note. The note itself contradicts the normative text. So this is NOT OK either.
Jinhua(Xiaomi) replies to George.
Srisakul (NTT DOCOMO) asks question for clarification to George (Ericsson) and Jinhua (Xiaomi).
George (Ericsson) respond. We would have it done after NSAC regardless, or leave it as implementation not an operator policy. This will work either way, and has no interworking impact.
Fenqin (Huawei) comments.
Jinhua(Xiaomi) respond to Srisakul for clarification.
Peter Hedman (Ericsson) provides comment and a proposal
Jinhua(Xiaomi) replies to Peter,
Alessio(Nokia) proposes to note this CR
Iskren (NEC) provides r04
Srisakul (NTT DOCOMO) comments.
==== Revisions Deadline ====
Iskren (NEC) can agree with r02 or r06
Peter Hedman (Ericsson) proposes to Approve r06 with additional changes i.e. removing the normative paragraph and change 'may' to 'can' in the added note.
Iskren (NEC) answers Peter Hedman (Ericsson) and proposes to Approve r06
Alessio(nokia) proposes to note this CR as it is not providing any improvement and as noted by Peter it is quite confusing
Jinhua(Xiaomi) proposes to approve r02/r06 for progress.
==== Comments Deadline ====
Peter Hedman (Ericsson) provides reply that approving only text in the note as normative text is ok.

Status:

Noted.

TD S2-2108287 (LS IN) LS from CT WG4: LS on Parameter adding in UEContext to support NSSRG feature. (Source: CT WG4 (C4-215492)).
Document for: Action.
Abstract: SA WG2 has agreed on CRs(S2-2106861) to update the UEContext in AMF to add the indication from UDM subscription data, i.e. provide the UE with the full set of subscribed S-NSSAIs. As per CT WG4 analysis and discussion: - Each AMF will download this data from UDM. - This UDM indication is not useful at the time of context transfer. Therefore, this UDM indication need not be required in the UEContext. CT WG4 kindly asks SA WG2 to clarify the use case of including this UDM indication in UEContext and whether UEContext needs to be updated to remove this UDM indication. More generally, can SA WG2 confirm whether Table 5.2.2.2.2-1 (UE Context in AMF) in clause 5.2.2.2.2 of TS 23.502 is meant to only specify the UE context parameters that shall be transferred to a target AMF during inter-AMF mobility, or if the table also includes parameters that may not be required to be transferred during inter-AMF mobility; if this was the latter case, could the table be extended to identify the parameters that shall be transferred to a target AMF. Action: CT WG4 kindly asks SA WG2 to take CT WG4 consideration into account and respond to the above questions.

Comment:

Responses drafted in S2-2108643, S2-2108759 and S2-2108894. Final response in S2-2109142.

Discussion and conclusion:

-

Status:

Replied to.

TD S2-2108643 (LS OUT) [DRAFT] LS Reply on Parameter adding in UEContext to support NSSRG feature. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: This contribution replies the LS (Parameter adding in UEContext to support NSSRG feature).

Comment:

Response to S2-2108287. r03 agreed. Revised to S2-2109142, merging S2-2108759 and S2-2108894.

Discussion and conclusion:

-

e-mail discussion:

Yunjing (CATT) proposes to merge this draft LS into S2-2108759.
Haiyang (Huawei) is OK to merge and discuss it in the 8759 thread.
Ashok (Samsung) comments
Peter (Ericsson) provides comments and r01
Haiyang (Huawei) is OK with r01
Ashok (Samsung) is fine with r01
alessio (nokia) provides r02 to restrict the question to rel-17 parameters only
Jinhua (Xiaomi) provides comments and r03
Haiyang (Huawei) prefers r01
==== Revisions Deadline ====
Peter Hedman (Ericsson) prefer r01, but can live with r03 as well.
alessio (Nokia) can accept r02 and r03.
==== Comments Deadline ====.

Status:

Revised to S2-2109142, merging S2-2108759 and S2-2108894.

TD S2-2109142 (LS OUT) LS Reply on Parameter adding in UEContext to support NSSRG feature. (Source: SA WG2).
Document for: Approval.
Abstract: To: CT WG4.

Comment:

Revision of S2-2108643r03, merging S2-2108759 and S2-2108894. Approved.

Discussion and conclusion:

-

Status:

Approved.

TD S2-2108759 (LS OUT) [DRAFT] Response LS on parameter adding in UEContext to support NSSRG feature. (Source: CATT).
Document for: Approval.
Abstract: Reply to S2-2108287.

Comment:

Response to S2-2108287. Merged into S2-2109142.

Discussion and conclusion:

-

e-mail discussion:

Peter (Ericsson) provides comments and suggest to mark as merged into S2-2108643
Yunjing (CATT) is fine to merge this paper into S2-2108643
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Merged into S2-2109142.

TD S2-2108894 (LS OUT) [DRAFT] Reply LS on Parameter adding in UEContext to support NSSRG feature. (Source: China Mobile ).
Document for: Approval.
Abstract: LS reply to CT WG4 about Parameter adding in UEContext to support NSSRG feature.

Comment:

Response to S2-2108287. Merged into S2-2109142.

Discussion and conclusion:

-

e-mail discussion:

Yunjing (CATT) proposes to merge this draft LS into S2-2108759.
Dan (China Mobile) is OK for merging this paper into S2-2108759.
Peter (Ericsson) provides comments and suggest to mark it merged into S2-2108643
==== Revisions Deadline ====
Dan(China Mobile) OK to mark it merged into S2-2108643
==== Comments Deadline ====.

Status:

Merged into S2-2109142.

TD S2-2108758 (CR) 23.502 CR3285 (Rel-17, 'F'): Update UE context transferred between AMFs. (Source: CATT).
Document for: Approval.
Abstract: Summary of change: Remove the'provide the UE with the full set of subscribed S-NSSAIs' indication from UE context and add a note to avoid adding UE subscription data into UE context.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Peter (Ericsson) provides comments and propose to mark it as merged into S2-2108895.
Yunjing (CATT) is fine to merge this CR into S2-2108895.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108895 (CR) 23.502 CR3304 (Rel-17, 'F'): Correct the UDM indication and RFSP index in UE Context in AMF table. (Source: China Mobile).
Document for: Approval.
Abstract: Summary of change: Remove the UDM indicaiton of 'Provide the UE with the full set of subscribed S-NSSAIs' and 'Subscribed RFSP index'from the UE Context in AMF table and add it in UE subscription table.Remove 'Subscribed RFSP index'from the UE Context in AMF table.

Comment:

r01 agreed. Revised to S2-2109143.

Discussion and conclusion:

-

e-mail discussion:

Yunjing (CATT) proposes to merge this CR into S2-2108758.
Peter (Ericsson) provides comments and r01
Dan (China Mobile) provides r02
Alessio(Nokia) is ok with r02
==== Revisions Deadline ====
Dan(China Mobile) is ok with r02
Haiyang (Huawei) prefers r01, objects r02
Ashok (Samsung) agrees with Haiyang (Huawei) and prefers r01, objects r02
Dan (China Mobile) OK with r01, and r02, but give a suggestion.
Peter Hedman (Ericsson) ok with any of r01 and r02.
alessio(Nokia) prefers r02. can live with r01
==== Comments Deadline ====.

Status:

Revised to S2-2109143.

TD S2-2109143 (CR) 23.502 CR3304R1 (Rel-17, 'F'): Correct the UDM indication and RFSP index in UE Context in AMF table. (Source: China Mobile, Ericsson).
Document for: Approval.
Abstract: Summary of change: Remove the UDM indication of 'Provide the UE with the full set of subscribed S-NSSAIs' from the UE Context in AMF table and add it in UE subscription table.

Comment:

Revision of S2-2108895r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108262 (LS IN) LS from CT WG1: LS on rejected NSSAI for the maximum number of UE reached when TAIs belonging to different PLMNs. (Source: CT WG1 (C1-214895)).
Document for: Action.
Abstract: CT WG1 is discussing the UE handling on the received rejected NSSAI for the maximum number of UEs reached when the registration area contains TAIs belonging to different PLMNs. There are two options observed: Option 1: the rejected NSSAI for the maximum number of UEs reached is applicable to all of these PLMNs in the registration area; Option 2: the rejected NSSAI for the maximum number of UEs reached is applicable to the registered PLMN only. Action: CT WG1 would like to ask SA WG2 which option (Option 1 or Option 2) is recommended.

Comment:

Revision of S2-2107020 from S2#147E. Responses drafted in S2-2108607, S2-2108762, S2-2108806 and S2-2108958. Final response in S2-2109364.

Discussion and conclusion:

-

Status:

Replied to.

TD S2-2108763 (DISCUSSION) Discussion on rejected NSSAI for the maximum number of UE reached when TAIs belonging to different PLMNs.. (Source: Huawei, HiSilicon).
Document for: Agreement.
Abstract: This discussion paper aims at discussing the scenario mentioned by the CT WG1 LS and proposes the way forward.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108607 (LS OUT) [DRAFT] LS Reply on rejected NSSAI for the maximum number of UE reached when TAIs belonging to different PLMNs. (Source: ZTE).
Document for: Approval.
Abstract: LS on rejected NSSAI for the maximum number of UE reached when TAIs belonging to different PLMNs.

Comment:

Response to S2-2108262. Noted.

Discussion and conclusion:

-

e-mail discussion:

Haiyang (Huawei) provides comments.
alessio(Nokia) proposes to note this LS as it is mandating a behavior in the CN that is not something that should happen by default.
Jinguo(ZTE) provides r01.
alessio (nokia) repeats we need to take a holistic decision for all the features and not one that works for NSAC and not for others..hence we proposed a generic CR and LS response.
Jinguo(ZTE) replies no agreement that this is a generic issue for other cause value in both SA2 and CT1.
alessio(Nokia) also believes the way this is worded is wrong. objects to this LS text.
Jinguo(ZTE) provides r02
==== Revisions Deadline ====
Stefano (Qualcomm) does not see how we can agree R02.
Tao(VC) check the way forward of the LS OUT, whether 8806 can be approved
Jinguo(ZTE) suggest to go with 8607r02
Haiyang (Huawei) suggests to postpone this LS as discussed in 8608 thread.(i.e. objects to r00, r01 and r02)
alessio(nokia) objects to r00, r01 and r02
Stefano (Qualcomm) thanks Jinguo for the effort but clearly 8607 (and the related CR) cannot be agreed any more than 8806 and the related CR.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108762 (LS OUT) [DRAFT] LS Reply on rejected NSSAI for the maximum number of UE reached when TAIs belonging to different PLMNs. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: This LS is to reply the LS on rejected NSSAI for the maximum number of UE reached when TAIs belonging to different PLMNs.

Comment:

Response to S2-2108262. Noted.

Discussion and conclusion:

-

e-mail discussion:

Peter (Ericsson) provides comments and question the proposed way forward proposed.
Haiyang (Huawei) replies to Peter (Ericsson).
Stefano (Qualcomm) expresses concerns about underlying assumptions.
Haiyang (Huawei) explains the original assumption should be the Allowed NSSAI should be valid in the whole RA.
Peter Hedman (Ericsson) provides comments and still have issues with the LS proposal.
Haiyang (Huawei) seeks clarification from Peter Hedman (Ericsson).
Alessio(Nokia) suggest we use the Nokia LS and CR approach as the discussion has generic validity. We do not want to have a behaviour that is specific for each feature.
==== Revisions Deadline ====
Haiyang (Huawei) suggests to go with the original version.
Jinguo(ZTE) suggest to merge this LS into 8607 <file:///E:/03%20%E6%A0%87%E5%87%86%E4%BC%9A%E8%AE%AE/3GPP%20SA2/2021/SA2%23148E/Docs/S2-2108607.zip>
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108806 (LS OUT) [DRAFT] LS Reply on rejected NSSAI for the maximum number of UE reached when TAIs belonging to different PLMNs. (Source: Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: -

Comment:

Response to S2-2108262. CC#2: This was left for review at CC#3. CC#3: r02 agreed. Revised to S2-2109364.

Discussion and conclusion:

CC#2: Nokia suggested that this LS is reconsidered with the modification to the action in r01. This was left for review at CC#3.
CC#3: Nokia provided S2-2108806r02. S2-2108806r02 was agreed and revised in S2-2109364.

e-mail discussion:

Jinguo(ZTE) suggests merge 8806 into 8607
Peter Hedman (Ericsson) propose to mark the LS as noted
alessio(Nokia) can only accepted the text in the formally agreed LS OUT ( without referring to the CR, we can remove the CR reference if the text in there is agreable). if despite this was approved people object to it, we put on hold any LS on this.
Alessio(nokia) comments that this LS was not receiving any comment so it is agreed per process technically. we can remove any reference to the CR but the technical content seems not challenged. I can work on an update text removing the CR reference and focus on the feedback in bullets 1 AND 2.
Jinguo(ZTE) asks discussion at CC#2
==== Comments Deadline ====
Alessio( Nokia) provides a modified text that keeps the 'agreed' concepts but removes reference to a CR. add the text as proposed by peter. Asks Jinguo(ZTE) and TAO to insist in obtaining discussion at CC#2.

Status:

Revised to S2-2109364.

TD S2-2109364 (LS OUT) LS Reply on rejected NSSAI for the maximum number of UE reached when TAIs belonging to different PLMNs. (Source: SA WG2).
Document for: Approval.
Abstract: To: CT WG1.

Comment:

Revision of S2-2108806r02. Approved.

Discussion and conclusion:

-

Status:

Approved.

TD S2-2108958 (LS OUT) [DRAFT] LS Reply on rejected NSSAI for the maximum number of UE reached when TAIs belonging to different PLMNs. (Source: QUALCOMM Europe Inc. - Italy).
Document for: Approval.
Abstract: To: CT WG1. CC:

Comment:

Response to S2-2108262. Noted.

Discussion and conclusion:

-

e-mail discussion:

Haiyang (Huawei) suggests to note this paper.
Peter Hedman (Ericsson) provides reply.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108334 (CR) 23.502 CR3129R1 (Rel-17, 'F'): Rejected NSSAI for NSAC. (Source: Ericsson, Qualcomm).
Document for: Approval.
Abstract: Summary of change: The NSAC for the registered PLMN is selected and rejected S-NSSAIs are rejected for the registered PLMN.

Comment:

Revision of (unhandled) S2-2107120 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

Haiyang (Huawei) suggests to note this paper.
Alessio(Nokia) also proposes to note this CR
Peter Hedman (Ericsson) provides reply
Alessio(Nokia) replies
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108608 (CR) 23.502 CR3261 (Rel-17, 'F'): Clarification on Equivalent PLMN for NSAC. (Source: ZTE).
Document for: Approval.
Abstract: Summary of change: If the Registration Area contains TAIs belonging to different PLMNs, which are equivalent PLMNs, the AMF invokes the Number of UEs per network slice availability check and update procedure for each S-NSSAI in Allowed NSSAI in each equivalent PLMN. If the S-NSSAIs in some equivalent PLMNs reached the maximum number of UEs per S-NSSAI, the AMF should not include this S-NSSAI in the Allowed NSSAI. Add following NOTE: NOTE x: The rejected S-NSSAI with cause 'maximum number of UEs per network slice reached' is only applicable for the serving PLMN.

Comment:

Postponed.

Discussion and conclusion:

-

e-mail discussion:

Peter (Ericsson) provides comments
Haiyang (Huawei) provides comments.
Jinguo(ZTE) provides response and asks question
Jinguo(ZTE) provides r01
Peter Hedman (Ericsson) provides comments
Jinguo (ZTE) response
alessio(Nokia) objects to this CR
Jinguo(ZTE) reply that the objection has no basis.
Peter Hedman (Ericsson) provides comments and concerns on applying NSAC on each ePLMN as well as assuming there is some common NSAC quota
Jinguo(ZTE) response
Jinguo(ZTE) provides r02
Haiyang (Huawei) comments on r01
==== Revisions Deadline ====
Jinguo(ZTE) replies to Haiyang.
Haiyang(Huawei) questions to Jinguo(ZTE).
Haiyang(Huawei) comments.
Jinguo(ZTE) response.
Haiyang(Huawei)also suggests to postpone this CR.
==== Comments Deadline ====.

Status:

Postponed.

## General

TD S2-2108605 (CR) 23.501 CR3401 (Rel-17, 'F'): Clarification on Multiple NSACFs for S-NSSAI. (Source: ZTE, NTT DOCOMO, Lenovo, Motorola Mobility).
Document for: Approval.
Abstract: Summary of change: Clarify that the maximum value configued in the each NSACF is only for the service area of the NSACF, i.e. not the maximum value of the whole network slice. When multiple NSACFs are deployed how the maximum number of UEs per networ slice and the maximum number of PDU Sessions per network slice is distributed among multiple NSACFs is implementation specific.

Comment:

r04 agreed. Revised to S2-2109144.

Discussion and conclusion:

-

e-mail discussion:

Genadi (Lenovo) provides r01 to merge some changes from S2-2108922.
Jinguo (ZTE) provides r02
George (Ericsson) comments
Jinguo(ZTE) provides r03
Genadi (Lenovo) is fine with r03.
Jinhua (Xiaomi) provides r04.
==== Revisions Deadline ====
Srisakul (NTT DOCOMO) ok with r04.
Jinguo (ZTE) ok with r04.
George (Ericsson) OK with r04
==== Comments Deadline ====.

Status:

Revised to S2-2109144.

TD S2-2109144 (CR) 23.501 CR3401R1 (Rel-17, 'F'): Clarification on Multiple NSACFs for S-NSSAI. (Source: ZTE, NTT DOCOMO, Lenovo, Motorola Mobility).
Document for: Approval.
Abstract: Summary of change: Clarify that the maximum value configued in the each NSACF is only for the service area of the NSACF, i.e. not the maximum value of the whole network slice. When multiple NSACFs are deployed how the maximum number of UEs per networ slice and the maximum number of PDU Sessions per network slice is distributed among multiple NSACFs is implementation specific.

Comment:

Revision of S2-2108605r04. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108921 (CR) 23.502 CR3309 (Rel-17, 'F'): Clarification on the NSACF result parameter sent to AMF. (Source: Lenovo, Motorola Mobility).
Document for: Approval.
Abstract: Summary of change: It is proposed that the NSACF returns a result indication to the AMF. The result indication contains one of: - 'maximum number of UEs registered with the network slice not reached'; or - 'maximum number of UEs registered with the network slice reached'. In addition, the 'availability status' parameter is moved from the 'Outputs, Required' to 'Outputs, Optional' description of the Nnsacf_NSAC_NumOfUEsUpdate service.

Comment:

r02 agreed. Revised to S2-2109145.

Discussion and conclusion:

-

e-mail discussion:

George Foti (Ericsson) provides r01. This CR provides good clarification But I think we should remove completely the availability status. The original CR questions its usefulness as well
https://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_148E_Electronic_2021-11/INBOX/Revisions/S2-2108921r01.zip
Genadi (Lenovo) agrees with r01 provided by George Foti (Ericsson). Provides r02 to update the cover page.
==== Revisions Deadline ====
George (Ericsson) OK r02
==== Comments Deadline ====.

Status:

Revised to S2-2109145.

TD S2-2109145 (CR) 23.502 CR3309R1 (Rel-17, 'F'): Clarification on the NSACF result parameter sent to AMF. (Source: Lenovo, Motorola Mobility).
Document for: Approval.
Abstract: Summary of change: It is proposed that the NSACF returns a result indication to the AMF. The result indication contains one of: - 'maximum number of UEs registered with the network slice not reached'; or - 'maximum number of UEs registered with the network slice reached'. In addition, the 'availability status' parameter is removed from the 'Outputs, Required'.

Comment:

Revision of S2-2108921r02. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108644 (CR) 23.501 CR3411 (Rel-17, 'F'): NSAC for priority services. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: When there is MPS related PDU Session with Invocation-related Priority Mechanisms, the SMF indicates this to the AMF based on the information from the PCF. Besides, it is clarified If the use case requires the UE to remain reachable at all times with at least one slice, it is recommended that at least one of the Subscribed S-NSSAIs is marked as the default S-NSSAI which is not subject to Network Slice Admission Control.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

George Foti (Ericsson) proposes to note the CR. With support for session continuity ensured for slices subject to NSAC during EPC IWK and inter AMF mobility, this is not needed.
Haiyang (Huawei) indicates this paper is needed in case we cannot have a general solution for session continuity ensured for slices subject to NSAC during EPC IWK and inter AMF mobility this meeting (as already shown in the cover page).
Hoyeon (Samsung) provides a comment.
Haiyang (Huawei) clarifies to Hoyeon (Samsung).
Genadi (Lenovo) provides comments to Haiyang (Huawei).
Srisakul (NTT DOCOMO) provides comments.
George (Ericsson) comments. Adding such an indication serves no purpose. The PDU session is already accepted and is guaranteed NSAC bypass based on the existing specification. So the SMF will do nothing with it, unless U can explain how will the SMF use it.
Haiyang (Huawei) provides r01.
Hoyeon (Samsung) provides comments and proposes to address it as a part of session continuity.
Haiyang (Huawei) replies to Hoyeon (Samsung).
==== Revisions Deadline ====
George (Ericsson) objects to all revisions
Haiyang (Huawei) thinks George (Ericsson)'s objection is not valid
George (Ericsson) respond. I already stated that the session has been admitted and is guaranteed SC because it is high priority. So what is the purpose of telling SMF this is a high priority session, after the session is already admitted. There is no use for it anymore.
Haiyang (Huawei) responds to George (Ericsson)
George (Ericsson) respond. The session is already anchored. So it is subject to handover based on existing procedures and the session should survive unless the handover fails. U miss the point that there is no additional admission in this case. If the session is lost then this UE is subject to regular procedures. Nothing is broken. The case U are citing below is incorrect. There is no additional admission in an already established session regardless of EPC counting or lack there of. The UE may not be able to register but that's different.
Haiyang (Huawei) further responds to George (Ericsson)
George (Ericsson) respond. No for the simple reason that we have to look into support for SC for this one. I don't want what I would label a 'hack' of telling the AMF, please exempt the user because he is engaged in high priority session. I have a fundamental problem with this approach which is not sound.
Haiyang (Huawei) does not think SC could be guaranteed when EPS counting is not required currently. There is additional admission control in an already established session when EPS counting is not required
George (Ericsson) SC is guaranteed as the SMF anchors the sessions. Lets not debate that. It is mute issue. If the UE is not MPS than he may not be allowed to register when the UE registers in 5GC if the slice is subject to NSAC. Now the UE can emergency register in 5GC in this case, and we are good to go. Otherwise we can mandate that slices used for MPS should not be subject to NSAC regardless of EPC or 5GC. We don't need to hack the system for a corner case, and for one session only for the UE; now elevating him to MPS for the session duration.
Haiyang (Huawei) thinks the comment from George (Ericsson) is unfounded. It is clearly stated that in TS 23.501 clause 5.15.11.5 that 'Mobility from EPC to 5GC does not guarantee all active PDU Session(s) can be transferred to the 5GC in certain circumstances when either the current number of UE registration or the current number of PDU sessions would exceed the maximum number when the UE moves from EPC to 5GC.'. Besides, Invocation-related Priority Mechanism is not corner case but a fundamental mechanism of MPS/MCS
George (Ericsson) comment. I will not discuss the session as I said it is mute. I already provided answer on the Registration that U did not address. Furthermore, we have to resolve this within the context of support for SC for slices admission. So we have to wait.
Haiyang (Huawei) responds to George (Ericsson): I think for number of UEs we could wait. But for sessions the ongoing discussion is not related to the case when EPS counting is not required currently. Besides, a lie repeated a thousand times is still a lie. Your comment is opposite to the current spec.
George (Ericsson) comment. Obviously U don't read
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108922 (CR) 23.501 CR3345R2 (Rel-17, 'F'): Clarifications of NSAC and NSAC for roaming cases including Emergency and Priority Services. (Source: Peraton Labs, CISA ECD, Ericsson, Verizon).
Document for: Approval.
Abstract: Summary of change: Revision 1: This CR introduces a number of editorial changes to improve the readability of sections 5.15.11.0, 5.15.11.1, 5.15.11.2., 5.15.11.3. In addition, the CR adds the possibility of HPLMN based admission control for roaming UEs and both for the count of registrations and for the count of PDU connections per network slice. Revision 2: It also clarifies that the AMF and SMF exempt certain UEs and not entire slices from NSAC and addresses gaps in case a UE/PDU session should get priority treatment but does not use a priority establishment cause.

Comment:

Revision of (Agreed) S2-2107943 from S2#147E. Postponed.

Discussion and conclusion:

CC#2: Huawei suggested r01. Peraton Labs objected to this. This remained Postponed.

e-mail discussion:

Hoyeon (Samsung) provides a comment, and proposes to discuss this CR together with session continuity.
Genadi (Lenovo) provides comments and r01 to remove changes overlapping with S2-2108605.
George (Ericsson) comments
Haiyang (Huawei) seeks for clarification.
==== Revisions Deadline ====
Genadi (Lenovo) can live with r01. Provides further comments that further work is needed in the next meeting.
==== Comments Deadline ====.

Status:

Postponed.

## Access type

TD S2-2108516 (CR) 23.501 CR3261R2 (Rel-17, 'F'): NSAC clarification. (Source: Samsung, Ericsson).
Document for: Approval.
Abstract: Summary of change: Below is the current mechanism: - NSACF knows (1) the S-NSSAI subject to NSAC and (2) access type for the S-NSSAI. - AMF knows (1) the S-NSSAI subject to NSAC. - When the AMF receives a reject response from the NSACF including the S-NSSAI and the AT, the AMF rejects the S-NSSAI to the UE for this particular AT. In this case, it is proposed that the NSACF provides to the AMF in the reject response message the access type for the rejected S-NSSAI. Rev1: Undo AMF configuration Additional clarification (highlighted in yellow).

Comment:

Revision of (Postponed) S2-2107226 from S2#147E. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108517 (CR) 23.502 CR3252 (Rel-17, 'F'): NSAC clarification. (Source: Samsung).
Document for: Approval.
Abstract: Summary of change: Below is the current mechanism: - NSACF knows (1) the S-NSSAI subject to NSAC and (2) access type for the S-NSSAI. - AMF knows (1) the S-NSSAI subject to NSAC. - When the AMF receives a reject response from the NSACF including the S-NSSAI and the AT, the AMF rejects the S-NSSAI to the UE for this particular AT. In this case, it is proposed that the NSACF provides to the AMF in the reject response message the access type for the rejected S-NSSAI.

Comment:

r03 agreed. Revised to S2-2109146.

Discussion and conclusion:

-

e-mail discussion:

George Foti (Ericsson) provides comments. Please provide an update replacing 'and access type(s) applicable to NSAC' with 'applicable access type'
Hoyeon (Samsung) provides r01.
Fenqin (Huawei) ask a question
Yunjing (CATT) has similar question as Fenqin.
Hoyeon (Samsung) replies.
Fenqin (Huawei) responds.
Hoyeon (Samsung) replies to Fenqin (Huawei).
Genadi (Lenovo) supports the proposal, but probably alignment with S2-2108921 may be needed.
Fenqin (Huawei) comments
Genadi (Lenovo) comments to Fenqin (Huawei).
Yunjing (CATT) comments
Jinguo(ZTE) response
George (Ericsson) comments. Please explain what requirements U are trying to fulfil with this rather big change. We are not OK with this change. There seens to be adhoc changes combined with the MA-PDU CR 8818.
Hoyeon (Samsung) provides comments
Fenqin (Huawei) provides comments
Hoyeon (Samsung) provides r02.
George (Ericsson) is not OK with r02, and provides comments
Hoyeon (Samsung) clarifies that this CR is nothing related to session counting, and asks some questions to George (Ericsson)
Fenqin (Huawei) responds and provides r03
George (Ericsson) responds. The discussion about MA-PDU is addressed elsewhere. Introducing access types as a plural is not OK in this CR as there is no such case for regular PDU sessions. If MA-PDU decides on multiple access types, then we may introduce some categorization, rather than a plural term. This forces U to include the response the access type that is impacted with what is proposed. So move the discussion into MA-PDU thread. We don't need this CR.
George (Ericsson) we are OK with r03
==== Revisions Deadline ====
Hoyeon (Samsung) we can accept r03 for the progress.
==== Comments Deadline ====.

Status:

Revised to S2-2109146.

TD S2-2109146 (CR) 23.502 CR3252R1 (Rel-17, 'F'): NSAC clarification. (Source: Samsung).
Document for: Approval.
Abstract: Summary of change: Below is the current mechanism: - NSACF knows (1) the S-NSSAI subject to NSAC and (2) access type for the S-NSSAI. - AMF knows (1) the S-NSSAI subject to NSAC. - When the AMF receives a reject response from the NSACF including the S-NSSAI and the AT, the AMF rejects the S-NSSAI to the UE for this particular AT. In this case, it is proposed that the NSACF provides to the AMF in the reject response message the access type for the rejected S-NSSAI.

Comment:

Revision of S2-2108517r03. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108606 (CR) 23.502 CR3260 (Rel-17, 'F'): Clarification on Access Type for NSAC. (Source: ZTE,Ericsson).
Document for: Approval.
Abstract: Summary of change: It is proposed to clarify that the SMF invokes the NSAC procedure during inter access handover to update the access type in NSACF.

Comment:

r06 agreed. Revised to S2-2109147, merging S2-2108830.

Discussion and conclusion:

-

e-mail discussion:

Ashok (Samsung) have few concerns with the CR and object to it.
Yunjing (CATT) provides comments.
Jinguo (ZTE) response and provides r01
Ashok (Samsung) comments and not OK with r01
Yunjing (CATT) asks a question to Ashok.
Jinguo (ZTE) responses to Ashok.
Ashok (Samsung) responds to Jinguo and Yunjing
Fenqin (Huawei) comments
George (Ericsson) comments. It is needed but we have to look at the different types of sessions.
Jinguo(ZTE) response and provides r02
Fenqin (Huawei) comment and provides r03
Srisakul (NTT DOCOMO) provides comments.
George (Ericsson) provide comments.
Genadi (Lenovo) provides comments.
Srisakul (NTT DOCOMO) provide comments.
Srisakul (NTT DOCOMO) agrees with Genadi's comments. We would need more parameter rather than just 'skip indicator' as proposed.
George (Ericsson) I would be OK with this. But this does not handle the case if one AT is congested for MA-PDU case. Just to remind folks that Fenqin remove which is clearly incorrect, when he provided his update. So the CR needs clearly more work, but at least we seem to be converging
Ashok (Samsung) need clarification
Jinguo(ZTE) suggest to add new value for update flag.
Genadi (Lenovo) agrees with Jinguo's proposal to introduce a new 'update' value of the update flag.
Jinguo(ZTE) provides r04 to introduce a new 'update' value of the update flag.
Ashok (Samsung) need one clarification from Jinguo(ZTE) : Why NSACF has to consider AT while counting the PDU?
Hyunsook (LGE) asks the clarifications.
Jinguo(ZTE) responses.
Jinguo(ZTE) asks which sentence are you refereing to?
Ashok (Samsung) responds to Jinguo(ZTE)
alessio(Nokia) believes this Cr now is not adding anything to normal behaviour as it says the SMF updates the NSACF by decreasing AT count of the leg that is released and increase the one of the leg that is added. so what is new? iff I understood correctly then I ask the CR to be noted.
Genadi (Lenovo) provides r05 to describe the meaning of the 'update flag' in bulleted list for easier reading.
Jinguo(ZTE) reply that alessio(Nokia) understanding is incorrect.
Alessio(Nokia) can live with r05 as it is clear what it means now --. suggest it is a category C
Jinguo(ZTE) is fine with r05
Ashok ( Samsung) comments
Jinguo(ZTE) replies to Ashok ( Samsung)
George (Ericsson) provide comment. Some cases are still not supported in the CR r05. Additional comments below on what is missing
George (Ericsson) comment. I don't see access type at all in this rev. 05 Please point me to where it is.
Jinguo(ZTE) reply.
George (Ericsson) comments. U said a minute ago everything is supported. I don't see access types in the service definition either. We need to have one CR handling all issues related to a session including MA-PDU.
Genadi (Lenovo) responds to George (Ericsson). The access type related enhancements are in 8818 and 8830.
George (Ericsson) Can we handle everything here under that thread. It is not efficient this distributed discussion. Why cant we have one CR for the whole topic
Genadi (Lenovo) comments on the counting in NSACF.
George (Ericsson) comment. I am flexible. I just want one CR discussing all PDU aspects, including MA-PDU. We need to make sure that we dot overlook something by prematurely agreeing to bits and pieces
George (Ericsson) comments. The anchor SMF increases the count only at session initiation. AS such the described problem does not exist if U read the text.
Genadi (Lenovo) responds to George (Ericsson). I quickly checked 8606r05 and 8830 - there seems to be no contradictions. However, if merging is desirable, I can try to provide a merge version (but I can only provide in 1 hour from now).
George (Ericsson) provide a consolidate one using Jinguo 8606 rev 05. Yes merging is desirable and essential to see the whole picture --
==== Revisions Deadline ====
Genadi (Lenovo) provides r06 including the changes from S2-2108830.
Srisakul (NTT DOCOMO) ok with r06 and comments.
George (Ericsson) comments. I think this is Ok. If we need to do more clarification we can do it that later. I would support this revision.
Genadi (Lenovo) responds to Srisakul (NTT DOCOMO).
George (Ericsson) comment. The response must include the result per access type in support of MA-PDU. I believe this is a stage 2 discussion. We can add it later or add an EN, but it needs to be added.
Srisakul (NTT DOCOMO) ok with r06. Agrees to George that it would be better to clarify the issue in stage 2 spec, and we can add these details to resolve the issue in the next SA2 meeting.
==== Comments Deadline ====.

Status:

Revised to S2-2109147, merging S2-2108830.

TD S2-2109147 (CR) 23.502 CR3260R1 (Rel-17, 'F'): Clarification on Access Type for NSAC. (Source: ZTE,Ericsson, Lenovo, Motorola Mobility).
Document for: Approval.
Abstract: Summary of change: It is proposed to clarify that the SMF invokes the NSAC procedure during inter access handover to update the access type in NSACF. It is further clarified that for MA PDU Session associated with an S-NSSAI subject to NSAC, the NSACF provides a Result indication (i.e. 'maximum number of PDU Sessions per S-NSSAI reached' or not) to the SMF together with an associated Access Type. Further, it is proposed to delete the 'availability status' parameter from the Nnsacf_NSAC_NumOfPDUsUpdate service in clause 5.2.21.2.4.

Comment:

Revision of S2-2108606r06, merging S2-2108830. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108757 (CR) 23.502 CR3284 (Rel-17, 'F'): NSAC result applied access type. (Source: CATT).
Document for: Approval.
Abstract: Summary of change: Clarify that the NSAC result is only applied to the access type via which the NSAC request is sent.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

George Foti (Ericsson) proposes to note the CR. The response retuned from NSACF applies only to that request, and can't be used for other purpose. It is possible that quota has been increased or PDU sessions has been released freeing quotas, etc.
Ashok (Samsung) comments
Yunjing (CATT) replies.
George (Ericsson) comments. This seems to be an optimization. I assume it can be done without any normative next added. We would therefore propose to not the CR.
Alessio(Nokia) supports ericsson: we should not start proliferating the NSAC policies across NFs in the CN. Let's note this.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108818 (CR) 23.501 CR3269R2 (Rel-17, 'F'): Clarification on Access Type for NSAC. (Source: ZTE, Lenovo, Motorola Mobility).
Document for: Approval.
Abstract: Summary of change: For MA PDU Session, the SMF provides correspondingly 3GPP access and non 3GPP access to NSACF when the MA PDU Session is activated over 3GPP and/or non-3GPP access.

Comment:

Revision of (Agreed) S2-2107949 from S2#147E. Approved.

Discussion and conclusion:

-

e-mail discussion:

George Foti (Ericsson) proposes to note the CR. See comments on 8830
Jinguo(ZTE) is fine with this CR.
Ashok (Samsung) comments
Jinguo(ZTE) response
Genadi (Lenovo) responds to Ashok (Samsung).
Genadi (Lenovo) responds to George Foti (Ericsson).
George (Ericsson) comments
Hyunsook (LGE) provides a comment.
Genadi (Lenovo) comments to Hyunsook (LGE) and George (Ericsson).
Ashok (Samsung) does not agree with the CR
Genadi (Lenovo) replies to Ashok (Samsung) and provides alternative text.
Ashok (Samsung) responds to Genadi (Lenovo)
Genadi (Lenovo) replies to Ashok (Samsung) and provides a view that the MA-PDU Session is counted once in the NSACF.
Fenqin (Huawei) comments.
Jinguo(ZTE) response.
Genadi (Lenovo) responds to question from Fenqin (Huawei).
George (Ericsson) comments. Can we have one CR based on Jinguo's CR 8606. This distributed discussion does not help.
==== Revisions Deadline ====
George (Ericsson) to be noted. Addressed in 8606
Genadi (Lenovo) does not agree with George (Ericsson). 8818 is NOT addressed in 8606. The CR is 8606 is against 23.502, whereas the CR in 8818 is against 23.501.
George (Ericsson) respond. Ok U are right. I missed that one. Ericsson is OK with this one
Tao(VC) Let's check whether to approve r00 or not
George (Ericsson) Yes for Ericsson
Genadi (Lenovo) responds to Tao: yes, as this CR (to 23.501) is complimentary to the agreeable one in 8606 (to 23.502).
==== Comments Deadline ====.

Status:

Agreed.

TD S2-2108830 (CR) 23.502 CR3292 (Rel-17, 'F'): Clarification on Access Type for NSAC. (Source: Lenovo, Motorola Mobility, ZTE).
Document for: Approval.
Abstract: Summary of change: For MA PDU Session associated with an S-NSSAI subject to NSAC, it is proposed that the NSACF provides a Result indication (i.e. 'maximum number of PDU Sessions per S-NSSAI reached' or not) to the SMF together with an associated Access Type. Further, it is proposed to delete the 'availability status' parameter from the Nnsacf_NSAC_NumOfPDUsUpdate service in clause 5.2.21.2.4.

Comment:

Merged into S2-2109147.

Discussion and conclusion:

-

e-mail discussion:

George Foti (Ericsson) proposes not to handle MA-PDU in Relese 17. Please see additional comments
Jinguo(ZTE) support this paper
Genadi (Lenovo) responds to George (Ericsson).
George (Ericsson) comments. I don't believe the logic has to be in the NSACF. The NSAF maintains counts for admissions; and that's it. This can be its only role. It cannot be aware of session type. We have all sorts of session types; We have MBMS as well for example. So the approach in my view is incorrect beside the missing cases. We have to choose a future proof approach. The SMFs are aware of the logic. This will require updating the interface to handle these cases so NSACF stay clean.
Ashok (Samsung) does not agree with the CR. It propose NSACF to mention the AT in its output to SMF while accepting or rejecting the PDU session. In our view the admission and rejection is based on PDU threshold which is irrespective of AT.
Genadi (Lenovo) replies to Ashok (Samsung).
Ashok (Samsung) responds to Genadi (Lenovo)
Genadi (Lenovo) replies to Ashok (Samsung) and provides a view that the MA-PDU Session is counted once in the NSACF.
Genadi (Lenovo) comments to George (Ericsson).
==== Revisions Deadline ====
George (Ericsson) to be noted. Addressed in 8606
Genadi (Lenovo) agrees to be noted as merged into 8606r06.
==== Comments Deadline ====.

Status:

Merged into S2-2109147.

## Roaming

TD S2-2108603 (CR) 23.502 CR3259 (Rel-17, 'F'): Roaming support for NSAC. (Source: ZTE,China Unicom).
Document for: Approval.
Abstract: Summary of change: Clarify the configuration in NSACF in VPLMN on maximum value per mapped S-NSSAI is optional Add reference to 23.501.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

George Foti (Ericsson) provides r01. Minor editorial changes
Jinguo(ZTE) is fine with r01.
Alessio(nokia) cannot agree to this CR
==== Revisions Deadline ====
Jinguo(ZTE) suggest to go with r01
Fenqin(Huawei) propose to note this CR.
Alessio(Nokia) still objects and the only sensible way forward is to come back in Q1 next year to remove roaming support from the feature at this stage. we can work on it in rel-18
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108563 (CR) 23.501 CR3391 (Rel-17, 'F'): Roaming support for NSAC with HPLMN control. (Source: China Telecom, Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: It is proposed to add the roaming support for NSAC with HPLMN control. This includes following part: Subscription based NSAC controlled. This is to avoid too much configuration data at the AMF/SMF. V-NSACF communicate with the H-NSACF for the NSACF controlled by the HPLMN if the local maximum value are all consumed. Adding the PLMN ID for the NSACF discovery and seletion.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

George Foti (Ericsson) proposes to note the CR. For Release 17 what we have is sufficient. Any additional capabilities have to be checked with GSMA.
Fenqin (Huawei) ask a question for clarification
George (Ericsson) responds. Nothing is missing. In HR cases, the SMF in the HPLMN interacts with the NSACF and apply NSAC. Now there will be an NSACF dedicated for outbound-roamers as the service area has no meaning here. SO what is missing that stops U from doing based on what I stated
Ouerdia (Orange) agrees with Fenqin (Huawei)
George (Ericsson) provides comments.
Kaisu (Nokia) adds a comment
George (Ericsson) comments. The claim was that we have to get requirement from GSMA, and this what we can agree to in Release 17. We cannot invent our own requirements on a topic that is clearly within the realm of GSMA and its support for roaming agreements, which can be static, dynamic or no support at all depending on what they agree on. Let lay the known facts and not more than that.
Fenqin(Huawei) comments and provides r01
George (Ericsson) provides comment. Oh yes there is a need for GSMA requirements. This whole work item was triggered by GSMA. U can make Ur case there.
Ouerdia (Orange) comments. From an operator point of view, it is not easy to define in advance the quota of roamers to allot for each PLMN partner in the SLA, it will be a hard exercise.
So, it is better to have a single quota and perform admission control at HPLMN level, in real time and for all PLMNs (home and partners).
No need to wait for a requirements from GSMA.
George (Ericsson) objects to R01, and supporting any dynamic control while roaming without explicit requirements from GSMA. We can agree to send an LS to GSMA. I will also bring the issue up at the next meeting. If there are GSMA requirements to that effect we will support that.
Heng(China Telecom) support r01
George (Ericsson) comments. If U want HPLMN control roaming don't invoke an NSACF in the VPLMN. Just do everything in HPLMN. But that requires roaming agreement to allow that. This is the logical way to do this. Invoking an NSACF in VPLMN in this HPLMN control accomplishes nothing and create some unclear communication between NSACFs with no idea what is it about or for what purpose, nor any documentation on what it does; on the fly. This is why we are not supporting this adhoc proposals.
Alessio(Nokia) is supportive of introducing this. we also have this in our CRs. we can discuss which one should be used as basis.
Yan (China Mobile) tend to support the idea of this paper supporting HPLMN control for roaming UE.
Heng(China Telecom) reply to Geroge
George (Ericsson) responds. Please specify the roaming requirements, when it comes to slices subject to NSAC, that U want to support. Static, dynamic, VPLN, HPLMN and these buzz words provide no requirement; they are wishes. What are the roles in each network, and how does the roaming agreement fits in here. So provide the above information first, then we can see how to fulfill them.
Fenqin(Huawei) comments and suggest to go r01
George (Ericsson) Please provide the requirements, and not a solution. We object to all revisions
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108576 (CR) 23.502 CR3257 (Rel-17, 'F'): Roaming support for NSAC with HPLMN control. (Source: China Telecom, Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: It is proposed to add the roaming support for NSAC with HPLMN control. This includes following part: Subscription based NSAC controlled. This is to avoid too much configuration at the VPLMN. V-NSACF communicate with the H-NSACF for the NSACF controlled by the HPLMN.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

George Foti (Ericsson) proposes to note the CR. Please see comments in 8563
Alessio(Nokia) is supportive of introducing this. we also have this in our CRs. we can discuss which one should be used as basis.
==== Revisions Deadline ====
George (Ericsson) objects to the CR
Orange (Ouerdia) supports the CR
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108602 (CR) 23.501 CR3399 (Rel-17, 'F'): Roaming for NSAC. (Source: ZTE,China Unicom).
Document for: Approval.
Abstract: Summary of change: Clarify that the NSAC in VPLMN and HPLMN are performed independently. Clarify that the configuration in NSACF in VPLMN on maximum value per mapped S-NSSAI are optional Add the principle that when the UE establishes first home routed PDU session in the H S-NSSAI, the H SMF performs the NSAC to add the UE ID the roaming UE. Add the principle that when the UE release the last home routed PDU session in the H S-NSSAI, the H SMF performs the NSAC to remove the UE ID of the roaming UE.

Comment:

Postponed.

Discussion and conclusion:

-

e-mail discussion:

George Foti (Ericsson) provides comments
Jinguo (ZTE) provides r01
George (Ericsson) comments. Please see inline I don't understand what U are trying to achieve.
Ouerdia (Orange) proposes to note the CR. HPLMN is not able to count the registered UEs and/or perform admission control of its roamers, if required, with this proposal
Heng (China Telecom) ask a technical issue
Jinguo (ZTE) response and provides r02
Jinguo (ZTE) provides r03 as backup if S2-2108563((inter NSACF communication)) cannot be agreed
Alessio(nokia) cannot agree to this CR
Fenqin(Huawei) comments
==== Revisions Deadline ====
Jinguo (ZTE) provides r04, but propose to go with 8563r01 first if it is agreeable.
George (Ericsson) we are Ok with r04
Fenqin(Huawei) object r04
Jinguo(ZTE) replies to Fenqin and asks for CC#2
Jinguo(ZTE) is ok to postpone at this meeting
==== Comments Deadline ====.

Status:

Postponed.

## Session continuity

TD S2-2108331 (CR) 23.501 CR3239R1 (Rel-17, 'F'): Support for Session Continuity for EPC 5GC IWK, and inter-AMF Mobility. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: UDM is configured with additional information for subscribed S-NSSAIs per VPLMN that indicates if the subscribed S-NSSAI is subject to both EPC interworking and NSAC in EPC. This enables the AMF to indicate that such an S-NSSAI is to be guaranteed session continuity at handover hence the NSACF ignores if the maximum number of UE has been reached and return success for suhc an S-NSSAI. For a S-NSSAI handed over from 5G and suject to NSAC in EPC, the SMF+ PGW-C includes a session continuity indication in the request to the NSACF they interact with so the NSACF ignores if the maximum number of UEs has been reached. Same prinicple applies during inter-AMF mobility, when the new AMF includes a session contiuity inidcation for the list of registsred and allowed S-NSSAI in the old AMF allowing the NSACF to ignore if the maximum number of UEs has been reached. This approach ensure accurate accounging in the access domain where the UE is located. This CRis related to the 23.502 CR on the same topic.

Comment:

Revision of (Noted) S2-2107112 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

Hoyeon (Samsung) provides a comment.
George (Ericsson) respond.
Fenqin (Huawei) comments
George (Ericsson) provides response.
Hoyeon (Samsung) sees some lack of logic about the proposal.
George (Ericsson) please sees a response in line. Also Ur solution puts a new system behavior where a slice is rejected but have a PDU session established. That is not allowed today. So U are allowing the UE to continue the session, claiming this supports SC, without being registered. That breaks Release 15, 16, and 17. U also create a regulation problem with emergency and MPS users, without a solution.
Fenqin (Huawei) provides response and r01
George (Ericsson) Ericsson object to r01. Explain what will the NSACF communication solve the problem, and how. Please put down what U want in details. Explaining my statement: if the UE is roaming in a different service area and U don't count it as being there but rather being counted in some other service area potentially than U are miscounting. The SMF++PGW-C at home is counting the UE as being in EPC, while the UE is in 5G.
Fenqin (Huawei) responds.
George (Ericsson) comment. So U now want to extend this to every congested NSACF. That's new. Also help me understand how will reporting this to a central node eliminate congestion in the NSACF having a congestion. Will the central now return a response that is to be relayed by the NSACF to the UE. If so, then the NSACF has to now hold a state that this UE state is in a different node, potentially only for one slice, while other requested slices are OK. There are so many details that U are just ignoring, which shows the holes in this solution.
Hoyeon (Samsung) thinks George (Ericsson) misunderstood Samsung proposal. There is no proposal like 'a new system behavior where a slice is rejected but have a PDU session established.'
Jinguo(ZTE) provides r02
George (Ericsson) asks a question. How is the rejection of new PDU sessions over that slice help the over quota situation. Also what if that same UE registers other slices unrelated to the IWK slice and establish new PDU sessions. Please answer these 2 questions separately. Of course the question is directed of proponents of this approach in case of over congestion. Additional comments below
Jinguo (ZTE) responses
George (Ericsson) comments. So if the UE maintains this lone allowed PDU session indefinitely than the over quota situation is not helped. If the same UE uses other slices the over quota is not helped. DO U agree with the above statements ?
Iskren (NEC) - r02 is not acceptable
Jinguo(ZTE) response
Jinguo(ZTE) response to Iskren (NEC)
George (Ericsson) comments. I am a bit perplexed that U guys are arguing for a solution that does not resolve the quota issue over other solutions that also does not resolve it but U are complaining about it !!. More comments in line and trying to find a possible path forward.
Iskren (NEC) provides r03 which does not allow the UE registrations or PDU Sessions to increase to infinity in EPC interworking.
George (Ericsson) comments. Jinguo, this has nothing to do with attractiveness., U acknowledged it does not solve the over quota. It's the argument over it that is rather strange. I proposed few options as a way forward. I think these are pragmatic and provides control. It is also solution neutral. We can have some show of hand as well if need be. This is becoming a show stopper at this time. The other option is we don't support EPC counting, and we remove it completely. I see no other way.
George (Ericsson) comments. I would be OK with that, and once we have a consensus we can update the 502 one.
Iskren (NEC) answers Jinguo (ZTE)
George (Ericsson) responds. No it is guaranteed for those operators who don't configure anything in their NSACF expect reserve a pool for SC users. U have not proposed any solution either expect through the magic of NSACF2NSACF communication. So to support SC, VPLMN1 updates some node (there could be many) in an HPLMN where the is counted there and that UE is not counted in the VPLMN, even though the UE using the VPLMN resources, and overloading the corresponding slice quota in the VPLMN without counting or knowing it; that's under reporting.
Alessio(Nokia) proposes to note this CR
Hoyeon (Samsung) asks a question for new proposal.
George (Ericsson) responds. Some stated that the over quota is infinite. We tried to introduce a maximum over quota limit that the operator configures in the NSAC based on policy if he so chooses. Once that configured over quota is reached SC is not guaranteed. This provides the operator control and as well avoid the infinite issue that U and Fenqin raised. There is no silver bullet here. No one has presented one and there will be none in a distributed environment unless U complicate things to an extreme for a rare event. IF folks want to go to a centralized node then we scrap service areas.
Fenqin (Huawei) proposed to note this paper
George (Ericsson) provides r04. This is a last ditch effort before NSACF gets formally canned from Release 17.
Jinguo(ZTE) provides r05. However propose to go with r04 first if it is agreeable
==== Revisions Deadline ====
George (Ericsson) comments. The note must become normative and with the following text added at the end 'except by implementation specific means'
Fenqin(Huawei) propose to note this paper as view are not converged.
Jinguo(ZTE) asks for CC#2.
Hoyeon (Samsung) we can only accept r01 or r05. Objects to other revisions.
George (Ericsson) Ericsson objects to all revision beyond the original
Iskren (NEC) supports r02 but can also accept r04.
Iskren (NEC) - Sorry, correction:). We can accept r00, r03, r04 only.
Alessio(Nokia) Objects to all revisions and the original one
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108332 (CR) 23.502 CR3126R1 (Rel-17, 'F'): Support for Session Continuity for EPC 5GC IWK, and inter-AMF Mobility. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: UDM is configured with additional information for subscribed S-NSSAIs per VPLMN that indicates if the subscribed S-NSSAI is subject to both EPC interworking and NSAC in EPC. This enables the AMF to indicate that such an S-NSSAI is to be guaranteed session continuity at handover hence the NSACF ignores if the maximum number of UE has been reached and return success for suhc an S-NSSAI. For a S-NSSAI handed over from 5G and suject to NSAC in EPC, the SMF+ PGW-C includes a session continuity indication in the request to the NSACF they interact with so the NSACF ignores if the maximum number of UEs has been reached. Same prinicple applies during inter-AMF mobility, when the new AMF includes a session contiuity inidcation for the list of registsred and allowed S-NSSAI in the old AMF allowing the NSACF to ignore if the maximum number of UEs has been reached. This approach ensure accurate accounging in the access domain where the UE is located.

Comment:

Revision of (Noted) S2-2107108 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

Hoyeon (Samsung) provides a comment. Please see our comment on S2-2108331.
Fenqin (Huawei) same comment as our comment on S2-2108331.
Alessio(Nokia) proposes to note this CR
George Foti (Ericsson) provides r01 adding the operator policy to manage over quota.
Iskren (NEC) provides r02.
Fenqin (Huawei) same comment as 8331.
alessio(Nokia) keeps their concerns.
George (Ericsson) provides r04. The only thing we will be able to agree upon, if any, is to leave it to implementation to ensure SC while not going over the quota. More comments
==== Revisions Deadline ====
Fenqin (Huawei) propose to note this paper due to same reason as 8331.
Hoyeon (Samsung) proposes to note this CR.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108520 (CR) 23.501 CR3384 (Rel-17, 'F'): NSAC mechanism for session continuity. (Source: Samsung).
Document for: Approval.
Abstract: Summary of change: To realize this, it is proposed that AMF stores the information indicating that the S-NSSAI is exempt from NSAC and corresponding on-going PDU session ID(s). After successful registration, if the UE requests a new PDU session associated with the S-NSSAI, the AMF rejects the request as the S-NSSAI is allowed only for the existing PDU sessions. When all existing PDU session(s) associated with the S-NSSAI are released, and the current number of UEs still exceeds the maximum number of UEs, the AMF puts the S-NSSAI in rejected S-NSSAIs, and provides the new Allowed NSSAI and rejected S-NSSAI to the UE via UE Configuration Update procedure.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

George Foti (Ericsson) provides comments
Hoyeon (Samsung) replies to George Foti (Ericsson).
George (Ericsson) provides comments in line. U have to clarify what objectives U are trying to achieve and why. What U are proposing is new behavior and solves nothing. Ur proposal does not solve the fact that the maximum number of registered UEs has been reached. Not to mention that the quotas are unrelated as U heard it from others as well.
Hoyeon (Samsung) thinks George (Ericsson) misunderstood Samsung proposal. There is no proposal like 'a new system behavior where a slice is rejected but have a PDU session established.'
George (Ericsson) please respond to the question on the purpose of this limitation. How will it get rid of the over quota situation.
Alessio(Nokia) proposes to note this CR
Dan(China Mobile) tend to support this idea of this paper
Hoyeon (Samsung) provides r01 to accommodate Dan(China Mobile)'s comment.
George (Ericsson) responds. There is nothing temporary as Jinguo confirmed, the UE can keep the session indefinitely, the UE can request new slices and new sessions. So this provides no solution to the basic problem of uncontrolled over quota as U call it.
Iskren (NEC) - this CR to be Noted or considered as merged to S2-210331 by Ericsson.
==== Revisions Deadline ====
Fenqin (Huawei) - propose to note this CR as it also not solve the over quota issue.
Hoyeon (Samsung) proposes to note this CR.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108521 (CR) 23.502 CR3253 (Rel-17, 'F'): NSAC mechanism for session continuity. (Source: Samsung).
Document for: Approval.
Abstract: Summary of change: To realize this, it is proposed that AMF stores the information indicating that the S-NSSAI is exempt from NSAC and corresponding on-going PDU session ID(s). After successful registration, if the UE requests a new PDU session associated with the S-NSSAI, the AMF rejects the request as the S-NSSAI is allowed only for the existing PDU sessions. When all existing PDU session(s) associated with the S-NSSAI are released, and the current number of UEs still exceeds the maximum number of UEs, the AMF puts the S-NSSAI in rejected S-NSSAIs, and provides the new Allowed NSSAI and rejected S-NSSAI to the UE via UE Configuration Update procedure.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

George Foti (Ericsson) Please see comments on S2-2108520. The CR is Not OK
Alessio(Nokia) proposes to note this CR
Iskren (NEC) - this CR to be Noted or considered as merged to S2-210332 by Ericsson.
==== Revisions Deadline ====
Hoyeon (Samsung) proposes to note this CR.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108817 (CR) 23.501 CR3434 (Rel-17, 'F'): Clarification of NSAC. (Source: Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: Clarifies that when EPS counting is active for a S-NSSAI, the AMF counting is not activated. it lso clarifie that subscription data controls the feature and tha Proxying is used to support roaming and also zoning without PDU session drop.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

George Foti (Ericsson) objects to the CR and to the gross misclassification of it as being a Cat F CR. The CR creates more issues, missed cases, and even what it provides is non-scalable. Not to mention the lack of any basis for these major functional change. Additional comments below.
Jinguo(ZTE) comments that this CR is not aligned with GSMA requirement.
Fenqin (Huawei) comments.
George (Ericsson) comments. Ur view of proxying is completely misaligned with what is in the CR as a starter. The CR specification of proxying is about routing and nothing more.
Iskren (NEC) expresses concerns with this CR.
Alessio(Nokia) replies
Hoyeon (Samsung) proposes to note this CR
Iskren (NEC) proposes to note this CR
Alessio(nokia) replies to Hoyeon(SS)
==== Revisions Deadline ====
Hoyeon (Samsung) proposes to note the CR. At least, SC related proposal should be noted.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108831 (CR) 23.502 CR3293 (Rel-17, 'F'): Clarification of NSAC. (Source: Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: Clarifies that NSACF services can be proxied and also that the PDU sessionrelated update service operation can be used to count the number of UEs per netwrok slice . it is clarified NSAS Information for a S-NSSAI is in subscrtiption data.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

George Foti (Ericsson) objects to the CR. Please see comments on 8817.
Iskren (NEC) expresses concerns with this CR.
Alessio(Nokia) replies
George (Ericsson) provides a response. The NSACF proxying is an even bigger issue. We can resort to a single node and simplify everything eliminating all problems; but to create NSACF for the sole purpose of proxying is rather strange as an architecture choice given that there is only a central node responsible for Counting. Furthermore with roaming, EPC IWK, and proxying as a package we will end up counting the UE in the PLMN where he initiated the session, and not the current one he is accessing.
Alessio(Nokia) replies that like NSSF and NRF, the NSACF can play the role of prosy between VPLMN and HPLMN. So we do not understand the issue.
George (Ericsson) comments. NSSF and NRF are not proxies. They are used for policies regarding slicing, and discovery. With that said, is the sole purpose of NSACF proxy routing towards the central node, or does it have another role. Also for intra-PLMN role what role beside routing is the NSACF playing. That is 95% of the traffic. Do NSACF perform anything when it comes to admission. I came to the conclusion that it is pure routing. All the admission, state creation, etc. are managed up in the single node.
Hoyeon (Samsung) expresses concerns with this CR
Iskren (NEC) proposes to Note this CR.
==== Revisions Deadline ====
Hoyeon (Samsung) proposes to note the CR. At least, SC related proposal should be noted.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108832 (CR) 23.501 CR3347R1 (Rel-17, 'F'): NSAC for maximum number of PDU Sessions for EPC IWK. (Source: Lenovo, Motorola Mobility, NTT DOCOMO, NEC).
Document for: Approval.
Abstract: Summary of change: It is proposed that for NSAC for maximum number of PDU Sessions when the UE moves between 5GC and EPC and PDU Sessions are handed over, the SMF+PGW-C does not send an update to the NSACF.

Comment:

Revision of (Postponed) S2-2107735 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

George Foti (Ericsson) provides comments
Hoyeon (Samsung) provides comments.
Genadi (Lenovo) provides r01 and replies to comments.
Fenqin (Huawei) ask question
Alessio(nokia) comments and requests to note this CR as it is going down an unworkable path for EPC counting
Hoyeon (Samsung) provides a comment.
Genadi (Lenovo) replies to Alessio (Nokia) that the CR works if the final conclusion is to go with the proposal in 8331.
==== Revisions Deadline ====
Hoyeon (Samsung) proposes to note this CR.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108888 (CR) 23.501 CR3058R3 (Rel-17, 'F'): TS23.501 Correction to the NSAC to maintain service continuity. (Source: NEC).
Document for: Approval.
Abstract: Summary of change: It is suggested that the following text is added to clause 5.15.11.0 'To maintain service continuity when the UE handovers to 5GS from EPS or when the UE re-registers to the same network slice during intra 5GS handover with AMF change, based on the operator's policy, the NSACF may not reject the registration of the UE even if the maximum number of the registered UEs with the network slice in 5GS has been reached. Similarly, based on operator's policy, the NSACF may not reject the PDU Session(s) even if the maximum number of PDU Sessions within the network slice in 5GS has been reached. However, the NSACF continues to count the UE registrations and PDU Sessions for such network slice.'.

Comment:

Revision of (Noted) S2-2107456 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

George Foti (Ericsson) provides comments. The CR does not distinguish the case when EPS counting is performed vs the case where EPS counting is not performed. It leaves everything to operator policy which is nit aligned with existing text.
Jinguo(ZTE) suggest to merge this CR into 8331 to have single thread discussion
Alessio(Nokia) asks to note this CR
==== Revisions Deadline ====
Hoyeon (Samsung) proposes to note this CR.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108889 (CR) 23.502 CR2950R4 (Rel-17, 'F'): TS23.502 Correction to the NSAC to maintain service continuity. (Source: NEC).
Document for: Approval.
Abstract: Summary of change: It is suggested that the NSACF in 5GS is made aware that service continuity is required and NSACF, based on operator policy, may not reject the UE if the max number of registered UEs or max number of established PDU Sessions for the network slice has been reached.

Comment:

Revision of (Noted) S2-2107478 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

George Foti (Ericsson) provides comments
Jinguo(ZTE) suggest to merge this CR into 8332 to have single thread discussion
Alessio(nokia) asks to note this CR
==== Revisions Deadline ====
Hoyeon (Samsung) proposes to note this CR.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108928 (CR) 23.501 CR3348R1 (Rel-17, 'F'): SMF+PGW-C behaviour during UE mobility between 5GC and EPC. (Source: Lenovo, Motorola Mobility).
Document for: Approval.
Abstract: Summary of change: It is proposed that for NSAC for maximum number of UEs during UE mobility between 5GC and EPC, the SMF+PGW-C or the AMF may delay sending of the update to decrease the number of UEs by an operator configured time.

Comment:

Revision of (Postponed) S2-2107736 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

George Foti (Ericsson) provides comments
Genadi (Lenovo) provides r01 based on comment from George Foti (Ericsson).
Alessio(Nokia) requests to note this CR
Jinguo(ZTE) supports this CR
Hoyeon (Samsung) is OK with the proposal, asks a question for clarification.
Alessio(Nokia) the conflict is because it affects same text. in clause.
Genadi (Lenovo) replies to Hoyeon (Samsung).
Genadi (Lenovo) replies to Alessio (Nokia) and provides r02.
==== Revisions Deadline ====
George (Ericsson) OK rev 02
Hoyeon (Samsung) is OK with r02.
Fenqin (Huawei) comments.
Genadi (Lenovo) comments Fenqin (Huawei).
Fenqin (Huawei) comments and suggest bring this to CC#2
Genadi (Lenovo) suggests to bring this CR to CC#2.
Alessio(Nokia) cannot agree to this CR which highlights the issues with the current model. we need to discuss this thing until next meeting.
Alessio(Nokia) provides further info on why there is no point to discuss in CC#2
==== Comments Deadline ====.

Status:

Noted.

## KI#3 U-Slice-MBR

TD S2-2108336 (CR) 23.503 CR0667 (Rel-17, 'F'): Correction to UE-Slice-MBR support. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: The PCF can perform monitoring of the UE-Slice-MBR if NG-RAN reports that UE-Slice-MBR reporting is not feasible.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Alessio(Nokia) objects to this CR
Paul (Ericsson) replies to Alessio (Nokia).
Alessio(Nokia) repeats Nokia concerns with this and cannot agree this is needed.
Paul (Ericsson) replies to Alessio (Nokia). Please provide technical reasons for Nokia's objection.
Alessio (Nokia) says he has already provided the reason.
Paul (Ericsson) provides r01.
==== Revisions Deadline ====
alessio(Nokia) objects to r01
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108380 (CR) 23.501 CR3368 (Rel-17, 'F'): Correction to UE-Slice-MBR support. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: Add missing requirement on RAN when UE-Slice-MBR enforcement is not feasible. Clarify transfer of UE-Slice-MBR transfer to NG-RAN.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Dongeun (Samsung) asks a question
Heng(China Telecom) has the same concern as Dongeun
Paul (Ericsson) replies to Dongeun (Samsung) and Heng(China Telecom).
Heng(China Telecom) has a comment under the reply
Jinguo(ZTE) think the second change is not needed
Haiyang (Huawei) shares similar view with Heng (China Telecom).
Paul (Ericsson) replies to Jinguo (ZTE).
alessio (Nokia) objects to this CR
Paul (Ericsson) replies to Alessio (Nokia). This CR is needed as otherwise CN has no visibility that a policy intended required) to be enforced is not followed. This breaks this functionality.
Alessio(Nokia) comments that we have a different understanding of how to choose between PCF based and RAN based and we do not see the need of this feature proposed after release is frozen.
Paul (Ericsson) replies to Alessio (Nokia). The feature is broken if CN is left unaware of whether the policy is actually enforced. No technical reasons to objection are provided.
Alessio (Nokia) says he has already provided the reason.
Jinguo(ZTE) comments
Paul (Ericsson) provides r01.
==== Revisions Deadline ====
Jinguo(ZTE) is ok with first change in r01 but not ok with second change.
alessio(Nokia) objects to r01
==== Comments Deadline ====
Paul (Ericsson) asks question for clarification. Can Nokia clarify what is expected to happen/happens when enforcement of UE-Slice-MBR in RAN is not feasible?

Status:

Noted.

TD S2-2108527 (CR) 23.502 CR3151R1 (Rel-17, 'F'): UE-Slice-MBR enforcement during SSC mode 3 operation. (Source: Samsung).
Document for: Approval.
Abstract: Summary of change: - During the PDU session establishment, if the AMF received the old PDU Session ID, the AMF includes SSC mode 3 operation indication to the SMF. - During the PDU session establishment, if the SMF received SSC mode 3 operation indication from the AMF, the SMF includes an indication of replacement of existing PDU sessionthe SSC mode 3 operation indication in N2 SM information and when NG-RAN receives an indication of replacement of existing PDU sessionSSC mode 3 operation indication, this may be taken into account by the NG-RAN for enforcing the UE-Slice-MBR on the corresponding S-NSSAI of the PDU Session.

Comment:

Revision of (Postponed) S2-2107268 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

Belen (Ericsson) objects to this CR.
Dongeun (Samsung) replies.
Jinguo(ZTE) objects to this CR
Dongeun(Samsung) responds to ZTE.
Jinguo(ZTE) responds.
Dongeun (Samsung) responds to ZTE
Jinguo(ZTE) reply
alessio(Nokia) objects to this CR as already discussed at last meeting
Belen (Ericsson) does not think this CR is needed.
Dongeun (Samsung) replies to Belen (Ericsson)
==== Revisions Deadline ====
Belen (Ericsson) replies to Samsung
==== Comments Deadline ====.

Status:

Noted.

## KI#4 slice info exposure

TD S2-2108313 (CR) 23.502 CR3220 (Rel-17, 'D'): Correction for the figure of Number of UEs and PDU Sessions per network slice status retrieval by AF procedure. (Source: KDDI).
Document for: Approval.
Abstract: Summary of change: Correct the figure of Number of UEs and PDU Sessions per network slice status retrieval by AF procedure of clause 4.15.3.2.12.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

George Foti (Ericsson)proposes to note the CR. This section will have to be completely removed.
==== Revisions Deadline ====
==== Comments Deadline ====
Koji Saito(KDDI) provides comment.

Status:

Noted.

TD S2-2108333 (CR) 23.502 CR3128R1 (Rel-17, 'F'): Using Immediate reply in conjunction with NSACF related events. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: Introduce support for immediate reporting flag to avoid a dedicated service for that. Handle aggregation in a PLMN with more than one service area and when there is single service area.

Comment:

Revision of (Noted) S2-2107114 from S2#147E. CC#2: r05 with restoration of changes in step 7 agreed. Revised to S2-2109341, merging S2-2108721, S2-2108423 and S2-2108642.

Discussion and conclusion:

CC#2: Ericsson proposed taking S2-2108333r05 with restoration of changes in step 7. This was agreed and revised in S2-2109341.

e-mail discussion:

George Foti (Ericsson) provides r01 merging changes from 8642 into r01. See comments on 8642.
George (Ericsson) provides r02. I included 8721 in here. In response to Genadi about including the S-NSSAI in event filer. I saw no way to do it as this is only for this event, and nothing else.
Jinhua (Xiaomi) provides comments.
Srisakul (NTT DOCOMO) provides r03 and comments.
George (Ericsson) is OK with r03
Kaisu (Nokia) provides r04, which also includes content from 8423rev01.
George (Ericsson) comment, We object to r04. Why are U sneaking in the geographical area now ?. We can add a note only for that part . The period chosen is selected by the NEF based on its internal logic, or implementation
Please see additional comments
George (Ericsson) provides r05. We created a Note for setting up period. Removed geographical area being new function not belonging in a Cat F CR, immature, and not completely thought out and incomplete. Cleaned up step 8.
Jinguo(ZTE) supports the georgraphic area
George (Ericsson) Is this additional function in the exception report?
Jinhua(Xiaomi) provides comments, r05 is fine, and replies to Srisakul about the trusted AF communicate directly
Dan(China Mobile) provides r06 and object to r05
George (Ericsson) This is a new feature and incorrectly specified. U can bring it in a call. We object to r06 that introduces new features
Srisakul (NTT DOCOMO) replies to Jinhua's comment. OK for both r05 and r06.
Jinhua(Xiaomi) replies to Srisakul, the NOTE2 in table 5.2.21.1-1 is sufficient for now. both r05 and r06 is OK for me.
Iskren (NEC) - none of the revisions of this CR are acceptable. NEC objects to it as it has gone much beyond its purpose.
George (Ericsson) comment. U misunderstood the additions that are necessary to handle service identifier for untrusted AF, and to support single NSACF vs multiple NSACFs deployments. These will have to be in regardless. They will never be out, in any version that U conceive will make U happy unless U eliminate the requirements. They are essential requirements not optional today.
==== Revisions Deadline ====
Jinguo(ZTE) agree with George (Ericsson) that we should go with r05 or r06 and ask for CC#2.
George (Ericsson) for us r06 is Not OK. The geographical support is a new feature and is only 10% specified; yes that's it, not well though at all, but I will not discuss any technical issues now or on the call. That's for another day. We need to have a stable revision first, and that's what matters now.
George (Ericsson) comments. Jinguo U should bring this up on CC#2.
George (Ericsson) comments. I don't understand what merging are U talking about. What is missing here in this procedure. It's a simple question. We did not touch the NSACF procedure. U cannot subscribe for both Registered UEs and PDU sessions in a single request if that is what U imply by merge.
Fenqin (Huawei) we are fine with r05 or r06. Thanks!
Kaisu (Nokia) we support r06.
Dan (China Mobile) we support r06.
Iskren (NEC) objects to all versions of this CR unless the bellow highlighted essential text from the current spec is restored.
7. The NSACF sends the Nnsacf_SliceEvent Exposure_Notify (Event ID, Event Filter, Event Reporting information) message to the NEF. If the subscription is for event based notification (e.g. based on the monitored event reaching a threshold value), the Event Reporting information parameter contains confirmation for the event fulfilment. If the subscription is for periodic notification or for immediate reporting, the Event Reporting information parameter provides information for the current number of UEs registered with a network slice (e.g. represented in percentage of the maximum number of the UEs registered with the network slice), information for the current number of PDU Sessions on a network slice (e.g. represented in percentage of the maximum number of the UEs established on the network slice) or both.
Genadi (Lenovo) supports r05 or r06 in order to make progress. Clean-ups are needed in CC#2 or in the next meeting.
Iskren (NEC) answers Genadi (Lenovo)
George (Ericsson) Ericsson accepts only r05.
Srisakul (NTT DOCOMO) is fine for both r05 and r06. Ok to restore texts in step#7 as proposed by Iskren.
==== Comments Deadline ====.

Status:

Revised to S2-2109341, merging S2-2108721, S2-2108423 and S2-2108642.

TD S2-2109341 (CR) 23.502 CR3128R2 (Rel-17, 'F'): Using Immediate reply in conjunction with NSACF related events. (Source: Ericsson, NTT DOCOMO).
Document for: Approval.
Abstract: Summary of change: Introduce support for immediate reporting flag to avoid a dedicated service for that. Handle aggregation in a PLMN with more than one service area and when there is single service area.

Comment:

Revision of S2-2108333r05 + changes, merging S2-2108721, S2-2108423 and S2-2108642. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108419 (CR) 23.501 CR3259R1 (Rel-17, 'F'): AF request for specific area slice status report when multiple NSACFs existing in network. (Source: China Mobile).
Document for: Approval.
Abstract: Summary of change: Adding service are in event filter to help NEF find one NSACF for the AF request.

Comment:

Revision of (Noted) S2-2107222 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

George Foti (Ericsson) proposes to note the CR. The request is for slices or service identifiers but not for service areas.
Genadi (Lenovo) provides comments.
Dan(China Mobile) provides reply.
Iskren (NEC) provides comments.
Ashok (Samsung) shares same view as Iskren (NEC)
Srisakul (NTT DOCOMO) comments and agrees to Iskren (NEC).
George (Ericsson) provides comments. This is an enhancement that has to be done separately. It is not within the scope of the exception report.
Dan (China Mobile) provides r01
George (Ericsson) objects to the CR
Kaisu (Nokia) supports rev01
==== Revisions Deadline ====
TAO(VC) check whether r01 agreeable
Iskren (NEC) supports r01
George (Ericsson) comments Ericsson objects to all revisions.
George (Ericsson) Ericsson objects. This adds new feature that is not on the table under a CAT F CR, and with no support at all in 23.502.
Dan (China Mobile) comments George (Ericsson) 's objection is not based on technical reason, which is unacceptable.
Dan (China Mobile) we request for CC#2
Srisakul (NTT DOCOMO) supports r01.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108423 (CR) 23.502 CR3143R2 (Rel-17, 'F'): AF request for specific area slice status report when multiple NSACFs existing in network. (Source: China Mobile).
Document for: Approval.
Abstract: Summary of change: Adding service are in event filter to help NEF find one NSACF for the AF request.

Comment:

Revision of (Postponed) S2-2107221 from S2#147E. Merged into S2-2109341.

Discussion and conclusion:

-

e-mail discussion:

George Foti (Ericsson) proposes to note the CR. See S2-2108419
Genadi (Lenovo) proposes to discuss first the proposal in S2-2108419 to 23.501.
Iskren (NEC) provides comments.
Dan (China Mobile) provides r01
Iskren (NEC) answers Dan (China Mobile) and provides r02 with some editorials.
George (Ericsson) objects to including additional functionality under a Cat F CR and not covered in the exception report.
George (Ericsson) comments. We don't agree to CAT F CRs adding functionality not in the exception sheet.
Iskren (NEC) - In my opinion it is not a new feature as we already have the service area as an input for NSACF discovery.
George (Ericsson) SA is not geographical area. We have to stop this adhoc addition of things. This is what got this work item in trouble. There is no relation to the study item anymore.
Kaisu (Nokia) informs that she has merged 8423rev01 to document 8333rev04
==== Revisions Deadline ====
Dan (China Mobile)suggest mark this merged into S2-2108333 if SA2 WG approve S2-2108333 r06.
==== Comments Deadline ====.

Status:

Merged into S2-2109341.

TD S2-2108641 (CR) 23.501 CR3410 (Rel-17, 'F'): Corrections on Nnsacf_SliceStatus and Nnef_SliceStatus services. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Remove Nnsacf_SliceStatus and Nnef_SliceStatus service. Remove the description of subscribing/notifying both the number of UEs reeistered for a network slice and the number of PDU sessions established on a network slice.

Comment:

Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108642 (CR) 23.502 CR3270 (Rel-17, 'F'): Corrections on Nnsacf_SliceStatus and Nnef_SliceStatus services. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Remove Nnsacf_SliceStatus and Nnef_SliceStatus service. Add the clarification related to the multiple NSACF instance for slice event exposure procedure. Change the forwarding to others suitable wording. Update the 2nd step 5( step 6 in the figure Remove the description of subscribing/notifying both the number of UEs reeistered for a network slice and the number of PDU sessions established on a network slice.

Comment:

Merged into S2-2109341.

Discussion and conclusion:

-

e-mail discussion:

George Foti (Ericsson) proposes to note the CR and incorporate the changes in 5.2.21, 5.2.21.4.2, 5.2.21.4.4, 5.2.21.5 in 8333r01. Additional comments below.
==== Revisions Deadline ====
Haiyang (Huawei) is OK to merge this paper into 8333.
==== Comments Deadline ====.

Status:

Merged into S2-2109341.

TD S2-2108721 (CR) 23.502 CR3278 (Rel-17, 'F'): Clarification for network slice notification procedure for untrusted AF case. (Source: NTT DOCOMO).
Document for: Approval.
Abstract: Summary of change: Clarifies that external parameter (e.g., AF-Service-Identifier or ENSI) should be used for translation/mapping to the S-NSSAI, when the untrusted AF wants to subscribe or unsubscribe for the number of UEs or the number of PDU Sessions per network slice notification with the NEF.

Comment:

CC#2: Merged into S2-2109341.

Discussion and conclusion:

CC#2: This was merged into S2-2109341,.

e-mail discussion:

George Foti (Ericsson) provide r01 just clarifying that Notification to trusted AF includes the service identifier. This CR fits nicely with Ericsson CR S2-2108333
Ashok (Samsung) comments
Srisakul (NTT DOCOMO) ok with r01 and provides responses to comments.
Genadi (Lenovo) supports the concept, but proposes to move the changes as normative text to clause 4.15.3.2.10. Provides r02.
Ashok (Samsung) thanks Genadi (Lenovo) for r02
George (Ericsson) comments. This is not the right place for that. I will provide an update of my CR merging this in 8333 which is the one that should be updated.
Genadi (Lenovo) provides comments to George (Ericsson).
Srisakul (NTT DOCOMO) provides comments.
==== Revisions Deadline ====
Srisakul (NTT DOCOMO) suggests to mark this tdoc as 'Merged into S2-2108333, if SA2 WG approves any revision from r03 of S2-2108333. Otherwise, let's consider r02 to be approved.'
==== Comments Deadline ====.

Status:

Merged into S2-2109341.

TD S2-2108785 (CR) 23.501 CR3428 (Rel-17, 'F'): Correction for External Exposure of Network Capability. (Source: Xiaomi,).
Document for: Approval.
Abstract: Summary of change: In clause 5.20, add the NEF function description of the event based notifications and reports for NSACF supporting.

Comment:

Approved.

Discussion and conclusion:

-

Status:

Agreed.

## KI#5 PCF based monitoring

TD S2-2108737 (CR) 23.503 CR0663R1 (Rel-17, 'F'): Correction for PCF based monitoring of the data rate per network slice. (Source: Huawei, HiSilicon, Ericsson).
Document for: Approval.
Abstract: Summary of change: A separate counting for the GBR traffic (Remaining Maximum Slice Guaranteed Data Rate) is introduced for the PCF based monitoring to enable a rejection of GBR service data flows by the PCF when a certain percentage of the Maximum Slice Data Rate is already used by GBR service data flows. There is also a note added about the possible scenario that a single PCF is used for the monitoring and limitation of the data rate for an S-NSSAI.

Comment:

Revision of (Noted) S2-2107509 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

Belen (Ericsson) proposes to merge this CR into S2-2108737
Jinhua(Xiaomi) replies to Belen,
Alessio(Nokia) asks to note the CR and all its revisions as per discussion we already had at SA2#147
Mirko (Huawei) responds to Alessio.
Belen (Ericsson) supports this CR.
==== Revisions Deadline ====
Tao(VC) further check whether it is agreeable per clarification from Huawei and Ericsson.
Alessio(Nokia) does not understand why we need this separate value given the quota is not separate. maintains the objection as there is no reason to assume that we starve Non GBR unless statisticaly almost all requests are GBR, which then means that GBR is most important category to be served.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108787 (CR) 23.503 CR0687 (Rel-17, 'F'): Correction for PCF Based Monitoring of the Slice Data Rate. (Source: Xiaomi,).
Document for: Approval.
Abstract: Summary of change: In clause 6.1.4.1, one Note for clarification and the statement is also completed about rejecting a GBR SDF request while exceeding the Maximum slice Data Rate.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

alessio(Nokia) provides r01
Mirko (Huawei) comments.
Belen (Ericsson) comments.
alessio(Nokia) clarifies that the maximum data rate defined by GSMA includes GBR and NON GBR.
==== Revisions Deadline ====
Belen (Ericsson) cannot accept r01 and objects, provides a rephrasing if acceptable
Tao(VC) check whether Belen's text proposal acceptable or not
Jinhua(Xiaomi) is OK with Belen's proposal, that r01 can be approved without the addition of 'exceeding the Maximum Slice Data Rate'.
Alessio(Nokia) does not understand why we need this separate value given the quota is not separate. maintains the objection as there is no reason to assume that we starve Non GBR unless statistically almost all requests are GBR, which then means that GBR is most important category to be served.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108788 (CR) 23.503 CR0652R2 (Rel-17, 'F'): Selection of the PCF for network slice related policy control. (Source: Ericsson(?), Xiaomi).
Document for: Approval.
Abstract: Summary of change: Remove the explicit indication in the options. - Clarify that the SMF receives 'Same PCF Selection Indication' from the AMF. - Clarify that the SMF receives the redirection indicator and the PCF ID from the PCF.

Comment:

Revision of (Agreed) S2-2107952 from S2#147E. Confirm Sources! r02 agreed. Revised to S2-2109148.

Discussion and conclusion:

-

e-mail discussion:

Belen (Ericsson) confirms support to this CR
Jinhua(Xiaomi) replies to Belen and provides r01,
Mirko (Huawei) provides r02.
Jinhua(Xiaomi) replies to Mirko, r02 is OK.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109148.

TD S2-2109148 (CR) 23.503 CR0652R3 (Rel-17, 'F'): Selection of the PCF for network slice related policy control. (Source: Ericsson, Xiaomi).
Document for: Approval.
Abstract: Summary of change: - Clarify that the SMF receives 'Same PCF Selection Indication' from the AMF. - Clarify that the SMF receives the redirection indicator and the PCF ID from the PCF.

Comment:

Revision of S2-2108788r02. Approved.

Discussion and conclusion:

-

Status:

Agreed.

## KI#7 configured NSSAI

TD S2-2108310 (CR) 23.501 CR3359 (Rel-17, 'F'): Alignment with RAN conclusion on providing Configured NSSAI to the RAN. (Source: Convida Wireless LLC, Nokia, Nokia Shanghai Bell, Orange, Verizon).
Document for: Approval.
Abstract: Summary of change: This CR updates the specification to allow the AMF the option of providing the RAN with the Configured NSSAI and an RFSP Index associated with the Configured NSSAI. This CR also provides some needed editorials.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Jinguo(ZTE) proposed to note this CR
Peter Hedman (Ericsson) proposed to note this CR
Dieter (Deutsche Telekom) proposes to note this CR.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108604 (CR) 23.501 CR3400 (Rel-17, 'F'): Removal of Editor's Note on Configured NSSAI. (Source: ZTE, Huawei, Samsung, Ericsson).
Document for: Approval.
Abstract: Summary of change: Editors Note is removed.

Comment:

Approved.

Discussion and conclusion:

-

e-mail discussion:

Alessio (Nokia) comments this is still discussed offline so let's hold approval till we take one last round of discussions following the SoH
==== Revisions Deadline ====
Jinguo(ZTE) suggest to approve the original version.
==== Comments Deadline ====.

Status:

Agreed.

TD S2-2108893 (DISCUSSION) On providing Configured NSSAI to the RAN. (Source: Nokia, Nokia Shanghai Bell, Convida Wireless).
Document for: Agreement.
Abstract: On providing Configured NSSAI to the RAN.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

# 8.5 Enhanced support of Industrial IoT - TSC/URLLC enhancements (IIoT)

This agenda item was convened by Puneet Jain (Intel).

## LSs

TD S2-2108276 (LS IN) Reply LS on more efficient PMIC/UMIC signalling exchange for time synchronization. (Source: CT WG1 (C1-216069)).
Document for: Action.
Abstract: CT WG1 thanks SA WG2 for their LS on more efficient PMIC/UMIC signalling exchange for time synchronization. Specific to the SA WG2 questions in C1-215544/S2-2106767 CT WG1 would like to provide the following feedback: Q1: SA WG2 would like to ask CT WG1 to consider whether such a solution is possible and provide feedback. Answer: CT WG1 has agreed in the attached CR to TS 24.539 (see C1-216245) on enhancements to Port management and User plane node management operations for supporting read parameter, and subscribe-notify parameter using only a subset of parameter value. Q2: Specific to the Write operation, when TSN AF (or TSCTSF) is sending UMIC or PMIC to a TT containing only partial PTP instance information, SA WG2 could not clearly understand the consequences from such operation. Can CT WG1 inform SA WG2 what happens in terms of the status of the PTP information available in the TT that is not included in the UMIC or PMIC? Answer: CT WG1 understanding is that the PTP instance list port parameter and DS-TT port time synchronization information list user plane node parameter already supports setting of individual PTP instance parameters without changing PTP instance parameters stored at the TT previous to the operation and not included in the UMIC or PMIC. Action: CT WG1 asks SA WG2 to take the above feedback into account.

Comment:

Postponed.

Discussion and conclusion:

-

Status:

Postponed.

TD S2-2108288 (LS IN) LS from CT WG4: Reply LS on UPF reporting for redundant transmission on transport layer. (Source: CT WG4 (C4-215505)).
Document for: Information.
Abstract: CT WG4 would like to thank SA WG5 for their LS on UPF reporting for redundant transmission on transport layer. CT WG4 can provide the following feedback on the question raised by SA WG5: Can the SMF be aware on whether the usage reported by UPF is with or without redundant counts when redundant transmission at transport layer is used? Answer: Like for the case of redundant transmission on N3/N9 interfaces specified in clause 5.2.2.3.3 of TS 29.244, the UPF does not count redundant packets in Usage Reports sent to the SMF when redundant transmission is used on transport layer. CT WG4 will clarify so in TS 29.244 at the next CT WG4 meeting.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Sang-Jun (Samsung) proposes to move it to 7.10 5G_URLLC or to note the LS since no action is required to SA2.
==== Revisions Deadline ====
Qianghua (Huawei) agrees with Samsung
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108292 (LS IN) LS from IEEE: RE: LS on Correction Field update for Transparent Clock. (Source: IEEE (Reply to 3GPP liaison correction field)).
Document for: Information.
Abstract: Methods to limit the error of Transparent Clock corrections, as specified in IEEE 1588-2019, include: 1. Use of an accurate and stable oscillator in the timestamping clock of the Transparent Clock, such that the worst-case residence time results in a sufficiently small error. 2. Syntonizing to the frequency of the Grandmaster clock. Note that it is not necessary to steer the timestamping clock oscillator to this frequency. Instead, an estimate of the current frequency offset can be maintained and used to correct residence time calculations. 3. The Cumulative Rate Ratio feature of PTP can be used. Note that this requires that all PTP nodes in the path from the Grandmaster support this feature. Method 3 requires the use of peer-delay. Methods 1 and 2 will work for either peer-delay or end-to-end networks. There might be other methods not listed. The use case of a network acting as a distributed Transparent Clock has not been studied in detail by the IEEE 1588 working group. If additional mechanisms are needed for this use case, participants in 3GPP are welcome to bring technical contributions to the IEEE 1588 working group. We recommend a careful error analysis to make sure that the requirements of any use case can be met. We look forward to continued communication and coordination with 3GPP.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Chunshan(Tencent) has provided related CR S2-2108539 based on this LS .
Devaki (Nokia) proposes to note the LS.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

## CRs

TD S2-2108308 (CR) 23.501 CR3357 (Rel-17, 'F'): Deletion of selected enrties in UMIC/PMIC data structures. (Source: Intel, NTT DOCOMO).
Document for: Approval.
Abstract: Summary of change: Clarifies the use of PMIC and UMIC for the deletion of selected entries in the UMIC/PMIC data structures that are lists of variable size.

Comment:

r02 agreed. Revised to S2-2109278.

Discussion and conclusion:

-

e-mail discussion:

Saso (Intel) provides r01
Saso (Intel) provides r02
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109278.

TD S2-2109278 (CR) 23.501 CR3357R1 (Rel-17, 'F'): Deletion of selected enrties in UMIC/PMIC data structures. (Source: Intel, NTT DOCOMO).
Document for: Approval.
Abstract: Summary of change: Clarifies the use of PMIC and UMIC for the deletion of selected entries in the UMIC/PMIC data structures that are lists of variable size.

Comment:

Revision of S2-2108308r02. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108309 (CR) 23.501 CR3358 (Rel-17, 'F'): Clarification on Static Filtering Entries. (Source: Intel, NTT DOCOMO, Ericsson).
Document for: Approval.
Abstract: Summary of change: 1) It is clarified that the SFE can indicate that an ingress frame matching the (MAC address, VID) pair can be forwarded to more than one egress port. 2) The references to 'uplink traffic' in Table 5.28.3.1-2 NOTE 3 are removed. The DS-TT egress port is added besides the existing NW-TT port.

Comment:

r05 agreed. Revised to S2-2109279.

Discussion and conclusion:

-

e-mail discussion:

Devaki (Nokia) provides r01.
Qianghua (Huawei) object r00, provides r02
Saso (Intel) objects r02; provides r03 on top of r01.
Qianghua (Huawei) provides r04, object r03
Saso (Intel) provides r05 on top of r04.
Zhendong (ZTE): prefer r04
Saso (Intel) replies to Zhendong that r05 is better because it lifts unnecessary restrictions for UPF implementations.
==== Revisions Deadline ====
Qianghua (Huawei) objects r00, r01, r03 given the reasons expressed before, OK with the other revisions (prefer r04)
Zhendong (ZTE): also prefer r04
Jari (NTT DOCOMO) prefers r05. r04 is not consistent.
Saso (Intel) prefers r05. Agrees with Jari that r04 is inconsistent.
==== Comments Deadline ====.

Status:

Revised to S2-2109279.

TD S2-2109279 (CR) 23.501 CR3358R1 (Rel-17, 'F'): Clarification on Static Filtering Entries. (Source: Intel, NTT DOCOMO, Ericsson).
Document for: Approval.
Abstract: Summary of change: It is clarified that the SFE can indicate that an ingress frame matching the (MAC address, VID) pair can be forwarded to more than one egress port. Reworded NOTE4 in clause 5.8.2.5.3 by replacing 'routing in all directions' with 'forwarding of Ethernet frames to one or more egress ports'.

Comment:

Revision of S2-2108309r05. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108315 (CR) 23.501 CR3242R2 (Rel-17, 'F'): Improved PTP instance configuration management. (Source: Intel, NTT DOCOMO, Ericsson).
Document for: Approval.
Abstract: Summary of change: It is clarified that the creation of PTP instance in DS-TT or NW-TT is achieved by using the 'Set parameter' operation as described in TS 24.539. For deletion of PTP Instance the text also refers to TS 24.539. Rev2: Change the 'Upon detection of a DS-TT port' to 'To add a DS-TT port into a PTP instance in 5GS', for a condition to create a new PTP instance in DS-TT. Remove the cases 'PTP instance is not available in 5GS' and 'PTP instance is already available in 5GS'.

Comment:

Revision of (Agreed) S2-2108126 from S2#147E. r02 agreed. Revised to S2-2109280.

Discussion and conclusion:

-

e-mail discussion:

Devaki (Nokia) supports the CR, happy to cosign. Minor correction is needed in the annex.
Saso (Intel) provides r01
Sebastian (Qualcomm) provides r02
Saso (Intel) is OK with r02.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109280.

TD S2-2109280 (CR) 23.501 CR3242R3 (Rel-17, 'F'): Improved PTP instance configuration management. (Source: Intel, NTT DOCOMO, Ericsson, Nokia).
Document for: Approval.
Abstract: Summary of change: It is clarified that the creation of PTP instance in DS-TT or NW-TT is achieved by using the 'Set parameter' operation as described in TS 24.539. For deletion of PTP Instance the text also refers to TS 24.539. Rev2: Change the 'Upon detection of a DS-TT port' to 'To add a DS-TT port into a PTP instance in 5GS', for a condition to create a new PTP instance in DS-TT. Remove the cases 'PTP instance is not available in 5GS' and 'PTP instance is already available in 5GS'.

Comment:

Revision of S2-2108315r02. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108426 (CR) 23.502 CR3131R1 (Rel-17, 'F'): Updating the description of UE-DS-TT Residence Time delivery to the PCF. (Source: Ericsson, [Nokia, Nokia Shanghai Bell, CATT]).
Document for: Approval.
Abstract: Summary of change: 1) The description of the procedures for set up/update of AF session with required QoS is corrected to reflect that the AF request can use either Option 1 or Option 2 (exclusive, not combinational). Option 1: The AF may provide (1) QoS reference, (2) (optional) Alternative Service Requirements that consist of one or more QoS reference parameters in a prioritized order, and they may be provided in addition to the QoS Reference, and (3) a subset of individual QoS parameters that constitute the TSC Assistance Container information, specifically, flow direction, Burst Size (optional), Burst Arrival Time (optional) at UE (uplink) or UPF (downlink), Periodicity (optional), Time domain (optional), Survival Time (optional). Option 2: Instead of QoS Reference and (optional) Alternative Service Requirements, the AF may provide the individual QoS parameters that can include Requested 5GS delay (optional), priority (optional), Requested GFBR, Requested MFBR, Burst Size (optional) and TSC Assistance Container information (specified when describing Option 1). 2) We clarify that Alternative Service Requirements can be provided only when the AF request a specific QoS via a QoS Reference (Option 1), i.e., Alternative Service Requirements can not be used when the AF request is done using the Individual QoS parameters (Option 2). 3) We provide the reference to clause 6.1.3.22 of TS 23.503 to clearly specify which QoS reference parameters may be included in the Alternative Service Requirements as there were many interpretations/discussions about that. The QoS reference parameters in the Alternative Service Requirements indicates the preference of the QoS requirement with which the service can operate (per 6.1.3.22 of TS 23.503), and these 'QoS Reference parameters' are subsequently used to establish Alternative QoS Profile(s) that is/are represented a combination of PDB, PER and GFBR to which the application traffic is able to adapt (as described in clause 5.7.1.2a of TS 23.501). So, the QoS reference parameters lead to those Alternative QoS Profile's parameters. 4) The ENs on whether and how the PCF uses the priority values specfied by an AF other than a TSN-AF is resolved. The AF requested priority may be used by the PCF to set priority of a QoS Flow as specfied in 23.501 clause 5.7.1.2a.

Comment:

Revision of (revised and approved) S2-2107132 from S2#147E. Merged into S2-2109285.

Discussion and conclusion:

-

e-mail discussion:

Devaki (Nokia) proposes to merge this paper with 8478 as that address the discovery part, also this paper seems to still assume the old discovery (not aligned with SoH).
Gy×rgy (Ericsson) proposes r01.
Qianghua (Huawei) provides r02
Jari (NTT DOCOMO) comments
Devaki (Nokia) provides r03 (although we still prefer 8478).
Qianghua (Huawei) comments for r03
Zhendong (ZTE): provides comments and prefer use 8478 as baseline
Gy×rgy (Ericsson) merges the CR into 8478.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Merged into S2-2109285.

TD S2-2108427 (CR) 23.503 CR0674 (Rel-17, 'F'): Parameter handling for an AF requesting a specific QoS. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: 1) In its request, the AF may provide either QoS Reference or Individual QoS parameters (i.e., exclusive options) 2) Alternative Service Requirements can be provided only when the AF request a specific QoS via a QoS Reference 3) Alternative Service Requirements contain one or more QoS Rreference parameters in a prioritized order indicating the preference of the QoS requirements with which the service can operate. (They do not include a subset of individual QoS parameters (in addition or separately) to QoS Reference parameters).

Comment:

Merged into S2-2109286.

Discussion and conclusion:

-

e-mail discussion:

Chunshan(Tencent) provides r01.
Jari (NTT DOCOMO) question for clarification
Shabnam (Ericsson) provides r02.
Mirko (Huawei) comments.
Devaki (Nokia) proposes to consider this as merged with a revision of 8479 due to many overlapping changes (although they are quite aligned technically overall).
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Merged into S2-2109286.

TD S2-2108428 (CR) 23.501 CR3370 (Rel-17, 'F'): Completing funtional description for TSC. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: - Add a new clause describing the support for TSC. - Address imprecisions in clause 6.1.3.22 regarding TSN AF and the general case of TSC. - Move a note in clause 6.1.3.23.

Comment:

Confirm Specification Number - CR states 23.503! Merged into S2-2109296.

Discussion and conclusion:

-

e-mail discussion:

Devaki (Nokia) provides r01.
Mirko (Huawei) comments and suggests to use S2-2108739 for documenting the support of time sensitive communication.
Shabnam (Ericsson) I would like to keep this separate from the CR you mention at this time. Let's see where we end up.
Shabnam (Ericsson) provides r02 removing changes in clause 6.1.3.22 and reinstated the model.
Devaki (Nokia) can live without the CR but cannot accept the model ( as it is not defined nor necessary for regular IP PDU Sessions/TSC services.
Shabnam (Ericsson) comments and provides r03, Maurice as the CR was taken on wrong spec number, if agreed I will need a new CR# on 23.503.
==== Revisions Deadline ====
Mirko (Huawei) proposes to note this CR and to use S2-2108739r01 for documenting the support of time sensitive communication.
Shabnam (Ericsson) considers this CR to be merged into 8739 and requests cosigning 8739.
==== Comments Deadline ====.

Status:

Merged into S2-2109296.

TD S2-2108429 (CR) 23.502 CR3235 (Rel-17, 'F'): Adding Trusted AF in Time Synchronization procedures. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: - Add that a trusted AF may invoke services directly to the TSCTSF in Time Synchronization procedures. - Correct reference mistake to the Table about Time Synchronization capability event parameters.

Comment:

r01 agreed. Revised to S2-2109281.

Discussion and conclusion:

-

e-mail discussion:

Zhendong (ZTE): provides r01
Devaki (Nokia) comments.
Shabnam (Ericsson) responds
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109281.

TD S2-2109281 (CR) 23.502 CR3235R1 (Rel-17, 'F'): Adding Trusted AF in Time Synchronization procedures. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: - Add that a trusted AF may invoke services directly to the TSCTSF in Time Synchronization procedures. - Correct reference mistake to the Table about Time Synchronization capability event parameters.

Comment:

Revision of S2-2108429r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108434 (CR) 23.503 CR0660R2 (Rel-17, 'F'): Policy for Handling of PMIC exchange with UE(s) in idle mode. (Source: Samsung[, Huawei, Ericsson]).
Document for: Approval.
Abstract: Summary of change: Remove TSCTSF from the clause 6.1.3.23 (undo changes), since it does not apply for TSN. Add new clause on support for TSC. Revise the text in clause 6.1.3.22 regarding use of TSN AF. The statement related to the TSC Assistance Container is corrected by referring to the new clause. - TSCTSF or TSN AF may indicate that the AMF is allowed to use ATC when it sends PMIC. Furthermore, a note is moved to its corresponding paragraph.

Comment:

Revision of (Agreed) S2-2108136 from S2#147E. Merged into S2-2109296.

Discussion and conclusion:

-

e-mail discussion:

Devaki (Nokia) proposes to merge this with 8428.
Sebastian (Qualcomm) objects to the CR
Shabnam (Ericsson) comments that we need to also withdraw the CR version that was approved last meeting, contents are now in 8428.
Zhendong (ZTE): proposes to merge this with 8428/8739
Sang-Jun (Samsung) agrees that the CR is merged to 8428.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Merged into S2-2109296.

TD S2-2108475 (CR) 23.501 CR3375 (Rel-17, 'F'): 23.501: TSCTSF Discovery and Selection. (Source: Nokia, Nokia Shangai Bell, Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Clarify that a single TSCTSF instance is associated to a given DNN/S-NSSAI. TSC TSF discovery section - to clarify that the GPSI, SUPI, Internal Group ID can also be used for discovery and selection. Add GPSI - in case the NF consumer uses GPSI for TSC TSF discovery and selection. Add SUPI or Internal Group ID - in case the NF consumer is only aware of the SUPI or Internal Group ID, it uses SUPI or Internal Group ID for TSC TSF discovery and selection. These parameters are in principle available already with NRF framework thus it should be straight forward to use them also for TSC TSF discovery selection.

Comment:

Revised to S2-2108961.

Discussion and conclusion:

-

Status:

Revised to S2-2108961.

TD S2-2108961 (CR) 23.501 CR3375R1 (Rel-17, 'F'): 23.501: TSCTSF Discovery and Selection. (Source: Nokia, Nokia Shangai Bell, Huawei, HiSilicon, Ericsson).
Document for: Approval.
Abstract: Summary of change: Clarify that a single TSCTSF instance is associated to a given DNN/S-NSSAI. TSC TSF discovery section - to clarify that the GPSI, SUPI, Internal Group ID can also be used for discovery and selection. Add GPSI - in case the NF consumer uses GPSI for TSC TSF discovery and selection. Add SUPI or Internal Group ID - in case the NF consumer is only aware of the SUPI or Internal Group ID, it uses SUPI or Internal Group ID for TSC TSF discovery and selection. These parameters are in principle available already with NRF framework thus it should be straight forward to use them also for TSC TSF discovery selection.

Comment:

Revision of S2-2108475. r05 agreed. Revised to S2-2109282.

Discussion and conclusion:

-

e-mail discussion:

Jari (NTT DOCOMO) objects to the CR
Qianghua (Huawei) replies
Jari (NTT DOCOMO) responds
Devaki (Nokia) replies. Based on the SoH outcome and recommended way forward, hope we can constructively progress.
Jari (NTT DOCOMO) provides r01
Gy×rgy (Ericsson) comments.
Gy×rgy (Ericsson) responds
Devaki (Nokia) thanks for the constructive progress and the revision, provides r03.
Jari (NTT DOCOMO) comments
Jari (NTT DOCOMO) provides r04
Zhendong (ZTE): provides r05
Zhendong (ZTE): provides response
Devaki (Nokia) comments.
Zhendong (ZTE): agree with devaki
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109282.

TD S2-2109282 (CR) 23.501 CR3375R2 (Rel-17, 'F'): 23.501: TSCTSF Discovery and Selection. (Source: Nokia, Nokia Shangai Bell, Huawei, HiSilicon, Ericsson, ZTE).
Document for: Approval.
Abstract: Summary of change: Clarify that a single TSCTSF instance is associated to a given DNN/S-NSSAI.Clarify that the GPSI, SUPI, Internal Group ID can also be used for discovery and selection. Add GPSI - in case the NF consumer uses GPSI for TSCTSF discovery and selection. Add SUPI or Internal Group ID - in case the NF consumer is only aware of the SUPI or Internal Group ID, it uses SUPI or Internal Group ID for TSCTSF discovery and selection. These parameters are in principle available already with NRF framework thus it should be straight forward to use them also for TSC TSF discovery selection.

Comment:

Revision of S2-2108961r05. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108476 (CR) 23.502 CR3246 (Rel-17, 'F'): 23.502: TSCTSF Discovery and Selection. (Source: Nokia, Nokia Shanghai Bell, Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: - (Option 2) Remove the UDR based TSCTSF instance discovery and selection for AF session with required QoS procedure and Time Synchronization service procedure - Updates for TSCTSF instance discovery for SMF initiated SM Policy Association Modification procdure, i.e., remove the repeated text and refer to clause 6.3.24 of TS 23.501 [2] - udpate the Npcf_Policy Authorization service, Nnef_AFsessionWithQoS and Ntsctsf_QoSandTSCAssistance.

Comment:

r05 agreed. Revised to S2-2109283.

Discussion and conclusion:

-

e-mail discussion:

Jari (NTT DOCOMO) questions for clarification
Gy×rgy (Ericsson) comments.
Jari (NTT DOCOMO) responds to Gy×rgy
Qianghua (Huawei) provides r01
Jari (NTT DOCOMO) comments, r01 does not address my previous questions
Jari (NTT DOCOMO) proposes to merge with S2-2108477
GY×rgy (Ericsson) responds to Jari.
Devaki (Nokia) provides r02, comments that this CR cannot be marked as merged with 8477 as they are addressing completely different sections:
8476r01: 4.16.5.1, 5.2.5.1, 5.2.5.3.1, 5.2.5.3.3, 5.2.6.9.2, 5.2.6.9.5, 5.2.27.3.2, 5.2.27.3.3; 8477r01: 4.15.9.2, 4.16.5.1
Devaki (Nokia) provides r03.
Devaki (Nokia) provides r04.
Jari (NTT DOCOMO) provides r05.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109283.

TD S2-2109283 (CR) 23.502 CR3246R1 (Rel-17, 'F'): 23.502: TSCTSF Discovery and Selection. (Source: Nokia, Nokia Shanghai Bell, Huawei, HiSilicon, Ericsson).
Document for: Approval.
Abstract: Summary of change: Remove the UDR based TSCTSF instance discovery and selection for SM policy association procedure.

Comment:

Revision of S2-2108476r05. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108477 (CR) 23.502 CR3247 (Rel-17, 'F'): 23.502: Time Sync exposure procedure. (Source: Nokia, Nokia Shanghai Bell, Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Updating the figure 4.15.9.2 to correct the service names with the ones in the procedure description and service operation (Nnef_TimeSynchronization_CapsSubscribe' vs 'Nnef_TimeSynchronizationCaps_Subscribe') Also, fix the use of UDR.

Comment:

r05 agreed. Revised to S2-2109284.

Discussion and conclusion:

-

e-mail discussion:

Jari (NTT DOCOMO) objects to the CR
Devaki (Nokia) provides r01 based on comments received. Based on SoH outcome for TSCTSF discovery, hope we can constructively move forward by using this as the basis and providing revisions.
Jari (NTT DOCOMO) comments
Devaki (Nokia) provides r03.
Jari (NTT DOCOMO) objects all revisions
Gy×rgy (Ericsson) provides r04.
Gy×rgy (Ericsson) provides r05
Devaki (Nokia) replies.
Gy×rgy (Ericsson) responds.
==== Revisions Deadline ====
Sebastian (Qualcomm) objects to r05; would be ok with r05 if 'If time synchronization capability information from the DS-TT or NW-TT is available at the PCF, the PCF reports the capabilities to the TSCTSF invoking Npcf_PolicyAuthorization_Notify. ' can be changed to 'If PMIC/UMIC information from the DS-TT or NW-TT is available at the PCF, the PCF reports it to the TSCTSF invoking Npcf_PolicyAuthorization_Notify. ''
Devaki (Nokia) agrees with Sebastian's proposed update to r05.
Gy×rgy (Ericsson) OK with Sebastian's proposed update to r05.
==== Comments Deadline ====
Qianghua (Huawei) OK with Sebastian's proposal.

Status:

Revised to S2-2109284.

TD S2-2109284 (CR) 23.502 CR3247R1 (Rel-17, 'F'): 23.502: Time Sync exposure procedure. (Source: Nokia, Nokia Shanghai Bell, Huawei, HiSilicon, Ericsson).
Document for: Approval.
Abstract: Summary of change: Updating the figure 4.15.9.2 to correct the service names with the ones in the procedure description and service operation (Nnef_TimeSynchronization_CapsSubscribe' vs 'Nnef_TimeSynchronizationCaps_Subscribe') Also, fix the use of UDR.

Comment:

Revision of S2-2108477r05. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108478 (CR) 23.502 CR3248 (Rel-17, 'F'): Fixes for AF session with required QoS update procedure. (Source: Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: 1 - UDR storage of TSCTSF address for TSC QoS is eliminated. It is assumed that in TSCTSF discovery & selection (or local configuration) there is only one TSCTSF or TSCTSF set per UE/S-NSSAI/DNN. Hence the same TSCTSF (or set) is selected when the PCF sends 5GS Bridge Information (with UE residence time) to the TSCTSF and when an NEF sends an AF request for QoS. This significantly simplifies the QoS procedures and resolves the issue of always selecting a correct UDR (where a TSCTSF address is stored). 3 - A QoS Reference may or may not be specified with Individual QoS Parameters and Alternative QoS Related Parameters in the AF request. When a QoS Reference is provided, AF specified QoS Parameters or Alternative QoS Related Parameters over-ride the corresponding parameters associated with the QoS reference (which may be considered the default parameters). If no QoS reference is provided, then the AF must specify a complete set of Individual QoS Parameters / Alternative QoS Related Parameters to specify what it wants. 4 - In step 1 (AF request), a reference is corrected. The currently referenced clause 5.7.1.2a of TS23.501 refers to Alternative QoS Profies (provided by the SMF to the RAN) not Alternative QoS Related parameters provided by the AF to the PCF. Instead a reference is given to 23.503 clause 6.1.3.22. Clarifying text is added at the end of step 1 with the 23.501 reference. 5 - Step 3 should only be executed when individual parameters for Alt QoS (Alternative QoS Related parameter set(s)) are not specified. A condition is added to the beginning of step 3 and a reference is added to point to 23.503 clause 6.1.3.22 6 - In steps 3a and 3b, the Alternative QoS Related parameters (ie: the individual parameters specified by the AF for a Alternative QoS Reference) are also part of the Alternative Service Requirements sent to the TSCTSF (3a) and PCF (3b). Note that the Alternative QoS Related Parameters (which are sent from AF to the PCF) and specify individual QoS Parameters for Alt QoS references (as per 23.503 clause 6.1.3.22) are not the same as the Alternative QoS parameter set(s) in the PCC rules, which are unchanged from Rel. 16. 7 - In step 4 text refering to Alternative QoS Related parameter sets is removed and in step 4a, the PCF may use the Alternative QoS Related parameter sets (that are part of the Alternative Service Requirements and originated at the AF) to determine the Alternative QoS parameter set(s) in the PCC rules. Note there is no change to the contents of the PCC rules - they already contain Alternative QoS parameter Set(s). 8 - The ENs on whether and how the PCF uses priority values specfied by an AF other than a TSN-AF is resolved. The AF requested priority may be used by the PCF to set priority of a QoS Flow as specfied in 23.501 clause 5.7.1.2a. 9 - Requested Priority and Requested PER parameters are added to Nnef_AFsessionWithQoS and Ntsctsf_QoSandTSCAssistance service operations to be consistent with text in clause 4.15.6.6 and 4.15.6.6a.

Comment:

r05 agreed. Revised to S2-2109285, merging S2-2108426 and S2-2108819.

Discussion and conclusion:

-

e-mail discussion:

Gy×rgy (Ericsson) comments.
Devaki (Nokia) provides r01 addressing the comments.
Gy×rgy (Ericsson) responds.
Jari (NTT DOCOMO) objects all revisions
Gy×rgy (Ericsson) provides r02
Qianghua (Huawei) provides r03
Jari (NTT DOCOMO) comments
Gy×rgy (Ericsson) provides r04.
Gy×rgy (Ericsson) provides r05 and comments.
Jari (NTT DOCOMO) proposes to postpone
Devaki (Nokia) comments.
Jari (NTT DOCOMO) comments.
Zhendong (ZTE): proposes to agree in this meeitng
==== Revisions Deadline ====
Qianghua (Huawei) also prefers to make some progress, and we are open to make other additional changes if possible next meeting
Devaki (Nokia) proposes updates on top of r05 to address Jari's concern and discussion with Gyorgy regarding Alt. QoS.
Uploaded as r07 in DRAFTS folder. Changes listed below explicitly
Qianghua (Huawei) OK with r07
Gy×rgy (Ericsson) provides r08 in the drafts folder to correct some minor aspects.
Devaki (Nokia) is fine with r08 to move forward.
==== Comments Deadline ====
Devaki (Nokia) requests r08 to be marked for CC#2 (changes on top of r05 stated below).
Devaki (Nokia) requests that this is brought up for CC#2 to approve r08 (= agreed changes on top of r05).

Status:

Revised to S2-2109285, merging S2-2108426 and S2-2108819.

TD S2-2109285 (CR) 23.502 CR3248R1 (Rel-17, 'F'): Fixes for AF session with required QoS update procedure. (Source: Nokia, Nokia Shanghai Bell, Huawei, Ericsson, ZTE).
Document for: Approval.
Abstract: Summary of change: 1 - UDR storage of TSCTSF address for TSC QoS is eliminated. It is assumed that in TSCTSF discovery & selection (or local configuration) there is only one TSCTSF or TSCTSF set per UE/S-NSSAI/DNN. Hence the same TSCTSF (or set) is selected when the PCF sends 5GS Bridge Information (with UE residence time) to the TSCTSF and when an NEF sends an AF request for QoS. This significantly simplifies the QoS procedures and resolves the issue of always selecting a correct UDR (where a TSCTSF address is stored). 3 - A QoS Reference may not be specified with Individual QoS Parameters and Alternative QoS Related Parameters in the AF request. 4 - In step 1 (AF request), a reference is corrected. The currently referenced clause 5.7.1.2a of TS23.501 refers to Alternative QoS Profies (provided by the SMF to the RAN) not Alternative QoS Related parameters provided by the AF to the PCF. Instead a reference is given to 23.503 clause 6.1.3.22. Clarifying text is added at the end of step 1 with the 23.501 reference. 5 - Step 3 should only be executed when individual parameters for Alt QoS (Alternative QoS Related parameter set(s)) are not specified. A condition is added to the beginning of step 3 and a reference is added to point to 23.503 clause 6.1.3.22 6 - In steps 3a and 3b, the Alternative QoS Related parameters (ie: the individual parameters specified by the AF for a Alternative QoS Reference) are also part of the Alternative Service Requirements sent to the TSCTSF (3a) and PCF (3b). Note that the Alternative QoS Related Parameters (which are sent from AF to the PCF) and specify individual QoS Parameters for Alt QoS references (as per 23.503 clause 6.1.3.22) are not the same as the Alternative QoS parameter set(s) in the PCC rules, which are unchanged from Rel. 16. 7 - In step 4 text refering to Alternative QoS Related parameter sets is removed and in step 4a, the PCF may use the Alternative QoS Related parameter sets (that are part of the Alternative Service Requirements and originated at the AF) to determine the Alternative QoS parameter set(s) in the PCC rules. Note there is no change to the contents of the PCC rules - they already contain Alternative QoS parameter Set(s). 8 - The ENs on whether and how the PCF uses priority values specfied by an AF other than a TSN-AF is resolved. The AF requested priority may be used by the PCF to set priority of a QoS Flow as specfied in 23.501 clause 5.7.1.2a. 9 - Requested Priority is added to Nnef_AFsessionWithQoS and Ntsctsf_QoSandTSCAssistance service operations to be consistent with text in clause 4.15.6.6 and 4.15.6.6a The CR also includes aspects from CR#3131 (S2-2108426) merged in.

Comment:

Revision of S2-2108478r05, merging S2-2108426 and S2-2108819. CC#2: Approved.

Discussion and conclusion:

CC#2: This was confirmed as approved.

Status:

Agreed.

TD S2-2108479 (CR) 23.503 CR0675 (Rel-17, 'F'): Fixes for AF session with required QoS update procedure. (Source: Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: 23.503 clause 6.1.3.22 is updated for consistency with 23.501 and 23.502 and to allow an AF to specify individual QoS Related Parameters.

Comment:

r04 agreed. Revised to S2-2109286, merging S2-2108427 and S2-2108740.

Discussion and conclusion:

-

e-mail discussion:

Gy×rgy (Ericsson) comments.
Devaki (Nokia) provides r01.
Devaki (Nokia) provides r02 (merging changes from 8427).
Gy×rgy (Ericsson) provides r03.
Gy×rgy (Ericsson) provides r04.
==== Revisions Deadline ====
Devaki (Nokia) proposes to move forward with r02 as r03 removes critical aspects (i.e. AF can no longer provide individual QoS parameters that can be used to determine Alt. QoS profile).
Gy×rgy (Ericsson) cannot accept r00-r02.
Devaki (Nokia) cannot accept r03, r04.
Gy×rgy (Ericsson) proposes to go with r04 (objects to r00-r02). Clarifies that r04 does not include the controversial aspects.
Devaki (Nokia) can accept r04 based on updates discussed also for TS 23.502 in r07.
Zhendong (ZTE): is fine with r04
==== Comments Deadline ====.

Status:

Revised to S2-2109286, merging S2-2108427 and S2-2108740.

TD S2-2109286 (CR) 23.503 CR0675R1 (Rel-17, 'F'): Fixes for AF session with required QoS update procedure. (Source: Nokia, Nokia Shanghai Bell, Ericsson, ZTE).
Document for: Approval.
Abstract: Summary of change: 23.503 clause 6.1.3.22 is updated for consistency with 23.501 and 23.502 and to allow an AF to specify individual QoS Related Parameters Also merged in aspect from CR#0674 (S2-2108427).

Comment:

Revision of S2-2108479r04, merging S2-2108427 and S2-2108740. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108539 (CR) 23.501 CR3386 (Rel-17, 'F'): Update the correction field for the end-to-end Transparent Clock. (Source: Tencent, Tencent Cloud, CATT).
Document for: Approval.
Abstract: Summary of change: If the 5GS operates as a end-to-end Transparent Clock, the residence time (TSe - TSi) is the time based on the 5GS time and is converted into the PTP GM time based on the factor as specified in Equation (6) of clause 12.2.2 in IEEE Std 1588-2019, and the calculated residence time expressed in PTP GM is added to the correction field. 'Pdelay_Resp_Follow_UP' is changed to 'Pdelay_Resp_Follow_Up'.

Comment:

r07 agreed. Revised to S2-2109287.

Discussion and conclusion:

-

e-mail discussion:

Devaki (Nokia) provides r01.
Jari (NTT DOCOMO) question for clarification
Chunshan (Tencent) question for clarification
Sebastian (Qualcomm) comments
Chunshan(Tencent) responses to Sebastian (Qualcomm).
Chunshan(Tencent) provides r02.
Chunshan(Tencent) provides r03.
Shabnam (Ericsson) provides comments and have concerns as introduces serious issues, I provide r04 but may need to further update.
Chunshan(Tencent) responses to Shabnam (Ericsson).
Chunshan(Tencent) provides r05.
Shabnam (Ericsson) provides r06, based on r04 and objects to all other revisions
Chunshan(Tencent) provides r07.
==== Revisions Deadline ====
Devaki (Nokia) comments that the cover sheet shall clarify CR#3260 should not be approved by SA plenary.
Chunshan (Tencent) responses to Devaki (Nokia) that the content of the CR#3260 is not included in the r06/r07 anymore.
==== Comments Deadline ====.

Status:

Revised to S2-2109287.

TD S2-2109287 (CR) 23.501 CR3386R1 (Rel-17, 'F'): Update the correction field for the end-to-end Transparent Clock. (Source: Tencent, Tencent Cloud, CATT).
Document for: Approval.
Abstract: Summary of change: If the 5GS operates as a end-to-end Transparent Clock, the residence time (TSe - TSi) is the time based on the 5GS time and is converted into the PTP GM time based on the factor as specified in Equation (6) of clause 12.2.2 in IEEE Std 1588-2019 if needed, and the calculated residence time is added to the correction field.

Comment:

Revision of S2-2108539r07. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108540 (CR) 23.501 CR3286R1 (Rel-17, 'F'): Time Synchronization of the 5GS as IEEE 1588 Boundary Clock. (Source: Tencent, Tencent Cloud, CATT).
Document for: Approval.
Abstract: Summary of change: When the GM is external, the operation of 5GS as Boundary Clock assumes that profiles that are supported by the 5GS allows the exemption specified in clauses 9.5.9 and 9.5.10 of IEEE Std 1588 [126] where the originTimestamp (or preciseOriginTimestamp in case of two-step operation) is updated to the sum of the received originTimestamp (or preciseOriginTimestamp in case of two-step operation), the received correction field of Sync and Follow_Up (in case of two-step operation), residence time expressed in PTP GM time and link delay expressed in PTP GM time. After the originTimestamp (or preciseOriginTimestamp in case of two-step operation) is updated, the correction field of Sync and Follow_Up (in case of two-step operation) can be set to zero. After the originTimestamp (or preciseOriginTimestamp in case of two-step operation) is updated, the corretionField of Sync is set to zero. As described in clause 5.27.1.2.2, the originTimestamp (or preciseOriginTimestamp in case of two-step operation) is updated with the correction field(s), 5GS residence time and link delay. A mathematically and functionally equivalent operation is specified for the time-aware system in clause 11.1.3 of IEEE Std 802.1AS [104]. If the 5GS operates as a Boundary Clock and the ingress TT is DS-TT, the UPF/NW-TT then regenerates the Sync and Follow_Up (for two-step operation) messages with the updated originTimestamp (or preciseOriginTimestamp) as described by the exemption in clause 5.27.1.1 based on the received Sync and Follow_Up messages for the PTP ports in Master state in NW-TT and DS-TT(s) within this PTP instance. The NW-TT/UPF forwards the regenerated Sync and Follow_Up messages to the PDU session(s) related to the Master ports in the DS-TT(s) within this PTP instance. Due to the exemption described in clause 5.27.1.1, when the PTP instance in 5GS is configured to operate as a Boundary Clock, the 5GS does not need to synchronize its Local PTP Clock to the external PTP grandmaster. The ingress TT in 5GS measures the link delay expressed in PTP GM time and updatethe correction field with the measured link delay expressed in PTP GM time. The egress TT converts the 5GS residence time into the residence time expressed in PTP GM time and updates the originTimestamp (or preciseOriginTimestamp) to the sume of the received originTimestamp (or preciseOriginTimestamp), the corrected field which has been updated by the ingress TT and the residence time expressed in PTP GM time. The egress TT sets the corrected field to zero for the Sync and Follow_Up message (for two-step operation). The externally observable behaviour of 5GS still conforms to the specifications for a Boundary Clock as described in IEEE Std 1588 [126].

Comment:

Revision of (Noted) S2-2107343 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

Devaki (Nokia) provides r01.
Sang-Jun (Samsung) asks for clarification why 5.27.1.1 and 5.27.1.2.2.2 are different.
Jari (NTT DOCOMO) proposes to postpone
Saso (Intel) points out that there is an alternative proposal in S2-2108877. It is fine to use this thread for the discussion.
Jari (NTT DOCOMO) responds to Saso (Intel)
Chunshan (Tencent) responses to Jari.
Chunshan (Tencent) comments 8877 on this thread.
Saso (intel) replies to Chunshan (Tencent).
Chunshan (Tencent) comments on Saso (intel).
Sebastian (Qualcomm) objects to the CR for the reason that we should first wait for the feedback from SMPTE before we make changes as the ones proposed in this CR
Chunshan (Tencent) points out that the CR is to solve the conflict between the TS and IEEE 1588 and is not related with the LS of SMPTE, and wants to say that Sebastian (Qualcomm) objection is not reasonable.
Chunshan (Tencent) provides r02.
Sang-Jun (Samsung) confirms changes of r02 are fine.
Chunshan (Tencent) responses to Saso (Intel) that solutions of 8870 is incomplete.
Chunshan (Tencent) response to Saso (Intel).
Chunshan (Tencent) responses to Saso (Intel).
Shabnam (Ericsson) maintains objection to this CR, provides detailed comments
Chunshan (Tencent) responses to Shabnam (Ericsson).
Shabnam (Ericsson) maintains objection to this CR, provides responses
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108626 (CR) 23.501 CR3404 (Rel-17, 'F'): Principle for Handling of PMIC exchange with UE(s) in idle mode. (Source: Samsung).
Document for: Approval.
Abstract: Summary of change: - TSCTSF may indicate that the AMF is allowed to use ATC when it sends PMIC.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Devaki (Nokia) proposes to note the CR.
Sang-Jun (Samsung) replies to Devaki (Nokia).
Sebastian (Qualcomm) objects to the CR
Zhendong (ZTE): similar view with nokia
Sang-Jun (Samsung) provides r01.
Sebastian (Qualcomm) objects to r01 (reasons already given)
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108627 (CR) 23.502 CR3267 (Rel-17, 'F'): Procedure for Handling of PMIC exchange with UE(s) in idle mode. (Source: Samsung).
Document for: Approval.
Abstract: Summary of change: - TSCTSF may indicate that the AMF is allowed to use ATC when it sends PMIC.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Devaki (Nokia) proposes to note the CR.
Sang-Jun (Samsung) replies to Devaki (Nokia).
Sebastian (Qualcomm) objects to the CR
Haiyang (Huawei) provides r01
Sang-Jun (Samsung) can accept r01.
Sebastian (Qualcomm) objects to r01 (reasons already given)
Shabnam (Ericsson) objects to original and r01 (reasons already given by Nokia and Qualcomm)
==== Revisions Deadline ====
Sang-Jun (Samsung) points out that r01 is listing some examples to the existing description on ATC for clarification.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108630 (CR) 23.501 CR3405 (Rel-17, 'F'): Relationship between Sync Exposure and Time Distribution. (Source: Samsung).
Document for: Approval.
Abstract: Summary of change: - Add relationship between Synchronization Activation/Modification/Deactivation and Time Distribution.

Comment:

r03 agreed. Revised to S2-2109288.

Discussion and conclusion:

-

e-mail discussion:

Devaki (Nokia) provides r01
Shabnam (Ericsson) asks clarification to the proposed changes, don't believe this CR is needed.
Sang-Jun (Samsung) provides r02.
Shabnam (Ericsson) comments that it is already described in the same clause so no reason for duplication?
==== Revisions Deadline ====
Sang-Jun (Samsung) can accept r03 provided by Shabnam (Ericsson).
Devaki (Nokia) comments that r03 is not correct for ASTI.
Shabnam (Ericsson) comments that on high level without going into all parameters and first sentence of the clause reading, r03 is correct, and that is why prefer not to duplicate between specs. Proposes to approve r03 and not r02 as marked in chair's notes.
Sang-Jun (Samsung) can accept r00, r02 and r03, and comments that r03 can work.
Devaki (Nokia) comments that the parameters should not have been included i.e. using the DNN and S-NSSAI. R03 is ok only if the parameters are removed. Otherwise, can accept r01 only.
Devaki (Nokia) comments that the ASTI procedure for a single UE is sent using UE ID and not DNN/S-NSSAI (rather DNN/S-NSSAI is a special case only for any UE). OK with r03 if DNN/S-NSSAI is removed.
Sang-Jun (Samsung) can accept r03 without 'using the DNN and S-NSSAI'.
Jari (NTT DOCOMO) accept r02, or can accept r03 without 'using the DNN and S-NSSAI'.
Sang-Jun (Samsung) provides r03+update in CC#2 folder in case we need to confirm. r03 is before deadline, and update is deleting 'using the DNN and S-NSSAI'.
Shabnam (Ericsson) OK with Samsung revision of r03+update deleting 'using the DNN and S-NSSAI' and approve at CC#2.
==== Comments Deadline ====.

Status:

Revised to S2-2109288.

TD S2-2109288 (CR) 23.501 CR3405R1 (Rel-17, 'F'): Relationship between Sync Exposure and Time Distribution. (Source: Samsung, Ericsson).
Document for: Approval.
Abstract: Summary of change: - Add relationship between Synchronization Activation/Modification/Deactivation and Time Distribution.

Comment:

Revision of S2-2108630r03. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108632 (CR) 23.503 CR0680 (Rel-17, 'F'): Correction on 5G access stratum time distribution parameters. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Add conditions for 5G access stratum time distribution indication and mark Uu interface time synchronization error budget as optional.

Comment:

r04 agreed. Revised to S2-2109289.

Discussion and conclusion:

-

e-mail discussion:

Devaki (Nokia) provides r01.
Jari (NTT DOCOMO) question for clarification
Zhendong (ZTE): provides r02
Haiyang (Huawei): provides r03 on top of r02
Shabnam (Ericsson) has concerns on the revisions as they are not acceptable, comments
Haiyang (Huawei) provides r04
==== Revisions Deadline ====
Shabnam (Ericsson) Thanks Sunhaiyang, comments that NOTE 10 is not complete, we need to have a revision to fix that.
Chunshan (Tencent) comments that a new revision is needed since the new added NOTE 10 is incomplete.
Haiyang (Huawei) suggests to go with [r04 + add 'enabled' in NOTE 10], (may need confirmation at CC#2)
==== Comments Deadline ====.

Status:

Revised to S2-2109289.

TD S2-2109289 (CR) 23.503 CR0680R1 (Rel-17, 'F'): Correction on 5G access stratum time distribution parameters. (Source: Huawei, HiSilicon, Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: Add conditions for 5G access stratum time distribution indication and mark Uu interface time synchronization error budget as optional.

Comment:

Revision of S2-2108632r04. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108633 (CR) 23.501 CR3406 (Rel-17, 'F'): Correction on 5G access stratum time distribution. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Clarify that the time synchronization error budget is used for both the 5G access stratum time distribution method and (g)PTP based synchronization method. Add Nnef_TimeSynchronization service to the table of NF Services provided by NEF.

Comment:

r02 agreed. Revised to S2-2109290, merging S2-2108821.

Discussion and conclusion:

-

e-mail discussion:

Devaki (Nokia) provides r01.
Zhendong (ZTE): agree with nokia
Shabnam (Ericsson) agrees with Nokia updates but requires additional corrections and provides via r02
Haiyang (Huawei) has questions on r01/r02
Devaki (Nokia) replies.
Haiyang (Huawei) replies
Zhendong (ZTE): provides response
Haiyang (Huawei) replies to Zhendong (ZTE) and provides r03
Shabnam (Ericsson) does not agree to r03, provides comment
==== Revisions Deadline ====
Haiyang (Huawei) can live with r02
==== Comments Deadline ====.

Status:

Revised to S2-2109290, merging S2-2108821.

TD S2-2109290 (CR) 23.501 CR3406R1 (Rel-17, 'F'): Correction on 5G access stratum time distribution. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Clarify that the time synchronization error budget is used for both the 5G access stratum time distribution method and (g)PTP based synchronization method. Add Nnef_TimeSynchronization service to the table of NF Services provided by NEF.

Comment:

Revision of S2-2108633r02, merging S2-2108821. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108634 (CR) 23.502 CR3268 (Rel-17, 'F'): Correction on 5G access stratum time distribution. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Correct the description for Nnef_TimeSynchronization_ CapsUnsubscribe. Clarify that the 'Current state of the time synchronization configuration' in the input of the Ntsctsf_TimeSynchronization_ConfigUpdateNotify/ Nnef_TimeSynchronization_ConfigUpdateNotify operation is the time synchronization information for the PTP instance as described in Table 5.28.3.1-2 of TS 23.501. And it is optional in steps 7-8 of the procedures in clause 4.15.9.3.2 and 4.15.9.3.3. Clarify that steps 5 to 10 of the procedure are used by the TSCTSF to manage the 5G access stratum time distribution for the UEs that are part of a PTP instance. Change '5G clock sync' to '5G access stratum time distribution method'.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Shabnam (Ericsson) comments regarding the NOTE in clause 4.15.9.1 and 4.15.9.3.2 step 6, last paragraph.
Haiyang (Huawei) replies to Shabnam (Ericsson).
==== Revisions Deadline ====
Jar (NTT DOCOMO) proposes to note
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108635 (CR) 23.502 CR3269 (Rel-17, 'F'): Clarifications on the use of DS-TT port MAC address. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Clarifications are added to align with 23.501.

Comment:

r02 agreed. Revised to S2-2109291.

Discussion and conclusion:

-

e-mail discussion:

Chunshan(Tencent) provides r01 and comments .
Zhendong (ZTE): provides comments
Haiyang (Huawei) provides r02.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109291.

TD S2-2109291 (CR) 23.502 CR3269R1 (Rel-17, 'F'): Clarifications on the use of DS-TT port MAC address. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Clarifications are added to align with 23.501.

Comment:

Revision of S2-2108635r02. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108636 (CR) 23.503 CR0681 (Rel-17, 'F'): Clarifications on the use of DS-TT port MAC address. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Clarifications are added to support time sensitive communication and time synchronization scenario.

Comment:

r01 agreed. Revised to S2-2109292.

Discussion and conclusion:

-

e-mail discussion:

Chunshan(Tencent) proposes to note this paper.
Jari (NTT DOCOMO) agrees with Chunshan, proposes to note this paper.
Haiyang (Huawei) indicates this paper is the alignment with agreed 501 CR S2-2108128 and is only related to the binding.
Jari (NTT DOCOMO) comments
Gy×rgy (Ericsson) comments
Jari (NTT DOCOMO) provides r01
Haiyang (Huawei) is OK with r01
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109292.

TD S2-2109292 (CR) 23.503 CR0681R1 (Rel-17, 'F'): Clarifications on the use of DS-TT port MAC address. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Clarifications are added to support time sensitive communication and time synchronization scenario.

Comment:

Revision of S2-2108636r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108646 (CR) 23.503 CR0682 (Rel-17, 'F'): Clarifications on Policy for AF. (Source: Samsung).
Document for: Approval.
Abstract: Summary of change: - Change 'Interacting with TSCTSF for Time synchronization service (see clause 5.27.1)' to 'Interacting with TSCTSF for Time synchronization service (see clause 5.27.1 of TS 23.501[2])' - Add specification numbers to the other clause references in the same way.

Comment:

r01 agreed. Revised to S2-2109293.

Discussion and conclusion:

-

e-mail discussion:

Mirko (Huawei) comments.
Sang-Jun (Samsung) provides r01 as per Mirko (Huawei)' comments.
Yuan Tao (CATT) comments.
Shabnam (Ericsson) agrees with CATT, the content of 6.2.10 needs to be moved under 6.2.3.
Sang-Jun (Samsung) provides r03.
==== Revisions Deadline ====
Mirko (Huawei) can only accept r01 and objects to all other versions.
Sang-Jun (Samsung) can accept r01 and r03.
Yuan Tao (CATT) prefer r03.
Mirko (Huawei) responds.
Yuan Tao (CATT) can accept r01.
==== Comments Deadline ====.

Status:

Revised to S2-2109293.

TD S2-2109293 (CR) 23.503 CR0682R1 (Rel-17, 'F'): Clarifications on Policy for AF. (Source: Samsung).
Document for: Approval.
Abstract: Summary of change: void the clause 6.2.10.

Comment:

Revision of S2-2108646r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108705 (CR) 23.501 CR3322R1 (Rel-17, 'F'): Processing (g)PTP messages for domain numbers and while in Disabled state. (Source: NTT DOCOMO, Intel).
Document for: Approval.
Abstract: Summary of change: 1. In 5.27.1.2.2, when 5GS is operating as BC or PTP Relay, clarify that the NW-TT discards the message if the NW-TT does not have a matching PTP instance. In 5.27.1.2.2.2, remove the verification of domain number and sdoId when 5GS is operating as a Transparent Clock. 2. In 5.27.1.6, it is clarified that the DS-TT maintains the Disabled state for the PTP ports in DS-TT, and this state can be read by the TSCTSF or TSN AF from the DS-TT via PMIC. The DS-TT discards all (g)PTP messages while in Disabled state. The duplicate NOTE is removed from 5.27.1.5.

Comment:

Revision of (Postponed) S2-2107617 from S2#147E. r01 agreed. Revised to S2-2109294.

Discussion and conclusion:

-

e-mail discussion:

Chunshan(Tencent) provides r01 and comments.
Haiyang (Huawei) agrees with Chunshan (Tencent).
Yuan Tao (CATT) agrees with Tencent and Huawei.
Zhendong (ZTE): provides comments
Jari (NTT DOCOMO) responds to Zhendong
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109294.

TD S2-2109294 (CR) 23.501 CR3322R2 (Rel-17, 'F'): Processing (g)PTP messages for domain numbers and while in Disabled state. (Source: NTT DOCOMO, Intel).
Document for: Approval.
Abstract: Summary of change: 1. In 5.27.1.2.2, when 5GS is operating as BC, TC or PTP Relay, clarify that the NW-TT discards the message if the NW-TT does not have a matching PTP instance. 2. In 5.27.1.6, it is clarified that the DS-TT maintains the Disabled state for the PTP ports in DS-TT, and this state can be read by the TSCTSF or TSN AF from the DS-TT via PMIC. The DS-TT discards all (g)PTP messages while in Disabled state. The duplicate NOTE is removed from 5.27.1.5.

Comment:

Revision of S2-2108705r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108738 (CR) 23.501 CR3107R3 (Rel-17, 'F'): QoS parameter handling for TSC. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: The description is updated as follows: The UE egress terminology and the UE-DS-TT Residence Time definition are updated by refereing to the SDAP layer to clarify the relation to the UE internal processing of PDUs. Clause 5.27.2 is renamed to also reflect the TSC Assistance Container The text in clause 5.27.2.1 is simplified a bit and a table listing the content of the TSC Assistance Container is added as well. Terminology is aligned and references are added in several places.

Comment:

Revision of (Endorsed) S2-2108139 from S2#147E. r04 agreed. Revised to S2-2109295.

Discussion and conclusion:

-

e-mail discussion:

Devaki (Nokia) objects to r00, provides r01.
Zhendong (ZTE): prefer go with approved CR in the last meeting
Sebastian (Qualcomm) provides r02
Mirko (Huawei) responds.
Shabnam (Ericsson) supports Qualcomm's r02.
Sang-Jun (Samsung) provides r03.
Sang-Jun (Samsung) provides r04.
Mirko (Huawei) can accept r04.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109295.

TD S2-2109295 (CR) 23.501 CR3107R4 (Rel-17, 'F'): QoS parameter handling for TSC. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: The description is updated as follows: Clause 5.27.2 is renamed to also reflect the TSC Assistance Container The text in clause 5.27.2.1 is simplified a bit and a table listing the content of the TSC Assistance Container is added as well. Terminology is aligned and references are added in several places.

Comment:

Revision of S2-2108738r04. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108739 (CR) 23.503 CR0634R3 (Rel-17, 'F'): QoS parameter handling for TSC. (Source: Huawei, HiSilicon, Samsung).
Document for: Approval.
Abstract: Summary of change: It is therefore proposed to update and restructure the description: The description of the TSC Assistance Container handling is described in a new clause (Support of Time Sensitive Communication and Time Synchronization). The description of the interaction between TSCTSF and PCF is added to the new clause. The description of the TSC Assistance Container content is replaced by a reference to 23.501 to have the definition in one place only.

Comment:

Revision of (Endorsed) S2-2108140 from S2#147E. r01 agreed. Revised to S2-2109296, merging S2-2108428 and S2-2108434.

Discussion and conclusion:

-

e-mail discussion:

Jari (NTT DOCOMO) comments
Mirko (Huawei) responds.
Shabnam (Ericsson) comments that the new clause repeats requirements from 23.501 and prefer to rather use reference instead towards 23.501/23.502.
Jari (NTT DOCOMO) provides r01
==== Revisions Deadline ====
Devaki (Nokia) prefers r01 (straight forward overview of the new clause), does not prefer r0 with listing exceptions.
==== Comments Deadline ====.

Status:

Revised to S2-2109296, merging S2-2108428 and S2-2108434.

TD S2-2109296 (CR) 23.503 CR0634R4 (Rel-17, 'F'): QoS parameter handling for TSC. (Source: Huawei, HiSilicon, Samsung, Ericsson).
Document for: Approval.
Abstract: Summary of change: It is therefore proposed to update and restructure the description: The description of the interaction between TSCTSF and PCF is added as a new clause (Support of Time Sensitive Communication and Time Synchronization). The description of the TSC Assistance Container content is replaced by a reference to 23.501 to have the definition in one place only.

Comment:

Revision of S2-2108739r01, merging S2-2108428 and S2-2108434. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108740 (CR) 23.503 CR0686 (Rel-17, 'F'): QoS parameter handling for TSC. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: It is therefore proposed to update and restructure the description by: Clarifying that either a QoS reference or a set of individual QoS parameters is provided by the AF (including the Alternative Service Requirements). The Requested 5GS Error Ratio is added as another QoS parameter that can be provided by the AF (as this is an important input for the 5QI selection). The mapping of AF provided QoS parameters to PCC rule QoS parameters is described explicitly. The principle for the selection of the 5QI is described explicitly. The possibility for a rejection of the AF request is added so that the PCF can respond appropriately if the QoS requirements (represented by the AF provided QoS parameters) cannot be fulfilled.

Comment:

Merged into S2-2109286.

Discussion and conclusion:

-

e-mail discussion:

Shabnam (Ericsson) comments on a number of aspects for this CR that requires first clarification before approval or revision
Devaki (Nokia) has concerns with the CR as they are not corrections, propose to merge with 8479 and use that as baseline to start with essential updates to this section.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Merged into S2-2109286.

TD S2-2108819 (CR) 23.502 CR3208R1 (Rel-17, 'F'): Fix the EN on the priority in the AF session with required QoS procedure. (Source: ZTE).
Document for: Approval.
Abstract: Summary of change: Removing the ENs on whether and how the PCF uses the Priority value provided by AF. And clarify that the Priority value provided by an AF is used by PCF to determine the Qos parameters.

Comment:

Revision of (Postponed) S2-2107661 from S2#147E. Merged into S2-2109285.

Discussion and conclusion:

-

e-mail discussion:

Devaki (Nokia) comments.
Zhendong (ZTE): provides r01
==== Revisions Deadline ====
==== Comments Deadline ====
Gy×rgy (Ericsson) proposes to consider this merged into 8478 (similar change is made there).
Zhendong (ZTE): agree with Gy×rgy.

Status:

Merged into S2-2109285.

TD S2-2108820 (CR) 23.501 CR3330R1 (Rel-17, 'F'): Clarification on the time synchronization. (Source: ZTE).
Document for: Approval.
Abstract: Summary of change: The configuration of the time synchronization service in 5GS for for options 1-4 by AF/NEF and TSCTSF. Clarifying how the NW-TT determine the PTP instance. NW-TT forwards (g)PTP message to NW-TT port in Leader state.

Comment:

Revision of (Postponed) S2-2107664 from S2#147E. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108821 (CR) 23.501 CR3435 (Rel-17, 'F'): Removing the PDU session description in 5G access stratum time synchronization distribution method. (Source: ZTE).
Document for: Approval.
Abstract: Summary of change: Removing this method is applicable for both IP and Ethernet PDU Sessions.

Comment:

Merged into S2-2109290.

Discussion and conclusion:

-

e-mail discussion:

Haiyang (Huawei) suggests to merge this paper into S2-2108633
Zhendong (ZTE): is fine with merge proposal
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Merged into S2-2109290.

TD S2-2108847 (CR) 23.501 CR3438 (Rel-17, 'F'): Multiple PTP instances supported in 5GS. (Source: Tencent, Tencent Cloud).
Document for: Approval.
Abstract: Summary of change: The 5GS can be configured to operate in one or multiple PTP instances to operate in different mode or different types(i.e. PTP relay instance, Boundary Clock, end-to-end Transparent Clock, peer-to-peer Transparent Clock) for each PTP instance in clause 5.27.1.1 and 5.27.1.4. The time aware system is replaced with PTP relay instance in the clause 5.27 and its subclauses, annex H and K. For the gPTP sync and Follow_Up messages, it is supported only by the PTP relay instance in clause 5.27.1.2.2.1. In clause 5.27.1.2.2.2 , it is explicitly described the PTP instance is Boundary Clock or Transparent Clock. In clause 5.27.1.3, the (g)PTP event messages with the matching domains are forwarded. In clause 5.27.1.3, the 5GS supports multiple (g)PTP domains, also the 5GS shall support multiple PTP instances. And more PTP instances can be supported for the same (g)PTP domain, and the PTP instance can be differented by the ingress port number with the same (g)PTP domain.

Comment:

r01 agreed. Revised to S2-2109297.

Discussion and conclusion:

-

e-mail discussion:

Devaki (Nokia) comments that this CR is a duplicate of 8541. Mark this as merged or the other one as merged. Same technical concerns apply.
Chunshan (Tencent) provides r02.
Jari (NTT DOCOMO) provides r02
Chunshan (Tencent) provides the r04. Jari (NTT DOCOMO) provides r03 in the previous comment.
Gy×rgy (Ericsson) comments and prefers r01.
Chunshan (Tencent) response to Gy×rgy (Ericsson).
Sang-Jun (Samsung) comments.
Devaki (Nokia) can also accept only r01.
==== Revisions Deadline ====
Devaki (Nokia) can accept r01 (objects to other revisions for reasons stated earlier).
==== Comments Deadline ====.

Status:

Revised to S2-2109297.

TD S2-2109297 (CR) 23.501 CR3438R1 (Rel-17, 'F'): Multiple PTP instances supported in 5GS. (Source: Tencent, Tencent Cloud).
Document for: Approval.
Abstract: Summary of change: The 5GS can be configured to operate in one or multiple PTP instances to operate in different mode or different types(i.e. time-aware system, Boundary Clock, end-to-end Transparent Clock, peer-to-peer Transparent Clock) for each PTP instance in clause 5.27.1.1.

Comment:

Revision of S2-2108847r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108849 (CR) 23.502 CR3296 (Rel-17, 'F'): Clarifications regarding TSCTSF discovery and selection. (Source: NTT DOCOMO).
Document for: Approval.
Abstract: Summary of change: 1. Clarify that the TSCTSF notification address that is stored to the UDR is used only for time-sync PTP service. This means the PCF does not need to notify the TSCTSF for a PDU Session, unless the TSCTSF has received a prior AF-request for time-sync capability subscription. 2. Remove the storing of TSCTSF NF instance in the UDR. Note that the storing of TSCTSF notification address for a time-sync capability subscription is still necessary so that the PCF can notify the TSCTSF for a PDU Session matching to the time-sync capability subscription. 3. Separate the ASTI-related service operations into a separate service. This means that a different TSCTSF instance may be selected for ASTI and time-sync services. 4. Add a possibility for the TSCTSF to use _Update service operation if an AF-session already exists with the PCF. 5. Clarify that the SMF stores the '5GS Bridge information' until the PCF subscribes for it. This is the same principle as with any other events that are reported from the SMF to the PCF. Remove the storing in PCF. In case of QoS-request: the PCF may receive a subscription for the '5GS Bridge information' from the TSCTSF while the PCF does not have the 5GS Bridge information for the PDU Session. In this case the PCF triggers the PCF initiated SM policy association modification and subscribes for it from the SMF. The SMF reports the 5GS Bridge information to the PCF, and PCF reports it to the TSCTSF. In case of time-sync request before a PDU Session: During the SM policy association establishment, the PCF retrieves the TSCTSF notification address in UDR, or uses the local configuration of the TSCTSF address, to determine that the PCF needs to subscribe for the 5GS bridge information event from the SMF. The SMF initiates an SM policy association modification and reports the 5GS Bridge information to the PCF, and PCF reports it to the TSCTSF. In case of time-sync request after a PDU Session: During the SM policy association establishment, the PCF subscribes for the TSCTSF notification address in UDR. Upon the time-sync request, the TSCTSF updates the notification address to UDR, and UDR notifies the PCF. PCF triggers PCF initiated SM policy modification to subscribe for the 5GS bridge information from the SMF. The SMF reports the 5GS Bridge information to the PCF, and PCF reports it to the TSCTSF. 6. It is proposed to remove the ovelapping description in clause 4.15.6.6.a and refer to steps in clause 4.15.6.6 instead.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Devaki (Nokia) objects to the CR and its revisions as the proposed approach to define discovery and selection per service is way too complex for little benefit.
Qianghua (Huawei) proposes to note this CR
Jari (NTT DOCOMO) responds
Gy×rgy (Ericsson) suggests to note this document given the SoH outcome on Monday.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108850 (CR) 23.502 CR3297 (Rel-17, 'F'): Updates on AS time distribution. (Source: CATT).
Document for: Approval.
Abstract: Summary of change: Clarify the Nnef_TimeSynchronization_ASTIDelete service operation used by AF. Clarify the use of PTP instance reference. Update the parameter Time synchronization configuration Id to PTP instance reference in Ntsctsf_TimeSynchronization_ASTI service operations.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Devaki (Nokia) has objections to the CR as it is technically wrong - ASTI service cannot use a PTP instance reference as ID.
Yuan Tao replies to Devaki (Nokia) and ask for clarification.
Jari (NTT DOCOMO) agrees with Nokia, CR is incorrect
Sebastian (Qualcomm) objects to the CR (PTP Instance IDs do not make sense for ASTI as commented by others also)
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108851 (CR) 23.503 CR0689 (Rel-17, 'F'): Clafication on bridge information notification. (Source: CATT).
Document for: Approval.
Abstract: Summary of change: Clarify the report on the event of the 5GS Bridge information Notification for TSCTSF. Add the interaction with TSCTSF for TSC Assistance Information and TSC QoS in description of AF functions.

Comment:

r02 agreed. Revised to S2-2109298.

Discussion and conclusion:

-

e-mail discussion:

Gy×rgy (Ericsson) comments.
Yuan Tao (CATT) provides r01.
Mirko (Huawei) comments.
Sang-Jun (samsung) confirms 8646 is updated to remove clause 6.2.10 from 23.503.
Yuan Tao (CATT) replies to Mirko (Huawei).
Jari (NTT DOCOMO) responds to Mirko
Yuan Tao (CATT) provides r02.
Mirko (Huawei) provides r03.
Yuan Tao responses to Mirko (Huawei).
==== Revisions Deadline ====
Yuan Tao (CATT) suggests to approve r02.
Mirko (Huawei) is ok with r02.
==== Comments Deadline ====.

Status:

Revised to S2-2109298.

TD S2-2109298 (CR) 23.503 CR0689R1 (Rel-17, 'F'): Clafication on bridge information notification. (Source: CATT).
Document for: Approval.
Abstract: Summary of change: Clarify the report on the event of the 5GS Bridge information Notification for TSCTSF.

Comment:

Revision of S2-2108851r02. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108852 (CR) 23.501 CR3439 (Rel-17, 'F'): Update on configuration for Sync and Announce reception timeouts. (Source: CATT).
Document for: Approval.
Abstract: Summary of change: Add the Announce Interval attributes for time-aware system. To clarify the TSCTSF or TSN AF uses the 'Time synchronization information for each DS-TT port' element in UMIC for DS-TT ports.

Comment:

Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108877 (CR) 23.501 CR3448 (Rel-17, 'F'): Correction on PTP message handling in Boundary Clock. (Source: Intel).
Document for: Approval.
Abstract: Summary of change: The following is clarified in clause 5.27.1.2.2.2: a) The Boundary Clock in NW-TT/UPF adds a timestamp (TSi) in the Suffix field of the regenerated Sync message and forwards it to the Master port(s) in NW-TT and to PDU Session(s) related to Master ports in the DS-TT(s). b) The yellow text is removed.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Chunshan(Tencent) proposes this paper to be merged into paper S2-2108540.
Saso (Intel) is happy to discuss on the 8540 thread, but disagrees with the merger.
Chunshan (Tencent) comments to Saso (Intel) that your paper is not complete.
==== Revisions Deadline ====
Chunshan (Tencent) objects this CR.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108933 (CR) 23.501 CR3456 (Rel-17, 'F'): Clarifications regarding TSCTSF discovery and selection. (Source: NTT DOCOMO).
Document for: Approval.
Abstract: Summary of change: 1. Clarify that the TSCTSF notification address that is stored to the UDR is used only for time-sync PTP service. This means the PCF does not need to notify the TSCTSF for a PDU Session, unless the TSCTSF has received a prior AF-request for time-sync capability subscription. 2. Remove the storing of TSCTSF NF instance in the UDR. Note that the storing of TSCTSF notification address for a time-sync capability subscription is still necessary so that the PCF can notify the TSCTSF for a PDU Session matching to the time-sync capability subscription. 3. Separate the ASTI-related service operations into a separate service. This means that a different TSCTSF instance may be selected for ASTI and time-sync services. 4. Clarify that TSCTSF deletes the TSCTSF Notification Target Address from the UDR after the subscriptions for '5GS and UE availability and capabilities for time synchronization service' are cancelled.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Devaki (Nokia) proposes to merge this CR with 8971/8476.
Sang-Jun (Samsung) also proposes this CR and 8961/8476 should be merged, and corrects the number 8971 to be 8961 in Nokia's comemnt.
Jari (NTT DOCOMO) does not agree to merge
Qianghua (Huawei) proposes to go with 08961.
Gy×rgy (Ericsson) suggests to note this document given the SoH outcome on Monday.
==== Revisions Deadline ====
Devaki (Nokia) proposes to note the document based on Monday SoH outcome (or mark it as merged with 8961).
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108822 (CR) 23.502 CR3291 (Rel-18, 'F'): Clarification on the Ntsctsf_QoSandTSCAssistance related service operation. (Source: ZTE).
Document for: Approval.
Abstract: Summary of change: Replace NEF withTSCTSF in Ntsctsf_QoSandTSCAssistance_Notify service operation. Adding Transaction Reference ID as input. Removing the Transaction Reference ID in the output of Ntsctsf_QoSandTSCAssistance_Unsubscribe service operation.

Comment:

Approved.

Discussion and conclusion:

-

Status:

Agreed.

# 8.6 Access Traffic Steering, Switch and Splitting support in the 5G system architecture Phase 2 (ATSSS_Ph2)

This agenda item was convened by Andy Bennett (Samsung).

TD S2-2108480 (CR) 23.503 CR0654R2 (Rel-17, 'F'): Extending MA PDU Session Control information in the PCC Rule. (Source: [Ericsson, Lenovo, Motorola Mobility], LG Electronics).
Document for: Approval.
Abstract: Summary of change: The MA PDU Session Control Information in the PCC Rule is extended with both Steering Mode Indicator and Threshold Values.

Comment:

Revision of (Agreed) S2-2107828 from S2#147E. r06 agreed. Revised to S2-2109095, merging S2-2108795.

Discussion and conclusion:

-

e-mail discussion:

Rainer (Nokia) asks for clarification.
Myungjune (LGE) replies to Rainer (Nokia).
Belen (Ericsson) objects to this revision
Dario (Qualcomm) comments.
Apostolis (Lenovo) has also concerns with this CR.
Myungjune (LGE) provides r01.
Apostolis (Lenovo) provides further comments.
Myungjune (LGE) provides r03.
Rainer (Nokia) provides r04.
Myungjune (LGE) is ok with r04
Apostolis (Lenovo) is also OK with r04
Belen (Ericsson) provides r05 and objects to previous revision and initial version.
Apostolis (Lenovo) responds to Belen.
Belen (Ericsson) disagrees with Apostolis proposal.
Dario (Qualcomm) supports r04
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109095, merging S2-2108795.

TD S2-2109095 (CR) 23.503 CR0654R4 (Rel-17, 'F'): Extending MA PDU Session Control information in the PCC Rule. (Source: Ericsson, Lenovo, Motorola Mobility, LG Electronics).
Document for: Approval.
Abstract: Summary of change: The MA PDU Session Control Information in the PCC Rule is extended with both Steering Mode Indicator and Threshold Values.

Comment:

Revision of S2-2108480r06, merging S2-2108795. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108730 (CR) 23.501 CR3421 (Rel-17, 'F'): 23.501 Clarification on threshold values. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: the UE and UPF may based on implementation send all the traffic to another access where the measured parameters do not exceed the provided threshold value.

Comment:

r02 agreed. Revised to S2-2109096.

Discussion and conclusion:

-

e-mail discussion:

Dario S. Tonesi (Qualcomm) provides r01
Apostolis (Lenovo) provides r02
Rainer (Nokia) is ok with r02.
Hualin (Huawei) is ok with r02.
Dario (Qualcomm) is OK with r02
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109096.

TD S2-2109096 (CR) 23.501 CR3421R1 (Rel-17, 'F'): Clarification on threshold values. (Source: Huawei, HiSilicon, Lenovo, Motorola Mobility).
Document for: Approval.
Abstract: Summary of change: It is clarified that, when at least one measured parameter (i.e. RTT or Packet Loss Rate) on one access exceeds the provided threshold value, the UE and UPF may either stop sending traffic on this access, or may continue sending traffic on this access but should reduce the traffic on this access by an implementation specific amount.

Comment:

Revision of S2-2108730r02. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108795 (CR) 23.503 CR0654R3 (Rel-17, 'F'): Extending MA PDU Session Control information in the PCC Rule. (Source: [Ericsson, Lenovo, Motorola Mobility], Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: The MA PDU Session Control Information in the PCC Rule is extended with both Steering Mode Indicator and Threshold Values. Added in this version: It is clarified that the threshold value for the UL and DL traffic direction may be different.

Comment:

Revision of (Agreed) S2-2107828 from S2#147E. Merged into S2-2109095.

Discussion and conclusion:

-

e-mail discussion:

Rainer (Nokia) asks for clarification.
Apostolis (Lenovo) proposes to merge this into 8480.
Susan (Huawei) replies to Rainer (Nokia) and is ok to merge to 8480.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Merged into S2-2109095.

# 8.7 Support of Aerial Systems Connectivity, Identification, and Tracking (ID_UAS)

This agenda item was convened by Tao Sun (China Mobile).

TD S2-2108281 (LS IN) LS on GTP-C cause value used for UAS services. (Source: CT WG1 (C1-216293)).
Document for: Information.
Abstract: CT WG1 is implementing stage 2 requirements on UUAA-SM and C2 authorization in EPS as specified in TS 23.256 and has noticed that in following two cases the SMF+PGW-C needs to reject the PDN connectivity request: (1) SMF+PGW-C determines that UUAA-SM is required but CAA-level UAV ID is not provided by the UE; and (2) SMF+PGW-C determines that C2 authorization is required but CAA-Level UAV ID and C2 aviation payload are not provided by the UE. To avoid MME impact, CT WG1 has agreed i. to re-use an existing NAS ESM cause value provided by the MME to the UE in the PDN CONNECTIVITY REJECT message; and ii. UAS services related rejection information will be indicated in a PCO parameter (rather than NAS ESM cause) of the PDN CONNECTIVITY REJECT message. Existing NAS ESM cause #29 'User authentication or authorization failed' and cause #31 'Request rejected, unspecified' have been identified as preferred in CT WG1. However, CT WG1 noted that in the PDN connectivity reject handling, it is the SMF+PGW-C provides a GTP-C cause value to the MME via the S-GW. Then, the MME maps the received GTP-C cause value to an NAS ESM cause value sent to the UE based on the mapping Table C.1 in TS 29.274. Concluding which existing NAS ESM cause value to be re-used, depends also on the GTP-C cause selected. CT WG1 would like to ask CT WG4 which GTP-C cause could be selected to ensure that the mapping Table C.1 in TS 29.274 enables the MME to use an existing NAS ESM cause for the above PDN connectivity reject handling and which existing NAS ESM cause value it will be mapped to.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

DongYeon (Samsung) proposes NOTE this LS, since no action required from SA2.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2109369 (LS IN) LS from CT WG1: LS on EPS requirements for ID_UAS. (Source: CT WG1 (C1-217131)).
Document for: Action.
Abstract: CT WG1 has discussed the support of ID_UAS in EPS and identified a protocol issue with the UE providing UAS parameters to the network (namely for UUAA-SM or for C2 authorization or for both). Based on current NAS specifications (i.e. TS 24.301 and TS 24.008) for IP based PDN connection in WB-S1 mode, there is a maximum size limitation of protocol configuration options. CT WG1 could not agree on whether certain protocol changes in MMEs/S-GWs are acceptable to SA WG2 to overcome the above limitations and support UAS in EPS. Therefore, CT WG1 would like to ask the following questions to SA WG2: Question 1): Whether UUAA-SM and C2 authorization need to be supported in deployments where MMEs/S-GWs are of previous releases (prior to release-17) with the limitations mentioned above. Question 2): If the answer to the Question 1 is No, whether the UAV UE due to the UE mobility may end-up being served by a target MME, or target S-GW or both, of a previous release (prior to release-17) with the limitations mentioned above, and if so, how to handle this mobility situation for ID_UAS. Action: CT WG1 kindly asks SA WG2 to answer above questions.

Comment:

CC#2: Response drafted in S2-2109342. Final response in S2-2109342.

Discussion and conclusion:

CC#2: Qualcomm requested a number for a response for this. This was allocated as S2-2109342 (for CC#3).
CC#3: Final response in S2-2109342.

Status:

Replied to.

TD S2-2109342 (LS OUT) Reply LS on EPS requirements for ID_UAS. (Source: SA WG2).
Document for: Approval.
Abstract: To: CT WG1.

Comment:

CC#2: Created at CC#2. Response to S2-2109369. This was left for review at CC#3. CC#3: Approved.

Discussion and conclusion:

CC#3: Qualcomm provided S2-2109342r00. Ericsson asked to note that if CT WG1 can provide a solution for pre-Rel-17 support without MMS/SGW impact then this should also be acceptable. S2-2109342.

Status:

Approved.

TD S2-2108431 (CR) 23.256 CR0031R2 (Rel-17, 'F'): TS 23.256: Rapporteur Editorial CR. (Source: Qualcomm Incorporated, Ericsson).
Document for: Approval.
Abstract: Summary of change: Rapporteur corrects the editorial issues and removes unnecessary ENs.

Comment:

Revision of (Agreed) S2-2107971 from S2#147E. r03 agreed. Revised to S2-2109149.

Discussion and conclusion:

-

e-mail discussion:

Guanglei (Huawei) provides r01
Stefano (Qualcomm) provides r02, cannot accept r01
Guanglei (Huawei) provides r03
==== Revisions Deadline ====
Stefano (Qualcomm) ok with r03.
==== Comments Deadline ====.

Status:

Revised to S2-2109149.

TD S2-2109149 (CR) 23.256 CR0031R3 (Rel-17, 'F'): TS 23.256: Rapporteur Editorial CR. (Source: Qualcomm Incorporated, Ericsson, Huawei, Hisilicon).
Document for: Approval.
Abstract: Summary of change: Rapporteur corrects the editorial issues and removes unnecessary ENs.

Comment:

Revision of S2-2108431r03. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108430 (CR) 23.256 CR0032 (Rel-17, 'F'): Correction of UUAA when aerial subscription is missing. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: Corrected how AMF rejects registration towards the UE/UAV. Clarified that UUAA-MM procedure is not executed when Aerial subscription is missing.

Comment:

r06 agreed. Revised to S2-2109150.

Discussion and conclusion:

-

e-mail discussion:

DongYeon (Samsung) asks a question for clarification.
Stefano (Qualcomm) provides comments.
Ashok (Samsung) comments
Shabnam (Ericsson) responds and provides r01.
Ashok (Samsung) comments and provides r02 with way forward
Stefano (Qualcomm) provides comments, not Ok with r02, has questions on r01.
Ashok (Samsung) responds to Stefano (Qualcomm)
Guanzhou (InterDigital) can't accept r02.
Shabnam (Ericsson) provides r03 addressing Qualcomm comment and adding cosigning company.
Tricci (OPPO) provides r04 to update the latest descriptions regarding the actual reason of the indication.
Ashok (Samsung) is OK with r04.
Dimitris (Lenovo) provides r06
Shabnam (Ericsson) agrees with r06.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109150.

TD S2-2109150 (CR) 23.256 CR0032R1 (Rel-17, 'F'): Correction of UUAA when aerial subscription is missing. (Source: Ericsson, Qualcomm Inc.).
Document for: Approval.
Abstract: Summary of change: Corrected how AMF rejects registration towards the UE/UAV. Clarified that UUAA-MM procedure is not executed when Aerial subscription is missing.

Comment:

Revision of S2-2108430r06. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108438 (CR) 23.256 CR0033 (Rel-17, 'F'): Correction on C2 authorization procedure. (Source: InterDigital).
Document for: Approval.
Abstract: Summary of change: 1. Only steps 1-4 of UAV re-authorization procedure is invoked. 2. Add support for C2 pending indication. 3. Clearing of the C2 pending indication after the pairing policy configuration is complete.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Jaewoo (LGE) provides comment.
Pallab (Nokia) comments and raises concern with the proposed changes.
Dimitris (Lenovo) agrees with the views from Pallab (Nokia)
Guanzhou (InterDigital) responds to Jaewoo (LGE) comment.
Guanzhou (InterDigital) responds to Pallab(Nokia) comments.
Shabnam (Ericsson) expresses concerns and don't believe the CR as is agreeable, comments.
Dimitris (Lenovo) comments
Guanzhou (InterDigital) provides further response.
Guanzhou (InterDigital) provides r01 for consistent service name.
==== Revisions Deadline ====
Pallab (Nokia) comments and proposes to NOTE the CR
Shabnam (Ericsson) objects to all versions, proposes to discuss offline further if there is an issue and can be solved via, e.g., Ericsson proposed changes in steps within current procedures.
Pallab (Nokia) responds to Jaewoo (LGE)
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108456 (CR) 23.502 CR3240 (Rel-17, 'F'): UASNF registration and discovery. (Source: Samsung).
Document for: Approval.
Abstract: Summary of change: The following change is proposed: NEF capability to support UAS NF functionality while registering with NRF and NF consumer AMF/SMF will select using this capability info.

Comment:

r02 agreed. Revised to S2-2109151.

Discussion and conclusion:

-

e-mail discussion:

Dimitris (Lenovo) provides r01
Shabnam (Ericsson) agrees with Lenovo proposed revision in r01, also asks to update the CR cover sheet to reflect the proposed changes.
Ashok (Samsung) provides r02
Dimitris (Lenovo) is ok with r02
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109151.

TD S2-2109151 (CR) 23.502 CR3240R1 (Rel-17, 'F'): UASNF registration and discovery. (Source: Samsung).
Document for: Approval.
Abstract: Summary of change: The following change is proposed: NEF to support UAS NF functionality while registering with NRF and NF consumer AMF/SMF will select using this info.

Comment:

Revision of S2-2108456r02. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108457 (CR) 23.256 CR0009R2 (Rel-17, 'F'): UUAA-MM Procedure Updates. (Source: Samsung,OPPO).
Document for: Approval.
Abstract: Summary of change: The following change is proposed: It is proposed that AMF updates the change in aerial subscription info to UE using the UCU procedure.

Comment:

Revision of (Agreed) S2-2108173 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

Stefano (Qualcomm) objects to this paper since the solution is not necessary, as discussed at the last meeting and offline.
Ashok (Samsung) does not agree with Stefano (Qualcomm) and need clarification for objection
Stefano (Qualcomm) re-iterates that the solution is not necessary.
Ashok (Samsung) responds to Stefano (Qualcomm)
Dimitris (Lenovo) agrees with QCOM that solution is not needed and already addressed in stage 3
Ashok (Samsung) responds to Dimitris (Lenovo)
Guanzhou (InterDigital) shares the position of Stefano (Qualcomm)
Ashok (Samsung) responds to Guanzhou (InterDigital)
Ashok (Samsung) is OK to NOTE the paper
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108458 (DISCUSSION) Discussion on UE impact because of change in Aerial subscription.. (Source: Samsung).
Document for: Information.
Abstract: This contribution discusses on how UE/UAV is getting impacted because the aerial subscription is getting enabled.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108542 (CR) 23.256 CR0035 (Rel-17, 'F'): Clean up for UUAA-MM procedure. (Source: LG Electronics).
Document for: Approval.
Abstract: Summary of change: Remove the description about defining USS operation in UUAA-MM and align with the description in UUAA-SM.

Comment:

Confirm CR Number - CR states <empty> ! r02 agreed. Revised to S2-2109152.

Discussion and conclusion:

-

e-mail discussion:

Shabnam (Ericsson) comments asking clarification.
Jaewoo (LGE) responds to Shabnam (Ericsson) and provides r01.
DongYeon (Samsung) comments.
Jaewoo (LGE) responds to DongYeon (Samsung) and provides r02.
==== Revisions Deadline ====
DongYeon (Samsung) is okay with r02 and r00, and objects to r01.
==== Comments Deadline ====.

Status:

Revised to S2-2109152.

TD S2-2109152 (CR) 23.256 CR0035R1 (Rel-17, 'F'): Clean up for UUAA-MM procedure. (Source: LG Electronics).
Document for: Approval.
Abstract: Summary of change: Remove the description about defining USS operation in UUAA-MM and added NOTEs for UUAA-MM and UUAA-SM procedure.

Comment:

Revision of S2-2108542r02. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108564 (CR) 23.256 CR0037 (Rel-17, 'F'): Clarification for UUAA-SM procedure when UUAA-MM performed. (Source: LG Electronics).
Document for: Approval.
Abstract: Summary of change: Clarify that UUAA-SM procedure when UUAA-MM performed. Introduce an indication that 'request is not for authentication'.

Comment:

Confirm CR Number - CR states <empty> ! Noted.

Discussion and conclusion:

-

e-mail discussion:

Pallab (Nokia) comments and asks for clarification. Raises concern with some of the changes.
Dimitris (Lenovo) comments
Jaewoo (LGE) responds to Pallab (Nokia) and Dimitris (Lenovo).
Pallab (Nokia) responds to Jaewoo (LGE)
Jaewoo (LGE) responds to Pallab (Nokia).
Guanglei(Huawei) provides comments.
Jaewoo (LGE) responds to Guanglei (Huawei).
Guanzhou (InterDigital) comments and provides r01.
Guanzhou (InterDigital) corrects its previous comment that no r01 was provided.
Shabnam (Ericsson) provides comments and shares others concerns
Jaewoo (LGE) responds to Guanzhou (InterDigital) and Shabnam (Ericsson).
Guanglei(Huawei) kindly reminds that it is already possible for NEF to receive DNN and S-NSSAI parameters from AF, besides mapping from AF identifier to DNN and S-NSSAI by NEF.
Jaewoo (LGE) responds to Pallab (Nokia) and Guanglei (Huawei).
Ashok (Samsung) responds to Jaewoo
Stefano (Qualcomm) comments, not convinced this solution is needed at all.
Jaewoo (LGE) proposes to note this CR.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108703 (CR) 23.256 CR0011R2 (Rel-17, 'F'): Clarify the implicit subscription during the UUAA procedure. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Clarify the UUAA-MM and UUAA-SM procedure to cover the Notification endpoint and the Authentication correlation ID. Clarify that AMF/SMF subscribe notifications from UAS NF/NEF and UAS NF/NEF subscribe notifications from USS implicitly based on the notification endpoint provided in the authentication request. Clarify that Naf_Authentication_authenticate Response messages from USS shall contain a authentication message in the multiple round-trip case. Remove the description about 'callback URI' in the UUAA-MM procedure.

Comment:

Revision of (Agreed) S2-2107959 from S2#147E. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108761 (CR) 23.256 CR0043 (Rel-17, 'F'): Network Initiated UUAA Revocation. (Source: Samsung, InterDigital, SK Telecom, LG Uplus).
Document for: Approval.
Abstract: Summary of change: Describe the UUAA Revocation initiated by the network when the aerial subscription data in Access and Mobility/Session Management Subscription Data in UDM is changed. UAS NF informs the USS that the authorization revocation procedure is triggered by Core Network to enable the USS initiates the UUAA to take the proper action in response (e.g., initiate revocation procedure).

Comment:

Postponed.

Discussion and conclusion:

-

e-mail discussion:

DongYeon (Samsung) provides r01, AT&T is added in source.
Dimitris (Lenovo) comments
Pallab (Nokia) agrees with the comments from Dimitris (Lenovo) and also feels that the changes proposed in the CR are not needed
Guanglei (Huawei) also thinks this CR is not correct.
Guanzhou (InterDigital) responds to Dimitris (Lenovo) and Pallab (Nokia) comments.
DongYeon (Samsung) replies to Dimitris (Lenovo) and Pallab (Nokia).
DongYeon (Samsung) replies to Guanglei (Huawei)
Dimitris (Lenovo) responds
DongYeon (Samsung) replies.
Guanzhou (InterDigital) further comments.
Pallab (Nokia) comments and proposes to NOTE the CR
Guanzhou (InterDigital) responds to Pallab (Nokia) and thinks this issue should be addressed in R17.
==== Revisions Deadline ====
Pallab (Nokia) responds to Guanzhou (InterDigital) and maintains objection
DongYeon (Samsung) proposes to postpone this CR.
==== Comments Deadline ====.

Status:

Postponed.

TD S2-2108623 (CR) 23.256 CR0038 (Rel-17, 'F'): Clarifications on UUAA context during revocation procedure. (Source: Samsung).
Document for: Approval.
Abstract: Summary of change: During the UUAA Revocation procedure, the UUAA result and the UUAA context in the network are removed.

Comment:

r01 agreed. Revised to S2-2109153.

Discussion and conclusion:

-

e-mail discussion:

Shabnam (Ericsson) provides r01 correcting 'response' to 'respond'
Guanglei (Huawei) provides comments.
DongYeon (Samsung) is Okay with r01, and replies to Guanglei (Huawei).
Guanglei (Huawei) replies.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109153.

TD S2-2109153 (CR) 23.256 CR0038R1 (Rel-17, 'F'): Clarifications on UUAA context during revocation procedure. (Source: Samsung).
Document for: Approval.
Abstract: Summary of change: During the UUAA Revocation procedure, the UUAA result and the UUAA context in the network are removed.

Comment:

Revision of S2-2108623r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108550 (CR) 23.256 CR0036 (Rel-17, 'F'): Replace of the term pairing authorization. (Source: LG Electronics).
Document for: Approval.
Abstract: Summary of change: Replace the term 'UAV-UAVC pairing authorization' to 'C2 authorization'.

Comment:

Confirm CR Number - CR states <empty> ! r02 agreed. Revised to S2-2109154.

Discussion and conclusion:

-

e-mail discussion:

Jaewoo (LGE) provides r01.
Guanglei (Huawei) provides comments and r02
Jaewoo (LGE) responds to Guanglei (Huawei) and is fine with r02.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109154.

TD S2-2109154 (CR) 23.256 CR0036R1 (Rel-17, 'F'): Replace of the term pairing authorization. (Source: LG Electronics).
Document for: Approval.
Abstract: Summary of change: Replace the term 'UAV-UAVC pairing authorization' to 'C2 authorization' in clause 5.2.3.1. Clarify that the C2 authorization includes paring authorzation and optional flight authorization.

Comment:

Revision of S2-2108550r02. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108553 (CR) 23.256 CR0002R1 (Rel-17, 'F'): Clarification and EN resolution for SMF Services. (Source: LG Electronics).
Document for: Approval.
Abstract: Summary of change: Delete the description about the need of indication to indicate 'UAV has been authenticated by the USS' in SMF services and Editor's note.

Comment:

Revision of (Noted) S2-2107150 from S2#147E. Remove Revision Marks from CR Cover! r01 agreed. Revised to S2-2109155.

Discussion and conclusion:

-

e-mail discussion:

Jaewoo (LGE) provides r01.
==== Revisions Deadline ====
Guanzhou (InterDigital) objects to the original version and is OK with r01.
==== Comments Deadline ====.

Status:

Revised to S2-2109155.

TD S2-2109155 (CR) 23.256 CR0002R2 (Rel-17, 'F'): Clarification and EN resolution for SMF Services. (Source: LG Electronics).
Document for: Approval.
Abstract: Summary of change: Clarify that AMF provides an indication to indicate 'UAV has been authenticated by the USS', if the UUAA has taken place during registration procedure by the AMF and delete the Editor's note.

Comment:

Revision of S2-2108553r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108628 (CR) 23.256 CR0039 (Rel-17, 'F'): Clarifications and corrections on UAV Re-authentication and the Networked Remote ID terminology. (Source: China Mobile).
Document for: Approval.
Abstract: Summary of change: 1. Remove the phrase 'Networked Remote ID' which only appears in the clause 3.1 and 3.2. 2. PDU Session IP address is replaced with 'PDU Session ID' in the related Figures of clause 5.2.4.1(step 3b), 5.2.4.2 (step 3) and 5.2.4.3(step 3b).

Comment:

r02 agreed. Revised to S2-2109156.

Discussion and conclusion:

-

e-mail discussion:

Stefano (Qualcomm) objects to this paper if networked Remote ID is removed.
Aihua(CMCC) asks Stefano (Qualcomm) for clarification.
Tricci (OPPO) prefers to keep the PDU Session IP and would like to propose to NOTE this CR because the changes are not needed.
Guanglei (Huawei) provides comments and thinks at least one change is needed and provides r01.
Pallab (Nokia) comments that changes in r01 is also not correct
Guanglei (Huawei) replies to Pallab(Nokia) and provides r02 to reflect Pallab's opinion
Stefano (Qualcomm) provides responses.
Guanglei (Huawei) thanks Stefano's (Qualcomm) clarification and propose to discuss r01 and r02.
Tricci (OPPO) thanks Guanglei (Huawei) for the update and withdraws previous objection.
Aihua(CMCC) suggests to proceed with r02.
==== Revisions Deadline ====
Stefano (Qualcomm) ok with r02, indicates to chair r00 is not acceptable.
==== Comments Deadline ====.

Status:

Revised to S2-2109156.

TD S2-2109156 (CR) 23.256 CR0039R1 (Rel-17, 'F'): Clarifications and corrections on UAV Re-authentication. (Source: China Mobile, Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: PDU Session IP address is replaced with 'PDU Session ID' in the related Figures of clause 5.2.4.1(step 3b), 5.2.4.2 (step 3) and 5.2.4.3(step 3b).

Comment:

Revision of S2-2108628r02. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108911 (CR) 23.502 CR3307 (Rel-17, 'F'): Correction on CAA-level UAV ID in AMF UE context. (Source: China Mobile).
Document for: Approval.
Abstract: Summary of change: CAA-Level UAV ID is added into UE context in AMF.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Pallab (Nokia) has the similar comments as in 8910. We need to first agree if AMF stores CAA-Level UAV Id in its context
Pallab (Nokia) provides r01 where CAA-Level UAV ID is changed to Service Level Device Identity. This is a revision to correct the identifier name. This should not be considered as Nokia's acceptance of the CR.
Pallab (Nokia) proposes to NOTE the CR based on objections in 8910.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108699 (CR) 23.256 CR0040 (Rel-17, 'F'): Correction on UAS NF discovery and UAS NF functionality. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Clarify that the UE provided USS address (i.e., a public address) is accessible to any UAS NF/NEF. Update and complete UAS NF functionality.

Comment:

r05 agreed. Revised to S2-2109157.

Discussion and conclusion:

-

e-mail discussion:

Stefano (Qualcomm) expresses concerns on the sentence wrt the use of USS Address for USS discovery and provides R01.
Guanglei (Huawei) replies and provides r02
Tricci (OPPO) asks Huawei for the further clarification for the proposed change from this CR
Guanglei (Huawei) replies to Tricci(OPPO)
Tricci (OPPO) thanks Guanglei (Huawei) reply and provides suggestion for the changes.
Guanglei (Huawei) provides r03
Dimitris (Lenovo) has a question on r03
Pallab (Nokia) asks for clarification on r03
Guanglei (Huawei) replies to Pallab(Nokia) and Demitris(Lenovo)
Tricci (OPP) understands the concern from Pallab (Nokia) and proposes further suggestions to the revised text.
Guanglei (Huawei) provides r04 to revise the UAS NF functionality.
Pallab (Nokia) comments.
Guanglei(Huawei) replies to Pallab (Nokia).
Guanglei(Huawei) provides r05 to remove the text about UAS NF storing subscription from USS
Tricci (OPPO) responds to Pallab (Nokia) comments.
Pallab (Nokia) is OK with r05.
==== Revisions Deadline ====
Tricci (OPPO) agrees to approve r05.
==== Comments Deadline ====.

Status:

Revised to S2-2109157.

TD S2-2109157 (CR) 23.256 CR0040R1 (Rel-17, 'F'): Correction on UAS NF discovery and UAS NF functionality. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Clarify that the UE provided USS address (i.e., a public address) is accessible to any UAS NF/NEF. Update and complete UAS NF functionality.

Comment:

Revision of S2-2108699r05. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108909 (CR) 23.256 CR0044 (Rel-17, 'F'): Corrections on usage of Nnef_AFsessionWithQoS service for UAS. (Source: China Mobile).
Document for: Approval.
Abstract: Summary of change: Incorrect inputs of Nnef_AFsessionWithQoS service when used for UAS service are corrected.

Comment:

Approved.

Discussion and conclusion:

-

e-mail discussion:

Guanglei(Huawei) ask for clarification.
Yi (China Mobile) reponds to Guanglei.
==== Revisions Deadline ====
Guanglei (Huawei) thanks Yi's clarification and is fine with r00
==== Comments Deadline ====.

Status:

Agreed.

TD S2-2108700 (CR) 23.501 CR3416 (Rel-17, 'F'): Correction on UAS NF discovery and update UAS related AF and NEF service. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Update AF and NEF service to reference to TS 23.256. Remove related NOTEs about USS address based UAS NF/NEF discovery.

Comment:

Confirm CR Number - CR states <empty> ! r02 agreed. Revised to S2-2109158.

Discussion and conclusion:

-

e-mail discussion:

Shabnam (Ericsson) comments that we need to first agree if USS information is to be used or not for UAS NF discovery. If this mechanism is kept, then we need to convert the NOTE into normative as the text is normative in the NOTE.
Guanglei(Huawei) replies to Shabnam (Ericsson).
Ashok (Samsung) comments
Tricci (OPPO) provides comments.
Pallab (Nokia) comments and suggests that capability of AMF/SMF to discover UAS NF/NEF based on UE provided USS address may be required in future.
Tricci (OPPO) would like to reiterate our preference to keep the existing NOTE - no issue to leverage the AF address (e.g. FQDN) to discover UAS NF.
Stefano (Qualcomm) asks whether there is a revision or what.
Guanglei(Huawei) provides r01
Pallab (Nokia) is OK with r01 and points out that cover page is missing CR number.
Pallab (Nokia) provides r02 to change the normative text in NOTE 'may' to 'can'. Also with cover page changes.
Dimitris (Lenovo) has concerns with using USS address for UAS NF/NEF discovery as it is not a complete solution
Pallab (Nokia) reminds that using USS address for UAS NF/NEF discovery is not the only option. It is an additional option that the AMF/SMF can use. Besides NEF already supports registering to NRF with domain names served by the NEF.
Shabnam (Ericsson) supports the latest version of the CR and clarifies that the function already exists in the spec as 'may' so changing to 'can' softens requirement.
Stefano (Qualcomm) proposes to postpone 8700 and 8701 together with 8724 until we have a complete view of the options and solutions.
Guanglei (Huawei) proposes to accept r01
==== Revisions Deadline ====
Shabnam (Ericsson) and the NOTE should not have 'may' normative text, should fix that too and go with latest revision. We still stay 'status quo' I believe.
Guanglei (Huawei) re-proposes to accept r02
Tricci (OPPO) supports to accept r02
==== Comments Deadline ====.

Status:

Revised to S2-2109158.

TD S2-2109158 (CR) 23.501 CR3416R1 (Rel-17, 'F'): Correction on UAS NF discovery and update UAS related AF and NEF service. (Source: Huawei, HiSilicon, Nokia, Nokia Shanghai Bell, Ericsson).
Document for: Approval.
Abstract: Summary of change: Update AF and NEF service to reference to TS 23.256. Remove normative text from the NOTE related to USS address based UAS NF/NEF discovery.

Comment:

Revision of S2-2108700r02. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108701 (CR) 23.502 CR3275 (Rel-17, 'F'): Correction on NEF discovery. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Remove the related NOTE about USS address based UAS NF/NEF discovery.

Comment:

Postponed.

Discussion and conclusion:

-

e-mail discussion:

Pallab (Nokia) indicates that this CR depends on the discussion in S2-2108700
Stefano (Qualcomm) asks whether there is a revision based on discussion of S2-2108700.
Pallab (Nokia) provides r01 to make the NOTE a normative text.
Dimitris (Lenovo) has concerns with r01
Stefano (Qualcomm) proposes to postpone 8700 and 8701 together with 8724 until we have a complete view of the options and solutions.
==== Revisions Deadline ====
Guanglei (Huawei) is fine to postpone
==== Comments Deadline ====.

Status:

Postponed.

TD S2-2108702 (CR) 23.256 CR0010R2 (Rel-17, 'F'): Clarification and Correction on AF and NEF authentication service. (Source: Huawei, HiSilicon, [Nokia, Nokia Shanghai Bell?], [LG Electronics?]).
Document for: Approval.
Abstract: Summary of change: 1. Addition of DNN,S-NSSAI and UAV location as input of Nnef_Authentication_Authenticate service operation. 2. Addition of Notify reason as input of Nnef/Naf_Authentication_Notification servie operation. 3. Remove notification endpoint from Nnef/Naf_Authentication_Notification service operation. 4. Addition of 'an indication whether the UAS service releated network resource can be released in case of UUAA failure' as optional output parameter of Nnef_Authentication_Authenticate service operation. 5. Clarify that the implicit subscription should be released implicitly by UAS NF/NEF and USS in the case of re-authentication failure and USS indicating to release network resource, or in the case of authorization revocation.

Comment:

Revision of (Agreed) S2-2107963 from S2#147E. Confirm Sources! r01 agreed. Revised to S2-2109159.

Discussion and conclusion:

-

e-mail discussion:

Jaewoo (LGE) would like to co-sign and provides r01.
Pallab (Nokia) OK with r01 and would like to co-sign.
DongYeon (Samsung) comments.
Jaewoo (LGE) responds to DongYeon (Samsung).
==== Revisions Deadline ====
Guanglei (Huawei) is ok with r01
==== Comments Deadline ====.

Status:

Revised to S2-2109159.

TD S2-2109159 (CR) 23.256 CR0010R3 (Rel-17, 'F'): Clarification and Correction on AF and NEF authentication service. (Source: Huawei, HiSilicon, Nokia, Nokia Shanghai Bell, LG Electronics).
Document for: Approval.
Abstract: Summary of change: 1. Addition of DNN,S-NSSAI and UAV location as input of Nnef_Authentication_Authenticate service operation. 2. Addition of Notify reason as input of Nnef/Naf_Authentication_Notification servie operation. 3. Remove notification endpoint from Nnef/Naf_Authentication_Notification service operation. 4. Addition of 'an indication whether the UAS service releated network resource can be released in case of UUAA failure' as optional output parameter of Nnef_Authentication_Authenticate service operation. 5. Clarify that the implicit subscription should be released implicitly by UAS NF/NEF and USS in the case of re-authentication failure and USS indicating to release network resource, or in the case of authorization revocation.

Comment:

Revision of S2-2108702r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108724 (CR) 23.256 CR0042 (Rel-17, 'F'): Clarification on discovering a UAS NF/NEF during UUAA-MM/UUAA-SM. (Source: Lenovo, Motorola Mobility,).
Document for: Approval.
Abstract: Summary of change: It is proposed to use the CAA-Level UAV ID as a means to discover the UAS NF.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Ashok (Samsung) comments and proposed to merge to S2-2108699
Stefano (Qualcomm) does not see the need to merge with S2-2108699
Ashok (Samsung) responds to Stefano (Qualcomm)
Guanglei (Huawei) provides comments and provides r01
Tricci (OPPO) also raised concern of the proposal for proposing to leverage CAA Level ID for AMF/SMF to discover UAS NF.
Pallab (Nokia) also raises concern on the proposal for using CAA Level ID for AMF/SMF to discover UAS NF.
Shabnam (Ericsson) shares similar view as Nokia and would be ok with 'AMF/SMF can discover based on local configuration or use UAS NF capability indication when discovering the NEF using NRF'.
Dimitris (Lenovo) can accept r01 provided by Guanglei (Huawei)
Pallab (Nokia) proposes to NOTE the CR. As discussed in 8700, we think it is good to keep the option of AMF/SMF discover UAS NF/NEF based on USS address provided by UE. Hence propose to NOTE this CR
Dimitris (Lenovo) points as described in 8700 that UAS NF/NEF discovery using USS address is not a complete solution
Pallab (Nokia) reminds that it is well defined how NEF is discovered based of AF address
Dimitris (Lenovo) responds to Pallab (Nokia)
Pallab (Nokia) responds to Dimitris (Lenovo)
Dimitris (Lenovo) further responds
Stefano (Qualcomm) OK to postpone the discussion on 8724 but will request to postpone 8700 and 8701 also.
==== Revisions Deadline ====
Tricci (OPPO) prefers to NOTE this CR based on the reason below.
Stefano (Qualcomm) comments.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108725 (CR) 23.502 CR3279 (Rel-17, 'F'): Clarification on discovering a UAS NF/NEF based on the USS address. (Source: Lenovo, Motorola Mobility,).
Document for: Approval.
Abstract: Summary of change: Removing NOTE 10 in clause 5.2.7.3.2 as the CAA-Level UAV ID is used to discover the UAS NF/NEF.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Pallab (Nokia) indicates that this CR is identical with S2-2108701 and should be merged. Also the CR depends on the discussion in 8700.
==== Revisions Deadline ====
Guanglei (Huawei) proposes to postpone
Tricci (OPPO) proposes to NOTE this CR for the same reason for 8724.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108723 (CR) 23.256 CR0041 (Rel-17, 'F'): Clarification on USS subscribing to a PDU session status event. (Source: Lenovo, Motorola Mobility,).
Document for: Approval.
Abstract: Summary of change: Clarifying that the USS always uses the T8 API event 'PDN Connectivity Status' event.

Comment:

Postponed.

Discussion and conclusion:

-

e-mail discussion:

Guanglei (Huawei) ask for clarification.
Shabnam (Ericsson) supports the intent of the CR and provides r01 correcting some editorials and normative language.
Guanglei(Huawei) provides comments.
Dimitris (Lenovo) responds
Guanglei(Huawei) kindly reminds that Stage 3 now supports PDU session status event via N33 interface.
Dimitris (Lenovo) provides clarifications
Guanglei(Huawei) replies
Dimitris (Lenovo) responds and provides r02
Guanglei (Huawei) thinks r02 is still not correct
Dimitris (Lenovo) disagrees with Huawei comment
Guanglei (Huawei) further clarifies
Dimitris (Lenovo) suggests to ask CT3 how the PDN Connectivity Status monitoring event is implemented in stage 3
Guanglei (Huawei) replies to Dimitris(Lenovo)
==== Revisions Deadline ====
Guanglei (Huawei) proposes to Postpone or Note
Dimitris (Lenovo) is ok to postpone, provided a draft LS out in the drafts folder
Guanglei (Huawei) re-proposes to NOTE and objects to send the LS just asking a simple question
==== Comments Deadline ====.

Status:

Postponed.

TD S2-2108910 (CR) 23.256 CR0045 (Rel-17, 'F'): Clarification on AMF determined re-authentication. (Source: China Mobile).
Document for: Approval.
Abstract: Summary of change: 1. Clarify that AMF determines to trigger subsequent re-authentication based on Aerial UE subscription information or local configuration; 2. Clarify that AMF stores CAA-Level UAV ID for further re-authentication.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Guanzhou (InterDigital) comments.
Yi (China Mobile) reponds to Guanzhou and provides r01.
Ashok (Samsung) comments whether AMF initiated reauth is valid scenario?
Pallab (Nokia) has the same question as Samsung.
Yi (China Mobile) replies.
Pallab (Nokia) objects to the CR and comments for further clarification
Ashok (Samsung) objects to the CR and all the revisions
==== Revisions Deadline ====
Guanzhou (InterDigital) comments and supports r01
Ashok (Samsung) responds to Yi
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108919 (CR) 23.256 CR0046 (Rel-17, 'F'): UE behaviour when AMF rejects registration due to missing aerial subscription. (Source: Lenovo, Motorola Mobility,).
Document for: Approval.
Abstract: Summary of change: Add a note indicate that how the UE handles rejection code 'UAS services not allowed' is addressed in stage 3.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Ashok (Samsung) proposes to NOTE
Stefano (Qualcomm) fully supports the CR and would like to cosign.
Ashok (Samsung) comments
Dimitris (Lenovo) responds
Ashok (Samsung) responds to Dimitris (Lenovo) and comments this CR is not needed
Tricci (OPPO) asks for clarification on why this CR is category 'F'?
Pallab (Nokia) suggests that the NOTE text needs to be revised based on updates in 8430 (if 8430 is agreed)
Tricci (OPPO) propose to NOTE this CR because it does not provide any added value or solve any issue.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

# 8.8 System enhancement for Proximity based Services in 5GS (5G_ProSe)

This agenda item was convened by Tao Sun (China Mobile).

## UE POLICY PROVISIONING REQUEST

TD S2-2108992 (LS IN) LS from RAN WG2: Reply LS on discovery and relay (re)selection. (Source: RAN WG2 (R2-2111583)).
Document for: Action.
Abstract: RAN WG2 thanks SA WG2 for the LS on discovery and relay (re)selection. RAN WG2 had discussed the LS in RAN WG2#116-e meeting, and provided RAN WG2 understanding on these issues as below: {. . .} Actions: To SA WG2: RAN WG2 kindly asks SA WG2 to take the above information into account for the future work.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Deng Qiang (CATT) asks Tao (VC) to move this reply LS to another sub-topic.
==== Revisions Deadline ====
Deng Qiang (CATT) this reply LS can be NOTED.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108284 (LS IN) LS from CT WG1: LS on UE POLICY PROVISIONING REQUEST message. (Source: CT WG1 (C1-216298)).
Document for: Action.
Abstract: CT WG1 thanks SA WG2 for their LS on UE POLICY PROVISIONING REQUEST message in S2-2106697/C1-215540. CT WG1 would like to provide the following feedback on points. CT WG1 cannot come into a conclusion on this issue and would like to ask the following questions for clarification to SA WG2: Q1) Whether the PCF shall include the latest V2X and/or ProSe policy to UE based on the service specific information from UDR when the UE includes UE STATE INDICATION in the Registration Request message regardless of UE POLICY PROVISIONING REQUEST. If the answer to Q1) is 'Yes', CT WG1 believes that the UE does not need to include 'UE POLICY PROVISIONING REQUEST message' in the Registration Request message when the UE needs to send 'UE STATE INDICATION message' to the PCF during the registration procedure. Because the 'UE STATE INDICATION message' can trigger the PCF to provide the latest UE policies based on the service specific information including the latest V2X and/or ProSe policy to the UE. Q2) If the answer to Q1) is 'No', how PCF handles both UE STATE INDICATION message and UE POLICY PROVISIONING REQUEST message received at the same time of UE policy association establishment procedure, given that each of them may result into separate MANAGE UE POLICY COMMAND message sent to the UE. If above aspects are clarified, CT WG1 can discuss whether to align with stage-2 requirement accordingly. Action: CT WG1 kindly asks SA WG2 to provide feedback.

Comment:

Responses drafted in S2-2108339, S2-2108453 and S2-2108582. Postponed.

Discussion and conclusion:

-

e-mail discussion:

Deng Qiang (CATT) proposed using this thread to discuss CT1 question first, before making CR revisions.
Hong (Qualcomm) comments.
Changhong (Intel) supports Qiang and Hong's proposal to start from what SA2 specification has.
Xiaoyan Shi (Interdigital) shares same view with Changhong, Qiang and Hong.
Belen (Ericsson) also shares the view that CT1 should follow SA2 design, and that is defined in 23.503, policy framework.
Changhong (Intel) asks Belen a question on Push and Pull mode.
Belen (Ericsson) replies to Intel
Dimitris (Lenovo) supports a solution that is backwards compatible
Susan (Huawei) cannot agree with the new proposal from Belen (Ericsson), and asks questions to Changhong (Intel).
Belen (Ericsson) comments to QC interpretation of the ANDSP support indicator.
Changhong (Intel) replies to Susan and Belen, proposes to use S2-2108453 as baseline for LS Reply to CT1.
Deng Qiang (CATT) comments.
Susan (Huawei) replies asks questions for clarification.
LaeYoung (LGE) replies to Susan (Huawei).
Sherry (Xiaomi) comments.
Hannu (Nokia) supports the proposal to take S2-2108453 as the way forward and replies to Sherry.
Hong (Qualcomm) replies to Susan.
Susan (Huawei) replies to LaeYoung (LGE).
Belen (Ericsson) agrees with Susan (Huawei).
==== Revisions Deadline ====
Changhong (Intel) comments and asks to stop challenging the design of having two separate indication for MM and UE Policy Container.
Susan (Huawei) replies to Sherry (Xiaomi).
Deng Qiang (CATT) provides spec for reference.
Yang (OPPO) comments
Belen (Ericsson) asks to POSPONE this LS given that no agreement on the answer and related CRs has been reached.
Susan (Huawei) replies to Deng Qiang (CATT).
Susan (Huawei) replies to Yang (OPPO).
Sherry (Xiaomi) replies.
Sherry (Xiaomi) replies to Hannu.
==== Comments Deadline ====.

Status:

Postponed.

TD S2-2109373 (LS IN) LS response on PC5 DRX for ProSe. (Source: RAN WG2 (R2-2111433)).
Document for: Action.
Abstract: RAN WG2 would like to thank SA WG2 for the incoming LS in R2-2111237/S2-2107979. RAN WG2 discussed the question asked by SA WG2 on whether PC5 DRX needs to be supported for 5G ProSe in Rel-17, and made the following agreements: For non-relay related ProSe communication and discovery: Agreements on SL-DRX for ProSe: 1: RAN WG2 confirm R17 SL-DRX design can support non-relay-related ProSe communication directly without additional specific solution discussion/specification effort. 2: RAN WG2 confirm the R17 SL-DRX design can support non-relay-related ProSe discovery by reusing SL default-DRX configuration used for communication without further additional specific solution discussion/specification effort. For relay related ProSe communication and discovery: Agreements on SL-DRX for ProSe: 1: RAN WG2 confirms Rel-17 SL-DRX design can be reused for relay-related ProSe communication in layer-3 relay without additional specific solution discussion/specification effort. 2: Keep RAN WG2 previous agreement (prioritize the non-relay case without consideration of relay specific optimization in Rel-17) but we're not going to make any conclusion if L2 relay-related ProSe communication is supported or not in Rel-17 now. 3: RAN WG2 confirms Rel-17 SL-DRX design can be reused for L3 relay-related ProSe discovery without additional specific solution discussion/specification effort (by applying SL default-DRX configuration). No conclusion if L2 relay-related ProSe discovery is supported or not in Rel-17 now. RAN WG2 does not specify any restriction now. Action: RAN WG2 respectfully asks SA WG2 to take the above agreements into account in future work.

Comment:

Postponed.

Discussion and conclusion:

-

Status:

Postponed.

TD S2-2108339 (LS OUT) [DRAFT] Reply LS on UE POLICY PROVISIONING REQUEST message. (Source: Ericsson).
Document for: Approval.
Abstract: Proposed reply LS to CT WG1 on the same topic.

Comment:

Response to S2-2108284. Noted.

Discussion and conclusion:

-

e-mail discussion:

Steve (Huawei) comments on relationship with discussion in S2-2108284, so can't be approved yet.
==== Revisions Deadline ====
Deng Qiang (CATT) this reply LS can be NOTED.
Changhong (Intel) objects to this LS OUT paper since no agreement has been reached yet.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108453 (LS OUT) [DRAFT] LS Reply to C1-216298 on UE Policy provisioning request. (Source: Intel Corporation (UK) Ltd).
Document for: Approval.
Abstract: LS Reply to C1-216298 on UE Policy provisioning request.

Comment:

Response to S2-2108284. Noted.

Discussion and conclusion:

-

e-mail discussion:

Sherry (Xiaomi) provides r01.
Changhong (Intel) provides r02.
Hannu (Nokia) provides r03 and points out that a revision of the related CR S2-2108452 is also needed to correct the CR number.
==== Revisions Deadline ====
Changhong (Intel) provides r04 with corrected CR number for the attachment.
Belen (Ericsson) objects to this LS reply given that the discussion took place in S2-2108284 and no conclusion was reached on the way forward.
Yang (OPPO) suggests to note or postpone the LS as no agreement is made in this meeting
Belen (Ericsson) asks Tao (VC) the reason to propose r03 and ask to NOTE this LS as is related to the same topic.
Tao (VC) change the status as Noted? For further checking
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108582 (LS OUT) [DRAFT] Reply LS on UE POLICY PROVISIONING REQUEST message. (Source: OPPO).
Document for: Approval.
Abstract: Reply LS of S2-2108284.

Comment:

Response to S2-2108284. Noted.

Discussion and conclusion:

-

e-mail discussion:

Steve (Huawei) comments on relationship with discussion in S2-2108284.
Hannu (Nokia) comments that S2-2108582 and S2-2108453 are draft replies to the same LS and proposes to reply based on S2-2108453r03.
==== Revisions Deadline ====
Changhong (Intel) objects to this paper since no agreement has been reached yet.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108341 (CR) 23.304 CR0042 (Rel-17, 'F'): ProSE policy provisioning request. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: - Include that the UE may send the list of stored PSIs, that includes ProSe PSIs. - Add references to 23.503 where PSI handling both at PCF; UDR and the UE is described. - Remove the explict request for ProSe policies from the UE at Registration.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Steve (Huawei) comments on relationship with discussion in S2-2108284.
==== Revisions Deadline ====
Deng Qiang (CATT) this CR not aligned with way-forward proposal discussed in 8284, and thus should be NOTED.
Belen (Ericsson) disagrees that there is a way forward agreed. If this CR is NOTED, then all related CRs to 8284 should also be NOTED
Deng Qiang (CATT) is fine to postponed or noted all the CRs related to the CT1 reply LS.
Changhong (Intel) objects to this paper since no agreement has been reached yet on the LS OUT.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108342 (CR) 23.503 CR0668 (Rel-17, 'F'): Removal of the V2X or ProSe policy request at Registration. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: - Remove the explict request for V2x/ProSe policies from the UE at Registration. - Define that the UE may request synchonization of V2x or ProSE policies at any time after Registration.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Mirko (Huawei) provides r01.
Steve (Huawei) comments on relationship with discussion in S2-2108284.
Hong (Qualcomm) comments on r01.
LaeYoung (LGE) comments on r01.
==== Revisions Deadline ====
Changhong (Intel) Objects to this paper.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108452 (CR) 23.304 CR0044 (Rel-17, 'F'): Correction for UE Policy Container. (Source: Intel, Qualcomm Incorporated).
Document for: Approval.
Abstract: Summary of change: Add the missting elements for UE Policy Container in 23.502.

Comment:

Confirm Specification Number - CR states 23.502!. Confirm Spec version used - CR states 17.2.1! r00 agreed. Revised to S2-2109139.

Discussion and conclusion:

-

e-mail discussion:

Hannu (Nokia) proposes that the CR must be revised to correct the CR number and possibly also the title as the CR number for this TS 23.502 CR is not drawn from the CR number range of the target specification (but possibly from the CR number range of TS 23.304?)
==== Revisions Deadline ====
Tao(VC) check the status of this paper
Changhong (Intel) comments.
Changhong (Intel) revised the paper into S2-2109139, the newly allocated CR number is 3314 .
Belen (Ericsson) objects to this CR as is related to S2-2108284 that reached no conclusions.

Status:

Revised to S2-2109139.

TD S2-2109139 (CR) 23.502 CR3314 (Rel-17, 'F'): Correction for UE Policy Container. (Source: Intel, Qualcomm Incorporated).
Document for: Approval.
Abstract: Summary of change: Add the missting elements for UE Policy Container in 23.502.

Comment:

Revision of S2-2108452r00. WITHDRAWN.

Discussion and conclusion:

-

Status:

Withdrawn.

TD S2-2108579 (CR) 23.304 CR0052 (Rel-17, 'F'): UE Policy Container with ProSe Policy Provisioning Request. (Source: OPPO).
Document for: Approval.
Abstract: Summary of change: The description of the ProSe Policy provisioning from Registration procedure is removed.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Steve (Huawei) comments on relationship with discussion in S2-2108284.
Hannu (Nokia) proposes to note this CR and proceed as shown in draft LS out S2-2108453r03.
==== Revisions Deadline ====
Belen (Ericsson) supports this CR, there is no agreement to go for draft LS out S2-2108453.
Changhong (Intel) objects to this paper since no agreement has been reached yet on the LS OUT.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108580 (CR) 23.503 CR0678 (Rel-17, 'F'): UE Policy Container with V2X and ProSe Policy Provisioning Request. (Source: OPPO).
Document for: Approval.
Abstract: Summary of change: In clause 6.1.2.2.2, The description of the V2X/ProSe Policy provisioning from Registration procedure is removed. Distribution of V2X/ProSe policy/parameters is refer to TS 23.287 and TS 23.304.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Steve (Huawei) comments on relationship with discussion in S2-2108284.
Hannu (Nokia) proposes to note this CR and proceed as shown in draft LS out S2-2108453r03.
==== Revisions Deadline ====
Changhong (Intel) objects to this paper since no agreement has been reached yet on the LS OUT.
==== Comments Deadline ====.

Status:

Noted.

## Mobility restriction

TD S2-2108382 (CR) 23.304 CR0027R2 (Rel-17, 'F'): EN resolve for mobility restriction. (Source: [vivo, Samsung, Nokia, Nokia Shanghai Bell,] Ericsson).
Document for: Approval.
Abstract: Summary of change: Clarify the following to resolve above EN: Non-Allowed Area: - In Non-allowed area of its serving PLMN, the 5G ProSe Layer-3 UE-to-Network Relay is not allowed to perform Relay operations e.g. Relay discovery or accept the relay connection setup. - Service Area Restriction are not applicable to the 5G ProSe Layer-3 Remote UE. - In Non-allowed area of its serving PLMN, the 5G ProSe Layer-2 Remote UE follows the same principles as specified in clause 5.3.4.1 of TS 23.501 [4] for communication with the network via the 5G ProSe Layer-2 UE-to-Network Relay. For emergency/priority access from a Remote UE to a Relay UE in non-allowed area, add a note that the emergency/priority access is not supported in this release of the specification. UE that can't communicate with the network due to Mobility Restrictions does not advertise itself as 5G ProSe UE-to-Network Relay.

Comment:

Revision of (Agreed) S2-2107978 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

Steve (Huawei) comments on overlap between S2-2108382, S2-2108949 & S2-2108956
Mehrdad (Samsung) suggests to use either S2-2108949 or S2-2108956 as the baseline.
Xiaoyan Shi (Interdigital) proposes to discuss mobility restriction in thread of S2-2108956.
Judy (Ericsson) is OK to have the discussion in 8956 to avoid same discussion in multiple threads.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108949 (CR) 23.304 CR0027R3 (Rel-17, 'F'): EN resolve for mobility restriction. (Source: Samsung).
Document for: Approval.
Abstract: Summary of change: It is proposed to use the following handlings to resolve above EN: Non-Allowed Area: - In Non-allowed area of its serving PLMN, the 5G ProSe Layer-3 UE-to-Network Relay is not allowed to perform Relay operations e.g. Relay discovery or accept the relay connection setup, except for as defined in TS24.501 [X] clause 5.3.5 (e.g. emergency services, high priority access) based on RSCs (pre-)configured for such conditions. - Service Area Restriction are not applicable to the 5G ProSe Layer-3 Remote UE. - In Non-allowed area of its serving PLMN, the 5G ProSe Layer-2 UE-to-Network Relay may perform Relay operations e.g. Relay discovery or accept the relay connection setup. - In Non-allowed area of its serving PLMN, the 5G ProSe Layer-2 Remote UE follows the same principles as specified in clause 5.3.4.1 of TS 23.501 [4] for communication with the network via the 5G ProSe Layer-2 UE-to-Network Relay. Editor's Note: whether the L2 Relay operation is allowed to perform only for exceptions (emergency services, high priority access) based on RSC configuration or for all Remote UEs will be FFS. UE that can't communicate with the network due to Mobility Restrictions does not advertise itself as 5G ProSe UE-to-Network Relay. Rev3: Clarified that UE that can't communicate with the network due to Mobility Restrictions does not advertise itself as 5G ProSe UE-to-Network Relay, except for conditions as defined in clause 5.3.5 of TS 24.501 [X].

Comment:

Revision of (Agreed) S2-2107978 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

Steve (Huawei) comments on overlap between S2-2108382, S2-2108949 & S2-2108956
Xiaoyan Shi (Interdigital) would suggest to merge this CR to S2-2108956.
Mehrdad (Samsung) is OK if we continue discussions in S2-2108956.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108956 (CR) 23.304 CR0027R4 (Rel-17, 'F'): EN resolve for mobility restriction. (Source: Interdigital Inc).
Document for: Approval.
Abstract: Summary of change: It is proposed to use the following handlings to resolve above EN: Non-Allowed Area: - In Non-allowed area of its serving PLMN, the 5G ProSe Layer-3 UE-to-Network Relay is not allowed to perform Relay operations e.g. Relay discovery or accept the relay connection setup, except for as defined in TS24.501 [X] clause 5.3.5 (e.g. emergency services, high priority access) based on RSCs (pre-)configured for such conditions. - Service Area Restriction are not applicable to the 5G ProSe Layer-3 Remote UE. - In Non-allowed area of its serving PLMN, the 5G ProSe Layer-2 UE-to-Network Relay may perform Relay operations e.g. Relay discovery or accept the relay connection setup. - In Non-allowed area of its serving PLMN, the 5G ProSe Layer-2 Remote UE follows the same principles as specified in clause 5.3.4.1 of TS 23.501 [4] for communication with the network via the 5G ProSe Layer-2 UE-to-Network Relay. Editor's Note: whether the L2 Relay operation is allowed to perform only for exceptions (emergency services, high priority access) based on RSC configuration or for all Remote UEs will be FFS. UE that can't communicate with the network due to Mobility Restrictions does not advertise itself as 5G ProSe UE-to-Network Relay.

Comment:

Revision of (Agreed) S2-2107978 from S2#147E. Confirm CR Revision - CR states 2! Noted.

Discussion and conclusion:

-

e-mail discussion:

Fei (OPPO) comments.
Steve (Huawei) comments on overlap between S2-2108382, S2-2108949 & S2-2108956
Xiaoyan Shi (Interigital) replies to Fei.
Judy (Ericsson) comments
LaeYoung (LGE) provides comment.
Fei (OPPO) responds to Xiaoyan (Interdigital)
Deng Qiang (CATT) provides comment.
Wen (vivo) provides comment.
Jianning (Xiaomi) shares the view from Qiang (CATT)
Xiaoyan Shi (Interdigital) comments
Hong (Qualcomm) comments.
Mehrdad (Samsung) comments
Judy (Ericsson) provides r01 to reflect the proposal in 8382: L2 Relay UE in Non-allowed not performing relay operations, and emergency/priority access from Remote UE via Relay UE in Non-allowed area to be studied in Rel-18.
Xiaoyan Shi (Interdigital) objects r01and provides r02. R01 overthrows agreement in last meeting and Xiaoyan Shi have not identified any technical reason to block NW relay service in Non-allowed area.
Judy (Ericsson) is not sure what agreement that Xiaoyan Shi (Interdigital) refers to considering there was a misunderstanding of revisions last meeting as discussed offline. r01 is just one of the alternatives under discussion.
Fei (OPPO) comments and provides r03.
Wen (vivo) comments and provides r04.
Mehrdad (Samsung) provides r05.
Steve (Huawei) comments on r05, and in general.
==== Revisions Deadline ====
Hong (Qualcomm) replies.
Mehrdad (Samsung) replies.
Xiaoyan Shi (Interdigital) replies.
Hong (Qualcomm) replies to Xiaoyan.
LaeYoung (LGE) accepts only r01 and objects all other versions including r00.
Judy (Ericsson) comments accepts only r01 and objects all other versions including r00.
Mehrdad (Samsung) objects to r01. We can not agree with that.
Fei (OPPO) asks if no revision can be agreed in this meeting, whether the 2107978 is still agreed.
Mehrdad (Samsung) is not clear on OPPO's question
Steve (Huawei) looks like mutual objections to all revisions, so no update this meeting.
Fei (OPPO) thanks for Steve's clarification.
==== Comments Deadline ====.

Status:

Noted.

## RDAI message

TD S2-2108522 (CR) 23.304 CR0019R2 (Rel-17, 'F'): Clarification on Relay Discovery Additional Information message. (Source: CATT, ZTE, Intel).
Document for: Approval.
Abstract: Summary of change: In rev1: (1) Add NCGI, Relay TAI and other parameters for Relay Discovery Additional Information message in clause 5.8.3.2. (2) Align the descriptions about Relay Discovery Additional Information message in clause 6.3.2.3.1, 6.3.2.3.2 and 6.5.1.3. In rev2: Extend cell ID annoucement procedure to accommodate more parameters, e.g. TAI of Layer-3 Relay. Source and Destination Layer-2 IDs for RDAI message are clarified.

Comment:

Revision of (Agreed) S2-2107974 from S2#147E. Remove Revision Marks from CR Cover! r08 agreed. Revised to S2-2109160, merging S2-2108488 and S2-2108558.

Discussion and conclusion:

-

e-mail discussion:

Zhang (Ericsson) asks clarification
Deng Qiang (CATT) replies to Zhang (Ericsson) and provides r01 that merged 8558.
Wen (vivo) comments on r01.
Fei (OPPO) asks questions.
Deng Qiang (CATT) replies to Fei (OPPO) and Wen (vivo).
Wen (vivo) replies to Deng Qiang (CATT)
Zhang (Ericsson) is OK with r01 and co-sign
Zhang (Ericsson) provides comments
Steve (Huawei) comments
Mehrdad (Samsung) comments on original version and r01.
Hong (Qualcomm) replies to Wen.
Wen (vivo) is ok to merge to 8522.
Deng Qiang (CATT) provides r02 based on Mehrdad (Samsung) constructure proposal.
LaeYoung (LGE) provides r03.
Fei (OPPO) provides r04.
Deng Qiang (CATT) replies to LaeYoung (LGE).
LaeYoung (LGE) replies to Deng Qiang (CATT).
Hao Dong (ZTE) provides version r05 with some editorial changes in clause 6.5.1.3.
Steve (Huawei) provides r07
Hao Dong (ZTE) responds to Zhang (Ericsson).
Fei (OPPO) responds to Zhang (Ericsson).
Wen (vivo) comments.
Xiaoyan Shi (Interdigital) provides comments
Deng Qiang (CATT) provides r08.
Mehrdad (Samsung) asks a question for clarification
Deng Qiang (CATT) replies to Mehrdad (Samsung).
Hannu (Nokia) points out that new LS in from RAN2 in S2-2108992 (sent from RAN2 last week) would be related with this.
Fei (OPPO) responds to Mehrdad (Samsung)
Hannu (Nokia) replies to Mehrdad. Can accept either approach as long as SA2 and RAN2 are aligned.
Deng Qiang (CATT) replies to Mehrdad (Samsung) and Hannu (Nokia).
==== Revisions Deadline ====
Zhang (Ericsson) is fine with r08
LaeYoung (LGE) is also fine with r08.
LaeYoung (LGE) responds to Zhang (Ericsson).
Hong (Qualcomm) comments.
==== Comments Deadline ====.

Status:

Revised to S2-2109160, merging S2-2108488 and S2-2108558.

TD S2-2109160 (CR) 23.304 CR0019R4 (Rel-17, 'F'): Clarification on Relay Discovery Additional Information message. (Source: CATT, ZTE, Intel, Huawei, HiSilicon, Ericsson, Samsung, vivo, LG Electronics).
Document for: Approval.
Abstract: Summary of change: In rev1: (1) Add NCGI, Relay TAI and other parameters for Relay Discovery Additional Information message in clause 5.8.3.2. (2) Align the descriptions about Relay Discovery Additional Information message in clause 6.3.2.3.1, 6.3.2.3.2 and 6.5.1.3. In rev2: Extend cell ID annoucement procedure to accommodate more parameters, e.g. TAI of Layer-3 Relay. Document common parameters for both Layer-2 and Layer-3 Relays in RDAI message in clause 5.8.3.1. Source and Destination Layer-2 IDs for RDAI message are clarified. Destination Layer-2 ID for discovery messages is clarified. In rev4: Cleanup of rev2.

Comment:

Revision of S2-2108522r08, merging S2-2108488 and S2-2108558. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108558 (CR) 23.304 CR0019R3 (Rel-17, 'F'): Clarification on Relay Discovery Additional Information message. (Source: Based on [CATT, ZTE, Intel], vivo).
Document for: Approval.
Abstract: Summary of change: (1) Add NCGI, Relay TAI and other parameters for Relay Discovery Additional Information message in clause 5.8.3.2. (2) Align the descriptions about Relay Discovery Additional Information message in clause 6.3.2.3.1, 6.3.2.3.2 and 6.5.1.3. In rev2: (is highlighted with green) Add the following configuration for relay to determine the DST L2 ID of the Relay Discovery Additional Information message: Default Destination Layer-2 ID(s) for sending and receiving Relay Discovery Additional Information message.

Comment:

Revision of (Agreed) S2-2107974 from S2#147E. Merged into S2-2109160.

Discussion and conclusion:

-

e-mail discussion:

Zhang (Ericsson) provides comments and r01
Hao Dong (ZTE) proposes to merge this CR into S2-2108522 since both of them are based on the same agreed CR (S2-2107974) from the last SA2 meeting.
Deng Qiang (CATT) proposes to merge this CR into S2-2108522r01.
Mehrdad (Samsung) proposes to merge this CR S2-2108522.
Xiaoyan Shi (Interdigital) proposes to merge it to S2-2108522.
Wen (vivo) is ok to merge this paper into 8522.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Merged into S2-2109160.

TD S2-2108488 (CR) 23.304 CR0045 (Rel-17, 'F'): TAI announcement procedure. (Source: LG Electronics).
Document for: Approval.
Abstract: Summary of change: Add TAI announcement procedure.

Comment:

Merged into S2-2109160.

Discussion and conclusion:

-

e-mail discussion:

Zhang (Ericsson) propose the merge the paper with S2-2108522
LaeYoung (LGE) responds to Zhang (Ericsson).
Hong (Qualcomm) replies to Laeyoung.
LaeYoung (LGE) responds to Hong (Qualcomm) and is fine to merge this CR to S2-2108522.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Merged into S2-2109160.

## UE-to-Network Relay

TD S2-2108324 (CR) 23.304 CR0032R1 (Rel-17, 'B'): Security procedures for L3 relaying. (Source: Nokia, Nokia Shanghai Bell, Interdigital Inc., LG Electronics).
Document for: Approval.
Abstract: Summary of change: Add general clause on L3 relay security and detailed call flow for authentication and authorisation of 5G ProSe Layer-3 UE-to-Network relaying and remove the unused clause 5.1.4.3.

Comment:

Revision of (Postponed) S2-2107566 from S2#147E. Postponed.

Discussion and conclusion:

-

e-mail discussion:

Zhang (Ericsson) provides comments
Fei (OPPO) comments this should be postponed until SA3 has documented the detailed procedure.
Deng Qiang (CATT) proposed this CR postponed.
Steve (Huawei) waiting for SA3 was also my understanding
Hannu (Nokia) comments on behalf of CR proponents and agrees to wait for SA3 guidance.
==== Revisions Deadline ====
Steve (Huawei) thanks Hannu for the clarification, should be postponed.
==== Comments Deadline ====.

Status:

Postponed.

TD S2-2108381 (CR) 23.304 CR0013R1 (Rel-17, 'F'): Removing the EN of policy control for L3 U2N Relay. (Source: OPPO, Ericsson, LG Electronics).
Document for: Approval.
Abstract: Summary of change: Remove the EN in clause 5.4.1.3 and clarify the policy control function specified in TS 23.503 is applied.

Comment:

Revision of (Agreed) S2-2107325 from S2#147E. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108451 (CR) 23.304 CR0012R2 (Rel-17, 'F'): Clarification for the PC5 QoS parameters and PC5 QoS rule. (Source: OPPO, Ericsson).
Document for: Approval.
Abstract: Summary of change: Remove Range from the PC5 QoS parameters from the clause 5.6.2.1 description. Clarify for the QoS Flows setup initiated by network, Relay UE provides the PC5 QoS rule to L3 Remote UE. Clarify PC5 QoS rule may be exchanged between Peer UEs for direct PC5 communication. Add ProSe identifier as an optional parameter in the PC5 QoS rule.

Comment:

Revision of (Agreed) S2-2107990 from S2#147E. Approved.

Discussion and conclusion:

-

e-mail discussion:

Steve (Huawei) asks some questions
Yali (OPPO) replies to Steve
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Agreed.

TD S2-2108802 (CR) 23.304 CR0055 (Rel-17, 'F'): Update on Unicast link profile for UE-to-Network Relay. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Describe the Unicast Link Profile for UE-to-Network Relay.

Comment:

Approved.

Discussion and conclusion:

-

e-mail discussion:

Fei (OPPO) asks questions.
Hao Dong (ZTE) comments.
Zhang (Ericsson) provides comments
Hao Dong (ZTE) responds to Zhang (Ericsson).
Steve (Huawei) replies to Fei.
Steve (Huawei) comments on explicit reference for direct comms
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Agreed.

TD S2-2108523 (CR) 23.304 CR0046 (Rel-17, 'F'): Resolve some ENs. (Source: CATT).
Document for: Approval.
Abstract: Summary of change: 1) add reference to TS 33.503 and remove the EN in scope section. 2) convert the EN to NOTE in clause 5.12. 3) remove the EN in clause 6.4.3.6.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Fei (OPPO) comments.
Deng Qiang (CATT) this CR can be NOTED as it is covered by other CRs.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108801 (CR) 23.304 CR0054 (Rel-17, 'F'): Updates and alignments based on further RAN WG2 feedback. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Correct that the 5G ProSe authorised information includes whether the UE is authorized to act as a 5G ProSe Layer-3 Remote UE. Remove the EN in clause 6.4.3.6. Clarify the connection of Layer-2 UE-to-Network Relay can be released by the netowrk, even though there is any serving Remote UE in RRC Connected state.

Comment:

r03 agreed. Revised to S2-2109161, merging S2-2108560.

Discussion and conclusion:

-

e-mail discussion:

Zhang (Ericsson) provides comments and ask for clarification
Wen (vivo) provides comments
Steve (Huawei) replies
Steve (Huawei) comments
Xiaoyan Shi (Interdigital) have same question with Zhang Fu
Hong (Qualcomm) replies to Steve.
Deng Qiang (CATT) comments.
Fei (OPPO) comments.
Steve (Huawei) provides r01
Hong (Qualcomm) comments.
Hannu (Nokia) comments and provides r02.
Steve (Huawei) provides r03
==== Revisions Deadline ====
Zhang (Ericsson) is OK with r03
==== Comments Deadline ====
Hannu (Nokia) thanks Steve and supports r03.

Status:

Revised to S2-2109161, merging S2-2108560.

TD S2-2109161 (CR) 23.304 CR0054R1 (Rel-17, 'F'): Updates and alignments based on further RAN WG2 feedback. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Remove the EN in clause 6.4.3.6. Clarify the connection of Layer-2 UE-to-Network Relay can be released by the network, even though there is any serving Remote UE in RRC Connected state.

Comment:

Revision of S2-2108801r03, merging S2-2108560. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108559 (CR) 23.304 CR0047 (Rel-17, 'F'): Registration Procedure to enter CM_CONNECTED for L2 relay. (Source: Vivo).
Document for: Approval.
Abstract: Summary of change: For L2 relay, if the 5G ProSe Layer-2 UE-to-Network Relay is in RM-DEREGISTERED, and receives a trigger from the AS layer to enter CM-CONNECTED state due to Remote UE's AS layer connection set up with the NG-RAN, the 5G ProSe Layer-2 UE-to-Network Relay performs Registration procedure in the clause 4.2.2.2 of TS 23.502 [5].

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Fei (OPPO) commets.
Wen (vivo) replies.
Judy (Ericsson) comments.
Wen (vivo) replies to Judy (Ericsson).
Judy (Ericsson) responds to Wen (vivo)
Deng Qiang (CATT) comments.
Wen (vivo)responds to Judy (Ericsson) and Deng Qiang (CATT)
Fei (OPPO) comments
Wen (vivo)responds to Fei(OPPO)
Hong (Qualcomm) repleis to Wen.
Jianning (Xiaomi) provides view
Wen (vivo) repleis to Hong (Qualcomm).
Hong (Qaulcomm) replies to Wen.
Wen (vivo) replies to Hong (Qaulcomm).
Wen (vivo) further provides r01.
Hannu (Nokia) still can't see the justification for this CR even in r01. Proposes to note the CR.
Wen (vivo) replies to Hannu (Nokia) and don't agree with NOTE .
Hong (Qualcomm) comments.
Wen (vivo) replies to Hong.
==== Revisions Deadline ====
Hong (Qualcomm) replies to Wen.
Wen (vivo) replies to Hong (Qualcomm).
Judy (Ericsson) also propose to NOTE this paper which is based on a misundersanding of the spec.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108560 (CR) 23.304 CR0048 (Rel-17, 'F'): Clarification on CM_CONNECTED state for L2 relay. (Source: Vivo).
Document for: Approval.
Abstract: Summary of change: In clause 6.5.2.1.2, change the 'should' to 'shall'.

Comment:

Merged into S2-2109161.

Discussion and conclusion:

-

e-mail discussion:

Deng Qiang (CATT) propose to be merged with S2-2108801.
Steve (Huawei) Should be NOTED or considered merged to S2-2108801.
Wen (vivo) is ok to merge this paper to S2-2108801.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Merged into S2-2109161.

TD S2-2108578 (CR) 23.304 CR0051 (Rel-17, 'F'): PC5 link release and CM state update for L2 U2N relay. (Source: OPPO).
Document for: Approval.
Abstract: Summary of change: The CM states for the remote UE and relay UE are updated. The AS triggering the PC5 link release is captured.

Comment:

r07 agreed. Revised to S2-2109162.

Discussion and conclusion:

-

e-mail discussion:

LaeYoung (LGE) provides r01.
Wen (vivo) comments.
Fei (OPPO) provides r02.
Wen (vivo) provides r03.
Lars (Sony) asks questions
Fei (OPPO) responds to Lars (Sony).
Steve (Huawei) comments
Wen (vivo) replies to Steve (Huawei)
Hong (Qualcomm) comments.
Steve (Huawei) thanks for the clarifications
Wen (vivo) replies to Hong (Qualcomm).
Fei (OPPO) comments.
Fei (OPPO) responds and provides r04.
Wen (vivo) comments and provides r05.
Fei (OPPO) responds and provides r06.
Steve (Huawei) provides r07
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109162.

TD S2-2109162 (CR) 23.304 CR0051R1 (Rel-17, 'F'): PC5 link release and CM state update for L2 U2N relay. (Source: OPPO).
Document for: Approval.
Abstract: Summary of change: The CM states for the remote UE and relay UE are updated. The AS triggering the PC5 link release is captured.

Comment:

Revision of S2-2108578r07. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108722 (CR) 23.304 CR0053 (Rel-17, 'F'): Clarification on Parameters Used in UE-to-Network Relay Discovery Message. (Source: ZTE).
Document for: Approval.
Abstract: Summary of change: Add UE-to-Network Relay Layer Indicator(s) parameter in the corresponding description for 5G ProSe UE-to-Network Relay Discovery in clause 5.8.3.1, and in the corresponding detailed procedures in section 6.3.2.3.2 and 6.3.2.3.3.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Fei (OPPO) comments.
Hao Dong (ZTE) responds to Fei (OPPO).
Fei (OPPO) responds to Hao (ZTE)
LaeYoung (LGE) provides comment.
Hao Dong (ZTE) thanks for clarification and confirms the CR could be NOTED.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108804 (CR) 23.304 CR0031R2 (Rel-17, 'F'): PDU Session release for L3 U2N Relay on authorisation revocation. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: If the 5G ProSe Layer-3 UE-to-Network Relay releases the PDU Session(s) used for relaying when the service authorisation for acting as a 5G ProSe Layer-3 UE-to-Network Relay is revoked.

Comment:

Revision of (Agreed) S2-2107987 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

Judy (Ericsson) comments
Steve (Huawei) replies
Mehrdad replies to Huawei and Ericsson.
Judy (Ericsson) comments the update in 8804 seems not absolutely necessary, and provides r01 as an alternative
Steve (Huawei) is ok with r01.
Hannu (Nokia) provides even simpler r02 and comments.
Steve (Huawei) comments
==== Revisions Deadline ====
Hannu (Nokia) complains about premature revision deadline and shows what was left not done in r01.
Hannu (Nokia) requests to disregard his previous comment on 8804 as document 8951 was targeted. Sorry for confusion when rushing to meet the deadline (and still failed)
Steve (Huawei) wrong CR?
Hannu (Nokia) replies to Steve that the CR is probably right but my one of my two comments with the same words was wrong --
Judy (Ericsson) assumes this paper can be NOTED based on the discussion, i.e. 7987 agreed in SA2#147E will be kept unchanged.
Steve (Huawei) can be NOTED, thanks for the discussion.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108807 (DISCUSSION) Discussion on Dual PDU session for the IPsec connection to N3IWF.. (Source: Sony).
Document for: Agreement.
Abstract: Discuss the option that the 5G ProSe Layer-3 UE-to-Network Relay may also use different PDU Sessions for the signalling traffic (e.g. IKE signalling) and for the user plane traffic of the 5G ProSe Layer-3 Remote UE via N3IWF.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108816 (CR) 23.304 CR0057 (Rel-17, 'F'): N3IWF connection via Dual PDU sessions. (Source: Sony).
Document for: Approval.
Abstract: Summary of change: Adding a new step 7 to describe how QoS is supported over N3IWF as described in clause 5.6.2.2 Replace the option to use two PDU sessions as discussed in S2-2108807 with an Editor's Note as this option need much more details on how it works.

Comment:

r02 agreed. Revised to S2-2109163.

Discussion and conclusion:

-

e-mail discussion:

Yali (OPPO) comments
Lars (Sony) provides r01
Steve (Huawei) comments, let's not add ENs now!
Zhang (Ericsson) provides r02
Lars (Sony) r02 looks good.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109163.

TD S2-2109163 (CR) 23.304 CR0057R1 (Rel-17, 'F'): N3IWF connection via Dual PDU sessions. (Source: Sony).
Document for: Approval.
Abstract: Summary of change: Adding a new step 7 to describe how QoS is supported over N3IWF as described in clause 5.6.2.2 Remove the option to use two PDU sessions as discussed in S2-2108807 as this option need much more details on how it works.

Comment:

Revision of S2-2108816r02. Approved.

Discussion and conclusion:

-

Status:

Agreed.

## Miscellaneous corrections

TD S2-2108414 (CR) 23.502 CR3232 (Rel-17, 'F'): Update to Nnrf_NFManagement_NFRegister service operation. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: Add missing ProSe capability for PCF profile and PCF discovery.

Comment:

r01 agreed. Revised to S2-2109164.

Discussion and conclusion:

-

e-mail discussion:

Steve (Huawei) asks questions
Judy (Ericsson) provides r01 and responds to Steve (Huawei)
==== Revisions Deadline ====
Steve (Huawei) is ok with r01.
==== Comments Deadline ====.

Status:

Revised to S2-2109164.

TD S2-2109164 (CR) 23.502 CR3232R1 (Rel-17, 'F'): Update to Nnrf_NFManagement_NFRegister service operation. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: Add missing ProSe capability for PCF profile and PCF discovery.

Comment:

Revision of S2-2108414r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108489 (CR) 23.501 CR3378 (Rel-17, 'F'): Fix reference for Naf_ProSe. (Source: LG Electronics).
Document for: Approval.
Abstract: Summary of change: Modify reference for the Naf_ProSe service from TS 23.502 to TS 23.304.

Comment:

r02 agreed. Revised to S2-2109165.

Discussion and conclusion:

-

e-mail discussion:

Fei (OPPO) comments.
LaeYoung (LGE) provides r01.
Judy (Ericsson) provides r02
Fei (OPPO) is ok with r01 and r02.
LaeYoung (LGE) is fine with r02.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109165.

TD S2-2109165 (CR) 23.501 CR3378R1 (Rel-17, 'F'): Fix reference for Naf_ProSe. (Source: LG Electronics).
Document for: Approval.
Abstract: Summary of change: Modify reference for the Naf_ProSe service from TS 23.502 to TS 23.304.

Comment:

Revision of S2-2108489r02. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108561 (CR) 23.304 CR0049 (Rel-17, 'F'): Miscellaneous clarifications and corrections. (Source: Vivo).
Document for: Approval.
Abstract: Summary of change: Remove the 'E-UTRA' and change the 'served by NR' to 'served by NG-RAN' Add the following configuration to Relay: 'Validity time indicating the expiration time of the Policy/Parameter for 5G ProSe UE-to-Network Relay discovery and communication.'.

Comment:

r01 agreed. Revised to S2-2109166.

Discussion and conclusion:

-

e-mail discussion:

Hao Dong (ZTE) provides revision r01.
Wen (vivo) is ok with r01.
Hannu (Nokia) provides r02. E-UTRAN should be kept as it is included for cross-carrier operation.
Wen (vivo) replies to Hannu and comments on r02.
Steve (Huawei) comments on E-UTRAN
==== Revisions Deadline ====
Wen (vivo) proposes r01 should be agreed and can live with r00.
Hao Dong (ZTE) supports r01.
Steve (Huawei) supports r01.
Fei (OPPO) supports r01 as well.
==== Comments Deadline ====
Hannu (Nokia) asks for technical explanation why r02 is not correct?

Status:

Revised to S2-2109166.

TD S2-2109166 (CR) 23.304 CR0049R1 (Rel-17, 'F'): Miscellaneous clarifications and corrections. (Source: Vivo).
Document for: Approval.
Abstract: Summary of change: Remove the 'E-UTRA' and change the 'served by NR' to 'served by NG-RAN' Add the following configuration to Relay: 'Validity time indicating the expiration time of the Policy/Parameter for 5G ProSe UE-to-Network Relay discovery and communication.'.

Comment:

Revision of S2-2108561r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108577 (CR) 23.304 CR0050 (Rel-17, 'F'): Clarification on the ID for Group discovery. (Source: OPPO).
Document for: Approval.
Abstract: Summary of change: It is clarified that the target info does not contain the group id info.

Comment:

r03 agreed. Revised to S2-2109330.

Discussion and conclusion:

-

e-mail discussion:

Zhang (Ericsson) provides comments and r01 and co-sign the paper
Fei (OPPO) is ok with r01.
Hao Dong (ZTE) comments.
Fei (OPPO) responds to Hao (ZTE) and provides r02.
Hao Dong (ZTE) thanks for the revision and is fine with r02.
Fei (OPPO) responds to Zhang (Ericsson).
Zhang (Ericsson) provides r03
Hao Dong (ZTE) comments on r03.
Steve (Huawei) asks for clarification on optional.
Fei (OPPO) responds to Steve (Huawei)
Steve (Huawei) thanks, quick follow up.
Steve (Huawei) thanks for the clarification.
==== Revisions Deadline ====
Changhong (Intel) comments on the 'Reason for Change'.
Fei (OPPO) responds to request from Changhong (Intel)
Changhong (Intel) asks to keep it open for CC#2. I am OK with Fei proposed text for the Reason for Change and ask Fei to provide a revision.
Fei (OPPO) provides r03+ version in the drafts folder to add one sentence in the reason for change.
==== Comments Deadline ====.

Status:

Revised to S2-2109330.

TD S2-2109330 (CR) 23.304 CR0050R1 (Rel-17, 'F'): Clarification on the ID for Group discovery. (Source: OPPO, Ericsson).
Document for: Approval.
Abstract: Summary of change: It is clarified that the target info does not contain the group id info.

Comment:

Revision of S2-2108577r03. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108985 (CR) 23.304 CR0059 (Rel-17, 'F'): User Info ID clarifications. (Source: Philips International B.V, Ericsson, Interdigital Inc.).
Document for: Approval.
Abstract: Summary of change: Change 1: remove how the User Info ID is used from the definition of User Info ID. Not needed to have that as part of the definition. Better to clarify the respective clauses on discovery and connection setup instead. Change 2: clarification that announcer info, discoverer info and discoveree info are related to User Info ID. The necessary clarifications were added already for group discovery (e.g. in 5.1.2.1 and 5.8.1), but not yet for UE-to-Network relay discovery. Change 3: clarification on which identity/identities to use as Source User Info parameter during layer-2 link layer setup with UE-to-Network relay will be decided by SA WG3, since it relates to their user-plane and control plane authorization procedures. Change 4: clarification on which identity is used for Remote UE report. Change 5: remove 'User Info' in relation to Application Layer ID from clause 5.6.1, since this may cause further confusion.

Comment:

r03 agreed. Revised to S2-2109167.

Discussion and conclusion:

-

e-mail discussion:

Steve (Huawei) comments
Hao Dong (ZTE) comments.
Walter Dees (Philips) responds to the comments from Huawei and ZTE
Hong (Qualcomm) comments.
Walter (Philips) provides comments and requests clarification.
Fei (OPPO) comments.
Xiaoyan Shi (Interdigital) provides r01.
Changhong (Intel) provides r02.
Walter Dees (Philips) prefers r00 or r01
Walter Dees (Philips) provides revision r03.
==== Revisions Deadline ====
Changhong (Intel) is OK with r03.
Steve (Huawei) supports r02, stage 3 in general is fine. R03 is too specific.
Zhang (Ericsson) is OK with r00, 01, 03
Steve (Huawei) comments.
Steve (Huawei) clarifies can live with other versions, but prefers r02
==== Comments Deadline ====.

Status:

Revised to S2-2109167.

TD S2-2109167 (CR) 23.304 CR0059R1 (Rel-17, 'F'): User Info ID clarifications. (Source: Philips International B.V, Ericsson, Interdigital Inc.).
Document for: Approval.
Abstract: Summary of change: Change 1: remove how the User Info ID is used from the definition of User Info ID. Not needed to have that as part of the definition. Better to clarify the respective clauses on discovery and connection setup instead. Change 2: clarification that announcer info, discoverer info and discoveree info are related to User Info ID. The necessary clarifications were added already for group discovery (e.g. in 5.1.2.1 and 5.8.1), but not yet for UE-to-Network relay discovery. Change 3: clarification on which identity/identities to use as Source User Info parameter during layer-2 link layer setup with UE-to-Network relay will be decided by SA WG3, since it relates to their user-plane and control plane authorization procedures. Change 4: avoid confusion on which identity is used for Remote UE report. Change 5: remove 'User Info' in relation to Application Layer ID from clause 5.6.1, since this may cause further confusion.

Comment:

Revision of S2-2108985r03. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108803 (CR) 23.304 CR0056 (Rel-17, 'F'): Clarification on subscription information to 5G ProSe. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Clarify that PC5 QoS parameters are provided by the PCF and the list of the PLMNs authorized for 5G ProSe services are contained both in UDM and PCF. Add Naf service to clause 4.2.6.

Comment:

r01 agreed. Revised to S2-2109168.

Discussion and conclusion:

-

e-mail discussion:

Judy (Ericsson) provide r01
Guanglei (Huawei) replies to Judy(Ericsson)
Mehrdad (Samsung) also agrees with r01 from Ericsson.
Guanglei(Huawei) replies to Mehrdad(Samsung).
Hannu (Nokia) supports r01 as the initial version is not correct.
==== Revisions Deadline ====
Guanglei (Huawei) is fine with r01
==== Comments Deadline ====.

Status:

Revised to S2-2109168.

TD S2-2109168 (CR) 23.304 CR0056R1 (Rel-17, 'F'): Clarification on subscription information to 5G ProSe. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Add Naf service to clause 4.2.6.

Comment:

Revision of S2-2108803r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108948 (CR) 23.304 CR0058 (Rel-17, 'F'): Clarification about path selection policy. (Source: Xiaomi).
Document for: Approval.
Abstract: Summary of change: It is clarified that PCF can determine the Path selection policy based on UE subscription or operator policy.

Comment:

r01 agreed. Revised to S2-2109169.

Discussion and conclusion:

-

e-mail discussion:

Zhang (Ericsson) provides comments
Steve (Huawei) comments
Mehrdad (Samsung) provides r01 and co-sources r01
Hong (Qualcomm) comments.
Changhong (Intel) has concern with r00, but can live with r01.
Sherry (Xiaomi) comments.
Fei (OPPO) comments.
Mehrdad (Samsung) replies to Huawei.
Hong (Qualcomm) replies to Steve.
Sherry (Xiaomi) replies
Steve (Huawei) thanks everyone.
==== Revisions Deadline ====
Zhang (Ericsson) is OK with r01
Steve (Huawei) is ok with r01.
Mehrdad (Samsung) supports r01. r01 is OK with us but objects to the original version.
==== Comments Deadline ====.

Status:

Revised to S2-2109169.

TD S2-2109169 (CR) 23.304 CR0058R1 (Rel-17, 'F'): Clarification about path selection policy. (Source: Xiaomi, Samsung).
Document for: Approval.
Abstract: Summary of change: It is clarified the UE may use the provisioned path selection policy to select the appropriate communication path for all or specific ProSe services.

Comment:

Revision of S2-2108948r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108951 (CR) 23.304 CR0038R1 (Rel-17, 'F'): Update to Groupcast mode 5G ProSe Direct Communication. (Source: Samsung, LG Electronics, Interdigital Inc.).
Document for: Approval.
Abstract: Summary of change: 1) In clause 5.2.4, remove the following EN. Editor's note: Whether and how to transmit metadata in discovery message depends on the size of the discovery message, it needs to be confirmed by RAN WG. 2) In clause 5.2.4, remove the following EN. Editor's note: It is FFS on how the Application layer discovery messages are exchanged over PC5 reference point between UEs. rev 1: 3) In clause 5.2.4, add a NOTE to describe how the PC5 Direct Discovery message can contain additional field carrying application layer metadata information. 4) In clause 6.3.2.1, add description that the Application layer metadata information can be transmitted as metadata in the Announcement and response messages.

Comment:

Revision of (Postponed) S2-2107713 from S2#147E. r01 agreed. Revised to S2-2109170.

Discussion and conclusion:

-

e-mail discussion:

Zhang (Ericsson) provides comments
Fei (OPPO) comments.
Mehrdad (Samsung) provides r01.
Zhang (Ericsson) is OK with r01
Fei (OPPO) is fine with r01.
==== Revisions Deadline ====
Hannu (Nokia) complains about premature revision deadline and shows what was left not done in r01.
Mehrdad (Samsung) suggest move forward with r01 and do any other changes in the next meeting.
==== Comments Deadline ====.

Status:

Revised to S2-2109170.

TD S2-2109170 (CR) 23.304 CR0038R2 (Rel-17, 'F'): Update to Groupcast mode 5G ProSe Direct Communication. (Source: Samsung, LG Electronics, Interdigital Inc.).
Document for: Approval.
Abstract: Summary of change: 1) In clause 5.2.4, remove the following EN. Editor's note: Whether and how to transmit metadata in discovery message depends on the size of the discovery message, it needs to be confirmed by RAN WG. 2) In clause 5.2.4, remove the following EN. Editor's note: It is FFS on how the Application layer discovery messages are exchanged over PC5 reference point between UEs. rev 1: 3) In clause 5.2.4, add a NOTE to describe how the PC5 Direct Discovery message can contain additional field carrying application layer metadata information. 4) In clause 6.3.2.1, add description that the Application layer metadata information may be transmitted as metadata in the Announcement and response messages.

Comment:

Revision of S2-2108951r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

# 8.9 Architectural enhancements for 5G multicast-broadcast services (5MBS)

This agenda item was convened by Tao Sun (China Mobile).

## LSs in and related documents

TD S2-2108278 (LS IN) LS from CT WG1: LS on maximum number of MBS sessions that can be associated to a PDU session. (Source: CT WG1 (C1-216247)).
Document for: Action.
Abstract: CT WG1 is currently working on the 5MBS impact on NAS protocol. CT WG1 would like to inform SA WG2 that CT WG1 assumes that the maximum number of MBS sessions that can be associated with a PDU session is limited to four and has agreed to introduce this in 3GPP TS 24.501. The consequence is that the NAS protocol can support a maximum of four MBS sessions associated with a PDU session. Action: CT WG1 kindly asks SA WG2 to take the above information into consideration. If SA WG2 has any concern with this assumption or any resulting limitation, then SA WG2 can kindly provide feedback.

Comment:

Response drafted in S2-2108404. Final response in S2-2109171.

Discussion and conclusion:

-

Status:

Replied to.

TD S2-2108934 (CR) 23.247 CR0070 (Rel-17, 'F'): Maximum of 4 Multicast sessions in one associated PDU session. (Source: Qualcomm Incorporated).
Document for: Approval.
Abstract: Summary of change: Clarify that there is a limit of 4 multicast sessions associated with a PDU session.

Comment:

Postponed.

Discussion and conclusion:

-

e-mail discussion:

Miguel (Qualcomm) proposes as author to postpone this CR in favor of outgoing LS, as per offline discussion.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Postponed.

TD S2-2108404 (LS OUT) [DRAFT] Reply LS on maximum number of MBS sessions that can be associated to a PDU session. (Source: Ericsson).
Document for: Approval.
Abstract: This paper responds that the max no. of MBS sessions associated with a PDU Session can reach 32.

Comment:

Response to S2-2108278. r06 agreed. Revised to S2-2109171.

Discussion and conclusion:

-

e-mail discussion:

Robbie (Ericsson) provides r01 based on offline CC discussion.
Thomas (Nokia) provides r02.
Robbie (Ericsson) provides r03.
Xiaoyan (CATT) provides r04.
Robbie asks Xiaoyan (CATT).
Xiaoyan (CATT) provides r05.
Robbie (Ericsson) provides r06.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109171.

TD S2-2109171 (LS OUT) Reply LS on maximum number of MBS sessions that can be associated to a PDU session. (Source: SA WG2).
Document for: Approval.
Abstract: To: CT WG1, SA WG4, SA WG6, RAN WG2. CC: RAN WG3.

Comment:

Revision of S2-2108404r06. Approved.

Discussion and conclusion:

-

Status:

Approved.

TD S2-2108991 (LS IN) LS from RAN WG2: Further reply on MBS broadcast service continuity. (Source: RAN WG2 (R2-2111511)).
Document for: Action.
Abstract: RAN WG2 would like to thank SA WG2 for their LS in S2-2108175 and for agreeing to introduce additional MBS identifier in upper layer signalling to allow for reducing the volume broadcasted in SIB. RAN WG2 notes that SA WG2 did not get consensus on whether frequency can be provided in the upper layer signalling, which goes against the working assumption made by RAN WG2 during RAN WG2#115-e meeting. RAN WG2 discussed this topic further during RAN#116-e meeting and made an agreement that frequency information in upper layer signalling is useful for some MBS use cases. This, for example, includes the cases where a certain MBS service is deployed homogeneously on a single frequency in a broadcast area, which is a likely deployment for some services. In such cases, it may be more efficient to directly provide the service-frequency mapping in upper layer signalling to decrease overhead over the air interface. Therefore, RAN WG2 would like to request SA WG2 to allow a possibility of including MBS service to frequency mapping in upper layer signalling in their specifications, similarly as in the case of USD in MBMS. Action: RAN WG2 respectfully asks SA WG2 to take the above information into account and allow a possibility of including MBS service to frequency mapping in upper layer signalling in their specifications.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Thomas (Nokia) suggest to Note this LS because the issue is addressed in outgoing LS S2-2108670
==== Comments Deadline ====.

Status:

Noted.

TD S2-2109002 (LS IN) LS from RAN WG3: Reply LS on MBS broadcast service continuity and MBS session identification. (Source: RAN WG3 (R3-215977)).
Document for: Action.
Abstract: RAN WG3 thanks RAN WG2 for the LS on the MBS broadcast service continuity and MBS session identification, RAN WG3 discussed the questions and would like to provide the answers as follows: Question: Can an 'MBS ID' (e.g. SAI) be defined for NR MBS for use in SIB and the upper layer signalling (e.g. USD), to avoid too many TMGIs from being broadcast in System Information? RAN WG3 answer: Yes. But as broadcast and higher layer signalling is out of RAN WG3 scope, it is subject to RAN WG2/SA WG2/SA WG4 decision. Action: RAN WG3 kindly ask RAN WG2, SA WG2 and SA WG4 to take the answers above into account.

Comment:

Postponed.

Discussion and conclusion:

-

Status:

Postponed.

TD S2-2109009 (LS IN) LS from RAN WG3: LS on Feedback on data forwarding solutions for MBS. (Source: RAN WG3 (R3-216195)).
Document for: Action.
Abstract: During mobility from MBS non-supporting node to MBS supporting node, a legacy handover is performed followed by a switch from individual delivery to shared delivery. The latter switch means a bearer type change from DRB to MRB during which the target gNB could buffer the data received from the shared N3 tunnel in order to re-send them over the MRB RLC PTP leg of the UE to fill the gap. This solution however typically leads to duplicate packets for the UE. One way for target gNB to eliminate duplicates would simply be if packets sent over the individual delivery unicast N3 could have the same CN SN (Sequence Number) than the same packet sent over the shared N3. Another possibility would be to rely on the fact that the UP-transmission times on N3 and RAN internal interfaces between individual delivery and shared delivery are fairly aligned and the gap that would be induced is in practice related to the HO process itself only. Action: RAN WG3 kindly ask SA WG2 whether the SA WG2 would be fine to accept the HO performance resulting from the 2nd option, otherwise, to comment on the 1st option.

Comment:

Response drafted in S2-2109013. Postponed.

Discussion and conclusion:

-

Status:

Postponed.

TD S2-2109013 (LS OUT) [DRAFT] Reply LS on Feedback on data forwarding solutions for MBS. (Source: Nokia).
Document for: Approval.
Abstract: To: RAN WG3. CC: RAN WG2. Attachments: [If agreed] S2-2108931.

Comment:

Created at CC#1. Response to S2-2109009. CC#2: r04 agreed. Revised to S2-2109351.

Discussion and conclusion:

CC#2: Nokia commented that there is an agreeable revision now available as r04. S2-2109013r04 was agreed and revised in S2-2109351.

e-mail discussion:

Thomas (Nokia) provides original version (r00)
Pau (Ericsson) objects to r00.
Thomas(Nokia) replies to Paul.
Provides r01
Paul (Ericsson) provides r02 and objects to r01.
==== Revisions Deadline ====
LiMeng (Huawei) provides r03 for this LS.
Paul (Ericsson) provides r04.
Thomas(Nokia) comments that timely r02 or late r03 are acceptable, but not late r04.
Paul (Ericsson) can only accept r04.
Thomas(Nokia) asks Paul if he rejects his own revision r02?
Paul (Ericsson) replies Thomas (Nokia), yes, object to r02.
Thomas(Nokia) can live with r04.
Tao(VC) Let's still check r02 since r04 provided after revision and r02 is provided by Paul
==== Comments Deadline ====
Thomas(Nokia) suggests bringing this to CC#2 as late r04 (but this is an LS) seems finally agreeable
LiMeng (Huawei) agrees Thomas to bring this to CC#2.

Status:

Revised to S2-2109351.

TD S2-2109351 (LS OUT) Reply LS on Feedback on data forwarding solutions for MBS. (Source: SA WG2).
Document for: Approval.
Abstract: To: RAN WG3. CC: RAN WG2.

Comment:

CC#2: Revision of S2-2109013r04. Approved.

Discussion and conclusion:

-

Status:

Approved.

## User plane management

TD S2-2108397 (CR) 23.247 CR0009R1 (Rel-17, 'F'): Dynamic Policy Control for 5GC Individual MBS Traffic Delivery. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: Resolve EN by adopting 1-step packet detection and forwarding for 5GC Individual Traffic Delivery in SMF and UPF.

Comment:

Revision of (unhandled) S2-2107207 from S2#147E. Merged into S2-2109173.

Discussion and conclusion:

-

e-mail discussion:

Judy (Ericsson) propose to merge this paper (i.e. 8397) to 8881.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Merged into S2-2109173.

TD S2-2108398 (CR) 23.501 CR3055R2 (Rel-17, 'F'): MBS Packet detection and forwarding. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: Remove ENs in clauses for PDR and FAR. Remove description related to 'MBS Internal' in source interface and destination interface.

Comment:

Revision of (unhandled) S2-2107206 from S2#147E. r01 agreed. Revised to S2-2109172, merging S2-2108880.

Discussion and conclusion:

-

e-mail discussion:

LiMeng (Huawei) suggests to merge this document into S2-2108880.
Judy (Ericsson) propose to use this paper (i.e. 8398) as base and merge 8880 and comments
Fenqin (Huawei) comments
Judy (Ericsson) provides r01
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109172, merging S2-2108880.

TD S2-2109172 (CR) 23.501 CR3055R3 (Rel-17, 'F'): MBS Packet detection and forwarding. (Source: Ericsson, ZTE).
Document for: Approval.
Abstract: Summary of change: Remove ENs in clauses for PDR and FAR. Remove description related to 'MBS Internal' in source interface and destination interface.

Comment:

Revision of S2-2108398r01, merging S2-2108880. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108880 (CR) 23.501 CR3450 (Rel-17, 'F'): Clarification on PDR and FAR in A-UPF for MBS data traffic in individual delivery. (Source: ZTE).
Document for: Approval.
Abstract: Summary of change: Remove the ENs on the 'MBS internal'. And remove the 'MBS internal' in the source and destination interface.

Comment:

Confirm Spec version used - CR states <17.2.0>! Merged into S2-2109172.

Discussion and conclusion:

-

e-mail discussion:

Judy (Ericsson) propose to merge this paper (i.e. 8880) to 8398 and comment
Zhendong (ZTE): is fine to merge 8880 to 8398
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Merged into S2-2109172.

TD S2-2108881 (CR) 23.247 CR0068 (Rel-17, 'F'): Clarification on PDR and FAR in A-UPF for MBS data traffic in individual delivery. (Source: ZTE).
Document for: Approval.
Abstract: Summary of change: Removing the EN and two step description. And clarify the SMF/UPF behavoir for receiving the MBS data for individual delivery.

Comment:

r04 agreed. Revised to S2-2109173, merging S2-2108397.

Discussion and conclusion:

-

e-mail discussion:

LiMeng (Huawei) suggests to merge this document into S2-2108397.
Judy (Ericsson) propose to use this paper (i.e. 8881) as base and merge 8397 and comments
LiMeng (Huawei) is fine with Judy's proposal on S2-2108397, S2-2108398, S2-2108880 and S2-2108881.
Judy (Ericsson) provide r01
Fenqin (Huawei) provide r02
Judy (Ericsson) is fine with r02
Thomas (Nokia) provides r03
Mirko (Huawei) provides r04.
==== Revisions Deadline ====
Judy (Ericsson) thanks Mirko (Huawei) for further improvement, I'm fine with r04.
==== Comments Deadline ====.

Status:

Revised to S2-2109173, merging S2-2108397.

TD S2-2109173 (CR) 23.247 CR0068R1 (Rel-17, 'F'): Clarification on PDR and FAR in A-UPF for MBS data traffic in individual delivery. (Source: ZTE, Ericsson, Nokia, Nokia Shanghai-Bell).
Document for: Approval.
Abstract: Summary of change: Removing the EN and two step description. And clarify the SMF/UPF behavoir for receiving the MBS data for individual delivery.

Comment:

Revision of S2-2108881r04, merging S2-2108397. Approved.

Discussion and conclusion:

-

Status:

Agreed.

## General

TD S2-2108403 (CR) 23.247 CR0026R2 (Rel-17, 'F'): Micellaneous corrections. (Source: Huawei, HiSilicon, Ericsson, [ZTE,] Tencent, CATT [, vivo], Samsung).
Document for: Approval.
Abstract: Summary of change: Clause 2: Remove TR 23.757. Clause 3.1: term alignment. Clause 4.1: MBS support clarification. Clause 4.2.2: Broadcast service timeline correction. Clause 4.3: replace 'NOTE' with 'EN'. Correct the clause reference for Multicast Session De-configuration procedure. Clause 5.1: 1) remove EN above Figure 5.1-2; 2) MBS support clarification. Clause 5.2: Update the interfaces used for MBS, e.g., Nmb3, Nmb6 and Nmb4 to Nmb5, Nmb10 and Nmb8. Clause 5.3.2.1: MBS support clarification. Clause 5.3.2.11: replace 'sender' with 'destination'. Clause 5.3.2.15: MBS support clarification. Replace 'MB Service Area' with 'MBS Service Area' Clause 6.3.2: MBS support clarification. (void). Clause 6.6: term alignment. Clause 6.9.1: reorder the column of clause 6.9.1 MBS Session Context. Remove service area and service area ID from AMF for multicast. Clause 7.1.1.3: Service name corrections. Clause 7.1.1.6: Replace 'MB Service Area' with 'MBS Service Area' Clause 7.2.1.3: 1) Correcting the step number; 2) Term alignment; 3) clarify Join rejection; 4) correct step 4 to state that SMF checks the authorization of the user to join a multicast session. Clause 7.1.1.4: fix service operation names to Nnef_MBSSession_Delete and Nmbsmf_MBSSession_Delete to align with service operation definition in clause 9.1.3 and 9.4.3. Clause 7.1.1.5: fix service operation names to Nnef_MBSSession_Delete and Nmbsmf_MBSSession_Delete to align with service operation definition in clause 9.1.3 and 9.4.3. Clause 7.2.2.2: fix service operation names to Nmbsmf_MBSSession_ContextUpdate and Nmbsmf_MBSSession_ContextStatusUnsubscribe to align with service operation definition in clause 9.1.3. Remove NOTE1 and NOTE2. Clause 7.2.3: 1) MBS support clarification; 2) term alignment; 3) step number; 4) Service name corrections. Clause 7.2.4.3: 1) Title correction for local MBS; 2) Clarification of 'local MBS service indication'. Clause 7.3.1-7.3.3: 1) term alignment; 2) Remove unrelated ENs. Clause 7.3.5: Remove unrelated EN. Clause 8.1: 1) Hanging clause; 2) replace 'NOTE' with 'EN'; 3) clarify the NG-RAN node interacting with MB-SMF is with MBS capability. Clause 8.2: remove Nmb9 to align with the figure. Clause 9.1.3.1: 1) NBSF( MBSF in clause 9.1.3.1; 2) MBSF/NEF or SMF ( MBSF/NEF/AF in clause 9.1.3.1. Clause 9.1.3.4: Replace 'MB Service Area' with 'MBS Service Area' (void)Clause 9.3.2.5: Remove unused services. (void)Clause 9.3.1: Remove unused services. Clause 9.3.3.2: Service name correction.

Comment:

Revision of (Agreed) S2-2107997 from S2#147E. r03 agreed. Revised to S2-2109174, merging S2-2108526.

Discussion and conclusion:

-

e-mail discussion:

Youngkyo(Samsung) provides a revision r01.
Chen Ying(TD Tech) provides a revision r02.
Thomas(Nokia) provides r03.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109174, merging S2-2108526.

TD S2-2109174 (CR) 23.247 CR0026R3 (Rel-17, 'F'): Micellaneous corrections. (Source: Huawei, HiSilicon, Ericsson, ZTE, Tencent, CATT , vivo, Samsung, Nokia, Nokia Shanghai-Bell, TD-Tech).
Document for: Approval.
Abstract: Summary of change: Clause 2: Remove TR 23.757. Clause 3.1: term alignment. Clause 4.1: MBS support clarification. Clause 4.2.2: Broadcast service timeline correction. Clause 4.3: replace 'NOTE' with 'EN'. Correct the clause reference for Multicast Session De-configuration procedure. Clause 5.1: 1) remove EN above Figure 5.1-2; 2) MBS support clarification. Clause 5.2: Update the interfaces used for MBS, e.g., Nmb3, Nmb6 and Nmb4 to Nmb5, Nmb10 and Nmb8. Clause 5.3.2.1: MBS support clarification. Clause 5.3.2.11: replace 'sender' with 'destination'. Clause 5.3.2.15: MBS support clarification. Replace 'MB Service Area' with 'MBS Service Area' Clause 6.3.2: MBS support clarification. (void). Clause 6.6: term alignment. Clause 6.9.1: reorder the column of clause 6.9.1 MBS Session Context. Remove service area and service area ID from AMF for multicast. Clause 7.1.1.3: Service name corrections. Clause 7.1.1.6: Replace 'MB Service Area' with 'MBS Service Area' Clause 7.2.1.3: 1) Correcting the step number; 2) Term alignment; 3) clarify Join rejection; 4) correct step 4 to state that SMF checks the authorization of the user to join a multicast session. Clause 7.1.1.4: fix service operation names to Nnef_MBSSession_Delete and Nmbsmf_MBSSession_Delete to align with service operation definition in clause 9.1.3 and 9.4.3. Clause 7.1.1.5: fix service operation names to Nnef_MBSSession_Delete and Nmbsmf_MBSSession_Delete to align with service operation definition in clause 9.1.3 and 9.4.3. Clause 7.2.2.2: fix service operation names to Nmbsmf_MBSSession_ContextUpdate and Nmbsmf_MBSSession_ContextStatusUnsubscribe to align with service operation definition in clause 9.1.3. Remove NOTE1 and NOTE2. Clause 7.2.3: 1) MBS support clarification; 2) term alignment; 3) step number; 4) Service name corrections. Clause 7.2.4.3: 1) Title correction for local MBS; 2) Clarification of 'local MBS service indication'. Clause 7.3.1-7.3.3: 1) term alignment; 2) Remove unrelated ENs. Clause 7.3.5: Remove unrelated EN. Clause 8.1: 1) Hanging clause; 2) replace 'NOTE' with 'EN'; 3) clarify the NG-RAN node interacting with MB-SMF is with MBS capability. Clause 8.2: remove Nmb9 to align with the figure. Clause 9.1.3.1: 1) NBSF( MBSF in clause 9.1.3.1; 2) MBSF/NEF or SMF ( MBSF/NEF/AF in clause 9.1.3.1. Clause 9.1.3.4: Replace 'MB Service Area' with 'MBS Service Area' (void) (void) Clause 9.3.3.2: Service name correction.

Comment:

Revision of S2-2108403r03, merging S2-2108526. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108972 (CR) 23.247 CR0015R2 (Rel-17, 'F'): Clarifications on functional entities. (Source: [CATT, Ericsson], Nokia, Nokia Shanghai-Bell).
Document for: Approval.
Abstract: Summary of change: Correct the functionality of MB-SMF and SMF for supporting shared delivery establishment and for the associated PDU Session management.

Comment:

Revision of (Endorsed) S2-2108001 from S2#147E. r02 agreed. Revised to S2-2109175.

Discussion and conclusion:

-

e-mail discussion:

Judy (Ericsson) provide r01
Thomas (Nokia) accepts changes in r01 and provides r02 to add Ericsson back as source
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109175.

TD S2-2109175 (CR) 23.247 CR0015R3 (Rel-17, 'F'): Clarifications on functional entities. (Source: CATT, Ericsson, Nokia, Nokia Shanghai-Bell).
Document for: Approval.
Abstract: Summary of change: Correct the functionality of MB-SMF and SMF for supporting shared delivery establishment and for the associated PDU Session management.

Comment:

Revision of S2-2108972r02. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108974 (CR) 23.247 CR0019R2 (Rel-17, 'F'): NRF service operation for broadcast service. (Source: [Samsung], Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: For broadcast service AMF discovery is supported based on the MBS service areatracking area. NF profile is updated; MB-SMF service area is added to MB-SMF profile, MBS service area for area session ID is replaced with session area for alignment with other description.

Comment:

Revision of (Agreed) S2-2108022 from S2#147E. Approved.

Discussion and conclusion:

-

e-mail discussion:

Judy (Ericsson) comments this paper depends on the MBS SAI discussion what type of location will be used for AMF discovery for broadcast MBS session.
Zhendong (ZTE): propsoe to complete the SAI first. then consider this
LiMeng (Huawei) wonders the reason why this document is related to SAI.
==== Revisions Deadline ====
Thomas(Nokia) comments that if we do not agree the update but keep the version from the last meeting, it would only fit if we decide to use SAI for routing
Judy (Ericsson) responds that proposed removal of cell id is correct thus I'm fine with r00.
==== Comments Deadline ====.

Status:

Agreed.

TD S2-2108651 (CR) 23.247 CR0002R2 (Rel-17, 'F'): MBS Session Management vs Configuration. (Source: Based on (Ericsson, vivo), vivo).
Document for: Approval.
Abstract: Summary of change: Use 'MBS Session Creation/Update/Deletion' instead of wording with 'MBS Session Configuration' Rev02: 1. Change 4.3-4 to 4.3-3, 4.3-5 to 4.3-4 2. Change figure 4.3-(1-4) 3. Change 'NULL' to 'Start' or 'End'.

Comment:

Revision of (Agreed) S2-2107998 from S2#147E. r01 agreed. Revised to S2-2109176.

Discussion and conclusion:

-

e-mail discussion:

LiMeng (Huawei) suggests to keep the 'NULL' state we currently defined.
Zhenhua (vivo) responds to LiMeng (Huawei).
Judy (Ericsson) comments
Zhendong (ZTE): similar view with limeng
Zhenhua (vivo) provides r01
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109176.

TD S2-2109176 (CR) 23.247 CR0002R3 (Rel-17, 'F'): MBS Session Management vs Configuration. (Source: Ericsson, vivo).
Document for: Approval.
Abstract: Summary of change: Use 'MBS Session Creation/Update/Deletion' instead of wording with 'MBS Session Configuration' Rev02: 1. Change 4.3-4 to 4.3-3, 4.3-5 to 4.3-4 2. Change figure 4.3-(1-4) 3. Change 'NULL' to 'Start (NULL)' or 'End (NULL)'.

Comment:

Revision of S2-2108651r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108653 (CR) 23.247 CR0038R2 (Rel-17, 'F'): Replacement reference architecture figures. (Source: Based on (BBC, Ericsson), vivo).
Document for: Approval.
Abstract: Summary of change: Editorial update: Change of typeface. More white space between functions. Alignment of functions into two horizontal planes. Depiction of AF/AS spanning both planes. Move the support of legacy AF/AS from clause 5.1 to normative Annex. Move the MB2/xMB related description from clause 7.1.1.1 to Annex Rev02: Change the figure 5.1-1 to remove the cross link.

Comment:

Revision of (Agreed) S2-2108000 from S2#147E. r03 agreed. Revised to S2-2109177.

Discussion and conclusion:

-

e-mail discussion:

LiMeng (Huawei) asks whether we need to clarify the interfaces in this document as well.
Judy (Ericsson) does not see the need of this paper, cross-line with little half-circle is sufficiently clear.
Zhenhua (vivo) answers to Judy (Ericsson) that it is only editorial for good looking without introducing any bad thing.
LiMeng (Huawei) provides r01.
Thomas (Nokia) provides r02 and asks to ignore it
Judy (Ericsson) comment that the 'good-looking' (in Zhenhua's eye) figure may cause confusion that MBSF is between NEF and AF, and provides r03 on top of r01.
LiMeng (Huawei) thanks Judy for the revison, and asks a question for clarification.
Judy (Ericsson) responds to LiMeng (Huawei)
==== Revisions Deadline ====
Judy (Ericsson) accepts only r03, objects to other revisions including r00 to avoid potential confusion on the relationships between NFs in the architecture
==== Comments Deadline ====.

Status:

Revised to S2-2109177.

TD S2-2109177 (CR) 23.247 CR0038R3 (Rel-17, 'F'): Replacement reference architecture figures. (Source: [BBC], Ericsson, vivo).
Document for: Approval.
Abstract: Summary of change: Editorial update: Change of typeface. More white space between functions. Alignment of functions into two horizontal planes. Depiction of AF/AS spanning both planes. Move the support of legacy AF/AS from clause 5.1 to normative Annex. Move the MB2/xMB related description from clause 7.1.1.1 to Annex Rev03: Clarify the functionalities of the interfaces.

Comment:

Revision of S2-2108653r03. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108656 (CR) 23.247 CR0061 (Rel-17, 'D'): Editorial modification on name of Session Update. (Source: Vivo Mobile Communications Co. LTD).
Document for: Approval.
Abstract: Summary of change: 1. Change clause 7.2.6 as session modification to distinguish the two procedures 2. Change clause 7.3.3 as session modification to distinguish the two procedures.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Judy (Ericsson) comments there is misunderstanding of MBS Session update procedure, and the update is not editorial at all as the CR Cat indicates
Zhenhua (vivo) replies to Judy (Ericsson)
==== Revisions Deadline ====
Judy (Ericsson) propse to NOTE this paper and clarify if needed next meeting using a proper CR Cat
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108672 (CR) 23.247 CR0066 (Rel-17, 'F'): Clarification on Annex A for transport mode. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Clarify the Transport only mode and service mode mentioned in Annex C Clarify the same mode will be used for service layer interworking. Clarify that if transport only mode is used and when Multicast service or Broadcast service requires service layer interworking with LTE MBMS, Nmb8 and Nmb10 provides similar functionalities to N6mb and N33, respectively.

Comment:

r02 agreed. Revised to S2-2109178.

Discussion and conclusion:

-

e-mail discussion:

Robbie (Ericsson) provides r01.
Thomas (Nokia) provides r02.
Robbie (Ericsson) is fine with r02.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109178.

TD S2-2109178 (CR) 23.247 CR0066R1 (Rel-17, 'F'): Clarification on Annex A for transport mode. (Source: Huawei, HiSilicon, Ericsson).
Document for: Approval.
Abstract: Summary of change: Clarify the Transport only mode and service mode mentioned in Annex A Clarify the same mode will be used for service layer interworking. Clarify that if transport only mode is used and when Multicast service or Broadcast service requires service layer interworking with LTE MBMS, Nmb8 and Nmb10 provides similar functionalities to N6mb and N33, respectively.

Comment:

Revision of S2-2108672r02. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2109014 (LS OUT) [DRAFT] LS on Interworking with eMBMS for Transport Only Mode. (Source: Ericsson).
Document for: Approval.
Abstract: To: SA WG4, SA WG6.

Comment:

Created at CC#1. Noted.

Discussion and conclusion:

-

e-mail discussion:

Robbie (Ericsson) provides r00.
LiMeng (Huawei) comments
Robbie (Ericsson) responds to LiMeng (Huawei)
LiMeng (Huawei) provides r01.
==== Revisions Deadline ====
Thomas(Nokia) raises concerns against r01 and questions need for the LS
==== Comments Deadline ====.

Status:

Noted.

## Multicast Session Management

TD S2-2108402 (CR) 23.247 CR0029R2 (Rel-17, 'F'): Updates on cases that SMF rejects UE join request. (Source: [Huawei, HiSilicon,] Ericsson).
Document for: Approval.
Abstract: Summary of change: If no MB-SMF can be assigned to the MBS session ID (according to the MB-SMF profile registered in configuration procedure or preconfigured by the operator), the NRF does not provide MB-SMF profile to SMF.

Comment:

Revision of (Agreed) S2-2108007 from S2#147E. Merged into S2-2109179.

Discussion and conclusion:

-

e-mail discussion:

Youngkyo(Samsung) proposes to merge this CR into S2-2108500.
Judy (Ericsson) agrees to Youngkyo(Samsung)'s merging proposal (8402->8500)
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Merged into S2-2109179.

TD S2-2108500 (CR) 23.247 CR0029R3 (Rel-17, 'F'): Updates on cases that SMF rejects UE join request. (Source: Samsung,Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: If no MB-SMF can be assigned to the MBS session ID (according to the MB-SMF profile registered in configuration procedure or preconfigured by the operator), the NRF may provide empty profile to SMF to indicate that no MB-SMF is assigned for the MBS session ID. When the shared tunnel for shared delivery is established, AMF may discover the serving MB-SMF based on MBS session ID and optionally Area Session ID which are received from NG-RAN.

Comment:

Revision of (Agreed) S2-2108007 from S2#147E. r06 agreed. Revised to S2-2109179, merging S2-2108402.

Discussion and conclusion:

-

e-mail discussion:

Judy (Ericsson) provides r01 merging 8402 into this paper (i.e. 8500)
Youngkyo(Samsung) provides r02
LiMeng (Huawei) provides r03.
Judy (Ericsson) is fine with r03
Youngkyo(Samsung) is fine with r03 also
Thomas (Nokia) provides r04.
Xiaoyan (CATT) provides r05.
LiMeng (Huawei) provides r06.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109179, merging S2-2108402.

TD S2-2109179 (CR) 23.247 CR0029R4 (Rel-17, 'F'): Updates on cases that SMF rejects UE join request. (Source: Huawei, HiSilicon, Samsung, Ericsson).
Document for: Approval.
Abstract: Summary of change: If no MB-SMF can be assigned to the MBS session ID (according to the MB-SMF profile registered in configuration procedure or preconfigured by the operator), the NRF may does not provide empty MB-SMF profile to SMF to indicate that no MB-SMF is assigned for the MBS session ID. When the shared tunnel for shared delivery is established, AMF may discover the serving MB-SMF based on MBS session ID and optionally Area Session ID which are received from NG-RAN.

Comment:

Revision of S2-2108500r06, merging S2-2108402. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108879 (CR) 23.247 CR0067 (Rel-17, 'F'): Fixing the EN and Nmbsmf_MBSSession service operation parameters.. (Source: ZTE, Ericsson).
Document for: Approval.
Abstract: Summary of change: Delete the EN on possible interaction related to the multicast Qos flows in the clause 7.2.1.3. Keep alignment in MBS session ID, subscription correlation ID in MBSSession_StatusSubscribe/StatusUnSubscribe service operation.

Comment:

r01 agreed. Revised to S2-2109180.

Discussion and conclusion:

-

e-mail discussion:

Thomas (Nokia) provides r01
Judy (Ericsson) is fine with r01 and corrects the doc link
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109180.

TD S2-2109180 (CR) 23.247 CR0067R1 (Rel-17, 'F'): Fixing the EN and Nmbsmf_MBSSession service operation parameters.. (Source: ZTE, Ericsson).
Document for: Approval.
Abstract: Summary of change: Delete the EN on possible interaction related to the multicast Qos flows in the clause 7.2.1.3. Calrify the NF consumer of Nmbsmf_MBSSession_Status subscribe and unsubscribe service operation.

Comment:

Revision of S2-2108879r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108666 (CR) 23.247 CR0063 (Rel-17, 'F'): On the issue of user plane activation. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: It is proposed to remove the EN related to UP activation.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Paul (Ericsson) provides comments and objects to this CR in all revisions.
Thomas (Nokia) provides r01
Wonders whether Paul has a crystal ball to reject future revisions --
No crystal ball needed --, Paul (Ericsson) objects to r01. The acknowledged RAN resource impacts issue is not being addressed and thus the EN can't be removed.
==== Revisions Deadline ====
Paul (Ericsson) objects to this CR in r00. The acknowledged RAN resource impacts issue is not being addressed and thus the EN can't be removed.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108401 (CR) 23.247 CR0014R2 (Rel-17, 'F'): Multicast session leave and session release. (Source: CATT, [ZTE, Huawei, HiSilicon,] Ericsson).
Document for: Approval.
Abstract: Summary of change: Update service operations and parameters in multicast session leave and session release procedures; Modify SMF removing joined UEs from MBS session procedures, to accommodate more scenarios for network initiated multicast session leave; Other modifications, e.g. changing the 'MBS Session' in sub-clause titles to 'multicast session' (as in clause 7.2.1).

Comment:

Revision of (Agreed) S2-2108005 from S2#147E. r01 agreed. Revised to S2-2109181.

Discussion and conclusion:

-

e-mail discussion:

Zhendong (ZTE): provides comments
Judy (Ericsson) provides r01
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109181.

TD S2-2109181 (CR) 23.247 CR0014R3 (Rel-17, 'F'): Multicast session leave and session release. (Source: CATT, ZTE, Huawei, HiSilicon, Ericsson).
Document for: Approval.
Abstract: Summary of change: Update service operations and parameters in multicast session leave and session release procedures; Modify SMF removing joined UEs from MBS session procedures, to accommodate more scenarios for network initiated multicast session leave; Other modifications, e.g. changing the 'MBS Session' in sub-clause titles to 'multicast session' (as in clause 7.2.1).

Comment:

Revision of S2-2108401r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108504 (CR) 23.247 CR0055 (Rel-17, 'F'): Minimize multicast service interruption caused by unintended PDU session release. (Source: Samsung).
Document for: Approval.
Abstract: Summary of change: - When the associated PDU session is released, the UE indicates that the UE wants to keep/stop the multicast service and accordingly SMF may keep/remove the MBS session context. - If UE wants to keep the multicast service, the SMF may trigger the UE for immediate PDU session re-establishment via PDU session release command message. -When the associated PDU session is released, it is noted that the source NG-RAN does not provide the multicast context to the target during handover.

Comment:

r09 agreed. Revised to S2-2109182.

Discussion and conclusion:

-

e-mail discussion:

LaeYoung (LGE) proposes to NOTE this CR because didn't see any value compared to impacts on UE, NG-RAN and CN.
Youngkyo(Samsung) replies to LaeYoung (LGE).
Judy (Ericsson) comments
LaeYoung (LGE) replies to Youngkyo (Samsung).
Youngkyo (Samsung) provides a revision r01.
LaeYoung (LGE) provides r02.
Youngkyo (Samsung) provides comments on r02.
LaeYoung (LGE) answers to Youngkyo (Samsung).
Judy (Ericsson) provide r03
LaeYoung (LGE) is fine with r03.
Youngkyo (Samsung) suggests another wording.
LaeYoung (LGE) comments.
Zhenhua (vivo) provides r04.
Zhendong (ZTE): provides r05
Youngkyo(Samsung) provides r06.
Thomas(Nokia) provides r07.
Fenqin (Huawei) provides r08.
LaeYoung (LGE) asks a Q for clarification on r07/r08 about 'the UE can use an existing PDU Session' part.
Xiaoyan (CATT) provides r09.
Thomas (Nokia) is fine with r09 and answers questions of LaeYoung
LaeYoung (LGE) thanks to Thomas (Nokia) for his answer.
==== Revisions Deadline ====
Youngkyo(Samsung) is okay with r09.
LaeYoung (LGE) is fine with r09.
==== Comments Deadline ====.

Status:

Revised to S2-2109182.

TD S2-2109182 (CR) 23.247 CR0055R1 (Rel-17, 'F'): Minimize multicast service interruption caused by unintended PDU session release. (Source: Samsung).
Document for: Approval.
Abstract: Summary of change: - When the associated PDU session is released, the UE indicates that the UE wants to keep/stop the multicast service and accordingly SMF may keep/remove the MBS session context. - If UE wants to keep the multicast service, the SMF may trigger the UE for immediate PDU session re-establishment via PDU session release command message. -When the associated PDU session is released, it is noted that the source NG-RAN does not provide the multicast context to the target during handover. Add a NOTE aboutto notice the warning of unintended multicast service interruption UE using the existing ore re-establish a suitable PDU session to join the MBS session due to the associated PDU Session release.

Comment:

Revision of S2-2108504r09. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108507 (CR) 23.247 CR0056 (Rel-17, 'F'): Paging strategy handling for multicast MBS session. (Source: Samsung).
Document for: Approval.
Abstract: Summary of change: Paging strategy for multicast MBS session is added and its corresponding MBS session activation procedures are modified as individual paging can be delayed to minimize the CM-IDLE UE list by excluding the UEs awaken by group paging.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Judy (Ericsson) comments
Youngkyo(Samsung) replies.
Zhendong (ZTE): provides comments
Thomas (Nokia) shares the concern of Zhendong
Fenqin (Huawei) comments
Youngkyo(Samsung) replies and provide a revision r01.
Fenqin (Huawei) responds
Fenqin (Huawei) replies
Judy (Ericsson) provide r02 including only the group paging in paging strategy handling. Just to remind, all new text should have track changes.
Youngkyo(Samsung) provides r03.
Judy (Ericsson) provides r04 removing the note on AMF delaying the individual paging
Fenqin (Huawei) provide r05
Youngkyo(Samsung) provide r06.
==== Revisions Deadline ====
Judy (Ericsson) accepts r02, r04, r05, objects to other revisions including r00 and responds to Youngkyo(Samsung)
Youngkyo(Samsung) replies and accept r03 and r06 and objects the other revision.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108612 (CR) 23.247 CR0022R2 (Rel-17, 'F'): Leftover issue for MBS session activation and deactivation. (Source: Based on [Huawei, HiSilicon, vivo], CATT).
Document for: Approval.
Abstract: Summary of change: Remove the unsuitalbe restriction that MBS session need be in activte state. Propose to reuse MT_EnableGroupReachability service to notify SMFs when the UEs are not reachable, and propose to reuse Nsmf_PDUSession_UpdateSMContext to inform SMFs when UEs are reachable after receiving the service request messages from the UEs. Clarify the way of the AMF figuring out the paging area. Add the related description that the SR is related to inactive MBS session. Additional changes compared to r01: MBS session activation procedure: clarify the parameters in Nmbsmf_MBSSession_ContextStatusNotify and Namf_Communication_N1N2MessageTransfer (in step 4b); correct the usage of UE reachability Notification Address (in step 3). Service request procedure: clarify that the procedure also applies to associated PDU session activation when the UE is in CM-CONNECTED state and the user plane of the associated PDU Session is deactivated.

Comment:

Revision of (Agreed) S2-2108011 from S2#147E. r06 agreed. Revised to S2-2109183, merging S2-2108654.

Discussion and conclusion:

-

e-mail discussion:

Zhenhua (vivo) provides r01 to merge 8654.
Judy (Ericsson) ask question
Zhendong (ZTE): provides r02
Thomas (Nokia): provides r03
Thomas (Nokia): provides r04,
Asks to disregard r03
Fenqin (Huawei): provides r05
Zhenhua (vivo) provides r06
==== Revisions Deadline ====
Judy (Ericsson) responds to Zhenhua (vivo) and ask question
Zhenhua (vivo) responds to Judy (Ericsson)
Judy (Ericsson) ask further question
Fenqin (Huawei) comments.
Judy (Ericsson) comments
Fenqin (Huawei) responds.
Zhenhua (vivo) replies to Judy (Ericsson)
Thomas(Nokia) replies to Judy
Judy (Ericsson) responds to Thomas(Nokia)
Thomas(Nokia) can accept r04, r05 and r06, objects to earlier revisions including r00
Thomas(Nokia) replies to Judy (Ericsson)
Xiaoyan (CATT) sugguest to agree r04 or r00.
Fenqin (Huawei) only accept r05 or r06.
Tao(VC) we still check r06 to agreeable or not then
Zhendong (ZTE): provides response
Xiaoyan (CATT) can accept r05 or r06.
Judy (Ericsson) responds to Fenqin (Huawei) that NOTE 1 allows both options thus the procedure should clarify both, but can live with r04-r06 to progress
==== Comments Deadline ====.

Status:

Revised to S2-2109183, merging S2-2108654.

TD S2-2109183 (CR) 23.247 CR0022R4 (Rel-17, 'F'): Leftover issue for MBS session activation and deactivation. (Source: Huawei, HiSilicon, vivo, CATT).
Document for: Approval.
Abstract: Summary of change: Remove the unsuitalbe restriction that MBS session need be in activte state. Propose to reuse MT_EnableGroupReachability service to notify SMFs when the UEs are not reachable, and propose to reuse Nsmf_PDUSession_UpdateSMContext to inform SMFs when UEs are reachable after receiving the service request messages from the UEs. Clarify the way of the AMF figuring out the paging area. Add the related description that the SR is related to inactive MBS session. Rev02: MBS session activation procedure: clarify the parameters in Nmbsmf_MBSSession_ContextStatusNotify and Namf_Communication_N1N2MessageTransfer (in step 4b); correct the usage of UE reachability Notification Address (in step 3). Service request procedure: clarify that the procedure also applies to associated PDU session activation when the UE is in CM-CONNECTED state and the user plane of the associated PDU Session is deactivated.

Comment:

Revision of S2-2108612r06, merging S2-2108654. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108654 (CR) 23.247 CR0022R3 (Rel-17, 'F'): Leftover issue for MBS session activation and deactivation. (Source: Based on (Huawei, HiSilicon), vivo).
Document for: Approval.
Abstract: Summary of change: Remove the unsuitalbe restriction that MBS session need be in activte state. Propose to reuse MT_EnableGroupReachability service to notify SMFs when the UEs are not reachable, and propose to reuse Nsmf_PDUSession_UpdateSMContext to inform SMFs when UEs are reachable after receiving the service request messages from the UEs. Clarify the way of the AMF figuring out the paging area. Add the related description that the SR is related to inactive MBS session. Rev02: 1. In step 3, make the two parameters optional, and describe only one of the parameter is included. 2. In step 4b, specify that, depends on operator policy, PDU Session Resource Modify Request or MBS Activation Request is used. Hence in step 8b, 9, and 10b is aligned accordingly. 3. Some editorial modification, including modifying the figure of step 10b that the 'steps 9-12' shall be 'steps 8-12'.

Comment:

Revision of (Agreed) S2-2108011 from S2#147E. Merged into S2-2109183.

Discussion and conclusion:

-

e-mail discussion:

Fenqin (Huawei) suggest to merget this paper into 8612
Zhenhua (vivo) agrees to merge into 8612
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Merged into S2-2109183.

TD S2-2108657 (CR) 23.247 CR0062 (Rel-17, 'F'): Editorial modification on activation procedure. (Source: Vivo Mobile Communications Co. LTD).
Document for: Approval.
Abstract: Summary of change: 1. In step 5, UE list may be indicated to RAN node based on operator policy. 2. In step 12, the NG-RAN interact with UE in RRC-CONNECTED or RRC-INACTIVE state.

Comment:

r03 agreed. Revised to S2-2109184.

Discussion and conclusion:

-

e-mail discussion:

Judy (Ericsson) provide r01 taking out the part overlapping with 8935 (on list of UE to RAN) and remove 'editorial' from the title which is contradictory with Cat F.
Thomas (Nokia) comments against this CR
Zhenhua (vivo) asks Thomas (Nokia) to reconsider r01
Zhendong (ZTE): provides r02
Thomas (Nokia): provides r03
==== Revisions Deadline ====
Judy (Ericsson) support Thomas (Nokia) on the removal of 'per UE' in r03.
Zhendong (ZTE): is fine with r03
Zhendong (ZTE): clarify
Judy (Ericsson) responds to Zhendong (ZTE)
Zhendong (ZTE): provides the response.
Thomas (Nokia) is fine with r03, objects against r00 and r02
Fenqin (Huawei) we are also fine with r03
==== Comments Deadline ====.

Status:

Revised to S2-2109184.

TD S2-2109184 (CR) 23.247 CR0062R1 (Rel-17, 'F'): Modification on activation procedure. (Source: Vivo Mobile Communications Co. LTD, Ericsson).
Document for: Approval.
Abstract: Summary of change: 1. In step 12, the NG-RAN interact with UE in RRC-CONNECTED or RRC-INACTIVE state.

Comment:

Revision of S2-2108657r03. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108935 (CR) 23.247 CR0047R1 (Rel-17, 'C'): Alignment with RAN WG2 for Multicast paging in service activation. (Source: Qualcomm Incorporated).
Document for: Approval.
Abstract: Summary of change: In Service activation procedure, the AMF creates a list of UEs to be paged and provides it to the NG-RAN together with the TMGI.

Comment:

Revision of (Postponed) S2-2107752 from S2#147E. Postponed.

Discussion and conclusion:

-

e-mail discussion:

Robbie (Ericsson) proposes to postpone this CR.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Postponed.

TD S2-2108988 (CR) 23.247 CR0012R2 (Rel-17, 'F'): Multicast session join and session establishment. (Source: [CATT, Qualcomm, Huawei, HiSilicon, ZTE, vivo], Nokia, Nokia Shanghai-Bell).
Document for: Approval.
Abstract: Summary of change: Clarify the handling by the SMF towards the UE when join request is rejected. Remove the descriptions of multicast QoS flow information from incorrect steps. Editorial corrections. Allow PDU session establishment for the associated PDU session and Multicast join to be requested in same NAS-SM message. In that case, PDU session establishment in the network is executed before MBS join procedure. The joint reply is created in SMF, after both PDU session establishment and MBS join are executed in the 5GC. This aligns TS 23.247 with TS 24.501 (Stage 3). Indication whether multicast session is active is provided to RAN.

Comment:

Revision of (Agreed) S2-2108006 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

Zhenhua (vivo) provides r01
Youngkyo(Samsung) provides r02.
Judy (Ericsson) provides r03 to remove the indication from SMF to RAN as the MBS session related info (including status) is already provided by MB-SMF.
Xiaoyan (CATT) provides r04.
==== Revisions Deadline ====
Youngkyo(Samsung) is okay with r04 and happy to cosign.
Thomas(Nokia) objects against r03 and r04
Judy (Ericsson) objects to r00, r01, r02, accept r03 & r04
Thomas(Nokia) replies to Judy
==== Comments Deadline ====.

Status:

Noted.

## Local MBS

TD S2-2108399 (CR) 23.247 CR0010R1 (Rel-17, 'F'): Local MBS service and Location dependent MBS service. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: 6.2.1 Move the procedure related details (e.g. Namf_EventExposure service) to the procedures in clauses 7.2.4. Move 6.2.4 (Update of broadcast local MBS service and location dependent MBS service) to 7.3.4 (Support for Local Broadcast Service) Move 6.2.5 (Update of multicast local MBS service and location dependent MBS service) to 7.2.4 (Support of Local multicast service) Introduce a new sub-clause to describe how to determine UE is IN or OUT of an MBS service area. Other editorial corrections.

Comment:

Revision of (unhandled) S2-2107208 from S2#147E. r02 agreed. Revised to S2-2109185.

Discussion and conclusion:

-

e-mail discussion:

Zhenhua (vivo) ask Q
Judy (Ericsson) responds to Zhenhua (vivo)
Thomas(Nokia) suggests to note this CR and check is some related enhancements are required in S2-2108680
Judy (Ericsson) proposes r01: keeping the update in 3.1, 6.2.4 & 6.2.5 in this paper and merge the rest to 8680 to avoid overlapping, and responds to Thomas(Nokia) that 2 out of 3 comments are not valid and the remaining 1 can be discussed.
Thomas (Nokia) proposes r02
Judy (Ericsson) thanks Thomas (Nokia) for the revision and is fine with r02
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109185.

TD S2-2109185 (CR) 23.247 CR0010R2 (Rel-17, 'F'): Local MBS service and Location dependent MBS service. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: Remove 6.2.4 and 6.2.5.

Comment:

Revision of S2-2108399r02. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108490 (CR) 23.247 CR0054 (Rel-17, 'F'): Clarification on local multicast. (Source: LG Electronics).
Document for: Approval.
Abstract: Summary of change: In clause 7.2.4.3.2: - Add description about Join Request via PDU Session Establishment Request and Join Accept via PDU Session Establishment Accept. - Fix step# from step 4 to step 3 about interaction between SMF and MB-SMF.

Comment:

Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108652 (CR) 23.247 CR0006R2 (Rel-17, 'F'): Multicast MBS Session: resolving ENs and cleanup. (Source: Based on (Ericsson, CATT, vivo, Nokia, Nokia Shanghai-Bell, ZTE), vivo).
Document for: Approval.
Abstract: Summary of change: Merge clause 7.2.7 into clause 7.2.6, and corrections are also made to improve consisteny In clause 9.4.2, update the service operation names to Nnef_MBSTMGI_Allocate and Nnef_MBSTMGI_Deallocate -On top of r12, clause 7.2.6, add missing 'SMF', which is included in the sentence before: For a UE previously outside the service area but now inside the updated service area, the SMF adds associated unicast QoS flows for the multicast MBS session to the PDU session resources. Rev02: 1. Make step 3-7 mandate to Service Area Update 2. In step 12, PDU Session Update only is performed to those UEs that 'in/out' state is changed 3. Remove the redundant description in step 12 for N2 container for PDU Session Update.

Comment:

Revision of (Agreed) S2-2108002 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

Thomas (Nokia) raises concerns against this CR update. Suggest noting it
Zhenhua (vivo) replies to Thomas (Nokia) and ask Thomas to reconsider the position.
Thomas (Nokia) replies to Zhenhua.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108679 (DISCUSSION) Mobility in local MBS service.. (Source: Huawei, HiSilicon).
Document for: Agreement.
Abstract: This contribution discuss the mobility in local MBS service.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108680 (CR) 23.247 CR0021R2 (Rel-17, 'F'): Clarification of the local MBS service. (Source: Huawei, HiSilicon, [LG Electronics, Nokia, Nokia Shanghai-Bell, Samsung, ZTE,vivo]).
Document for: Approval.
Abstract: Summary of change: Remove unnecessary plural description Add the UE mobility event subscritption description Remove the MB-SMF can skip the registration part description. Add new clause about the local MBS session activation and termination of the local MBS session. Remove unclear NOTE description. Rev 2: Clause 6.2.1 the subscription also applies to the shared delivery to let the SMF be aware that the UE need be removed from the MBS session. Adrress the Editor's Note related to mobility procedure. Add two new clause related to the UE is removed from the MBS session. Add a new clause related to the Inactivate MBS session state mobility handling.

Comment:

Revision of (Agreed) S2-2108014 from S2#147E. CC#2: r12 + changes agreed. Revised to S2-2109343, merging S2-2108977.

Discussion and conclusion:

CC#2: S2-2108680r012 with changes was proposed by Huawei. r12 with changes was agreed and revised in S2-2109343.

e-mail discussion:

Fenqin (Huawei) provides r01 with an attempt to merge suggestion from 8977r01
Zhenhua (vivo) ask why 7.2.4.X is removed
Thomas (Nokia) comments that new version is incomplete and split into two versions not possible
suggest to focus the discussion in the 8977 thread
Fenqin (Huawei) provides r02
Thomas Nokia provides r03
Agrees to focus discussion on this thread and regard 8977 as merged.
Fenqin (Huawei) provides r04 and suggest to take this as basic for Local MBS discussion
Thomas (Nokia) provides r05
Fenqin (Huawei) provides r06
Judy (Ericsson) provide r07 based on r05
Fenqin (Huawei) provide r08
Judy (Ericsson) provide r09
Thomas (Nokia) objects against r07
Thomas (Nokia) objects against r08
Fenqin (Huawei) provides r10
Judy (Ericsson) responds to Thomas (Nokia)
Thomas(Nokia) provides r11
Thomas(Nokia) asks Judy to clarify her position regarding autonomous switching at RAN node
Judy (Ericsson) responds to Thomas(Nokia) that we do support the intra-RAN mobility but does not see the need to introduce new terms 'autonomous switching' and 'combined service area'.
Fenqin(Huawei) provides r12
==== Revisions Deadline ====
Thomas(Nokia) asks Judy for more clarifications.
Nokia objects against r00, r01, r02, r04, r07, r08 and r09
Judy (Ericsson) accepts r07, r09, cannot accept r11 as is and request to remove 'combined service area' and 'autonomous' (see below), objects to other revisions and responds to Thomas(Nokia)
Fenqin (Huawei) provides r13, which is based on R12 + change suggested by Judy(Ericsson)
Judy (Ericsson) responds to Fenqin (Huawei)
Fenqin (Huawei) provides r14 and suggest bring this to CC#2.
==== Comments Deadline ====.

Status:

Revised to S2-2109343, merging S2-2108977.

TD S2-2109343 (CR) 23.247 CR0021R4 (Rel-17, 'F'): Clarification of the local MBS service. (Source: Huawei, HiSilicon, LG Electronics, Nokia, Nokia Shanghai-Bell,Samsung, ZTE,vivo).
Document for: Approval.
Abstract: Summary of change: Remove unnecessary plural description Add the UE mobility event subscritption description Remove the MB-SMF can skip the registration part description. Add new clause about the local MBS session activation and termination of the local MBS session. Remove unclear NOTE description. Rev 2: Clause 6.2.1 the subscription also applies to the shared delivery to let the SMF be aware that the UE need be removed from the MBS session. Adrress the Editor's Note related to mobility procedure. Add two new clause related to the UE is removed from the MBS session. Add a new clause related to the Inactivate MBS session state mobility handling.

Comment:

CC#2: Revision of S2-2108680r12 + changes, merging S2-2108977. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108975 (DISCUSSION) Location based services. (Source: Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Location based services.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108977 (CR) 23.247 CR0021R3 (Rel-17, 'F'): Clarification of the local MBS service. (Source: [Huawei, HiSilicon, LG Electronics,] Nokia, Nokia Shanghai-Bell, [Samsung, ZTE, vivo]).
Document for: Approval.
Abstract: Summary of change: Remove unnecessary plural description Add the UE mobility event subscritption description Remove the MB-SMF can skip the registration part description. Add new clause about the local MBS session activation and termination of the local MBS session. Remove unclear NOTE description. The RAN node switches autonomously between service areas for location based services The RAN node notifies the SMF only if the UE leaves the combined service area.

Comment:

Revision of (Agreed) S2-2108014 from S2#147E. Merged into S2-2109343.

Discussion and conclusion:

-

e-mail discussion:

Thomas (Nokia) provides r01 with an attempt to merge 8680
Fenqin (Huawei) comments and suggest this update focus on the three call flow
Thomas (Nokia) provides r02 with more changes discussed with Fenqin
Thomas(Nokia) agrees to merge this contribution into 8680
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Merged into S2-2109343.

## MBS PCC

TD S2-2108396 (CR) 23.247 CR0004R1 (Rel-17, 'F'): Policy Control for MBS Session. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: Clause 7.1.1: Replace the PCC interactions with MB-SMF interaction with PCF, describe only the difference to the procedure without PCC. For MBS Session update with updated service requirement (e.g. QoS, packet filter), new policy trigger for MBS Resource Request is introduced. Clause 5.3.2.1, remove 'The PCF can receive MBS information from AF, NEF or MBSF-' Clause 6.6, remove 'Editor's note: The following description depends on the ongoing PCF discussion and needs revisit' Clause 6.10, Remove text related to MBS Session binding Clause 9.2, add service operation 'Npcf_MBSPolicyControl_Update', remove Npcf_MBSPolicyAuthorization Service.

Comment:

Revision of (Noted) S2-2107193 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

Thomas (Nokia) object against this CR
Zhendong (ZTE): similar view with thomas
Judy (Ericsson) would like to remind Zhendong (ZTE) and Thomas (Nokia) that, in addition to the unnecessary complexity on the AF and 5GC NFs without any clear benefit (see more in 8407), the current MBS PCC solution does not work for multiple MBS QoS Flows, thus request to reconsider their position.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108405 (LS OUT) [DRAFT] LS on AF/MBSF handling MBS Session when dynamic PCC is deployed. (Source: Ericsson).
Document for: Approval.
Abstract: This LS out asks feedback and comments from SA WG4/SA WG6 that AF/MBSF acts differently depending on availability of dynamic PCC.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Thomas (Nokia) objects against this LS
==== Revisions Deadline ====
Judy (Ericsson) responds to Thomas (Nokia) that we believe it is part of the SA2 work asking for feedback from WGs (SA4/SA6 in our case), particularly when additional/unreasonable requirements are added to MBSF and AF.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108407 (DISCUSSION) Policy Control for MBS Session .. (Source: Ericsson).
Document for: Agreement.
Abstract: This paper discusses complexities and potential issues of the PCC solution and propose a way forward.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108882 (CR) 23.247 CR0039R1 (Rel-17, 'F'): Calrification on the initial MBS session configuration and update. (Source: ZTE).
Document for: Approval.
Abstract: Summary of change: Remove the EN in the clause 7.1.1.2 and 7.1.1.3. And claify, PCF may create the MBS policy according to operator configuration/policy if there is no service requirement. Removign the clause 7.1.1.7 in the step 14 in clause 7.1.1.2 Repalce the 7.2.x with 7.2.7 in the figure and step description in clause 7.1.1.6 and 7.1.1.7.

Comment:

Revision of (Postponed) S2-2107739 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

Judy (Ericsson) comments that the EN in 7.1.1.3 is removed without providing a working solution.
==== Revisions Deadline ====
Judy (Ericsson) objecst to this paper as commented previously
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108883 (CR) 23.247 CR0040R1 (Rel-17, 'F'): Update to the Removal of MBS session configuration with PCC and related service operation.. (Source: ZTE).
Document for: Approval.
Abstract: Summary of change: Removing the EN in the clause 9.2.2.4. Modify the Removal fo MBS session configuration procedure, the MB-SMF sends the Npcf_MBSPolicyControl_Delete to request the deletion of the SM Policy Association.

Comment:

Revision of (Postponed) S2-2107740 from S2#147E. Confirm CR Revision - CR states 0! Noted.

Discussion and conclusion:

-

e-mail discussion:

Judy (Ericsson) comments this paper is related to general MBS PCC discussion
Zhendong (ZTE): clarify this CR is not related to general PCC.
==== Revisions Deadline ====
Judy (Ericsson) objects to this paper as the proposed update is based on a PCC solution that does not work for multiple MBS QoS Flows.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108983 (CR) 23.247 CR0050R1 (Rel-17, 'F'): PCC related MBS corrections. (Source: Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: 2. MBS Session policy control subscription information in the UDR is defined. Multicast session ID or an application identifier provided by the AF can serve as data key. 3. The editorµs note about failure handling is removed. 4. Explicitly signalled QoS Characteristics are added as information 5. If the PCF has no information about the multicast session ID, it provides preconfigured default policies.

Comment:

Revision of (Postponed) S2-2107780 from S2#147E. r03 agreed. Revised to S2-2109186.

Discussion and conclusion:

-

e-mail discussion:

Judy (Ericsson) comments that the EN is removed without providing a working solution. More comments below
Thomas (Nokia) replies to Judy and provides r01
Judy (Ericsson) provide r02 and responds
Mirko (Huawei) provide r03.
Thomas (Nokia) provides r04.
==== Revisions Deadline ====
Judy (Ericsson) accepts r02&r03, object to other revisions including r00.
Thomas(Nokia) can accept r03.
==== Comments Deadline ====.

Status:

Revised to S2-2109186.

TD S2-2109186 (CR) 23.247 CR0050R2 (Rel-17, 'F'): PCC related MBS corrections. (Source: Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: 4. Explicitly signalled QoS Characteristics are added as information 5. If the PCF has no information about the multicast session ID, it provides preconfigured default policies.

Comment:

Revision of S2-2108983r03. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108600 (CR) 23.247 CR0059 (Rel-17, 'F'): MBS session update related procedures. (Source: CATT).
Document for: Approval.
Abstract: Summary of change: For both MBS Session Update with PCC and without PCC procedures: Correct the NF services used, clause references for multicast session update procedures, etc. For MBS Session Update with PCC procedure: merge the handling for 'updates of MBS service area and/or MBS session activation/deactivation' with that for 'updates of the service description and QoS related updates', i.e. applying same interactions of NEF/MBSF->PCF->MB-SMF for MBS related PCC control.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Judy (Ericsson) does not see the justification why MBS Session Update with service area update should go via PCF
Xiaoyan (Xiaoyan) provides r01.
Xiaoyan (CATT) provides r01.
Judy (Ericsson) comments there is still no justification provided, and proposed update does not resolve the issue of the current MBS PCC solution.
Fenqin (Huawei) also suggest not to touch the update with PCC.
Xiaoyan (CATT) provides r02.
==== Revisions Deadline ====
Judy (Ericsson) objects to this paper (all revisions including r00) which does not solve the issue in a systematic way but bring new problem
==== Comments Deadline ====.

Status:

Noted.

## MBS SAI

TD S2-2108394 (CR) 23.247 CR0007R1 (Rel-17, 'F'): Introducing MBS SAI and updating MBS service area. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: #1 Introduce 3-octet MBS SAI to identify a group of cells within a PLMN and is frequency agnostic and MBS SAI replaces TAI. Update description related to MBS service area as follows: MBS service area represented by MBS SAI list, cell ID list, geographical area information or civic address information can be used by AF, and MBS service area represented by MBS SAI list and/or cell ID list is used in 5GC and NG-RAN. MBS service area (MBS SAI list, cell ID list, geographical area information or civic address information) may be included in the service announcement for local multicast MBS service or broadcast MBS service. NEF translates the geographical area information or civic address information to MBS SAI list. MBS service area (MBS SAI list and/or cell ID list) will be used by 5GC and NG-RAN for area restriction for local multicast MBS service or broadcast MBS service. MBS service area (MBS SAI list and/or cell ID list) may be included in the Join Accept or Join Reject NAS messages #2 In MBS session create or TMGI allocate request, AF may provide geographical area information or civic address information as MBS service area. In this case, NEF/MBSF translates it into MBS SAI list and include MBS SAI list in in MBS session create or TMGI allocate response as MBS service area. #3 In clause 7.1.1.2 & 7.1.1.3, MBS service area should be provided in TMGI allocation when needed.

Comment:

Revision of (unhandled) S2-2107197 from S2#147E. Postponed.

Discussion and conclusion:

-

e-mail discussion:

Thomas (Nokia) raises concerns against this CR
Robbie (Ericsson) responds to Thomas (Nokia)
==== Revisions Deadline ====
Robbie (Ericsson) proposes to postpone this CR which is related with MBS SAI discussion
LiMeng (Huawei) agrees to postpone this CR.
==== Comments Deadline ====.

Status:

Postponed.

TD S2-2108395 (CR) 23.502 CR3139R1 (Rel-17, 'F'): Introducing MBS SAI and updating MBS service area. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: Clause 5.2.2.3.1, the 'Area of Interest' supports MBS SAIs. Clause 5.2.7.2.2, add missing parameter 'MBS service area' in the AMF profile. Clause 5.2.7.3.2, add the missing parameter 'MBS service area' for AMF discovery.

Comment:

Revision of (unhandled) S2-2107199 from S2#147E. Postponed.

Discussion and conclusion:

-

e-mail discussion:

Thomas (Nokia) comments that this CR needs to be postponed
LiMeng (Huawei) agrees that this CR needs to be postponed, sorry for not providing a timely comment.
Robbie (Ericsson) agrees with LiMeng (Huawei) and Thomas (Nokia) to postpone this CR.
==== Comments Deadline ====.

Status:

Postponed.

TD S2-2108406 (DISCUSSION) MBS SAI Discussion.. (Source: Ericsson).
Document for: Agreement.
Abstract: This paper discusses the topics in LS on MBS broadcast service continuity and MBS session identification from RAN WG2 and proposes the introducing of MBS SAI.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Robbie (Ericsson) proposes to use this paper for MBS SAI discussion to avoid the same discussion in multiple threads and asks company's view on the options discussed in offline CC.
Zhendong (ZTE): provides feedback
LiMeng (Huawei) suggests a way forward regarding the SAI.
Robbie (Ericsson) is supportive for the suggestion from LiMeng (Huawei).
Thomas (Nokia): provides feedback
Thomas(Nokia) replies to the proposals of Limeng
LiMeng (Huawei) replies to Thomas.
Robbie (Ericsson) replies to Thomas (Nokia)
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108668 (CR) 23.247 CR0065 (Rel-17, 'F'): On the support of SAI in Rel-17 MBS. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Introduce the Abbreviation for MBS SAI in clause 3.2. Introduce the concept of MBS Serving Area Identity in new clause 6.x.

Comment:

Postponed.

Discussion and conclusion:

-

e-mail discussion:

Robbie (Ericsson) raises concerns against this CR
==== Revisions Deadline ====
Robbie (Ericsson) proposes to postpone this CR which is related with MBS SAI discussion
LiMeng (Huawei) is fine with postponing this document.
==== Comments Deadline ====.

Status:

Postponed.

TD S2-2108670 (LS OUT) [DRAFT] LS on SAI usage. (Source: Huawei,HiSilicon).
Document for: Approval.
Abstract: This contribution clarifies the UP activation of the session join procedure in 7.2.1.3.

Comment:

r01 agreed. Revised to S2-2109187.

Discussion and conclusion:

-

e-mail discussion:

LiMeng (Huawei) suggests to provide a revision on this after we have a concrete idea on SAI.
Robbie (Ericsson) asks LiMeng (Huawei) whether this one can be used to respond S2-2108991 (R2-2111511)
==== Revisions Deadline ====
LiMeng (Huawei) agrees that the content can be used to respond, but this one is a separated document and suggests to approved it.
Tao(VC) let's check to approve r01 then.
==== Comments Deadline ====.

Status:

Revised to S2-2109187.

TD S2-2109187 (LS OUT) LS on MBS broadcast service continuity and MBS session identification. (Source: SA WG2).
Document for: Approval.
Abstract: To: RAN WG2. CC: RAN WG3. Attachments: CR0074 of TS 23.247 (S2-2109331).

Comment:

Revision of S2-2108670r01. Approved.

Discussion and conclusion:

-

Status:

Approved.

TD S2-2108953 (CR) 23.247 CR0072 (Rel-17, 'F'): Adding the MBS SAI definition and description. (Source: ZTE).
Document for: Approval.
Abstract: Summary of change: Adding the MBS SAI definition. Clarify the Broadcast area can comprises several MBS SAIs. The management of mapping between MBS SAI and cell list is perform in the MBSF.

Comment:

Merged into S2-2109331.

Discussion and conclusion:

-

e-mail discussion:

Thomas (Nokia) raises concerns against this CR
==== Revisions Deadline ====
Zhendong (ZTE): proposes this CR is merged to 8965
==== Comments Deadline ====.

Status:

Merged into S2-2109331.

TD S2-2108963 (DISCUSSION) New identifier for broadcast in SIBs. (Source: Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: New identifier for broadcast in SIBs.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108965 (CR) 23.247 CR0074 (Rel-17, 'F'): Broadcast Frequency selection Identifier. (Source: Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: A Broadcast frequency selection identifier (BFSID) is introdced. The BFSID is used for broadcast MBS session to announce the availability of MBS sessions in signalling between RAN nodes and the UE to guide the frequency selection of the UE. BFSIDs and their mapping to frequencies are provided to RAN nodes and made known to the MB-SMF or NEF via OAM. Based on this configuration, RAN nodes announce in SIBs over the radio interface information about the BFSIDs supported by cells and frequencies. When a broadcast session is created, BFSID(s) are selected for that broadcast session/TMGI by MB-SMF, NEF, or AF (assuming that the AF has related knowledge via business agreements). The BFSIDs assigned to a broadcast session are communicated in the service announcement towards the UE. The UE compares those BFSIDs with the BFSID(s) in SIBS for frequency selection.

Comment:

r07 agreed. Revised to S2-2109331, merging S2-2108953.

Discussion and conclusion:

-

e-mail discussion:

Robbie (Ericsson) raises concerns against this CR
Thomas(Nokia) replies to Robbie
Thomas(Nokia) provides r01 maintaining only the general description in an attempt to document agreeable principles
Robbie (Ericsson) provides r02 to keep the minimum agreeable scope
Zhendong (ZTE): provides r03
Robbie (Ericsson) objects to r03.
LiMeng (Huawei) provides r04.
Zhendong (ZTE): provides response
Robbie (Ericsson) provides r05 based on r04.
Thomas (Nokia) provides r06.
Zhendong (ZTE): provides r07
==== Revisions Deadline ====
Robbie (Ericsson) provides r08 to update coversheet.
LiMeng (Huawei) is fine with r07 or r08. The coversheet can be modified by Thomas before uploading the documents if r07 is agreed.
Robbie (Ericsson) is not fine with r00-r07 due to wrong coversheet. Suggest to bring to CC#2 for coversheet update on top of r07 (as indicated in r08)
LiMeng (Huawei) is fine to bring it to CC#2.
Thomas (Nokia) is fine with updated cover sheet as in r08 and bringing this to CC#2
Formally we should agree r07 + 'Summary of change is updated to 'Introduce MBS XXX ID (a temporary name).'
==== Comments Deadline ====.

Status:

Revised to S2-2109331, merging S2-2108953.

TD S2-2109331 (CR) 23.247 CR0074R1 (Rel-17, 'F'): Broadcast Frequency selection Identifier. (Source: Nokia, Nokia Shanghai Bell, ZTE, Ericsson, Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Introduce MBS XXX ID (a temporary name).

Comment:

Revision of S2-2108965r07, merging S2-2108953. Approved.

Discussion and conclusion:

-

Status:

Agreed.

## NF Services

TD S2-2108502 (CR) 23.502 CR3192R2 (Rel-17, 'F'): Correction on NRF service operations for MBS. (Source: Samsung).
Document for: Approval.
Abstract: Summary of change: AMF discovery based on MBS service area is added MB-SMF discovery based on UE location(TAI), its reference, etc are updated.

Comment:

Revision of (Agreed) S2-2108023 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

Zhendong (ZTE): provides comments
Thomas(Nokia) suggest to note this revision
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108601 (CR) 23.247 CR0060 (Rel-17, 'F'): Updates to NF services for MBS. (Source: CATT).
Document for: Approval.
Abstract: Summary of change: Align parameters in Nmbsmf_MBSSession_ContextUpdate service operation definition for different consumers (AMF or SMF). Use Nmbsmf_MBSSession_ContextUpdate in step 5 and 7 of clause 7.2.3.2. Add parameter 'MBS Service Type (multicast or broadcast)' to Nmbsmf_MBSSession_Create service operation. Other corrections/clarifications, including: change 'notification target address' to 'Notification Target Address (+ Notification Correlation ID)', add 'unsubscribe to' for Nmbsmf_MBSSession_StatusUnsubscribe description, etc.

Comment:

r02 agreed. Revised to S2-2109188.

Discussion and conclusion:

-

e-mail discussion:

Zhendong (ZTE): provides comments
Thomas (Nokia) provides r01
Xiaoyan (CATT) provides r02
Judy (Ericsson) comments that both 8601 (CATT) and 8867 (Huawei) update clause 9 and there are some overlapping.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109188.

TD S2-2109188 (CR) 23.247 CR0060R1 (Rel-17, 'F'): Updates to NF services for MBS. (Source: CATT).
Document for: Approval.
Abstract: Summary of change: Add parameter 'MBS Service Type (multicast or broadcast)' to Nmbsmf_MBSSession_Create service operation. Other corrections/clarifications, including: change 'notification target address' to 'Notification Target Address', add 'unsubscribe to' for Nmbsmf_MBSSession_StatusUnsubscribe description, etc.

Comment:

Revision of S2-2108601r02. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108667 (CR) 23.247 CR0064 (Rel-17, 'F'): Clarification on NF services. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: For the MB-SMF service: Remove the ENs; For Nmbsmf_MBSSession_ContextUpdate service, correct the input parameters to align the associating procedures, e.g., 7.2.1.4. For the exact IEs in N2 container, correct that it is the Action for establishment/release. For Nmbsmf_TMGI_Allocate service clarify the optional input parameters could be already allocated TMGI, to extend the expiry time. For the AMF service: Remove the ENs; Correct the service operation name of Namf_MBSCommunication_N2MessageTransfer; For the exact IEs in N2 container, use 'e.g.'. For the NEF service: Remove the ENs.

Comment:

r01 agreed. Revised to S2-2109189.

Discussion and conclusion:

-

e-mail discussion:

Judy (Ericsson) comments that both 8867 (Huawei) and 8601 (CATT) update clause 9 and there are some overlapping to be resolved.
LiMeng (Huawei) provides r01 to remove the overlapping clauses.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109189.

TD S2-2109189 (CR) 23.247 CR0064R1 (Rel-17, 'F'): Clarification on NF services. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: For the MB-SMF service: For Nmbsmf_TMGI_Allocate service clarify the optional input parameters could be already allocated TMGI, to extend the expiry time. For the AMF service: Remove the ENs; Correct the service operation name of Namf_MBSCommunication_N2MessageTransfer; For the exact IEs in N2 container, use 'e.g.'. For the NEF service: Remove the ENs.

Comment:

Revision of S2-2108667r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108955 (CR) 23.247 CR0073 (Rel-17, 'F'): Clarification on the input of PCF/NEF/MB-SMF service operation. (Source: ZTE).
Document for: Approval.
Abstract: Summary of change: Adding MBS session ID as input to Npcf_MBSPolicyAuthorization Update and Delete service operation. Replace Multicast session ID with MBS session ID in pcf and NEF service opeartion.

Comment:

r02 agreed. Revised to S2-2109190.

Discussion and conclusion:

-

e-mail discussion:

Thomas (Nokia) provides r01
Judy (Ericsson) provide r02 with only cleanup in cover sheet.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109190.

TD S2-2109190 (CR) 23.247 CR0073R1 (Rel-17, 'F'): Clarification on the input of PCF/NEF/MB-SMF service operation. (Source: ZTE).
Document for: Approval.
Abstract: Summary of change: Replace Multicast session ID with MBS session ID in mbsmf and NEF service opeartion.

Comment:

Revision of S2-2108955r02. Approved.

Discussion and conclusion:

-

Status:

Agreed.

## Broadcast

TD S2-2108526 (CR) 23.247 CR0058 (Rel-17, 'F'): Modification on Broadcast service timeline. (Source: TD Tech).
Document for: Approval.
Abstract: Summary of change: The phase MBS Session Configuration and Session De-configuration are added in the Figure 4.2.2-2. The start point and the end point of session existing period in the the Figure 4.2.2-2 are modified.

Comment:

Merged into S2-2109174.

Discussion and conclusion:

-

e-mail discussion:

LiMeng (Huawei) suggests to merge this document into the Mega CR S2-2108403.
Chen Ying(TD Tech) agrees to LiMeng (Huawei)'s merging this document into the Mega CR S2-2108403. I can give a new version of the Mega CR S2-2108403 later.
Thomas (Nokia) proposes to note this contribution
==== Revisions Deadline ====
Chen Ying(TD Tech) The CR has been modifed and merged into the the Mega CR S2-2108403.
==== Comments Deadline ====.

Status:

Merged into S2-2109174.

TD S2-2108617 (CR) 23.247 CR0051R2 (Rel-17, 'F'): Corrections to MBS Broadcast Session Establishment. (Source: Based on [Nokia, Nokia Shanghai Bell, Huawei], CATT).
Document for: Approval.
Abstract: Summary of change: It is clarified that the AMF may receive N2 message response after transfering Namf_MBSBroadcast_ContextCreate response. The transfer of Namf_MBSBroadcast_ContextStatusNotify request () is added to transer the result of N2 message response received after transfering Namf_MBSBroadcast_Context create response. The AMF should indicate whether it receive responses from all NG-RAN nodes to the MB-SMF. The Namf_MBSBroadcast_ContextCreate sevice should be asynchronous in order to not delay the establishment of point-to-point N3mb transfer. The MB-SMF should have the possibility to request the maximum response time, which is now added to the request. Consequenlty, the AMF needs to be able to indicate in the Namf_MBSBroadcast_ContextStatusNotify request () that not all resposenses from NG-RANs were received. Updates compared to r1: Clarify the N2 SM information in relevant NF services (e.g. Namf_MBSBroadcast_ContextCreate) in the procedures. Further clarify the descriptions for partially successful result, i.e. MBS Session resources are not established successfully for all new/updated MBS QoS flows in all requested cells. Other corrections/clarifications, e.g. changing NG-RAN 'advertise' to 'broadcast', 'the Notification' to 'Namf_MBSBroadcast_ ContextStatusNotify'. Correct the Event ID parameter in Namf_MBSBroadcast_ContextStatusNotify service operation.

Comment:

Revision of (Agreed) S2-2108004 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

Robbie (Ericsson) asks a question
Fenqin (Huawei) also question on the 4th change.
Thomas (Nokia) provides r01
Judy (Ericsson) provides r02 and comments
==== Revisions Deadline ====
Thomas (Nokia) objects against r02 and comments
Judy (Ericsson) does not accept r00&r01, provide late r03 (based on r02) to add 'MBS service area' from AMF to RAN.
Thomas(Nokia) replies to Judy and also has concerns against late r03
Fenqin (Huawei) agree with Thomas and object r02 /r03.
Xiaoyan (CATT) replies to Judy (Ericsson) and suggest to agree r01.
Judy (Ericsson) responds to Fenqin (Huawei) and Xiaoyan (CATT)
==== Comments Deadline ====.

Status:

Noted.

## Handover

TD S2-2108655 (CR) 23.247 CR0035R2 (Rel-17, 'F'): Modification on handover procedures. (Source: Vivo Mobile Communications Co. LTD).
Document for: Approval.
Abstract: Summary of change: [7.2.3.2], [7.2.3.3] 1. Remove END MARK in figure. 2. Refer to session join procedure for N19mb shared tunnel management. 3. Remove forwarding in figure. 4. Some editorial modification. Rev 2: 1. remove '5G' from '5G MBS' 2. add ', if MBS-capable,' after the target RAN node, and remove 'whether' so that only MBS capable target RAN node can indicate 'MBS support'. 3. In 7.2.3.2 step 4, change step 13 to step 11 according to the new figure in 7.2.1.3.

Comment:

Revision of (Endorsed) S2-2108015 from S2#147E. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108931 (CR) 23.247 CR0069 (Rel-17, 'B'): Multicast Data Forwarding between RAN nodes supporting MBS. (Source: Qualcomm Incorporated).
Document for: Approval.
Abstract: Summary of change: Define a sequence number from the MB-UPF for data forwarding and PDCP sequence number synchronization between RAN nodes during handover. During handover, the source and target RAN node exchange the status (i.e. Source and target exchange PDCP SN in HO Request and HO Request Acknowledge messages) This allows srouce RAN node to know whether to perform bdata forwarding and when to stop.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Zhenhua (vivo) ask Q
Paul (Ericsson) provides comments and objects to this CR in all revisions.
Miguel (Qualcomm) responds to Paul: my understanding is a compromise way forward was agreed in RAN3?
Miguel (Qualcomm) responds to Zhenhua
Thomas(Nokia) support the CR and comments on RAN3 status
LiMeng (Huawei) considers the CR is helpful and agrees the RAN3 status mentioned by Thomas.
Paul (Ericsson) clarifies that there is no agreement in RAN3 on data forwarding at mobility between MBS supporting RAN nodes.
==== Revisions Deadline ====
LiMeng (Huawei) clarifies and comments that we can keep the 1st added paragraph of the document.
Paul (Ericsson) provides comments.
Paul (Ericsson) objects r00, the original revision.
==== Comments Deadline ====.

Status:

Noted.

## Others

TD S2-2108400 (CR) 23.247 CR0008R1 (Rel-17, 'F'): Interworking with MBMS over E-UTRAN for broadcast service. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: Replace 'multicast service' with 'MBS service' to generalize the description for interworking.

Comment:

Revision of (Agreed) S2-2107204 from S2#147E. r04 agreed. Revised to S2-2109191.

Discussion and conclusion:

-

e-mail discussion:

Thomas (Nokia) provides r01
Robbie (Ericsson) provides r02
Thomas (Nokia) accepts r02
Fenqin (Huawei) provides r03
Robbie (Ericsson) provides r04
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109191.

TD S2-2109191 (CR) 23.247 CR0008R2 (Rel-17, 'F'): Interworking with MBMS over E-UTRAN for broadcast service. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: Replace 'multicast service' with 'MBS service' to generalize the description for interworking.

Comment:

Revision of S2-2108400r04. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108509 (CR) 23.247 CR0057 (Rel-17, 'F'): Multicast MBS service for SNPN. (Source: Samsung).
Document for: Approval.
Abstract: Summary of change: Multicast service is applied to SNPN as well as PLMN. When the appropriate PDU session is not established yet, for UE join we may establish a PDN session establishment including UE join request.

Comment:

r01 agreed. Revised to S2-2109192.

Discussion and conclusion:

-

e-mail discussion:

Josep (DT) objects to this CR.
Youngkyo(Samsung) replies to Josep(DT) and request withdrawal of objection.
Zhendong (ZTE): provides comments
Youngkyo(Samsung) provides a revision r01.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109192.

TD S2-2109192 (CR) 23.247 CR0057R1 (Rel-17, 'F'): Multicast MBS service for SNPN. (Source: Samsung).
Document for: Approval.
Abstract: Summary of change: Multicast service is applied to SNPN as well as PLMN. When the appropriate PDU session is not established yet, for UE join we may establish a PDN session establishment including UE join request.

Comment:

Revision of S2-2108509r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108945 (DISCUSSION) Discussion on support of satellite access in 5MBS.. (Source: Xiaomi).
Document for: Agreement.
Abstract: Issues identified on support of satellite access in 5MBS for the determination of whether to specify solution in R17 or study them in R18.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Sherry (Xiaomi) provides r01.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108946 (CR) 23.247 CR0071 (Rel-17, 'F'): Clarification on the support of satellite access for Local MBS service and Location dependent MBS service. (Source: Xiaomi).
Document for: Approval.
Abstract: Summary of change: A NOTE is added for the clarification.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Sherry (Xiaomi) provides r01.
Sherry (Xiaomi) explains that this CR is drafted under the assumption that satellite access is already supported for 5MBS for R17.
Thomas(Nokia) suggest noting the CR.
Sherry(Xiaomi) has no problem to note the CR as long as we agree to revisit this issue in R18.
Jean Yves (Thales) also ok to note the CR as long as we agree to revisit this issue in R18
Relja (TNO) supports to revisit this issue in R18 as part of 'New SID: Architectural enhancements for 5G multicast-broadcast services Phase 2'.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

# 8.10 System enablers for multi-USIM devices (MUSIM)

This agenda item was convened by Puneet Jain (Intel).

TD S2-2108258 (LS IN) LS from RAN WG2: Reply LS on NAS-based busy indication. (Source: RAN WG2 (R2-2108855)).
Document for: Action.
Abstract: AN WG2 thanks SA WG2 for their LS on NAS-based busy indication for Idle and RRC Inactive state (R2-2106970/ S2-2105150). RAN WG2 can provide the following response to the SA WG2 questions: 1) SA WG2 respectfully asks RAN WG2 to consider the above and provide feedback. RAN WG2 discussed the topic and agreed to support only the NAS based solution for busy indication in Rel-17. 2) SA WG2 would also like to ask RAN WG2 what range of absence time RAN WG2 considers to use in the procedure for 'switching without leaving RRC Connected state'. RAN WG2 hasn't yet discussed the range of absence time and will inform SA WG2 when there is an agreement. Action: RAN WG2 respectfully asks SA WG2 and RAN WG3 to take note of the above feedback.

Comment:

Revision of S2-2107010 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

Alessio(Nokia) proposes to note this incoming LS as there is no further action for us.
Lalith(Samsung) agrees with Alessio and proposes to note this incoming LS as there is no further action for us.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108263 (LS IN) LS from CT WG1: Reply LS on NAS-based busy indication. (Source: CT WG1 (C1-214917)).
Document for: Information.
Abstract: CT WG1 thanks RAN WG2 for their LS on NAS-based busy indication (R2-2104354/C1-214013, R2-2108855/ C1-214772). CT WG1 would like to provide the following feedback. CT WG1 noticed that RAN WG2 agreed to support only the NAS based solution for busy indication in Rel-17 in the latest LS in R2-2108855/ C1-214772. When implementing the NAS based solution into CT WG1 specification, there are two questions that CT WG1 would like to seek for RAN WG2's feedback. There are several possible ways for the interaction between the NAS layer and the AS layer when the AS layer receives RAN paging: Option 1: the AS layer resumes the RRC connection upon receipt of RAN paging and then the AS layer informs the NAS layer an indication that the UE has transitioned to RRC_CONNECTED state and indication about the RAN paging; Option 2: the AS layer informs the NAS layer an indication about the RAN paging and the AS layer resumes the RRC connection based on a request from the NAS layer to the AS layer to transition to RRC_CONNECTED state (the request from NAS layer is triggered by acceptance of RAN paging or the SERVICE REQUEST message containing the 'NAS signalling connection release' indication). There could be other possible options that CT WG1 has not discussed. Question 1: CT WG1 respectfully asks RAN WG2's guidance on the interaction between the NAS layer and the AS layer when the AS layer receives RAN paging. Qusetion 2: Is a paging cause, if any, indicated together with indication about RAN paging from the AS layer to NAS layer?

Comment:

Revision of S2-2107021 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

Alessio(Nokia) proposes to note this incoming LS as there is no action for us. (we are in CC)
Lalith(Samsung) agrees with Alessio and proposes to note this incoming LS as there is no further action for us.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108447 (CR) 23.501 CR3335R2 (Rel-17, 'F'): On Connection Release and Paging Restriction during a Mobility Registration Update in a TA outside the current Registration Area. (Source: Based on (Nokia, Nokia Shanghai Bell, Intel), vivo).
Document for: Approval.
Abstract: Summary of change: Adds text clarifying that the UE does not need to wait to learn the capabilities to provide the indication and the PRs, when the UE registration is not emergency registration.

Comment:

Revision of (Agreed) S2-2108152 from S2#147E. Merged into S2-2109308.

Discussion and conclusion:

-

e-mail discussion:

Alessio(Nokia) asks to note this CR as it is a revision of an agreed CR that does not need this further revision.
Saso (Intel) proposes to MERGE this CR into S2-2108917.
Saso (Intel) replies to Alessio.
Qian (Ericsson) comments.
Xiaowan(vivo) replies and is OK to merge it into 2108917.
Saso (Intel) replies to Qian (Ericsson).
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Merged into S2-2109308.

TD S2-2108448 (CR) 23.501 CR3235R2 (Rel-17, 'F'): Enabling of paging reception for 5GS. (Source: Based on (Intel, Sony, Ericsson, Apple), vivo).
Document for: Approval.
Abstract: Summary of change: Upon detection of Paging Occasion (PO) collisions and the UE registration is not emergency registration, the MUSIM UE uses the Mobility Registration procedure to trigger a new 5G-GUTI assignment. Clarify the Paging Timing Collision Control feature doesn't require capability exchange between the UE and network.

Comment:

Revision of (Agreed) S2-2108145 from S2#147E. Merged into S2-2109308 and S2-2109310.

Discussion and conclusion:

-

e-mail discussion:

Qian (Ericsson) comments and propose to merge with 8917 and 8941
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Merged into S2-2109308 and S2-2109310.

TD S2-2108449 (CR) 23.501 CR3372 (Rel-17, 'F'): MUSIM features for Emergency Registration. (Source: Vivo).
Document for: Approval.
Abstract: Summary of change: During emergency registration, both the UE and the network side indicate the Paging Cause Indication for Voice Service, Reject Paging Request and Paging Restriction are not supported.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Guillaume (MediaTek Inc.) asks for clarification
Alessio(Nokia) comments
Qian (Ericsson) comments
Xiaowan(vivo) replies
alessio(nokia) comments and objects to all CRs on emergency at this meeting as they are not really what we need.
Juan Zhang (Qualcomm) provides comments
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108450 (CR) 23.502 CR3239 (Rel-17, 'F'): MUSIM features for Emergency Registration. (Source: Vivo).
Document for: Approval.
Abstract: Summary of change: During emergency registration, both the UE and the network side indicate the Paging Cause Indication for Voice Service, Reject Paging Request and Paging Restriction are not supported. Clarify Note1.

Comment:

r03 agreed. Revised to S2-2109299.

Discussion and conclusion:

-

e-mail discussion:

Alessio(Nokia) requests to note this paper
Xiaowan(vivo) replies Alessio(Nokia)
Alessio(Nokia) comments that indeed we need to indicate how to not hinder callback in general
Lalith(Samsung) seeks clarification.
Xiaowan(vivo) replies Lalith(Samsung)
Xiaowan (vivo) is fine with Alessio(Nokia)'s update.
Saso (Intel) comments Alessio(Nokia)'s update.
Xiaowan (vivo) provides r01 and comment for choice1 provided by Saso (Intel)
Lalith(Samsung) comments.
Saso (Intel) replies to Xiaowan. Object to r01.
Lalith(Samsung) is OK.
Xiaowan(vivo) replies to Saso (Intel) and seek clarification for your comment
Xiaowan(vivo) provides r02
Qian (Ericsson) asks question
Saso (Intel) is OK with r02. Editorial fixes needed
Xiaowan(vivo) replies to Qian (Ericsson)
Xiaowan (vivo) provides r03 to renumber NOTEs.
==== Revisions Deadline ====
Juan Zhang (Qualcomm) is fine with r03.
alessio (Nokia) is fine with r03.
==== Comments Deadline ====.

Status:

Revised to S2-2109299.

TD S2-2109299 (CR) 23.502 CR3239R1 (Rel-17, 'F'): MUSIM features for Emergency Registration. (Source: Vivo).
Document for: Approval.
Abstract: Summary of change: Clarify Note1 and change it to normotive text.

Comment:

Revision of S2-2108450r03. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108483 (DISCUSSION) Discussion on paging restrictions and signalling.. (Source: LG Electronics).
Document for: Discussion.
Abstract: This paper discusses whether NAS signalling can trigger the paging when a UE has provided paging restriction.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Lalith (Samsung) seeks clarification.
Myungjune (LGE) replies to Lalith (Samsung)
Steve (Huawei) this discussion document should be NOTED.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108484 (CR) 23.401 CR3672 (Rel-17, 'F'): Clarification on paging restrictions and signalling. (Source: LG Electronics).
Document for: Approval.
Abstract: Summary of change: Clarify that if voice service or PDN Connection is allowed to be paged, associated signalling for voice service or PDN Connection can trigger the paging.

Comment:

Merged into S2-2109306.

Discussion and conclusion:

-

e-mail discussion:

Steve (Huawei) should be NOTED or marked as merged to S2-2108875
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Merged into S2-2109306.

TD S2-2108485 (CR) 23.501 CR3377 (Rel-17, 'F'): Clarification on paging restrictions and signalling. (Source: LG Electronics).
Document for: Approval.
Abstract: Summary of change: Clarify that if voice service or PDU Session is allowed to be paged, associated signalling for voice service or PDU Session can trigger the paging.

Comment:

Merged into S2-2109306.

Discussion and conclusion:

-

e-mail discussion:

Steve (Huawei) should be NOTED or marked as merged to S2-2108878
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Merged into S2-2109306.

TD S2-2108791 (DISCUSSION) Discussion About Paging Restriction Information Handling.. (Source: Qualcomm Incorporated).
Document for: Information.
Abstract: .

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Steve (Huawei) this discussion document should be NOTED.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108792 (CR) 23.501 CR3258R1 (Rel-17, 'F'): Clarification on paging restrictions. (Source: Qualcomm Incorporated).
Document for: Approval.
Abstract: Summary of change: Clarify that if voice service or PDU Session is allowed to be paged, SM signalling associated with voice service or PDU Session can trigger the paging.

Comment:

Revision of (Postponed) S2-2107220 from S2#147E. Merged into S2-2109306.

Discussion and conclusion:

-

e-mail discussion:

Alessio(Nokia) proposes to merge this in S2-2108878
Saso (Intel) proposes to use the DISCUSSIONS list to discuss the four options on the table.
Steve (Huawei) should be NOTED or marked as merged to S2-2108878
Juan Zhang (Qualcomm) agrees this CR is merged to S2-2108875
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Merged into S2-2109306.

TD S2-2108793 (CR) 23.401 CR3660R1 (Rel-17, 'F'): Clarification on paging restrictions. (Source: Qualcomm Incorporated).
Document for: Approval.
Abstract: Summary of change: - Clarify that if voice service or PDN Connection is allowed to be paged, SM signalling associated with voice service or PDN Connection can trigger the paging in clause 4.3.33.6. - MME provides acceptance/rejection of the requested Paging Restriction Information to UE in the Tracking Area Update Accept message in clause 5.3.3.1. - if MME detects that paging restriction information is setting as all paging is restricted, MME will not page UE in clause 5.4.4.1.

Comment:

Revision of (Postponed) S2-2107219 from S2#147E. Merged into S2-2109306.

Discussion and conclusion:

-

e-mail discussion:

Alessio(Nokia) proposes to merge this in S2-2108875
Saso (Intel) proposes to use the DISCUSSIONS list to discuss the four options on the table.
Steve (Huawei) should be NOTED or marked as merged to S2-2108875
Juan Zhang (Qualcomm) agrees this CR is merged to S2-2108875.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Merged into S2-2109306.

TD S2-2108794 (CR) 23.502 CR3287 (Rel-17, 'F'): Clarification on paging restrictions. (Source: Qualcomm Incorporated).
Document for: Approval.
Abstract: Summary of change: - Adding AMF sends acceptance / rejection of Paging Restriction Information in Registration Accept message in clause 4.2.2.2.2. - Adding AMF sends acceptance / rejection of Paging Restriction Information in Service Accept message in clause 4.2.3.2. - Adding the condition for the SMF initiated PDU session release procedure, if UE is in CM-IDLE state and the 'skip indicator' is not included in the Namf_Communication_N1N2MessageTransfer service operation but the AMF detects that the UE context contains Paging Restriction Information with all paging is restricted, AMF will skip paging UE and response SMF N1 SM Message Not Transferred.

Comment:

r02 agreed. Revised to S2-2109300.

Discussion and conclusion:

-

e-mail discussion:

Alessio(Nokia) provides r01
Juan Zhang (Qualcomm) is fine with r01.
Steve (Huawei) asks a question
Juan Zhang (Qualcomm) replies to Steve (Huawei).
Juan Zhang (Qualcomm) provides r02.
Steve (Huawei) Juan Zhang (Qualcomm)
==== Revisions Deadline ====
alessio(Nokia)ok with r02.
==== Comments Deadline ====.

Status:

Revised to S2-2109300.

TD S2-2109300 (CR) 23.502 CR3287R1 (Rel-17, 'F'): Clarification on paging restrictions. (Source: Qualcomm Incorporated, Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: - Adding AMF sends acceptance / rejection of Paging Restriction Information in Registration Accept message in clause 4.2.2.2.2. - Adding AMF sends acceptance / rejection of Paging Restriction Information in Service Accept message in clause 4.2.3.2. - Adding the condition for the SMF initiated PDU session release procedure, if UE is in CM-IDLE state and the 'skip indicator' is not included in the Namf_Communication_N1N2MessageTransfer service operation but the AMF detects that the UE context contains Paging Restriction Information with all paging is restricted, AMF will skip paging UE and response SMF N1 SM Message Not Transferred.

Comment:

Revision of S2-2108794r02. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108797 (DISCUSSION) Discussion on Paging Cause Indication in the RRC Inactive Assistance Info.. (Source: Sony, Ericsson, Samsung).
Document for: Agreement.
Abstract: Discussion whether 'Paging Cause Indication for Voice Service Supported' should be added to the RRC Inactive Assistance Information.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108799 (CR) 23.501 CR3430 (Rel-17, 'F'): Adding Paging Cause Indication for Voice Service Supported in the RRC Inactive AI. (Source: Sony, Ericsson, Samsung).
Document for: Approval.
Abstract: Summary of change: Adding Paging Cause Indication for Voice Service Supported in the RRC Inactive AI Clarify that the RRC Inactive Assistance information is also important for NG RAN to perform RAN based paging.

Comment:

r03 agreed. Revised to S2-2109301.

Discussion and conclusion:

-

e-mail discussion:

Alessio(Nokia)provides r01
Juan Zhang (Qualcomm) thinks r01 is good and we support the idea to include the paging cause in RRC_Inactive assistance information.
Jianning (Xiaomi) provides comment
Lars (Sony) r01 is good
Lars (Sony) responds to Jianning
Jianning (Xiaomi) replies to Lars (Sony)
Lars (Sony) replies to Jianning
Steve (Huawei) provides r02
Lars (Sony) provides r03
Jianning (Xiaomi) replies to Lars (Sony), and propose way forward on r04
Lars (Sony) provides r05
Xiaowan (vivo) comments .
Lars (Sony) provides r06.
Jianning (Xiaomi) comment on r05/06, suggest to go with r04
Steve (Huawei) is the clause consistent before the changes?
Lars (Sony) responds to Jianning does not think r04 is the way to go
==== Revisions Deadline ====
Lars (Sony) responds to Jianning.
Juan Zhang (Qualcomm) prefers r06.
Jianning (Xiaomi) asks clarification to Juan (Qaulcomm)
Jianning (Xiaomi) seeks clarification from Lars (Sony)
Lars (Sony) provides clarification.
Alessio(Nokia) would like to suggest we approve r06
Jianning (Xiaomi) replies to Lars (Sony) , propose new way forward with acceptance that PC indication in RRC Inactive Assistance Information
Lars (Sony) asks Jianning to please consider r06.
Lars (Sony) asks Jianning to please consider r03 which may be even closer to your r07.
Lars (Sony) can we approve either r03 or r06?
Jianning (Xiaomi) replies to Lars (Snoy), r06 is not clear version for us, suggest to go with r07 in CC#2
Jianning (Xiaomi) replies to Lars (Sony), the r03 or r06 still contains something that we cannot accept, suggest to go r07 in CC#2
Lars (Sony) I will then ask to approve r03 + update second change with replacing 'The RRC Inactive Assistance Information also includes information ' with 'The Paging Cause Indication for Voice Service is used'
Lars (Sony) asks to handle this tdoc in CC#2.
Jianning (Xiaomi) agree with lars (Sony)'s new proposal based on r03, by replacing 'The RRC Inactive Assistance Information also includes information ' with 'The Paging Cause Indication for Voice Service is used'
==== Comments Deadline ====.

Status:

Revised to S2-2109301.

TD S2-2109301 (CR) 23.501 CR3430R1 (Rel-17, 'F'): Adding Paging Cause Indication for Voice Service Supported in the RRC Inactive AI. (Source: Sony, Ericsson, Samsung, Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: Adding Paging Cause Indication for Voice Service Supported in the RRC Inactive AI Clarify that the RRC Inactive Assistance information is also important for NG RAN to perform RAN based paging.

Comment:

Revision of S2-2108799r03. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108800 (CR) 23.502 CR3288 (Rel-17, 'F'): Paging Cause Indication for Voice Services Supported in the RRC Inactive AI. (Source: Sony, Ericsson, Samsung).
Document for: Approval.
Abstract: Summary of change: Specify that the AMF supporting the Paging Cause Indication for Voice Service shall include an indication in the RRC Inactive Assistance Information in the N2 message that the UE supports the Paging Cause Indication for Voice Service feature.

Comment:

r01 agreed. Revised to S2-2109302.

Discussion and conclusion:

-

e-mail discussion:

Alessio(Nokia) asks whether we really need this CR and whether this CR is correct.
Lars (Sony) responds to Alessio(Nokia).
Alessio(Nokia). provides r01
Jianning (Xiaomi) provide r02
Lars (Sony) responds to Jianning and is not ok with r02
Jianning (Xiaomi) replise to Lars (Sony)
Xiaowan (vivo) provides r03.
==== Revisions Deadline ====
Juan Zhang (Qualcomm) provides comments to r02 and r03.
Jianning (Xiaomi) provide comment
Lars (Sony) ask Jianning provide a reference to when 'Paging Cause Supported' in sent in the N2 initial UE context setup during SR
Lars (Sony) suggest to approve r01.
Juan Zhang (Qualcomm) supports to approve r01.
Juan Zhang (Qualcomm) replies to Jianning (Xiaomi)
Xiaowan(vivo) is OK to use r01 as basis but replace the change in step 23a by 'If the Multi-USIM UE has indicated support for the Paging Cause Indication for Voice Service feature, and the network supports the Paging Cause Indication for Voice Service, the AMF shall include an indication in the RRC Inactive Assistance Information that the UE supports the Paging Cause Indication for Voice Service to NG-RAN to enable NG-RAN to apply the Paging Cause Indication for Voice Service feature for RAN based paging'.
Jianning (Xiaomi) replies to Juan (Qaulcomm)
Jianning (Xiaomi) replies to Lars (Sony), that may be the new potential update for SR procedure, if PC indication is not in the RRC inactive AI.
Lars (Sony) is ok to approve r01 + the update suggested by Xiaowan.
alessio(Nokia) is ok to approve r01 + the update suggested by Xiaowan. this should be discussed in CC#2 then.
Lars (Sony) asks to handle this tdoc in CC#2.
==== Comments Deadline ====.

Status:

Revised to S2-2109302.

TD S2-2109302 (CR) 23.502 CR3288R1 (Rel-17, 'F'): Paging Cause Indication for Voice Services Supported in the RRC Inactive AI. (Source: Sony, Ericsson, Samsung, Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: Specify that the AMF supporting the Paging Cause Indication for Voice Service shall include an indication in the RRC Inactive Assistance Information in the N2 message that the UE supports the Paging Cause Indication for Voice Service feature.

Comment:

Revision of S2-2108800r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108805 (LS OUT) [DRAFT] LS on Paging Cause Indication for Voice Service Supported in RRC Inactive. (Source: Sony).
Document for: Approval.
Abstract: SA WG2 have discussed whether to add the 'Paging Cause Indication for Voice Service Supported' in RRC Inactive assistance information and agreed to add this information element as it is important for NG RAN to perform RAN based paging.

Comment:

r01 agreed. Revised to S2-2109303.

Discussion and conclusion:

-

e-mail discussion:

Steve (Huawei) provides r01
Lars (Sony) ok with r01
==== Revisions Deadline ====
Jianning (Xiaomi) trying to provide r02, if it is not too late.
Alessio(Nokia)) ok with r01
Jianning (Xiaomi) agree to go r01, as the consensus is made to include PC indication in RRC Inactive Assistance Information
==== Comments Deadline ====.

Status:

Revised to S2-2109303.

TD S2-2109303 (LS OUT) LS on Paging Cause Indication for Voice Service Supported in RRC Inactive assistance information. (Source: SA WG2).
Document for: Approval.
Abstract: To: RAN WG3. CC: RAN WG2. Attachments: TS 23.501 CR#3430 (S2-2109301), TS 23.502 CR#3288 (S2-2109302).

Comment:

Revision of S2-2108805r01. Approved.

Discussion and conclusion:

-

Status:

Approved.

TD S2-2108808 (CR) 23.502 CR3289 (Rel-17, 'F'): Example conditions to remove paging restrictions. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Add the example conditions for UE to remove paging restrictions.

Comment:

r02 agreed. Revised to S2-2109304. CC#2: Noted.

Discussion and conclusion:

CC#2: This was noted. The reserved revision in S2-2109304 was then withdrawn.

e-mail discussion:

Alessio(Nokia) proposes to note this paper as there is no FASMO issue this identifies and solves.
Steve (Huawei) fully rejects the comment from Alessio, the exact opposite is true.
Lars (Sony) comments
Steve (Huawei) comments
Lars (Sony)responds to Steve
Saso (Intel) comments
Steve (Huawei) provides r01
Lars (Sony) provides r02
Steve (Huawei) comments on r02, it removes the useful guidance. R01 is better.
Juan Zhang (Qualcomm) prefers r02.
Xiaowan (vivo) thinks r02 is OK and provides comment.
Steve (Huawei) comments, prefers r01. R02 loses essential guidance.
==== Revisions Deadline ====
Steve (Huawei) objects to r02.
alessio(Nokia) can live with r02 but also with no change (all revisions including the original version are non-essential correction, meaning nothing breaks without the change)
==== Comments Deadline ====.

Status:

Noted.

TD S2-2109304 (CR) 23.502 CR3289R1 (Rel-17, 'F'): Example conditions to remove paging restrictions. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Add the example conditions for UE to remove paging restrictions.

Comment:

Revision of S2-2108808r02. CC#2: WITHDRAWN.

Discussion and conclusion:

-

Status:

Withdrawn.

TD S2-2108809 (CR) 23.401 CR3675 (Rel-17, 'F'): Example conditions to remove paging restrictions. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Add the example conditions for UE to remove paging restrictions.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Alessio(Nokia) proposes to note this paper as there is no FASMO issue this identifies and solves.
Steve (Huawei) fully rejects the comment from Alessio, the exact opposite is true.
Lars (Sony) comments
Saso (Intel) comments
Steve (Huawei) provides r01
Lars (Sony) provides r02
Steve (Huawei) comments on r02, it removes the useful guidance. R01 is better.
Juan Zhang (Qualcomm) prefers r02.
==== Revisions Deadline ====
Steve (Huawei) objects to r02.
alessio(Nokia) can live with r02 but also with no change (all revisions including the original version are non-essential correction, meaning nothing breaks without the change) R01 is not ok
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108812 (CR) 23.501 CR3433 (Rel-17, 'F'): Exception of Paging Restriction for important system signalling. (Source: Xiaomi).
Document for: Approval.
Abstract: Summary of change: Three proposals as provided in the Discussion paper S2-2108815 Proposal 1a: provide new PR, e) paging of control plane signalling (e.g., MM related signalling, UE parameter update, etc.) is allowed Also to add clarification for NOTE 1: The case e) is provided by UE when the paging of control plane signalling is expected. Proposal 1b: to add 'and whether the paging of control plane signalling (e.g., MM related singnaling, SOR, Policy update, etc.) is expected' Proposal 2: to add new NOTE 3: it is up to network policy and implementation whether to send the paging of control plane signalling (e.g., MM related signalling, SOR, policy update, etc.) NOTE:There are three options provided in this doc for discussion, once one of the three is agreed, the other two will be removed.

Comment:

Merged into S2-2109307.

Discussion and conclusion:

-

e-mail discussion:

Lars (Sony) comments on new option (e) and suggest not to add (e).
Steve (Huawei) comments
Alessio(Nokia) believes the current understanding is that in mode a) the network is not expected to page at all (as the text says) and the UE is not required to monitor paging . in mode A the network should not be in a hurry to configure or reach the UE as anyhow the UE is not available for any MT service in the USIM. the next time the UE comes back to life for the USIM, the network by all means can catch up. proposes to note this CR (there is nothing FASMO here)
Jianning (Xiaomi) replies to Lars(Sony)
Jianning (Xiaomi) replies to Alessio (Nokia), actully the main issue is for PR-b), c) and d) whether the paging of control plane signaling is allowed or not, several CRs are trying to solve this issue. And people seems to agree the PR-a) is used to restrict all the paging (including paging of control plane signaling). It is too early to NOTE this paper, suggest to discuss further together with other CRs to see what can be achieved.
Lalith (Samsung) comments
Steve (Huawei) should be NOTED or marked as merged to S2-2108878
Jianning (Xiaomi) is ok to merge into 8878 for futher progress
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Merged into S2-2109307.

TD S2-2108813 (CR) 23.401 CR3676 (Rel-17, 'F'): Exception of Paging Restriction for important system signalling. (Source: Xiaomi).
Document for: Approval.
Abstract: Summary of change: Three proposals as provided in the Discussion paper S2-210xxxx Proposal 1a: provide new PR, e) paging of control plane signalling (e.g., MM related signalling, UE parameter update, etc.) is allowed Also to add clarification for NOTE 1: The case e) is provided by UE when the paging of control plane signalling is expected. Proposal 1b: to add 'and whether the paging of control plane signalling (e.g., MM related singnaling, SOR, Policy update, etc.) is expected' Proposal 2: to add new NOTE 3: it is up to network policy and implementation whether to send the paging of control plane signalling (e.g., MM related signalling, SOR, policy update, etc.) NOTE:There are three options provided in this doc for discussion, once one of the three is agreed, the other two will be removed at the end.

Comment:

Merged into S2-2109306.

Discussion and conclusion:

-

e-mail discussion:

Alessio(Nokia) asks to note this CR (there is nothing FASMO here)
Jianning (Xiaomi) replies to Alessio (Nokia), this CR openly proivdes three possible options to correct the potential issue for PR feature what we have discussed in previous meeting. it is FASMO issue. There are also other CRs to fix this issue. It is too early to NOTE the paper, there is still more time for further discussion to see what we can achieve.
Lalith (Samsung) comments
Steve (Huawei) should be NOTED or marked as merged to S2-2108875
Jianning (Xiaomi) is ok to merge into 8875 for futher progress
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Merged into S2-2109306.

TD S2-2108814 (CR) 23.502 CR3290 (Rel-17, 'F'): Exception of Paging Restriction for important system signalling. (Source: Xiaomi).
Document for: Approval.
Abstract: Summary of change: - To add 'paging of control plane signalling supported indication' in the Registration Reguest - To add 'paging of control plane signalling supported indication' in the UE triggered Service Request. - To add 'paging of control plane signalling supported indication' in the network triggered Service Request.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Alessio(Nokia) proposes to note this paper as there is no FASMO issue this identifies and solves
Jianning (Xiaomi) replies to Alessio (Nokia), this CR openly proivdes three possible options to correct the potential issue for PR feature what we have discussed in previous meeting. it is FASMO issue. There are also other CRs to fix this issue. It is too early to NOTE the paper, there is still more time for further discussion to see what we can achieve.
Saso (Intel) proposes to use the DISCUSSIONS list to discuss the four options on the table.
Steve (Huawei) should be NOTED
Jianning (Xiaomi) is ok to NOTE, as there is no impact on 502 per discussion
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108815 (DISCUSSION) Discussion on exception for paging of control plane signalling when using PR.. (Source: Xiaomi).
Document for: Discussion.
Abstract: Provide discussion on the excepted paging of control plane signalling (e.g., MM related signalling) when the PR is activated.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Alessio(Nokia) proposes to note this paper as there is no FASMO issue this identifies.
Jianning (Xiaomi) replies to Alessio (Nokia), this CR openly proivdes three possible options to correct the potential issue for PR feature what we have discussed in previous meeting. it is FASMO issue. There are also other CRs to fix this issue. It is too early to NOTE the paper, there is still more time for further discussion to see what we can achieve.
Steve (Huawei) this discussion document should be NOTED.
Jianning (Xiaomi) is ok to NOTE this Discussion paper.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108834 (CR) 23.401 CR3677 (Rel-17, 'F'): Adding Alternative IMSI to the MM Context in the MME. (Source: Sony).
Document for: Approval.
Abstract: Summary of change: Clarify the text to clearly state that it is the MME responsibility to calculate the UE Identity Index Value based on the Alternative IMSI value, and that it still only the UE Identity Index Value that is sent in the paging message. Add Alternative IMSI to the MM Context.

Comment:

r06 agreed. Revised to S2-2109305.

Discussion and conclusion:

-

e-mail discussion:

Saso (Intel) points out that the LS IN from RAN2 (8997) indicates their preference for calculating the Alternative IMS in AS, also aligned with CT1.
Lars (Sony) comments
Steve (Huawei) comments on UE vs network side.
Saso (Intel) withdraws comment.
Lars (Sony) comment and ask do we need an LS reply?.
Qian (Ericsson) provides comments.
Lars (Sony) provides r01
Steve (Huawei) LSout would be useful.
Saso (Intel) thinks that an LS OUT is not urgent.
Lars (Sony) LS OUT should be possible to send from this meeting.
Juan Zhang (Qualcomm) thinks it is useful to send the reply LS.
Saso (Intel) is not opposed to sending LS OUT from this meeting, but not sure if this is possible.
Steve (Huawei) good for me.
Lars (Sony) have requested a tdoc number now for an LS.
Lars (Sony) We can get an tdoc# only if we have consensus on the LS and it is urgent.
Jianning (Xiaomi) supports to try this LSout in this meeting.
Juan Zhang (Qualcomm) replies the comment
Steve (Huawei) provides r02.
Lars (Sony) asks Steve on r02.
Steve (Huawei) replies to Lars
Saso (Intel) comments on the LS.
Lars (Sony) provides r03 fixing the reference
Xiaowan(vivo) clarifies the reason of misalignment and propose a way forward
Lars (Sony) responds to Xiaowan
Xiaowan provide r04
Steve (Huawei) does not like r04
Lars (Sony) comments on r04 and provides r05.
Xiaowan(vivo) replies Steve (Huawei)
Xiaowan(vivo) replies to Lars (Sony).
Steve (Huawei) provides r06
==== Revisions Deadline ====
Lars (Sony) supports r06.
Juan Zhang (Qualcomm) is OK with r06.
Xiaowan(vivo) OK with r06.
Lars (Sony) When making the final update, I will add Vivo as supporting company.
==== Comments Deadline ====.

Status:

Revised to S2-2109305.

TD S2-2109305 (CR) 23.401 CR3677R1 (Rel-17, 'F'): Adding Alternative IMSI to the MM Context in the MME. (Source: Sony, Vivo).
Document for: Approval.
Abstract: Summary of change: Clarify the text to clearly state that it is the MME responsibility to calculate the UE Identity Index Value based on the Alternative IMSI value, and that it is still only the UE Identity Index Value that is sent in the paging message. Add Alternative IMSI to the MM Context Aligning term Requested Alternative IMSI offset to Requested IMSI offset.

Comment:

Revision of S2-2108834r06. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108875 (CR) 23.401 CR3678 (Rel-17, 'F'): Clarification on paging restrictions. (Source: Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: clarifies that when PRs are applied which allow for paging at least for some services and PDU sessions, the UE can still be paged for all the MT MM signalling and only the MT SM signalling related to the PDU sessions and services that can cause paging.

Comment:

r08 agreed. Revised to S2-2109306, merging S2-2108484, S2-2108485, S2-2108792, S2-2108793 and S2-2108813.

Discussion and conclusion:

-

e-mail discussion:

Lalith(Samsung) seeks clarification.
alessio (Nokia) provides r01 based on offline discussion
Myungjune (LGE) provides r02 to update coversheet
Lalith (Samsung) provides r03
Krisztian (Apple) provides r04.
Jianning (Xiaomi) comments on r03/04
Lalith(Samsung) replies to Jianning (Xiaomi)
Myungjune (LGE) comments on r03/r04
Juan Zhang (Qualcomm) asks to co-sign the CR.
Lalith(Samsung) replies to Myungjune (LGE)
Alessio(Nokia) ok with r04
Myungjune (LGE) replies to Lalith(Samsung)
Lalith(Samsung) replies to Myungjune(LGE)
Jianning (Xiaomi) share the concerns with Myungjune (LGE) on r03/04
Lalith(Samsung) comments.
Jianning (Xiaomi) replies to Lalith (Samsung), provide r05
Myungjune (LGE) provides r06
Lalith(Samsung) is OK with r05 and r06
Steve (Huawei) comments on r04, r05 and r06, provides r07.
Jianning (Xiaomi) is ok with r07
Myungjune (LGE) provides r08
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109306, merging S2-2108484, S2-2108485, S2-2108792, S2-2108793 and S2-2108813.

TD S2-2109306 (CR) 23.401 CR3678R1 (Rel-17, 'F'): Clarification on paging restrictions. (Source: Nokia, Nokia Shanghai Bell, LG Electronics, Apple).
Document for: Approval.
Abstract: Summary of change: Clarifies that when PRs are applied which allow for paging at least for some services and PDN connections, the UE can still be paged for MT signalling based on policy taking the PRs into account.

Comment:

Revision of S2-2108875r08, merging S2-2108484, S2-2108485, S2-2108792, S2-2108793 and S2-21088. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108878 (CR) 23.501 CR3449 (Rel-17, 'F'): Clarification on paging restrictions. (Source: Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: clarifies that when PRs are applied which allow for paging at least for some services and PDU sessions, the UE can still be paged for all the MT RM signalling and only the MT SM signalling related to the PDU sessions and services that can cause paging.

Comment:

r07 agreed. Revised to S2-2109307, merging S2-2108812.

Discussion and conclusion:

-

e-mail discussion:

Lalith(Samsung) seeks clarification.
Alessio(Nokia) provides r01 based on offline discussion
Myungjune (LGE) provides r02 to update coversheet
Lalith (Samsung) provides r03
Krisztian (Apple) provides r04 matching changes in 8875r04.
Jianning (Xiaomi) comments on r03/04
Alessio(Nokia) ok with r04.
Myungjune (LGE) provides r06
Xiaowan(vivo) comment
Myungjune (LGE) provides r07
==== Revisions Deadline ====
Jianning (Xiaomi) is ok with r07
==== Comments Deadline ====.

Status:

Revised to S2-2109307, merging S2-2108812.

TD S2-2109307 (CR) 23.501 CR3449R1 (Rel-17, 'F'): Clarification on paging restrictions. (Source: Nokia, Nokia Shanghai Bell, LG Electronics, Apple).
Document for: Approval.
Abstract: Summary of change: Clarifies that when PRs are applied which allow for paging at least for some services and PDU sessions, the UE can still be paged for MT signalling based on policy taking the PRs into account.

Comment:

Revision of S2-2108878r07, merging S2-2108812. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108917 (CR) 23.501 CR3235R3 (Rel-17, 'F'): Enabling of paging reception for 5GS. (Source: Intel, [Sony, Ericsson, Apple]).
Document for: Approval.
Abstract: Summary of change: Upon detection of Paging Occasion (PO) collisions, the MUSIM UE uses the Mobility Registration procedure to trigger a new 5G-GUTI assignment. Rev3: Added text to clarify that the Paging Timing Collision Control being based on the existing Mobility Registration Update procedure, the UE does not indicate support for this feature to the network.

Comment:

Revision of (Agreed) S2-2108145 from S2#147E. r01 agreed. Revised to S2-2109308, merging S2-2108447 and S2-2108448.

Discussion and conclusion:

-

e-mail discussion:

Xiaowan (vivo) provides r01
Lars (Sony)we are fine with r01, and supports the update so the brackets around Sony can be removed.
Saso (Intel) is OK with r01.
Krisztian (Apple) is fine with r01.
Jianning (Xiaomi) is ok with r01
Qian (Ericsson) is fine with r01, and supports the update so the brackets for Ericsson can be removed.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109308, merging S2-2108447 and S2-2108448.

TD S2-2109308 (CR) 23.501 CR3235R4 (Rel-17, 'F'): Enabling of paging reception for 5GS. (Source: Intel, Sony, Ericsson, Apple, vivo).
Document for: Approval.
Abstract: Summary of change: Upon detection of Paging Occasion (PO) collisions, the MUSIM UE uses the Mobility Registration procedure to trigger a new 5G-GUTI assignment. Rev3: Added text to clarify that the Paging Timing Collision Control being based on the existing Mobility Registration Update procedure, the UE does not indicate support for this feature to the network.

Comment:

Revision of S2-2108917r01, merging S2-2108447 and S2-2108448. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108939 (CR) 23.401 CR3658R1 (Rel-17, 'F'): MUSIM capabilities in Emergency Attach. (Source: Intel, [Apple]).
Document for: Approval.
Abstract: Summary of change: Clause 4.3.33.1: Clarifies that the UE shall not indicate MUSIM capabilities when performing Emergency Attach. Clause 5.3.2.1: Clarifies that the UE shall not indicate MUSIM capabilities when performing Emergency Attach.

Comment:

Revision of (Noted) S2-2107101 from S2#147E. r07 agreed. Revised to S2-2109309.

Discussion and conclusion:

-

e-mail discussion:

Alessio(Nokia) requests to note this paper
Saso (Intel) clarifies that this CR is needed to enable stage 3 work.
Qian (Ericsson) comments and supports the CR.
Xiaowan (vivo) comments and provides r01.
Saso (Intel) comments on r01. Prefers r00.
Xiaowan(vivo) replies to Saso (Intel)
Saso (Intel) provides r02. Still prefers r00. R01 is not acceptable.
Krisztian (Apple) provides r03 (equivalent with r02 but without brackets in Source). We are OK with r00 as well but r01 is not acceptable.
Krisztian (Apple) provides r04 that fixes the missing updates to the signaling flow in 5.3.2.1
Lars (Sony) provides r05.
Saso (Intel) provides r06. Objects to r05.
Lars (Sony) we are ok with r06.
Juan Zhang (Qualcomm) is ok with r06.
Xiaowan (vivo) provides r07
==== Revisions Deadline ====
Juan Zhang (Qualcomm) is fine with r07.
Lars (Sony) is fine with r07.
==== Comments Deadline ====.

Status:

Revised to S2-2109309.

TD S2-2109309 (CR) 23.401 CR3658R2 (Rel-17, 'F'): MUSIM capabilities in Emergency Attach. (Source: Intel, Apple).
Document for: Approval.
Abstract: Summary of change: Clause 4.3.33.1: Clarifies that the UE shall not indicate MUSIM capabilities when performing Emergency Attach. Clause 5.3.2.1: Clarifies that the UE shall not indicate MUSIM capabilities when performing Emergency Attach.

Comment:

Revision of S2-2108939r07. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108941 (CR) 23.501 CR3237R1 (Rel-17, 'F'): MUSIM capabilities in Emergency Registration. (Source: [Apple,] Intel).
Document for: Approval.
Abstract: Summary of change: Clarifies that the UE shall not indicate MUSIM capabilities when performing Emergency Registration.

Comment:

Revision of (Noted) S2-2107102 from S2#147E. r03 agreed. Revised to S2-2109310, merging S2-2108448.

Discussion and conclusion:

-

e-mail discussion:

Alessio(Nokia) requests to note this paper
Saso (Intel) clarifies that this CR is needed to enable stage 3 work. Proposes to keep the discussion on the 8939 thread.
Qian (Ericsson) comments and supports the CR.
Xiaowan (vivo) comments and provides r01.
Saso (Intel) comments on r01. Prefers r00.
Krisztian (Apple) provides r02 that matches the changes in 8939r04.
Saso (Intel) is OK with r02.
Juan Zhang (Qualcomm) is OK with r02.
Xiaowan (vivo) provides r03
==== Revisions Deadline ====
Juan Zhang (Qualcomm) is OK with r03.
==== Comments Deadline ====.

Status:

Revised to S2-2109310, merging S2-2108448.

TD S2-2109310 (CR) 23.501 CR3237R2 (Rel-17, 'F'): MUSIM capabilities in Emergency Registration. (Source: Apple, Intel).
Document for: Approval.
Abstract: Summary of change: Clarifies that the UE shall not indicate MUSIM capabilities when performing Emergency Registration.

Comment:

Revision of S2-2108941r03, merging S2-2108448. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108942 (CR) 23.502 CR3124R1 (Rel-17, 'F'): MUSIM capabilities in Emergency Registration. (Source: Intel, [Apple]).
Document for: Approval.
Abstract: Summary of change: Clause 4.2.2.2.2: Clarifies that the UE shall not indicate MUSIM capabilities when performing Emergency Registration.

Comment:

Revision of (Postponed) S2-2107103 from S2#147E. r03 agreed. Revised to S2-2109311.

Discussion and conclusion:

-

e-mail discussion:

Alessio(Nokia) proposes to note this CR
Saso (Intel) clarifies that this CR is needed to enable stage 3 work. Proposes to keep the discussion on the 8939 thread.
Nokia sees no reason why this is needed still
Saso (Intel) replies to Alessio
Qian (Ericsson) comments and supports the CR.
Xiaowan (vivo) comments and provides r01.
Saso (Intel) comments on r01. Prefers r00.
Krisztian (Apple) provides r02 that matches the changes in 8939r04.
Saso (Intel) is OK with r02.
Juan Zhang (Qualcomm) is OK with r02.
Xiaowan (vivo) provides r03
==== Revisions Deadline ====
Juan Zhang (Qualcomm) is OK with r03.
==== Comments Deadline ====.

Status:

Revised to S2-2109311.

TD S2-2109311 (CR) 23.502 CR3124R2 (Rel-17, 'F'): MUSIM capabilities in Emergency Registration. (Source: Intel, Apple).
Document for: Approval.
Abstract: Summary of change: Clause 4.2.2.2.2: Clarifies that the UE shall not indicate MUSIM capabilities when performing Emergency Registration.

Comment:

Revision of S2-2108942r03. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108950 (DISCUSSION) On the need of MUSIM capabilities for Emergency Attach/Registration.. (Source: Intel).
Document for: Agreement.
Abstract: Provides the rationale for the proposal in S2-2108939, S2-2108941 and S2-2108942.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108997 (LS IN) LS from RAN WG2: Reply LS on RAN2 agreements for MUSIM. (Source: RAN WG2 (R2-2111329)).
Document for: Action.
Abstract: RAN WG2 thanks CT WG1 for their reply to LS on NAS-based busy indication. Regarding the NAS-based busy indication, RAN WG2 would like to provide the following responses for the questions asked by the CT WG1 in the LS C1-214917: o Question 1: CT WG1 respectfully asks RAN WG2's guidance on the interaction between the NAS layer and the AS layer when the AS layer receives RAN paging. Answer 1: RAN WG2 has discussed the issue and agreed that the AS-NAS interaction for paging reception in RRC_INACTIVE is left up to the UE implementation. o Question 2: Is a paging cause, if any, indicated together with indication about RAN paging from the AS layer to NAS layer? Answer 2: As mentioned in Answer 1, the AS-NAS interaction for paging reception, including any paging cause, in RRC_INACTIVE is left up to the UE implementation. In addition, RAN WG2 found inconsistent between CT WG1 and SA WG2 specification on alternative IMSI calculation in EPS. Based on the CT WG1 spec, NAS will forward the accepted IMSI offset to lower layers. This is aligned with RAN WG2 agreement on PF/PO calculation for EPS since the AS layer needs the IMSI offset to calculate the UE_ID. However, SA WG2 specifies that the IMSI offset is used by the NAS layer to calculate an alternative IMSI instead of the UE_ID, and it seems that the NAS layer needs to forward the alternative IMSI to the AS for the determination of paging occasions as specified in TS 36.304. So based on the SA WG2's specification, SA WG2 is not aligned with both RAN WG2 and CT WG1's agreements. RAN WG2 prefers that the alternative IMSI is to be calculated in AS layer (i.e. aligned with CT WG1 specification). Action: RAN WG2 respectfully asks CT WG1 and SA WG2 to take the above responses into consideration and provide feedback if any.

Comment:

Postponed.

Discussion and conclusion:

-

Status:

Postponed.

TD S2-2108998 (LS IN) LS from RAN WG2: LS on RAN2 agreements for paging with service indication. (Source: RAN WG2 (R2-2111330)).
Document for: Action.
Abstract: RAN WG2 would like to inform RAN WG3/SA WG2/CT WG1/SA WG3 the RAN WG2's agreements on introduction of paging cause for voice service: - Paging cause for service indication will be introduced in NR and LTE o RAN WG2 agreed to provide the paging cause value 'voice' to UEs by extending the Paging message. The presence of the extension, which can be empty list if none of the UEs have paging cause 'voice', indicates that network supports transmission of paging cause for service indication. - For paging reception in RRC_IDLE (i.e. CN paging), UE forwards the paging cause to NAS. It's up to NAS whether to accept or reject the paging. - For paging reception in RRC_INACTIVE (i.e. RAN paging), the AS-NAS interaction is left up to UE implementation. Action: RAN WG2 respectfully ask RAN WG3/SA WG2/CT WG1 to take RAN WG2's agreements into consideration and provide feedback if any.

Comment:

Postponed.

Discussion and conclusion:

-

Status:

Postponed.

# 8.11 Architecture aspects for using satellite access in 5G (5GSAT_ARCH)

This agenda item was convened by Andy Bennett (Samsung).

TD S2-2108274 (LS IN) LS from RAN WG1: Reply LS on PDB for new 5QI. (Source: RAN WG1 (R1-2106331)).
Document for: Action.
Abstract: RAN WG1 would like to thank SA WG2 for sending their LS on PDB for the new 5QI. RAN WG1 notices that the new 5QI has a AN PDB of 812 ms and a PER of 10-6 for QoS flow of type Non-GBR. A AN PDB of 812 ms is about 1.5 RTT of the maximum round trip delay in GEO satellite access with transparent payload. RAN WG1 understands that services using Non-GBR QoS Flows should be prepared to experience congestion-related packet drops and delays. In uncongested scenarios, 98 percent of the packets should not experience a delay exceeding the 5QI's PDB. The PDB for Non-GBR denotes a 'soft upper bound' in the sense that an 'expired' packet, e.g. a link layer SDU that has exceeded the PDB, does not need to be discarded and is not added to the PER. However, there are different views in RAN WG1 whether the new 5QI is reasonable. Some companies hold the view that it is possible to satisfy the new 5QI with proper network configuration and implementation. Some companies hold the view that satisfying the new 5QI will cause severe drop in network spectral efficiency due to conservative link adaptation and significantly longer delay for retransmissions to reach PER of 10-6, and thus the new 5QI can only be satisfied in ideal conditions and recommend that SA WG2 consider higher PDB and/or higher PER for this new 5QI. In general, RAN WG1 holds the view that, if RTT is X and PER is Y, where Y is as small as 10-6, Y can be met with a delay that is multiple times of the RTT. Action: RAN WG1 respectfully requests SA WG2 to take the above into account.

Comment:

Revision of S2-2107076 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

Stefan (Ericsson) proposes to NOTE the LS.
Sherry (Xiaomi) agrees to NOTE the LS.
DongYeon (Samsung) agrees to NOTE this LS.
Jean Yves (Thales) ok to NOTE the LS
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108252 (LS IN) LS from CT WG1: LS reply on multiple TACs per PLMN. (Source: CT WG1 (C1-213965)).
Document for: Action.
Abstract: CT WG1 would like to thank RAN WG2 for their question in the LS R2-2104377/C1-212840. Here is the answer from CT WG1: Option 2 is feasible and with Option 2 the following impact to the NAS layer (non-exhaustive) is expected: - A TAI from the multiple TAIs will need to be selected as the current TAI. However, it is not clear to CT WG1 how the NAS layer selects a TAI from the multiple TAIs. CT WG1 will consider further impacts and make clarification according to feedback from RAN WG2 and SA WG2. CT WG1 needs further analyses to consider how the network gets to know the selected TAI. In addition, CT WG1 would like to ask what should be considered for TAI selection. In the LS R2-2104377/C1-212840, only the registration area is mentioned. Action: CT WG1 respectfully asks SA WG2 to provide, if any, feedback on the TAI selection in case of multiple TACs broadcast per PLMN.

Comment:

Revision of S2-2106993 from S2#147E. CC#2: Postponed.

Discussion and conclusion:

-

Status:

Postponed.

TD S2-2108255 (LS IN) LS from SA WG3: Reply LS on UE location aspects in NTN. (Source: SA WG3 (S3-212306)).
Document for: Action.
Abstract: SA WG3 thanks RAN WG2 and SA WG3-LI for the LS on UE location aspects in NTN (R2-2102055/ S3i210282). - Question 2: RAN WG2 would like to ask SA WG3 and SA WG3-LI to confirm whether A-GNSS based UE location information, i.e. computed at network using A-GNSS based measurements provided by UE, or computed by UE, can be considered reliable e.g. for lawful interception. In general, SA WG3 shares the same view with SA WG3-LI. For giving more concrete answers with better understanding, SA WG3 would like to ask the following questions for clarification: - What is the purpose of sending A-GNSS based measurements after AS security has been established? Is it for core network reselection after initial core network selection? - Are the A-GNSS based measurements used by the applied UE positioning method during LCS procedure or used in a different procedure? SA WG3 would appreciate if RAN WG2 could provide feedback to the above questions or any additional information if necessary for further discussion. Action: RAN WG2 is kindly requested to answer the above questions. SA WG2, SA WG3-LI, RAN WG3 are kindly requested to take the above information into account.

Comment:

Revision of S2-2107002 from S2#147E. CC#2: Postponed.

Discussion and conclusion:

-

Status:

Postponed.

TD S2-2108260 (LS IN) LS from RAN WG2: Response LS on Multiple TACs per PLMN. (Source: RAN WG2 (R2-2108888)).
Document for: Action.
Abstract: RAN WG2 would like to thank CT WG1 and SA WG2 for their response LSs, submitted in C1-213965 and S2-2104891, respectively. RAN WG2 has taken into account the feedback provided and confirms Option 2 (AS indicates all received TAC(s) for one PLMN to NAS layer) has been adopted by RAN WG2. As a consequence of this decision and to provide feedback requested by CT WG1, RAN WG2 has further discussed what factors can be helpful at NAS layer in TAI selection. RAN WG2 indicates that TACs in NTN are fixed to geographical location on Earth. Furthermore, RAN WG2 thinks that UE's location information could be used for TAI selection. RAN WG2 respects the final decision on which criteria to apply (e.g. UE location information or other) is up to CT WG1 and SA WG2 judgement. CT WG1 and SA WG2 may consider also other factors, specific to NAS layer. Action: RAN WG2 respectfully asks CT WG1 and SA WG2 to work on the solution for selecting a single TAC from the list of multiple TACs per PLMN indicated by the AS layer, possibly considering the feedback provided by RAN WG2.

Comment:

Revision of S2-2107015 from S2#147E. CC#2: Postponed.

Discussion and conclusion:

-

Status:

Postponed.

TD S2-2108994 (LS IN) LS from SA WG1: Reply LS on Indication of country of UE location and its use in PLMN selection. (Source: SA WG1 (S1-214208)).
Document for: Information.
Abstract: SA WG1 thanks CT WG1 for their LS on Indication of country of UE location. On the CT WG1 questions, SA WG1 provides the following answers: 1) Should the indication of UE location represent a 'country' in the manner a 'country' is defined in TS 23.122, or should the 'country' be the TR 22.926 definition of 'a country is defined as the area embedded within a set of borders and for which a unique set of regulations applies for the provision of communication services through mobile networks'? Answer SA WG1: SA WG1 do not see the purpose of 'indicated country of UE location'. Further CT WG1 would like to ask SA WG1's guidance on the usage/applicability, if at all, of the indicated country of UE location, in the subsequent PLMN selection, i.e. shall it be considered by the UE: 2) that the UE is not allowed in the current geographical position to select any PLMN which does not correspond to the indicated country of UE location; or Answer SA WG1: There is no impact of the 'indicated country of UE location' on the PLMN selection procedures. 3) the UE might select available and allowable PLMNs of that indicated country and other countries. Answer SA WG1: There is no impact of the 'indicated country of UE location' on the PLMN selection procedures.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

DongYeon (Samsung) proposes to NOTE this LS, The content of LS is noticed and the related discussion has done in S2-2108329.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108279 (LS IN) Reply LS on UE location aspects in NTN. (Source: CT WG1 (C1-216250)).
Document for: Action.
Abstract: CT WG1 thanks SA WG2 for involving CT WG1 in discussing TAC report in the ULI. CT WG1's feedback is as follows: There was no consensus in CT WG1 on the options in S2-2106651. CT WG1 will implement the NAS layer aspect of the option selected by SA WG2. Action: CT WG1 kindly requests SA WG2 to take the above feedback into account.

Comment:

Response drafted in S2-2108697. Final response in S2-2109337.

Discussion and conclusion:

-

Status:

Replied to.

TD S2-2108697 (LS OUT) [DRAFT] Reply LS on UE location aspects in NTN. (Source: OPPO).
Document for: Approval.
Abstract: This LS replies to CT WG1 about UE location aspects in NTN.

Comment:

Response to S2-2108279. Merged into S2-2109337.

Discussion and conclusion:

-

e-mail discussion:

Stefan (Ericsson) comments that there are two overlapping LSs
Jean Yves (Thales) proposes 8510 r01 merging 2 LSs out (8510 and 8697)
==== Revisions Deadline ====
Jingran (OPPO) is ok to merge.
==== Comments Deadline ====.

Status:

Merged into S2-2109337.

TD S2-2108681 (CR) 23.501 CR3413 (Rel-17, 'C'): Multiple TACs handling for NR satellite access. (Source: OPPO).
Document for: Approval.
Abstract: Summary of change: When receives multiple TAIs in the ULI, AMF proceeds with the procedure if one of the multiple TACs is not in non-allowed area or Forbidden Area, and initiates LCS procedure to determine the UE location and the TA the UE currently located. the NG-RAN may determine the TA which the UE is currently located when the target UE is in CM-CONNECTED state and provide that TAI to AMF as part of ULI.

Comment:

Merged into S2-2109097.

Discussion and conclusion:

-

e-mail discussion:

Stefan (Ericsson) provides comments
Jean Yves (Thales) provides comment and proposes to focus on 8360
==== Revisions Deadline ====
Jingran (OPPO) replies.
Stephen (Qualcomm) proposes merger of this CR into S2-2108360
==== Comments Deadline ====.

Status:

Merged into S2-2109097.

TD S2-2108693 (CR) 23.502 CR3274 (Rel-17, 'C'): Multiple TACs handling for NR Satellite Access. (Source: OPPO).
Document for: Approval.
Abstract: Summary of change: For NR satellite access, the ULI may include more than one TAIs and how multiple TACs handling is described in 23501 clause 5.4.11.X.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Stefan (Ericsson) provides comments.
==== Revisions Deadline ====
Stephen (Qualcomm) believes the CR can be noted
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108359 (DISCUSSION) Tracking Area handling for moving cells .. (Source: Ericsson).
Document for: Approval.
Abstract: This contribution discusses how to handle Soft TAC switching where multiple TACs are broadcast per PLMN in a cell.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Stephen (Qualcomm) provides comments
Hucheng (CATT) comments and gives a proposal.
Yuxin (Xiaomi) provides comments
Stefan (Ericsson) replies to Yuxin and Stephen
Stefan (Ericsson) replies to Hucheng
Hannu (Nokia) replies and prefers option B, C or E
Jean Yves (Thales) comments and propose to move forward with option C+D (opt)
Stephen (Qualcomm) provides more comments
Stefan (Ericsson) provides comments
Wanqiang (Huawei) provides comments
Guillaume (MediaTek Inc.) comments
Stephen (Qualcomm) comments again
Stefan (Ericsson) provides more comments
Wanqiang (Huawei) provides more comments
==== Revisions Deadline ====
Hannu (Nokia) comments in favour of minimum number of procedures.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108360 (CR) 23.501 CR3364 (Rel-17, 'F'): TA handling for moving cells in satellite access. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: Clarify UE, NG-RAN and 5GC handling of Tracking Areas in NTN with moving cells, and how mobility restrictions can be applied.

Comment:

r09 agreed. Revised to S2-2109097, merging S2-2108495, S2-2108496 and S2-2108681.

Discussion and conclusion:

-

e-mail discussion:

Stephen (Qualcomm) provides comments and an r01
Jingran (OPPO) provides comments.
Hucheng (CATT) comments.
Stephen (Qualcomm) replies to previous comments
Stefan (Ericsson) replies and provides r02
Wanqiang (Huawei) comments.
Hannu (Nokia) comments and shares r03.
Hucheng (CATT) replies to Stephen (Qualcomm).
Stephen (Qualcomm) provides an r04 and more comments
Hucheng (CATT) provides r05.
Yuxin (Xiaomi) provides r06.
Guillaume (MediaTek Inc.) provides r07
Stefan (Ericsson) provides r08
Yuxin (Xiaomi) replies to Stefan (Ericsson)
Stefan (Ericsson) replies to Yuxin and provides r09
==== Revisions Deadline ====
Stephen (Qualcomm) prefers r09 followed by r08, r05, r04, r07, r06 in that order
Yuxin (Xiaomi) is fine with r09
Jean Yves (Thales) is fine with r09. Thank you all for this good discussion.
Hannu (Nokia) can live with r09 but points out it's still not perfect.
==== Comments Deadline ====.

Status:

Revised to S2-2109097, merging S2-2108495, S2-2108496 and S2-2108681.

TD S2-2109097 (CR) 23.501 CR3364R1 (Rel-17, 'F'): TA handling for moving cells in satellite access. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: Clarify UE, NG-RAN and 5GC handling of Tracking Areas in NTN with moving cells, and how mobility restrictions can be applied.

Comment:

Revision of S2-2108360r09, merging S2-2108495, S2-2108496 and S2-2108681. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108501 (DISCUSSION) Resolution of Support for TACs, SAs, FAs for NR Satellite Access.. (Source: Qualcomm Incorporated).
Document for: Discussion.
Abstract: Identifies a reasonably effective and simple solution for support of TACs, SAs, FAs for NR Satellite Access.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108746 (DISCUSSION) Discussion on Supporting Multiple TACs for Satellite Access.. (Source: Huawei, HiSilicon).
Document for: Discussion.
Abstract: This discussion paper aims at making a way forward on supporting multiple TACs for satellite access and proposes gNB sends ULI to AMF after AS security is established.

Comment:

Revision of (Noted) S2-2107618 from S2#147E. Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108747 (CR) 23.501 CR3323R1 (Rel-17, 'C'): Support multiple TACs for satellite access. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: See the reason part.

Comment:

Revision of (Postponed) S2-2107619 from S2#147E. r04 agreed. Revised to S2-2109098.

Discussion and conclusion:

-

e-mail discussion:

Stefan (Ericsson) provides comments and suggests to merge this into 8360 and 8499
Wanqiang (Huawei) provides feedback and r01
Stephen (Qualcomm) provides an r02
Wanqiang (Huawei) comments on r02
Stefan (Ericsson) provides r03
Wanqiang (Huawei) provides r04
==== Revisions Deadline ====
Stephen (Qualcomm) prefers r04 followed by r03
Stefan (Ericsson) ok with r04
Jean Yves (Thales) ok with r04
Hannu (Nokia) supports r04
Relja (TNO) supports r04.
==== Comments Deadline ====.

Status:

Revised to S2-2109098.

TD S2-2109098 (CR) 23.501 CR3323R2 (Rel-17, 'C'): Support multiple TACs for satellite access. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: See the reason part.

Comment:

Revision of S2-2108747r04. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108748 (CR) 23.502 CR3197R1 (Rel-17, 'C'): Support multiple TACs for satellite access. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: See the reason part.

Comment:

Revision of (Postponed) S2-2107620 from S2#147E. Covered by S2-2108499.

Discussion and conclusion:

-

e-mail discussion:

Stefan (Ericsson) provides comments
Stephen (Qualcomm) comments that the CR seems unneeded
Stefan (Ericsson) comments and provides r01, but also ok to note CR
Wanqiang (Huawei) is ok with r01.
==== Revisions Deadline ====
Wanqiang (Huawei) propose to agree r01 if there is no other view. Also S2-2108693 <file:///C:\Users\z00330098\Downloads\Docs\S2-2108693.zip> marked as merging into this one
Stephen (Qualcomm) proposes merger into S2-2108499
Wanqiang (Huawei) OK to merge.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108496 (CR) 23.501 CR3381 (Rel-17, 'B'): Support of TAI indication in a ULI for NR Satellite Access. (Source: Qualcomm Incorporated).
Document for: Approval.
Abstract: Summary of change: Add impacts to support the Option C+D solution.

Comment:

Merged into S2-2109097.

Discussion and conclusion:

-

e-mail discussion:

Wanqiang (Huawei) comments to merge into S2-2108360 <file:///C:\Users\z00330098\Downloads\Docs\S2-2108360.zip> based on the discussion?
==== Revisions Deadline ====
Stephen (Qualcomm) agrees to merge into S2-2108360
==== Comments Deadline ====.

Status:

Merged into S2-2109097.

TD S2-2108499 (CR) 23.502 CR3251 (Rel-17, 'B'): Support of NG-RAN Location Reporting for NR Satellite Access. (Source: Qualcomm Incorporated).
Document for: Approval.
Abstract: Summary of change: Add impacts to align with the Option C+D solution.

Comment:

Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108494 (CR) 23.501 CR3379 (Rel-17, 'B'): Indicating a last visited TAI in a Registration for NR Satellite Access. (Source: Qualcomm Incorporated).
Document for: Approval.
Abstract: Summary of change: Add support for the above method of selecting the last visited TAI.

Comment:

Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108498 (CR) 23.502 CR3250 (Rel-17, 'B'): Indicating a last visited TAI in a Registration for NR Satellite Access. (Source: Qualcomm Incorporated).
Document for: Approval.
Abstract: Summary of change: Add support for the above method of selecting the last visited TAI.

Comment:

Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108495 (CR) 23.501 CR3380 (Rel-17, 'B'): Support of Service Areas and Forbidden Areas for NR Satellite Access. (Source: Qualcomm Incorporated).
Document for: Approval.
Abstract: Summary of change: Add impacts to support the new rules for SAs and FAs.

Comment:

Merged into S2-2109097.

Discussion and conclusion:

-

e-mail discussion:

Wanqiang (Huawei) comments to merge into S2-2108360 <file:///C:\Users\z00330098\Downloads\Docs\S2-2108360.zip> based on the discussion?
Stefan (Ericsson) supports to merge into 8360
==== Revisions Deadline ====
Stephen (Qualcomm) agrees to merge into S2-2108360
==== Comments Deadline ====.

Status:

Merged into S2-2109097.

TD S2-2108510 (LS OUT) [DRAFT] LS on TAC reporting in ULI and support of SAs and FAs for NR Satellite Access. (Source: Qualcomm Incorporated).
Document for: Approval.
Abstract: To: CT WG1, RAN WG2, RAN WG3. CC:

Comment:

Response to S2-2105283 (Replied to at S2#147E). r02 agreed. Revised to S2-2109337, merging S2-2108697.

Discussion and conclusion:

-

e-mail discussion:

Stefan (Ericsson) comments that there are two overlapping LSs
Jean Yves (Thales) proposes 8510 r01 merging 2 LSs out (8510 and 8697)
Stefan (Ericsson) provides r02
==== Revisions Deadline ====
Jingran (OPPO) is ok with r02
Wanqiang (Huawei) ask to add the S2-2108747 in the attachment on top of rev2
Stephen (Qualcomm) can agree the r02 and with adding S2-2108747 as another attachment
Yuxin (Xiaomi) is fine with r02
==== Comments Deadline ====.

Status:

Revised to S2-2109337, merging S2-2108697.

TD S2-2109337 (LS OUT) LS on TAC reporting in ULI and support of SAs and FAs for NR Satellite Access. (Source: SA WG2).
Document for: Approval.
Abstract: To: CT WG1, RAN WG2, RAN WG3. Attachments: S2-2109097, S2-2108494, S2-2108498, S2-2108499, S2-2109098.

Comment:

Revision of S2-2108510r02, merging S2-2108697. Approved.

Discussion and conclusion:

-

Status:

Approved.

TD S2-2108530 (CR) 23.501 CR3301R1 (Rel-17, 'C'): Support of selecting a single TAI. (Source: CATT).
Document for: Approval.
Abstract: Summary of change: Clarifying that UE selects a single TAC from the broadcasted TAC list based on its implementation; The AMF takes UE location into account to enforce mobility restriction.

Comment:

Revision of (Postponed) S2-2107446 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

Hucheng (CATT) provides r01.
==== Revisions Deadline ====
Stephen (Qualcomm) proposes merger of this CR into S2-2108360
Jean Yves (Thales) propose to note the CR
==== Comments Deadline ====
Hucheng (CATT) is OK to either merge this paper into S2-2108360 or note it, slightly prefers the merger.

Status:

Noted.

TD S2-2108514 (DISCUSSION) Discussion on Registration Update handling when broadcasting more than one TACs.. (Source: Xiaomi).
Document for: Approval.
Abstract: This paper discusses how the anomaly handling between UE and network side for mobility registration update is handled for NR satellite access.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108515 (CR) 23.501 CR3383 (Rel-17, 'C'): Mobility Registration Update handling. (Source: Xiaomi).
Document for: Approval.
Abstract: Summary of change: When receiving Registration Update indication from AMF, the UE initiates registration update procedure no matter whether there is any supported TAC in the UE which is part of the UE Registration Area or not.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Stefan (Ericsson) comments and questions the need for the CR
Hannu (Nokia) can't see why NR satellite access specific requirement for Mobility Registration Update would be needed?
Yuxin (Xiaomi) clarification request to Stefan (Ericsson) comments
Yuxin (Xiaomi) answers Hannu (Nokia) questions
Stephen (Qualcomm) comments
Guillaume (MediaTek) agrees with Stefan (Ericsson)
==== Revisions Deadline ====
Stephen (Qualcomm) proposes to note the CR
Yuxin (Xiaomi) agrees to note the CR
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108947 (CR) 23.501 CR3458 (Rel-17, 'F'): AMF selection for Intra NG-RAN node N2 based handover. (Source: Xiaomi).
Document for: Approval.
Abstract: Summary of change: Add a description on how NG-RAN node selects the target PLMN based on UE's current country and how target AMF is selected based on UE's current country during UE mobility.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

DongYeon (Samsung) provides r01.
Hannu (Nokia) provides r02 simplifying the CR even further.
Wanqiang (Huawei) comments.
Stefan (Ericsson) comments
Sherry (Xiaomi) provides r03.
Sherry (Xiaomi) provides r04.
Stefan (Ericsson) asks whether any CR is needed
Chris (Vodafone) tends to agree with Ericsson
==== Revisions Deadline ====
Hannu (Nokia) supports the view that CR is not needed and can be noted.
==== Comments Deadline ====
Sherry (Xiaomi) replies to Hannu, Chris and Stefan.

Status:

Noted.

TD S2-2108325 (CR) 23.501 CR3284R2 (Rel-17, 'F'): Editorial correction in TS 23.501. (Source: Xiaomi, Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: Add satellite backhaul category description in its debut clause.

Comment:

Revision of (Agreed) S2-2107836 from S2#147E. r02 agreed. Revised to S2-2109099.

Discussion and conclusion:

-

e-mail discussion:

DongYeon (Samsung) provides r01.
Yuxin (Xiaomi) comments to r01.
Hucheng (CATT) comments.
Hannu (Nokia) supports Yuxin and prefers the previous version of the CR before r01.
Yuxin (Xiaomi) replies and prefers to use r00.
Stephen (Qualcomm) also prefers the r00
Stefan (Ericsson) also prefers r00
Yuxin (Xiaomi) agrees with Stephen (Qualcomm) and provides r02
==== Revisions Deadline ====
Stephen (Qualcomm) prefers the r02 but the r00 is also acceptable
Jean Yves (Thales) prefers the r02 also
Hannu (Nokia) also supports r02 as the way forward. Can also live with the original version.
==== Comments Deadline ====.

Status:

Revised to S2-2109099.

TD S2-2109099 (CR) 23.501 CR3284R3 (Rel-17, 'F'): Editorial correction in TS 23.501. (Source: Xiaomi, Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: Add satellite backhaul category description in its debut clause.

Comment:

Revision of S2-2108325r02. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108326 (CR) 23.502 CR3161R2 (Rel-17, 'F'): Editorial correction in TS 23.502. (Source: Xiaomi, Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: Align the use of the cause value and the description of 'country of UE location' sending to the UE as optional information Adding Satellite backhaul category in the PDU session update request sending from V-SMF to H-SMF.

Comment:

Revision of (Agreed) S2-2107837 from S2#147E. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108327 (CR) 23.503 CR0659R2 (Rel-17, 'F'): Editorial correction in TS 23.503. (Source: Xiaomi, Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: Either satellite backhaul or non-satellite backhaul is reported when the satellite backhaul category change event was met. Reference to normative definition of satellite backhaul category is added.

Comment:

Revision of (Agreed) S2-2107838 from S2#147E. r01 agreed. Revised to S2-2109100.

Discussion and conclusion:

-

e-mail discussion:

Stephen (Qualcomm) comments
Yuxin (Xiaomi) agrees with Stephen (Qualcomm) comments and provides r01
==== Revisions Deadline ====
Stephen (Qualcomm) agrees the r01
Hannu (Nokia) supports r01 and thanks Stephen for the comment and Yuxin for providing the revision.
==== Comments Deadline ====.

Status:

Revised to S2-2109100.

TD S2-2109100 (CR) 23.503 CR0659R3 (Rel-17, 'F'): Editorial correction in TS 23.503. (Source: Xiaomi, Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: Either satellite backhaul or non-satellite backhaul is reported when the satellite backhaul category change event was met. Reference to normative definition of satellite backhaul category is added.

Comment:

Revision of S2-2108327r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108698 (CR) 23.501 CR3415 (Rel-17, 'C'): Mobility Registration Update trigger clarification. (Source: Xiaomi).
Document for: Approval.
Abstract: Summary of change: Clarify in subclasue 5.3.2.2.3 that, for NR satellite access, if a radio cell indcates support more than one TAIs for each PLMN and at least one of the indicated TAI is in the list of TAIs that the UE previously registered in the AMF, then the UE need not initiate the registration procedure for mobility and periodic registration update. If none of the indicated TAIs are in the list of TAIs that the UE previously registered in the AMF, then the UE initiates the registration procedure for mobility and periodic registration update.

Comment:

r01 agreed. Revised to S2-2109101.

Discussion and conclusion:

-

e-mail discussion:

Stefan (Ericsson) provides r01
Hannu (Nokia) prefers r01
Yuxin (Xiaomi) agrees with r01
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109101.

TD S2-2109101 (CR) 23.501 CR3415R1 (Rel-17, 'C'): Mobility Registration Update trigger clarification. (Source: Xiaomi).
Document for: Approval.
Abstract: Summary of change: Clarify in subclasue 5.3.2.2.3 that, for NR satellite access, if a radio cell indcates support more than one TAIs for each PLMN and at least one of the indicated TAI is in the list of TAIs that the UE previously registered in the AMF, then the UE need not initiate the registration procedure for mobility and periodic registration update. If none of the indicated TAIs are in the list of TAIs that the UE previously registered in the AMF, then the UE initiates the registration procedure for mobility and periodic registration update.

Comment:

Revision of S2-2108698r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108329 (CR) 23.501 CR3030R3 (Rel-17, 'F'): UE location verification handling. (Source: Ericsson, Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: Enhance description in 23.501 to allow it to be used as common reference for UE location verification makes it mandatory for the AMF to include the appropriate cause value in the reject or deregistration request. The indication of the present UE location country is optional. r03 add the AMF requirement to include suitable cause value (already specified by CT WG1 as #78) and AMF option to indicate the country.

Comment:

Revision of (Agreed) S2-2107835 from S2#147E. r02 agreed. Revised to S2-2109338.

Discussion and conclusion:

-

e-mail discussion:

DongYeon (Samsung) asks for clarification.
Hannu (Nokia) answers to DongYeon and provides r01 to update the cover page.
DongYeon (Samsung) comments.
Stephen (Qualcomm) provides comments and an r02
Guillaume (MediaTek Inc.) comments.
Stephen (Qualcomm) provides comments on the SA1 LS
DongYeon (Samsung) proposes to NOTE this CR.
Jean Yves (Thales) provides comments on the SA1 LS and supports r02
DongYeon (Samsung) provides r03.
==== Revisions Deadline ====
Stephen (Qualcomm) prefers r03 followed by r02
Jean Yves (Thales) ok with r02 and r03
DongYeon (Samsung) prefers r03.
Hannu (Nokia) can only agree r02. r03 breaks the TS 23.501 and 23.502 CRs that move UE location verification to clause 5.4.11.4 meaning that also the previous versions of this 23.501 CR in S2-2107835 and S2-2107231 agreed in SA2 #147E shall be rejected in order to reverse the whole removal of duplication of text between TS 23.501 and TS 23.502.
DongYeon (Samsung) prefers r03, but not object to r02.
Hannu (Nokia) requests that this CR is marked up for CC. SA2 needs to decide which versions (if any) of S2-2108329, S2-2107835 and S2-2107231 to send for plenary approval.
==== Comments Deadline ====
Hannu (Nokia) withdraws his request to bring this CR to CC if r02 can be agreed.

Status:

Revised to S2-2109338.

TD S2-2109338 (CR) 23.501 CR3030R4 (Rel-17, 'F'): UE location verification handling. (Source: Ericsson, Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: Enhance description in 23.501 to allow it to be used as common reference for UE location verification makes it mandatory for the AMF to include the appropriate cause value in the reject or deregistration request. The indication of the present UE location country is optional. r03 adds two things. The AMF requirement to include suitable cause value (already specified by CT WG1 as #78) and AMF option to indicate the country is an alignment with TS 24.501. The second change in r03 re-introduces the reference to UE procedures that failed to get carried over when this procedure was moved from multiple places in TS 23.502 to clause 5.4.11.4 which is referred from TS 23.502. See e.g. TS 23.502 clause 4.2.2.2.2 step 3 where the reference to UE procedures specified by CT WG1 used to be. This reference is extended by adding also TS 24.501 which specifies the UE procedures.

Comment:

Revision of S2-2108329r02. CC#2: Approved.

Discussion and conclusion:

CC#2: S2-2108329r02 was confirmed as agreed and S2-2109338 was approved.

Status:

Agreed.

TD S2-2108481 (CR) 23.501 CR3376 (Rel-17, 'F'): Clarification on IAB support for NR satellite access. (Source: Rakuten Mobile, Inc).
Document for: Approval.
Abstract: Summary of change: Clarify that IAB is not applied for NR satellite access in Release 17. PLMN will provide the mobility restriction for NR satellite access to the IAB-UE.

Comment:

Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108482 (CR) 23.401 CR3671 (Rel-17, 'F'): Clarification on IAB support for NR satellite access. (Source: Rakuten Mobile, Inc).
Document for: Approval.
Abstract: Summary of change: Clarify that IAB is not applied for NR satellite access in Release 17. PLMN will provide the mobility restriction for NR satellite access to the IAB-UE.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Stefan (Ericsson) provides comments and questions the need for the CR
Hannu (Nokia) shares the concern of Stefan that this CR is not appropriate under the present work item scope.
Aoken (Rakuten Mobile) provide the comment.
Stephen (Qualcomm) comments
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108513 (CR) 23.501 CR3318R1 (Rel-17, 'F'): Limited service PLMN selection for emergency. (Source: Nokia, Nokia Shanghai Bell, Xiaomi).
Document for: Approval.
Abstract: Summary of change: If a UE in limited service state is aware of its location, then it should attempt to select a PLMN that can operate in the same country as the present UE location. This cannot be a 'shall' level mandate, as the same LS from SA WG1 admits that there are cases when some other PLMN might need to be selected. While selection of emergency PLMN in the country of the present UE location is highly desirable, if that is not possible, the UE is allowed to select some other PLMN as secondary option. Further updates in revision 1 The network option to verify the UE's location in limited service emergency registration is added. UE behaviour upon receiving indication that the selected PLMN is not allowed to operate in the present UE location is added as an alignment with SA WG1 LS S1-211319 and the corresponding CT WG1 CR on TS 23.122 in C1-216273.

Comment:

Revision of (Agreed) S2-2107568 from S2#147E. r01 agreed. Revised to S2-2109102.

Discussion and conclusion:

-

e-mail discussion:

Stephen (Qualcomm) provides comments and an r01
==== Revisions Deadline ====
Jean Yves (Thales) agrees with r01
Yuxin (Xiaomi) agrees with r01
Hannu (Nokia) agrees r01
==== Comments Deadline ====.

Status:

Revised to S2-2109102.

TD S2-2109102 (CR) 23.501 CR3318R2 (Rel-17, 'F'): Limited service PLMN selection for emergency. (Source: Nokia, Nokia Shanghai Bell, Xiaomi).
Document for: Approval.
Abstract: Summary of change: If a UE in limited service state is aware of its location, then it should attempt to select a PLMN that can operate in the same country as the present UE location. This cannot be a 'shall' level mandate, as the same LS from SA WG1 admits that there are cases when some other PLMN might need to be selected. While selection of emergency PLMN in the country of the present UE location is highly desirable, if that is not possible, the UE is allowed to select some other PLMN as secondary option.

Comment:

Revision of S2-2108513r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2109000 (LS IN) LS from RAN WG2: Reply LS on UE location aspects in NTN . (Source: RAN WG2 (R2-2111547)).
Document for: Action.
Abstract: RAN WG2 would like to thank SA WG2 for the response. For now, RAN WG2 cannot provide their view on the different options for TAC reporting in the ULI identified by SA WG2. However, as part of the discussion on TAC handling, RAN WG2 assumes that a given satellite beam can cover simultaneously multiple tracking areas from same or different countries. Typically, a LEO satellite can generate a beam covering an area of ~100km diameter while a GEO satellite could cover similar or larger area. For example, a given beam can cover part of Germany, Austria, Switzerland, and Liechtenstein, and one or several TACs per country. The different PLMNs may share or not share TACs in the NR NTN cell. Currently RAN WG2 assumes maximum 12 TACs per NR NTN cell, including same or different PLMNs, can be broadcast. In order to size this signalling, RAN WG2 would like to ask for feedback on the expected size of the earth-fixed tracking area and the maximum number of TACs from the same or different PLMN that needs to be broadcast in a radio cell. Action: RAN WG2 kindly asks SA WG2 to take into account the above information and provide feedback on maximum number of TACs and expected size of the earth fixed tracking area.

Comment:

CC#2: Postponed.

Discussion and conclusion:

-

Status:

Postponed.

TD S2-2109001 (LS IN) LS from RAN WG2: Reply LS on extended NAS supervision timers at satellite access. (Source: RAN WG2 (R2-2111612)).
Document for: Information.
Abstract: RAN WG2 received an LS from CT WG1 asking about feasibility of the current NAS supervision timer {. . .}.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2109005 (LS IN) LS from RAN WG3: Reply LS on UE Location Aspects in NTN. (Source: RAN WG3 (R3-216067)).
Document for: Action.
Abstract: RAN WG3 thanks SA WG2 for the LS on UE location aspects in NTN. RAN WG3 has discussed the options for reporting of TAC in the ULI described by SA WG2, but no consensus has been reached at this time regarding a RAN WG3 preferred solution. RAN WG3 can provide the following observations. - Options A1, A2 and C require the gNB to determine the TAC based on UE location information which can be obtained by the gNB from the UE and may reuse current User Location information IE. - Option D requires the gNB to send all TACs via a new IE to the AMF, but it may not enable the AMF to discriminate the UE location precisely enough. - Option B would provide additional information to the gNB which might be beneficial to drive e.g. NNSF. Given that this option has UE impact, RAN WG3 cannot comment on its feasibility, which requires RAN WG2 discussion. - Combinations (e.g. Options C and D, or potentially also option B, if feasible) have also been discussed and may be acceptable to RAN WG3. RAN WG3 has also discussed the possibility to signal additional information to the AMF concerning uncertainty/reliability of the reported NR CGI for the UE. RAN WG3 cannot determine whether this information is required in the AMF and would like to ask SA WG2 to comment on this aspect. Action: RAN WG3 kindly asks SA WG2 to take the above into account and provide additional feedback and/or preference regarding the listed options, if any. RAN WG3 kindly asks SA WG2 to clarify whether uncertainty/reliability information for the reported NR CGI for the UE, is required in the AMF. RAN WG3 kindly asks RAN WG2 to take the above into account and provide feedback on the feasibility of Opt. B, if needed.

Comment:

CC#2: Postponed.

Discussion and conclusion:

-

Status:

Postponed.

TD S2-2109018 (LS IN) Reply LS on UE location aspects in NTN. (Source: SA WG3 (S3-214394)).
Document for: Action.
Abstract: SA WG3 would like to thank RAN WG2 for their reply LS S3-213822/R2-2109217 on UE location aspects in NTN. Based on RAN WG2's clarification to the questions raised by SA WG3, SA WG3 would like to follow up and provide the following complementary views: - The A-GNSS based measurements are provided by the UE after AS security establishment, hence are integrity protected against tampering during transmission. - As per R2-2109217, the A-GNSS based measurements are sent for core network reselection after initial core network selection, it means that the A-GNSS based measurements provided by the UE in NTN are used in LCS procedure initiated for core network reselection. Therefore, the reliability of the UE-provided A-GNSS based measurements used in NTN is at a comparable level of the reliability requirement for A-GNSS based LCS services. - Due to the concern of misbehaving UEs and GNSS spoofing, location information derived at the network side is considered as more reliable. Action: SA WG3 kindly asks RAN WG2, CT WG1, SA WG2, SA WG3-LI and RAN WG3 to take the above into account.

Comment:

CC#2: Postponed.

Discussion and conclusion:

-

Status:

Postponed.

# 8.12 Architecture enhancements for 3GPP support of advanced V2X services - Phase 2 (eV2XARC_Ph2)

This agenda item was convened by Andy Bennett (Samsung).

TD S2-2108300 (CR) 23.287 CR0165R2 (Rel-17, 'B'): NR Tx Profile. (Source: LG Electronics, Deutsche Telekom, ZTE, Tencent, vivo, Intel, CATT, Lenovo, Motorola Mobility, OPPO).
Document for: Approval.
Abstract: Summary of change: ¨3.1: - Add a definition for 'NR Tx Profile' ¨5.1.2.1: - Add the mapping of V2X service types to NR Tx Profiles for broadcast and groupcast. ¨5.9: - Describe that the V2X layer determines the NR Tx Profile for a particular V2X service type and provides it to the AS layer for broadcast and groupcast. ¨6.3.1 & ¨6.3.2: - Describe that the V2X layer determines the NR Tx Profile and provides it to the AS layer when providing the Destination Layer-2 ID and the PC5 QoS parameters in the transmitting UE for the transmission and in the receiving UEs for reception. Rev2 for SA WG2#148E - In ¨3.1 and ¨5.1.2.1, add TS 38.300 and TS 38.331 as references for NR Tx Profile based on the following RAN WG2 running CRs: - R2-2109003: Stage 2 Running CR of TS 38.300 for eSL (Endorsed TS 38.300 CR @RAN WG2#115e) - R2-2109606: RRC running CR for NR Sidelink enhancements (Submitted TS 38.331 CR @RAN WG2#116e) - In ¨5.9, clarify the description.

Comment:

Revision of (Agreed) S2-2107841 from S2#147E. r01 agreed. Revised to S2-2109103.

Discussion and conclusion:

-

e-mail discussion:

Zhang (Ericsson) provides r01
LaeYoung (LGE) is fine with r01.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109103.

TD S2-2109103 (CR) 23.287 CR0165R3 (Rel-17, 'B'): NR Tx Profile. (Source: LG Electronics, Deutsche Telekom, ZTE, Tencent, vivo, Intel, CATT, Lenovo, Motorola Mobility, OPPO, Ericsson).
Document for: Approval.
Abstract: Summary of change: ¨3.1: - Add a definition for 'NR Tx Profile' ¨5.1.2.1: - Add the mapping of V2X service types to NR Tx Profiles for broadcast and groupcast. ¨5.9: - Describe that the V2X layer determines the NR Tx Profile for a particular V2X service type and provides it to the AS layer for broadcast and groupcast. ¨6.3.1 & ¨6.3.2: - Describe that the V2X layer determines the NR Tx Profile and provides it to the AS layer when providing the Destination Layer-2 ID and the PC5 QoS parameters in the transmitting UE for the transmission and in the receiving UEs for reception. Rev2 for SA WG2#148E - In ¨3.1 and ¨5.1.2.1, add TS 38.300 and TS 38.331 as references for NR Tx Profile based on the following RAN WG2 running CRs: - R2-2109003: Stage 2 Running CR of TS 38.300 for eSL (Endorsed TS 38.300 CR @RAN WG2#115e) - R2-2109606: RRC running CR for NR Sidelink enhancements (Submitted TS 38.331 CR @RAN WG2#116e) - In ¨5.9, clarify the description Change during SA WG2#148E - In ¨5.2.1.1, clarify that Tx Profile is applied to NR PC5 as well.

Comment:

Revision of S2-2108300r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108301 (CR) 23.287 CR0169 (Rel-17, 'F'): Resolution of ENs related to PC5 DRX. (Source: LG Electronics, Deutsche Telekom, ZTE, Tencent).
Document for: Approval.
Abstract: Summary of change: ¨5.1.2.1: - Remote EN related to RAN specification for PC5 DRX configuration. - Add TS 38.331 as RAN specification about PC5 DRX configurations. - Clarify PC5 DRX configurations based on sl-DRX-PreConfig-GC-BC-r17 made up of SL-DRX-Config-GC-BC-r17 defined in TS 38.331 by considering that PC5 DRX configurations include various information including the mapping of PC5 QoS profile(s) to PC5 DRX cycle(s), default PC5 DRX configuration, etc. ¨5.9: - Remove EN related to RAN specification for PC5 DRX operation. - Add TS 38.300 as RAN specification about support for PC5 DRX operations in the AS layer.

Comment:

Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2109372 (LS IN) Reply LS on Tx Profile. (Source: RAN WG2 (R2-2111432)).
Document for: Action.
Abstract: RAN WG2 thanks SA WG2 for the LS in R2-2111232/S2-2107840. RAN WG2 discussed the information to be indicated in NR Tx Profile and made the following agreement: - a Tx profile identifies one or more sidelink feature groups. Action: RAN WG2 kindly asks SA WG2 to take the above agreement into account for further work.

Comment:

Postponed.

Discussion and conclusion:

-

Status:

Postponed.

# 8.13 5G System Enhancement for Advanced Interactive Services (5G_AIS)

This agenda item was convened by Puneet Jain (Intel).

# 8.14 Enhancement to the 5GC LoCation Services-Phase 2 (5G_eLCS_Ph2)

This agenda item was convened by Andy Bennett (Samsung).

TD S2-2108253 (LS IN) LS from RAN WG1: LS on Positioning Reference Units (PRUs) for enhancing positioning performance. (Source: RAN WG1 (R1-2106326)).
Document for: Information.
Abstract: RAN WG1 has started working on Rel-17 WI on NR Positioning Enhancements [1]. During working on the WI, RAN WG1 has made the following agreement in RAN WG1#105: Agreement: Send an LS to RAN WG2/RAN WG3 (cc SA WG2), including the following content: - RAN WG1 has evaluated the use of positioning reference units (PRUs) with known locations for positioning and observes improvements in using PRUs for enhancing the positioning performance. But, RAN WG1 has not identified specification enhancements needed in RAN WG1 specifications. RAN WG1 kindly requests RAN WG2/RAN WG3 (cc SA WG2) to determine if and what specification enhancements are adopted for PRUs for positioning. - Notes: o The term 'positioning reference unit (PRU)' is only used as a terminology in this discussion. PRU does not necessarily mean an introduction of a new network node. o PRU may support, at least, some of the Rel-16 positioning functionalities of UE, if agreed, which is up to RAN WG2. The positioning functionalities may include, but not limited to, the following: 1. Provide the positioning measurements (e.g., RSTD, RSRP, Rx-Tx time differences) 2. Transmit the UL SRS signals for positioning o PRU may be requested by the LMF to provide its own known location coordinate information to the LMF. If the antenna orientation information of the PRU is known, the information may also be requested by the LMF.

Comment:

Revision of S2-2106995 from S2#147E. Response drafted in S2-2108756. Final response in S2-2109105.

Discussion and conclusion:

-

e-mail discussion:

Runze (Huawei) proposes to NOTE the LS.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Replied to.

TD S2-2108756 (LS OUT) [DRAFT] Response LS on Positioning Reference Units (PRUs) for enhancing positioning performance. (Source: CATT).
Document for: Approval.
Abstract: Reply to S2-2108253.

Comment:

Response to S2-2108253. r02 agreed. Revised to S2-2109105.

Discussion and conclusion:

-

e-mail discussion:

Stephen (Qualcomm) provides comments and an r01
Sherry (Xiaomi) comments.
Yunjing (CATT) replies to Sherry.
Runze (Huawei) replies and suggest to merge into S2-2109017.
Yunjing (CATT) thinks the two draft LSs are replied to different LSs came from different RAN WGs and prefers to keep the two LSs separate.
Runze (Huawei) replies.
Cai Simon (Nokia) supports Yunjing (CATT) with two separate LS replies
Sherry (Xiaomi) agrees with Runze to have merged LS reply.
Yunjing (CATT) prefers separate LS replies to different LSs from different RAN WGs and provides r02.
==== Revisions Deadline ====
Runze (Huawei) is fine to send this LS and suggest to align the response in 2017.
Stephen (Qualcomm) can agree r02 or r01 but not r00
Sherry (Xiaomi) still thinks 9017 already included enough information for RAN1 and RAN2 to understand SA2 position on this issue, but if she is the only one having concern, she can live with r02.
Guillaume (MediaTek Inc.) supports r01/r02 only.
==== Comments Deadline ====.

Status:

Revised to S2-2109105.

TD S2-2109105 (LS OUT) Response LS on Positioning Reference Units (PRUs) for enhancing positioning performance. (Source: SA WG2).
Document for: Approval.
Abstract: To: RAN WG1, RAN WG2. CC: RAN WG3.

Comment:

Revision of S2-2108756r02. Approved.

Discussion and conclusion:

-

Status:

Approved.

TD S2-2108270 (LS IN) LS from RAN WG2: Reply LS on determination of location estimates in local co-ordinates. (Source: RAN WG2 (R2-2108957)).
Document for: Action.
Abstract: RAN WG2 discussed the question raised by SA WG2 if determination of local co-ordinates would be limited to certain positioning methods. RAN WG2 believes that local co-ordinates can be used for all RAT dependent positioning methods and some RAT independent positioning methods (e.g. WLAN) without a translation into or out of global coordinates. However, for some RAT independent positioning methods like A-GNSS, RAN WG2 understanding is that an LMF would need to perform a translation from global co-ordinates to local co-ordinates. Based on the latest 23.032 and 29.572 'Local Co-ordinates are relative to a known reference point defined by a unique Coordinate ID configured by the PLMN operator.' and 'The origin may have known WGS84 coordinates.', RAN WG2 understands that this would only be possible when the origin for the local coordinates has a known global location. When that is not available, local coordinates could not be supported. RAN WG2 believes that this restriction applies only to GNSS based and barometric sensor-based positioning methods. For other positioning methods, there would be no restrictions. However, RAN WG2 would like to understand whether SA WG2 expects there may be potential LPP impacts such as providing the local co-ordinates from the UE. In such case, RAN WG2 may need to discuss this further as there will be potential RAN WG2 impacts. Action: RAN WG2 kindly asks SA WG2 to take the above into account and would kindly request to provide the feedback.

Comment:

Revision of S2-2107040 from S2#147E. Responses drafted in S2-2108358 and S2-2108505. Postponed.

Discussion and conclusion:

-

Status:

Postponed.

TD S2-2108358 (LS OUT) [DRAFT] Response LS on determination of location estimates in local co-ordinates. (Source: Ericsson).
Document for: Approval.
Abstract: Answers questions on LPP impact.

Comment:

Response to S2-2108270. Noted.

Discussion and conclusion:

-

e-mail discussion:

Yunjing (CATT) provides r01 to merge S2-2108505 into this draft LS.
Runze (Huawei) objects r01 and provides r02.
Æke (Ericsson)finds r01 acceptable
Stephen (Qualcomm) provides an r03
==== Revisions Deadline ====
Runze (Huawei) objects R03 and propose to agree r02.
Stephen (Qualcomm) can agree r03 but not any other version
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108505 (LS OUT) [DRAFT] LS Response to Reply LS on determination of location estimates in local co-ordinates. (Source: Qualcomm Incorporated).
Document for: Approval.
Abstract: To: RAN WG2. CC: RAN WG1, RAN WG3.

Comment:

Response to S2-2108270. Noted.

Discussion and conclusion:

-

e-mail discussion:

Runze (Huawei) comments and suggests this paper merge into S2-2108358.
Yunjing (CATT) suggests this paper merge into S2-2108358.
==== Revisions Deadline ====
Stephen (Qualcomm) agrees to a merger into S2-2108358
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108491 (CR) 23.273 CR0205 (Rel-17, 'F'): Addition of Exception Procedures. (Source: Qualcomm Incorporated).
Document for: Approval.
Abstract: Summary of change: Addition of a new clause to support exception procedures similar to clause 9.4 in TS 23.271. The new clause defines exception procedures at an AMF and is based on the exception procedures at an MME defined in clause 9.4.3a in TS 23.271 with suitable changes for 5GC.

Comment:

Postponed.

Discussion and conclusion:

-

e-mail discussion:

Æke (Ericsson) Provides comments
Yunjing (CATT) Provides comments
Stephen (Qualcomm) replies to comments and provides an r01
Runze (Huawei) provides comments.
Cai Simon (Nokia) provides further comments
Yunjing (CATT) provides comments.
Stephen (Qualcomm) provides an r02 and replies to previous comments
Yunjing (CATT) replies.
==== Revisions Deadline ====
Yunjing (CATT) supports Cai Simon (Nokia), especially when SLT is introduced.
Stephen (Qualcomm) agrees to postpone the CR
==== Comments Deadline ====.

Status:

Postponed.

TD S2-2108493 (CR) 23.273 CR0151R5 (Rel-17, 'B'): Addition of a Scheduled Location Time. (Source: Qualcomm Incorporated).
Document for: Approval.
Abstract: Summary of change: A scheduled location time is defined. Support of a scheduled location time is added for a 5GC-MT-LR, 5GC-MO-LR and deferred 5GC-MT-LR for periodic or triggered location.

Comment:

Revision of (Postponed) S2-2107787 from S2#147E. r03 agreed. Revised to S2-2109106, merging S2-2108841.

Discussion and conclusion:

-

e-mail discussion:

Leo (Deutsche Telekom) provides r01.
Runze (Huawei) objects to r00 and r01, and provides r02.
Stephen (Qualcomm) provides an r03
Runze (Huawei) can live with r03
==== Revisions Deadline ====
Æke (Ericsson) accept r02 and r03
==== Comments Deadline ====.

Status:

Revised to S2-2109106, merging S2-2108841.

TD S2-2109106 (CR) 23.273 CR0151R6 (Rel-17, 'B'): Addition of a Scheduled Location Time. (Source: Qualcomm Incorporated).
Document for: Approval.
Abstract: Summary of change: A scheduled location time is defined. Support of a scheduled location time is added for a 5GC-MT-LR, 5GC-MO-LR and deferred 5GC-MT-LR for periodic or triggered location.

Comment:

Revision of S2-2108493r03, merging S2-2108841. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108841 (CR) 23.273 CR0199R1 (Rel-17, 'B'): Addition of a Scheduled Location Time. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: It is updated that LMF triggers the positioning procedure based on the time. It is also clarified that LMF does not provide schedule location time to RAN. It is proposed that AMF may provide the scheduled location time T to UE using the UE Configuration Update procedure, and UE based on the scheduled location time T enters CM-connected mode when the scheduled location time T is about to come.

Comment:

Revision of (Postponed) S2-2107681 from S2#147E. Merged into S2-2109106.

Discussion and conclusion:

-

e-mail discussion:

Stephen (Qualcomm) provides comments
Æke (Ericsson) Support comment from Qualcomm.
==== Revisions Deadline ====
Runze (Huawei) proposes to merge the CR into S2-2108493
==== Comments Deadline ====.

Status:

Merged into S2-2109106.

TD S2-2108750 (CR) 23.273 CR0206 (Rel-17, 'F'): Editorial changes for eLCS_Ph2. (Source: CATT).
Document for: Approval.
Abstract: Summary of change: Editorial changes.

Comment:

r03 agreed. Revised to S2-2109107.

Discussion and conclusion:

-

e-mail discussion:

Æke (Ericsson) provides r01 and a question
Yunjing(CATT) replies to Æke (Ericsson).
Leo (Deutsche Telekom) provides comments on r01.
Yunjing (CATT) replies to Leo (Deutsche Telekom) and provides r02.
Leo (Deutsche Telekom) is fine with r02, thanks.
Yunjing (CATT) provides r03.
Æke (Ericsson) is fine with r03
Leo (Deutsche Telekom) is fine with r03
==== Revisions Deadline ====
Runze (Huawei) supports r03
==== Comments Deadline ====.

Status:

Revised to S2-2109107.

TD S2-2109107 (CR) 23.273 CR0206R1 (Rel-17, 'F'): Editorial changes for eLCS_Ph2. (Source: CATT, Ericsson).
Document for: Approval.
Abstract: Summary of change: Editorial changes.

Comment:

Revision of S2-2108750r03. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108753 (CR) 23.273 CR0209 (Rel-17, 'F'): Location Services applicable to SNPN(s). (Source: CATT, Ericsson).
Document for: Approval.
Abstract: Summary of change: Clarify that the location services applicable to SNPN(s).

Comment:

r05 agreed. Revised to S2-2109108.

Discussion and conclusion:

-

e-mail discussion:

Josep (DT) requests clarification(s). Not clear whether SNPN support clarification is needed.
Yunjing (CATT) replies to Josep (DT).
Josep (DT) comments, provides r01.
Yunjing (CATT) provides r02.
Josep (DT) comments that there are no requirements for integrating further functionality in the CH. Objects to r02.
Yunjing (CATT) replies to Josep (DT) and provides r03.
Josep (DT) provides r04.
Antoine (Orange) provides r05.
Walter Dees (Philips) provides r06
Yunjing (CATT) replies to Walter Dees (Philips)
Æke (Ericsson) Comments reply from Yunjing (CATT)
Walter Dees (Philips) responds to Yunjing (CATT)
==== Revisions Deadline ====
Josep (DT) objects to all revisions except r05
Yunjing (CATT) agrees with Æke (Ericsson).
Yunjing (CATT) replies to Walter Dees (Philips).
Yunjing (CATT) can accept r05.
==== Comments Deadline ====.

Status:

Revised to S2-2109108.

TD S2-2109108 (CR) 23.273 CR0209R1 (Rel-17, 'F'): Location Services applicable to SNPN(s). (Source: CATT, Ericsson).
Document for: Approval.
Abstract: Summary of change: Clarify when the location services are applicable to SNPN.

Comment:

Revision of S2-2108753r05. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108842 (CR) 23.273 CR0218 (Rel-17, 'F'): Update AMF functionality for satellite access UE. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Propose to add an additional AMF functionality that Request the LMF to include the country information within the UE location determination, for satellite access UE.

Comment:

r01 agreed. Revised to S2-2109109.

Discussion and conclusion:

-

e-mail discussion:

Sherry (Xiaomi) provides r01.
Runze (Huawei) comments on r01, and prefers original CR.
Sherry (Xiaomi) prefers r01.
Runze (Huawei) can live with r01.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109109.

TD S2-2109109 (CR) 23.273 CR0218R1 (Rel-17, 'F'): Update AMF functionality for satellite access UE. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Propose to add an additional AMF functionality that Request the LMF to include the country information within the UE location determination, for satellite access UE.

Comment:

Revision of S2-2108842r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108999 (LS IN) LS from RAN WG2: Response LS on Positioning Reference Units (PRUs) for enhancing positioning performance. (Source: RAN WG2 (R2-2111488)).
Document for: Action.
Abstract: RAN WG2 thanks RAN WG1 for their LS on Positioning Reference Units (PRUs) for enhancing positioning performance. RAN WG2 discussed support of PRUs as described in the RAN WG1 LS R2-2106920 (R1-2106326, S2-2105263). Based on the information provided by RAN WG1, RAN WG2's current understanding is that a PRU is a device with a priori known location (to some degree of accuracy at least) and which perfoms location measurements at this known location. In addition, the PRU can transmit SRS to enable TRPs to measure and report UL positioning measurements from PRUs at known location. The PRU or TRP measurements can then be compared by a location server with the measurements expected to determine 'correction information' for other nearby target devices. The location measurements for other target devices may then be corrected based on the previously determined 'correction information'. Further, RAN WG2 discussed the modelling of PRUs and agreed that the PRU can be considered (at least) as a UE (from LMF perspective). However, since the PRU location measurements are needed by an LMF itself different views exist in RAN WG2 on how this can be enabled in the current LCS architecture. Some companies in RAN WG2 believe that PRU support has no impact on SA WG2 and CT specifications and think that the MT-LR procedures as currently specified in TS 23.273 can also be instigated by an LMF (e.g., an LMF may initiate a location request to a GMLC) or existing MO LR procedures as specified in TS 23.273 can be instigated by a PRU for enabling an LMF to obtain PRU location measurements or transmit UL-SRS. Other companies in RAN WG2 believe that an LMF needs to be enabled to instigate location procedures for a PRU (e.g., LPP, NRPPa procedures) without receiving a location request for the PRU from an AMF (i.e., in the absence of an MT-LR or MO-LR for the PRU). These companies also believe that this effectively means that the LMF should act as an 'LCS Client' for PRUs. However, since the LCS procedures and overall architecture are in the realm of SA WG2, RAN WG2 would like to confirm with SA WG2 whether PRU support as described by RAN WG1 can be provided with the current LCS framework as specified by SA WG2 (e.g., TS 23.273) or whether any changes would be required. In addition, RAN WG2 discussed whether the LMF determined 'correction information' obtained from PRU measurements needs to be provided to target UEs for UE-based mode of operation. As mentioned by RAN WG1 in the LS, a PRU may provide 'antenna orientation information' to an LMF and RAN WG2 would like to ask RAN WG1 to provide further details of the 'PRU antenna orientation information'. Action: RAN WG2 kindly asks SA WG2 whether the MT-LR or MO-LR location procedures as currently specified in TS 23.273 can be used to enable an LMF obtaining location measurements from PRUs (via LPP) and to trigger SRS transmission of PRUs (via NRPPa), or whether an LMF needs to be enabled to instigate location procedures for a PRU (e.g., LPP, NRPPa procedures) without receiving a location request for the PRU from an AMF (i.e., in the absence of an MT-LR or MO-LR for the PRU), and if so, whether support can be provided as part of Release 17.

Comment:

Response drafted in S2-2109017. Final response in S2-2109104.

Discussion and conclusion:

-

Status:

Replied to.

TD S2-2109017 (LS OUT) [DRAFT] Reply LS on Response LS on Positioning Reference Units (PRUs) for enhancing positioning performance. (Source: Huawei).
Document for: Approval.
Abstract: To: RAN WG2. CC: RAN WG1, RAN WG3.

Comment:

Created at CC#1. Response to S2-2108999. r03 agreed. Revised to S2-2109104.

Discussion and conclusion:

-

e-mail discussion:

Stephen (Qualcomm) provides comments and an r01
Runze (Huawei) provides r02.
Leo (Deutsche Telekom) provides r03.
Runze (Huawei) agrees r03.
Stephen (Qualcomm) can also agree the r03
==== Revisions Deadline ====
Stephen (Qualcomm) notes that r00 is not acceptable (in case there is an objection to other rev.s)
==== Comments Deadline ====.

Status:

Revised to S2-2109104.

TD S2-2109104 (LS OUT) Reply LS on Response LS on Positioning Reference Units (PRUs) for enhancing positioning performance. (Source: SA WG2).
Document for: Approval.
Abstract: To: RAN WG2. CC: RAN WG1, RAN WG3.

Comment:

Revision of S2-2109017r03. Approved.

Discussion and conclusion:

-

Status:

Approved.

TD S2-2109003 (LS IN) LS from RAN WG3: Reply LS to RAN2 on the misalignment in SRS configuration. (Source: RAN WG3 (R3-216009)).
Document for: Information.
Abstract: RAN WG3 would like to thank RAN WG2 for the LS on on the misalignment in SRS configuration. RAN WG3 has agreed CRs attached to align with RAN WG2 specification.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Yunjing (CATT) proposes to note the LS.
==== Revisions Deadline ====
Runze (Huawei) proposes to note the LS.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2109011 (LS IN) LS from RAN WG3: Reply LS on location estimates in local co-ordinates. (Source: RAN WG3 (R3-216235)).
Document for: Action.
Abstract: RAN WG3 would like to thank RAN WG1 for the reply LS on determination of location estimates in local co-ordinates. RAN WG3 also would like to provide the additional information and clarify previous LS R3-214312 that, the local coordinates are only applicable for gNB in current RAN WG3 specifications via NRPPa signaling and the local coordinates for LTE RAT-dependent positioning can be retrieved by OAM. Action: RAN WG3 respectfully asks RAN WG1 and SA WG2 to take the above information into account.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Yunjing (CATT) proposes to note the LS.
==== Revisions Deadline ====
Runze (Huawei) proposes to note the LS.
==== Comments Deadline ====.

Status:

Noted.

# 8.15 Multimedia Priority Service (MPS) Phase 2 (MPS2)

This agenda item was convened by Puneet Jain (Intel).

# 8.16 Dynamic management of group-based event monitoring (TEI17_GEM)

This agenda item was convened by Andy Bennett (Samsung).

# 8.17 N7/N40 Interfaces Enhancements to Support GERAN and UTRAN (TEI17_NIESGU)

This agenda item was convened by Puneet Jain (Intel).

TD S2-2108930 (CR) 23.501 CR3455 (Rel-17, 'F'): Support of GERAN/UTRAN access: Annex L alignment to CR 2970r1 to TS 23.501. (Source: Vodafone).
Document for: Approval.
Abstract: Summary of change: Notes in Annex L are updated to align with CR 2970r1.

Comment:

r01 agreed. Revised to S2-2109312.

Discussion and conclusion:

-

e-mail discussion:

Haris(Qualcomm) asks question for clarification
Chris (Vodafone) provides r1.
Haris(Qualcomm) comments that r01 is ok
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109312.

TD S2-2109312 (CR) 23.501 CR3455R1 (Rel-17, 'F'): Support of GERAN/UTRAN access: Annex L alignment to CR 2970r1 to TS 23.501. (Source: Vodafone).
Document for: Approval.
Abstract: Summary of change: Notes in Annex L are updated to align with CR 2970r1.

Comment:

Revision of S2-2108930r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108932 (CR) 23.502 CR3312 (Rel-17, 'F'): Support of GERAN/UTRAN access: Annex G alignment to CR 2970r1 to TS 23.501. (Source: Vodafone).
Document for: Approval.
Abstract: Summary of change: Notes in Annex G are updated to align with CR 2970r1.

Comment:

r01 agreed. Revised to S2-2109313.

Discussion and conclusion:

-

e-mail discussion:

Haris(Qualcomm) asks question for clarification
Chris (Vodafone) provides r01
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109313.

TD S2-2109313 (CR) 23.502 CR3312R1 (Rel-17, 'F'): Support of GERAN/UTRAN access: Annex G alignment to CR 2970r1 to TS 23.501. (Source: Vodafone).
Document for: Approval.
Abstract: Summary of change: Notes in Annex G are updated to align with CR 2970r1.

Comment:

Revision of S2-2108932r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

# 8.18 System enhancement for Redundant PDU Session (TEI17_SE_RPS)

This agenda item was convened by Puneet Jain (Intel).

# 8.19 IMS Optimization for HSS Group ID in an SBA environment (TEI17_IMSGID)

This agenda item was convened by Puneet Jain (Intel).

# 8.20 Support for Signed Attestation for Priority and Emergency Sessions (TEI17_SAPES)

This agenda item was convened by Tao Sun (China Mobile).

# 8.21 Dynamically Changing AM Policies in the 5GC (TEI17_DCAMP)

This agenda item was convened by Tao Sun (China Mobile).

TD S2-2108266 (LS IN) LS from CT WG3: LS on DCAMP related issues. (Source: CT WG3 (C3-214425)).
Document for: Action.
Abstract: CT WG3 is studying the Dynamic Change of AM policies in the 5GC functionality and would like to ask SA WG2 following questions. {. . .} Action: CT WG3 kindly asks SA WG2 to answer the questions above and amend the SA WG2 specifications accordingly, where appropriate.

Comment:

Revision of S2-2107029 from S2#147E. Responses drafted in S2-2108343 and S2-2108585. Final response in S2-2109193.

Discussion and conclusion:

-

e-mail discussion:

Belen (Ericsson) proposes to merge LS into S2-2108343
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Replied to.

TD S2-2108343 (LS OUT) [DRAFT] LS reply on DCAMP related issues. (Source: Ericsson).
Document for: Approval.
Abstract: Response to CT WG3 incoming LS on DCAMP related issues.

Comment:

Response to S2-2108266. r01 agreed. Revised to S2-2109193, merging S2-2108585.

Discussion and conclusion:

-

e-mail discussion:

Pallab (Nokia) proposes to have the LSout discussion in this thread.
Belen (Ericsson) is okay to use this thread and ask Huawei and Nokia.
Belen (Ericsson) provides r01.
Susan (Huawei) is ok with r01.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109193, merging S2-2108585.

TD S2-2109193 (LS OUT) LS reply on DCAMP related issues. (Source: SA WG2).
Document for: Approval.
Abstract: To: CT WG3. Attachments: TS 23.502 CR 3125, CR 3189, TS 23.503 CR 0651, CR 0650.

Comment:

Revision of S2-2108343r01, merging S2-2108585. Approved.

Discussion and conclusion:

CC#2: Ericsson reported that 23.503 CR #0662 should not be attached, as it was not agreed. It was agreed to remove the reference to it from the LS. S2-2109193 remained approved.

Status:

Approved.

TD S2-2108585 (LS OUT) [DRAFT] Reply LS on DCAMP related issues. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Reply LS on DCAMP related issues to CT WG3.

Comment:

Revision of (Postponed) S2-2107480 from S2#147E. Response to S2-2108266. Merged into S2-2109193.

Discussion and conclusion:

-

e-mail discussion:

Pallab (Nokia) suggests to move the LSOut discussion to a single email thread in S2-2108343.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Merged into S2-2109193.

TD S2-2108338 (CR) 23.501 CR3362 (Rel-17, 'F'): Align BSF NF profile in NRF (23.501) with BSF related information in NRF services (23.502). (Source: Oracle).
Document for: Approval.
Abstract: Summary of change: BSF Group ID is included within BSF NF profile.

Comment:

Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108586 (CR) 23.502 CR3189R1 (Rel-17, 'F'): Correction to AF-triggered dynamically changing AM policies. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Propose to report the registration of the first SM policy association establishment and deregistration of the last SM policy association if service area coverage and/or the indication of high throughput provided by the AF are associated with the (DNN, S-NSSAI).

Comment:

Revision of (Postponed) S2-2107481 from S2#147E. r04 agreed. Revised to S2-2109194.

Discussion and conclusion:

-

e-mail discussion:

Pallab (Nokia) comments and thinks that the proposed changes are not needed.
Susan (Huawei) replies to Pallab (Nokia).
Pallab (Nokia) responds to Susan (Huawei).
Belen (Ericsson) is okay with the CR.
Pallab (Nokia) responds to Belen (Ericsson)
Belen (Ericsson) asks for clarification.
Belen (Ericsson) replies.
Pallab (Nokia) comments.
Belen (Ericsson) replies to Nokia
Pallab (Nokia) responds to Belen (Ericsson).
Belen (Ericsson) replies to Nokia.
Pallab (Nokia) replies to Susan (Huawei).
Belen (Ericsson) is okay with r03.
Susan (Huawei) provides r04 with the only change on the cover sheet to add Oracle as supporting company.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109194.

TD S2-2109194 (CR) 23.502 CR3189R2 (Rel-17, 'F'): Correction to AF-triggered dynamically changing AM policies. (Source: Huawei, HiSilicon, Oracle).
Document for: Approval.
Abstract: Summary of change: Propose to report the registration of the first SM policy association establishment and deregistration of the last SM policy association if service area coverage and/or the indication of high throughput provided by the AF are associated with the (DNN, S-NSSAI).

Comment:

Revision of S2-2108586r04. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108587 (CR) 23.503 CR0662R2 (Rel-17, 'F'): Correction to AF-triggered dynamically changing AM policies. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Propose to report the registration when the first SM policy association establishment and deregistration when the last SM policy association If service area coverage and/or the indication of high throughput provided by the AF are associated with the (DNN, S-NSSAI).

Comment:

Revision of (Revised and Agreed) S2-2107482 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

Pallab (Nokia) has same comments as in 8586 and thinks that the proposed changes are not needed.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

# 8.22 IP address pool information from UDM (TEI17_IPU)

This agenda item was convened by Puneet Jain (Intel).

# 8.23 Same PCF selection for AMF and SMF (TEI17-SPSFAS)

This agenda item was convened by Puneet Jain (Intel).

# 8.24 Support of different slices over different Non-3GPP access (TEI17_N3SLICE)

This agenda item was convened by Puneet Jain (Intel).

TD S2-2108731 (CR) 23.501 CR3422 (Rel-17, 'F'): Clarification on support of slicing in TWIF scenario. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Add a NOTE to state that the different TAI configuration is not applicable to TWIF.

Comment:

r02 agreed. Revised to S2-2109314.

Discussion and conclusion:

-

e-mail discussion:

Stefan (Ericsson) provides r01
Marco (Huawei) ok with r01
Myungjune (LGE) comments
Myungjune (LGE) provides r02
Marco (Huawei) answers to Myungjune (LGE) and disagrees with r02
Myungjune (LGE) replies to Marco (Huawei)
Marco (Huawei) replies to Myungjune (LGE)
Stefan (Ericsson) comments
==== Revisions Deadline ====
Myungjune (LGE) prefer r02
Marco (Huawei) comment and R02 is ok
==== Comments Deadline ====.

Status:

Revised to S2-2109314.

TD S2-2109314 (CR) 23.501 CR3422R1 (Rel-17, 'F'): Clarification on support of slicing in TWIF scenario. (Source: Huawei, HiSilicon, Ericsson).
Document for: Approval.
Abstract: Summary of change: Clarify that NWIF can be configured with a different TAI value.

Comment:

Revision of S2-2108731r02. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108854 (CR) 23.501 CR3440 (Rel-17, 'F'): Removal of a now obsolete sentence about non-3GPP Access being forbidden in a PLMN. (Source: Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: Remove the obsolete sentence.

Comment:

r01 agreed. Revised to S2-2109315.

Discussion and conclusion:

-

e-mail discussion:

Stefan (Ericsson) provides r01
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109315.

TD S2-2109315 (CR) 23.501 CR3440R1 (Rel-17, 'F'): Removal of a now obsolete sentence about non-3GPP Access being forbidden in a PLMN. (Source: Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: Remove the obsolete sentence.

Comment:

Revision of S2-2108854r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

# 8.25 Minimization of Service Interruption (MINT)

This agenda item was convened by Puneet Jain (Intel).

TD S2-2108283 (LS IN) LS from CT WG1: LS on system information extensions for minimization of service interruption (MINT). (Source: CT WG1 (C1-216297)).
Document for: Information.
Abstract: CT WG1 agreed the following conclusion in TR 24.811 as part of FS_MINT-CT SI: ------------------ A solution: - which informs the UE about Disaster Condition over 3GPP access; and - with minimal information broadcast over 3GPP access of a PLMN offering disaster roaming to UEs of a PLMN with Disaster Condition, sufficient to enable the UEs to determine that a Disaster Condition applies to the PLMN with Disaster Condition; shall be progressed in normative phase. ------------------ and ------------------ .. - PLMN offering disaster roaming shall indicate accessibility for disaster roamers through SIB messages. The indication may contain the list of PLMN(s) with Disaster condition for which disaster roaming is offered. .. - UE of PLMN D with Disaster Condition shall determine that PLMN A offers disaster roaming when PLMN A's NG-RAN cell broadcasts PLMN ID of PLMN D in the list of PLMN(s) with Disaster Condition for which disaster roaming is offered by PLMN A. ------------------ Thus, for available PLMN(s), NAS will need to obtain from RRC: a) disaster related indication, for which CT WG1 still discusses whether it indicates (a) solely that the available PLMN is accessible for disaster inbound roamers or (b) that the available PLMN is accessible for disaster inbound roamers and all other PLMNs have disaster condition; or b) 'list of one or more PLMN(s) with disaster condition for which disaster roaming is offered by the available PLMN' where each PLMN with disaster condition is identified by its PLMN ID. The list will need to be able to hold at least the same amount of PLMN IDs as number of PLMNs which can share an NR cell. (a) or (b) is used depending on the decision of the available PLMN.

Comment:

Response drafted in S2-2108637. Noted.

Discussion and conclusion:

-

e-mail discussion:

Hyunsook (LGE) proposes to note this LS for information.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108637 (LS OUT) [DRAFT] LS OUT on system information extensions for minimization of service interruption (MINT). (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: This LS is to reply to the LS on system information extensions for minimization of service interruption (MINT).

Comment:

Response to S2-2108283. Noted.

Discussion and conclusion:

-

e-mail discussion:

Hyunsook (LGE) proposes to note it.
Qian (Ericsson) supports to note this.
Haiyang (Huawei) responds.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108371 (CR) 23.501 CR3264R2 (Rel-17, 'F'): MINT Updates. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: Synchronising the list name 'list of one or more PLMN(s) with Disaster Condition for which Disaster Roaming service is offered by the available PLMN' with CT WG1 in 5.40.3. Adding EN for SMF and charging related indication Synchronizing the congenstion handling with CT WG1 CRs Following is included in r02 Adding disaster return wait range infromation. Specify SoR, Registration request procedure and UCU procedure are used for disaster roaming service related information delivery.

Comment:

Revision of (Agreed) S2-2107848 from S2#147E. r01 agreed. Revised to S2-2109316.

Discussion and conclusion:

CC#2: Ericsson commented that r01 was agreed rather than r02 (Revised to S2-2109316). The status lists should be updated accordingly.

e-mail discussion:

Hyunsook (LGE) has a comment and proposes to note it in this meeting.
Haiyang (Huawei) agrees with Hyunsook (LGE) to note this paper in this meeting.
Qian (Ericsson) comments.
Haris(Qualcomm) provides r01
Hyunsook (LGE) provides r02.
==== Revisions Deadline ====
Hyunsook (LGE) can accept r01 (with CT1 CR dependency) and r02.
Qian (Ericsson) propose to go with r01.
Lalith(Samsung) OK with r01 or r02.
Haris(Qualcomm) propose to go with r01
Haiyang (Huawei) is OK with r02 or postpone, but not ok with r00/r01.
Qian (Ericsson) provides r03 in DRAFT folder on top of r01 with these changes: 1) 'after' -> 'during and after'. 2) delete 'in the roamed country' 3) Delete 'SOR' in cover sheet. 4) adding 'This CR is to synch with the agreement in C1-216752'. Qian also asks this to be handled in CC#2 with the above changes.
==== Comments Deadline ====
Haiyang (Huawei) is OK with [r01+the updated part provided by Qian(Ericsson)].

Status:

Revised to S2-2109316.

TD S2-2109316 (CR) 23.501 CR3264R3 (Rel-17, 'F'): MINT Updates. (Source: Ericsson, LG Electronics).
Document for: Approval.
Abstract: Summary of change: Synchronising the list name 'list of one or more PLMN(s) with Disaster Condition for which Disaster Roaming service is offered by the available PLMN' with CT WG1 in 5.40.3. Adding EN for SMF and charging related indication Synchronizing the congenstion handling with CT WG1 CRs Following is included in r02 Adding disaster return wait range infromation. Specify Registration request procedure and UCU procedure are used for disaster roaming service related information delivery.

Comment:

Revision of S2-2108371r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108372 (CR) 23.502 CR3146R1 (Rel-17, 'C'): Registration procedure improvement for MINT. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: Adding the delivery of 'list of PLMN(s) to be used in Disaster Condition in the roamed to country' and disaster roaming wait range information in Registration procedure.

Comment:

Revision of (Postponed) S2-2107253 from S2#147E. r01 agreed. Revised to S2-2109317.

Discussion and conclusion:

-

e-mail discussion:

Hyunsook (LGE) proposes to note it in this meeting.
Haiyang (Huawei) agrees with Hyunsook (LGE) to note this paper.
Qian (Ericsson) comments.
Qian (Ericsson) provides r01.
==== Revisions Deadline ====
Hyunsook (LGE) can accept r01 only in case if S2-2108371r01 is agreed, otherwise, propose to postpone it.
Qian (Ericsson) propose to go with r01.
Haiyang (Huawei) is OK with r01.
==== Comments Deadline ====.

Status:

Revised to S2-2109317.

TD S2-2109317 (CR) 23.502 CR3146R2 (Rel-17, 'C'): Registration procedure improvement for MINT. (Source: Ericsson, LG Electronics).
Document for: Approval.
Abstract: Summary of change: Adding the delivery of 'list of PLMN(s) to be used in Disaster Condition' and disaster roaming wait range information in Registration procedure.

Comment:

Revision of S2-2108372r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108373 (CR) 23.502 CR3228 (Rel-17, 'C'): UE configuration procedure update and SoR update for MINT. (Source: Ericsson).
Document for: Approval.
Abstract: Summary of change: Adding the delivery of 'list of PLMN(s) to be used in Disaster Condition' and disaster roaming wait range information in UE configuration update procedure. Synch the SOR infromation delivery.

Comment:

r03 agreed. Revised to S2-2109318.

Discussion and conclusion:

-

e-mail discussion:

Hyunsook (LGE) proposes to note it in this meeting.
Haiyang (Huawei) agrees with Hyunsook (LGE) to note this paper.
Qian (Ericsson) comments.
Lalith(Samsung) comments.
Qian (Ericsson) provides r01.
Lalith(Samsung) provides r02
Hyunsook (LGE) doesn't want to make a progress on this CR.
Haris(Qualcomm) comments on r01 and r02 and provides r03
==== Revisions Deadline ====
Hyunsook (LGE) can accept r03 only in case if S2-2108371r01 is agreed, otherwise, propose to postpone it.
Qian (Ericsson) propose to go with r03.
Lalith (Samsung) also propose to agree r03.
Haris(Qualcomm) propose to agree r03
Haiyang (Huawei) is OK with r03 but request the author to delete the SoR related description in the cover page if it is finally agreed.
==== Comments Deadline ====.

Status:

Revised to S2-2109318.

TD S2-2109318 (CR) 23.502 CR3228R1 (Rel-17, 'C'): UE configuration procedure update for MINT. (Source: Ericsson, LG Electronics).
Document for: Approval.
Abstract: Summary of change: Adding the delivery of 'list of PLMN(s) to be used in Disaster Condition' and disaster roaming wait range information in UE configuration update procedure.

Comment:

Revision of S2-2108373r03. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108440 (CR) 23.502 CR3133R1 (Rel-17, 'B'): Authentication and Subscription information checking for Disaster Roaming service. (Source: LG Electronics, KT Corp., LG Uplus, SK Telecom, Ericsson, vivo).
Document for: Approval.
Abstract: Summary of change: It is proposed to specify both options for operator's flexible deployment and preference The new editor's note on SA WG3 feedback is also added, as same to one of TS 23.501.

Comment:

Revision of (Postponed) S2-2107160 from S2#147E. Postponed.

Discussion and conclusion:

-

e-mail discussion:

Haiyang (Huawei) suggests to postpone this paper.
Alessio(Nokia) is also OK to postpone this paper.
==== Revisions Deadline ====
Hyunsook (LGE) is O.K. to postpone it in this meeting.
==== Comments Deadline ====.

Status:

Postponed.

TD S2-2108441 (CR) 23.502 CR3236 (Rel-17, 'F'): Session management related subscription information during Disaster Roaming. (Source: LG Electronics).
Document for: Approval.
Abstract: Summary of change: It is proposed to describe the configuration option basically to get the session management related subscription information during Disaster Roaming. In addition, while waiting for the feedback from SA WG3 and SA WG5, the same editor's note is needed to be kept.

Comment:

Postponed.

Discussion and conclusion:

-

e-mail discussion:

Haiyang (Huawei) suggests to postpone/note this paper.
==== Revisions Deadline ====
Hyunsook (LGE) is O.K. to postpone it in this meeting.
==== Comments Deadline ====.

Status:

Postponed.

TD S2-2108555 (CR) 23.501 CR3388 (Rel-17, 'F'): Clarification on the pre-conditions for DC roaming. (Source: Vivo).
Document for: Approval.
Abstract: Summary of change: Clarify that: the UE cannot get service via 5G ProSe UE-to-Network relay as specified in TS 23.304 [128], then the UE can perform the DC roaming. the 'list of PLMN(s) to be used in Disaster Condition' may be configured over non-3GPP access after disaster condition has occurred.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Hyunsook (LGE) proposes to note it
Wen (vivo) replies to Hyunsook (LGE)
Qian (Ericsson) comments
Wen (vivo) replies and provides r01
Hyunsook (LGE) provides r02.
Wen (vivo) replies.
Lalith(Samsung) objects r00, r02
Haris(Qualcomm) proposes to note the CR (r00 or r01)
alessio(nokia) also agrees it is wise to note the CR.
==== Revisions Deadline ====
Hyunsook (LGE) can accept only r02, and also o.k. to note this CR.
Qian (Ericsson) is ok with r02 or NOTE.
Wen (vivo) is ok with r02 as well.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108556 (CR) 23.501 CR3389 (Rel-17, 'F'): Handling of DC is no longer applicable. (Source: Vivo).
Document for: Approval.
Abstract: Summary of change: Clarify that when the DC is no longer applicable: the PLMN providing Disaster Roaming service shall reactive the principles of the PLMN as not allowed and stop broadcasting of providing Disaster Roaming service.

Comment:

r02 agreed. Revised to S2-2109319.

Discussion and conclusion:

-

e-mail discussion:

Lalith(Samsung) comments.
Wen(vivo) replies to Lalith(Samsung).
Lalith(Samsung) replies to Wen(Vivo)
Wen(vivo) replies and provides r01
Hyunsook (LGE) provides a comment on r01
Wen (vivo) replies and provides r02
==== Revisions Deadline ====
Hyunsook (LGE) can accept only r02.
Qian (Ericsson) is ok with r02.
==== Comments Deadline ====.

Status:

Revised to S2-2109319.

TD S2-2109319 (CR) 23.501 CR3389R1 (Rel-17, 'F'): Handling of DC is no longer applicable. (Source: Vivo).
Document for: Approval.
Abstract: Summary of change: Clarify that when the DC is no longer applicable: the PLMN providing Disaster Roaming service shall stop broadcasting of providing Disaster Roaming service.

Comment:

Revision of S2-2108556r02. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108557 (CR) 23.501 CR3390 (Rel-17, 'F'): Handling of preventing signalling overload. (Source: Vivo).
Document for: Approval.
Abstract: Summary of change: If the PLMN providing Disaster Roaming is under the congestion control, it should not broadcast of supporting Disaster Roaming service The UEs consider the PLMN providing Disaster Roaming is not under the overload and congestion when the PLMN providing Disaster Roaming is broadcasting of supporting Disaster Roaming service and stop the Mobility Management back-off time provided by the PLMN providing Disaster Roaming if it is running.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Hyunsook (LGE) proposes to note it
Wen (vivo) replies to Hyunsook (LGE)
Qian (Ericsson) comments
Wen (vivo) replies to Qian (Ericsson)
Hyunsook (LGE) still has a concern.
Wen (vivo) replies to Hyunsook (LGE) and provides r01.
Haris(Qualcomm) objects to the CR
alessio(Nokia) also objects to the CR
Wen (vivo) replies and provides r02
Hyunsook (LGE) provides a comment on r02
Hyunsook (LGE) replies.
==== Revisions Deadline ====
Hyunsook (LGE) objects r00 and all revisions.
Wen (vivo) is ok to be NOTED but still keep this concern which the PLMN providing DC service still broadcasts of providing DC service even if it is under congestion control, then make the DC UEs have high priority to access to this PLMN then be rejected by the network .
Qian (Ericsson) supports to NOTE the paper.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108638 (CR) 23.501 CR3407 (Rel-17, 'F'): Alignment on system information extensions for minimization of service interruption. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Remove the EN and 'a list of PLMN(s) with Disaster Condition for which Disaster Roaming service' in the broadcasting information.

Comment:

r01 agreed. Revised to S2-2109320.

Discussion and conclusion:

-

e-mail discussion:

Hyunsook (LGE) cheeked it has a conflict with S2-2107848 which was approved at SA2#147E.
Haiyang (Huawei) provides r01.
Qian (Ericsson) provides comments.
Hyunsook (LGE) provides a comment.
Haiyang (Huawei) provides some information to Qian (Ericsson).
Lalith(Samsung) comments.
Haiyang (Huawei) replies to Lalith(Samsung) that r01 does not change the parameter themselves.
Lalith(Samsung) objects r00 and is OK with r01
==== Revisions Deadline ====
Hyunsook (LGE) can accept r01, if agreed.
Qian (Ericsson) is ok with r01.
==== Comments Deadline ====.

Status:

Revised to S2-2109320.

TD S2-2109320 (CR) 23.501 CR3407R1 (Rel-17, 'F'): Alignment on system information extensions for minimization of service interruption. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Remove the EN and 'a list of PLMN(s) with Disaster Condition for which Disaster Roaming service' in the broadcasting information.

Comment:

Revision of S2-2108638r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108639 (CR) 23.501 CR3408 (Rel-17, 'F'): Emergency Services for Disaster Inbound Roamers. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Emergency Services for Disaster Inbound Roamers.

Comment:

r03 agreed. Revised to S2-2109321.

Discussion and conclusion:

-

e-mail discussion:

Hyunsook (LGE) provides r01.
Haiyang (Huawei) replies.
Qian (Ericsson) comments.
Haiyang (Huawei) replies and prefers r00.
Hyunsook (LGE) provides a comment.
Lalith (Samsung) comments.
Haris(Qualcomm) proposes to note the CR (all revisions)
Haiyang (Huawei) disagrees with Haris(Qualcomm) 's view
Haris(Qualcomm) comments
Lalith(Samsung) supports NOTE from Haris(Qualcomm)
Hyunsook (LGE) can agree to add new NOTE suggested by Haris.
Haiyang (Huawei) can live with the new note.
Qian (Ericsson) is also ok with the proposal adding a note.
Haiyang (Huawei) provides r02.
Hyunsook (LGE) provides r03 with cover page update and applying NOTE style.
==== Revisions Deadline ====
Hyunsook (LGE) can accept r03.
Qian (Ericsson) is ok with r03.
Haiyang (Huawei) is ok with r03.
==== Comments Deadline ====.

Status:

Revised to S2-2109321.

TD S2-2109321 (CR) 23.501 CR3408R1 (Rel-17, 'F'): Emergency Services for Disaster Inbound Roamers. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Emergency Services for Disaster Inbound Roamers.

Comment:

Revision of S2-2108639r03. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108640 (CR) 23.501 CR3409 (Rel-17, 'F'): Implicit Deregistration in the PLMN with Disaster Condition. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Implicit Deregistration in the PLMN with Disaster Condition.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Hyunsook (LGE) proposes to note it.
Haiyang (Huawei) clarifies.
Qian (Ericsson) comments and supports LGE's view.
Lalith(Samsung) shares view of Qian (Ericsson) and Hyunsook (LGE) and proposes to note.
Alessio(Nokia) also supports noting this CR.
Haris(Qualcomm) also proposes to note the CR
Haiyang (Huawei) is OK to note this CR.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2109019 (LS IN) Reply LS on LS on MINT functionality for Disaster Roaming. (Source: SA WG3 (S3-214342)).
Document for: Action.
Abstract: SA WG3 would like to thank SA WG2 for the LS(S3-213874/S2-2108172) on MINT functionality for Disaster Roaming. SA WG3 would like to inform SA WG2 that the MINT functionality must ensure that a VPLMN cannot single-handedly trick the HPLMN into considering the VPLMN as providing the disaster roaming. With this in mind, OAM configuration in the HPLMN seems important. SA WG3 would also like to inform SA WG2 that SA WG3 will continue to analyse further security impact caused by Disaster Roaming service indication and will keep SA WG2 informed when there is progress. Action: SA WG3 kindly asks SA WG2 to take the above information into account.

Comment:

Postponed.

Discussion and conclusion:

-

Status:

Postponed.

# 8.26 Architecture Enhancement for NR Reduced Capability Devices (ARCH_NR_REDCAP)

This agenda item was convened by Puneet Jain (Intel).

TD S2-2108648 (CR) 23.501 CR3316R1 (Rel-17, 'B'): EDRX enhancement for 10.24s cycle for RedCap. (Source: China Mobile).
Document for: Approval.
Abstract: Summary of change: Add the architecture enhancements to support paging handling of eDRX cycle 10.24s for the UE that support both NR and WB-E-UTRAN.

Comment:

Revision of (Postponed) S2-2107554 from S2#147E. r04 agreed. Revised to S2-2109322, merging S2-2108940.

Discussion and conclusion:

-

e-mail discussion:

Hannu (Nokia) provides r01 to merge the whole contents of S2-2108940 into this CR.
Qian (Ericsson) comments and provides r02.
Miguel (Qualcomm) ok with r02.
Aihua (China Mobile) provides r03.
Qian (Ericsson) comments on r03 and consider r02 is more correct.
Wanqiang (Huawei) comments and provides r04.
==== Revisions Deadline ====
==== Comments Deadline ====
Tricci (OPPO) supports r02 provided by Qian (Ericsson).

Status:

Revised to S2-2109322, merging S2-2108940.

TD S2-2109322 (CR) 23.501 CR3316R2 (Rel-17, 'B'): EDRX enhancement for 10.24s cycle for RedCap. (Source: China Mobile, Qualcomm Inc).
Document for: Approval.
Abstract: Summary of change: Add the architecture enhancements to support paging handling of eDRX cycle 10.24s for the UE that support both NR and WB-E-UTRAN.

Comment:

Revision of S2-2108648r04, merging S2-2108940. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108741 (CR) 23.501 CR3324R2 (Rel-17, 'B'): Capabilities for NR RedCap UE. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Specify the capabilities for NR RedCap UEs.

Comment:

Revision of (Agreed) S2-2107855 from S2#147E. Approved.

Discussion and conclusion:

-

e-mail discussion:

Qian (Ericsson) asks a question
Steve (Huawei) replies
Hannu (Nokia) supports approval of this revision for the sake of clarity (to send this clean version for plenary approval).
Miguel (Qualcomm) agrees this revision is needed for clean CR implementation of what was agreed last meeting, i.e. clause 5.6.1 is untouched.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Agreed.

TD S2-2108912 (CR) 23.501 CR3454 (Rel-17, 'F'): RAT type determination on AMF for NR Redcap. (Source: China Mobile).
Document for: Approval.
Abstract: Summary of change: Add the description of RAT type determination on AMF for NR Redcap.

Comment:

Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108940 (CR) 23.501 CR3457 (Rel-17, 'F'): Handling of PTW for eDRX = 10.24s. (Source: Qualcomm Incorporated).
Document for: Approval.
Abstract: Summary of change: If the AMF provides an extended idle mode DRX cycle length value of 10.24s, and the registration area of the UE contains only NR cells, the AMF does not include a Paging Time Window. If the AMF provides an extended idle mode DRX cycle length value of 10.24s, and the registration area of the UE contains E-UTRA cells, the AMF may include a Paging Time Window.

Comment:

Merged into S2-2109322.

Discussion and conclusion:

-

e-mail discussion:

Qian (Ericsson) propose to merge this into 8648
Hannu (Nokia) supports Qian's proposal to merge this into 8648 as there is one overlapping change.
Miguel (Qualcomm) ok to merge into 8648 to continue discussion in one thread and one CR.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Merged into S2-2109322.

# 8.27 Architecture support for NB-IoT/eMTC Non-Terrestrial Networks in EPS (IoT_SAT_ARCH_EPS)

This agenda item was convened by Tao Sun (China Mobile).

TD S2-2108261 (LS IN) LS on EPS support for IoT NTN in Rel-17. (Source: TSG RAN (RP-212617)).
Document for: Action.
Abstract: TSG RAN would like to thank SA WG2 for their LS on EPS support for IoT NTN in Rel-17. TSG RAN notes that SA WG2 does not plan to define new functionality in Rel-17 to support discontinuous coverage. TSG RAN would like to emphasize that support for discontinuous coverage (incl. related impact on paging, (e)DRX, PSM, and PLMN search) is considered minimum essential functionality in TSG RAN with work under way in RAN WGs. Bearing in mind the scope of SA WG2 WID, TSG RAN would like to ask: - TSG SA, SA WG2 to reconsider supporting new functionality to support discontinuous coverage; - TSG CT/CT WG1 to consider whether low-hanging fruit solutions are feasible at NAS relying on existing functionality to support discontinuity in coverage, or, should TSG SA, SA WG2 decide to introduce new functionality to support discontinuous coverage, to align with TSG SA, SA WG2. - TSG SA/SA WG2/CT/CT WG1 to inform TSG RAN on the outcome of the discussion above. TSG RAN may adjust the scope of its Work Item depending on the outcome of the above discussions in TSG SA, SA WG2, CT, CT WG1. TSG RAN notes that SA WG2 decided not to support WUS, assuming it was not discussed in RAN for Rel-17 IoT NTN. TSG RAN would like to emphasize that work to support WUS in IoT NTN is indeed ongoing, with RAN WG2 concluding the existing WUS mechanism can be reused without enhancement (except for minor enhancements if needed to support discontinuous coverage). TSG RAN would therefore like to ask TSG SA, SA WG2, CT and CT WG1 to ensure WUS is not excluded. Action: TSG RAN would like to ask TSG SA, SA WG2, TSG CT and CT WG1 to take note of the information above.

Comment:

Revision of S2-2107017 from S2#147E. Response drafted in S2-2108823. Final response in S2-2109344.

Discussion and conclusion:

-

Status:

Replied to.

TD S2-2108823 (LS OUT) [DRAFT] Reply LS on EPS support for IoT NTN in Rel-17. (Source: MediaTek Inc.).
Document for: Approval.
Abstract: LS reply should a conclusion be reached by SA WG2.

Comment:

Response to S2-2108261. CC#2: r05 agreed. Revised to S2-2109344.

Discussion and conclusion:

CC#2: S2-2108823r05 was proposed by MediaTek. It was clarified that the CRs need to be updated to the agreed versions. This was agreed and the LS was revised in S2-2109344.

e-mail discussion:

Hannu (Nokia) points out the obvious for the comment feed, that this proposes LS Out cannot be evaluated before conclusion on all related CRs.
==== Revisions Deadline ====
Guillaume (MediaTek Inc.) provides r01 in drafts.
Haris(Qualcomm) comments on r01 in DRAFTS and proposes additions
Guillaume (MediaTek Inc.) provide r02 in drafts.
Tao(VC) check can we live with the proposal by Haris
Sherry (Xiaomi) replies.
Sherry (Xiaomi) provides r03 in the draft folder.
Jean Yves (Thales) supports r03.
Wanqiang (Huawei) prefer r02. R03 does not really reflect the status
Guillaume (MediaTek Inc.) prefers r02
Jean Yves (Thales) is ok with r02 also.
Sherry (Xiaomi) comments and prefers r03.
Wanqiang (Huawei) think r03 is wrong, and we have to take r02.
==== Comments Deadline ====
Sherry (Xiaomi) can't accept r02.
Sherry (Xiaomi) provides r04.
Guillaume (MediaTek Inc.) comments
Guillaume (MediaTek Inc.) provides r05 with the correct TDoc# (8823 not 8937). OK with r02, not r03/r04.
Chris (Vodafone) says that r05 looks good.
Sherry (Xiaomi) is fine with r05.
Hannu (Nokia) thanks Guillaume for the update and supports r05.

Status:

Revised to S2-2109344.

TD S2-2109344 (LS OUT) Reply LS on EPS support for IoT NTN in Rel-17. (Source: SA WG2).
Document for: Approval.
Abstract: To: TSG RAN, TSG CT, CT WG1, TSG SA, RAN WG2. CC: RAN WG3, CT WG3, CT WG4. Attachments: S2-2109197, S2-2109198.

Comment:

CC#2: Revision of S2-2108823r05. Approved.

Discussion and conclusion:

-

Status:

Approved.

TD S2-2108271 (LS IN) LS from RAN WG2: LS on supporting discontinuous coverage in IoT NTN. (Source: RAN WG2 (R2-2109213)).
Document for: Action.
Abstract: RAN WG2 would like to inform that RAN WG2 has agreed on supporting discontinuous coverage without excessive UE power consumption and without excessive failures / recovery actions. RAN WG2 expects that when not in coverage UE may save power by not attempting cell search or connection establishment. The network is not expected to try to page UEs in an area with no coverage at a certain time, to the extent possible/reasonable. Due to limited time in Rel-17, it is RAN WG2's understanding that discontinuous coverage in Rel-17 needs to be introduced with minimum specification impact. RAN WG2 has discussed that there may be some impacts to paging, (e)DRX, PSM and PLMN search handling mechanisms and their configurations when the UE is in discontinuous coverage. Action: RAN WG2 respectfully asks SA WG2 and CT WG1 to take the above information into account for possible alignment work and provide feedback, if any.

Comment:

Revision of S2-2107047 from S2#147E. Postponed.

Discussion and conclusion:

-

Status:

Postponed.

TD S2-2108712 (CR) 23.401 CR3673 (Rel-17, 'C'): Multiple TACs handling for IoT NTN. (Source: OPPO).
Document for: Approval.
Abstract: Summary of change: When receives multiple TAIs in the ULI, MME proceeds with the procedure if one of the multiple TAIs is not in Forbidden Area, and initiates LCS procedure to determine the UE location and the TA the UE currently located. the eNodeB may determine the TA which the UE is currently located when the target UE is in CM-CONNECTED state and provide that TAI to MME as part of ULI.

Comment:

Postponed.

Discussion and conclusion:

-

e-mail discussion:

DongYeon (Samsung) comments.
Haris(Qualcomm) proposes to postpone this CR to February SA2 meeting
Guillaume (MediaTek Inc.) proposes to merge 8712 into 8824.
Jean Yves (Thales) comments on 8.11 & 8.27 synchronization and propose to postpone this CR.
Jingran (OPPO) is ok to postpone.
Stefan (Ericsson) supports to postpone
Sherry (Xiaomi) proposes to postpone this CR to align with the conclusion on the same issue under 8.11.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Postponed.

TD S2-2108742 (CR) 23.401 CR3674 (Rel-17, 'C'): Support of discontinuous coverage in IoT NTN. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Periodic TAU timer and/or active time configuration for support of discontinuous coverage. HLCom based on coverage information.

Comment:

Postponed.

Discussion and conclusion:

-

e-mail discussion:

Haris(Qualcomm) comments
Stefan (Ericsson) provides comments
Wanqiang (Huawei) provides feedback on the technical issues
Chris (Vodafone) asks on technical issues
Sherry (Xiaomi) comments and prefers to study the issue in R18.
Hannu (Nokia) supports the proposal to postpone.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Postponed.

TD S2-2108743 (CR) 23.682 CR0488 (Rel-17, 'C'): Support of discontinuous coverage in IoT NTN. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Periodic TAU timer and/or active time configuration for support of discontinuous coverage. HLCom based on coverage information.

Comment:

Postponed.

Discussion and conclusion:

-

e-mail discussion:

Haris(Qualcomm) comments
Stefan (Ericsson) provides comments
Sherry (Xiaomi) has the same comments as to 8742.
Hannu (Nokia) supports the proposal to postpone.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Postponed.

TD S2-2108744 (CR) 23.271 CR0436R2 (Rel-17, 'B'): LCS enhancement for IoT NTN in EPS. (Source: Huawei, HiSilicon, MediaTek Inc.).
Document for: Approval.
Abstract: Summary of change: Introduction the enhancement of EPC-NI-LR procedure to support the verification of UE location for NB-IoT, WB-EUTRAN and LTE-M satellite access.

Comment:

Revision of (Agreed) S2-2108026 from S2#147E. r01 agreed. Revised to S2-2109195.

Discussion and conclusion:

-

e-mail discussion:

Stefan (Ericsson) provides r01
Hannu (Nokia) asks why this EPS CR needs to be treated under NR satellite access WID and AI?
Stefan (Ericsson) used the wrong AI# in subject. Has been resent with correct AI#
Hannu (Nokia) prefers r01 but can also live with the original version of the CR.
==== Revisions Deadline ====
Guillaume (MediaTek Inc.) ok with r01
Tyler (OTD) prefers r01
Steve (Huawei) is ok with r01.
==== Comments Deadline ====.

Status:

Revised to S2-2109195.

TD S2-2109195 (CR) 23.271 CR0436R3 (Rel-17, 'B'): LCS enhancement for IoT NTN in EPS. (Source: Huawei, HiSilicon, MediaTek Inc.).
Document for: Approval.
Abstract: Summary of change: Introduction the enhancement of EPC-NI-LR procedure to support the verification of UE location for NB-IoT, WB-EUTRAN and LTE-M satellite access.

Comment:

Revision of S2-2108744r01. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108745 (CR) 23.682 CR0487R1 (Rel-17, 'B'): Support IoT NTN in EPS. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Introduction the support of NB-IoT and LTE-M satellite access and in EPS.

Comment:

Revision of (Agreed) S2-2107624 from S2#147E. r02 agreed. Revised to S2-2109196.

Discussion and conclusion:

-

e-mail discussion:

Stefan (Ericsson) provides r01
Hannu (Nokia) asks why this EPS CR is moved to NR satellite access WI and AI?
Stefan (Ericsson) provides comments
Steve (Huawei) is ok with r01
Hannu (Nokia) agrees r01 but asks a question on the new sub clause title and EPS satellite access.
Chris provides r02 as editorial alignment of r01
==== Revisions Deadline ====
Guillaume (MediaTek): ok with r02.
Steve (Huawei) is ok with r02.
==== Comments Deadline ====.

Status:

Revised to S2-2109196.

TD S2-2109196 (CR) 23.682 CR0487R2 (Rel-17, 'B'): Support IoT NTN in EPS. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Introduction the support of NB-IoT and LTE-M satellite access and in EPS.

Comment:

Revision of S2-2108745r02. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108784 (CR) 23.203 CR1136R2 (Rel-17, 'B'): Support policy and QoS control for satellite access. (Source: Huawei, HiSilicon, Qualcomm).
Document for: Approval.
Abstract: Summary of change: 1, PCRF considers satellite access for policy decision. 2, Add a new QCI=10 for QoS control 3, Add RAT type as input for PCC decision.

Comment:

Revision of (Agreed) S2-2108028 from S2#147E. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108824 (CR) 23.401 CR3663R2 (Rel-17, 'B'): Introduction of Satellite support for Cellular IoT. (Source: MediaTek Inc., Deutsche Telekom, Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Adding IoT NTN support in EPS.

Comment:

Revision of (Agreed) S2-2108025 from S2#147E. r05 agreed. Revised to S2-2109197.

Discussion and conclusion:

-

e-mail discussion:

Fei (OPPO) provides r01.
Stefan (Ericsson) provides r02
Guillaume (MediaTek Inc.): ok with r02
Sherry (Xiaomi) comments.
Hannu (Nokia) provides r03.
Hannu (Nokia) replies to Sherry on the indication of 'country'.
Guillaume (MediaTek Inc.) provides r04.
Sherry (Xiaomi) replies to Hannu.
Haris(Qualcomm) provides r05
==== Revisions Deadline ====
Guillaume (MediaTek): ok with r05
Steve (Huawei) is ok with r05.
Sherry (Xiaomi) is ok with r05.
==== Comments Deadline ====.

Status:

Revised to S2-2109197.

TD S2-2109197 (CR) 23.401 CR3663R3 (Rel-17, 'B'): Introduction of Satellite support for Cellular IoT. (Source: MediaTek Inc., Deutsche Telekom, Huawei, HiSilicon, Nokia. Nokia Shanghai Bell, Ericsson).
Document for: Approval.
Abstract: Summary of change: Adding IoT NTN support in EPS.

Comment:

Revision of S2-2108824r05. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108825 (WID REVISED) Revised WID: 'Architecture support for NB-IoT/eMTC Non-Terrestrial Networks in EPS' [IoT_SAT_ARCH_EPS].. (Source: MediaTek Inc.).
Document for: Approval.
Abstract: Discontinuous coverage, WUS.

Comment:

r03 agreed. Revised to S2-2109198.

Discussion and conclusion:

-

e-mail discussion:

Hannu (Nokia) provides r01 of the WID.
Guillaume (MediaTek Inc.) replies to Hannu (Nokia).
Guillaume (MediaTek Inc.) provides r01 in the rev folder
Haris(Qualcomm) proposes WID revision in DRAFTS
Stefan (Ericsson) provides r02 in rev folder
Guillaume (MediaTek Inc.) provides r03
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109198.

TD S2-2109198 (WID REVISED) Revised WID: 'Architecture support for NB-IoT/eMTC Non-Terrestrial Networks in EPS' [IoT_SAT_ARCH_EPS].. (Source: MediaTek Inc.).
Document for: Approval.
Abstract: Discontinuous coverage, WUS.

Comment:

Revision of S2-2108825r03. Approved.

Discussion and conclusion:

-

Status:

Approved.

TD S2-2108937 (CR) 23.401 CR3667R1 (Rel-17, 'C'): Support for IoT NTN with discontinuous coverage. (Source: Vodafone, MediaTek Inc., Sateliot, Novamint).
Document for: Approval.
Abstract: Summary of change: An explanatory note on MME configuration that can deal with discontinuous coverage without MME implementation change is added to 4.3.5.2, 'Reachability Management for UE in ECM-IDLE state'. NTN is added to the TAI list management 'other features' list in 4.3.5.3. HLCOM behaviour is updated.

Comment:

Revision of (Postponed) S2-2107723 from S2#147E. r04 agreed. Revised to S2-2109199.

Discussion and conclusion:

-

e-mail discussion:

Haris(Qualcomm) objects to the CR
Vodafone (Chris) answers the technical questions from Qualcomm
Haris(Qualcomm) provides further comments
Sherry(Xiaomi) comments
Hannu (Nokia) responds to Haris and supports this CR.
Chris (Vodafone) answers the Xiaomi comments
Haris(Qualcomm) comments
Haris(Qualcomm) provides r02
Sherry(Xiaomi) provides r03.
Chris (Vodafone) provides r04.
==== Revisions Deadline ====
Guillaume (MediaTek Inc.) supports r04
Jean Yves (Thales) supports r04
Sherry (Xiaomi) supports r04
Haris(Qualcomm) is ok with r04
Wanqiang (Huawei) is ok with r04 as progress
==== Comments Deadline ====.

Status:

Revised to S2-2109199.

TD S2-2109199 (CR) 23.401 CR3667R2 (Rel-17, 'C'): Support for IoT NTN with discontinuous coverage. (Source: Vodafone, MediaTek Inc., Sateliot, Novamint).
Document for: Approval.
Abstract: Summary of change: An explanatory note on MME configuration that can deal with discontinuous coverage without MME implementation change is added to 4.3.5.2, 'Reachability Management for UE in ECM-IDLE state'. NTN is added to the TAI list management 'other features' list in 4.3.5.3. HLCOM behaviour is updated.

Comment:

Revision of S2-2108937r04. Approved.

Discussion and conclusion:

-

Status:

Agreed.

# 8.28 Rel-17 CAT B/C alignment CR(s) due to the work led by other 3GPP Working Groups

This agenda item was convened by Andy Bennett (Samsung).

TD S2-2108280 (LS IN) LS on Slice list and priority information for cell reselection. (Source: CT WG1 (C1-216256)).
Document for: Action.
Abstract: CT WG1 thanks RAN WG2 for the LS on slice-based cell reselection and would like to respond to the questions asked as follows. 1. Can UE NAS provide to UE AS a list of slices (or slice group(s)), each with its corresponding priority for cell reselection evaluation in RRC_IDLE/RRC_INACTIVE? Answer 1: CT WG1 assumes SA WG2 to agree a stage 2 solution on how a list of slices (or slice group(s)) with priorities is provided to UE NAS. Once such solution is agreed in SA WG2, CT WG1 can work on clarifying the related interaction between the NAS and AS layers. 2. Can the concept of Slice group and its signalling (Slice Group and its identifier) be supported using NAS signalling? Answer 2: CT WG1 sees no issues to introduce support in NAS to convey information on Slice groups from the network to the UE. A solution would depend on requirements outside CT WG1 area of responsibility to configure Slice group information in the network, but once stage 2 requirements are available, CT WG1 can proceed with stage 3 NAS details. Action: CT WG1 asks RAN WG2 and SA WG2 groups to take the information above into account for the further work on slice-based cell reselection.

Comment:

CC#2: Postponed.

Discussion and conclusion:

-

Status:

Postponed.

TD S2-2108996 (LS IN) Reply LS on Slice list and priority information for cell reselection. (Source: RAN WG2 (R2-2111310)).
Document for: Action.
Abstract: RAN WG2 thanks SA WG2 for their reply LS on Slice list and priority information for cell reselection. RAN WG2 answers to the further questions asked by SA WG2 are below: 1. SA WG2 would like to understand from RAN WG2 perspective, whether it is possible that a network slice can be associated to none, one or more slice groups? RAN WG2 Answer: A slice can be associated to none or only one slice group. From RAN WG2 perspective, it is allowed to not associate a slice to any of the slice groups. 2. Does RAN WG2 intend to use the slice groups only for cell reselection or also for slice based RACH and if for both would RAN WG2 require different type of slice groups or is one type of slice group enough? RAN WG2 answer: RAN WG2 aims to use slice groups for both cell reselection and slice based RACH. This means slice to slice-group configuration is common to cell reselection and RACH. Configuration of whether to use slice-specific cell reselection or slice specific RACH is up to network configuration (i.e. some slice groups may use cell reselection but not RACH, some may use RACH but not cell reselection, some may use both). 3. What are the granularities of the slice groups for cell reselection, i.e. per TA or PLMN? RAN WG2 answer: RAN WG2 understanding is that the granularities of the slice groups are per TA but RAN WG2 details are FFS. 4. With regards to the logic of network slice priority for cell reselection; SA WG2 wonder if the UE NAS prioritization should consider network slice registration status (i.e. selecting among registered network slices from the Allowed NSSAI or also not yet registered network slices? RAN WG2 answer: RAN WG2 understands it is up to SA WG2/CT WG1 whether to consider the slice registration status. From RAN WG2 perspective, both registered slices and not yet registered slices can be considered for the slice priority. Furthermore, RAN WG2 confirms the following understanding and expects SA WG2, RAN WG3 and CT WG1 to take into account for future work: - Mapping between slice and slice group should be consistent between serving cell and UE, in order to avoid misunderstanding of system information. Action: RAN WG2 kindly asks SA WG2, RAN WG3 and CT WG1 to take the above information into consideration.

Comment:

Response drafted in S2-2109016. Postponed.

Discussion and conclusion:

-

Status:

Postponed.

TD S2-2109016 (LS OUT) [DRAFT] Reply LS on Slice list and priority information for cell reselection. (Source: China Mobile).
Document for: Approval.
Abstract: To: RAN WG2, RAN WG3 CC: CT WG1. Attachments: S2-210xxxx (TS23.501); S2-210xxxx (TS23.502).

Comment:

Created at CC#1. Response to S2-2108996. CC#2: The related CRs were not agreed and this LS was noted.

Discussion and conclusion:

CC#2: The related CRs were not agreed and this LS was noted.

e-mail discussion:

Dan (China Mobile) provides LS in revision folder
alessio(Nokia) provides revision 01
Peter Hedman (Ericsson) provides r02.
==== Revisions Deadline ====
Guillaume (MediaTek Inc.) suggests to keep this open as it is dependent on the conflicting CRs
==== Comments Deadline ====.

Status:

Noted.

TD S2-2109012 (LS IN) LS from RAN WG3: LS on Clarification of SCG outside RA for slicing. (Source: RAN WG3 (R3-216237)).
Document for: Action.
Abstract: RAN WG3 is discussing a solution for resource optimisation for a slice 1 in a gNB cell called Multi Carrier Resource Sharing solution. This solution assumes that the gNB hosts another cell with different frequency and overlapping coverage where the same slice 1 is available. It consists of setting up DC using SCG resources on the 'other cell' for offloading the PDU sessions of slice 1 of some or all UEs. RAN WG3 is not sure if gNB can select such 'other cell' outside of the RA (registration area) of the concerned UE as SCG resource (i.e. the secondary cell group in Dual Connectivity.). Action: RAN WG3 kindly ask SA WG2 to provide feedback on the question above and if yes, how to address it.

Comment:

Postponed.

Discussion and conclusion:

-

Status:

Postponed.

TD S2-2108471 (CR) 23.501 CR3317R1 (Rel-17, 'B'): Enabling slice priority and slice groups for RRM purposes. (Source: Ericsson, China Mobile).
Document for: Approval.
Abstract: Summary of change: Enabling the Slice Groups and slice priorities as requested.

Comment:

Revision of (Noted) S2-2107556 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

Alessio(Nokia) as already commented for the document S2-2108798 we suggest to postpone handling of priority topic to eNS_Ph3, cannot accept the approach in this CR.
Peter Hedman (Ericsson) provides comments
Guillaume (MediaTek Inc.) comments and asks for misc. clarification.
Dieter (Deutsche Telekom) comments.
Peter Hedman (Ericsson) provides r01
Dan(China Mobile) comments.
Peter Hedman (Ericsson) provides r02
Dan (China Mobile) provides reply to Guillaume
Alessio(Nokia) sees no rush to approve CRs at this meeting.in particular the topic of priority is contentious for this release (some see it contentious even for rel-18 I have just seen !)
Guillaume (MediaTek Inc.) responds to Peter (Ericsson) and provide r03
Peter Hedman (Ericsson) provides r04
Dongeun (Samsung) provides r05
Alessio(Nokia) proposes to merge this in 8845 that only covers the group assignment topic. it is not feasible to agree on priority discussion in this release.
==== Revisions Deadline ====
alessio(Nokia) objects to any CR including priority topic
Guillaume (MediaTek) proposed to postpone or note this CR (and 8845)
Peter Hedman (Ericsson) provides reply to Dongeun (Samsung) and do not think there is a need for separate list of groups per TA as in r05.
Dongeun (Samsung) provides reply to Peter (Ericsson)
Dieter (Deutsche Telekom) proposes to postpone or note this CR as per previous comment.
Dan (China Mobile) propose we should work on this and try to get some conclusoin in R17
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108618 (DISCUSSION) Discussion on the Granularity of Slice Groups for Cell Re-selection.. (Source: Samsung).
Document for: Agreement.
Abstract: This contribution discusses on the granularity of slice groups for cell reselection.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108620 (CR) 23.502 CR3264 (Rel-17, 'B'): Support Slice group for cell re-selection. (Source: Samsung).
Document for: Approval.
Abstract: Summary of change: -If the AMF determines that the UE and the RAN supports network slice group for cell re-selection, the AMF provide the NSG-CR List to UE according to clause 5.15.4.1.1 in TS 23.501 [2]. The AMF may query NSSF to obtain the NSG-CR List.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Peter (Ericsson) provides comments and propose we should cover both group aspects and the priority handling
Dieter (Deutsche Telekom) comments.
==== Revisions Deadline ====
Peter Hedman (Ericsson) object to any CR that only covers slice grouping and not the priority handling
Dieter (Deutsche Telekom) proposes to postpone or note this CR as per previous comment.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108781 (CR) 23.501 CR3427 (Rel-17, 'B'): Support Slice group for cell re-selection. (Source: Samsung).
Document for: Approval.
Abstract: Summary of change: -Add NSG-CR in UE MM capability -Desccriptions on the NSG-CR List -NSSF support of determining NSG-CR List.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Peter (Ericsson) provides comments and propose we should cover both group aspects and the priority handling
Dieter (Deutsche Telekom) comments.
==== Revisions Deadline ====
Peter Hedman (Ericsson) object to any CR that only covers slice grouping and not the priority handling
Dieter (Deutsche Telekom) proposes to postpone or note this CR as per previous comment.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108764 (CR) 23.501 CR3424 (Rel-17, 'F'): Slice Group ID Management. (Source: Huawei).
Document for: Approval.
Abstract: Summary of change: Add NSRRMG related description. NSRRMG could be used for slice based cell reselection and slice based RACH.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Peter (Ericsson) provides comments and propose we should cover both group aspects and the priority handling
Alessio(Nokia) this is not far apart from what we proposes and suggests to merge this into S2-2108845
Dieter (Deutsche Telekom) comments.
Haiyang (Huawei) is ok to merge into S2-2108845
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108765 (CR) 23.502 CR3286 (Rel-17, 'F'): Slice Group ID management. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: Summary of change: Add NSRRMG related description in Registration and UCU procedure.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Peter (Ericsson) provides comments and propose we should cover both group aspects and the priority handling
Dieter (Deutsche Telekom) comments.
==== Revisions Deadline ====
Peter Hedman (Ericsson) object to any CR that only covers slice grouping and not the priority handling
Dieter (Deutsche Telekom) proposes to postpone or note this CR as per previous comment.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108798 (CR) 23.502 CR3194R1 (Rel-17, 'B'): Support of slice priority and slice group information for cell (re)selection. (Source: China Mobile).
Document for: Approval.
Abstract: Summary of change: Add description about 5GC providing NPNSP, NSRRMG information to UE Slice information coordination between RAN,5GC and UE for cell reselection.

Comment:

Revision of (Noted) S2-2107535 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

Dan (China Mobile) provides r01
Alessio(Nokia) comments and suggest to postpone handling of priority topic to eNS_Ph3, cannot accept r01 nor r00 and proposes to merge into S2-2108866
Dieter (Deutsche Telekom) comments.
Dan (China Mobile) provide r02
Alessio(Nokia) sees no rush to approve CRs at this meeting.in particular the topic of priority is contentious for this release (some see it contentious even for rel-18 I have just seen !)
Dan (China Mobile) provide r03 with removing Allowed NSSAI related parameters
Dongeun (Samsung) provides r04. This is an 23.502 alignment with 23.501 CR (8471r05)
alessio(Nokia) proposes to merge this into the nokia et al CR in S2-2108866 which is addressing only the group aspect. we prefer to note this one
==== Revisions Deadline ====
alessio(Nokia) objects to any CR revision including priority topic
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108943 (CR) 23.501 CR3319R2 (Rel-17, 'B'): Support for Paging Early Indication. (Source: Qualcomm Inc.).
Document for: Approval.
Abstract: Summary of change: Support for NR Paging Early Indication in RRC_IDLE and RRC_INACTIVE. Support of CN assigned Paging Early Indication with Paging subgrouping assistance information.

Comment:

Revision of (Revised and Agreed) S2-2107584 from S2#147E. Merged into S2-2109339.

Discussion and conclusion:

-

e-mail discussion:

Hannu (Nokia) comments proposes to merge the agreeable parts of this CR to S2-2108959.
Guillaume (MediaTek Inc.) proposed to merge 8943 in 8959
Miguel (Qualcomm) responds to Hannu
Miguel (Qualcomm) ok to merge in S2-2108959
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Merged into S2-2109339.

TD S2-2108959 (CR) 23.501 CR3319R3 (Rel-17, 'B'): Support for Paging Early Indication. (Source: Vodafone [rev 1 was MediaTek Inc., Qualcomm Inc., OPPO, Apple, Ericsson, Huawei, HiSilicon]).
Document for: Approval.
Abstract: Summary of change: Support for NR Paging Early Indication in RRC_IDLE and RRC_INACTIVE. Support of CN assigned Paging Early Indication with Paging subgrouping assistance information.

Comment:

Revision of (Agreed) S2-2107857 from S2#147E. r08 agreed. Revised to S2-2109339, merging S2-2108943.

Discussion and conclusion:

-

e-mail discussion:

Qian (Ericsson) provides comments and asks questions
Hannu (Nokia) provides r01 and proposes to take this CR as the template for further work.
Guillaume (MediaTek Inc.) provides r02.
Chris (Vodafone) answers Ericsson.
Qian (Ericsson) provides comments and r03
Tricci (OPPO) provides r04 to add an EN to clarify that the support for the paging probability info is subject to RAN2 agreement.
Chris (Vodafone) provides r05 in order to avoid this feature INCREASING UE power consumption.
Qian (Ericsson) comments on r05 and express concerns.
Steve (Huawei) comments
Chris (Vodafone) answers Ericsson and Huawei.
Guillaume (MediaTek Inc.) provides r06 (pls ignore) and r07
Qian (Ericsson) comments on provides r07.
Qian (Ericsson) indicates that r08 is provided (instead of r07 as in previous comment).
==== Revisions Deadline ====
As a basis for further work Chris (Vodafone) can accept r08 with the cover sheet tidied up to remove the 'r03 updates..'
Miguel (Qualcomm) is ok with r08.
Guillaume (MediaTek Inc.) provides r09 in drafts - basic clean-ups.
Steve (Huawei) is ok with r08 + coversheet clean-up.
==== Comments Deadline ====
Hannu (Nokia) request this for CC and asks whether there was any discussion on re-inserting the UE assistance info (in the form of paging assistance data) since r01?
Chris (Vodafone) answers Nokia.
Guillaume (MediaTek Inc.) confirms the paging probability information was indeed discussed explicitly before yesterday's deadline and was not rediscussed today. An EN was added by Tricci/Oppo.
Hannu (Nokia) thanks Chris and Guillaume for their explanation on the UE provided paging probability topic.
Tricci (OPPO) thanks Guillaume (MediaTek) great work for the merge and clarifications.
Tricci (OPPO) can support r08 + coversheet clean-up.

Status:

Revised to S2-2109339, merging S2-2108943.

TD S2-2109339 (CR) 23.501 CR3319R4 (Rel-17, 'B'): Support for Paging Early Indication. (Source: MediaTek Inc., Qualcomm Inc., OPPO, Apple, Ericsson, Huawei, HiSilicon, Vodafone, Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: Support for NR Paging Early Indication in RRC_IDLE and RRC_INACTIVE. Support of CN assigned Paging Early Indication with Paging subgrouping assistance information.

Comment:

Revision of S2-2108959r08, merging S2-2108943. Approved.

Discussion and conclusion:

-

Status:

Agreed.

TD S2-2108944 (CR) 23.502 CR3216R2 (Rel-17, 'B'): Support of Paging subgrouping. (Source: Qualcomm Incorporated).
Document for: Approval.
Abstract: Summary of change: Registration procedure: -Include indications of NR paging subgrouping support and AMF indication of NR paging subgrouping ID. -Extend paging probability from UE to apply to NR paging subgrouping Network intiated service request procedure: -Include support of NR paging subgrouping and NR paging subgrouping in N2 paging request - Rev 2: Reuse paging probability information for UE assistance to AMF PEIPS assistance information determination. MM context: Include NR paging subgrouping support and NR paging subgrouping ID.

Comment:

Revision of (Agreed) S2-2107858 from S2#147E. CC#2: This was left for further update for decision at CC#3. CC#3: Postponed.

Discussion and conclusion:

CC#2: Nokia objected to this CR as it was agreed to reuse existing information whereas this adds new paging assistance information. Nokia added that the previously agreed CR does not align with agreements from this meeting and should be 'unagreed'. Qualcomm suggested removing the Editor's note on this. Vodafone asked to allow time to update this to align with 23.501 and quickly review in CC#3. This was left for further update for decision at CC#3.
CC#3: Qualcomm provided S2-2108944r02. Nokia asked whether r01 could be acceptable. This was not agreed and the CR was postponed. Nokia commented that the previously agreed CR in S2-2107858 is therefore misaligned with agreements and should also be postponed. S2-2107858 from S2#147E was also postponed.

e-mail discussion:

Hannu (Nokia) proposes to note this CR.
Miguel (Qualcomm) responds to Hannu, prefers to keep open and dependent on the 23.501 discussion, e.g. S2-2108959
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Postponed.

TD S2-2108866 (CR) 23.502 CR3300 (Rel-17, 'B'): Enabling configuration of Network Slice AS Groups. (Source: Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: Configuration of NSAGs (Network Slices AS Groups); Some other errors related to NSSRG support are also removed. (the NSSRG support is part of 5GMM core network capability infor not independent info).

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Peter (Ericsson) provides comments and propose we should cover both group aspects and the priority handling
Jinhua(Xiaomi) provides r01,
Dongeun (Samsung) provides r02
Dieter (Deutsche Telekom) comments.
Peter Hedman (Ericsson) provides comments
Alessio(Nokia) can live with r02
Jinhua(Xiaomi) provides r03,
Alessio(Nokia) thanks Jinhua(Xiaomi) who provided r03, which is acceptable to us.
==== Revisions Deadline ====
Peter Hedman (Ericsson) object to any CR that only covers slice grouping and not the priority handling
Dieter (Deutsche Telekom) proposes to postpone or note this CR as per previous comment.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108845 (CR) 23.501 CR3436 (Rel-17, 'B'): Enabling configuration of Network Slice AS Groups. (Source: Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: Configuration of NSAGs (Network Slices AS Groups).

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Peter (Ericsson) provides comments and propose we should cover both group aspects and the priority handling
Dongeun (Samsung) provides comments
Alessio(Nokia) this is moved to AI#8.28
Alessio(Nokia) despite it is in 8.28, I can reply to Dongeun (Samsung) that we are happy to consider enhancements to cover the per TA granularity.
Dongeun (Samsung) provides r01 and comments
Dieter (Deutsche Telekom) comments.
Peter Hedman (Ericsson) provides comments
Alessio(Nokia) would then be ok to postpone this to rel-18 as the topic of priority is contentious for this release (some see it contentious even for rel-18I have just seen !)
Alessio(nokia) can live with r01
Haiyang (Huawei) provides r02
==== Revisions Deadline ====
Jinhua(Xiaomi) prefer r02, agree with Haiyang,
Guillaume (MediaTek) proposed to note or postpone this CR
Peter Hedman (Ericsson) object to any CR that only covers slice grouping and not the priority handling
Dieter (Deutsche Telekom) proposes to postpone or note this CR as per previous comment.
alessio(Nokia) replies and would welcome a change of heart by Mediatek
Genadi (Lenovo) supports the r02.
Guillaume (MediaTek Inc.) replies
==== Comments Deadline ====
Tricci (OPPO) supports the r02 to align with RAN2 conclusions.

Status:

Noted.

TD S2-2108259 (LS IN) LS from RAN WG2: Reply LS on Cell reselection with band-specific network slices. (Source: RAN WG2 (R2-2108868)).
Document for: Action.
Abstract: RAN WG2 thanks SA WG2 for the LS on Cell reselection with band specific network slices (S2-2105158/ R2-2106972). Regarding the Action: point for RAN WG2: ' Please provide feedback as to whether providing this information to the RAN and handling it as described above in the text in the box, can have any negative impact and any other feedback.' RAN WG2 has concluded that this mechanism has no impact on RAN WG2 specifications. Action: RAN WG2 respectfully asks SA WG2 to take the above feedback into account.

Comment:

Revision of S2-2107011 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

Tao(VC) suggest to NOTE this LS suppose this has been acknowledged after 3 meetings.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2109371 (LS IN) LS from RAN WG2: LS on paging subgrouping and PEI. (Source: RAN WG2 (R2-2111415)).
Document for: Action.
Abstract: RAN WG2 discussed UE paging subgrouping as part of the Rel-17 work on UE power saving enhancement (see RP-200938). On paging subgrouping, the following provides the detailed agreements for the 2 approaches (CN-assigned subgrouping and UE ID-based subgrouping): - Assume that one subgroup indication refers to either CN-assigned subgroups or UE ID-based subgroup (no overlapping) - Both UE ID-based and CN-assigned subgrouping can be supported simultaneously in a cell, it is allowed to just support one of them. - The total number of CN-assigned subgroups that is used is not fixed and can be configured up to 8 (e.g. by OAM). No impact on signalling is assumed. - RAN introduces a new parameter Nsg-UEID to indicate its support of UE ID-based subgrouping. - RAN does not support any type of subgrouping if its configuration for subgrouping is either absent or nullified (e.g. subgroupsNumPerPO is either absent or set to zero). FFS for the signalling details. - We assume separate indications for UE capability of CN-assigned subgrouping and UE ID-based subgrouping. - UE's capability of supporting the UE ID-based subgrouping is reported to RAN by AS UE capability signalling while R2 assumes that UE's capability of supporting the CN-assigned subgrouping is reported to CN by NAS signalling. RAN WG2 also discussed the Paging Early Indication, and agreed to the following: - RAN WG2 assumes that if PEI is detected, and the PEI indicates that the UE has to monitor the associated PO, then the UE monitors paging DCI in the associated PO, including scheduling information for paging PDSCH (if included) as in legacy. This assumption may be updated based on RAN WG1 agreements. - As a baseline RAN WG2 has a preference to support PEI with both DRX and eDRX, but potential issues (e.g. PEI and PTW) are FFS. - For UE ID-based subgroups the UE identity is UE_ID = 5G-S-TMSI mod X, where X is 8192 (1024*8). - Introduce a UERadioPagingInfo IE in the UECapabilityInformation message in NR in Rel-17. - If the UE was not able to monitor the PEI occasion corresponding to its PO, the UE shall monitor the PO. Actions: To SA WG2 and CT WG1: RAN WG2 respectfully asks SA WG2 and CT WG1 to take the above information into account for their future work, and provide further information on the following issue once concluded: - NAS signalling between AMF and UE to convey the related information to the UE, e.g., UE's capability reporting by NAS.

Comment:

Postponed.

Discussion and conclusion:

-

e-mail discussion:

Steve (Huawei) Suggests postponing.
Guillaume (MediaTek Inc.) agrees this should be postponed.
==== Comments Deadline ====.

Status:

Postponed.

# 9 Project Planning and Managemen

This agenda item was convened by Puneet Jain (Intel).

# 9.1 New and Revised Work Items, TS/TR Cover sheets, Exception Sheets

# 9.1.1 Rel-17 new and revised Work Items

TD S2-2108417 (WID NEW) New WID on 5G Architecture Enhancements for RAN Slicing for NR.. (Source: China Mobile).
Document for: Approval.
Abstract: New WID on 5G Architecture Enhancements for RAN Slicing for NR.

Comment:

Revision of (Noted) S2-2107273 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

Alessio(Nokia) expects we do not need a new WID, soe we can note this. We can reuse eNS_Ph2 WID and update it to cover alignment with NR_Slice-Core RAN WI as an objective. this can be an updated WID for SA#94 the rapporteur or another company can submit.
==== Revisions Deadline ====
Dan(China Mobile) OK to note this wid and we can try to update the eNS_Ph2 WID in SA plenary.
==== Comments Deadline ====.

Status:

Noted.

# 9.1.2 TS/TR Cover sheets

# 9.1.3 Revision of Rel-18 SID/WID proposal POSTPONED at SA2#147E

TD S2-2108369 (SID NEW) New SID: Study on enhanced support of NR RedCap with long eDRX for RRC INACTIVE State.. (Source: Ericsson, Deutsche Telekom, Verizon, Xiaomi, Sony, Nokia, Nokia Shanghai Bell, MediaTek, AT&T, Apple, Qualcomm, Vodafone, InterDigital, China Mobile.).
Document for: Approval.
Abstract: New SID to enhanced the support for RedCap UE.

Comment:

r02 agreed. Revised to S2-2109323.

Discussion and conclusion:

-

e-mail discussion:

Jinsook (DISH Network) provides r01.
Qian (Ericsson) comments that r01 is not uploaded by rapporteur and rapporteur will upload a new revision with more supporting companies.
Hannu (Nokia) supports r01 as reasonable clarification of the wording and looks forward to the rapporteur version.
Qian (Ericsson) comments and provides r02 on top of r01.
Wanqiang (Huawei) ok with r02.
==== Revisions Deadline ====
Lars (Sony) ok with r02.
Sherry (Xiaomi) is fine with r02 and using TR for the study.
Jinsook (DISH Network) is also fine with r02 and using TR.
==== Comments Deadline ====
Hannu (Nokia) can live with his own r01 but prefers subsequent r02.

Status:

Revised to S2-2109323.

TD S2-2109323 (SID NEW) New SID: Study on enhanced support of NR RedCap with long eDRX for RRC INACTIVE State.. (Source: Ericsson, Deutsche Telekom, Verizon, Xiaomi, Sony, Nokia, Nokia Shanghai Bell, MediaTek, AT&T, Apple, Qualcomm, Vodafone, InterDigital, China Mobile, OPPO, DISH Network.).
Document for: Approval.
Abstract: New SID to enhanced the support for RedCap UE.

Comment:

Revision of S2-2108369r02. Approved.

Discussion and conclusion:

-

Status:

Approved.

TD S2-2108370 (DISCUSSION) Discussion on NR RedCap with long eDRX in RRC Inactive SID handling and summary of the reviewed solutions.. (Source: Ericsson).
Document for: Agreement.
Abstract: This document discusses the possible ways of conducting the study and provides a high level summary of solutions reviewed in previous meetings.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Hannu (Nokia) requests that whichever way the candidate solutions are documented, SA2 must leave a quotable document on the conclusions.
Dieter (Deutsche Telekom) also prefers a TR.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108379 (WID NEW) New WID on Use of L4S in 5GS (5G_L4S) .. (Source: Ericsson).
Document for: Approval.
Abstract: Support of L4S in 5GS.

Comment:

CC#3: 5 objections. Noted.

Discussion and conclusion:

CC#3: Ericsson proposed S2-2108379r02. Huawei could not accept this version and preferred to include a study phase for this. Tencent also preferred to have an initial Study. Ericsson replied that a previous WI had been agreed including Tencent as a supporting company with similar work needed, Huawei clarified that the AIS WI had consensus and there was only a single identified solution to document whereas they believe there are additional solutions for this proposed WI. The SA WG2 Chair asked whether a compromise could be reached for this to have a short study to analyse potential solutions and agree on a single solution. Huawei proposed a short 3TU study in r01. Magenta preferred to do a direct WID but could accept a compromise of a short study. Ericsson commented that Huawei suggest there is another solution but the WID is to reuse existing functionality for LCS. This was left for further consideration.
Ericsson reported that they did not see how they can have a study phase with a single TU. Huawei replied that they did not accept including a study phase within the WID and did not think 0.25 TU was enough time for such a study. Nokia supported the WID and could accept also having a Study Phase for LCS but did not see the real need for it. Tencent preferred to have a study phase for this.
Objections to this WID: 5
This was then noted.

e-mail discussion:

Hui (Huawei) objects r00 and provides r01.
Youngkyo(Samsung) provides some questions for understanding.
Hui (Huawei) objects r00, provides draft r01.
Hucheng (CATT) comments.
Paul (Ericsson) replies to Hui (Huawei).
Paul (Ericsson) replies to Youngkyo(Samsung) and Hucheng (CATT).
Hui (Huawei) replies to Paul (Ericsson).
Youngkyo(Samsung) provides further comment and question.
Antoine (Orange) supports r00 i.e a Study is not needed.
Curt (Charter) supports Antoine (Orange)
Jinguo (ZTE) supports to have study first
Dieter (Deutsche Telekom) also supports original WID, i.e. no study is needed.
Paul (Ericsson) replies to Youngkyo(Samsung).
Sriram (CableLabs) supports original WID, i.e. no study is needed.
Devaki (Nokia) supports L4S as a WID (r00) to keep the work focused.
Krisztian (Apple) supports r00, there's no need to convert this into a SID.
Youngkyo(Samsung) replies.
Paul (Ericsson) replies to Jinguo (ZTE).
Jinguo(ZTE) replies
Patrice (Huawei) reminds that the argument for a direct WID only works when there is a complete WG consensus on the proposed solution, and therefore a SID is the only appropriate approach in this case. And even if there were a full consensus on the exact solution (which is not the case), this should be then dealt as a TEI18, therefore not part of the agenda at this meeting.
Yali (OPPO) comments and shares the view from Jinguo(ZTE).
Paul (Ericsson) replies to Youngkyo (Samsung).
Paul (Ericsson) replies to Jinguo (ZTE) and Yali (OPPO).
Yali (OPPO) replies to Paul (Ericsson).
Paul (Ericsson) replies to Yali (OPPO).
Paul (Ericsson) thanks Huawei for the lesson on how it works, maybe we can help your understanding that since there is no full consensus as you say on details, that is why it is a WI.
Patrice (Huawei) thanks Paul (Ericsson) on his compliment regarding the lesson on how it works, and clarifies that since there is no full consensus (and not on details only), that is why it has to be a SID.
Gerry (Verizon) supports r00 and we also do not see the need for a study.
==== Revisions Deadline ====
Farooq (AT&T) also supports r00 and we also do not see the need for a study.
Jinsook (DISH Network) We also support original WID, no need any study phase.
Serge M (T-Mobile USA) also supports r00 and we also do not see the need for a study.
Guillaume (MediaTek Inc.) supports r00
Paul (Ericsson) provides a proposal. This feature has been discussed since 2 years now, in that time its specification in IETF also further matured. L4S is becoming well established in the industry and a there is a high interest for its introduction in 3GPP. The WID has a clear and well defined scope and a wide support in SA2 to be progressed in Rel-18. Given all technical comments and questions being addressed, we propose to approve this Rel-18 WID r00 at this meeting.
Jinguo(ZTE) asks why UE is excluded to support L4S?
Lars (Sony) also supports r00
Hui (Huawei) insists that a study item is needed.
==== Comments Deadline ====
Shabnam (Ericsson) asks to discuss at CC#2 to find a reasonable way forward, for a mature technology with nothing to study but reflect how 3GPP system can enable this feature option, reusing 3GPP existing architecture and mechanism.
Paul (Ericsson) provides r01 to the CC#2.
Hui(Huawei) disagree with r01 provided by Paul.

Status:

Noted.

TD S2-2108463 (SID NEW) New SID: Study on enhanced support of Non-Public Networks phase 2.. (Source: Ericsson, Futurewei, Convida Wireless, Charter, China Unicom, ETRI; Cisco, China Mobile, Lenovo, Motorola Mobility, Qualcomm, ZTE, Philips, Intel, Matrixx, SHARP, InterDigital, LG Electronics, NEC, Samsung, OPPO, T-Mobile USA, NICT).
Document for: Approval.
Abstract: New SI proposal related to enhancements to NPN.

Comment:

CC#3: r05 agreed. Revised to S2-2109353.

Discussion and conclusion:

CC#3: Ericsson provided S2-2108463r04 and S2-2108463r05 with reduced Scope and TU budget. Huawei asked why 3d is removed. Ericsson replied that this was removed as part of the budget reduction exercise by supporting companies. S2-2108463r05 was agreed and was revised to S2-2109353.

e-mail discussion:

Peter Hedman (Ericsson) provides r01
Sebastian (Qualcomm) comments
Curt (Charter) comments
Qianghua (Huawei) provides comments
Saso (Intel) comments
Peter Hedman (Ericsson) provides replies.
Marco (Huawei) comments
Marco (Huawei) answers to Curt (Charter) comment
Peter Hedman (Ericsson) provides r02
Dieter (Deutsche Telekom) comments.
Hualin(Huawei) have similar comments as Sebastian (Qualcomm) to go back to 'non-3GPP'
==== Revisions Deadline ====
Sebastian (Qualcomm) objects to r00 - r02 for reasons given earlier
Peter Hedman (Ericsson) provides reply and ok to change back objective 2 as proposed, r03 in draft folder
Rainer (Nokia) comments.
Sebastian (Qualcomm) is ok with r03 in draft folder
==== Comments Deadline ====
Jarmo (KPN) would like to support the study.
Peter Hedman (Ericsson) provides r05 (and r04) in CC#3 folder.

Status:

Revised to S2-2109353.

TD S2-2109353 (SID NEW) New SID: Study on enhanced support of Non-Public Networks phase 2.. (Source: Ericsson, Futurewei, Convida Wireless, Charter, China Unicom, ETRI; Cisco, China Mobile, Lenovo, Motorola Mobility, Qualcomm, ZTE, Philips, Intel, MATRIXX Software, SHARP, InterDigital, LG Electronics, NEC, Samsung, OPPO, T-Mobile USA, NICT, DISH Network, vivo, KPN, CableLabs).
Document for: Approval.
Abstract: New SI proposal related to enhancements to NPN.

Comment:

Revision of S2-2108463r05. Approved.

Discussion and conclusion:

-

Status:

Approved.

TD S2-2108518 (DISCUSSION) Discussion paper on Network & Computing Power integration. (Source: China Telecom).
Document for: Information.
Abstract: Discussion paper on Network & Computing Power integration.

Comment:

Revision of (Noted) S2-2107563 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

Laurent (Nokia): proposes to Note this discussion paper (objects to it) and to concentrate on the SID discussion
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108519 (SID NEW) New SID on Study on integration of network and computing power in 5GS .. (Source: China Telecom).
Document for: Approval.
Abstract: Objective: The objectives of this SA WG2 study are to study how 5G system can be enhanced to support mobile computing power network, including the following working tasks (WT): WT#1: Identification and standardization computing power in 5G; WT#2: Potential architecture enhancement in network architecture e.g., EC to coordinate with computing power; WT#3: For operators controlled (Edge) Application Server (AS/EAS), design the mechanism of EAS/AS (re-)discovery to satisfy the computing power resource requirement; WT#4: Optimize the end-to-end delay for low delay or Deterministic delay service.

Comment:

Revision of (Postponed) S2-2107562 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

Guliang (Inspur) support the SID and would like to co-source it.
Laurent (Nokia): expresses serious concerns
Haris(Qualcomm) objects to this SID
Saso (Intel) objects to this SID
Shabnam (Ericsson) shares same view as expressed during MED and similar to Intel, Qualcomm, Nokia, as such objects to this SI.
Jungshin (Samsung) objects to this SID.
Yifan (China Telecom) provides r01.
Laurent (Nokia): objects to any version of this SID
==== Revisions Deadline ====
Yifan (China Telecom) replies.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108529 (SID NEW) New SID on Study on Support of Satellite Backhauling in 5GS .. (Source: CATT).
Document for: Approval.
Abstract: This contribution proposes a new SID on supporting satellite backhaul in 5GS.

Comment:

Revision of (Postponed) S2-2107429 from S2#147E. CC#3: r04 agreed. Revised to S2-2109354.

Discussion and conclusion:

CC#3: CATT provided S2-2108529r04 and S2-2108529r05, reporting that r04 had appeared acceptable. S2-2108529r04 was agreed and was revised to S2-2109354.

e-mail discussion:

Stefan (Ericsson) provides comments and a revision in DRAFTS
Haris(Qualcomm)
Wanqiang (Huawei) provides a revision in DRAFTS
Hucheng (CATT) responds to the comments.
Hannu (Nokia) comments that the original version is definitely not acceptable and may come back with comments on the proposed revisions later.
Hucheng (CATT) provides r01 based on the draft revisions from Ericsson, Qualcomm and Huawei.
Leo (Deutsche Telekom) provides comments.
Hucheng (CATT) replies to Leo (Deutsche Telekom).
Hannu (Nokia) shares Leo's concern on charging.
Hucheng (CATT) clarifies the charging aspect to Hannu (Nokia).
Hucheng (CATT) provides r02 based on the comments.
Hannu (Nokia) provides revision in drafts area and asks question on the justification for WT#4.
Hucheng (CATT) thanks for Hannu's revision and clarifies the use cases for WT#4.
Stefan (Ericsson) comments and provided a revision in DRAFTS
Leo (Deutsche Telekom) comments
Hucheng (CATT) replies to Stefan (Ericsson)'s comments and provided r03.
==== Revisions Deadline ====
Haris(Qualcomm) comments
Hucheng (CATT) replies to Haris(Qualcomm)
Hucheng (CATT) replies to Leo.
Hucheng (CATT) replies to Stefan (Ericsson) and points out that there is a SA1 requirement related to limited bandwidth.
Hucheng (CATT) replies to Haris(Qualcomm) and provides r04 and r05 into draft folder, but prefer r04.
Wanqiang (Huawei) prefers r04.
Haris(Qualcomm) is ok with either r04 or r05
Jean Yves (Thales) ok also with either r04 or r05
Stefan (Ericsson) prefers r05
==== Comments Deadline ====
Hannu (Nokia) prefers r05.

Status:

Revised to S2-2109354.

TD S2-2109354 (SID NEW) New SID on Study on Support of Satellite Backhauling in 5GS .. (Source: CATT).
Document for: Approval.
Abstract: This contribution proposes a new SID on supporting satellite backhaul in 5GS.

Comment:

Revision of S2-2108529r04. Approved.

Discussion and conclusion:

-

Status:

Approved.

TD S2-2108543 (DISCUSSION) The Discussion on the motivation of Passive IoT. (Source: China Mobile).
Document for: Discussion.
Abstract: The Discussion on the motivation of Passive IoT.

Comment:

Revision of (Noted) S2-2107559 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

Hannu (Nokia) comments that since the corresponding SA1 SID is not approved and it's targeting Rel-19, it is not possible to plan the SA2 work in Rel-18.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108573 (DISCUSSION) Moderated email discussion on FS_GMEC.. (Source: Huawei/Samsung (moderator)).
Document for: Information.
Abstract: Pre SA WG2#148E_Moderated email discussion_FS_GMEC.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108574 (SID NEW) New SID on generic group management, exposure and communication enhancements.. (Source: Huawei, HiSilicon, Samsung, CATT, China Mobile, China Telecom, China Unicom, ZTE, Juniper, SK Telecom, KT Corp, LG Uplus, KPN, Siemens, Robert Bosch GmbH, LGE, Spreadtrum Communications, ETRI, CAICT, China Southern Power Grid, CEPRI, CBN, SIA).
Document for: Approval.
Abstract: SID revision for postponed FS_GMEC SID - generic group management, exposure and communication enhancements, revision of postponed S2-2108163.

Comment:

Revision of (Postponed) S2-2108163 from S2#147E. CC#3: r09 was agreed. Revised to S2-2109355.

Discussion and conclusion:

CC#3: Huawei provided S2-2108574r09. Qualcomm asked how this interacted with the WID in S2-2108773. Nokia replied that there is some overlap for the Work Task 1 and they preferred to have a separate WID for the Work Task 1 part. Samsung reported that 15/18 participants in an off-line poll indicated handling these SIDs together. Ericsson preferred to separate out the WT1 topic. Huawei commented that the objections are not on the technical content and the majority of companies prefer to do this work together. S2-2108574r09 was agreed and was revised to S2-2109355.

e-mail discussion:

Antoine (Orange) provides r01.
Dieter (Deutsche Telekom) agrees with Orange's comment on WT1.2 and in addition comments.
Stefan (Ericsson) provides comments and questions
Qianghua (Huawei) replies
Sebastian (Qualcomm) provides revision in drafts folder
Rainer (Nokia) comments.
Qianghua (Huawei) provides r02 and responses
Rainer (Nokia) proposes updates to WT1.1 and WT1.2.
Stefan (Ericsson) provides replies
Qianghua (Huawei) provides r03 and responses
Qianghua (Huawei) provides r04
Sebastian (Qualcomm) provides r07 in drafts/GMEC
Rainer (Nokia) replies and prefers to split the SI in two parts.
Rainer (Nokia) replies, cannot accept removing of WT1.1 sub-bullet.
Stefan (Ericsson) also prefers separate studies on group management and traffic handling aspects, as was commented already last SA2 meeting
Qianghua (Huawei) replies and provide r05, and proposes that we follow the summary and way proposal resulting from MED progress
Sebastian (Qualcomm) replies to Nokia and Huawei
Qianghua (Huawei) provides r06
Sebastian (Qualcomm) comments on r05
==== Revisions Deadline ====
Rainer (Nokia) cannot accept r06.
Sebastian (Qualcomm) objects to any revision that includes the WT '- create/modify/delete groups for other purposes besides group communication' because there is nothing to be done except from some Edge scenario, which overlaps with a WT in the already approved Edge SID
Sang-Jun (Samsung) prefers not to split, and reminds Rainer (Nokia) that the MED already showed 15 of 18 companies prefer not to split.
Chi (China Unicom) prefers not to split as CUC has shown the opinion during the MED.
Heng (China Telecom) prefers not to split.
Wonjung (LG Uplus) prefers not to split.
Patrice (Huawei) comments regarding the relation with Edge computing ph2 work.
DongJin Lee (SK Telecom) prefers not to split.
Sebastian (Qualcomm) replies to Patrice; objects to r00-r06, provides r07 in drafts/GMEC
Stefan (Ericsson) comments again on WT#4 artificially restricted to 5G VN and provides update in DRAFTS
Qianghua (Huawei) provides r08draft in DRAFTS
Sebastian (Qualcomm) comments that r08draft in DRAFTS is ok
==== Comments Deadline ====
Qianghua (Huawei) provides r09 in DRAFTS, only change on r08draft is 'Enhance group attribute management'
Qianghua (Huawei) proposes to take r09 in DRAFTS in CC#2 for confirmation.

Status:

Revised to S2-2109355.

TD S2-2109355 (SID NEW) New SID on generic group management, exposure and communication enhancements.. (Source: Huawei, HiSilicon, Samsung, CATT, China Mobile, China Telecom, China Unicom, ZTE, Juniper, SK Telecom, KT Corp, LG Uplus, KPN, Siemens, Robert Bosch GmbH, LGE, Spreadtrum Communications, ETRI, CAICT, China Southern Power Grid, CEPRI, CBN, SIA, DISH Network, Volkswagen AG, Quectel).
Document for: Approval.
Abstract: SID revision for postponed FS_GMEC SID - generic group management, exposure and communication enhancements, revision of postponed S2-2108163.

Comment:

Revision of S2-2108574r09. Approved.

Discussion and conclusion:

-

Status:

Approved.

TD S2-2108575 (SID NEW) Study on Interworking of Non-3GPP Multicast and Broadcast Networks with 3GPP 5G System.. (Source: Saankhya Labs, Ligado Networks, ONE Media 3.0, Fraunhofer IIS, CEWiT, Tejas Networks, IIT Bombay, IIT Kanpur, IIT Madras, IIT Hyderabad, IIT Kharagpur).
Document for: Approval.
Abstract: Justification: The proliferation of mobile broadband networks is increasingly making the devices like smartphones as the preferred choice for content consumption. However, with the growth in content consumption, especially video consumption, via cellular networks, the load on available cellular spectrum has also increased leading to congestion in cellular networks. The non-3GPP satellite networks (NTN) and non-3GPP Digital Terrestrial Broadcasting Technology networks (DTT) might help in reducing the load on the cellular spectrum/network if some of the content delivery (video data) is offloaded onto them. This may efficiently be done through interworking or convergence of NTN and DTT networks with 5GS. Advantages of using Non-3GPP Satellite Broadcasting Technologies for Multicast/Broadcast delivery in 5GS - In 3GPP, the usage of NTN is already being considered as a means of providing coverage enhancement for terrestrial networks. They are being proposed to be used both for access as well as backhaul connectivity. - Services such as Firmware-Over-The-Air (FOTA) might be delivered very efficiently via satellite broadcast due to the pervasive coverage provided by them. The satellite-based delivery may be cost effective too. Apparently, there is no plan in 3GPP as yet to issue standards for satellite multicast/broadcast for services like FOTA until Release 3GPP 18. - Non-3GPP satellite multicast/broadcast systems (both open-standard and proprietary) have existed for some time, and it may not be necessary to wait for a 3GPP satellite broadcast system to be standardized in NTN, before other 5G 3GPP systems can roam to them. 3GPP can play an enabling role in the process (of standardization) by standardizing the roaming interfaces while remaining agnostic towards the air interface. Advantages of using Non-3GPP Digital Terrestrial Broadcasting Technologies (DTT) - They also provide support for large coverage areas, which might be quite useful for service delivery in rural areas and sparsely populated areas. - Many of the Non-3GPP DTTs provide high spectral efficiency supporting higher order modulation and coding schemes, e.g., Advanced Television Systems Committee 3.0 (ATSC3) standard supports 1024-QAM. - Improved mobility handling due to support for large coverage areas and SFNs Convergence of Cellular and Non-3GPP Digital Terrestrial Broadcast Network (DTT)/Non-3GPP Satellite Broadcasting Technologies would - Reduce load on Cellular Network through efficient offloading - Enable creation of 'best connected' hybrid broadcast network. Higher throughput payload could be broadcast over terrestrial networks and lower throughput, but critical payloads broadcast over the satellite network. - Enhance the device ecosystems of both cellular and broadcast networks by leveraging the scales of cellular devices - Improve resource utilization across non-3GPP NTN/DTT and 3GPP 5G NG-RAN - Open up new business opportunities through interfacing of 5GS with the legacy and new broadcasting networks. As an example, ATSC3 is deployed in USA, Korea & DVB-T2 is deployed in 144 countries world-wide. There can be improved monetization of these networks through convergence with 5GS. - The 5G system architecture has already been defined with a converged core network integrating non-3GPP access networks such as WLANs and wireline access for unicast communication. It may therefore be appropriate to extend this capability to wide area multicast/broadcast communication too, including satellite networks, and integrate the non-3GPP multicast and broadcast networks within the 5G system.

Comment:

Revision of (Postponed) S2-2107129 from S2#147E. CC#3: Noted.

Discussion and conclusion:

CC#3: Saankhya Labs provided S2-2108575r03 and reported that there were objections to this and asked for the reasons for the objections. Nokia questioned the requirements behind this WID and added that the objectives are unclear and objected to this. Ligado commented that there are already a number of non-3GPP deployments and considered this interworking important. Ericsson agreed with Nokia that the formulation of the objectives is unclear and added that there are a number of technologies which do not require MBS and a SID should not be defined only to do a Gap analysis. Qualcomm sustained their objection. IIT Bombay commented that the study would allow non-3GPP Satellite access to interwork with 5MBS and believed the requirements can be extracted from TS 22.261. Saankhya Labs agreed to take this into SA WG1 to clarify the requirements. This was then noted.

e-mail discussion:

Antoine (Orange) asks what kind of impacts to UICC apps are envisionned.
Anindya Saha (SaankhyaLabs) responds to the Question on 'Elaboration of what kind of impacts to UICC apps are envisioned?'
Miguel (Qualcomm) has concerns with this SID, that the service requirements are not clear, there is no SA1 related work.
Stefan (Ericsson) comments that stage 1 requirements are missing
Dieter (Deutsche Telekom) we share the concerns expressed by Qualcomm and Ericsson.
Thomas (Nokia) also shares the concerns expressed by Qualcomm and Ericsson.
Comments that objectives read like TR working procedures and would also require improvements
First objective reads like stage 1 work
Wanqiang (Huawei) shares the same concern, and on this non-3GPP multicast and broadcast integration to 5GC, we need more broad requirement level discussion first to consolidate what 3GPP can offer.
Anindya Saha (SaankhyaLabs) responds to the concerns raised by Stefan (Ericsson), Miguel (Qualcomm), Dieter (Deutsche Telekom), Thomas (Nokia) and Wanqiang (Huawei).
==== Revisions Deadline ====
Anindya Saha (SaankhyaLabs) observes that the requirements and use cases for multicast/broadcast services as captured in 3GPP stage 1 document TS 22.261, TS 22.101, and TS 22.246 already allow for Interworking of non-3GPP satellite networks and non-3GPP DTT networks with 5GS.
Miguel (Qualcomm) objects to this SID
Stefan (Ericsson) objects to SID and restates concerns
Anindya Saha (SaankhyaLabs) seeks detailed clarifications to the objections from Miguel (Qualcomm), and Stefan (Ericsson) citing sections from as captured in 3GPP stage 1 documents TS 22.261 which clearly mention non-3GPP Access for Satellite Communication.
Dieter (Deutsche Telekom) objects to SID and replies to Anindya Saha (SaankhyaLabs).
Clive Packer, Ligado Networks
Services such as Firmware-Over-The-Air (FOTA) might be delivered very efficiently via satellite broadcast due to the pervasive coverage provided by it. Another example of a service that may be considered part of critical infrastructure is satellite delivery of augmentation services for high precision GNSS; this is already part of the planning for automated driving in the future. Multimode, satellite-terrestrial delivery of such services is likely to optimize both the cost and the geographic coverage of such services. Apparently, there is no plan in 3GPP as yet to issue standards for satellite multicast/broadcast over NBIoT and eMTC air interfaces until Release 3GPP 18. Until such services are launched, FOTA & GNSS augmentation (mentioned as examples) could be carried over a multimode 3GPP-cellular/non-3GPP-satellite broadcast network, at least as a gap filler. Therefore, it would be helpful for 3GPP to enable the proposed work.
Anindya Saha (SaankhyaLabs) responds to objections raised by Dieter (Deutsche Telekom) and observes that the TS22.261 (3GPP Stage 1 Requirements) has been misunderstood with respect to the proposed SID objectives.
==== Comments Deadline ====
Pranav (IIT Bombay) supports the SID and replies to Dieter (Deutsche
Telekom)
Anindya Saha (SaankhyaLabs) provides a revision r01 of the SID based on the comments received.
Anindya Saha (SaankhyaLabs) provides a revision r02 of the SID and seeks feedback.
Anindya Saha (SaankhyaLabs) provides a revision r03 of the SID and seeks feedback.

Status:

Noted.

TD S2-2108594 (SID NEW) New Study on enhancement of support for Separation and Isolation of NF and data in 5GC.. (Source: China Telecom).
Document for: Approval.
Abstract: Objective: The study item will study (Investigate the key issues and corresponding solutions) the potential enhancements for separation and isolation of NF and data in 5GC, including: Objectives: for case 1: WT#1. Whether and how to support the indirect communication between the operator's network and the vertical which contains dedicated AMF, SMF and UPF. WT#1.1. Whether and how the NFs register to the NRF deployed at the operator's network through the NF which is used to isolate NFs deployed at the operator's network and NFs deployed at the vertical, when NFs deployed at the vertical are invisible to the operator's network. WT#1.2. How the NF, which is used to isolate the vertical and operator's network, identify and decide which signaling should be forwarded to NFs located at which network, especially when the NF is used to communicate with multiple vertical. Objectives: for case 2: WT#2. Whether and how to support scenarios where UDM of operator's network is only used to authenticate users of the vertical and UDM of the vertical to authorize service usage. WT#2.1 How the UDM deployed at vertical knows that the enterprise's UEs can be authorized to obtain subscription data from UDM deployed at vertical after enterprise' UEs being authenticated through the AUSF and UDM located in the operator's network. WT#2.2 How to support new vertical UEs to register with the vertical when the NFs deployed at the vertical failed to communicate with the NFs located at the operator's network.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Haris(Qualcomm) comments that the scope of this SID remains unclear and provides justification
Rainer (Nokia) comments, asking for clarification.
Yubing (China Telecom) replies to Haris (Qualcomm), Rainer (Nokia) and provides r01.
Saso (Intel) thinks that this proposal should be considered for SA3.
Saso (Intel) objects to this SID.
Rainer (Nokia) agrees with Intel to note the SI.
Yubing (China Telecom) replies to Saso (Intel).
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108609 (SID NEW) Study on Enhancement of Network Slicing Phase 3 .. (Source: ZTE, LG Electronics, Samsung, Alibaba, Apple, AT&T, CATT, China Telecom, China Unicom, Convida Wireless LLC, Ericsson, Intel, InterDigital, KDDI, Lenovo, Matrixx, MITRE, Motorola Mobility, NEC , Nokia, Nokia Shanghai Bell , NTT Docomo, OPPO, Oracle, Orang).
Document for: Approval.
Abstract: Propose new study on network slicing in Rel-18.

Comment:

CC#3: r13 endorsed. Revised to S2-2109356.

Discussion and conclusion:

CC#3: ZTE provided S2-2108609r12. There were issues around bullets 5a and 5b. The majority appeared to prefer 5a. Huawei suggested removing bullet 5 completely. Nokia commented that the limitation of using NSAC should not be included in the objectives of a SID. Ericsson agreed with Nokia. Huawei objected to including bullet 5. The SA WG2 Chair asked if there were objections with removal of bullet 5. Verizon objected to the removal of bullet 5.
Support for objective 5: 17
Objection: 1
Huawei repeated that there is no justification provided for including bullet 5 and there is no indication of the problem that needs to be solved and provides a solution rather than a study of a problem. ZTE suggested adding a note (FFS) and holding a CC before TSG SA to try to resolve this issue. S2-2108609r13 was endorsed and revised in S2-2109356.

e-mail discussion:

Antoine (Orange): Obj. 7 needs to be clarified .
Jinguo (ZTE) response and provides r01
Patrice (Huawei) comments on the updated r01, with the following considerations. We can likely accept WT1 with some refinements, we object to WT4.2 as it is irrealistic as proposed. We object to WT5 as the (unclear) justification requires either GSMA input, SA1 requirements, or should be done in eUEPO. We have concerns with WT7, especially the lack of SA1 service requirements, and the current WT7 could be acceptable if the additional SA1 requirements can be clearly identified. Further minor updates are indicated in the comments.
Myungjune (LGE) replies to Patrice (Huawei) on WT7
Alessio(Nokia) supports the r01 by Jinguo with small changes
Kundan (NEC) does not support 4.2 in r01which has lot of system/RAN impact.
alessio(Nokia) comments
Kundan (NEC) responds to Alessio
alessio(Nokia) comments this will need to work only for UEs that are capable of simultaneous registrations.. i.e. with dual RX/TX.
Srisakul (NTT DOCOMO) comments and suggests some minor change in WT1.
Jinguo(ZTE) response
Patrice (Huawei) thanks Myungjune for his clarification and proposes an update to WT7 accordingly.
Patrice (Huawei) comments on Jinguo (ZTE)'s rewording.
Jinguo(ZTE) provides r02.
Ashok (Samsung) comments on WT1
Peter Hedman (Ericsson) provides comments.
Alessio(Nokia) supports the wording and comments by Peter(ericsson)
Jinguo(ZTE) provides r03
Chia-Lin (MediaTek) provides the comments and ask to remove Obj. 7.
alessio(Nokia) cannot live with removal of 4.2
Jinguo(ZTE) response and think WT4.2 is out of scope this study.
Genadi (Lenovo) comments on WT1 in r03.
Patrice (Huawei) thanks Jinguo (ZTE) for the update, which is mostly fine except that objective 5 needs to be removed.
Jinguo(ZTE) replies to Genadi (Lenovo).
Dieter (Deutsche Telekom) asks questions for clarification on objective 1.
Patrice (Huawei) comments, confirms his objection to any version of the SID that includes WT4.2 in one form or another.
Jinguo(ZTE) replies to Dieter (Deutsche Telekom)
Myungjune (LGE) replies to Chia-Lin (MediaTek).
Jinguo (ZTE) replies to Chia-Lin (MediaTek).
Dongeun (Samsung) supports Obj5 provided by Peter (Ericsson)
Jinguo(ZTE) provides r04
Patrice (Huawei) objects all revisions so far including r04, due to the presence of WT5. This includes objection to technical endorsement. Once WT5 is removed, barring other changes, we will support the SID.
==== Revisions Deadline ====
Alessio(Nokia comments)
Jinguo(ZTE) asks for CC#2 or CC#3. Lets see if we can agree the wording in obj 5.
Chia-Lin (MediaTek) provides comments
Jinguo(ZTE) provides r05 in draft folder, and replies to Chia-Lin (MediaTek)
Chia-Lin (MediaTek) still think Ojb.7 should have nothing to do with the UE and should be removed
Jinguo(ZTE) replies to Chia-Lin (MediaTek)
Chia-Lin (MediaTek) replies
alessio(Nokia) would certainly like this 'by the UE' bit to be removed.
Myungjune (LGE) replies to Chia-Lin (MediaTek) and Alessio (Nokia)
Patrice (Huawei) requests that WT7 is left as is (i.e. keep the 'by the UE'), as it is what answers the SA1 requirement with the clarification from Myungjune (LGE).
Chia-Lin (MediaTek) provides more comments and insists to remove Obj. 7
Patrice (Huawei) proposes further minimal rewording on WT5 to make it acceptable.
Chia-Lin (MediaTek) responds to Myungjune (LGE)
Jinguo(ZTE) provides r06 in draft folder
Chia-Lin (MediaTek) responds to Myungjune(LGE) and considers Obj. 7 is not needed as explained below
Myungjune(LGE) responds to Chia-Lin (MediaTek)
alessio(Nokia) proposes we discuss on CC#2 the latest version of the SID by Jinguo.
Patrice (Huawei) comments, and cannot accept WT7 wording in latest versions, questions the 'e.g.' in WT5. I am still looking for a revision that I can accept (none so far are acceptable).
Jinguo(ZTE) provides r07 in draft folder
Dieter (Deutsche Telekom) support removing WT7.
Patrice (Huawei) thanks Jinguo (ZTE) for r07, is OK with r07, and would like to add Huawei and HiSilicon to this version.
Peter Hedman (Ericsson) Support r05 and objects to r07, r06 and any revision with objective 5 restricted to NSAC
Patrice (Huawei) (for the records) objects to all versions except r07.
Guillaume (MediaTek) responds to Myungjune (LGE)
Jinguo (ZTE) provides r08 and clarifies that solutions for obj5 may also be workable for other scenarios.
Patrice (Huawei) cannot accept r08, as we don't know what we are going to study now in obj5.
Dieter (Deutsche Telekom) supports removing WT5.
==== Comments Deadline ====
Alessio(Nokia) Support r05 but cannot live with an objective that is just NSAC oriented as the operator wants to control the UE behaviour irrespective of that (i.e. also in networks without NSAC).
Gerry Libunao (Verizon) supports r05 and objects to r07, r06 and any revision with objective 5 restricted to NSAC.
Jinguo(ZTE) propose a way forward on obj 5
alessio(Nokia) comments that bj5 should be reinstated like it was in the MED. it is not possible to keep churning things like it has been done. it was very clear the goal was controlling the UE behaviour in registration and PDU session establishment. this received wide support. we can now check who object on the call and who supports that one..
Peter Hedman (Ericsson) provides comments and proposal for objective 5
Jarmo (KPN) would like to support the study.

Status:

Revised to S2-2109356.

TD S2-2109356 (SID NEW) Study on Enhancement of Network Slicing Phase 3 .. (Source: ZTE, LG Electronics, Samsung, Alibaba, Apple, AT&T, CATT, China Telecom, China Unicom, Convida Wireless LLC, Ericsson, Intel, InterDigital, KDDI, Lenovo, Matrixx, MITRE, Motorola Mobility, NEC , Nokia, Nokia Shanghai Bell , NTT Docomo, OPPO, Oracle, Orange, Qualcomm, Sanechips, Sharp, T-Mobile USA, Spreadtrum, Tencent, Verizon UK Ltd, Xiaomi).
Document for: Approval.
Abstract: Propose new study on network slicing in Rel-18.

Comment:

Revision of S2-2108609r13. CC#3: Technically Endorsed with an objection from Huawei.

Discussion and conclusion:

Technically Endorsed with an objection from Huawei. This will not be submitted by MCC to TSG SA, but will be included in the list from the SA WG2 Chair for the prioritization list.
Huawei provided the following text for this report:
Huawei objects to the approval and to the technical endorsement of S2-2109356, due to the inclusion of a version of objective WT5 (now renumbered as objective 4) that, even after many rounds of discussions, does not have any viable justification or service requirements associated with it. It is using as sole justification the idea that an incorrect perception of what the NSAC feature measures would require changes unrelated to NSAC, and rejects solutions with impacts limited to NSAC. It then extends this limited justification to 'other scenarios' without bothering to try and list a sensible list of scenarios to address. It requires changes to 5GS principles established since Rel-15 regarding UE MM and SM without any clarification as to what is missing in Rel-15~17 existing features, nor any explanation as to which scenarios are being targeted, nor what is expected to achieve by studying solutions. The objective describes a solution in search of a problem, and the current wording ensures that lengthy discussions will take place during the study with a lack of ability to reach consensus, since there will be no possibility to evaluate solutions according to the non-existing problem. Huawei has engaged in deep discussions around this topic, and seen no attempt from other parties except from the rapporteur to try and address the concerns. Huawei would have approved and supported a version of S2-2109356 without WT5 (now objective 4), or with a wording better scoped to solve the perception problem described as the justification. Huawei will propose and discuss possible revisions to objective 4 so that we can avoid a detrimental objection of eNS in TSG SA#94.

Status:

Endorsed.

TD S2-2108611 (REPORT) Summary of Email discussion on FS_eNS_Ph3. (Source: ZTE(rapporteur)).
Document for: Information.
Abstract: Summary of Email discussion on FS_eNS_Ph3.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108619 (DISCUSSION) Motivation of supporting UPF on-board. (Source: CATT).
Document for: Endorsement.
Abstract: This paper discusses the need of supporting UPF on-board.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Hannu (Nokia) proposes to note the discussion paper and comments on the contents.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108658 (DISCUSSION) E-mail discussion on Personal IoT Network (PIN).. (Source: Zhenhua Xie / vivo).
Document for: Information.
Abstract: Report on e-mail discussion on Personal IoT Network (PIN).

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Laurent (Nokia): proposes to Note this discussion paper (objects to any of version of this Tdoc) and to concentrate on the SID discussion
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108659 (DISCUSSION) Updated discussion on SID of Personal IoT Network architecture. (Source: vivo).
Document for: Information.
Abstract: Updated discussion on SID of Personal IoT Network architecture.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Laurent (Nokia): proposes to Note this discussion paper (objects to any of version of this Tdoc) and to concentrate on the SID discussion
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108660 (SID NEW) New SID on Personal IoT Network architecture.. (Source: Vivo Mobile Communications Ltd, CATT, China Telecom, Convida Wireless, InterDigital, KPN, OPPO, Philips, Spreadtrum Communications, T-Mobile USA, Tencent).
Document for: Approval.
Abstract: Objective: The objectives of this SA WG2 study are to study how 5G System architecture can be enhanced to support Personal IoT Network (PIN) that has been studied by SA WG1 in TR 22.859 with requirements captured in 3GPP TS 22.261.

Comment:

CC#3: r14 agreed. Revised to S2-2109357.

Discussion and conclusion:

CC#3: Vivo provided S2-2108660r13. Nokia asked where the listed stage 1 requirements are to be found. Vivo replied that there is a SA WG1 Study on this. Orange asked for clarification on the link to NPN. Vivo replied that there was a request to take the onboarding study into account and NPN is therefore considered a related Study for WT2. Ericsson asked whether this is the Rel-17 Phase 2 WI or the Rel-18 SID at this meeting. Vivo agreed to remove this from related WIs. This was updated in r14. S2-2108660r14 was agreed and was revised in S2-2109357.

e-mail discussion:

Antoine (Orange) comments on WT#2.
Zhenhua (vivo) responds to Antoine (Orange) and provides r01.
Laurent (Nokia): Comments and suggests some changes
Sherry (Xiaomi) Comments.
Stefan (Ericsson) comments
Guliang (Inspur) support this SID and would like to co-source the SID.
Laurent (Nokia): suggests a revision with only WT1, WT2, and WT3 and Neither WT4 nor WT5 (as in the S2-2108660-SID-PIN - Nokia version put in /drafts)
Zhenhua (vivo) provides r02
Zhenhua (vivo) asks Laurent (Nokia) whether r02 is OK, which removed WT5
Antoine (Orange) requests further edition of WT#2.1.
Amanda ( Futurewei ): provide r03 to add identifying PIN in WT#1.2 and WT#2.1
Zhenhua (vivo) provide r04
Zhenhua (vivo) provides r05 to add more supporter and co-source.
Zhenhua (vivo) provides r06
Zhenhua (vivo) provides r07 to correct the dependency in TU estimates.
Walter Dees (Philips) does not agree with the sentence that no changes to ProSe and non-3GPP access can be assumed, and proposes revision r08.
Laurent (Nokia): Zhenhua do you endorse this r08? asks also a question to Walter
Walter (Philips) apologizes for sending the revision r08 instead of a company revision
Hualin(Huawei) disagree with Walter (Philips)'s comments.
Zhenhua (vivo): Clarified r08 is not provided by rapporteur, and responds.
Sherry(Xiaomi) comments.
==== Revisions Deadline ====
Walter (Philips) responds to Hualin (Huawei) and Sherry(Xiaomi).
Zhenhua (vivo) provides r09 in draft folder based on r07 to only add new supporter and co-source company.
Laurent (Nokia): Comments: What is problematic is NOTE 1
Zhenhua (vivo) replies to Laurent (Nokia)
Walter Dees (Philips) cannot agree with revisions r02, r03, r04, r05, r06, r07 and r09 if the last sentence in the second to last NOTE is not removed or updated. Propose to discuss in CC#3 unless some agreement can be reached beforehand.
Zhenhua (vivo) thanks Walter (Philips) to provides suggestion on the NOTE modification.
Hualin(Huawei) can't agree the revised NOTE.
Laurent (Nokia): objects to any version between R00 and R05 both included. Can live with R06/R07 but wants first Note 1 to be clean and then to have a look at the TU numbers that heavily depend on Note 1. If ProSe WT about non 3GPP support is agreed, reusing ProSe solution is Mandatory
Hong (Qualcomm) comments.
Hualin(Huawei) support the way proposed by Nokia
Sherry(Xiaomi) supports the way forward proposed by Laurent.
==== Comments Deadline ====
Zhenhua (vivo) provides a wording proposal for the NOTE.
Zhenhua (vivo) provides r10 in CC#2 folder.
Hong (Qualcomm) propose some new wording for the NOTE.
Zhenhua (vivo) provides r11 in CC#2 folder to adopt wording to the NOTE proposed by Hong (Qualcomm).
Walter Dees (Philips) proposes a change to the wording of the NOTE.
Sherry (Xiaomi) is fine with Hong's wording and Walter's proposal to the NOTE.
Zhenhua (vivo) provides r12 in CC#3 folder.
Zhenhua (vivo) provides r13 in CC#3 folder.

Status:

Revised to S2-2109357.

TD S2-2109357 (SID NEW) New SID on Personal IoT Network architecture.. (Source: Vivo Mobile Communications Co. Ltd, CATT, China Mobile, China Telecom, Convida Wireless, InterDigital, KPN, OPPO, Philips, Spreadtrum Communications, T-Mobile USA, Tencent, Futurewei, Xiaomi, Inspur, Guangdong Genius, Apple).
Document for: Approval.
Abstract: Objective: The objectives of this SA WG2 study are to study how 5G System architecture can be enhanced to support Personal IoT Network (PIN) that has been studied by SA WG1 in TR 22.859 with requirements captured in 3GPP TS 22.261.

Comment:

Revision of S2-2108660r14. Approved.

Discussion and conclusion:

-

Status:

Approved.

TD S2-2108661 (DISCUSSION) Updated discussion on SID of UE Aggregation for Industry with Multi-connectivity. (Source: vivo).
Document for: Information.
Abstract: Updated discussion on SID of UE Aggregation for Industry with Multi-connectivity.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108662 (SID NEW) New SID on UE Aggregation for Industry with Multi-connectivity.. (Source: Vivo Mobile Communications Ltd, China Telecom, China Unicom, CATT, Spreadtrum Communications).
Document for: Approval.
Abstract: Objective: The objectives of this SA WG2 study is to investigate how the 5G CN can be enhanced to support UE aggregation for uplink aggregation and fast switching: - (WT#1) Support of management and authorization for UE aggregation. - (WT#2) Support of policy enforcement for binding multiple UEs, e.g., load balance, standby, etc.; - (WT#3) When redundancy for an application session is supported with two UE(s), support of status report for fast switching to UE backup when connection with a UE fails; NOTE: Coordination with RAN WGs for assisting RAN solution if RAN based solution is selected.

Comment:

CC#3: Noted.

Discussion and conclusion:

CC#3: Vivo provided S2-2108662r03. Vivo reported that there were objections to including some WTs. This was then noted.

e-mail discussion:

LaeYoung (LGE) asks a Q for clarification.
Qian (LGE) provides comments.
LaeYoung (LGE) just wants to clarify that Qian is not from LGE but from Ericsson. ^__^
Qian (Ericsson) re-sends the mail to indication the source company is 'Ericsson' (Copy/Paste mistake).
Haris(Qualcomm) proposes revision in DRAFTS folder
Saso (Intel) seeks clarification.
Saso (Intel) provides additional comment.
Antoine (Orange) comments.
Devaki (Nokia) provides _revNokia (on top of _revQC). Devaki requests to ignore r01 as it was provided by mistake. We are also supportive of 5GC based solution to be studied (without impacting RAN for UE aggr) in Rel-18.
Fei (OPPO) comments.
Zhenhua (vivo) responds
Zhenhua (vivo) responds to Qian (Ericsson).
Dieter (Deutsche Telekom) has strong concerns with the proposal.
Marco (Huawei) objects to the new WT addition.
Haris(Qualcomm) asks question to Marco (Huawei)
Zhenhua (vivo) provides r02
Qian (Ericsson) comments and expresses concerns
Guillaume (MediaTek Inc.) comments
Marco (Huawei) replies to Haris (Qualcomm)
Haris(Qualcomm) comments
Saso (Intel) objects to this SID.
Jinsook (DISH Network) comments
Marco (Huawei) comments
Zhenhua (vivo) provides r03
Zhenhua (vivo) replies
==== Revisions Deadline ====
Jinsook (DISH Network) as a clarification
Saso (Intel) replies.
Devaki (Nokia) objects to all the SID versions (as long as RAN impact is ticked). As commented earlier, we are ok with studying system solutions for the objectives proposed but not ok with RAN impact.
Zhenhua (vivo) replies to Jinsook (DISH Network)
Zhenhua (vivo) replies to Saso (Intel).
LaeYoung (LGE) proposes to NOTE this SID and objects to all versions.
Dieter (Deutsche Telekom) objects to this SID as per previous comments.
Marco (Huawei) objects to r02 and r03 as per previous comments.
Saso (Intel) replies to Zhenhua (vivo).
Haris(Qualcomm) objects to r03
Antoine (Orange) objects to r02.
==== Comments Deadline ====
Devaki (Nokia) can also accept r02 (removing RAN impact or at least marking it as don't know).

Status:

Noted.

TD S2-2108671 (SID NEW) New SID: Architectural enhancements for 5G multicast-broadcast services Phase 2.. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: This contribution proposes to continue the work of 5MBS in rel-18.

Comment:

Revision of (Postponed) S2-2107550 from S2#147E. CC#3: r10 agreed. Revised to S2-2109362.

Discussion and conclusion:

CC#3: Huawei provided S2-2108671r06. Huawei asked for comments on whether the highlighted text is acceptable (WT 1.3). Vodafone asked to add the meaning of FTA (Free To Air). Ericsson raised issues on their proposal to add a WT 4.3 which is important for Public Safety. Orange maintained their objection to WT 1.3.
Objection to including WT 1.3: 3
WT1.3 should be removed.
WT#4.3 Taking into account RAN WG's progress in Rel-17, study whether and how to further optimize on the resource usage without mandating PDU session UP resource only for the purpose of receiving multicast MBS session data.
NOTE Y: This WT can be skipped if the corresponding aspect is addressed in Rel-17.
Ericsson commented that the companies indicating an issue with WT 4.3 appeared to be misunderstanding the meaning rather than to including Public Safety requirements and if no reason is found in the study to include such functionality then it will not move forward to normative work. Nokia objected to 4.3, but clarified that they were not against Public Safety coverage, but did not think this bullet would cover the needs and suggested instead adding a more relevant WT. It was suggested to add a WT 5 for the collaboration with SA WG6 on Public Safety aspects.
WT#5: Study in collaboration with SA6 whether any improvements are required for high number of public safety UEs
Huawei updated the SID accordingly in S2-2108671r10. This modified WT#5 wording. S2-2108671r10 was agreed and revised to S2-2109362.

e-mail discussion:

Antoine (Orange) objects to WT 1.3.
Dieter (Deutsche Telekom) objects to WT1.3.
Robbie (Ericsson) provides r00-Ericsson in DRAFTS folder.
Miguel (Qualcomm) objects to WT 1.3, still has concerns with WT 1.2.
Thomas (Nokia) comments against changes suggested by Robbie.
Thomas (Nokia) points to requirements for WT 1.2 and WT 1.3 in TS 22.101
Miguel (Qualcomm) responds to Thomas, the referenced requirements do not apply
Dieter (Deutsche Telekom) answers to Thomas.
LiMeng (Huawei) answers and clarifies.
LaeYoung (LGE) provides comment while pointing out that LiMeng (Huawei) provided r01 previously.
Robbie (Ericsson) disagree with Thomas (Nokia) and also asks whether 8:5 is a clear majority.
Zhenhua (vivo) questions on TU of WT2, and suggest to split WT4.
Robbie (Ericsson) provides r01-Ericsson in DRAFTS folder, reinstate WT#4.3 which is important for public safety use cases, and asks why this valid requirement is removed
Zhuoyi (China Telecom) supports the SID and would like to co-source it.
Kaixin (CBN) answers to Antoine and Dieter.
LaeYoung (LGE) asks a Q to Kaixin (CBN).
Sherry (Xiaomi) provides a revision on top of r01-Ericsson in DRAFTS folder
Kaixin (CBN) answers to LaeYoung.
Dieter (Deutsche Telekom) answers Kaixin(CBN).
Wanqiang (Huawei) comments.
LaeYoung (LGE) thanks to Kaixin (CBN).
Relja (TNO) supports this SID and would like to be added to the list of supporting companies. Some comments are also provided.
LiMeng (Huawei) thanks for sharing the views and provides r02 and r03.
==== Revisions Deadline ====
Robbie (Ericsson) reiterates that WT#4.3 is important for public safety, which is also shown in MED. As such, propose to be included in the SID.
Miguel (Qualcomm) objects to r02 and any revision with WT 1.3.
Thomas(Nokia) supports r02.
Relja(TNO) supports r02.
Robbie (Ericsson) provides r02-Ericsson and r03-Ericsson in DRAFTS folder, reinstate WT#4.3 on top of r02 and r03 provided by Rapporteur. We believe this WT is important for scalability of MBS and building more complex features on top of Rel-17 architecture.
Antoine (Orange) objects r00, r01 and r02.
Ihab (FirstNet) We support Ericsson and we would like to see WT#4.3 in the scope of the WID since it is important for public safety.
Miguel (Qualcomm) objects to r03, due to the addition of this statement in Justification 'In addition, the FTA-type data reception (i.e., broadcast reception by devices with no subscription or with 3rd party content provider subscription only) for NR can be supported in Rel-17 by configuring reception information at UE side.' We can accept r03 if that sentence is removed.
James (AT&T) supports Ericsson and FirstNet to include WT#4.3 in the scope of the WID since it is important for public safety.
Thomas(Nokia) has concerns about extra objective suggested by Robbie.
Reminds Robbie of the results of moderated email discussion and that we are already above the time budget,
LiMeng (Huawei) provides r04 with removing the sentence highlighted by Miguel, and asks to check r02 and r04 in CC#2.
Robbie (Ericsson) objects to all revisions without WT#4.3.
Dieter (Deutsche Telekom) we also insist on removing the sentence highlighted by Miguel.
Zhendong (ZTE): r02 is better
==== Comments Deadline ====.

Status:

Revised to S2-2109362.

TD S2-2109362 (SID NEW) New SID: Architectural enhancements for 5G multicast-broadcast services Phase 2.. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: This contribution proposes to continue the work of 5MBS in rel-18.

Comment:

Revision of S2-2108671r10. Approved.

Discussion and conclusion:

-

Status:

Approved.

TD S2-2108692 (DISCUSSION) Discussion about Uu based sensing. (Source: vivo).
Document for: Information.
Abstract: Open discussion about Uu based sensing.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108760 (SID NEW) Study on Passive Internet of Things (Passive IoT) for 5G Advanced .. (Source: China Mobile, Spreadtrum Communications, Huawei, HiSilicon, China Telecom, China Unicom, CATT, Tencent, vivo, Quanray, NTT DOCOMO, Vodafone, Alibaba, CAICT).
Document for: Approval.
Abstract: R18 Passive IoT SID is proposed.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Chunhui (Spreadtrum) provides the revision(r01) with 2 additional supporting companies.
Hannu (Nokia) comments that since the corresponding SA1 SID is not approved and it's targeting Rel-19, it is not possible to plan the SA2 work in Rel-18.
LaeYoung (LGE) proposes to NOTE this SID because she believes that use cases, scenarios, service requirements and performance requirements need to be identified in SA1 first. This will be able to put the studies in downstream groups in the right direction.
Leo (Deutsche Telekom) objects this SID for SA2 in Rel-18.
Hannu (Nokia) supports the proposal to note this SID in Rel-18 due to lack of service requirements.
Saad (Interdigital) proposes to note this SID.
Miguel (Qualcomm) proposes to NOTE this SID proposal, in favor of a proper study in SA1
Guillaume (MediaTek Inc.) provides comments.
Chunhui(Spreadtrum) replies Guillaume (MediaTek Inc.)'s comments.
Chunhui(Spreadtrum) replies LaeYoung (LGE)'s comments.
LaeYoung (LGE) does not get the answer from Chunhui (Spreadtrum).
Chunhui (Spreadtrum) answers LaeYoung (LGE).
LaeYoung (LGE) responds to Chunhui (Spreadtrum).
Guillaume (MediaTek Inc.) responds.
Chunhui(Spreadtrum) responds to Guillaume (MediaTek Inc.).
==== Revisions Deadline ====
Miguel (Qualcomm) objects to this SID in all revisions.
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108766 (SID NEW) New SID: Study on Seamless UE context recovery.. (Source: Samsung, NEC, CableLabs, Cisco, InterDigital Inc.).
Document for: Approval.
Abstract: Objective: Following objectives are expected to be studied: 1) Objective: 1 (WT#1): Study whether it is feasible to define mechanisms where the UE is unavailable but UEs contexts at both UE and network side (e.g AMF, SMF(s)) are maintained (i.e. UE remains in Registered state and PDU Sessions are preserved), minimizing upper layer service interruptions for cases where UE's context is not (or partially) maintained in today's implementations. 2) Objective: 2 (WT#2): Study the possibility an 'unavailability period' is determined for the UE. NOTE 1: Example cases in which UEs context is not (or partially) maintained in today's implementation is listed in justification section. The handling of Network initiated deregistration and SIM swapping are not impacted by this Study Item.

Comment:

Revision of (Postponed) S2-2107383 from S2#147E. r01 agreed. Revised to S2-2109324.

Discussion and conclusion:

-

e-mail discussion:

Haris(Qualcomm) comments
Laurent (Nokia): Comments
Lalith(Samsung) agrees with Haris and Laurent and provides r01
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109324.

TD S2-2109324 (SID NEW) New SID: Study on Seamless UE context recovery.. (Source: Samsung, NEC, CableLabs, Cisco, InterDigital Inc.).
Document for: Approval.
Abstract: Objective: Following objectives are expected to be studied: 1) Objective: 1 (WT#1): Study whether it is feasible to define mechanisms where the UE is unavailable but UEs contexts at both UE and network side (e.g AMF, SMF(s)) are maintained (i.e. UE remains in Registered state and PDU Sessions are preserved), minimizing upper layer service interruptions for cases where UE's context is not (or partially) maintained in today's implementations. 2) Objective: 2 (WT#2): Study the possibility an 'unavailability period' is determined for the UE. NOTE 1: Example cases in which UEs context is not (or partially) maintained in today's implementation is listed in justification section. The handling of Network initiated deregistration and SIM swapping are not impacted by this Study Item.

Comment:

Revision of S2-2108766r01. Approved.

Discussion and conclusion:

-

Status:

Approved.

TD S2-2108768 (OTHER) Email discussion on Passive IoT SID.. (Source: China Mobile, Spreadtrum Communications).
Document for: Information.
Abstract: The Pre SA WG2#148E Email Discussion summary for Passive IoT is submitted.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Hannu (Nokia) comments that the proposed way forward is not acceptable as it does not reflect the outcome of the moderated email discussion.
Miguel (Qualcomm) fully agrees with Hannu (Nokia) that the moderator proposed way forward does not reflect the company positions expressed in the MED, and cannot accept proposed way froward.
Guillaume (MediaTek Inc.) proposes to just note this document and not to endorse the WF proposals
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108769 (SID NEW) New SID on 5G Architecture enhancements for Harmonized Communication and Sensing service.. (Source: Huawei, HiSilicon, vivo, CAICT, China Unicom, China Mobile, China Telecom, CATT, ZTE, OPPO, ROBERT BOSCH GmbH, NTT DOCOMO, TCL, Philips, Xiaomi, Lenovo, China Security and Protection Industry Association).
Document for: Approval.
Abstract: New SID on 5G Architecture enhancements for Harmonized Communication and Sensing service.

Comment:

Revision of (Postponed) S2-2107636 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

Antoine (Orange) asks clarification about RAN impacts.
Wanqiang (Huawei) feedback and clarify the way how to decouple from the RAN1/2 work.
Leo (Deutsche Telekom) objects to all versions/revisions of the SID.
LaeYoung (LGE) proposes to NOTE this SID because she believes that use cases, scenarios, service requirements and performance requirements need to be identified in SA1 first. This will be able to put the studies in downstream groups in the right direction.
Hong (Qualcomm) comments about the RAN dependency.
Shabnam (Ericsson) sharing same concerns as given before, as well we do not see what only CN based sensing architecture study would benefit without actual service requirements. As such, objects to the study proposal in Rel-18.
Guillaume (MediaTek Inc.) comments
Saso (Intel) maintains the same position of previous meeting and proposes to note this SID.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108770 (DISCUSSION) Moderated email discussion summary on FS_HCS.. (Source: Huawei (moderator)).
Document for: Information.
Abstract: Moderated email discussion summary on FS_HCS.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108771 (DISCUSSION) Harmonized Communication and Sensing service (HCS). (Source: Huawei, Hisilicon, vivo, CAICT, China Unicom, China Mobile, China Telecom, ZTE, CATT, China Security and Protection Industry Association).
Document for: Discussion.
Abstract: Harmonized Communication and Sensing service (HCS).

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108773 (SID NEW) New SID about AF control of 5GC groups.. (Source: Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Objective: The following aspects regarding support of group related requirements including necessary enhancements to the NEF exposure framework will be studied: WT#1: Device group management: Create/modify/delete groups and manage group attributes such as group service area, add/modify/delete group members, allocation of a unique external group identifier. The study aims to re-use and generalize existing solutions for group management. WT#2: Study whether and how to use additional traffic profile information in 5GS for a group of UEs, which include transfer interval, data volume per cycle time, average and peak data rates, silence time intervals, and allow requesting QoS for all UEs which are part of a group. WT#3: Allow following operations to be applied for a group of devices: Device connectivity monitoring and QoS monitoring, AF subscribing to group status events. WT#4: Support of dynamic management of ad-hoc groups, i.e., groups with a list of members that are not pre-defined group members based on their subscription data in UDM but can, for example, contain all users for which traffic is handled by a given edge application server instance, and the ability for an AF to manage the list of members of an ad-hoc group, i.e., add/update/delete the ad-hoc group member list. For untrusted AF this includes enhancements to the NEF exposure framework. NOTE: Co-ordination with 5G ACIA will take place as needed during the study phase.

Comment:

CC#3: This was noted.

Discussion and conclusion:

CC#3: This was noted.

e-mail discussion:

Sang-Jun (Samsung) proposes that 8773 should be merged to 8574. The objectives of 8574 seem to include those of 8773.
Rainer (Nokia) replies to Sang-Jun (Samsung).
Sang-Jun (Samsung) asks Rainer (Nokia) a question.
Sebastian (Qualcomm) asks a question
Rainer (Nokia) replies.
Qianghua (Huawei) prefers one SID for group management and group communication
==== Revisions Deadline ====
Sebastian (Qualcomm) objects to the SID; would be ok if WT4 was removed
==== Comments Deadline ====
Susana (Vodafone) supports this SID and comments
Sebastian (Qualcomm) replies to Rainer and provides r01 in drafts folder
Rainer (Nokia) replies and provides r01 to CC#3 folder.

Status:

Noted.

TD S2-2108774 (SID NEW) New SID on 5G support for Femto.. (Source: Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Objective: Following aspects will be studied: WT#1: Study how to support 5G Femto deployments: WT#1.1 Study how to define the necessary overall architecture and required functionalities for 5G Femto deployments. WT#1.2: Study how to define the access control mechanism to allow for 5G Femto deployments by using the CAG concept. NOTE: RAN internal (architecture) aspects need to be studied in RAN WGs, e.g., RAN WG3 and RAN WG4. Cooperation with RAN WGs is required, for example when enhancing interfaces between RAN and Core. WT#2: Study how to enable provisioning of subscribers allowed to access 5G Femto (such as using a function like CSG Subscriber Server (CSS) as specified for EPS), e.g., within a CAG, and how to manage 5G Femto access control by the CAG owner or an authorized administrator.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Hualin(Huawei) still have strong concerns as in last meeting, since there is RAN work on this so far. So, we propose to note this SID.
Rainer (Nokia) replies.
Stefan (Ericsson) has same concerns as Hualin (Huawei)
Dieter (Deutsche Telekom) has also concerns with the proposal
==== Revisions Deadline ====
Stefan (Ericsson) objects to this SID
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108779 (DISCUSSION) Sensing capability for support of Low-Altitude intelligent network in UAV industry. (Source: CSPIA (China Security and Protection Industry Association)).
Document for: Discussion.
Abstract: -

Comment:

WITHDRAWN.

Discussion and conclusion:

-

Status:

Withdrawn.

TD S2-2108855 (SID NEW) New SID: new Study on the support for 5WWC, Phase 2.. (Source: Nokia, Nokia Shanghai Bell, Huawei, HiSilicon, Deutsche Telekom, Broadcom, Lenovo, Motorola Mobility, Qualcomm, KPN, China Telecom, CableLabs).
Document for: Approval.
Abstract: New SID: new Study on the support for 5WWC, Phase 2.

Comment:

CC#3: r09 agreed. Revised to S2-2109363.

Discussion and conclusion:

CC#3: Nokia provided S2-2108855r06 (with WT2a WT2e WT2f and WT3d). There were a number of issues for decision in this proposal. Intel commented that they could accept r03 or only bullet a of r06. Charter commented that e and f were necessary for BBF and CableLabs requirements. Nokia updated this to S2-2108855r09. S2-2108855r09 was agreed and revised in S2-2109363.

e-mail discussion:

Laurent (Nokia): Comments
Laurent (Nokia): Comments and provides r01
Marco (Huawei): provided Huawei's position on WTs in draft folder. Huawei proposals for revision of 5WWC SID are included in S2-2108936.
Stefan (Ericsson) provided 5WWC poll paper in DRAFTS folder
Farooq (AT&T) provides 5WWC poll paper in DRAFTS folder (adds to E/// input)
Myungjune (LGE) comments on WT 3a
Laurent (Nokia): answers
Sebastian (Qualcomm) provides Qualcomm comments for 5WWC poll paper
Marco (Huawei) proposes to prepare a revision with only non controversial objectives as minimum basis
Curt (Charter) provides comments for 5WWC poll paper
Myungjune (LGE) provides comments for 5WWC poll paper
Dieter (Deutsche Telekom) provides comments for 5WWC poll paper.
Laurent (Nokia): provides the result of the polling about 5WWC
Laurent (Nokia): provides the result of the polling about 5WWC with a summary for each WT, provides R02 and r03 (fairly minimalistic)
Dieter (Deutsche Telekom) comments on WT2 d) Support of emergency calls, for UE(s) connected behind the 5G RG.
Saso (Intel) comments on WT#2a and WT#2b. Proposes to remove them.
Hualin(Huawei) object r02 and r03. We propose to remove objective 2d and 2e based on r02 as further revision r04.
Laurent (Nokia): asks Hualin whether he is sure to object to r03, this is about emergency calls
Tyler (OTD) comments on WT#2b, supports keeping it.
Laurent (Nokia): provides r04 that should replace r03 (corrects a bug in TU calculation)
Saso (Intel) replies.
Laurent (Nokia): provides r05
Marco (Huawei) comments WT2a
Hualin(Huawei) answers
Hualin(Huawei) suggest to remove emergency calls. But not very insistent.
Hualin (Huawei) comments on r05.
Laurent (Nokia): provides r06
Laurent (Nokia): provides r07
Laurent (Nokia): provides r08
==== Revisions Deadline ====
Curt (Charter) comments on WT selection process
Laurent (Nokia): with BBF and CL we have worked via LS in the past and need to go on that way
Laurent (Nokia): answers: WT07/WT08 had a an overwhelming majority of concerns 8 against 1 support
Curt (Charter): Charter can only support R02 or any version post and including R04 that is updated to also contain WT2e and WT2f.
Sebastian (Qualcomm) objects to r00 to r02; is ok with other versions; flexible on WT2e and WT2f
Laurent (Nokia): is happy to support R04, R06 or R07 with WT2e, WT2f (added back to any of R04, R06 or R07). Suggest that we consider discussing R07 with WT2e, WT2f being readded during the CC2
Marco (Huawei) can only support r03,04,05,06 that are updated also containing WT3d (No r00, r01, r02, r07, r08)
Dieter (Deutsche Telekom) can only support r04, 06 with or without adding WT4b, but not more. Objects to all other versions.
.
Stefan (Ericsson) can only support r04, r06 as is. (R03, R05 in principle OK but they have same objectives as r04, r06 respectively). Objects to other versions.
Sriram (CableLabs): is happy to support R04 with WT2e, WT2f added back.
marco (Huawei): if further discussion in CC2, also Wt3d
Laurent (Nokia): is happy to support R04, R06 or R07 with WT2e, WT2f (added back to any of R04, R06 or R07). Suggest that during the CC2 we consider discussing R06 with (WT2e + WT2f +W3d) being readded and the package being agreed!
==== Comments Deadline ====
Aditya (Comcast): Comcast shares the views expressed by Charter and Nokia. We will support R02 or any version post
Laurent (Nokia): I have put a .pptx for the SoH in Inbox/CC/CC2.

Status:

Revised to S2-2109363.

TD S2-2109363 (SID NEW) New SID: new Study on the support for 5WWC, Phase 2.. (Source: Nokia, Nokia Shanghai Bell, Huawei, HiSilicon, Deutsche Telekom, Broadcom, Lenovo, Motorola Mobility, Qualcomm, KPN, China Telecom, CableLabs, Charter, Apple).
Document for: Approval.
Abstract: New SID: new Study on the support for 5WWC, Phase 2.

Comment:

Revision of S2-2108855r09. Approved.

Discussion and conclusion:

-

Status:

Approved.

TD S2-2108868 (SID NEW) New SID on Access Traffic Steering, Switching and Splitting support in the 5G system architecture; Phase 3.. (Source: Lenovo, Motorola Mobility, ZTE, Broadcom, Apple, Alibaba, Tencent, China Mobile, Convida Wireless, Deutsche Telekom, Nokia, Nokia Shanghai Bell, Samsung, Interdigital, Matrixx, Cisco Systems, Charter Communications, CableLabs, Comcast, CATT, Intelsat, Viv).
Document for: Approval.
Abstract: New SID: Study on Access Traffic Steering, Switching and Splitting support in the 5G system architecture; Phase 3.

Comment:

Revision of (Postponed) S2-2107635 from S2#147E. CC#3: r03 endorsed. Revised to S2-2109358.

Discussion and conclusion:

CC#3: Lenovo provided S2-2108868r02 (+updates_CC#3). Qualcomm commented that they could not accept this SID without including the removed 5.2, which they consider to be the core of this SID. Huawei commented that they did not believe 5.2 was needed and could add 5.2 at TSG SA if it is demonstrated that it is necessary for this WID. Ericsson could not accept including 5.2. Samsung agreed with Qualcomm that 5.2 was needed for this SID. This was Technically Endorsed with objections from Qualcomm and Samsung. Magenta clarified that issues raised with 5.2 included that there is no service requirement for it and many companies did not see the need for this and considered that this could be proposed as a separate SID based on any requirements from SA WG1. CableLabs replied that they disagreed that there are no service requirements for this. AT&T replied that the stage 1 includes vague requirements which can be read as a white paper rather than service requirements. Nokia commented that they also supported 5.2 but preferred to agree the SID without 5.2 and work offline to try to make an update at TSG SA. Qualcomm sustained their objection to the version without 5.2. S2-2108868r03 was endorsed and revised in S2-2109358.

e-mail discussion:

Marco (Huawei) per techical comments in S2-2108920, we confirm objection to WT5.2.
Marco (Huawei) comment and proposed revision of WT5.1 in folder INBOX/DRAFTS/ ATSSS_ph3_discussion.
Tricci (OPPO) shares the same concern with Marco (Huawei) for objective 5.2 and has further questions on other objectives.
Dieter (Deutsche Telekom) maintains objection from last meeting to WT5.2.
Huan (vivo) shares the same concern with previous comments to WT5.2.
Rainer (Nokia) replies.
Apostolis (Lenovo) responds to Tricci (OPPO).
Dario (Qualcomm) replies
Marco (Huawei) comments to Dario (Qualcomm)
Marco (Huawei) point out that revision of WT5.1 as in folder INBOX/DRAFTS/ ATSSS_ph3_discussion are essential to make WT 5.1 acceptable.
Marco (Huawei) asks clarification on WT 5.3
Apostolis (Lenovo) confirms that the changes to WT5.1 requested by Marco (Huawei) will be implemented in r01.
Dieter (Deutsche Telekom) answers to Dario .
Omkar (CableLabs) agrees with Qualcomm's view and indicates support for WT#5.2.
Stefan (Ericsson) expresses concerns with WT#5.2
Farooq (AT&T) also expresses concern on WT5.2.
Apostolis (Lenovo) provides r01
Apostolis (Lenovo) responds to Marco (Huawei) on WT5.3.
Marco (Huawei) proposes revision of WT5.
Marco (Huawei) proposes a revision of WT5 (to himself).
Apostolis (Lenovo) comments on WT#5.2.
Dario (Qualcomm) replies to Apostolis
Apostolis (Lenovo) provides r02.
Marco (Huawei) comments and confirm concern on 5.2
Farooq (AT&T) asks question for clarification
==== Revisions Deadline ====
Farooq (AT&T) suggests adding a Note to the objectives
Apostolis (Lenovo) responds to Farooq (AT&T).
Farooq (AT&T)responds to Apostolis (Lenovo)
Omkar (CableLabs) responds on removal of WT#5.2
Apostolis (Lenovo) comments that the Note suggested by Farooq (AT&T) is only needed if we keep WT#5.2.
Marco (Huawei) objects R00, R01. OK with r02 with comment for clarification
DongYeon (Samsung) supports keeping WT#5.2.
Rainer (Nokia) supports also keeping WT5.2
Spencer (Tencent) also supports keeping WT5.2.
Apostolis (Lenovo) supports keeping WT5.2 with a clarification Note.
Rainer (Nokia) is ok with the Note.
Stefan (Ericsson) objects to r00, r01. OK with r02.
Dieter (Deutsche Telekom) objects to r00, r01. OK with r02.
Tyler (OTD) supports r02.
Dario (Qualcomm) is OK with r00, r01 (also with NOTE by Farooq) and objects to r02
Omkar (CableLabs) is OK with r00, r01 and objects to r02
==== Comments Deadline ====
Spencer (Tencent) agrees with Dario (Qualcomm).
Tricci (OPPO) supports ONLY r02 with the NOTE (see below) suggested by Farooq.

Status:

Revised to S2-2109358.

TD S2-2109358 (SID NEW) New SID on Access Traffic Steering, Switching and Splitting support in the 5G system architecture; Phase 3.. (Source: Lenovo, Motorola Mobility, ZTE, Broadcom, Apple, Alibaba, Tencent, China Mobile, Convida Wireless, Deutsche Telekom, Nokia, Nokia Shanghai Bell, Samsung, Interdigital, MATRIXX Software, Cisco Systems, Charter Communications, CableLabs, Comcast, CATT, Intelsat, Vivo, BT, Thales, HPE, Tessares, Telefonica, KPN, Orange, MediaTek Inc., Rogers Communications Canada, Huawei, Xiaomi, Bouygues Telecom, US Cellular, ETRI).
Document for: Approval.
Abstract: New SID: Study on Access Traffic Steering, Switching and Splitting support in the 5G system architecture; Phase 3.

Comment:

Revision of S2-2108868r03. CC#3: Technically Endorsed with an objection from Qualcomm.

Discussion and conclusion:

Technically Endorsed with an objection from Qualcomm. This will not be submitted by MCC to TSG SA, but will be included in the list from the SA WG2 Chair for the prioritization list.

Status:

Endorsed.

TD S2-2108896 (SID NEW) New SID on Study on Architecture Enhancements for Vehicle Mounted Relays .. (Source: Qualcomm Incorporated, Sony, InterDigital Inc. AT&T, Verizon UK Ltd, ZTE Corporation, Telstra, vivo Mobile Communications Ltd, Volkswagen AG, Philips International B.V., Xiaomi, SyncTechno Inc., FirstNet, Lenovo/Motorola Mobility, LG Electronics, Rakuten ).
Document for: Approval.
Abstract: New SID on Study of Architecture Enhancement for Vehicle Mounted Relays.

Comment:

Revision of (Postponed) S2-2107310 from S2#147E. r03 agreed. Revised to S2-2109325.

Discussion and conclusion:

-

e-mail discussion:

Laurent (Nokia): Comments
Lars (Sony) asks Laurent (Nokia)
Laurent (Nokia): answers
Hong (Qualcomm) provides r01.
Wanqiang (Huawei): Comments on the new added 'NOTE 1: The study aims to avoid introducing new RAN architectures.'
Hong (Qualcomm) provides r02.
Wanqiang (Huawei) feedback the update does not work.
Hong (Qualcomm) replies to Wanqiang.
Wanqiang (Huawei) replies to Hong.
Hong (Qualcomm) provide r03 and r04.
Sherry (Xiaomi) comments.
Hong (Qualcomm) provides r05 (based on r03) and r06 (based on r04).
Shabnam (Ericsson) proposes to continue on r05 path.
Wanqiang (Huawei) comments on r05.
Laurent (Nokia): we have reservation/concern on the approach in R04 and R06
Relja (TNO) would like to be added to the list of supporting companies. TNO finds r05 as a good basis. Relja responds to Wanqiang (Huawei) and pose a question to Hong(Qualcomm).
==== Revisions Deadline ====
Hong (Qualcomm) replies to Relja.
Laurent (Nokia): objects to R00, R01,R02, R04, R06
Hong (Qualcomm) replies to Laurent.
Wanqiang (Huawei) proposes to go with r03.
Laurent (Nokia): answers to Hong
Hong (Qualcomm) replies and fine with either r03 or r05 route.
Lars (Sony) fine with r03.
Sherry (Xiaomi) is fine with either r03 or r05.
LaeYoung (LGE) is fine with r03.
Relja (TNO) is fine with both r03 and r05.
Jean Yves (Thales) is fine also with either r03 or r05.
==== Comments Deadline ====.

Status:

Revised to S2-2109325.

TD S2-2109325 (SID NEW) New SID on Study on Architecture Enhancements for Vehicle Mounted Relays .. (Source: Qualcomm Incorporated, Sony, InterDigital Inc. AT&T, Verizon UK Ltd, ZTE Corporation, Telstra, vivo Mobile Communications Ltd, Volkswagen AG, Philips International B.V., Xiaomi, SyncTechno Inc., FirstNet, Lenovo/Motorola Mobility, LG Electronics, Rakuten Mobile Inc., Thales, TNO, Apple).
Document for: Approval.
Abstract: New SID on Study of Architecture Enhancement for Vehicle Mounted Relays.

Comment:

Revision of S2-2108896r03. Approved.

Discussion and conclusion:

-

Status:

Approved.

TD S2-2108904 (SID REVISED) New SID: Study on system architecture for next generation real time communication services.. (Source: China Mobile, China Unicom, Huawei, Hisilicon, ZTE, CATT, Vivo, Deutsche Telekom, T-Mobile USA, Ericsson, AT&T).
Document for: Approval.
Abstract: The SID is revised to use correct template and to update the time slot estimation.

Comment:

Revision of (Approved) S2-2108165 from S2#147E. Approved.

Discussion and conclusion:

-

e-mail discussion:

Mario (TI) Telecom Italia supports this study.
==== Comments Deadline ====
Jarmo (KPN) also supports this study.
Susana (Vodafone) supports the study.

Status:

Approved.

TD S2-2108915 (REPORT) Moderated Email Discussion summary for FS_VMR_ARC. (Source: Qualcomm Incorporated).
Document for: Information.
Abstract: This is the summary of the moderated email discussion for Rel-18 SID proposal on FS_VMR_ARC.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108920 (DISCUSSION) Consideration on ATSSS WT #5 objectives.. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: This paper presents considerations on ATSSS WT #5 objectives.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108936 (DISCUSSION) Considerations on 5WWC SID objectives.. (Source: Huawei, HiSilicon).
Document for: Approval.
Abstract: This paper proposes a revision of the 5WWC SID objectives.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Laurent (Nokia): proposes to Note this discussion paper (objects to any of version of this Tdoc) and to concentrate on the SID discussion
Marco (Huawei): This paper provides the motivations for all Huawei's comments to the 5WWC SID, hence this information will be used directly in SID email discussion
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108938 (SID NEW) New Study on Service-based N2.. (Source: Intel, Qualcomm Incorporated, Deutsche Telekom, Verizon UK Ltd., AT&T, Microsoft, Orange, Cisco, InterDigital, Broadcom).
Document for: Approval.
Abstract: Objective: This study item aims at investigating 5GS enhancements to enable the use of a service-based interface between NG-RAN and the 5GC for selected N2 functionality that is not related to UE mobility or NAS signalling. Specifically, the study aims to investigate the following aspects: 1. Identification of N2 functionality not related to UE mobility or NAS signalling that can benefit from a service-based interface. Examples include UE Radio Capability ID mapping, obtaining of non-UE associated assistance data, broadcast of assistance data by an LMF, Warning Request Transfer, communication between NG-RAN and NWDAF (depending on RAN WG3 progress), etc. As part of the study, and in close cooperation with RAN WG3, it will be investigated whether the service-based interface could also be used for direct conveyance of information between NG-RAN nodes that currently traverses the AMF transparently (e.g. RIM Information Transfer, Configuration Transfer for SON). 2. Mechanisms for implementation of the identified NG-RAN services (i.e. service registration, service discovery, request/response vs subscribe/notify paradigm, etc.). 3. Investigate the migration and co-existence aspects for deployments where NG-RAN nodes supporting a service-based interface need to co-exist with legacy NG-RAN nodes. The study will be coordinated with RAN WG3 and CT WG4 WGs as needed. The focus of the SA WG2 work will be on the generic stage 2 framework for a service-based interface for the identified N2 functionality (as listed in the objectives above) that falls under SA WG2 responsibility. As part of the study it will be concluded whether and how to proceed with normative work. The time for this study item is estimated at 5 TUs, as summarized in the table.

Comment:

Revision of (Postponed) S2-2107100 from S2#147E. Noted.

Discussion and conclusion:

-

e-mail discussion:

Laurent (Nokia): Objects to this Tdoc and any of its revisions
Shabnam (Ericsson) objects to this SI, already stated reasons during SA2#147E and additional NOTE adds more confusion and concern as it seems the study extends on discussing AN/CN functional split.
Wanqiang (Huawei) maintains the same position of previous meeting and proposes to note this SID.
Jicheol (Samsung) share the same view with Nokia, Ericsson and Huawei.
Jinguo(ZTE) shares the same view with Nokia, Ericsson, Huawei, and Samsung.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108960 (DISCUSSION) FS_ATSSS_Ph3: Dual 3GPP access for PLMN + SNPN and PLMN + PLMN. (Source: Qualcomm Incorporated).
Document for: Endorsement.
Abstract: This slide set describes use cases for MA PDU sessions with Dual 3GPP access.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Marco (Huawei) propose to note the DP
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108973 (SID NEW) New SID: PWS over non-3GPP access.. (Source: Apple, Verizon UK Ltd, Broadcom, Convida Wireless).
Document for: Approval.
Abstract: New SID: PWS over non-3GPP access.

Comment:

Revision of (Postponed) S2-2107773 from S2#147E. CC#3: Noted.

Discussion and conclusion:

CC#3: Original version S2-2108973r00. Qualcomm commented that there are no regulatory requirements for support of PWS and this was not in the Scope of SA WG2 work and objected to this SID. Magenta also did not consider this a SA WG2 Scope. This was then noted.

e-mail discussion:

Haris(Qualcomm) objects to this SID since there are no regulatory and SA1 requirements
Krisztian (Apple) has a concern regarding Qualcomm's objection as it is not based on technical ground. There's at least one operator (Verizon) interested to study PWS over WLAN as a service improvement without regulatory mandate. The increased probability of successful warning message delivery (e.g. in indoor environment) is a clear improvement to PWS service resulting in better user experience. In addition, it's unclear what kind of new SA1 service requirements are necessary to make PWS service available over non-3GPP access. We think there are architectural and protocol impacts but PWS service experience remains the same for the user. Hence, we still think the work can start from SA2.
==== Revisions Deadline ====
Haris(Qualcomm) comments that the objection is absolutely based on technical grounds since there are no regulatory and service requirements for SA2 to accomplish
Krisztian (Apple) responds: as commented before, TS 22.268 states that PWS, ETWS and CMAS deployment depends on operator decision or national regulations. National regulations are not the only driving force to improve the service, it is up to operator decision. There's operator interest to deploy PWS service improvement. Furthermore, PWS requirements in TS 22.268 are not dependent on access technology. We are proposing to re-create the same service experience on non-3GPP access that is already available on 3GPP access using the existing PWS service requirements present in TS 22.268. Hence, the objection by Qualcomm has no ground.
Dieter (Deutsche Telekom) propose to note the SID as PWS is not in SA2 responsibility.
==== Comments Deadline ====
Krisztian (Apple) asks to make a decision at CC#2 regarding this proposal.
CT1 owns Stage-2 Cell Broadcast Service (CBS) for 3GPP access, TS 23.041 is called 'Technical realization of Cell Broadcast Service (CBS)'.
The proposal here is PWS over non-3GPP access that can't be based on CBS. SA2 is the group to tackle new work with architectural impacts. Offloading work to CT1 is of course a possible way forward but that's for SA to decide during prioritization.
Krisztian (Apple) asks to make a decision at CC#2 regarding this proposal.
CT1 owns Stage-2 Cell Broadcast Service (CBS) for 3GPP access, TS 23.041 is called 'Technical realization of Cell Broadcast Service (CBS)'.
The proposal here is PWS over non-3GPP access that can't be based on CBS. SA2 is the group to tackle new work with architectural impacts. Offloading work to CT1 is of course a possible way forward but that's for SA to decide during prioritization.
Krisztian (Apple) asks to make a decision at CC#2 regarding this proposal.
CT1 owns Stage-2 Cell Broadcast Service (CBS) for 3GPP access, TS 23.041 is called 'Technical realization of Cell Broadcast Service (CBS)'.
The proposal here is PWS over non-3GPP access that can't be based on CBS. SA2 is the group to tackle new work with architectural impacts. Offloading work to CT1 is of course a possible way forward but that's for SA to decide during prioritization.

Status:

Noted.

TD S2-2108982 (DISCUSSION) Sensing capability for support of Low-Altitude intelligent network in UAV industry.. (Source: CSPIA (China Security & Protection Industry Association)).
Document for: Discussion.
Abstract: This discussion paper aims at giving the regulation requirement of UAV from the industry perspective and proposes to study a basic network sensing capability in R18.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108987 (DISCUSSION) DISC On AMF relocation in connected mode.. (Source: NEC,).
Document for: Discussion.
Abstract: The aim of the discussion paper is to discuss the scenario related to AMF relocation in the connected mode.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108989 (REPORT) Moderated email discussion summary on FS_INCP. (Source: China Telecom (moderator)).
Document for: Information.
Abstract: Moderated email discussion summary on FS_INCP.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108990 (REPORT) Moderated Email Discussion summary for FS_ESSIND. (Source: China Telecom).
Document for: Information.
Abstract: This is the summary of the moderated email discussion for Rel-18 SID proposal on FS_ESSIND.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

# 9.1.4 Revision of Rel-18 SID/WID proposal TECHNCIALLY ENDORSED at SA2#147E

TD S2-2108433 (SID NEW) New SID on Enhancement to the 5GC LoCation Services Phase 3.. (Source: CATT, Huawei).
Document for: Approval.
Abstract: This contribution proposes a new SID on Enhancement to the 5GC LoCation Services Phase 3.

Comment:

Revision of (Endorsed) S2-2108170 from S2#147E. r02 agreed. Revised to S2-2109326.

Discussion and conclusion:

-

e-mail discussion:

Ming (CATT) provides r01.
Ming (CATT) provides r02, with one more supporting company, two WT merge and better WT#7 wording.
Jingran (OPPO) provides comments on some WTs.
Ming(CATT) reply to Jingran (OPPO).
Relja(TNO) would like to be added to the list of supporting companies.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109326.

TD S2-2109326 (SID NEW) New SID on Enhancement to the 5GC LoCation Services Phase 3.. (Source: CATT, Huawei).
Document for: Approval.
Abstract: This contribution proposes a new SID on Enhancement to the 5GC LoCation Services Phase 3.

Comment:

Revision of S2-2108433r02. Approved.

Discussion and conclusion:

-

Status:

Approved.

TD S2-2108474 (SID NEW) New SID on Study on 5G Timing Resiliency and TSC enhancements .. (Source: Nokia, Nokia Shanghai Bell, Verizon, AT&T, Sennheiser, Huawei, HiSilicon, Matrixx, ZTE, China Unicom, Vivo, NTT Docomo, ETRI, Xiaomi, Orange, China Mobile, KDDI, Tencent, T-Mobile USA, Interdigital, Samsung, CATT, Deutsche Telekom, Ericsson, Denso, BMWi, ).
Document for: Approval.
Abstract: New SID on Study on 5G Timing Resiliency and TSC enhancements.

Comment:

Approved.

Discussion and conclusion:

-

e-mail discussion:

Susan (Huawei) provides a revision.
Sebastian (Qualcomm) raises concerns for the draft revision provided by Huawei
Gy×rgy (Ericsson) comments.
Devaki (Nokia) comments.
Susan (Huawei) replies to Sebastian (Qualcomm).
Susan (Huawei) replies to Gy×rgy (Ericsson).
Devaki (Nokia) provides r01.
Susan (Huawei) replies to Devaki (Nokia).
Susan (Huawei) is ok with r01.
==== Revisions Deadline ====
Gy×rgy (Ericsson) replies to Huawei.
Gy×rgy (Ericsson) objects to r01, proposes to go with original version.
Devaki (Nokia) asks if we can go with the original version r00?
Susan (Huawei) replies to Devaki (Nokia) and accept to move with the original version r00.
Devaki (Nokia) thanks Susan (Huawei) for the understanding and accepting r0.
==== Comments Deadline ====.

Status:

Approved.

TD S2-2108525 (SID NEW) New WID on Study on System enhancement for Proximity based Services in 5GS - Phase 2 .. (Source: CATT, OPPO).
Document for: Approval.
Abstract: Rel-18 new SID on 5G ProSe.

Comment:

Revision of (Endorsed) S2-2108162 from S2#147E. CC#3: r06 endorsed. Revised to S2-2109359.

Discussion and conclusion:

CC#3: CATT provided S2-2108525r06. Huawei raised issues on the vagueness of WT#9. Samsung replied that this had been technically endorsed at the previous meeting and would object to excluding WT#9. Nokia commented that this fails to take account of the feedback from the Mediated e-mail discussions where there were issues raised on WTs#4, 5, 6 and 9. The SA WG2 Chair suggested removing WT#9 and checking support. AT&T emphasised the importance of WTs #5 and 6 and would object to excluding these. Qualcomm did not agree to removing WT#9. CATT clarified that they had added 'Whether and how' to WT#9 to mitigate the issues raised. Huawei commented that they could accept this to allow progress on this SID. Nokia commented that they objected to WT#4 but could accept WT#5 and 6 if the need for corresponding RAN progress is acknowledged.
Objection to WT#4: 1
Support for WT#4: 12
The SA WG2 Chair commented that any RAN dependent work which does not progress in RAN WGs will need to be reviewed when this is known for all WIDs.
S2-2108525r06 was endorsed and revised in S2-2109359.

e-mail discussion:

Judy (Ericsson) comments
Fei (OPPO) responds to Judy (Ericsson)
Judy (Ericsson) responds to Fei (OPPO)
Hannu (Nokia) supports Judy's comment on WT#2 TUs and provides a draft revision.
Steve (Huawei) comments
Mehrdad (Samsung) does not agree with the view shared on removing WT#4 and WT#9.
Hong (Qualcomm) comments and share the view of Samsung.
Ihab (FirstNet) FistNet does not agree with removing WT5 & WT6 for multi-hop support since it is an important feature for Public Safety
James Hu (AT&T) comment that removing WT4, WT5 and WT6 are not acceptable to us. These WTs shall stay within this SID.
Heng (China Telecom) dose not agree the removal of WT4 and WT9
Deng Qiang (CATT) responds and provides r01.
LaeYoung (LGE) comments on r01.
Deng Qiang (CATT) provides r02.
Mehrdad (Samsung) comments on r02
Deng Qiang (CATT) provides r03 and r04.
Fei (OPPO) comments.
Fei (OPPO) responds to Steve (Huawei)
Ihab (FirstNet) FistNet will object to any revisions of the SID that propose the removal of WT5 & WT6 for multi-hop support
==== Revisions Deadline ====
James Hu (AT&T) provides comments: we are ok with r03 with WT5 and WT6 included and object r04 and all revisions without multi-hops support.
Hannu (Nokia) has got sympathy with WT#5 and #6, but SA2 is the wrong place for this battle. Since RAN has already de-prioritised these topics out of Rel-18, there is no point to include them in SA2 study either.
Hannu (Nokia) still doesn't see the need for WT#9 but can live with revision where the service continuity aspect is removed from WT#4.
Hannu (Nokia) does not oppose the SID but requests it to be handled in CC due to high number of budgeted TUs.
Asks also why is WT#9 still included in the draft SID when 10 companies spoke against it in MED process?
Steve (Huawei) objects to any revision that includes WT#9 (all so far, r00, r01, r02, r03, r04).
Mehrdad (Samsung) suggests to take r03 and r04 to CC#3. We prefer r04 and object to any revisions without WT#9
Hong (Qualcomm) replies to Steve.
Hannu (Nokia) objects to r03 and r04, but proposes to take r04 as the template for further work. WT4, 5, 6 and 9 have all been challenged so r05 with all of them removed would give us a subset of the SID that probably nobody would object based on what it includes. (some might object it based on what it does not, though)
Mehrdad (Samsung) does not agree on removing WT#4 and WT#9 and objects to any new revisions based on this
==== Comments Deadline ====
James (AT&T) understands RAN dependency with WT#5 and #6. RAN has NOT decided to exclude this feature yet for R18, it is premature to exclude it in this SID. Our position stands.
Steve (Huawei) comments.

Status:

Revised to S2-2109359.

TD S2-2109359 (SID NEW) New WID on Study on System enhancement for Proximity based Services in 5GS - Phase 2 .. (Source: CATT, OPPO).
Document for: Approval.
Abstract: Rel-18 new SID on 5G ProSe.

Comment:

Revision of S2-2108525r06. CC#3: Technically Endorsed with an objection from Nokia on WT#4.

Discussion and conclusion:

CC#3: Technically Endorsed with an objection from Nokia on WT#4. This will not be submitted by MCC to TSG SA, but will be included in the list from the SA WG2 Chair for the prioritization list.

Status:

Endorsed.

TD S2-2108593 (DISCUSSION) Discussion on enhancement for URLLC.. (Source: Huawei, HiSilicon).
Document for: Agreement.
Abstract: This discussion paper proposes to study how to adapt 5GS URLLC solutions to support the typical industrial redundancy for high reliability, and propose to bring back the deleted objective for redundancy in FS_5GTTUe SID.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108690 (DISCUSSION) Discusson about AI based positioning. (Source: vivo).
Document for: Decision.
Abstract: This discussion paper is to discuss the way forward of AI based positioning.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

# 9.1.5 Revision of Rel-18 SID/WID proposal APPROVED at SA2#147E

TD S2-2108416 (SID NEW) New SID on Study on architecture enhancement for XR and media services .. (Source: China Mobile, Huawei, Hisilicon, Tencent, Xiaomi).
Document for: Approval.
Abstract: Study on architecture enhancement for XR and media services.

Comment:

Revision of (Approved) S2-2108156 from S2#147E. r07 agreed. Revised to S2-2109360.

Discussion and conclusion:

CC#3: China Mobile provided S2-2108416r07. S2-2108416r07 was agreed and revised in S2-2109360.

e-mail discussion:

Paul (Ericsson) provides comments and questions for clarification.
Dario S. Tonesi (Qualcomm) provides S2-2108416_Qualcomm in the draft folder.
Dan (China Mobile) provides r02 and please ignore r01
Devaki (Nokia) provides -revNokia in the DRAFTS folder.
Hui (Huawei) replies to Paul (Ericsson) .
Hui (Huawei) fine with Devaki's proposal.
Paul (Ericsson) asks questions for clarifications and provides comments.
Paul (Ericsson) asks Hui (Huawei) questions for clarification.
Hui (Huawei) replies.
Dan(China Mobile) provides r03
Paul (Ericsson) replies to Hui (Huawei) and asks questions for clarifications.
Hui(Huawei) replies.
Paul (Ericsson) replies to Hui (Huawei).
Hui(Huawei) replies to Paul (Ericsson).
Dario (Qualcomm) thanks and provides S2-2108416r02_QC in the draft folder.
Dan(China Mobile) provide r04 to reflect Hui's update.
Dan (China Mobile) thanks Dario's mention and provide r05,and thanks for Yang(oppo)'s offline comment and provide r06
==== Revisions Deadline ====
Dan (China Mobile) suggest to accept r06
Dario (Qualcomm) objects to r03, 4, 5, 6. Can accept r02 + TU adjustment.
==== Comments Deadline ====
Devaki (Nokia) comments that r01 based on _Nokia revision is missing. Requests that the SID is brought up to CC#2/#3 as it has a pending EN, TU(s) do not match thus changes have to be done. Original version cannot be approved due to pending issues that have not been resolved yet.
Dan(China Mobile) provide update r06 in CC#2.

Status:

Revised to S2-2109360.

TD S2-2109360 (SID NEW) New SID on Study on architecture enhancement for XR and media services .. (Source: China Mobile, Huawei, Hisilicon, Tencent, Xiaomi).
Document for: Approval.
Abstract: Study on architecture enhancement for XR and media services.

Comment:

Revision of S2-2108416r07. Approved.

Discussion and conclusion:

-

Status:

Approved.

TD S2-2108424 (DISCUSSION) Discussion on Topic for NWDAF-assisted RFSP Index Selection in R18.. (Source: China Telecom).
Document for: Discussion.
Abstract: This contribution proposes to add an objective for NWDAF-assisted RFSP Index Selection in FS_eAN_Ph3.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Belen (Ericsson) disagree to add this objective to eNA_Ph3 as it would need their own SID.
Leo (Deutsche Telekom) has similar concerns as Ericsson, eNA should not be extended to be applicable to EPC.
Yannick (Nokia): Nokia provides comments and share concerns expressed already on this proposed eNA_Ph3 work task.
Zhuoyi (China Telecom): China Telecom replies to Yannick and Belen.
Belen (Ericsson) replies to China Telecom, still disagrees to add this objective to eNA_Ph3 SID.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

TD S2-2108437 (SID NEW) New SID on enhancement of 5G AM Policy.. (Source: China Telecom).
Document for: Approval.
Abstract: New SID on enhancement of 5G AM Policy for R18, with new update on SID Item Checkbox.

Comment:

Revision of (Approved) S2-2108155 from S2#147E. r02 agreed. Revised to S2-2109327.

Discussion and conclusion:

-

e-mail discussion:

Sicheng (SGCC) supports the SID and would like to co-sign it.
Kaixin (CBN) supports the SID.
Jing (CAICT) supports the SID and would like to co-sign it.
Zhuoyi (China Telecom) provides r01 with new supporting companies.
Guliang (INSPUR) supports this SID and please add Inpurt as supporting companies.
Zhuoyi (China Telecom) provides r02 with Inspur as new supporting company.
==== Revisions Deadline ====
==== Comments Deadline ====
Susana (Vodafone) supports this SID and asks to be included as supporting company.
Zhuoyi(China Telecom) provides drafting r03 with Vodafone in supporting company.

Status:

Revised to S2-2109327.

TD S2-2109327 (SID NEW) New SID on enhancement of 5G AM Policy.. (Source: China Telecom).
Document for: Approval.
Abstract: New SID on enhancement of 5G AM Policy for R18, with new update on SID Item Checkbox.

Comment:

Revision of S2-2108437r02. Approved.

Discussion and conclusion:

CC#2: China Telecom reported that Vodafone had requested adding to the supporting companies for this. The SA WG2 Chair clarified that adding and removing Source companies to reflect the confirmed support may be done without requesting express permission before a document is uploaded. S2-2109327 remained approved.

Status:

Approved.

TD S2-2108455 (SID REVISED) New SID: Study on enhancement of 5G UE Policy.. (Source: Intel, Qualcomm Incorporated, OPPO, ZTE, NTT Docomo, vivo, Telecom Italia, China Unicom, Huawei, HiSilicon, Vodafone, CATT, MediaTek, KPN, China Telecom, CMCC, KDDI, Xiaomi, Apple, Verizon UK Ltd, Samsung, Lenovo, Motorola Mobility, LG Electronics, Rakute).
Document for: Approval.
Abstract: Study on enhancement of 5G UE Policy.

Comment:

r02 agreed. Revised to S2-2109328.

Discussion and conclusion:

-

e-mail discussion:

Changhong (Intel) provides r01 to be consistent the new SID template.
Changhong (Intel) provides r02 to add DISH Network as supporting company.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Revised to S2-2109328.

TD S2-2109328 (SID REVISED) New SID: Study on enhancement of 5G UE Policy.. (Source: Intel, Qualcomm Incorporated, OPPO, ZTE, NTT Docomo, vivo, Telecom Italia, China Unicom, Huawei, HiSilicon, Vodafone, CATT, MediaTek, KPN, China Telecom, CMCC, KDDI, Xiaomi, Apple, Verizon UK Ltd, Samsung, Lenovo, Motorola Mobility, LG Electronics, Rakuten Mobile Inc., Ericsson, Convida Wireless, Orange, DISH Network).
Document for: Approval.
Abstract: Study on enhancement of 5G UE Policy.

Comment:

Revision of S2-2108455r02. Approved.

Discussion and conclusion:

-

Status:

Approved.

TD S2-2108552 (SID NEW) New SID on Enhancement of support for Edge Computing in 5G Core network - phase 2. (Source: Huawei, HiSilicon, Alibaba, China Unicom, Convida Wireless, Intel, Toyota, vivo, Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: This update corrects the number of TUs and removes the highlights in the SID approved in SA WG2#147e.

Comment:

Revision of (Approved) S2-2108166 from S2#147E. r01 agreed. Revised to S2-2109329.

Discussion and conclusion:

-

e-mail discussion:

Samsung supports this SID.
Guliang(Inspur) supports this SID and please add Inspur as supporting company.
Patrice (Huawei) thanks Jicheol (Samsung) and Guliang (Inspur) for their support.
Jarmo (KPN) thanks for support given to add the proposed objective in a new revision S2-2108552 and replies to whether to include the objective to WT7 or to add a new WT9
Zhuoyun (Tencent) supports the SID.
Patrice (Huawei) thanks Zhuoyun (Tencent) for their support and provides r01 with the additional supporting companies and the content of S2-2108897.
==== Revisions Deadline ====
==== Comments Deadline ====
Susana (Vodafone) supports this SID.

Status:

Revised to S2-2109329.

TD S2-2109329 (SID NEW) New SID on Enhancement of support for Edge Computing in 5G Core network - phase 2 .. (Source: Huawei, HiSilicon, Alibaba, China Unicom, Convida Wireless, Intel, Toyota, vivo, Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: This update corrects the number of TUs and removes the highlights in the SID approved in SA WG2#147e.

Comment:

Revision of S2-2108552r01. Approved.

Discussion and conclusion:

-

Status:

Approved.

TD S2-2108749 (SID NEW) Study on Enablers for Network Automation for 5G - phase 3.. (Source: China Mobile, vivo).
Document for: Approval.
Abstract: TU estimates update for R18 eNA SID.

Comment:

CC#3: r08 agreed. Revised to S2-2109361.

Discussion and conclusion:

CC#3: China Mobile provided S2-2108749r08. It was commented that the TU Budget for this needs further work to try to reduce it if possible. Ericsson suggested Rapporteurs indicate which items they will favour for prioritization. S2-2108749r08 was agreed and revised in S2-2109361.

e-mail discussion:

Antoine (Orange) provides r01.
Aihua(CMCC) replies and provides r02.
Aihua(CMCC) provides r03 to make alignment between the first column and the last on the WT tag .
Xiaobo(vivo) replies and provides r04.
Yannick (Nokia): Nokia provides comments. Nokia cannot agree to reduce the TU estimates agreed in SA2#147E without changing the work tasks description. Nokia cannot agree to remove WT#3.1 and WT#3.5.
Farooq (AT&T) provides proposal on down scoping the study
Guliang (Inspur) support the SID and would like to co-source it.
Belen (Ericsson) objects to all revisions presented so far, supports AT&T proposal to discuss thos WT that start with 'whether and how' for downscoping.
Juan Zhang (Qualcomm) supports to trigger a discussion for down scoping but not just simply reduce the total number.
LaeYoung (LGE) also thinks that down-scoping is needed instead of just down-sizing to unrealistic TUs.
David (Samsung) supports avoiding plain down-sizing without adjustments in the scope.
Dimitris (Lenovo) supports the view that any changes to TU would require adjustments in the scope
Antoine (Orange) provides r05.
Aihua (CMCC) replies and provides r06.
Malla (NTT DOCOMO) object r06.
Malla (NTT DOCOMO) further comment.
Belen (Ericsson) objects to r06
Juan Zhang (Qualcomm) proposes to start a moderate email discussion.
David (Samsung) comments.
Aihua(CMCC) comments and provides r07 as the basis for potential MED.
Belen (Ericsson) comments on r07 and ask for updates
==== Revisions Deadline ====
Xiaobo(vivo) reply Belen's comments.
Yang (OPPO) provides the rewording suggestion.
Belen (Ericsson) still objects to r07. Provides a rewording suggestion
Yannick (Nokia): Nokia objects to all revisions that attempt to remove some work tasks (r01, r02, r03, r04, r06) and to initial version that reduces the TU estimates without appropriate down-scoping for the work. We should have proper moderated email discussion to further reduce the number of work tasks and suggest to discuss the details for this at a CC during this meeting.
Xiaobo(vivo) support the proposal from Yannick(Nokia) to reword WT#3.8.
==== Comments Deadline ====
Aihua(CMCC) provides drafting r08 for further check.

Status:

Revised to S2-2109361.

TD S2-2109361 (SID NEW) Study on Enablers for Network Automation for 5G - phase 3.. (Source: China Mobile, vivo).
Document for: Approval.
Abstract: TU estimates update for R18 eNA SID.

Comment:

Revision of S2-2108749r08. Approved. It was noted that the TU Budget for this needs further off-line work.

Discussion and conclusion:

CC#3: Approved. It was noted that the TU Budget for this needs further off-line work.

Status:

Approved.

TD S2-2108993 (LS IN) LS from 5GAA: LS on Enhancements on QoS Sustainability analytics in the context of the Study on Enablers for Network Automation for 5G - phase 3 (FS_eNA_Ph3). (Source: 5GAA (5GAA_S-210186)).
Document for: Action.
Abstract: 5GAA would like to thank SA WG2 for taking into consideration the requirements on QoS Sustainability analytics (or QoS prediction) that 5GAA has proposed in the context of the TSG SA workshop (SP-210619). And specifically for including some of the proposed requirements in the Rel.18 Study on Enablers for Network Automation for 5G - phase 3 (S2-2108169) {. . .} Action: 5GAA respectfully asks SA WG2 to take into consideration the above clarifications for the task 'Whether and how to increase QoS sustainability with finer granularity' of the Rel.18 FS_eNA_Ph3 Study Item.

Comment:

Postponed.

Discussion and conclusion:

-

Status:

Postponed.

TD S2-2108897 (DISCUSSION) DP on new objective for FS_eEDGE_5GC_ph2: potential solutions for the AF to be able to obtain/determine the DNAI in Release 18.. (Source: KPN, Huawei).
Document for: Agreement.
Abstract: This discussion paper provides a suggestion to add a new objective on 'potential solutions for the AF to be able to obtain/determine the DNAI that is associated to a certain selected EAS' to the currently approved SID on Enhancement of support for Edge Computing in 5G Core network - phase 2 (FS_eEDGE_5GC_ph2).

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Patrice (Huawei) proposes to endorse S2-2108897 and include the proposed objective in a revision of S2-2108552.
==== Revisions Deadline ====
==== Comments Deadline ====.

Status:

Noted.

# 9.2 Review of the Work Plan, Rel-17 WID Status Reports

TD S2-2108492 (WORK PLAN) Work_plan_3gpp_211001_Filtered_SA2. (Source: MCC).
Document for: Information.
Abstract: Filtered SA WG2 Work Plan for information.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108302 (WI STATUS REPORT) EV2XARC_Ph2 status report. (Source: LG Electronics).
Document for: Information.
Abstract: EV2XARC_Ph2 status report.

Comment:

Revised to S2-2109374.

Discussion and conclusion:

-

Status:

Revised to S2-2109374.

TD S2-2109374 (WI STATUS REPORT) EV2XARC_Ph2 status report. (Source: LG Electronics).
Document for: Information.
Abstract: EV2XARC_Ph2 status report.

Comment:

Revision of S2-2108302. Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108435 (WI STATUS REPORT) SA WG2 Status report for eLCS_Ph2. (Source: CATT).
Document for: Information.
Abstract: 5G_eLCS_ph2 Status report.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108439 (WI STATUS REPORT) MINT Status Report. (Source: LG Electronics).
Document for: Information.
Abstract: MINT Status Report.

Comment:

Revised to S2-2109379.

Discussion and conclusion:

-

Status:

Revised to S2-2109379.

TD S2-2109379 (WI STATUS REPORT) MINT Status Report. (Source: LG Electronics).
Document for: Information.
Abstract: MINT Status Report.

Comment:

Revision of S2-2108439. Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108464 (WI STATUS REPORT) ENPN Status Report. (Source: Ericsson (rapporteur)).
Document for: Information.
Abstract: ENPN Status Report.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108487 (WI STATUS REPORT) IIoT Status report. (Source: Nokia, Nokia Shanghai Bell (Rapporteur)).
Document for: Approval.
Abstract: IIoT Status report.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108524 (WI STATUS REPORT) 5G_ProSe Status Report. (Source: CATT).
Document for: Information.
Abstract: 5G_ProSe Status Report.

Comment:

Revised to S2-2109375.

Discussion and conclusion:

-

Status:

Revised to S2-2109375.

TD S2-2109375 (WI STATUS REPORT) 5G_ProSe Status Report. (Source: CATT).
Document for: Information.
Abstract: 5G_ProSe Status Report.

Comment:

Revision of S2-2108524. Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108610 (WI STATUS REPORT) ENS_Ph2 status report. (Source: ZTE).
Document for: Information.
Abstract: ENS_Ph2 status report after SA WG2#147e.

Comment:

Revised to S2-2109376.

Discussion and conclusion:

-

Status:

Revised to S2-2109376.

TD S2-2109376 (WI STATUS REPORT) ENS_Ph2 status report. (Source: ZTE).
Document for: Information.
Abstract: ENS_Ph2 status report after SA WG2#147e.

Comment:

Revision of S2-2108610. Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2109377 (WI STATUS REPORT) eEdge_5GC status report. (Source: Huawei).
Document for: Information.
Abstract: eEdge_5GC status report.

Comment:

Revision of S2-2108720. Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108669 (WI STATUS REPORT) 5MBS Status Report. (Source: Huawei,HiSilicon).
Document for: Information.
Abstract: This document includes the status report for 5MBS.

Comment:

Revised to S2-2109380.

Discussion and conclusion:

-

Status:

Revised to S2-2109380.

TD S2-2109380 (WI STATUS REPORT) 5MBS Status Report. (Source: Huawei,HiSilicon).
Document for: Information.
Abstract: This document includes the status report for 5MBS.

Comment:

Revision of S2-2108669. Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108691 (WI STATUS REPORT) Report_eNA_ph2. (Source: vivo).
Document for: Information.
Abstract: This is TS status report of eNA Ph2.

Comment:

Revised to S2-2109378.

Discussion and conclusion:

-

e-mail discussion:

Aihua(CMCC) provides r01.

Status:

Revised to S2-2109378.

TD S2-2109378 (WI STATUS REPORT) Report_eNA_ph2. (Source: vivo).
Document for: Information.
Abstract: This is TS status report of eNA Ph2.

Comment:

Revision of S2-2108691. Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108720 (WI STATUS REPORT) eEdge_5GC status report. (Source: Huawei).
Document for: Information.
Abstract: eEdge_5GC status report.

Comment:

Revised to S2-2109377.

Discussion and conclusion:

-

Status:

Revised to S2-2109377.

TD S2-2108826 (WI STATUS REPORT) IoT_SAT_ARCH_EPS Status Report. (Source: MediaTek Inc.).
Document for: Discussion.
Abstract: Will need updating during the meeting.

Comment:

r01 Revised to S2-2109382.

Discussion and conclusion:

-

e-mail discussion:

Guillaume (MediaTek Inc.) provides r01.

Status:

Revised to S2-2109382.

TD S2-2109382 (WI STATUS REPORT) IoT_SAT_ARCH_EPS Status Report. (Source: MediaTek Inc.).
Document for: Discussion.
Abstract: Will need updating during the meeting.

Comment:

Revision of S2-2108826r01. Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2108957 (WI STATUS REPORT) SA WG2 Status report for MUSIM. (Source: Intel (rapporteur)).
Document for: Information.
Abstract: SA WG2 Status report for MUSIM.

Comment:

Revised to S2-2109381.

Discussion and conclusion:

-

Status:

Revised to S2-2109381.

TD S2-2109381 (WI STATUS REPORT) SA WG2 Status report for MUSIM. (Source: Intel (rapporteur)).
Document for: Information.
Abstract: SA WG2 Status report for MUSIM.

Comment:

Revision of S2-2108957. Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2109021 (WI STATUS REPORT) WI Status Report for ARCH_NR_REDCAP. (Source: China Mobile (rapporteur)).
Document for: Information.
Abstract: Status report for ARCH_NR_REDCAP.

Comment:

Noted.

Discussion and conclusion:

-

e-mail discussion:

Aihua(CMCC) provides status report for ARCH_NR_REDCAP.

Status:

Noted.

TD S2-2109370 (WI STATUS REPORT) ID_UAS status report. (Source: Qualcomm (Rapporteur)).
Document for: Information.
Abstract: ID_UAS status report.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD S2-2109383 (WI STATUS REPORT) SA WG2 Status report for 5GSAT_ARCH. (Source: Thales (Rapporteur)).
Document for: Information.
Abstract: SA WG2 Status report for 5GSAT_ARCH.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

# 9.3 Planning future meetings

See https://portal.3gpp.org/?tbid=375&SubTB=385#/

# 11 Close of e-meeting

The SA WG2 Chair thanked the Vice Chairs, the MCC Secretary, Rapporteurs and Delegates for their good work and cooperation at this meeting. He then wished everybody a happy holidays and prosperous new year.