Drafting Session on Controversial Points Regarding 5G Satellite Communication

5GSAT_Ph3_ARCH Drafting Session Focus on controversional points KI#2: Store and forward 1. List of satellites / Monitoring List & Wait timer . One or two lists. Mandatory/Advisory for UE. Including: Optional Detach indication Single list + UE remains registered (2008) 2. Attach with default PDN connection KI#3: UE-satellite-UE communication 1. Mobility support in IMS AGW onboard solution 1. How to notify the P-CSCF of the change of satellite ID? 2. How to notify the P-CSCF of whether the L-PSA is still available or not? 3. How to send a SIP re-INVITE for AGW relocation? 2. [Early media in call set-up] 3. [UPF only onboard solution: Postponed to wait for confirmation from SA3Li?] KI#1: Regenerative payload None

KI#2 Store and forward

KI#2 Minutes from the informal CC 3 options are discussed: Option 1, Using 2 different list ("List of Satellite IDs" and "S&F Monitored List") Option 2, Using one list with additional indication, e.g., mandatory or advisory Option 4, Using a single list without any indication Companies who support Option 1 or 2: Samsung, Sateliot, Qualcomm, Novamint Companies who support Option 4: vivo, NEC, OPPO, China Telecom, Ericsson, Nokia, Huawei The main issue of Option 1 or 2 mentioned by supporters of Option 4 could it may not work in the mobility procedure, and Samsung clarified there is no such mobility issue. Huawei provided more clarifications in the DP. Way forward: continue email discussion. SAMSUNG will initiate an email discussion on this issue.

E-mail discussion (1/2) Samsung: Clarifications provided for S&F List in accept message to address concerns that UE may remain in NO service in case of mobility: If S&F list is restricted to the registration area there is no such issue. When UE gets out of RA it will trigger TAU (irrespective of the list of sat IDs) and network has to provide the updated list (if required). Unprotected NAS message carrying monitoring list can be a security threat. Sateliot: For the attach accept case, still two possible uses of the S&F list and impacts if not followed depending on whether the UE is expected to detach or not when the serving satellite moves away Nokia: View is to have single list and define network behaviour for failure scenarios. The UE behaviour is based on the S&F list or S&F list+ S&F cause. The S&F list is not applicable for a detached UE. The UE is free to choose any satellite to Attach after being Detached. S&F-capable UEs need to use this assistance information and avoid failures, whereas legacy UEs will go through many failures and ultimately may be able to avail services.

E-mail discussion (2/2) Oppo: Single list. List not feasible to be applicable to detached UE feasible as UE has no idea how long the S&F list needs to be stored and what s the applicable area Vivo: mandatory behavior for UE to follow the list is problematic in our view. Huawei: We can guide the UE about which satellites to talk to (both while detached and CM_IDLE) and the UE should have some input into guide the construction of the list. If the UE does not follow the guidance, then it is just essentially trying random satellites. The UE should have some flexibly to escape the list and try other satellites. UE shall follow the list forever and forever. Qualcomm: There seem to be 2 types of use case: Type 1: The UE can disregard the Wait Time and/or monitoring list without harm except that in most cases, the UE access will not be successful Type 2: If the UE disregards the Wait Time and/or monitoring list, consequences are more serious e.g. onboard MME synchronization is impaired, successful UE access is delayed further, UE is detached (worst case) The type may be a property of the PLMN which can then support just this one type. For Type 2, some failsafe is still needed to overcome any error in the Wait Time or Monitoring List, movement of the UE or a DOS attack. However, that could be fairly simple.

KI#2- Single list S&F Satellite Lists: Purpose and expected UE behaviour when receiving the list Case Purpose UE behaviour Attach Accept Satellite IDs of the serving satellites in which the attach is valid. The UE needs to follow this list. TAU/Service Accept Satellite IDs of the serving satellites in which the attach is valid. The UE needs to follow this list. Attach Reject + S&F Cause Satellite IDs of the same PLMN in which the attach procedure can be re-attempted. The UE needs to follow this list. Validity duration needed? TAU/Service Reject + S&F Cause Satellite IDs of the same PLMN in which an attach procedure can be re-attempted. The UE needs to follow this list. Validity duration needed? Attach Accept + Detach indication Satellite IDs of the same PLMN in which the attach procedure can be re-attempted. The UE needs to follow this list. Validity duration needed? Default behavior if not provided: UE to consider all satellites , i.e., no restrictions (TBC)

KI#2 Analysis of possible cases (1/2) (rappourteur input) Cases Information elements that may be provided by MME Comments Attach Accept S&F Satellite List: Satellite IDs of the serving satellites in which the attach is valid. The UE needs to follow this list. If detach indication is provided in Attach Accept, Satellite IDs of the same PLMN in which attach procedure can be re-attempted. The UE needs needs to follow this list (TBD). A validity duration may be needed. (If not provided, asumed value is: any satellite of this PLMN ) All the parameters can be provided under NAS security. Description: 1. UE is not attached 2. UE selects a NTN cell operationg in S&F mode 3. UE triggers initial attach 4. UE receives Attach Accept S&F Wait Timer is needed for UE context update across the serving satellites. S&F Wait Timer: Time that the UE has to wait when losing converage from the current serving satellite until a new NAS procedure is triggered in any of the satellites indicated in S&F Sat. List (If not provided, assumed value is 0) S&F Detach indication: if provided by the MME, the UE should explicity or implicity detach of the current serving satellite when losing coverage. (If not provided, assumed that no detach is needed) TAU Accept / SR Accept Description: 1. UE is attached (it may have a S&F satellite List and S&F Wait Timer - already expired) 2. UE selects a NTN cell operating in S&F mode in a serving satellite 3. UE should monitor paging 4. UE may trigger TAU request /SR 5. UE receives TAU Accept or Service Accept S&F Satellite List: Satellite IDs of the serving satellites in which the attach is valid. The UE needs to follow this list. Same as above If not provided, asumed value is: any satellite of this PLMN S&F Wait Timer: Time that the UE has to wait when losing converage from the current serving satellite until a new NAS procedure is triggered in any of the satellites indicated in List_of_Satellites. If not provided, assumed that no detach is needed

KI#2 Analysis of possible cases (2/2) (rappourteur input) Cases Information elements that may be provided by MME Comments Attach Reject with S&F Cause S&F Satellite List: Satellite IDs of the same PLMN in which the attach procedure can be re-attempted. The UE needs to follow this list. A validity duration may be needed Parameters provided with no security NAS context activated. Description: 1. UE is not attached 2. UE selects a NTN cell operationg in S&F mode 3. UE triggers initial attach 4. UE receives Attach Reject with S&F Reject Cause S&F Satellite List is needed for the network to upload authentication vectors and/or subscription information to ensure attach can be accepted if the UE re-attempts. S&F Wait Timer is needed for the NW to have time to propagate AVs/subscripton inf. to the satellites of the S&F list. (If not provided, asumed value is: any satellite of this PLMN ) S&F Wait Timer: Time for the UE has to wait before attempting re-attach in any of the satellites indicated in List_of_Satellites. (If not provided, assumed value is 0) TAU/SR Reject with S&F Cause Description: 1. UE is attached (it has a S&F satellite List and S&F Wait Timer has expired) 2. UE selects a NTN cell operating in S&F mode in a serving satellite 3. UE should monitor paging 4. UE may trigger TAU request /SR 5. UE receives TAU Reject or Service Reject with S&F Reject Cause 6. Previous rejection requires the UE to re- attach S&F Satellite List: Satellite IDs of the same PLMN in which the attach procedure can be re-attempted. The UE needs to follow this list. A validity duration may be needed Same situation as previous (If not provided, asumed value is: any satellite of this PLMN ) S&F Wait Timer: Time for the UE has to wait before attempting re-attach in any of the satellites indicated in List_of_Satellites. (If not provided, assumed value is 0)

KI2: informal SoH during MonQ3 Assumption: monitoring list sent by the network is optional Question 1: whether network indicates to the UE when the UE shall follow and when UE may follow the monitoring list Yes: Samsung, Sateliot, Vodafone, CMCC, Novamint, TNO, QUALCOMM, Thales No: Intel, Huawei, NEC, Vivo, Oppo, Apple, CT, Xiaomi, CATT, Nokia (Nokia objects) Question 3: if network indicates monitoring list, the UE behavior is should Yes: Samsung, TNO, Novamint, LGE, Huawei, Intel, NEC, CMCC, Apple, Thales, Sateliot, CATT, No: Qualcomm, Nokia, AT&T, Vivo, OPPO, Xiaomi (Qualcomm and AT&T object) Remove monitoring list from baseline CR and add EN.

KI#3 UE-satellite-UE communication

KI#3 Minutes from the informal CC Topic 2: controversial issue on KI#3 Can we have following assumptions for simplifying mobility support in Rel-19 gNB, local PSA and AGW are always within same satellite. If a N2 CHO happens, the 5GC can determine to terminate UE-sat-UE communication. MO and MT side of a UE-sat-UE communication will not be subject to AGW relocation simultaneously due to IMS layer coordination. Summary: The first and third bullets could be agreed. While 2ndbullet cannot be agreed based on the following discussion on case 1. Case 1: SMF determines to terminate UE-sat-UE communication during the change of serving gNB. Summary of comments from Huawei, Nokia, CMCC, Ericsson: the termination of UE-Satellite-UE communication has nothing to do with Handover, SMF should notify PCF/P-CSCF the satellite change, then P-CSCF makes the decision. Way forward: continue email discussion. Can we always let P-CSCF make the decision as proposed by Ericsson? Case 2: P-CSCF determines to continue/terminate UE-sat-UE communication after the change of serving gNB and local PSA. Focus on the sub-issue#3, how to trigger the re-invite message for AGW relocation. Summary of the comments: Huawei, Ericsson, Nokia, NTT DOCOMO support that P-CSCF triggers IMS AS to sends the re-invite. While China Telecom, CMCC, vivo prefer the solution that P-CSCF builds the re-invite message. For the solution that P-CSCF triggers IMS AS to sends the re-invite, Nokia and NTT DOCOMO clarified that: P-CSCF works on the same dialog and not behaves as B2BUA; the existing procedure defined in TS 23.228 can be re-used. Way forward: continue email discussion. CMCC will check further the existing procedure. China Telecom provides more technical explanation if both solutions are to be supported.

#1-How to notify the P-CSCF the change of satellite ID #2-How to notify the P-CSCF whether L-PSA is still available #3-how to send a SIP re-INVITE msg for AGW relocation? Huawei Early notification Early/late notification P-CSCF triggers IMS-AS to build a re-INVITEmsg China Mobile Not specified Not specified P-CSCF builds a re-INVITEmsg China Telecom PCF event Early/late notification P-CSCF or S-CSCF builds a re-INVITE msg Vivo PCF event A new indication from PCF P-CSCF builds a re-INVITEmsg witout SDP NTT DCM Early notification Early notification P-CSCF triggers IMS-AS to build a re-INVITEmsg Opt1 IMS-AS building re-INVITE msg Opt2 both options Way forward still using PCF event on N5/Rx interface? Early notification?

KI#3: during MonQ3 Assumption: PCF notifies P-CSCF about change of satellite ID

Other material Slides presented in the CC

Both list of satellite ID and S&F monitoring list aim to assist UE to access a list of satellites which can provide S&F service to the : For split MME case, this list may indicate all satellites which can work together with same MME-GND to be a single MME, where the exact list can be pre-configured on the satellite. For full EPC case, this list may just indicate satellites which may have UE subscription. In this case, the list can not be accurately known by a satellite currently handling UE request. TO support this list, there are several options: Option1, Using different list: For list of satellite ID, the UE shall only access to the satellite within the list For S&F monitoring list, the UE is recommended to follow the list Option2, Using same list with additional indication, e.g., mandatory or advisory mandatory implicitly means this list is for split MME case, then the UE shall follow the list; advisory means the UE is recommended to select satellite within the list Option3, both list of satellite ID and S&F monitoring list are used as assistance information, i.e. no mandatory UE behaviors.

Can we have following assumptions for simplifying mobility support in Rel-19 1. 2. 3. gNB, local PSA and AGW are always within same satellite. If a N2 CHO happens, the 5GC can determine to terminate UE-sat-UE communication MO and MT side of a UE-sat-UE communication will not be subject to AGW relocation simultaneously due to IMS layer coordination case 1: SMF determines to terminate UE-sat-UE communication during the change of serving gNB. Steps: 1. The SMF decides to remove additional PSA, e.g.,: During any N2 conditional Handover During a Xn handover, UE-CL/local-PSA resources on the target satellite is not available 2. A notification is sent to the P-CSCF to select a AGW on the ground; 3. The P-CSCF notifies the peer P-CSCF to also select a AGW on the ground; 4. Both of MO and MT P-CSCF/IMS-AS send SIP re-INVITE msgs to the UEs. case 2: P-CSCF determines to continue/terminate UE-sat-UE communication after the change of serving gNB and local PSA. Steps: 1. Existing UL-CL and additional PSA simultaneously change procedure is reused to support serving gNB and local PSA change; 2. A notification is sent to the P-CSCF to trigger AGW relocation; 3. P-CSCF determines whether the UE-sat-UE communication can still be kept; 4. If yes, the P-CSCF selects a AGW onboard, otherwise, it selects a AGW on the ground; 5. The P-CSCF sends SIP re-INVITE msg to the UE or trigger the IMS-AS to send the re-INVITE msg; 6. 5GS continues simultaneously change of UL-CL and additional PSA procedure

Controversial issues #1-How to notify the P-CSCF the change of satellite ID #2-How to notify the P-CSCF whether L-PSA is still available #3-how to send a SIP re-INVITE msg for AGW relocation? Huawei Early notification Early/late notification P-CSCF triggers IMS-AS to build a re-INVITEmsg China Mobile Not specified Not specified P-CSCF builds a re-INVITEmsg China Telecom PCF event Early/late notification P-CSCF or S-CSCF builds a re-INVITE msg Vivo PCF event A new indication from PCF P-CSCF builds a re-INVITEmsg witout SDP NTT DCM Early notification Early notification P-CSCF triggers IMS-AS to build a re-INVITEmsg Way forward TBD Early/late notification? IMS-AS building re-INVITE msg?

Other material Miscelaneous

Since we have the drafting session on Monday, my recommendation is to have a slide set with a set of issues/questions that need to be addressed. That would help me understand: Which documents to open (and which ones to skip) Where to focus the discussion Identify the controversial issues and find a way forward for them In my understanding, the critical issues identified so far are: KI2 (Store and forward) 1.Whether the wait timer and monitoring list are mandatory or advisory. KI3 (UE-satellite-UE communication) 1.How to notify the P-CSCF of the change of satellite ID? 2.How to notify the P-CSCF of whether the L-PSA is still available or not? 3.How to send a SIP re-INVITE for AGW relocation? My questions: 1.Is there anything else I should be aware of? 2.Thanks to the slides on KI3 by Hucheng, I have a rough idea of where companies stand. Could you please summarize also the situation for KI2 (and any other issue I might have missed

KI#2 Analysis of possible cases (rappourteur input) Situation Information elements that may be provided by MME Comments Situation D: TAU/SR Reject with S&F Cause 1. UE is attached (it has a S&F satellite List and S&F Wait Timer has expired) 2. UE selects a NTN cell operating in S&F mode in a serving satellite 3. UE should monitor paging 4. UE may trigger TAU request /SR 5. UE receives TAU Reject or Service Reject with S&F Reject Cause 6. Previous rejection do not require the UE to re-attach S&F Satellite List: Satellite IDs of the same PLMN in which the TAU/SR procedure can be re-attempted. In this case, a validity duration may be needed. The UE needs to follow this list. Same situation as previous If not provided, asumed value is: any satellite of this PLMN S&F Wait Timer: Time that the UE has to wait when losing converage from the current satellite and attempting re-attach in any of the satellites indicated in List_of_Satellites. If not provided, assumed value is 0. IS THIS A VALID CASE?