3GPP TSG-CT WG4 Meeting #99E	Notes C4-204004

E-Meeting; 18th – 28rd August 2020

Source:	Chairman, TSG-CT WG4

Title:	Notes allocation of documents to agenda items for CT4#99E day 6

Agenda item:	2

Document for:	INFORMATION

Saved 25/08/2020 22:28 CET

Document available, not yet treated

Document available late, not yet treated

Document not available

Document treated

Document available later

NOTE 1: Hyperlinks assume that this document is extracted and stored in a directory and all documents are in a subdirectory "docs" of this directory.

NOTE 2: Late arrived Contributions will be handled only, if time allows and any company has the right to ask for postponing the document to the next meeting. The detailed agenda and time plan on eve of meeting, and the proposed allocation of documents to agenda items, are treated as being received on time even though they are available only at the start of the meeting (the chairman does have some privileges)

NOTE 3: If a document which was received late (after the deadline) is a revision of a document which was received before the deadline, it is treated as being received on time.

Agenda	Agenda Title	Tdoc C4-20#	Tdoc Title	Source	Result	Notes
1	Opening of the Meeting and Approval of the Agenda
2	Allocation of Documents to Agenda Items
4000	agenda Draft Agenda	CT4 Chairman	Noted
4001	agenda Detailed agenda & time plan for CT4 meeting: status at document deadline	CT4 Chairman	revised
4002	agenda Detailed agenda & time plan for CT4 meeting: status on eve of meeting	CT4 Chairman	Approved
4003	agenda Proposed allocation of documents to agenda items for CT4 meeting: status at document deadline	CT4 Chairman	Revised
4004	agenda Proposed allocation of documents to agenda items for CT4 meeting: status on eve of meeting	CT4 Chairman	Approved with amendments
3	Meeting Reports
4005	report Previous CT4 meeting report	MCC	Bruno: The list of participants in Annex F needs to be corrected: I attended the meeting but am currently not part of this list.
4007	report Plenary #88e report on CT4 related topics	CT4 Chairman	Noted
4	Input Liaison Statements
4032	LS in Rel-16 LS on S1/NG DAPS handover	RAN3	Postponed to 7.3.13	R3-202932 To: SA2, CT4 CC: Contact: CATT Rel-16 Wi: LTE_feMob-Core, NR_Mob_enh-Core RAN3 agreed to support S1/NG DAPS (Dual Active Protocol Stacks) Handover over S1 and NG. RAN3 agreed to introduce the below changes as described in the attached BL CRs for S1AP and NGAP: Add the DAPS related information in transparent containers between source and target in the Handover Preparation and Handover Resource Allocation procedures. Introduce two new class-2 procedures for transferring the COUNT value for the early data forwarding. The content of these messages is transparent to the core network. Introduce a new message (i.e. Handover Success from MME/AMF to source node) and enhance the Handover Notify message for indicating the successful access of the UE from target node to source node via MME/AMF. These changes may have impact on SA2 and CT4 specifications. To SA2 and CT4 working group: RAN3 kindly asks SA2 and CT4 to take the above RAN3 agreements into account and do corresponding change(s) to the specification(s) if needed. Postponed to Agenda item: 7.3.13 Proposed treatment: See reply from SA2 in C4-204038 and C4-204051. LS can be noted.
4033	LS in Rel-16 Reply LS on Service on I-NEF Event Exposure	SA2	Noted	S2-2004451 To: CT3, CT4 CC: Contact Nokia Rel-16 WI: 5G_CIoT SA2 thanks CT3 for their LS. SA2 has decided to simplify the Monitoring Event Report normalisation in roaming scenarios by removing the I-NEF and merging its tasks into the AMF and SMF. The attached CRs document this change in TS 23.501, TS 23.502 and TS 23.273. Action: SA2 kindly asks CT3 and CT4 to align their specifications with the attached stage 2 CRs Postponed to Agenda item: 7.2.4?? Proposed treatment align the Monitoring Event Report normalization if needed.
4034	LS in Rel-15 Reply LS on NAS Non delivery for RRC Inactive state	SA2	Noted	S2-2004452 To: RAN3, CT4 CC: Contact: Cisco Postponed in last CT4 meeting. S2-2004452 Rel-15 NR_newRAT-Co SA2 thanks RAN3 about the LS on NAS Non delivery for RRC Inactive state (R3-201362). SA2 discussed the questions and agreed the following answers. Q1/ RAN3 would like to ask SA2 to clarify the meaning of the above statement in TS 23.501 for the considered scenario and clarify whether option 1/ or option 2/ is the expected behaviour? Ans 1: N1N2Transfer failure notification from AMF to SMF is not needed. Thus, NG-RAN node trigger of the NAS Non delivery procedure for PDU Session Release is not required. For PDU session Resource Release Command, there should be a PDU Session Resource Release response from RAN before UE context release occurs. Q2/ In general, does SA2 see any other scenario for which the 5GC expects the NAS-non-delivery report in addition to those failed NAS-PDUs in the DL NAS Transport message? Ans 2: For "Initial Context Setup Request" & "PDU Session Resource Setup" which have non-PDU session related NAS messages, indication from RAN of failure of these non-PDU session related NAS messages may be needed. SA2 requests RAN3 to decide how to handle the failure notification to AMF of these non-PDU session related NAS messages. Typically, "PDU Session Resource Setup" containing non-PDU session related NAS message is sent in RRC CONNECTED state, but SA2 identified one possible case (Selective activation of UP connection ) where it could be sent by the AMF also when the gNB and UE are in RRC Inactive state. SA2 will consider updates to their specifications based on RAN3 response. To CT4 group: ACTION: SA2 kindly requests CT4 to take the information in Ans 1 above into account and update their specifications if needed. Remarks from last meeting:: Bruno: we may need a CR to 29.518 or 29.502 but this needs further checking Propose to postpone Frank: CR 29.518 0257 agreed in last November meeting is related to this. Postponed to Agenda item: 8.3.1?? Giorgi: Is there any CR related to this LS? At least I can’t find one. Maybe we could postpone this LS to agenda 8.3 or 8.3.2, so that we would gain extra time to check if the clarification from SA2 impacts 29.518? Bruno: There is none. And it is still not clear to me whether we need any change to the CT4 spec (I would rather say “no”). And I am aware that there are also related RAN3 discussions still going on. I would suggest to note this LS, and companies might still bring CRs at the next meeting if they think anything needs to be changed. Giorgi: Great that you checked. Let’s note the LS, then. Lets note the LS and if we receive further input from RAN3 we can use this as trigger
4035	LS in Rel-16 LS Response on which features cannot interwork with ETSUN	SA2	Noted	S2-204443 To: CT4 CC: ETSUN Contact: Huawei Rel-16 SA2 thanks CT4 for their LS on which features cannot interwork with ETSUN. SA2 has the following answer on the question mentioned in the LS: CT4 kindly asks SA2 group to clarify which features cannot interwork with ETSUN and add the clarification in relevant specification if needed, and to confirm in particular whether URLLC applies to PDU session with I-SMF. [Answer]: SA2 provides following answer: Features for which SA2 has already specified the interworking with ETSUN: AF influence on traffic routing, eNS, eSBA, 5G_CIOT, Inter-RAT interworking. Features for which SA2 has already specified that they cannot interwork with ETSUN: LADN, and ATSSS Left to implementation: SSC mode 2/3 (PDU Session can be released or kept per operator’s policy) 5G_LAN: The UE may be connected with the PSA via an I-UPF which is controlled by the I-SMF. In this case, traffic switching (e.g. UPF local traffic switching) is controlled by the SMF as described in clause 5.29.4 without any specific knowledge or involvement of the I-SMF to support the 5G LAN-type service. The attached CR describe whether and if yes how following features interwork with ETSUN: 5G_URLLC, TSN/TSC, NPN. Interworking with ETSUN has not been explicitly documented in SA2 specifications for following features: V2X, and IAB: these feature do not have impact to I-SMF. So, by default they are supported when an I-SMF is inserted in a PDU Session. For any other feature, for R16: If the feature adds a new requirement to I-SMF or to N16a, the feature is not supported with ETSUN deployments by default ACTION: SA2 kindly requests CT4 to take the responses provided above into account. Remarks from last meeting: C4-203543 covered parts of the LS. There is also a dependency with RAN3. Postponed to Agenda item: 7.1.2?? Proposed treatment: Provide a CR for the remaining part of the LS
4036	LS in Rel-16 Reply LS on Stage 3 for V2X QoS	SA2	Postponed to 7.1.9	S2-2004445 To: RAN3, CT3, CT4 CC: Contact: Vodafone Rel-16 WI: 5G_V2X_NRSL / eV2XARC SA 2 thanks RAN 3 for informing them of their Working Assumption (WA) to proceed with stage 3 design as shown in the Text Proposals attached to their LS SA 2 have discussed the topic and agreed to change the SA2 specifications to align with the QoS attributes in the endorsed RAN3 CRs attached to the received incoming LS. However, SA2 believes that it is important that the NG-RAN shall enable the SMF to determine that the gNB supports the feature but cannot fulfill even the least preferred Alternative QoS Profile. Attached CR is agreed to capture this feature. ACTION: SA 2 respectfully ask RAN 3 to add the above to their Text Proposals/CRs. Remarks in last meeting Related to CRs on alternative QoS profiles We may need to do a final checking until next meeting. Postponed to Agenda item: 7.1.9 Bruno: Related CR is provided in C4-204198
4037	LS in Rel-16 Reply LS on “LS on Network Configuration Parameters in Monitoring Events”	SA2	Noted	S2-2004467 To: CT4 CC: CT3 Ericsson Rel-16 5G_CIoT SA2 would like to thank CT4 for the “LS on Network Configuration Parameters in Monitoring Events”. SA2 discussed the LS and would like to provide the following feedback. C4-202355 states: The configuration of Network Configuration Parameters in Monitoring Event seems to be inherited from EPC domain, where both Monitoring Events and Network Parameters are configured via the same interface on HSS (s6t). Since the introduction of Network Configuration, the use of configuration of parameters via monitoring events is no longer recommended, according to latest TS 23.682: NOTE 3: The Network Parameter Configuration via SCEF feature (see clause 4.5.21) feature supersedes the option of setting Reachability Type to "configuration" during configuration of the UE Reachability Monitoring Event which is no longer recommended. [SA2 feedback] SA2 agrees that continuous maintenance of parallel mechanisms (specified in 4.15.3.2.3b and 4.15.6.3a of TS 23.502) for Network Configuration Parameter provisioning should be avoided. In preparation for possible future deprecation of the event specific parameter provisioning as part of Monitoring Request specified in clause 4.15.3.2.3b of TS 23.502, SA2 has inserted recommendation to use the Parameter Provisioning procedure specified in clause 4.15.6.3a of TS 23.502. Due to T8 Northbound API legacy, SA2 did not discontinue the capability of event specific parameter provisioning as part of Monitoring Request specified in clause 4.15.3.2.3b of TS 23.502. C4-202355 states: CT4 considers managing Network Configuration Parameters ONLY via Nudm_ParameterProvisioining service is a better choice, which follows the direction of SBI design and better fits the service logic as the parameters are applied on UE level, regardless of the events being monitored. The handling of the parameters by different AFs on the same UE can be described properly [SA2 feedback] Ideally Network Configuration Parameters should be managed ONLY via Nudm_ParameterProvision service operation in 5GC, however, SA2 could not agree to remove the capability of event specific parameter provisioning as part of Monitoring Request specified in clause 4.15.3.2.3b of TS 23.502. In addition, SA2 also identified inconsistent description and incomplete functionality in Parameter Provisioning for Network Configuration parameters which are also captured in the attached CR. ACTION: SA2 kindly asks CT4 to take the above into account. Remarks from last meeting: The following CRs were agreed last CT4 meeting C4-203669 and C4-203713 Open Issue last meeting: in the LS (attached CR) is to support of multiple AFs via Nudm_PP API by allowing the create/delete instances of PPData per AF. This is new requirements to be covered by other CRs. Proposed treatment: No CR provided to this meeting, Clarify open issue from last meeting, Postponed to Agenda item: 7.2.4 ??
4038	LS in Rel-16 Reply LS on S1/NG DAPS handover	SA2	Postponed to 7.3.13	S2-2004474 To: CT, SA, CT4, RAN3; Cc: RAN. Contact: Nokia Rel-16 WI: LTE_feMob-Core, NR_Mob_enh-Core SA2 thanks RAN3 for their LS. Considering that Core Network protocol change are required (to cover inter AMF/MME mobility) while SA2 ensures that CT specifications are frozen in this quarter, SA2 has agreed to the attached R16 CR(s) based on the condition that TSG CT and TSG SA plenary agree to their inclusion in R16 specifications. SA2 will also like to highlight another issue which is not addressed in RAN3’s LS and the attached RAN3 CR but considered in the attached SA2 CRs. It is assumed that S-RAN will only initiate the DAPS HO when both S-RAN and S-AMF support DAPS HO. T-RAN will only send the DAPS HO accept when both T-RAN and T-AMF support the DAPS HO. ACTION: SA2 kindly asks RAN3 and CT4 to take the above information into account. Remarks from last meeting: SA2 conditionally agreed CRs, depends if plenary agrees the CRs for Rel-16 or 17 CRs to CT4 in August meeting. Postponed to Agenda item: 7.3.13 Proposed treatment: See LS in C4-204032 and C4-204051. Related stage 2 CRs are approved at plenary in SP-200551 and SP-200607 for Rel-16 CRs provided in C4-204xxx…
4046	LS in N32-f Protection Policy IE Data-Type Mapping	GSMA 5GIS	Postponed to 7.1.6	5GIS11_01 LS GSMA 5GIS to 3GPP CT4 IEData-Type v3 To: CT4 CC: SA3 Contact: Rel- WI - Actions to CT4: GSMA 5GIS requests the 3GPP CT4 group to consider these Data-Type mapping guidelines and provide responses to the following questions: Are these guidelines correct, or are there alternative guidelines which can be given? Is it an objective for 3GPP to define the correct Data-Type for IEs? Postponed to Agenda item: 7.1.6 Proposed treatment: provide feedback to GSMA and clarify in TS29.573 if seen needed. See C4-204146
4047	LS in N32-f Error Responses - Mapping	GSMA 5GIS	Postponed to 7.1.6	5GIS11_02 LS GSMA 5GIS to 3GPP CT4 N32f_ErrorTypes v3 To: CT4 CC: SA3 Contact: Rel- WI – Actions to CT4: GSMA 5GIS requests 3GPP CT4 group to consider these errors and provide responses to the following questions: What is the correct mapping for these error types? Do additional N32fErrorType values need to be assigned within TS 29.573 if the existing errors do not map to the currently defined enumerated types? Postponed to Agenda item: 7.1.6 Proposed treatment: provide feedback to GSMA on cause mapping and clarify in TS 29.573 if seen needed. See C4-204146
4048	LS in Rel-16 LS on secure that a UE does not wait indefinitely for completion of NSSAA procedure	CT1	Noted	C1-203895 TO SA2 CC: CT4 Contact: Rel- WI – CT1 discussed whether an additional mechanism is required to secure that a UE does not wait indefinitely for completion of the network slice-specific authentication and authorization. And CT1 has agreed attached CR and concluded that the existing mechanism can ensure that a UE does not wait indefinitely for completion of the network slice-specific authentication and authorization. No actions to CT4 Proposed treatment: note the LS
4049	LS in Rel-16 LS on new AVPs in TS 29.214	CT3	Noted	C3-203305 To: CT4 CC: Contact: Ericsson Rel- WI - CT3 would like to request CT4 to update TS 29.230 with the following new AVPs defined in TS 29.214 in Release 16: AVP code 569, 570 and 571 Proposed treatment provide CR to 29.230. See C4-204079, C4-204080 in Agenda item: 7.3.3 and 8.3.1 LS can be noted once CRs are agreed.
4050	LS in Rel-16 Reply LS on PAP/CHAP and other point-to-point protocols usage in 5GS	CT3	Noted	C3-203609 To: CT1 CC: SA2, SA3, CT4 Contact Qualcomm Rel-16 WI 5GProtoc16 CT1’s question: The following point-to-point protocols are defined in TS 24.008 as (e)PCO parameters which can be exchanged between the UE and the network during GPRS and EPS session management procedure: C021 Link Control Protocol (LCP) C023 Password Authentication Protocol (PAP) 8021 IP Control Protocol (IPCP) C223 Challenge Handshake Authentication Protocol (CHAP) Are above point-to-point protocols supported in 5GS (i.e. Rel-15 and/or Rel-16) as (e)PCO parameters or to be supported in the near future (i.e. Rel-17)? CT3’s Answer: CT3 has reviewed its current specifications related to the question above and the summary of the current status is in the following: TS 23.401 cl.4.4.3.3 describes PPP support for P-GW: “The network does not support PPP bearer type in this version of the specification. Pre-Release 8 PPP functionality of a GGSN may be implemented in the PDN GW.” Since PPP bearer type was deprecated in Rel-8, there is no support in TS 29.061 and 29.561 describing the interworking with external DN using PPP in 5G. For the authentication, if PCO includes PAP/CHAP, SMF doesn’t currently support using RADIUS/Diameter protocol including the corresponding PAP/CHAP information elements directly for interaction with external DN-AAA server, in the current release 15 and 16, but a combo-SMF+PGW node can support Radius/Diameter interface through its PGW component. No action for CT4 Proposed treatment note the LS
4051	LS in Rel-16 Reply LS on S1/NG DAPS handover	TSG CT	Postponed to 7.3.13	CP-201312 To: SA2, SA, RAN3, CT4 CC: RAN Contact Qualcom Rel-16 WI TEI16 CT thanks SA2 for their LS on S1/NG DAPS handover. CT has agreed that CT4 should work on completing the stage 3 changes required to enable S1/NG DAPS handover in Rel-16 at CT4#99-e. Consequently CT sees no issue with approving the CRs agreed by SA2 in S2-2004472 and S2-2004473 at SA#88. ACTION: CT asks CT4 to complete the stage 3 changes required to enable S1/NG DAPS handover in Rel-16 at CT4#99-e. Proposed treatment. See LS in C4-204032 and C4-204038. The LS can be noted.
4052	LS in Rel-16 Reply LS on port allocation	TSG CT	Noted	CP-201316 To CT4, RAN3 CC RAN, SA Contact Nokia Rel-16 WI - The way forward proposed by CT4 is endorsed by CT, RAN and SA. CT has asked IESG to approve the request for port number allocation for the W1 interface. CT4 is kindly asked to submit a WID for approval at the next TSG meeting, to specify alternative solutions for port allocation for new 3GPP interfaces from Rel-17 onwards that each 3GPP WG could rely upon when defining new interfaces. Proposed treatment. See proposed WID in C4-204030. This LS can be noted once the WID is handled. Giorgi I believe this LS should be noted, because we will discuss new PortAl WID. Perhaps, we could send a reply LS back to CT once we reach agreement on PortAl Bruno: we can note the LS once the SID is agreed. We don’t need to send a reply LS, CT will receive already the SID for approval. Giorgi: That’s fine by me.
4053	LS in Rel-16 LS on human-readable network name (HRNN)	TSG CT	Noted	CP-201361 To: SA1, SA2 CC: CT1, CT4 Contact Ericsson Rel-16 WI Vertical_LAN CT approved CR 23.122 CR#0518 which contains the following editor's note: Editor's note: It is FFS whether human-readable network name can be configured for a CAG-ID in a PLMN’s entry in the CAG Information list, to be provided to the upper layer during manual CAG selection. Furthermore, CT approved the exception sheet for Vertical_LAN WI (CP-201172) stating the following: TS 23.122 does not clearly reflect a requirement to obtain a human-readable network name via system information broadcast. It remains open whether there is a requirement for a UE to obtain a human-readable network name via other means than the system information broadcast and if so by what other way(s) the UE can obtain a human-readable network name. Finally, TS 23.501, subclauses 5.30.2.1, 5.30.2, 5.30.2.4, 5.30.3.2 indicates that the HRNN (if broadcasted) is only used for presentation in case of manual NPN selection. No action for CT4. Proposed treatment. This LS can be noted.
4054	LS in Rel-16 LS reply on RACS multiple radio capability formats	RAN3	Noted	R3-204147 To: SA2 CC: RAN2, CT4, CT3 Contact Huawei Rel-16 WI RACS_RAN RAN3 has agreed to introduce the support for multiple coding formats from the RAN node to the CN node over S1 and NG interfaces (as indicated by the SA2 LS). The agreed TPs are attached for reference. No action for CT4. Proposed treatment. This LS can be noted.
4055	LS in Rel-16 LS to CT4 on MDT specific configuration parameters in NR	SA5	Postponed to next meeting	S5-203166 To: CT4 CC: Contact Ericsson Rel-16 WI 5GMDT SA5 would like to inform CT4 that 3GPP TS 32.422 clause 5.10 has defined new parameters for NR as well as new parameter value settings for some existing parameters for NR in release 16. The MDT specific configuration parameters shall be propagated from 5GC towards RAN nodes in the case of signalling based MDT activation. Here are the list of new introduced parameters for NR: Area configuration for neighboring cell Report type for logged MDT Event list for event triggered measurement Sensor information The parameters with new introduced value settings in NR: Report Interval Report Amount Event Threshold for RSRP Event Threshold for RSRQ Logging Interval Logging Duration Area configuration for neighboring cell The detailed definition of the parameters above can be found in 3GPP TS 32.422 clause 5.10 and 3GPP TS 38.331 clause 6. Action: SA5 would request CT4 to take the above changes into consideration. Ericsson will bring CRs to next meeting
4060	LS in Completion of WT-456 and WT-470	Broadband Forum	Noted	LIAISE-411 To: SA2, SA3, SA5, CT1, CT3, CT4, RAN3 CC: cable labs Contact: - Rel- WI - We are pleased to attach the finalized versions of WT-456 “AGF Requirements” and WT-470 “5G WWC Architecture”. To be clear on our process, this is upon completion of comment resolution and editorial review by the WWC work area, but prior to final membership balloting, formal approval and publication. Review and comments are welcome, although any modifications to the document will not appear until the next revision. These two documents are part of the phase 1 of BBF WWC work, which is also expected to include updates to TR-124 (Functional Requirements for Broadband Residential Gateway Devices) and TR-181 (Device Data Model for TR-069) – these two specifications have started finalization process with comment resolution to take place at our Q3 meeting. We have a number of functional extensions and refinements to the WWC work planned for the remainder of the year and beyond, including some FFS items present in the attached WT documents. We look forward to continuing our fruitful relationship. The attached documents are for information to CT4. Proposed treatment : CT4 to note the LS Except someone has comments on the attached papers
5	WIDs
4030	SID new Rel-17 Port Number Allocation Alternatives for New Interfaces	Huawei	revised to C4-204121	Revision of C4-204121
CC1	4062	WID new Rel-17 New WID on Service-based support for SMS in 5GC	Orange, China Telecom	Revised to C4-204431	CT4 lead CT1 impacted Completion date September 2021 Jesus: E/// has the following comments to this WID: On clause 3 Justification, when an HSS/HLR is deployed in the network, we see no reason to not make use of it, and use the existing EPC interfaces towards the SMS nodes. This achieves the goal of keeping the UDM fully SBI, and UDICOM covers everything it is needed. Then, of course, in absence of HSS/HLR in the network (i.e. no UDICOM), UDM would benefit from having SBI interfaces towards SMS nodes, and be a full-SBI node, and we are supportive of such approach. Abdessamad I agree with you that this could be one approach, but I am not sure if it needs to be assumed from the beginning. One of the main objectives of this work is to avoid using MAP and Diameter for SMS transport over the roaming and interco interfaces due to the well-known security vulnerabilities. Indeed, SMSoDiameter is not yet (or rarely) deployed in the roaming context due to such reasons and GSMA is currently working on securing the Diameter international interco by specifying measures such as the usage of integrity and confidentiality protection in order to overcome those vulnerabilities. The usage of https and the 5G security by design framework around the SEPP is hence one of the main motivations for this work as it will also help overcoming these issues in an easier way maybe. Saying that we should restrict this work to 5G only users or to networks that do not have legacy HLR/HSS deployed could be a limitation in my opinion. Anyway, my proposal is to keep all the options on the table and discuss all these aspects during the study phase. On clause 4 Objective, we would like to add another impact to CT4, related to the aspect of how to route SBI requests from SMS nodes towards the recipient's HPLMN, based on the MSISDN of the SMS recipient Abdessamad OK, I have added it in v1. Please let me know if it is OK for you. On clause 5, the new TR mentions in its title "architecture enhancements". We don't think there needs to be any such "architecture enhancements"; in a similar WID proposal from E/// to SA2, that was done some months ago, E/// proposed to introduce new entities (e.g. SMS-GW) so that would indeed be an architectural change. But here, in our view, it's the same entities with the same (or almost) interactions, but just done using different protocols. Our proposal is to name the TR as the WID, e.g. "Study on Service-based support for SMS in 5GC". Abdessamad I agree with you. We forgot to change it actually in the TR title after changing it in the WID title . I have changed it in v1. With regards to CT1 involvement/impacts, I'd suggest to capture that they need at least to assess and review TR before completed Abdessamad I agree with you. I have added this in v1. With all these comments, if accepted, E/// would be happy to support the WID. Jesus: Thanks for addressing these points, and for accepting most of the comments. However, we are still disagreeing with the 1st point; as you say, one of the main motivations of this work is triggered by the request from GSMA to achieve a secure transport of the SMS payloads, by making use of the N32 security mechanisms available in 5G. That is fine, and fully agreed by us. However, to my recollection, GSMA does not indicate, or take any stand on, whether the signaling interfaces of UDM/HSS/HLR should be changed. In that sense, our view is that existing interfaces available when HSS/HLR is deployed in a network, can be perfectly be used, and this, along with the UDICOM mechanisms, offer a full working solution today. In our view, the WID should not state as objective to NOT make use of these interfaces. Still, E/// supports the definition of full SBI interfaces from UDM to SMS entities because this offers additional benefits (e.g. in scenarios where there is no HSS/HLRs deployed). These considerations and analysis can be deferred to the study in the TR, rather than putting them upfront in the WID, if you wish; we would agree to that; but then, the wording of the WID should be neutral and not hint in any specific direction. Ravi: This may require some architectural change for which SA2 engagement might be needed. Is SA2 okay for CT group to take these architectural decisions? We would like support this WID. Please add Cisco System in supporting members list. Jesus: As indicated in our former email (see below), we (E///) believe that this WID does not introduce any architectural change. Note that E/// proposed some time ago another WID in SA2 on this same topic, which did propose architectural changes by introducing a new network element called SMS-GW. However SA2 considered that this work could be done in CT4, and the current proposed WID in CT4 simply defines alternative signalling protocols (SBI APIs) for existing interactions between existing network elements. So, we don't think this is really an architectural change (and SA2 was already involved in the discussions, when the E/// WID was submitted there, some time ago). Abdessamad: Thanks for your feedback. Regarding your question, please refer to SP-191281/CP-193301 and SP-191362 where SA agreed to transfer the work on service-based support for SMS in 5GC to CT WGs, as it is mainly an interface and protocol evolution. I will be happy to add Cisco as a supporting company in the next version of the WID that I will share. It should be noted that during plenary discussion it was agreed that CT should take care of this work. Abdessamad: I have uploaded a new version (v2) of the WID taking into account your comments. Please let me know if this version is OK for you. Ravi: Thanks Jesus for the clarification. I will review (v2) and let you know if I have more comments. Jesus: The revision in v2 looks good to me Abdessamad: V3 uploaded to the draft inbox, which takes onboard Jesus’s last comment (during the conf. call). Please let me know if you have any additional comments Abdessamad: As I have not received further comments on 4062_v3, I have prepared based on this version and uploaded the proper revision (C4-204431) to the inbox folder.
4431	WID new Rel-17 New WID on Service-based support for SMS in 5GC	Orange, China Telecom	CT1 has to endorse the WID
4082	discussion Rel-17 Rel-17 enhancements for non-public networks in stage-2 WGs	Ericsson	Noted	Jesus: contact is Ivo if some one would, like to have presentation please send request on the reflector.
CC6	4095	WID new Rel-17 CT aspects on Dynamically Changing AM Policies in the 5GC	Ericsson	CT3 lead CT4 impacted Completion date September 2021 Peter Propse to change acronym
CC6	4096	WID new Rel-17 CT aspects on Dynamic Management of Group-based Event Monitoring	Ericsson	CT3 lead CT4 impacted Completion date June 2021 Peter Propse to change acronym
4097	discussion Rel-17 Impacts of eNS_Ph2 to CT WGs	ZTE	Noted
4098	WID new Rel-17 New WID on Enhancement of Network Slicing Phase 2	ZTE	Postponed to next meeting	CT1 lead CT3 and CT4 impacted Completion date December 2021 Bruno: it is premature to agree on the WID while there are still many competing solutions being studied by SA2. We agree with your conclusion in your DISC paper in C4-204097 that next CT WG meetings in Q4 would be appropriate to agree on the related CT WID. Note also (for clause 2 of the WID) that the CT WID should be BB of SA (normative) feature WID (which does not exist yet to my knowledge), and not of the SA2 SID. In clause 1, this CT WID should not impact the AN. Giorgi: We also support postponing the WID. Zhijun: Agree with you and thanks for the comments. Our intention is to provide information of SA2 progress and raize initial thinking for the eNS phase2 to collect comments from companies. And thanks for your suggestion to the content of draft WID, we will update it in future meeting. Should be postpone to next CT4 meeting.
4121	SID new Rel-17 Port Number Allocation Alternatives for New Interfaces	Huawei, DT, Vodafone	Revised to C4-204347	CT4 only Completion date June 2021 Bruno: Nokia and Nokia Shanghai Bell support this new study. We concur with Lionel's comments earlier posted on the CT4 list: “ About the proposed SID, I think that we will need two TR types: •one in the xx.8xx series to study the potential solutions •one in the xx.9xx to capture the solutions adopted by 3GPP (and endorsed by IETF if needed), TR that can be updated release after release if needed to include additional alternatives. And 3GPP WG will refer to this TR when appraising the best solution for their new interface(s) “ Clause 3: we should clarify in the justification (and objectives) that this study aims at specifying guidelines for port allocation for new 3GPP interfaces from Rel-17 onwards, that each 3GPP WG could rely upon when defining new interfaces as requested by CT(/RAN/SA) in C4-204052. Clause 4: "a preferred solution will be identified." : not necessarily only one solution. CT4 will define guidelines. "3GPP will share the outcome of the study with IANA and IESG for further coordination of the work": we should coordinate with IESG during the course of the study, not to end up with an outcome that is not agreable to IESG. Clause 5: The proposed TR title should be updated to “Study on Port Allocation Alternatives for new 3GPP interfaces” (and in any case, be aligned with the TR title that we will agree separately, which is not the case now). The date for presentation of the TR to CT for information can be changed to TSG#91 (March 2021). Otherwise this would leave only 1 meeting to reach at least 60% progress. Clause 8: we can strike the text related to W1 (that relates to Rel-16 and that has been tackled w/o these new alternatives). Please also correct the title of this document, replacing “WID” by “SID”. Giorgi: I will take your comments onboard and will update the SID accordingly. Zhijun: ZTE supports this SID. Please add ZTE as supporting company. Giorgi: Will do Giorgi: A draft of updated SID on PortAl is in Inbox/Drafts/5/C4-204121_v1. Please comment. I shifted the TR 29.xxx one CT plenary after the TR 28.xxx deadlines. Hope, this is agreeable. Frank: Just spot a typo in clause 8 as highlighted below: Oher 3GPP WGs may also need to obtain port numbers for new interfaces and therefore will be invited to review and comment on the findings of the study. Giorgi: Will do in v2. Lionel: Clause 3: IANA decided to cease the port number allocations to the new 3GPP interfaces. 3GPP WGs however will need to reserve certain port numbers for new interfaces. Therefore, 3GPP needs to find a solution to this problem. Not correct. IANA will still allocate port number but not for protocols used only inside a private network i.e. for protocols not used over the global internet. We can also indicate that IANA has eventually agreed to allocate a port number for a new 3GPP (internal) interface defined in Rel-16 as a last exception, at the condition that alternative solutions are developed by 3GPP for the future 3GPP interfaces. Clause 4: 3GPP CT4 discussed the following alternative solutions: - 3GPP allocating port numbers from the Private/Dynamic Port number range [49152 - 65535]; - Operators allocating port numbers from either the User Port number range [1024-49151] or the Private/Dynamic Port number range [49152 - 65535]; - DNS based solution also allocating port numbers from the User Port number range [1024-49151]. The above alternatives and potentially also other proposals will be studied and a preferred solution will be identified. 3GPP will share the outcome of the study with IANA and IESG for further coordination of the work, if necessary. As an introduction, we should indicate that the CT4 has discussed these alternative solutions due actually to the IANA reluctance to accept our port number assignment request. I agree with Bruno that we should not wait for the end of the study to coordinate with IESG/IANA. In the objectives, we should also provide some guidance to WGs on when it is valid to apply for an IANA port number allocation and when if it is preferable to rely on one of the solutions documented in the TR. Clause 8: I agree with Bruno’s comment, especially on the date for info presentation. Giorgi: Will fix these in v2. Giorgi: Revised version 4121_v2 is I the Inbox/Drafts/5 folder.
4347	SID new Rel-17 Port Number Allocation Alternatives for New Interfaces	Huawei, DT, Vodafone	Revised to C4-204432	Giorgi: Orange indicated support for this SID and I uploaded the revised version of 4347_v1 (former 4121) into Drafts/5 folder. Changes are visible in revision marks. Bruno: A few comments below: Title: Study on Port Number Allocation Alternatives for New 3PGG Interfaces 5 Expected Output and Time scale 29.9xy Study Guidelines on Port Allocation Solutions for New 3GPP Interfaces TR 29.9xy is to capture Guidelines for Port Allocation for New 3GPP interfaces. This is not a study. 3 Justification IANA became restrictive to reserving new port numbers to private networks. IANA has agreed to allocate a port number for a new 3GPP Rel-16 (internal) interface as the last exception with a condition that alternative solutions are developed by 3GPP for the future 3GPP interfaces. Therefore, 3GPP needs to specify guidelines for the port number allocation when new 3GPP interfaces are specified in 3GPP Rel-17 and onwards. Bruno> I recommend to also reference the CT(/RAN/SA) LS requesting CT4 to do this work.
4432	SID new Rel-17 Port Number Allocation Alternatives for New Interfaces	Huawei, DT, Vodafone	Revised to C4-204434
CC6	4434	SID new Rel-17 Port Number Allocation Alternatives for New Interfaces	Huawei, DT, Vodafone
CC1 CC6	4141	WID revised Rel-17 Revised WID on Enhancement for the 5G Control Plane Steering of Roaming for UE in CONNECTED mode	NTT DOCOMO Inc.	Revised to C4-204418	CT1 lead CT4 and CT6 impacted Completion date June 2021. WIC: eCPSOR_CON CT1 wants to handle it on Thursday any input from CT4. Hiroshi: Based on CT1 discussion, the Revised WID on “Enhancement for the 5G Control Plane Steering of Roaming for UE in CONNECTED mode” is now revised to C4-204418. It is available in the following link: http://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Docs/C4-204418.zip # It is not available in the inbox or draft folder under agenda 5, please let me know if it should also need to be uploaded there. from the previous version: - Reverted the proposed changes for replacing “the new SOR information” - Editorial updates. Hiroshi: The revised WID is now also available in the inbox under Agenda 5. https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/5/C4-204418.zip
4418	WID revised Rel-17 Revised WID on Enhancement for the 5G Control Plane Steering of Roaming for UE in CONNECTED mode	NTT DOCOMO Inc.
4181	discussion Discussion paper on FS_enh_EC	Huawei	Noted
4182	discussion Status of study on enhanced support of IIoT in 5GS (FS_IIoT)	Nokia, Nokia Shanghai Bell	Noted
CC6	4252	WID new Rel-17 New WID on CT aspects on Same PCF Selection For AMF and SMF	China Telecommunications	CT3 lead CT4 impacted Completion date March 2021 Acronym: TEI17_SPSFAS same as SA2! Proposed to add -CT
4273	discussion Rel-17 Discussion on TEI17_SPSFAS and TEI17_DCAMP	China Telecommunications	Noted
4299	discussion Analytics on eNA Phase 2 work	Huawei	Noted
4300	discussion Roaming Enhancement	Huawei	Noted	Hiroshi: Are the issues addressed based on 3GPP requirements or GSMA requirements? As indicated in the last paragraph of Discussion section, GSMA seems to be revisiting how SEPP and relevant reference points/API should work, and if this is true it might be better to wait for their requirements to progress the work, if the WID is to include any GSMA discussion. Caixia: The intention of this WID is to do enhancements of roaming in CT4 on R17, which do not require the stage work. There is no requirement from SA2 as no chance to do the roaming enhancements in stage 2 now. For GSMA, there are LSes from them on updating the SEPP API definition, not sure how much enhancements will come from GSMA in future. I propose to exclude the GSMA discussion and focus on the issues identified firstly, we can update the WID if there are any requirements from GSMA during R17 cycle Bruno: We agree that the following aspects could be further described and enhanced in the CT4 specifications: N31 between vNSSF and hNSSF N27 between vNRF and hNRF On the latter, vNF can update or delete the subscription via vNRF, with vNRF forwarding the request to hNRF using the H-PLMN ID provided by vNF. But the current design assumes that hNRF is able to route the request to a proper hNRF based on the susbcriptionId, i.e. that the subscriptionId contains information identifying the hNRF holding the subscription. How this is done is implementation specific. We agree that the solution could be enhanced to provide an explicit identifier or address of the hNRF holding the subscription. Regarding N32 between vSEPP and hSEPP, I expect a few Rel-16 corrections regarding the issues brought up by GSMA. Can you please provide more details on what possible alternative approach you foresee regarding remote SEPP discovery: Currently, SEPP discovers the peer SEPP based on roaming agreement with all of the roaming partners and local configuration, and the stateless related function shall also be supported based on local configuration, other solution may be needed to avoid the complex configuration. I doubt here that CT4 can do much on N32 w/o stage 2 from SA2 or SA3. And the door for stage 2 enhancements in Rel-17 is closed in SA2. We also need to check related work in GSMA. So in conclusion, we could consider some Rel-17 stage 3 enhancements in CT4 that are not dependent and do not require stage 2 work. Caixia: For the remote SEPP discovery, the original consideration is dynamic discovery from NRF may be needed to avoid the local configuration. But I agree with you, the enhancements included in the scope shall not depend on or require the stage 2 work. SEPP discovery enhancement, which shall have the related requirement from stage2, cannot be included in the scope. Regarding the work from GSMA on SEPP API enhancement, actually, I am not sure how many requirements will come, we can check the related work in GSMA, and perhaps it is better to not include this in the scope at the beginning. Bruno: This is fine. Note that discovery of a remote SEPP via remote NRF would anyhow need to send a discovery request to the remote SEPP, i.e. chicken and egg problem. Hiroshi: In conjunction with what has been discussed in the other thread with you and Bruno, I am fine to exclude any GSMA requirement to be included at this point.
4326	discussion Rel-17 Impacts of EDGEAPP to CT WGs	Samsung	Noted
4331	WID new Rel-17 New WID on Authentication and key management for applications based on 3GPP credential in 5G	China Mobile	Revised to C4-204355	CT3 lead CT4 impacted Completion date June 2021 WIC: AKMA-CT Zhenning: Draft revision 2 of C4-204331 new WID of AKMA have been uploaded. Changes 4 and 7-10 affect CT4: 1) ME impact is changed into "Don't Know"; 2) UICC APP impact is changed into "No"; 3) AN impact is changed into "No"; 4) Deriving the A-KID is added; 5) AKMA AF Key is changed into AKMA Key; 6) Impove the description of CT4 objective; 7) Adding a note to indicate potential impace related to CT1 could be further added when the evolution of the work; 8) CT3/4 responsibility are added; 9) Remove the impact of TS 29.509; 10) Hewlett Packard Enterprise, Nokia, Nokia Shanghai Bell, Qualcomm Incorporated are added as support company. Any further comments and support are welcome. Zhenning: Draft revsion 3 of C4-204331 new WID of AKMA have been uploaded. Main changes are related to CT1: 1) Shift the note to the normal word to indicate the potential CT1 impact; 2) Coodinate between CT1, CT3, CT4 and SA3 could be performed during the work. Any further comments and support are welcome
4355	WID new Rel-17 New WID on Authentication and key management for applications based on 3GPP credential in 5G	China Mobile
6	Release 17
6.1	CT4 Led WIs
6.1.1	Study on IETF QUIC Transport for 5GC Service Based Interfaces	FS_QUIC
4161	pCR 29.893 Rel-16 Update of the references	Huawei	Agreed to be incorporated
3GPP TR 29.893 v1.5.0	Huawei/Caixia
6.1.2	Service based Interface protocol improvements	SBIProtoc17
CC3	4059	CR 29.510 0369 Rel-17 NF discovery based on SUCI information	China Mobile	Revised to C4-204339	WI SBIProtoc17 CAT B See discussion paper in C4-204078. Anders: 6.1.6.2.7: Typo – AUSF -> UDM 6.1.6.2.x: In the Description, in addition to AUSF, also applicable to the UDM, suggest AUSF/UDM Yue: . Will take on board in the revision. Varini: Thanks for the paper. I want to request for a clarification on inclusion of suciInfos in the udmInfo/ausfInfo. Do we need AUSF/UDM NF Consumers to know which list of routing-identifiers map to which Public Key? As long as AUSF/UDM instance update the list of public keys they support, the requirement can still be met. From this point of view, maybe we can directly add array of hNwPubKeyId in udmInfo/ausfInfo? Yue: The motivation of this CR is described in C4-204078. In a nutshell, the Routing Indicator is not long enough to match the nunmber of number-ranges, and you can find more details regarding why the routing indicator shall match the number of number-ranges in the mentioned DISC. Actually the CR is not proposing a map b/w routing indicator and public key id, it is a combination of them. Varini: Thanks for the quick response. I went through the paper and agree with the intent – Routing-ID + Public-Key to serve as always-valid routing info, possibly driven from MSISDN, so as to avoid any impact of db migrations. With this change, an AMF, while performing AUSF discovery in NRF, can use both Routing-ID and Public Key in received SUCI, right? The question I have is - List of routing indicators is already present in the ausfInfo. If we simply add a list of public-keys to ausfInfo, that should suffice? Basically I am thinking if we duplicate Routing-Ids information – once in ausfInfo and once in suciInfo? Yue Regarding the AUSF discovery, yes, the AMF can use both information Regarding the duplicated Routing indicator in the NF profile. The reason for making (another) routing indicator and public key ID in one data structure is to express the combination of these two information. For example: An UDM supports RID#1+PKID#1, RID#2+PKID#2, RID#3+PKID#3, if the UDM registers RID and PKID in separate arrays like [RID#1, RID#2, RID#3] and [PKID#1, PKID#2, PKID#3], it may be interpreted as the UDM supports full-mesh combination of RIDs and PKIDs, e.g. RID#1+PKID#2 which is not actually supported by the UDM. Varini: Understood. Thanks for the clarification. Bruno: 1) I understand the problem statement that the current 4 digits of the Routing Indicator enables only 10 K ranges of subscriptions, which may result in too many users per range in an PLMN with a lot of subscriptions (e.g. 100 K users per range for a PLMN with 1 billion subscriptions), and therefore that there is not enough granularity/flexibility to support moving subscriptions across UDRs (not controlled by the same AUSF/UDM). So I understand that with your proposal, you use the Home Public Key ID to encode a 5th digit (+ the key ID on 4 bits) for AUSF/UDM discovery, that would result e.g. in up to 100 K ranges of 10 K subscriptions in my above example. Right? [Yue] Right. 2) Can you please explain how the proposal works in roaming scenarios. In roaming scenarios, do you expect the visited AMF to discover the AUSF/UDM using the home public key id? How does the visited network know that it should do so? How is backward compatibility supported? are the changes to be implemented only by the home PLMN, with requests being (often) forwarded to a different AUSF/UDM within the HPLMN? Yue] In the roaming case, HPLMN may deploy International AUSF (as usually done in the legacy networks where international GW-like functions are deployed for roaming usage). Then the AMF in VPLMN needs only to reach the International AUSF, that AUSF will subsequently discover UDM based on Routing indicator plus public key ID. Thus the impact on vplmn can be avoided. 3) The Routing Indicator may be used per existing stage 2 and stage 3 by all UDM consumers for routing requests towards the UDM serving the subscriber. See TS 23.501. Routing Indicator: Indicator that allows together with SUCI/SUPI Home Network Identifier to route network signalling to AUSF and UDM instances capable to serve the subscriber. NOTE 1: The UE provides the Routing Indicator to the AMF as part of the SUCI as defined in TS 23.003 [19] during initial registration. The AMF provides the UE's Routing Indicator to other NF consumers (of UDM) as described in TS 23.502 [3]. Yue] Yes, and this is the whole reason for my coming up with this CR. Routing Indicator was introduced to serve the routing purpose when SUCI is used, since the number range is encrypted in SUCI. Now it is identified that 4 digits Routing Indicator may not be able to serve the purpose in some networks. 4 digits Routing Indicator is obviously a miss design of protocol, thus should be fixed in stage3. In stage 3, see e.g. TS 29.502 where the routing indicator may be sent from AMF to V/I-SMF, H-SMF/SMF. or e.g. TS 29.518 where the routing indicator is forwarded to the target AMF during inter-AMF mobility. Should these SBIs be extended to also enable to forward the Home Public Key ID towards UDM consumers? If not, what does happen if e.g. the SMF or target AMF uses only the Routing Indicator to discover the UDM? Yue] As said above, Routing indicator was defined for SUCI, we shouldn't have overloaded it. 4) Your proposed updates would in any case require stage 2 changes in SA2 and SA3, see e.g. further excerpts from stage 2: Yue] My CR does not violate above text, Routing Indicator is still used for selection of UDM/AUSF. I don't think every factor which can be used for NF selection shall be explicitly described in SA2, e.g. supported-features, required-features, (if you have interest and time you may find more) 23.501 : The AUSF selection function in AUSF NF consumers or in SCP should consider one of the following factors when available: 1. Home Network Identifier (e.g., MNC and MCC) of SUCI/SUPI (by an NF consumer in the Serving network) along with NID (provided by the NG-RAN) in the case of SNPN and Routing Indicator. NOTE 1: The UE provides the Routing Indicator to the AMF as part of the SUCI as defined in TS 23.003 [19] during initial registration. The AMF can provide the UE's Routing Indicator to other AMFs as described in TS 23.502 [3]. [Yue] My CR does not change the truth that "The Routing Indicator in the SUCI can be used to identify the right UDM instance that is capable of serving a subscriber The UDM selection functionality in NF consumer or in SCP should consider one of the following factors: 1. Home Network Identifier (e.g. MNC and MCC) of SUCI/SUPI, along with NID (provided by the NG-RAN) in the case of SNPN, and UE's Routing Indicator. NOTE 1: The UE provides the Routing Indicator to the AMF as part of the SUCI as defined in TS 23.003 [19] during initial registration. The AMF provides the UE's Routing Indicator to other NF consumers (of UDM) as described in TS 23.502 [3]. 33.501 : 6.12.5 Subscription identifier de-concealing function (SIDF) SIDF is responsible for de-concealing the SUPI from the SUCI. When the Home Network Public Key is used for encryption of SUPI, the SIDF shall use the Home Network Private Key that is securely stored in the home operator's network to decrypt the SUCI. The de-concealment shall take place at the UDM. Access rights to the SIDF shall be defined, such that only a network element of the home network is allowed to request SIDF. NOTE: One UDM can comprise several UDM instances. The Routing Indicator in the SUCI can be used to identify the right UDM instance that is capable of serving a subscriber. Considering that stage 2 should then be updated to specify that the home public key could become a new criteria for selecting the UDM/AUSF, and specify how the proposal works in roaming scenarios (to ensure open interoperability), and whether the home public key should also be forwarded to other UDM consumers by AMF, and the earlier proposals have also been discussed in SA2 (even if not exactly the same as this one) and not pursued, we should not bypass SA2 but ensure first that SA2 is fine in principle with the proposed changes, that SA2 documents the enhancements first in stage 2, and then we can safely proceed with the required stage 3 impacts. So to be constructive and help addressing the aforementioned issues, if CT4 is fine in principle with the proposed changes, we propose to postpone the CT4 CR and to send an LS to SA2 reporting the issues, attaching the proposed CR, indicating that CT4 would be fine in principle with the proposed solution in Rel-17 provided stage 2 requirements are agreed first, and suggesting SA2 to consider possibly enhancing the selection of AUSF/UDM based on SUCI in Rel-17 to address the reported issues. [Yue] Last time (it was in R16) I raised this issue, and it was Nokia who proposed to go to SA2 first. Then my SA2 colleague brought the discussion paper to SA2, and it was Nokia again who objected to discuss this issue (if your SA2 colleague still remembers this). Please note that, in China Mobile network quite a number of vertical customers will use devices and NW compliant to R16, we already have the risk in our network. This issue has to be solved ASAP! Again, you propose to go to stage2, you must be aware of there is no time slot for topics other than the dedicated work items in SA2. Yes, you can argue that for those REAL important thing we still have chance to be discussed there. However, you must be also aware of how long this will take. PLEASE, do not delay the process that we want to solve a real problem. CC Yue Routing indicator of 4 digits is to small Bruno system wide impact, roaming scenarios are not mentioned, we need to make sure specifications are inline. We should send LS to SA2 attching the CT4 CR on which we have reached consensus. Wee should no bypass SA2. Yue: For roaming case the roaming AUSF is directly contacted We agreed to send an LS to SA2 in copy to CT and SA, SA3 CT4 Chair will request action in plenary to make sure that the LS is handled in Q4 If SUCI information is used in roaming scenarios depends on roaming agreements. This should be captured in a note as a hint to designers. The primary intention of the CR/solution is home PLMN specific. Yue: I have put the draft LS on the server ( inbox/draft/6.1.2 ). The revised CR is also attached
4339	CR 29.510 0369 Rel-17 NF discovery based on SUCI information	China Mobile	Bruno: I have uploaded an updated version with my proposed updates and comments: https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/6.1.2/draft-C4-204339-C4-204059-%2029510%20CR%20NF%20discovery%20based%20on%20SUCI%20information(%2Bbruno).doc One point I wish to clarify: In the CR, you wrote: NOTE 2: The combination of SUCI informations e.g. Routing Indicator, Home Network Public Key Id can be criteria for UDM discovery. This usage is only subject to the scenario where the AMF and UDM/AUSF belong to the same PLMN in this release. It is not clear to me what this means for roaming scenarios. I have changed the text to NOTE 2: The combination of SUCI informations, e.g. Routing Indicator and Home Network Public Key Id, may be used as criteria for UDM discovery. This may only be used by the HPLMN in roaming scenarios in this release of the specification, i.e. an AMF in a visited network does not use the Home Network Public Key ID for UDM selection. as I understood roaming scenarios would be supported, but with an AUSF/UDM in the HPLMN doing a new discovery with the new Home Network Public Key ID (+ routing ID) and forwarding the request to the right AUSF/UDM. Yue: You almost changed all the wording in the LS, I should have let you draft this LS... But I am fine with your text. As for the CR, comments from you (and also Marco) have been addressed. Just to clarify that, I included "supiType" in suciInfo data type simply because I thought it might be useful in the future, now I have removed it to save time. v1 uploaded to draft folder. Bruno: Thanks. The LS and CR revisions look fine. Please just add a NOTE for the home-pub-key-id query parameter : NOTE: This may only be used by the HPLMN in roaming scenarios in this release of the specification, i.e. an AMF in a visited network does not use the Home Network Public Key ID for AUSF/UDM selection. Also one small editorial (in 2 places): A SUCI that matches all attributes of at least one entry in this array shall be considered as a match of this information. Yue: Additional comments will be incorporated in the formal revision
CC6	4337	LS out LS on AUSF/UDM discovery based on SUCI information	China mobile	To: SA2 CC: CT, SA, SA3 Draft version provided: Bruno: I have uploaded an updated version with my proposed updates. https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/6.1.2/C4-204337-LS%20on%20AUSF%20UDM%20discovery%20based%20on%20SUCI%20information(%2Bbruno).docx Yue: You almost changed all the wording in the LS, I should have let you draft this LS... But I am fine with your text. Bruno: Thanks. The LS and CR revisions look fine. CC Yue will provide final version
4078	discussion Discussion on information used for AUSF/UDM discovery based on SUCI	China Mobile Com. Corporation	Noted	Bruno: See our related comments to C4-204059.
4094	discussion Rel-17 Evolution of UE Parameter Update mechanism	Ericsson	Varini Thanks for the paper. We agree there is a need to update the mechanism and support the same. Do we need involvement of CT1 too for this work as I believe there will be NAS impacts too? From what I understand, many of these SBI attributes are translated to corresponding NAS attributes. Ulrich: I agree, in the existing mechanism the UE parameters (if not is secured packet format) are not transparent to the AMF and the main disadvantage of this is that the old AMF not supporting the new UE parameter needs to be updated. However, which network node would provide/convert the UE parameter in AMF-transparent format? Is the intention that the operator’s provisioning at the UDR supports the transparent format?
4124	CR 29.571 0231 Rel-17 Ncgi typo correction	Nokia, Nokia Shanghai Bell	Agreed	WI TEI17 CAT F If this CR (no feature enhancement) is the only Rel-17 CR for this TS should this CR create a new TS or should we agree it for Rel-16.
4125	CR 29.503 0471 Rel-17 Adjacent PLMN restrictions	Nokia, Nokia Shanghai Bell	WI SBIProtoc17 CAT B Zhijun: In clause 6.1.3.5.3.1, do we really need the query paramter - "adjacentPlmns" to the GET operation to AccessAndMobilityManagement? Without such query parameter, the UDM will always return the adjacent PLMN restrictions. Ulrich: Having the list of adjacent PLMNs in the request message (as query parameter) aligns with existing Diameter S6a (see 29.272 clause 5.2.1.1.1). The intention is that the UDM does not need to send adjacentPlmnRestrictions if the query parameter was absent from the GET request.
CC5	4126	CR 29.503 0472 Rel-17 Network Slices in AMF registrations	Nokia, Nokia Shanghai Bell	Revised to C4-204441	WI SBIProtoc17 CAT B Yue What is the definition of "UE registers to NW slice"? If the UE only registers to the NW but does not establish any PDU session, is this UE counted? In CT1 there is a discussion on the complicated mapping b/w HPLMN S-NSSAIs and VPLMN S-NSSAIs. Suppose some HPLMN S-NSSAIs, say [h1, h2, h3] are all mapped into VPLMN SNSSAI say [v1], then how to count in this scenario? Ulrich: My understanding is that UEs can be registered (at AMF) without establishing any PDU session, and registrations count independent from established PDU sessions Yue: UE can be registered without establishing any PDU session, this is understood. My question is on "register to NW slice", if the UE has no PDU session agaist e.g. NS#1, can we say the UE has registered to NS#1? During the regsitration, the AMF only tells the UE which S-NSSAIs are allowed to be used when establishing PDU sessions, then does it mean the UE has registered to those S-NSSAIs? To my understanding, the purpose of counting the number of UEs is to analyze the usage of the NW slices, or potentially to limit the number of UEs that are using the NW slices. If the UE does not establish PDU session, it is not really using that NW slice. Ulrich: if the UE has no PDU session agaist e.g. NS#1, can we say the UE has registered to NS#1? Yes does it mean the UE has registered to those S-NSSAIs? Yes If the UE does not establish PDU session, it is not really using that NW slice. Yes, but it is registered. SA5 have defined different counters for PDU session Establishment success rate of one network slice (see 28.554) Varini Thanks for the paper. We agree with the intent and would like to co-sign. Just to add to Yue’s question #2 – I think AMF should update mapped home NSSAIs into UDM when the user is in V-PLMN. Ulrich: Thank you for co-signing Varini: IMO, an AMF too is part of slice. UE’s registration in an AMF is as good as UE’s registration in a slice. UE, for example, can use SMS services on eMBB slice without activating PDU session? Ulrich: discussions during this week have shown that Rel-16 is not too deeply frozen, so we may want to do the proposed change as cat F in Rel-16. Note that the requirement from 28.554 is also Rel-16 (or even Rel-15). Please find draft 4126v1 in the draft inbox Yue Though 28.554 describes (and only describes) there is a counter which counts the subscribers register to a network slice instance, the requirement is still not clear to me: which S-NSSAIs will be considered as the UE registered to, i.e. to be sent to the UDM, the S-NSSAIs contained in the "Allowed NSSAI" sent to the UE or something else? if the UE handover/TAU to 4G, is the UE still considered as registered to those network slices? if the UE registers via 3GPP and non-3GPP accesses in parallel, is the UE counted once or twice? Ulrich: my understanding is: The AMF, when it registers at the UDM, sends all S-NSSAIs it serves for the UE This depends on single/dual registration, i.e. whether or not the UDM sends a deregistration notification to the AMF. This is not relevant to CT4. I would assume the UE is counted once. Yue: Then should these be explicitly specified somewhere in stage2? Ulrich: I’m fine without any further stage 2 specification. Thank you. CC Yue: Proposes to send LS to SA5 Ulrich: 4126 has been revised to C4-204441 which has been uploaded to the meeting’s Docs folder. Please also find a new proposal for the LS in draft-C4-204421 UWv2 in the draft inbox.
4441	CR 29.503 0472 Rel-17 Network Slices in AMF registrations	Nokia, Nokia Shanghai Bell
CC6	4421	LS out Counter of UEs registering to Network Slices	China Mobile/ Yue	To: SA5, SA2 CC: CT1 Yue: The draft LS in 4421 is uploaded to inbox/drafts/6.1.2. NOTE: When drafting the LS, I thought it would be better to send the LS also to SA2 and copy CT1, thus I did so in the draft LS. Ulrich: thank you for the draft. Please find my proposed modifications in the draft inbox. Yue: Thank you for review and proposed update. However I am not very happy with the modification: whether or not CT4 has agreed 4126's revision is not directly relevant to this LS. For "CT4's assumption so far.....", I don't think CT4 has consensus on these "assumptions". We should focus on the questions. SA2 may updating their spec by adding the new IE, but this is not of my major concern. My concerning is less of description on AMF behaviour, e.g. when UE moves to 4G in certain condition, whether AMF should update UDM for this counting sake. CC Yue wants to trigger the discussion to initate the discussion in stage 2. Ulrich: we first need to check if we can agree on the CR and need to decide if we should attach the CR to the LS. Ulrich will try to make a proposal based on the discussion. Ulrich: Please also find a new proposal for the LS in draft-C4-204421 UWv2 in the draft inbox.
CC3	4128	CR 29.500 0147 Rel-17 3gpp-sbi-binding for member NF-instance/service within NF-Set/service	Cisco Systems	WI SBIProtoc17, SBIProtoc17 CAT B Giorgi: Could you please elaborate on the purpose and the usage of the "member-service"? I’m afraid the reason for change is little cryptic. Ravi) There was a typo in the Reason for change – “should the consumer wish to or have “ This is corrected and I have added additional lines to clarify it further. Do let me know if it is still not clear Also, here are some errors on the cover sheet: Revision 1 of which tdoc? Ravi) Corrected .Source to TSG: Ravi) Corrected WIC Ravi) CIam using SIBProt17 Clauses affected Other specs affected Ravi) Corrected Zhijun: I also have such question on how to use this "member-service". Bruno: Same questions from my side. What are the justifications for the proposed changes? Also in clause 6.12.x, what is this concept of "Group binding" ? Ravi: I have uploaded v1 of the document after incorporating your comments. Giorgi: I’m afraid I still need to do some guessing on the contents  Anyway, the membership would link e.g. two biding indications, right? I feel more detailed description of the feature usage is necessary Ravi The membership is to indicate the receiving side that there is one equivalent NF/Service which can be used in case the primary NF/Service fails. The membership will be indicated in another binding indication (both binding indication can go in the same service req/rsp). Hope this clarifies your doubt. Let me know if you have more queries or questions for clarification. CC: Bruno why we need this member service? All NFs in a set support the same features have same functionality. We do not have pool or group concept. Bruno the use case is not valid. Ravi will do some internal checks.
4136	CR 29.504 0101 Rel-17 Resource Level Authorization for Data Sets	Nokia, Nokia Shanghai Bell	Agreed	WI SBIProtoc17 CAT B
4137	CR 29.505 0292 Rel-17 Resource Level Authorization for SubscriptionData	Nokia, Nokia Shanghai Bell	Agreed	WI SBIProtoc17 CAT B
4138	CR 29.503 0473 Rel-17 Resource Level Authorization for UECM registrations	Nokia, Nokia Shanghai Bell	Agreed	WI SBIProtoc17 CAT B
4139	CR 29.504 0102 Rel-17 Resource Level Authorization for registrations	Nokia, Nokia Shanghai Bell	Agreed	WI SBIProtoc17 CAT B
4140	CR 29.505 0293 Rel-17 Resource Level Authorization for registrations	Nokia, Nokia Shanghai Bell	Agreed	WI SBIProtoc17 CAT B
4183	CR 29.510 0374 Rel-17 NF Discovery procedure enhancements	Nokia, Nokia Shanghai Bell	Postponed to next meeting	WI SBIProtoc17 CAT B Yue IMO, the "rank" attribute is a very ambiguous information which I suspect it does not really help. What's the criteria for the NRF to set the value of rank attribute? Based on different use cases, locations, UE IDs.... the importance of the query parameters may differ, then how does the NRF get the knowledge of which queries are more important thus the NF instances which match those queries should have a higher ranking? Caixa: For Rank IE, I may have the similar understanding as Yue. And additional comments from my side: 1. Compare with the list of URI, it is OK to return the NF instance ID list, the client can retrieve the NFprofile based on the NF instance ID? Bruno> the nfProfileURI actually contains the nfInstanceID (per existing 29.510 reqt). Returning a list of URIs follows the guidelines documented in 29.501 for discovering a collection of resources, also indicates the apiRoot of the NRF holding the profile and is also more future proof if we change later how the URI of an NF profile is built. 2. Coversheet:This CR introduces backward compatible new features in the OpenAPI YAML file of the Nnrf_NFDiscovery API, the changes are related to management API, which is different with the statement in coversheet. Bruno> the cover sheet is correct, but the heading of the OpenAPI section in the CR needs to be corrected to show A.3 (NFDiscovery) and not A.2 (NFMgt) Yue The NRF can of course use any factor for ranking the NF instances. However, my point is how to make sure that this kind of ranking makes sense to the NF consumer? For instance, the NF consumer includes preferred-api-version and preferred-locality, then how does the NRF know which one is "more preferred" by that NF consumer? Jones: For PreferredSearch result (preferred-Tai and Preferred-full-plmn), the current definition of NRF only return NF profiles matched preferred parameter, OR return not matched NF profile otherwise, i.e. there is no mixed scenarios: preferred-tai When present, the NRF shall prefer NF profiles that can serve the TAI, or the NRF shall return NF profiles not matching the TAI if no NF profile is found matching the TAI. (NOT E 5) preferred-full-plmn When present, the NRF shall prefer NF profile(s) that can serve the full PLMN (i.e. can serve any TAI in the PLMN), or the NRF shall return other NF profiles if no NF profile serving the full PLMN is found: - true: NF instance(s) serving the full PLMN is preferred; - false: NF instance(s) serving the full PLMN is not preferred. (NOTE14) Bruno> indeed, and this is definitely one restriction/limit of the existing specification. A discovery request may contain one or more preference parameters, and forcing to only return profiles that match all a certain preference parameter or none is unnecessary limitative. The proposed change modifies the definition of current behavior, which is not backward compatible in my view. E.g. if AMF discovering SMF with preferred-tai received a search result indicating false (in this CR, it could be mixed result), the AMF will consider no matching and directly select I-SMF. Bruno> The CR does not intend to change the existing behaviour, when the new feature is not supported or not used. When the feature is supported/used, the discovery response can contain a mix of profiles supporting and not supporting a given preference parameter (i.e. which removes the unnecessary restriction). I assume you refer to the changes in clause 6.2.6.2.6, for the ‘false’ value, whose description was not very clear, I will correct the text to say that ‘No NF profile matches the query parameter.’. NfInstanceInfo contains absolute URI of the NF profiles, and it is also indicated that “If the response includes a list of URIs of NF profiles, the NF Service Consumer may retrieve the NF profiles using the NF Profile Retrieval procedure (see clause 5.2.2.9).” which is slightly conflicting with each other. How should an NF consumer perform “NF Profile Retrieval procedure” with an absolute URI? Or the NF consumer simply perform a GET towards the URI to fetch the NF profile? Isn’t returning NfInstanceId more efficient and reasonable? Bruno> the nfProfileURI actually contains the nfInstanceID (per existing 29.510 reqt). Returning a list of URIs follows the guidelines documented in 29.501 for discovering a collection of resources, also indicates the apiRoot of the NRF holding the profile and is also more future proof if we change later how the URI of an NF profile is built. Search result with URIs are not very efficient which requires the NF consumer to acquire the NF profile with extra transaction per NF profile, once at a time. Bruno> the existing solution results in very large payload size of the discovery response, causes extensive data to be sent to NF service consumers, signalling overhead in the network and/or limits the number of candidate NF profiles that can be returned to the requester NF, and hinders HTTP caching for subsequent requests. The proposed solution complies with the 29.501 guidelines for retrieving list of resources, and adding the option to return list (possibly in addition to NF profiles) becomes more and more justified considering the growing size of the NF profile (e.g. UDM profile found to already exceed 2 million octects). This is a typical HTTP design pattern. See all the benefits listed in “Other comments” NF Discovery and NF management may use different Security schema, especially we are introducing resource level authority which may allow an NF consumer to subscriber for NF profile change but not fetching… Bruno> I am not aware of any CR proposing so for 29.510. And already today, both NF Mgt and NF Discovery APIs are used for discovering an NF and for subscribing to NF changes. For the mechanism with searching ID, I don’t think we really need to caching the search result composed with NF profiles data, only candidate list is to be kept (e.g. list of NF instance Ids). It doesn’t introduce very big problem for NRF in my view. Bruno> the CR does not modify this option. But when supported, it requires the NRF to cache thousands of search results (without knowing whether the NF service consumers will retrieve them), this results in the NF service consumers downloading twice the NF profiles that were already part of the initial discovery response, and this results in sending extensive NF profiles data to NF service consumers (i.e. all NF profiles of the complete search result Jesus: Let me follow up on one of the comments brought up by Jones, regarding the retrieval of the NFProfile based on a "nfProfileUri". My concern is also related to the distinct APIs in the NRF (NFManagement vs NFDiscovery), but not limited to the potentially different security requirements, as Jones pointed out, but most importantly in relation to the contents retrieved in each API, for a given NF Instance ID. In NFManagement, the retrieval of an "nfProfileUri" will result in receiving the exact same resource representation as it was registered by the NF Producer, when it used the NFRegister service operation. In NFDiscovery (where "nfProfileUri" does not exist), the content of the profile of such NF Instance ID, is the result of trimming down the "raw profile", and accommodate it to several filters based on permissions, query parameters, etc…. As an example, an NF Profile retrieved by a consumer in a discovery response will be filtered down based, e.g. on the respective slices of requester and target NFs. However, such NF Profile, if retrieved via NFManagement, will contain ALL info about ALL slices supported by the NF producer. When we have discussed this same issue, in the past, Nokia has expressed their strong will to keep the NF Consumer "view" of the NF Profile received in the discovery response restricted to only the set of data that the consumer is entitled to see. With the proposal given in the CR, I don't see how this can be achieved. Bruno: Thanks. Yes, this is a valid point. Couldn’t this be addressed by extending the profile retrieval request (GET) with the same requester parameters as we have in the Discovery request? Another possible option could be to use the NF discovery procedure for retrieving the NF profile of a specific NF instance ID (possibly defining one new parameter to convey the apiRoot of the NRF hosting the profile). Jesus: Yes, I also thought about options, in particular this one: to use the NF discovery procedure for retrieving the NF profile of a specific NF instance ID (possibly defining one new parameter to convey the apiRoot of the NRF hosting the profile). However, this will make one Discovery request returning 100 instances to be converted into 100 Discovery requests (all of them having most of the query parameters that the original discovery request had). So, the impact on the NRF will be exceptionally high. To be honest, none of the alternatives sounds appealing enough to me and, to say the least, I think that the proposal deserves much more thorough thinking (to avoid situations such as the unfortunate R15 issue we had to fix in the last meeting, due to overlooks similar to this one). Bruno: This is why our CR proposes to use the NF profile retrieval procedure. We can certainly check the proposal further to ensure we won’t fall again with similar issues as we had in Rel-15. But why would it be an issue in principle to extend this procedure with the requester’s parameters? At very least, we (CT4) need to agree on whether we should consider enhancing the existing discovery procedure in Rel-17, to address the issues raised in the reason for change, and specifically the following points. This is the starting point for any work on this in CT4. We think we should. NF Discovery responses returned by the NRF typically contain the profiles of multiple NF service producers matching the query parameters. The size of each NF profile can be very large (e.g. UDM profile sizes have already been found to exceed 2 Million octets in some network deployments based on 3GPP Rel-15). This can result in very large payload size of the discovery response, in limiting the number of NF profiles that can be returned to the requester NF, and in hindering HTTP caching for subsequent requests (since doing so would lead to excessive data to be cached for every request with different query parameters sent to the NRF). An NF Discovery Response may contain a "searchId", to enable server-side caching of the search result and enable NF service consumers to retrieve the complete search in a subsequent request, but a) this requires the NRF to cache thousands of search results (without knowing whether the NF service consumers will retrieve them); b) this results in the NF service consumers downloading twice the NF profiles that were already part of the initial discovery response, c) this results in sending extensive NF profiles data to NF service consumers (i.e. all NF profiles of the complete search result). Consequences if not approved: Very large payload size of the discovery response, causing extensive data to be sent to NF service consumers, signalling overhead in the network and/or limiting the number of candidate NF profiles that can be returned to the requester NF, and hindering HTTP caching for subsequent requests. The NRF needs to to cache thousands of search results (without knowing whether the NF service consumers will retrieve them). Jesus I agree with pursuing a solution to the problem described in the cover sheet of the CR. My comment was that the solution needs to be more carefully thought. From the 3 approaches we have seen, the current proposal in the CR cannot be accepted because it does not work as intended. The other 2 alternatives need to be further evaluated. The option to extend the NF profile retrieval procedure can be considered but, as it has been said in the past, this procedure was mainly designed to be used by the NF producer (the owner of the registered resource), or by O&M center that manages the registration on behalf of the producer. It was not meant to be a pseudo-discovery request. But certainly we can evaluate this approach, along with several other approaches (it quickly comes to my mind to maybe extend the discovery service with new resources, rather than extending the management service). So, my proposal would be to evaluate alternatives during the R17 timespan, but not to rush anything in this meeting (give the limitations spotted in the CR in its current form). How to proceed with the CR, should we postpone and have a discussion paper in next meeting comparing the solutions/alternatives in detail?
4328	CR 29.503 0487 Rel-17 Shared Data Treatment	Nokia, Nokia Shanghai Bell	Agreed	WI SBIProtoc17 CAT B
6.1.3	BEst Practice of PFCP	BEPoP
CC3	4028	pCR 29.820 Rel-17 Clarifying the scenario types	Huawei	withdrawn	Yue: For my clarification, with the proposed update do we still support the combination of scenarios? For instance: If the UPF is deployed in "vertical network operator", then is it still supported that multiple UPF controlled by one SMF? I mean, does it match "Both CP and UP functions are run by the same mobile network operator"? Giorgi: No, if SMF operator does not have O&M access to UPFs If the UPF is deployed in "enterprise", then is it still supported that multiple UPF controlled by one SMF? I mean, does it match "Both CP and UP functions are run by the same mobile network operator"? Giorgi: Once again, the answer depends on whether the SMF operator does or does not have O&M access to UPFs Yvette: My question might not be directly related to your pCR but is scenario#6 really needed? It would be rather put as a generic requirement applicable to all, not a different use case. By the way the wording „run“ is a bit unconventional;-). Giorgi: I will replace ‘run’ by ‘managed’ in the revision. Don’t have a strong opinion on #6, but I belive it should be considered Yvette: No strong opinion. That is fine. Chenxi: there is a typo in the "reason for change", This group of scenarios is different from scenario #6 #5, where CP and UP functions are run by two operators, Besides, I am wondering if it is really needed to add the clarification about CP and UP functions runs by the same operator or not for different scenarios, since this may limit what we could study on a long view, could you explain the necessity on that? Frank: I don't get the motivations for changes for scenarios 1-3 and 6. In my view, scenario 1-3 is describing different network topology, which is independent if CP and UP are from the same operator or not. I am also not sure why for scenario 6, CP and UP have to be from the same operator? In the reason for change, " This group of scenarios is different from scenario #6, where CP and UP functions are run by two operators, despite the fact the "customer side" may not be a network operator in a traditional sense.", you meant for scenario #5? Giorgi Thanks for the comments, I’ll fix the typo in the reason for change (replace #6 with #5). Back to the goal of the pCR. I am trying to group the scenarios based on certain commonality, which should simplify discussion and also finding solutions. Now, one of the fundamental differences between these scenarios is if CP and UP functions are managed by the same operator or not. Point is, if a single operator has O&M access to the CP and UP functions, the operator should be able to fix most of the issues that will be identified by the study. Concerning scenario 6, I have to agree with Frank. In principle it is possible that two operators are provided with CP and UP functions from a third cloud operator. I will remove the proposed change to #6. Bruno: regarding scenario 5, what does “Customer side may be a vertical network operator, or an enterprise” really mean? Do you mean “UPF can be deployed in a vertical network operator or an enterprise’s site” (while it can still be managed by the mobile operator)? What about scenario 4? regarding scenario 5, what does “Customer side may be a vertical network operator, or an enterprise” really mean? Do you mean “UPF can be deployed in a vertical network operator or an enterprise’s site” (while it can still be managed by the mobile operator)? What about scenario 4? Giorgi: I’ll upload revised versions in a minute. For #5, I meant this: Customer side may be a vertical network operator, or an enterprise. CP and UP functions are managed by O&M of different operators. For #4, I thought it implies multiple operators manage CP and UP functions. Giorgi: Revised pCR 4028_1 is in Drafts/6.1.3 folder CC We need to clarify the key issue independent of this pCR
CC3	4029	pCR 29.820 Rel-17 Key issues - general	Huawei	Revised to C4-204346	Yue: Well, I don't know "how to say" :) But the reason for having this whole WID at all, is the text proposed in this CR is NOT true. Chenxi: In this pCR you made an assumption that stage 2 and stage 3 specifications provide for the interoperation between the standards compliant implementations of the CP and UP functions from different vendors in these scenarios. IMO, since different vendors implement their CP and UP functions with different mechanism,e.g. support different features , choose different mechanisms if multiple option existed, it is not easy to say that today's specification ensure the effective interoperability between CP and UP functions from different vendors. and that is one of the reasons this BEPoP WID raised. So I think this assumption is not appropriate and this pCR is not needed. Giorgi: Ok, I see your point, but the statement still stands. I’d propose to add new statement to that, which explains why the existing mechanisms are not sufficient. Something along the lines you just explained: “…different vendors implement their CP and UP functions with different mechanism, e.g. support different features, choose different mechanisms if multiple option existed, it is not easy…”. I’ll update the paper to cover this Frank. I don't really get any motivation on the change, the proposed text in General clause is difficult to read, and may not be suitable here. How to proceed with this CR Giorgi Revised pCR 4029_1 is in Drafts/6.1.3 folder CC Giorgi would prefer to have all key issues in same style/structure. Frank We should give some guidelines how to write key issues and solutions. Bruno shares the view. We need to have description of key issues consistent. Giorgi: I updated the paper after our agreements during today’s telco. 4029_v2 is in the Drafts/6.1.3 folder. If the provisions are acceptable to all, please update your BEPoP pCRs to match the template in 4029_v2. CC4 Deleagtes are aske d to check the pCR and if no comment s delegates with Key issu pCR shall align their CRs.
4346	pCR 29.820 Rel-17 Key issues - general	Huawei	Agreed to be incorporated
CC3	4058	pCR 29.820 Rel-17 Key issue of maintenance of NF deployed on customer side	China Mobile	Chenxi: 4058 overlaps with CATT's 4131, merging is needed. Since the "transmitting pre-configuration data" aims at providing mechanisms to ensure the non-conflicting and efficient interoperability between CP and UP functions as mentioned in 4131, is it OK for you to merge 4058 into 4131 and add China Mobile as co-source? Giorgi: I believe the part that starts with “It should be possible to provide…” rather belongs to the potential solution section. I’d propose to remove this from the CR. Concerning the key issue, O&M also handles alarms, performance reporting, etc. Should we add also these to this key issue so that the potential solution would address all at once? Bruno: Can you please clarify the following aspects: 1) if IP connectivity is enabled for N4/N3/N6, why cannot it be open for OAM? [Yue] Customer is always customer. If you talk with a dozen of vertical customers, you get mad. Their security policy open minimum gate for traffic which is directly impacting their service logic, O&M may unfortunately not considered Bruno> so do you suggest that OAM (config mgt, fault mgt, performance monitoring, …) isn’t directly affecting the service logic? How can a vertical / enterprise operator opens N4/N3/N6 but prevents the mobile operator - who is responsible for operating the UPF (cf your answer below)- from accessing the management functionalities of the UPF ? Please capture the above in the pCR. (note: T3 for LI also requires enterprise to open firewall for this protocol too) [Yue] True, but LI is something we shouldn't discuss here and shouldn't expect to have the fair treatment. 2) who is responsible for operating the UPF (software mgt, configuration mgt, alarm/fault mgt, performance monitoring, tracing) and debugging issues: the mobile operator or enterprise/vertical operator? Yue] Operator. But in the scenario I described above, most of the work will be done offline, I mean we send engineers to the customer if needed Bruno> I assume you mean “mobile operator”. How can the mobile operator operate the UPF and ensure that it works according to the service level agreement and committed performance/capacity with the enterprise/vertical operator, if the mobile operator cannot get alarms, KPIs in real time and cannot have access to the UPF configuration. Do you send engineers to read the alarms, KPIs? Please capture the above in the pCR 3) there is more configuration data in the UPF that may need to be changed by the mobile operator than just the pre-defined rules. So what about all such configuration data other than pre-defined rules? Yue] I agree that there are more config data in UPF, but many of them are initial configurations and not need to be changed during the service runtime. If some config data does need to be changed, and again in the scenario described above, do it offline Bruno> some data (“many of them”) may not need to be changed often/usually during service runtime, but still configuration data that may be changed during service runtime expands beyond pre-defined rules. Please capture the above in the pCR 4) I agree with Giorgi that the part that starts with “It should be possible to provide…” belongs to the potential solution and should be removed from this CR. We should really here focus on well defining what are the exact issues. [Yue] It is not pure solution, I may describe it like "It should be possible to provide the following pre-configuration data even when the O&M connection cannot reach the UPF", does it work for you? Bruno> by the way, why do pre-defined rules need to be modifiable online? why cannot they configured at setup, or “modified on customer site” as you say above? Can you please explain and clarify in the pCR. Besides, pre-defined rules are very tightly related to UP implementation. The expression of the policies could become very complex. The contents of the rules supported by PFCP are limited and do not allow e.g. to provision rules or PDR with advanced or operator specific reqts, or even some simple specific traffic patterns (e.g. ICMP traffic to detect IPv6 Neighbour Solicitation). Also, policy config’s are NOT just about PDR/QER/URR ID , there is lot more specific information which is associated to achieve the final use case for example what kind of actions one would take when the traffic exceeds, whether the usage exceeding causes it to block some traffic etc and all these behaviours should be permitted by just activating and deactiving predefined rules as done by PCF. Are we going to standardize all these rules and extra configuration too to make it work as whole use case? I mean this cannot be ultimately a simple CR just adding configuration of rules over N4. >>Concerning the key issue, O&M also handles alarms, performance reporting, etc. Should we add also these to this key issue so that the potential solution would address all at once? [Yue] Well, I am fine with adding these, given others do not object. Bruno> yes, this should be added, as I do not see how the mobile operator can operate the UPF w/o getting real time alarms and KPIs. And this should also expand the configuration data beyond the pre-defined rules. 4058 and 4131 are clashing CC Yue will reply.
4075	pCR 29.820 Rel-17 Additional Requirements	Deutsche Telekom AG	Revised to C4-204419	Giorgi: I have a question for clarification. Currently, PFCP mandates that CP and UP functions negotiate supported feature prior to session establishment. Which scenarios are not covered by this functionality? Yvette: There are „requirements“ listed as part of “Overall requirements”. Right now I only see interoperability issues, customer-side deployment and protocol extensions for unsupported features. But according to the objective of the SID (to study whether it is needed to enhance how SMF discovers the feature supported by UPFs, in particular for deployments mixing UPFs with different PFCP capabilities) this should also be mentioned inside the overall requirements. Hope I answer your question. Giorgi: Thanks Bruno: suggest to enhance the wording of Reqt 4: "Requirement#4: For use cases where multiple (not set) CP functions are considered" e.g. "where multiple CP functions not part of an NF set …" Yvette: I was struggeling to have a simple description dintinguishing multiple CP functions vs set of … for the case of CP functions. But your suggestion is perfectly fine. I will provide a V1 version of the pC (in draft inbox).
4419	pCR 29.820 Rel-17 Additional Requirements	Deutsche Telekom AG
CC3	4114	pCR 29.820 Rel-17 Key Issue - Feature Classification and Feasibility for Different Services	ZTE	Merge into 4132	Clash with C4-204132 Chenxi 4114 overlaps with CATT's 4132, merging is needed. Since the "necessary functionality set of PFCP for different use cases " is a more general expression in 4132 and "Feature Classification" in 4114 is actually a sub-issue in 4132, is it OK for you to merge 4114 into 4132 and add ZTE as co-source? Zhijun: I am fine to merge them. You can take "feature classification" concept into the merged PCR as one point need to be considered. Let's see how to merge them. Frank: I am not really sure if it is a valid key issue. In PFCP protocol, we have introduced a number of features, basically these feature can be catagoried into either general protocol enhancement, or related to certain SA2 feature WI. If it is a general protocol enhancement, it is of course independent on the end user (human or machine); if it is SA2 related, SA2 should have defined what feature is intended for. On the other hand, the UP function has no idea if it is human or machine device for a given PDU session. I agree we may enhance the description of the features as specified in 8.2.25, however, it sounds to me, it is not a key issue? Or I have misunderstood your intention, are you thinking, for a given PFCP session, which feature it is applicable, so to enable UP to arrange the resource? Zhijun: The intention is to figure out which feature is applicable for specific services e.g. Vertical-LAN, V2X, URLLC, etc, among all those features. Or, in other words, if an operator want's to deploy simple Vertical-LAN service for enterprises, what kinds of features are required as mandatory. I.E. find out the minimal feature sets. Basically, the idea is something similar as in C4-204132. And we would like to merge C4-204114 into 4132
4115	pCR 29.820 Rel-17 Key Issue - Header Enrichment for HTTPS	ZTE	Revised to C4-204371	Chenxi: I understand the security sensitive issue you mentioned in the Description, however I am wondering if it is appropriate to enrich the HTTPS header, since the original intention of HTTPS is to ensure the security of user information, if the HTTPS header is enriched with user's IMSI ,IMEI information, there may add new security issues for user data transmission, and may lead to user privacy issue too. so maybe some extra mechanisms are needed here to make sure that the "HTTPS header enrichment" is security and this kind of description needs to be added in this proposal. Zhijun: As I known, lots of operators have such requirement to carry customized information when using HTTPS schema instead of HTTP schema. Of course the HTTPS is used to secure the user information, but operator still have the requirement to track the user who invokes the service. Legal interception supports such kind of requirement. To be noted that, the customized information is provided to the HTTP server, but not to another third party not involved into the service. So the privacy issue you worrying about doesn't exist. But of course, IMSI/IMEI just an example, and if operator don't want to expose IMSI/IMEI then MSISDN is used. I can correct this in PCR to ease mis-leading. Zhijun: Forgot to mention an important point. The customized information carried in additional SSL/TLS extension can also be encrypted by some methods, which may be pre-configured to both the operator's UPF and the HTTP server. I will further clarify this point in the revision. Chenxi, Thanks for the clarification and I am OK with it, just as you mentioned, a little modification is needed here Provide revision Zhijun: have uploaded the revision - v2 to the server: https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/6.1.3/C4-204115_v2_BEPoP_29820_KI_Header%20Enrichment%20for%20HTTPS.docx Chenxi: Thanks, the content is OK for me, but there is a indent problem for the three bullets~ Zhijun Thanks, I will fix it when generate formal revision Caixia: Thank you for your draft revision. I do not think we can study this directly in CT4, this should also be done by SA3. Zhijun: It doesn't impact SA3, as the N4 is totally controlled by CT4, and using applicaiton level encryption is just under operator's control. What really missing is how the SMF instruct the UPF to perform Header Enrichment for HTTPS, and how does the UPF do against the instruction. Frank: Thanks for the revision. However, I don't think v2 is agreeable, the new aspect "How to ensure that security sensitive information attached to the service request from the UE is transmitted in a safe way? " need to be further discussed, not sure if there is any requirement. On the other hand, v1 is fine with me. Zhijun: I can simply remove the new bullet. Original thinking is to reflect the comments from Chenxi. We can remove the third bullet, and keep in mind that there may be such consideration Frank: Sure, we can come back with the bullet with a new paper, where hopefully the use case or problems can be clearly identified.
4371	pCR 29.820 Rel-17 Key Issue - Header Enrichment for HTTPS	ZTE
CC3	4116	pCR 29.820 Rel-17 Solution for Header Enrichment for HTTPS	ZTE	Revised to C4-204372	Giorgi: Please elaborate on how the proposal ensures that sensitive identifiers, like IMSI, MSISDN, IMEI are not exposed. This issue should be explained explicitly Zhijun: As I explained in the email thread of C4-204115, the customized information carried in SSL/TLS extension can also be encrypted, by some methods which are known to operator's UPF and the remote HTTPS server. I added the following text in the v1 to reflect this consideration: If security sensitive information is carried in additional SSL/TLS extensions, such customized information should be secured by certain encrypt methods which are known to the operator’s UPF and the remote HTTPS server, e.g. by pre-configuration. And, v1 is uploaded now: https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/6.1.3/C4-204116_v1_BEPoP_29820_Solution%20for%20Header%20Enrichment%20for%20HTTPS.docx Giorgi: Thanks for the explanations. I agree with Caixia’s comment to the linked pCR in 4115. This issue should be studied at SA3, to start with. Zhijun: As I respond to Caixia in another email, I don't think it should be start from SA3, as SA3 doesn't take care of N4 procedures, and SA3 doesn't take care of any improvement on PFCP. Generally, if user identifier is required to be inserted in HTTPS messages, it is the MSISDN (not the IMSI/IMEI, I apologize for the wrong example). As the MSISDN is not so much security sensitive, we don't think there is too much related to SA3. In addition, as the operator can use any other encrypt method not defined by 3GPP to encrypt the informations carried in HTTPS traffics, it is also not related to SA3 security mechanism. Even if people think there MIGHT be some relationship with SA3, it should be done when we do evaluation to the solutions, but not from the begining. Bruno: "And set the Protocol Type to “SSL/TLS” (or set to “HTTPS”).": does this refer to the Header Type of the Header Enrichment IE? Where is this protocol type to SSL/TLS? Does this target SMF / UPF only or also PGW-C/PGW-U? Zhijun: Yes, it refers to the protocol type when setting the Header Type of Header Enrichment IE. This is new requirement to 29.244, currently we only have the "HTTP" protocol type. As this is R17 study, the aim is to target SMF/UPF. But if it is also useful and applicable to PGW-C/PGW-U, we are fine to extend it. Bruno: Thanks. Can you please clarify these points in the pCR. Zhijun: Yes, I have change the "protocol type" to "Header Type" as per 29.244 defination, also updated the SMF/UPF to CP/UP Function . And v3 is uploaded to the server Frank: I have some difficulty to understand the following statement, and request to remove it; and you can come back at next meeting with detail explanation how this exactly work and why it is needed. " If security sensitive information is carried in additional SSL/TLS extensions, such customized information should be secured by certain application level encrypt methods which are known to the operator’s UP Function and the remote HTTPS server, e.g. by pre-configuration. " Chenxi: IMO, the statement below should be kept. In the v0 of this pCR, it states that IMSI/IMEI could be added in the HTTPS header, but there is a risk of user information being exposed. I specified this issue to Zhijun, so if we want to add security sensitive information in the header, some security mechanisms should be used e.g. encryption. Zhijun: Yes, the intention is IF there is requirement to carry some security sensitive, it deponds on the agreement between the operator and third party to select some application layer method to e.g. encrypt the information. So here I use "SHOULD" word Caixia: For this key issue, we shall consider the following issues: Whether the sensitive information will be included, or only the insensitive information is included? Zhijun: In normal requirement, the MSISDN is sufficient for the operator/third party to locate the user, which means normally there is no need to include IMSI/IMEI in the TLS extension. But if there is potential requirement for this, an application layer mechanism is succificent, which is under operator's control. Expose the user’s sensitive information in internet, I see the security issue, and as I indicated, I still think it shall be evaluated in SA3? Zhijun: I don't think it is SA3's aspects, if operator decides to use application layer method to encrypt the customized information in TLS extension, because it is totally the application layer agreement between operator and third party. Even how to encode the customized information in TLS extension, is totally out of 3GPP scope. For SSL/TLS, which version you mentioned? SSL 2.0, SSL3.0, TLS 1.2 TLS 1.3? Zhijun: Normally, in current IT enviorment, it is TLS1.3 used. Corrected in follow up email TLS 1.2 Zhijun: In general, our focus should be put on how the SMF instruct the UPF to do Header Enrichment for HTTPS, i.e. N4 impacts, and UPF necessary behaviours. Maybe when we do solution evaluation, we can ask SA3 that: do you see any potential issue on this mechanism, and expect some opinion from SA3. How do you think?
4372	pCR 29.820 Rel-17 Solution for Header Enrichment for HTTPS	ZTE
CC6	4129	pCR 29.820 Rel-17 Key Issue on Interoperability issues caused by multiple CP and multiple UP functions	CATT	Editorial remark: Use clause not subclause Giorgi Concerning this: “Identify how to ensure the interoperability if CP function(s) and/or UP function(s) are from different vendors”, I’m keeping asking the same question, which is why the current feature negotiation is not enough? Varini: I agree with Giorgi, maybe we need to have key issues with specific inter-operability problems? Current text of key-issue does not highlight any interoperability issue that needs to be fixed Chenxi: It looks like there are several questions raised for your 4028 and 4029 from Yue, Koza, Frank, me, et al related to what your mentioned below . IMO, I am not saying that CP and UP functions from different vendors cannot be implemented to work together currently, but there are risks that they cannot work non-conflictly and efficiently due to different mechanisms implenented. There are many examples, like the UE IP allocation issue, the End Marker issue, the downlink buffer issue, etc. Besides, there are two more bullets to clarify other issues to be identified in this pCR. So it is really cannot say that it can "ensure the interoperability if CP function(s) and/or UP function(s) are from different vendors " based on current specifications. Giorgi: I believe these pCRs are starting to achieving their goal. I am uneasy with generic statements that things don’t work. What we need is a an explicit list of use cases that prove things are not working. Let me try revising 4129 to document the above. Chenxi: If you want to make a revision of CATT's 4129, it is OK for me. We can discuss it then Giorgi: Sorry I’m lost. In the message you discussed 4028 and 4029, while the subject reads 4129. Apart from that, I’m planning to revise only my pCRs  Frank: While agreeing comments from Giorgi and Varini, I have some further comments: In the description, it would be good to highlight which network scenarios you are trying to deal with, I am assuming you are targeting scenarios 1-3? Chenxi: yes , I will add this description in r1 Could you please clarify the bullet " Identify which factors need to be considered to ensure continuity of the PDU session when the UE moves if multiple CP functions and/or multiple UP functions exist."? What issue may be in relation to UE mobility in those network scenarios? Chenxi: for example, if UE moves to a different SMF/UPF area in which the new SMF/UPF may have different functionalities than the old ones, we need to identify the factors to select the appropriate ones that meet the ongoing PFCP reqirements to make sure the continuity Even for the first bullet, what is missing in term of selecting a UP function for a given PDU session? Or in such network scenarios, what extra aspects need to take into account? Chenxi: if there are multiple UPF with different functionalities to be selected, there is a need to identify what factors need to be considered. I think DT' 4075 is related to this topic Bruno: I also agree with the previous comments. Additionally, the last issue/bullet is actually independent from whether there are multiple CP or UP functions. Giorgi: I would like to use this pCR for raising another generic matter. Some pCRs are well structured, but some are not. Can we agree on the following format? Each new key issue should have two parts, a Description and a Proposal Description part should provide the details of the identified problem, which is also a justification of the proposal Proposal part should be short and to the point, pretty much like a requirement, which the key issue needs to address What you reckon? Chenxi Draft 1 provided Caixia: I think we discuss the CP and UP come from different vendors, PCC rules is sent from PCRF, why it shall be considered in Interoperability issues caused by CP and or UP functions? Chenxi: OK, I will remove the "PCC rules" in the next revision Chenxi: The v1 of 4129 is uploaded with title changed, now this pCR focuses on “different vendors”issue，please check: @Caixia, please see my reply inline: Frank: Thanks for the revision. However, I don't agree with the revision. In my view, the key issue need to be substantive, in the network scenario 1# to 3#, different UE IP Address allocation mechanism is already worth to be a key issue, which includes many different aspects, e.g. CP or UP allocation method conflicting, the impact on restoration, UE IP address pool managing… I am not sure what are problems with " different timer value, different load capacity, different overload control mechanisms, different CP/UP function selection algorithms, different PCC rules ", we need identify the problem and issues. 5.X Key Issue #X: Interoperability issues caused by CP and/or UP function(s) come from different vendors As described in Scenarios 1-3 in overall requirements in 3GPP TR 29.820, interoperability issues can arise when CP and UP function(s) come from different vendors. For instance, different IP address pool planning, different timer value, different load capacity, different overload control mechanisms, different CP/UP function selection algorithms, different PCC rules, etc. Solutions for effective interoperability mechanism between CP and UP function(s) which come from different vendors need to be identified. This key issue shall study solutions to: - Identify the factors that may affect interoperability when CP and UP function(s) come from different vendors and the solutions to these factors. Chenxi: these are just some examples that may cause interoperability issue. I am open to modify these examples to make it substantive, e.g. we can remove "UE IP Address pool planning", "PCC rules" to make it more certain to the topic. Any suggestion?~ CC Frank we some more background why we need this. What is really the issue/ the problem? Chenxi will provide detailed examples . Frank possibly having a key issue per problem. Giorgi: the template for Key issues should be used C4-204346. Key issues should clearly identify the problem. CR could be split in multiple key issues if useful.
4130	pCR 29.820 Rel-17 Key Issue on Interoperability issues caused by multiple options co-existence	CATT	Add china mobile as co source? Chenxi with some wording change Draft 1 provided Caixia: Typo: As described in in clause 3 in the WID Chenxi: OK, I will fix this in the next revision Chenxi The v1 of 4130 is uploaded with some wording change, please check: @Caixia, please see my reply inline:
CC3	4131	pCR 29.820 Rel-17 Key Issue on Interoperability issues caused by vertical industry	CATT	4058 and 4131 are clashing and should be merged which one to use as basis Add china mobile as co source? Frank: I don't think the proposed study as below is under CT4 remit, this should be done by SA3. - Identify mechanisms for protecting customer's privacy under the premise of ensuring non-conflicting and effective CP and UP interoperability. - Identify mechanisms for authorizing customers to customize the functionalities of PFCP to their needs (e.g. add or remove certain features) under the premise of ensuring non-conflicting and effective CP and UP interoperability. I suggest you can merge the contribution to CMCC's (4058). Chenxi Thanks for your comment, let me explain here. these two sub-issue are not related to certain security method which should be studied by SA3, but the mechanisms to provide customer privacy and autonomy, e.g. as It is stated in this pCR, add or remove certain features. Thank for your suggestion, we have asked CMCC for the merging, still waiting for the reply~ Bruno: I also suggest using 4058 as baseline. So see also my comments to 4058. Heading should reflect UPF deployed on customer side, rather than Vertical industry. As described in Justification in subclause 3 in the WID of BEPoP (C4-203630), vertical market is estimated to be the most important use case of 5G, where UPF is very likely to be deployed locally on the customer side: Bruno> We should use the same wording as in Introduction of this TR, i.e. "-Vertical market is one important use case of 5G, where UPF can be deployed locally on the customer side, while the SMF is centrally deployed on the operator side". Chenxi: OK "Solutions for non-conflicting, efficient and customized interoperability mechanism between CP and UP function(s) need to be identified": Bruno> to which conflicts does this refer ? we should strike this sentence. Chenxi: please see the 4th reply "Identify mechanisms for protecting customer's privacy under the premise of ensuring non-conflicting and effective CP and UP interoperability.": Bruno> privacy for what? which conflicts? Chenxi: I think what mentioned in 4058 could be an example "Identify mechanisms for authorizing customers to customize the functionalities of PFCP to their needs (e.g. add or remove certain features) under the premise of ensuring non-conflicting and effective CP and UP interoperability.": Bruno> which conflicts? what needs to be customized by the customers vs. by the mobile operator owning the UPF? Chenxi: conflict means when customer want to have certain functionality set but he cannot because he cannot operate or he does not have the authorization or the operation may influnce the current PFCP interoperation, etc. we cannot always rely on the operator to customize the functionalities when the customer needs since these needs can be urgent, frequent, so it is better to provide customer some autonamy Chenxi: I am OK to use 4058 as the baseline to merge if CMCC is OK too. please see my reply inline CC Frank: Security issues need to be considered. We agreed to have 4058 and 4131 separate, the intention should be to have two separate key isssues. Chenxi Key Issue on Interoperability issues caused by security and privacy needs of customers in vertical market (with title changed, now focuses on interoperability issues if customer use security and privacy mechanisms) Draft 1 provided Caixia: security and privacy are mainly covered in SA3, is it possible to study security related issues in CT4? Chenxi: as I replied to Frank on the CC last Thursday, This KI studies on how to ensure the effective interoperability of PFCP IF customer use certain mechanisms to protect their security and privacy, e.g. firewall , encryption, etc. It is not going to study the security mechanism itself, but "how to ensure the interoperability of PFCP" Chenxi: The v1 of 4131 is uploaded with title changed, now this pCR focuses on interoperability issues if customer use security and privacy mechanisms, please check: @Caixia, please see my reply inline: Frank: Thanks for the revision. However, I don't agree with the revision. In my view, the key issue you raised is not at CT4 remit; those requirement and corresponding solution should be first discussed and specified in SA3, and then CT4 can continue. In addition, if you want to have further discussion, you need describe what kind of firewall is used between CP and UP, and what kind problem it will lead; similar to security mechanism. Chenxi: I have specified this issue for several times... as what I said in the CC last Thursday and what I replied to Caixia today, this KI studies on how to ensure the effective interoperability of PFCP IF customer use certain mechanisms to protect their security and privacy, e.g. firewall , encryption, etc. It is not going to study the security mechanism itself, but "how to ensure the interoperability of PFCP"， so it has nothing to do with SA3. I really don't know where we stuck since I think this KI make itself quite clear here. If you really want an example, how about this one: if customer want to keep their user information secure, e.g. encrypt the UE IMSI/MSISDN using encryption algorithm such as DES on the UPF side, can SMF on the operator side handle this by current specification? At least an Encryption and decryption conversion mechanism is needed which will definitely affect the current PFCP interoperation, right?(this is a quick thought come to my mind)
CC3	4132	pCR 29.820 Rel-17 Key Issue on Necessary functionality set of PFCP for different use cases	CATT	Clash with C4-204114 Add ZTE as co-source Chenxi I uploaded the v1 for the merged pCR: https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/6.1.3/C4-204132_29.820_pCR_Key%20Issue%20on%20Necessary%20functionality%20set%20of%20PFCP%20for%20different%20use%20cases_v1.docx please check if it is OK for you~ Bruno: “to meet industry requirements such as minimization and customization” Please explain/develop these terms (in the context of this key issue). Is the intention of this key issue to define informative guidelines about which optional features are applicable/recommended for each use case, i.e. NOT to remove existing mandatory functionality of the protocol for certain use cases? This should be clarified Chenxi the minimization means the industry who want have the minimum functionality set the customization means the industry who want have the specific functionality set to there needs CC Bruno categorisation is just to identify feature set of PFCP feature for defined stage 2 features the intention should not to change the protocol. The key issue description should follow a clear structure. Bruno: we should postpone and next time we have a detailed description and a proposed solution to understand the topic. Chenxi Rel-17 Key Issue on Necessary functionality set of PFCP for different use cases (now focuses on minimum necessary functionality set of PFCP for common use case and specific functionality set of PFCP for specific use case) Draft 2 provided Caixia: I think the work related to this key issue is still not clear. Chenxi: I have no idea where we're stuck right now, for me, it is quite clear... The need for lightweight UPF is becoming more and more urgent in the industry, in order to achieve lightweight, we need to study the "minimum functionality set" for the common case and "specific functionality set" for the specific case. In this way, we could flexibly and quickly configure the PFCP functionality set between SMF and UPF in various use cases. And this KI focuses on this topic. Hope this clarifies your concern. Chenxi: The v2 of 4132 is uploaded, now this pCR focuses on minimum necessary functionality set of PFCP for common use case and specific functionality set of PFCP for specific use case， please check： @Caixia, please see my reply inline:
4240	pCR 29.820 Rel-17 pCR on key issue of UE IP address&prefix allocation by SMF in SMF set	China Mobile Com. Corporation	Chenxi 4240 overlaps with CATT's 4130, merging is needed. Since UE IP allocation is a sub-issue for "multiple options co-existence" in 4130, is it OK for you to merge 4240 into 4130 and add China Mobile as co-source? Rong: The key issue 4240 and 4130 are both related to UE IP allocation issue. But they are different topics. 4130 mainly focus on which side should be used to allocate the UE IP(CP or UP) due to multiple options co-existence. 4240 mainly focus on how to provide an mechanism to allocate UE IP address/prefix by CP function with SSET or MPAS feature deployed. So, I don’t think it’s necessary to merge them. Thanks Chenxi: Still I have the feeling that these two pCRs can be merged in some way... But it's OK for me, we can discuss the two proposal separately
4245	pCR 29.820 Rel-17 pCR on solution of UE IP address&prefix allocation by SMF in SMF set	China Mobile Com. Corporation	Giorgi: Below are few comments to consider. “SMF shall broadcast the recovery message towards all other SMFs”, this needs further explanations. Also, ‘shall’ seems too strong. [Rong]: After the SMF recover, the SMF need to allocate the UE IP address from it’s own UE IP resource block. But some UE IP address might been used and the corresponding sessions is controlled by other SMF, so the SMF must broadcast the recovery message and be aware of these unavailable UE IP addresses to avoid UE IP address allocation conflict. If “shall” is too strong, then I can change it to “should”, it is OK? In addition to failure/recovery, an SMF may be added or removed to/from the SMF set. Mechanism for the IP ranges/ prefixes re-assignment should be considered. [Rong]: Yes, when SMF added or removed, the IP ranges/prefixs should be re-assigned. But I think this is an operator specific item. How do you think? If the BSF is combined with the SMF, the SMF shall have the fixed range of IP address. If such SMF fails, the IP address ranges/prefix list should be re-assigned to other SMFs, which looks problematic. [Rong]: Thanks for your thoughtful consideration. If the BSF is combined with each SMF in the SMF set, I think the BSFs should be interchangeable and share the same record information. Or for SMF set, one BSF should be deployed for an SMF set. Anyway, maybe this is related to the deployment solution. How do you think? Caixia: I think it is not just deployment solution, if the BSF is combined with SMF, and the BSFs is interchangeable, share the same record information as SMF, how to update the registration information related to the BSF in NRF or in NEF? [Rong]: If the BSF is combined with SMF in SMF set and share the same record, I think the BSFs is somehow like a BSF set in NRF or NEF point of view also. Frank: I have a few additional comments: For each candidate solution, we should have a subclause for evaluation, pros and cons; if you don't have time, an editor's note should be added; [Rong]: OK, I will add an editor’s note and these information will be added later. It would be good to have a signalling flow to illustrate the solution; [Rong]: This is just a general solution idea. Will provide next meeting if needed. With proposed solution, if I understand correctly, the PDU sessions which was managing by the failed SMF will be spread over other SMFs in set (during its failure), and the recovered SMF can only accept new PFCP session creation (from the rest IP addresses range ) and thus it will not be able to reach its capacity; the load is not evenly distributed in the SMF set. [Rong]: Thanks for your question. Then the other SMFs can redirect PFCP sessions back to the recovered SMF which originally created these sessions. To avoid lots of session switching, the session redirection can be triggered by other mechanism like SMF set load balance which can be implementation specific. How do you think? The solution requires a lot inter SMFs signalling, as far as I know, this has been avoided to be further specified in SA2 and leave it as implementation specific. I am wondering if CT4 can open a new interface. Rong]: Yes, a lot of inter SMFs signalling is introduced. But these requirement is just a general description. The detailed signalling structures and IEs are still implementation specific I think. I’m not sure whether CT group can open a new interface or not. But anyway, this is just one possible solution, we can discuss further if better one comes to avoid this interface. Bruno One more point: am I right that if an SMF fails, other SMFs in the SMF set cannot reuse the UE IP Addresses that were still available in the failed SMF? Rong: According to currently solution proposal, yes
CC3	4249	pCR 29.820 Rel-17 KI on UPF Support for Multiple Network Slice Sharing	China Telecommunications	Yue I would rather to see pCR in 'normal' style, i.e. with change mark than "all new". At least "5 Key Issues" is not new :) Liuliu: Rev 1 is on the way Giorgi: Let me challenge this statements: "current UPF does not support being shared by multiple slices". Point is, SMF already tells the UPF for which slice the PDU session is activated. Also, please use revision marks when introducing new text. Liuliu Thank you for your comments. On N4, S-NSSAI is only used for Performance Messurement, when UPF are shared by several network slices(eg. 5G slice and IoT slice), UPF needs to know, which slice the N4 message come from. But the current mechanism does not support this requirement. Rev1 is on the way, I will inform you when uploaded. Bruno: In clause 5.1 (UPF support of multiple network slices), why is it said that "current UPF does not support being shared by multiple slices"? S-NSSAI is sent over N4, and it is already possible e.g. to use and select different network instances (mapped from S-NSSSAI) and different transport networks for different PDU sessions pertaining to different S-NSSAIs. Liu Liu: On N4, S-NSSAI is only used for Performance Messurement, when UPF are shared by several network slices(eg. 5G slice and IoT slice), UPF needs to know, from which slice the N4 message comes. But the current mechanism does not support this requirement "Study how UPF can support being shared by multiple network slices": Bruno> We should study the potential missing functionalities to enable an UPF to support multiple network slices. Liu Liu: OK, I will add this study point in the Key Issue Giorgi Ok, let me check updated paper Liuliu Rev1 of 4249 have been uploaded. Thank you for your comments. https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/6.1.3?login=1 Frank: We are fine with the key issue. However, we may enhance the description as below: In 5G system, multiple network slices with different functions and performance requirement may have different control plane functions, while they may share the same UPF. Therefore, the UPF is expected to serve PDU sessions with different QoS and network separation requirements (in corresponding to different network slice), and the UPF will allocate different user plane resource (e.g. CPU/Memory/bandwidth/delay budget) to those PDU session. However, in current specifications, the S-NSSAI transmitted on the N4 interface is only used for performance measurement, when UPF are shared by several network slices (e.g. eMBB5GC slice and IoT slice), UPF needs to know, which slice the PFCP session (PDU session) is pertaining to N4 message come from. But the current mechanism does not support this requirement. This key issue aims at addressing following aspects for scenario 4: 1. Study possible protocol enhancement over PFCP to enable how a UPF to support being shared by multiple network slices more efficiently. 2. Study whether any additional parameters are required during the interaction between UPF and SMF. 3. We should study the potential missing functionalities to enable an UPF to support multiple network slices. Liuliu Thank you for your modifications. I am OK with all of your modifications, except for deleting study point 3 3. We should study the potential missing functionalities to enable an UPF to support multiple network slices. This study point is suggested by Bruno, and I think it is reasonable. Mechanism for UPF shared by multiple network slices may bring about influence to UPF functionalities, we can not skip this influence from the beginning. So I think this study point should be retained. Liuliu Rev 2 of 4249 have been uploaded according to your modifications, except for study point 3 If your accept this version, I will ask for a new Tdoc number and upload it. https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/6.1.3?login=1 Frank: I removed it because I proposed a very generic bullet😊 "1. Study possible protocol enhancement over PFCP to enable how a UPF to support being shared by multiple network slices more efficiently." The third bullet you are referring is the SA2 remit, strictly speaking
CC3	4250	pCR 29.820 Rel-17 Solution on enabling UPF to Support Multiple Network Slice Sharing	China Telecommunications	Yue step2 and step8 are optional, please indicate this in the description below the figure. The style of the text all across this pCR is not what we usually use for the specification, e.g. the first level bullets are not in "B1" style. I cannot remember the reason for this, but when I switch to normal view the figure disappears. Remark for 3 word/Viso feature depend s how the figure is inserted solution depends on the versions used solution depends on the version. Frank: We don't agree with the proposed solution, the solution requires SA2 requirement, to populate S-NSSAI information to the UPF during PFCP Session Establishment. Though S-NSSAI is introduced in the PFCP, but it is for performance measurement. Liu Liu：As you mentioned, S-NSSAi is for PM now, but operaters require that UPF can be shared by several control plane,when UPF are shared by several network slices(e.g. 5GC slice and IoT slice), UPF needs to know, which slice the N4 message come from. But the current mechanism does not support this requirement.As you can see, several operators have already show the needs for UPF sharing, So far, it is assumed using Network Instance to achieve the key issue – supporting multiple network slices. Liu Liu: S-NSSAI is ok. On the other hand, there is no SA2 requirement requiring UPF to consume Nnrf_NFmanagement service API to update its NF profile. Liu Liu: This is an optional procedure, if UPF registering to NRF and UPF selection in NRF are used. Yue: I have no strong position on UPF registering to NRF. But for indicating SNSSAI during the session establishment, I support. To deploy dedicated UPF for each NW slice is a waste in some scenarios, e.g. the NW slices do not require much bandwidth. Thus I see a need for UPF being shared by multiple slices Varini: I have a question - with inclusion of S-NSSAI in PFCP Session Establishment, isn’t this KI already supported? UPF profile in NRF already includes an array of S-NSSAIs -> UPFInfo. I understand s-NSSAI was included in PFCP Session message for PM purpose, but I don’t think we restricted it to that? Liuliu: On N4, S-NSSAI is only used for Performance Messurement now. But when UPF are shared by several network slices(eg. 5G slice and IoT slice), UPF needs to know, which slice the N4 message come from.The current mechanism does not support this requirement. Bruno: All the proposed enhancements in red are already supported by stage 2 and stage 3, apart that in step 11, resources allocation is done today based on the network instance id (derived by SMF from various parameters including S-NSSAI) and optionally IP Address Pool ID, but not on Slice ID that was defined for PM. Step 11: "11. UPF performs corresponding resource allocation and subsequent slice isolation according to the received slice ID." Liu Liu: OK, I will modify Step 11 We should develop first the key issue if there are issues / limitations identified with the existing approach based on Network Instance ID and IP Address Pool IDs. Then we should describe whether the solution proposes to use the Slice ID in addition to Network Instance ID and/or IP Address Pool ID, or in replacement, and pros/cons of doing so including backward compatibility aspects. Liu Liu: OK, I will take these into consideration. Liuliu I think in current specifications, S-NSSAI is used for PM only, and when UPF are shared by several network slices(e.g. 5GC slice and IoT slice), UPF needs to know, which slice the N4 message come from. So we should add Slice ID to the current procedures as mark red in this pCR. Response above How to proceed with this pCR? Please note this is a TR and there will be an evaluation for each solution Liuliu: I will update a new version soon.
TR 29.820 0.1.0	China Mobile, Yue
6.1.4	Port Allocation	PortAl
4031	other Rel-17 TR skeleton for Study on Port Number Allocation Alternatives for New Interfaces	Huawei	Revised to C4-204348	Bruno: I propose to update the TR title to "Study on Port Number Allocation Alternatives for New 3GPP Interfaces" For each solution, we also need a clause identifying the impacts. Giorgi Will do in the revised version
4348	other Rel-17 TR skeleton for Study on Port Number Allocation Alternatives for New Interfaces	Huawei	Agreed to be incorporated
4039	discussion Rel-17 pCR on PortAl Introduction	Huawei	Agreed to be incorporated
4040	discussion Rel-17 pCR on PortAl Scope	Huawei	Revised to C4-204349	Bruno: Editorial: "the new 3GPP interfaces and applications" Why does the DNS solution exclude the Dynamic/Private Port number range [49152 - 65535] ? It shouldn’t. Giorgi Will fix the editorial and also will extend DNS option to include also dynamic range.
4349	discussion Rel-17 pCR on PortAl Scope	Huawei	Agreed to be incorporated
4041	discussion Rel-17 pCR on PortAl References	Huawei	Withdrawn
4042	discussion Rel-17 pCR on PortAl Definitions of terms, symbols and abbreviations	Huawei	Revised to C4-204350	Bruno: Port Number: "This report discusses ways for determining how to allocate (reserve) such port numbers for the future new interfaces." this is not a definition of a Port Number. Also this should not be restricted to TCP and UDP, e.g. but also covers SCTP (that is typically used on RAN interfaces). And the definition should not be restricted to 3GPP interafaces. This should be a generic definition. It does not really help to strike all the guidance text at this stage.
4350	discussion Rel-17 pCR on PortAl Definitions of terms, symbols and abbreviations	Huawei	Agreed to be incorporated
4043	discussion Rel-17 pCR on PortAl Requirements	Huawei	Revised to C4-204351	Bruno: 3GPP working groups need a way for allocating and reserving port numbers " Bruno> it depends on the solutions (e.g. operator configured or not). Intention is to define guidelines, there won't be necessarily "one selection solution". "Therefore, e.g. two different Rel-17 and onwards interface applications shall not be listening and sending packets to the same port": Bruno> this is not necessarily true and we cannot conclude on this now. e.g. we might also consider for SCTP interfaces the approach where a single port would be shared for multiple interfaces and where we distinguish each interface by its individual SCTP Payload Protocol Identifier, of which only 72 out of 4294967295 values are currently assigned by IANA. IANA has allocated 3 PPIDs to the O-RAN Alliance for the E2 interfaces, so allocating new PPIDs doesn’t seem to be an issue" (https://www.iana.org/assignments/sctp-parameters/sctp-parameters.xhtml#sctp-parameters-25) We should structure this clause with subclauses(General, Reqt x).
4351	discussion Rel-17 pCR on PortAl Requirements	Huawei	Agreed to be incorporated
4044	discussion Rel-17 pCR on PortAl Key issues	Huawei	Revised to C4-204352	Bruno: General" clause should not be specific to certain solutions, and should not be used to describe key issues. Giorgi: I agree, removed One key issue may be to study whether Dynamic/Private Port numbers range [49152 - 65535] or User Port number range [1024-49151] can be used for new 3GPP interface. Giorgi: Do you mean in addition to the existing ones, or instead of the existing ones? Another issue may be ensure there is no port number clash between 3GPP Rel-17 and onwards interface applications and other, 3GPP and non-3GPP applications utilizing the same port numbers. Giorgi: Same as above.
4352	discussion Rel-17 pCR on PortAl Key issues	Huawei
4045	discussion Rel-17 pCR on PortAl Solutions	Huawei	Revised to C4-204353	Bruno: We should not start evaluating solutions until they are properly described. I suggest to revert all pros/cons at this stage. We should focus first on describing well the solutions. Giorgi: I moved them into editor’s notes, so that in the next meeting we could decide if these hold or not. Solution 1: strike “CT4”. It does not matter at this stage which WG would do so. Giorgi: Ok "New annex to this TR could serve as a repository for such 3GPP specific data to show which port number is allocated for which interface application.". This TR is 29.8xy TR for the study that we won’t maintain. This would not be appropriate for a placeholder of such port allocations. Giorgi: Ok Pros and cons should be formatted as a bulleted list. Giorgi: Ok, this is done in the TR (4348). Solution 3: there were more comprehensive materials submitted by Orange on possible DNS approaches. Giorgi: I expect Orange to fill DNS part in the next meeting. Here I’m trying to document the crucial part: regardless of the DNS query solution, at the end of the day there is a need to decide from which IANA controlled port range this solution intends to allocate numbers 6.2.3: "Cons: Same as for solution #1. " not true. Operator can choose ports that are not yet used by any application. Giorgi: Well, today some ports in the User Port range are not allocated by IANA, but in future IANA most likely will allocate them. So, a clash is inevitable, because I don’t believe IANA will delegate to 3GPP any sub range from User Port number range "In addition to that, roaming interfaces will become a huge challenge": wouldn't IANA agree assigning ports for such interfaces? Giorgi: If IAN would be willing to that, why would we need this study? 6.2.1 below 6.3 needs to be corrected to> 6.3.1 Giorgi: ok, the numbering for Solutions clause are changed in the TR template "The port can be selected from the User Port number range [1024-49151]." how can this be so and with which implications then if IANA allocates the same port nb? Giorgi: exactly, but I understood operators will monitor IANA database update and dynamically redefine available port ranges. Anyway, I invite Orange to bring pCRs on DNS based solution
4353	discussion Rel-17 pCR on PortAl Solutions	Huawei
TR29.8xy 0.1.0	Huawei Giorgi
6.1.5	Service-based support for SMS in 5GC
4117	other Rel-17 pCR on Skeleton of Study on 5G SMS architecture enhancements to support SBASBI	China Telecom, Orange	Agreed to be incorporated
4118	other Rel-17 pCR on Introduction of Study on 5G SMS architecture enhancements to support SBASBI	China Telecom, Orange	Agreed to be incorporated
29.8ab V0.1.0	Orange
6.2	CT4 Supported WIs
6.2.1	Study on enhanced IMS to 5GC Integration Phase 2	FS_eIMS5G2
4292	pCR 23.700-12 Rel-17 23700-12 initial version	Huawei, HiSilicon	Agreed as basis for futre work
6.2.2	Stage 3 of Multimedia Priority Service (MPS) Phase 2	MPS2-CT
6.2.3	Enhancement for the 5G Control Plane Steering of Roaming for UE in CONNECTED mode	eCPSOR_CON-CT
6.3	AoB for Rel-17	TEI17
6.3.1	CUPS/PFCP	TEI17
CC4	4006	CR 29.244 0465 Rel-17 Correction on Reference to RFC 6887	HuaWei	Postponed to next meeting	WI ATSSS, TEI17 CAT F If this CR (no feature enhancement) is the only Rel-17 CR for this TS should this CR create a new TS or should we agree it for Rel-16. Frank: The intention of this CR is fine; however I don't think the MPTCP client, i.e. the UE will use PCP. This clause should be removed as it applies to other Transport converter deployments, not for 3GPP ATSSS. It is confusing. Zhijun: It depends on whether the MPTCP connection is always setup from the UE to the remote side. Normally the MPTCP connection is setup from the UE side, like normal NAT behaviour. In the case that the UE uses PDU session IP@ to setup application layer session with the remote server, and the remote server knows the UE supports MPTCP, the remote server may setup MPTCP connection towards the UE. If so, the UE needs to use PCP to prepare the IP/Port mapping for waiting the incoming MPTCP connection setup. Actually we don't know whether there will be such UE behaviour, because till now no device OS supports ATSSS. So it is better to keep this text, but could add some NOTE to clarify that in most cases the MPTCP connection is setup from the UE to the remote server. Frank: At least in my understanding, for 3GPP ATSSS, such scenario (MPTCP connection initiated from remote server) is not applicable. Question to this scenario: Is UE served as a TCP server? In this scenario, the MPTCP converter in UPF will not take any action and be transparent; the TCP packet will be treated as normal payload. I think we should remove this subclause. And in E.2.1General, the sentence " The incoming Multipath is initiated by the MPTCP Proxy in the UPF towards the MPTCP Client in the UE" should be removed! Zhijun: If you look into the figure E.2.3.-1 and the description, you will find that the MPTCP Proxy(acting as Transport Converter) will add MPC indication to the TCP SYN from the remote server. So the MPTCP Proxy is not transparent to the MPTCP connection setup procedure from the remote server. Actually, there are two ways to setup MPTCP connection from the remote server to the UE: 1) The remote server sends TCP SYN(MPC) to the UE, the UE answers the SYN(MPC) so as to setup the MPTCP connection. In this case, the MPTCP Proxy(Transport Converter) acts transparenetly, i.e. directly forward the TCP SYN. Which means the MPTCP is setup directly between the remote server and the UE. 2) The remote server sends TCP SYN to the UE, the MPTCP Proxy adds (MPC) indication to the TCP SYN. In this case, the TCP connection between the MPTCP Proxy and the remote server is REGULAR TCP connection. But the TCP connection between the MPTCP Proxy and the UE is MPTCP connection. The method (2) is typically used for those remote server doesn't support MPTCP, while operator decides to still using MPTCP for the TCP connection initiated by the remote server. Regarding to whether a UE can act as TCP server, I would say it could be, even it might not be used regularly. In general, I don't think it is a good idea to simply remove the clause we are talking about. CC Zhijun would like to keep the informative annex Frank we should remove it. 5G is serving as a tunnel between UE and the server we should not describe this in our 5G specs. Zhijun: MPTCP proxy. Bruno: if such specification is not specified in Stage2 or any CT1 means no requirement we should remove it in our spec. Delegates ask for more time to check the scenario.
6.3.2	Diameter	TEI17
4013	CR 29.272 0822 Rel-17 Monitoring Configurations in ULA	Nokia, Nokia Shanghai Bell	Revised to C4-204420	WI TEI17 CAT F Anders: We agree with the CR, but for readability, would like to suggest that the beginning of the last sentence in the modified paragraph would read: ”If the Subscription-Data AVP is received in the ULA but it does not contain any Monitoring-Event-Configuration AVPs, the MME or SGSN…” Ulrich: I shall update the CR according to your proposal later today. draft 4013-v1 is now in the draft inbox Anders: Thanks Ulrich, looks good to me.
4420	CR 29.272 0822 Rel-17 Monitoring Configurations in ULA	Nokia, Nokia Shanghai Bell
6.3.3	Common Data	TEI17
4008	CR 29.571 0229 Rel-17 Adding missing Reference to SUPI definition	HuaWei	Agreed	WI TEI17 CAT F If this CR (no feature enhancement) is the only Rel-17 CR for this TS should this CR create a new TS or should we agree it for Rel-16.
4017	CR 29.571 0230 Rel-17 Regular expression	Huawei	WI TEI17 CAT F If this CR (no feature enhancement) is the only Rel-17 CR for this TS should this CR create a new TS or should we agree it for Rel-16. Ulrich: I do not think that this CR is needed; it may even be confusing. We already have the reference [3] OpenAPI: "OpenAPI 3.0.0 Specification", https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md. which provides all the details Giorgi: I don’t have strong opinion, but when I rejoined CT¤, I would have appreciated a lot if the specs have hinted how to read the string patterns, which are all over. I do understand regex is explained in OpenAPI, but it is enormously large and complex specification. As a compromise, could you point a precise spot in OpenAPI, which could be referenced instead of the one in the CR? Jesus: I support the view that the CR is not necessary. Regular expressions are not a new term introduced by 5GC, not even by OpenAPI. They are a common topic in computer science, and providing a "definition" may mislead readers into thinking that 3GPP introduces something specific. The only clarification worth doing is to make it clear the specific dialect of regular expressions used in a given IE (in HTTP payloads), when such IE is simply defined as a string (for that, it may not be clear that the regex dialect used in the HTTP payload is the same dialect as OpenAPI uses for its own language). But this clarification is already done in all places that it's needed, to my knowledge. Giorgi: At CT4 we need to have a profound understanding of stage 2. Despite this, we always reference stage 2 specs when justifying presence or absence of certain IEs in a message or a data structure. And, we do reference specific clauses in specific stage 2 specs to make it easier to check the validity of the justification. Another example is, TR 29.905 holds definitions of zillion of notions that are well known in computer science and also are not 3GPP specific, like TCP, IP, you name it. Therefore, I totally disagree with a claim as if providing a definition of a Regex may mislead readers into thinking that 3GPP introduces something specific to 3GPP. Jesus That's ok, let's not call it "misleading" then 😊 Still, I don't think we need to define what are regular expressions in our specs. We can find many comparisons; if you want to compare with TCP or IP, be aware that 21.905 includes them as "abbreviations", which is fine, but they don't define what is "TCP/IP". A good comparison for adding "regular expressions" as a definition, would be similar to defining in our specs what is, say, the "client-server model": totally unnecessary. Giorgi TR 29.905, clause 3 Terms and definitions, example: Performance: The ability to track service and resource usage levels and to provide feedback on the responsiveness and reliability of the network. Does not look awful lot of 3GPP specific thing  Jesus: This is to avoid confusing it with: https://en.wikipedia.org/wiki/Performance#Arts Just kidding 😊
6.3.4	SBA	TEI17
4014	CR 29.500 0144 Rel-17 Editorial fixes	Huawei	Revised to C4-204344	WI TEI17 CAT D If this CR (no feature enhancement) is the only Rel-17 CR for this TS should this CR create a new TS or should we agree it for Rel-16. Hiroshi: Very minor point, but “P” is missing for “3GPP” just before the first correction of one of the unbreakable space, perhaps this should also be fixed Giorgi: Will do. Revised CR 4014_v1 is in the Drafts/6.3.4 folder
4344	CR 29.500 0144 Rel-17 Editorial fixes	Huawei	Agreed
4015	CR 29.500 0145 Rel-17 Fixing proofing language	Huawei	Agreed	WI TEI17 CAT D If this CR (no feature enhancement) is the only Rel-17 CR for this TS should this CR create a new TS or should we agree it for Rel-16.
4016	CR 29.501 0085 Rel-17 Editorial fixes	Huawei	revised to C4-204021	Revision of C4-204021 WI TEI17 CAT D
4021	CR 29.501 0085 Rel-17 Editorial fixes	Huawei	Agreed	WI TEI17 CAT D If this CR (no feature enhancement) is the only Rel-17 CR for this TS should this CR create a new TS or should we agree it for Rel-16.
6.3.5	UDM	TEI17
4076	CR 29.503 0464 Rel-17 Deregistration Notification to AMF in AMF-Set	Samsung	Merged into 4068	WI TEI17 CAT F Anders Shouldn’t this be addressed from rel-16 as the NF Sets are introduced in rel-16? I would like to suggest that this CR is merged into 4068 as both issues are related and can be addressed by a single CR from rel-16. Varini: agree with you, I will provide an update to 4068 and merge these changes there Varini: Draft v1 is available in drafts folder: Merging 4076 into 4068 https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.3.6/C4-204068v1.zip
6.3.6	Restoration	TEI17
4184	CR 23.007 0372 Rel-17 Restoration of PDN connections after a PGW-C/SMF failure, restart or scale-in	Nokia, Nokia Shanghai Bell	WI TEI17 CAT B Frank: I request to postpone this Rel-17 CR to next meeting with the following reasoning: The proposed solution has large impact on the existing MME / SGW nodes; any of them doesn't support the solution, this will lead a failure of restoration; Bruno> If SGW or MME does not support the proposed changes, so then the system behaves as per existing specs, which indeed prevents restoring PDN connections of a failed/restarted/de-instantiated (scale-in) SMF/PGW – which is exactly why we propose this 23.007 CR to ensure that PDN connections are maintained in these scenarios. I do not agree that this has “large impacts” to MME, SGW. This requires minimal GTP-C protocol changes (as described in the 23.007 CR), and for PDN connections setup with this feature, the capability to not tear down a context of a PDN connection when the PGW fails/restarts/is de-instantiated, but instead to keep it and reselects an alternative SMF/PGW-C. There are some impacts, but that are perfectly manageable. The support of SMF Set is introduced in Rel-16; normally in 3GPP, we should avoid to impact too much on the legacy node when we introduce a feature on the new node, instead we should look for alternatives which affects only the new network elements. Bruno> right, but in this case, the new entity is the SMF and it is collocated with the PGW-C for 5GC-EPC interworking, and w/o enhancing the EPC restoration procedures, we lose the benefits of the SMF set concept as explained in the reason for change Up to now, as one of key requirement, the S5 F-TEID on the control plane and use plane in the PGW cannot be changed; so that, we had discussed the solutions such as "gratuitous arp" which enables other PGW to take it over the sessions of failed PGW, though it was not captured in the spec. Bruno> I don’t remind having ever discussed this reqt, and you also say further down that you will consider the option to make the S5 F-TEID changeable. Note also that SMF/PGW-C of an SMF set can be deployed in different sites, and that restoration shall be possible towards any such SMF/PGW-C from the SMF set (meaning that the S5 PGW F-TEID should be able to be changed). And during introducing SMF Set, we were supporting to the approach that the SMF set being considered as a big SMF/PGW as specified SSET feature; in such way, the failure/restart/scale in of a PGW/SMF in the set may be hinden within the SMF/PGW Set. Bruno> I don’t follow your comments here. An SMF set comprises multiple SMF/PGW-C that can be deployed in different sites In the end, we are interested in this topic, and will do further study internally, and considering the option e.g. to make S5 F-TEID changable. Bruno> I can accept to postpone the CR to the next meeting to let you more time for studying the topic. We can also discuss the topic further offline before the next meeting. But I intend to come back with the same proposal at the next meeting (unless we agree on changes offline), so please be prepared at the next meeting for this discussion so that we can progress. Thanks Zhijun: We also see a lot of impacts to legacy MME/SGW/PGW and introduces more configuration work. In general, we should be careful to introduce too much impacts to legacy 4G system. So we should take more time to analyze the solution How to proceed with the CR? Postpone to next meeting?
7	Release 16
7.1	CT4 Led WIs
7.1.1	CT aspects on Enhancements to the Service-Based 5G System Architecture	5G_eSBA
4143	CR 29.500 0148 Rel-16 Custom headers related to indirect communication	Huawei	Revised to C4-204385	WI 5G_eSBA CAT F Jones: I have a question on the first change. In Indirect Communication with delegated discovery, the first SCP (e.g. SCPc) perform discovery using the discovery factors, and then select a target NF instance; and if it cannot access the target NF instance, it find a next SCPp according to e.g. the SCP Domain of the target NF instance. If we suggest the first SCP don’t perform discovery/selection and forward the discovery factors to next hop SCP (as proposed in the CR), how the first SCP locate the next hop SCP? Could you provide some clarification? Caixia: The SCP will do the discovery based on the discovery factors as you indicated, our CR just indicates the discovery factors will be sent from the first SCP to next SCP for the scenario you indicated and to align with the following description in clause 6.10.3.2 of TS 29.500: Based on SCP configuration, an SCP deciding to address a next-hop SCP for a service request may delegate the NF instance and/or service instance discovery and selection to subsequent SCPs, in which case it shall forward the "3gpp-Sbi-Discovery-*" request headers to the next-hop SCP. Jones So it is universal “by configuration” 😊. I am fine with the CR. Thanks! Bruno: In clause 6.10.2.5, we can simplify the text of the first bullet e.g. as follows: " - if the received request does not include the 3gpp-Sbi-Target-apiRoot header for the apiRoot of a selected NF service instance, and the selection of the target NF instance is not delegated to a next hop SCP" The text of all bullets in this clause needs to be enhanced, e.g. starting bullets by "if .. Abdessamad: I agree with Bruno’s remarks and I propose the following modifications to the 3 bullet points added in clause 6.10.2.5: An SCP shallmay include or modify a 3gpp-Sbi-Target-apiRoot header set to the apiRoot of an authority server for the target resource, if available, in requests it sends to the next hop SCP. In particular: If the received request does not include thea 3gpp-Sbi-Target-apiRoot header forcontaining the apiRoot of a selected NF service instance and NF discovery is not delegated to a next hop SCP, then the SCP performs NF service discovery towardswith the NRF or based on internallylocal configuration (i.e. without interacting with NRF) is invoked by the SCP according to the corresponding "3gpp-Sbi-Discovery-*" request header(s); If the received request includes thea 3gpp-Sbi-Target-apiRoot header forcontaining the apiRoot of a selected NF service instance, but the SCP needs to reselect a different NF service instance; If the received request includes thea 3gpp-Sbi-Target-apiRoot header forcontaining the apiRoot of a selected NF service instance and, the SCP does not reselect a different NF service instance, the SCP shall forward the received 3gpp-Sbi-Target-apiRoot header to the next hop SCP. Please let me know if it is OK for you. Caixia: I update the text in V1 as below, based on the suggestions from your side, which is also available in draft inbox. An SCP may include a 3gpp-Sbi-Target-apiRoot header set to the apiRoot of an authority server for the target resource, if available, in requests it sends to the next hop SCP. In particular: if the received request does not include a 3gpp-Sbi-Target-apiRoot header containing the apiRoot of a selected NF service instance, and NF service discovery is not delegated to a next hop SCP, then the SCP performs NF service discovery with the NRF or based on local configuration (i.e. without interacting with NRF) according to the corresponding "3gpp-Sbi-Discovery-*" request header(s); if the received request includes a 3gpp-Sbi-Target-apiRoot header containing the apiRoot of a selected NF service instance, but the SCP needs to reselect a different NF service instance; if the received request includes a 3gpp-Sbi-Target-apiRoot header containing the apiRoot of a selected NF service instance and the SCP does not reselect a different NF service instance, the SCP shall forward the received 3gpp-Sbi-Target-apiRoot header to the next hop SCP. Hope you are fine with the proposal. Abdessamad Ok for me Bruno: An SCP may include a 3gpp-Sbi-Target-apiRoot header … The SCP shall actually do so or forward the receiver header, in the different use cases listed in the bullets. Caixia: For the cases listed in bullets, it is mandatory for the SCP to do so, I will also prefer to change the description to An SCP shall include a 3gpp-Sbi-Target-apiRoot header …. Which is also same as the description for the behavior in NF consumer in the same clause: For Indirect Communications with or without delegated discovery, the HTTP client shall include a 3gpp-Sbi-Target-apiRoot header set to the apiRoot of an authority server for the target resource, if available, in requests it sends to the SCP. Hope this is fine. Abdessamad: V1 OK for me Abdessamad: After reading the text again, I confirm that I am fine with the usage of “shall”. Bruno: propose the following updates in red (for the text to read better): An SCP shall include a 3gpp-Sbi-Target-apiRoot header set to the apiRoot of an authority server for the target resource, if available, in requests it sends to the next hop SCP. In particular: if the received request does not include a 3gpp-Sbi-Target-apiRoot header containing the apiRoot of a selected NF service instance, and NF service discovery is not delegated to a next hop SCP, then the SCP shall select a target NF service instance (performing an NF service discovery with the NRF or based on local configuration (i.e. without interacting with NRF) according to the received "3gpp-Sbi-Discovery-*" request header(s)) and insert a 3gpp-Sbi-Target-apiRoot header set to the apiRoot of the selected target NF service instance ; if the received request includes a 3gpp-Sbi-Target-apiRoot header containing the apiRoot of a selected NF service instance, but the SCP needs to reselect a different NF service instance, the SCP shall modify and set the 3gpp-Sbi-Target-apiRoot header to the apiRoot of the newly selected target NF service instance ; if the received request includes a 3gpp-Sbi-Target-apiRoot header containing the apiRoot of a selected NF service instance and the SCP does not reselect a different NF service instance, the SCP shall forward the received 3gpp-Sbi-Target-apiRoot header to the next hop SCP. Caixia: Thank you, your proposed text is fine, which make the description more clear. Please find the draft v2 as below: https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.1/C4-204143_V2_eSBA%2029500-Custom%20headers%20related%20to%20indirect%20communication.docx
4385	CR 29.500 0148 Rel-16 Custom headers related to indirect communication	Huawei
4144	CR 29.510 0373 Rel-16 Support of eSBA by NFs	Huawei	WI 5G_eSBA CAT F Jones I think the CR is not intended. Overall, deciding on redundancy model based on support on the peer NF seems over complicated, and there are many aspects to be considered, e.g. The scenario described in the CR is to detect the capability of handling binding of the peer NF, this may not work in many cases, e.g. a NF consumer may not register NF profile in NRF at all; Even a peer NF does register NF profile, should the producer creating the resources context after the NF query result to decide whether redundancy applies or not, this is very low efficient; Even the current peer NF doesn’t support Binding, what about the peer NF changes, e.g. AMF changes after inter-AMF mobility, will then the data resilience model adapted accordingly? The obvious value mentioned in the CR is to avoid dead data when the hosting NF failure, which in my view is not really a frequent case and could be addressed with other mechanism like garbage collection. Caixia: We think it is valuable for the server to know whether the client support the reselection if the NF producer instance is failed. For the server side, if the client does not support the reselection, the dead data is not easy to be removed, you do not know when the backup data will be visited Consider the SMF set scenario, if the SMF1 serving the UE, and PCF reselects the SMF2, SMF1 retrieves the UE context, however AMF does not support the reselection mechanism, and the AMF detects the failure of the SMF1 will deactivate the PDU session directly. For this scenario, if the SMF2 knows the AMF does not support the reselection, the SMF2 can simply reject the message from PCF. I agree the solution based on the NRF is not good enough, and may be a new custom header will be a good way forward. Bruno: I understand that you wish to provide some indication to the NF service producer on whether the consumer supports NF service instance reselection in an NF set, NF service set or NF instance, when a resource is created, to avoid ending up with hanging contexts stored in the NF set or NF instance if the consumer does not support corresponding procedures and the original NF service producer instance fails or is de-instantiated. But I fail to understand then why such indication should be provided via the NF profile of the consumer in the NRF, that would require then the producer to discover the consumer profile (which looks odd). If any new information is needed, this should be rather signalled in the HTTP request, e.g. in an HTTP header. Besides, not supporting Binding procedures does NOT imply that the NF service consumer does not support NF Set or cannot reselect a different service instance. Actually I do expect Rel-16 compliant NFs to support the NF set concept, while they may additionally support the binding procedures. TS 23.527 clause 6.5.3 (NF Service Instance Reselection when a (Routing) Binding Indication is not available ) specifies how to reselect an NF service instance when a (Routing) Binding Indication is not available. The same procedures should apply if binding is not supported. So if any new indication was defined, this should not be tied to the support of the binding procedures as such, but to the support of NF set and NF service instance reselection. In other words, this would be to differentiate a Rel-15 NF from a Rel-16 NF. For the above reasons, this 29.510 CR is not agreeable to us. Caixia: I understand the solution based on NRF is not good, and the custom header will be a good way forward. We think it will be benefit for the server to know whether the client support the reselection of the NF service instance, server can optimize the procedure or data storage handling. If it is fine, we can provide a contribution for the HTTP header solution.
4185	CR 29.573 0041 Rel-16 TLS security with the 3gpp-Sbi-Target-apiRoot header on N32f	Nokia, Nokia Shanghai Bell, NTT DOCOMO	Revised to C4-204458	WI 5G_eSBA CAT F Giorgi Concerning clause 5.3.3, we believe it would make it more generic to move the major provisions of the new text to the similar CR to 29.500 in 4186. Bruno: I have uploaded v1 of C4-204185 in the draft inbox, moving the changes of clause 5.3.3 into the 29.500 CR. https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.1/C4-204185_v1_29573_Rel16_TLS%20security%20with%203gpp-Sbi-Target-apiRoot.docx (I am going to send a separate email to indicate that v1 of C4-204186 is also available) Giorgi: The revision is fine by me.
4458	CR 29.573 0041 Rel-16 TLS security with the 3gpp-Sbi-Target-apiRoot header on N32f	Nokia, Nokia Shanghai Bell, NTT DOCOMO
4186	CR 29.500 0150 Rel-16 TLS security with the 3gpp-Sbi-Target-apiRoot header on N32f	Nokia, Nokia Shanghai Bell, NTT DOCOMO	Revised to C4-204459	WI 5G_eSBA CAT F Bruno: I have uploaded v1 of C4-204186 in the draft inbox, moving the changes of clause 5.3.3 of C4-204185 (29.573) into this CR (29.500), further clarifying the routing reqts between SEPPs https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.1/C4-204186_v1_29500_Rel16_TLS%20security%20with%203gpp-Sbi-Target-apiRoot.docx Giorgi: The revision is fine by me.
4459	CR 29.500 0150 Rel-16 TLS security with the 3gpp-Sbi-Target-apiRoot header on N32f	Nokia, Nokia Shanghai Bell, NTT DOCOMO
4187	CR 29.573 0042 Rel-16 Corrections to PRINS call flows	Nokia, Nokia Shanghai Bell	Agreed	WI 5G_eSBA CAT F
4188	CR 29.500 0151 Rel-16 Determining the NF Service Producer Identity without support of binding procedures	Nokia, Nokia Shanghai Bell	Revised to C4-204460	WI 5G_eSBA CAT F Frank: In this CR, you have proposed to modify the condition for SCP to include 3gpp-Sbi-Producer-Id, to consider if the NF service consumer doesn't support Binding Indication. You have another CR C4-204189 which has also a change on the same clause 6.10.3.4, to extend the use of 3gpp-Sbi-Producer-Id to indirect communication without delegation. C4-204247 from Ericsson has proposed similar changes on the same topic. (but 4247 has covered also some other aspect) I think what we proposed requirements are better and easy for implemenation, basically: The SCP, in the indirect communication, shall include 3gpp-Sbi-Producer-Id in the response message if it has reselected a NF service producer; The NF service consumer shall use Binding Indication if it supports and receives, otherwise the NF service consumer shall use 3gpp-Sbi-Producer-Id. What proposed in 4188 will lead extra configuration in SCP (for NF consumer) and complex logic. Could you please consider revise 4188 and merge our proposal (the changes in 6.10.3.4 and 6.10.5.1) Waqar Support Frank Bruno: Thanks for your comments. I am fine with requiring the SCP to always return the Producer ID when it has (re)selected a NF service instance, regardless of whether binding information is returned by the producer or not. I will revise our CR and merge your changes in the revision. Bruno: Thanks for your comments. I have uploaded v1 in the draft inbox merging statements from C4-204189 and C4-204247 related to returning the producer identity to the NF service consumer, and added Ericsson as co-source. https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.1/C4-204188_v1_29500_Rel16_Producer%20Identity%20without%20support%20of%20binding%20procedures.docx Please let me know if you have any comment.
4460	CR 29.500 0151 Rel-16 Determining the NF Service Producer Identity without support of binding procedures	Nokia, Nokia Shanghai Bell
CC5	4189	CR 29.500 0152 Rel-16 Clarifications for Indirect Communications	Nokia, Nokia Shanghai Bell	Revised to C4-204461	WI 5G_eSBA CAT F Frank: In this CR, except the aspects for 3gpp-Sbi-Producer-Id which I have addressed in the other email for the comment to 4188, I don't really understand the following requirement: When forwarding a request that includes the 3gpp-Sbi-Sender-Timestamp and the 3gpp-Sbi-Max-Rsp-Time headers, an SCP should set the 3gpp-Sbi-Sender-Timestamp to the time when it forwards the request and it should adjust the 3gpp-Sbi-Max-Rsp-Time accordingly (i.e. such as to properly reflect the time until which the HTTP client waits for a response). As an alternative, the SCP may forward these headers unmodified. I think only the yellow highlighted is proper requirement for the SCP. If the SCP changes these header, there are risks those requests have been expired in the original sender. Bruno: There isn’t any such risk, since the SCP adjusts the 3gpp-Sbi-Max-Rsp-Time such as to properly reflect the time until which the HTTP client waits for a response. The 3gpp-Sbi-Sender-Timestamp header has been introduced, among others, to allow measuring signalling delays between different network entities. By enabling the SCP to insert its sender timestamp, it is possible to know when e.g. the SCP sends a discovery request to NRF, an access authorization token request to the OAutH2 server, and when it finally forwards the request to the NF service producer. And this also allows to measure the signalling delays between the HTTP client and SCP, and between the SCP and HTTP server. This is as was originally designed/intended, where each sender sends the request with its own time when the request (or response) is sent. Frank: Thanks for the clarification. However, to achieve " And this also allows to measure the signalling delays between the HTTP client and SCP, and between the SCP and HTTP server.", shouldn't SCP add its own "3gpp-Sbi-Sender-Timestamp ", possibly with a new header; why should SCP modify the one sent from the original requester, and also make new calculation of 3gpp-Sbi-Max-Rsp-Time; the receiver should still use the ones from the original requester. Bruno: Only one sender timestamp can be included in an HTTP request or response. The procedures do not foresee to add multiple occurences of this header, nor to indicate in this case the identifier of the entity that included the timestamp. The SCP can measure the signalling delay between the consumer and SCP, the producer can measure the signalling delay between the SCP and producer. There is no need to change the procedures. This is totally transparent for the receiver. The CR also allows the option for the SCP to forward the headers unmodified. Bruno: I have uploaded V1 in the draft inbox, removing the changes related to returning the producer identity to the consumer that have been moved into the revision of C4-204188. https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.1/C4-204189_v1_29500_Rel16_Clarifications%20for%20indirect%20communications.docx Please let me know if you have any further comment. Frank In my view, the SCP need not modify the 3gpp-Sbi-Sender-Timestamp and the 3gpp-Sbi-Max-Rsp-Time headers, if you see the benefits, could we revise the following with yellow highlighted: When forwarding a request that includes the 3gpp-Sbi-Sender-Timestamp and the 3gpp-Sbi-Max-Rsp-Time headers, the SCP may forward these headers unmodified; if the SCP modifies and set the 3gpp-Sbi-Sender-Timestamp to the time when it forwards the request and it shall adjust the 3gpp-Sbi-Max-Rsp-Time accordingly (i.e. such as to properly reflect the time until which the HTTP client waits for a response). As an alternative, the SCP may forward these headers unmodified. Bruno Thanks for your comments. I have incorporated them in V2 uploaded in the draft inbox. https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.1/C4-204189_v2_29500_Rel16_Clarifications%20for%20indirect%20communications.docx
4461	CR 29.500 0152 Rel-16 Clarifications for Indirect Communications	Nokia, Nokia Shanghai Bell
4190	CR 29.510 0375 Rel-16 scpPrefix attribute in SCP profile	Nokia, Nokia Shanghai Bell	Revised to C4-204462	WI 5G_eSBA CAT F Jones: I am fine with the principle of the CR. Just one comment: the ScpDomainInfo is used to indicate any domain specific information in ScpInfo when present. If there is no specific information for the domain, i.e. if fqdn, Ipv4Addresses and Ipv4Addresses of the a domain are commonly specified in NFProfile level, ScpDomainInfo doesn’t need to be present for this domain. As we don’t have apiPrefix at NF level and SCP doesn’t support a service, if scpPrefix is specified only in ScpDomainInfo, it will require ScpDomainInfo to be present for all the SCP domain, even the scpPrefix is the same for all domains. I suggest that we add scpPrefix also in ScpInfo data type as common data. Only if a specific domain has different scpPrefix, it can indicate it in ScpDomainInfo. Bruno: thanks. Your comment is fine by me and will prepare a revision accordingly. V1 is available in the draft inbox, incorporating your comments. https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.1/C4-204190_v1_29510_Rel16_scpPrefix%20attribute%20in%20SCP%20profile.docx
4462	CR 29.510 0375 Rel-16 scpPrefix attribute in SCP profile	Nokia, Nokia Shanghai Bell
4191	CR 29.500 0153 Rel-16 Incorrect references and editorial errors	Nokia, Nokia Shanghai Bell	Agreed	WI 5G_eSBA CAT F
4192	CR 29.500 0154 Rel-16 Sending the NRF API URIs to the SCP for indirect communication	Nokia, Nokia Shanghai Bell	Agreed	WI 5G_eSBA CAT F
4193	CR 29.510 0376 Rel-16 Resolving Editor's notes on SCP profile registration and discovery	Nokia, Nokia Shanghai Bell	WI 5G_eSBA CAT F It is assumed that SA2 will send a reply LS during CT4#99e. The contents of this CR will be updated during CT4#99e, if necessary, along SA2 replies.
4211	CR 29.500 0157 Rel-16 Discovery Headers	Ericsson	Agreed	WI 5G_eSBA CAT F
CC5 CC6	4214	CR 29.505 0296 Rel-16 Addition of SMSF registration notification flag	NTT DOCOMO	Postponed	WI 5G_eSBA CAT F Anders: Not objecting to the principle, but wondering if perhaps there is a bit of overhead in having a unique resource for a single Boolean value. Could it be combined with the MessageWaitingData resource Hiroshi: Actually our initial idea was to define a new resource that contains both MessageWaitingData and SMSFRegistrationNotificationFlag, then we felt that has a backward compatibility issue. We are totally fine to go with this initial idea, if people prefer. or is there a use case for the SMSFRegistrationNotificationFlag to be set when there is no MWD? Hiroshi: No. Whenever SMSFRegistrationNotificationFlag is set, there is a pending MT-SMS, then there is SC that retains this MT-SMS. This means there is MWD (i.e. the list of those SCs). On the other hand, the existing of MWD does not mean SMSFRegistrationNotificationFlag is set. There is a case only Urrpindicator is set and there is MWD. If not, perhaps the presence of MWD data can indicate the same thing? Hiroshi: No. (See the above.) Anders: I have a couple of follow-up questions: Currently, there are separate AMF URRP flags, one for 3GPP and one for Non-3GPP access. Is there a need for an SMSF Registration Flag Notification per access type as well? Hiroshi: No The timing SMSF Registration Flag Notification is cleared is when a SMSF gets registered. This means the UE is during the UE Registration process and in connected mode, and therefore this is a good timing for SC to retry sending a pending MT-SMS. It does not matter whether the SMSF is activated for either 3GPP or non-3GPP; the UE is now connected In 23.040, the MWI – Message Waiting Indication (clause 3.2.6) is a superset of MWD and e.g. MNRF, MCEF, MSISDN Alert and so forth. I’m not sure if the whole or a subset of MWI (besides MWD) is applicable in the limited SMS in UDM that is currently supported, but if it is, perhaps renaming the current MWD resource, or at least change its description to allow it to also support additional MWI data as needed, could then also host the SMSF Registration Flag Notification(s) as applicable. What do you think? Hiroshi: We agree with you in that “change its description to allow it to also support additional MWI data as needed” We agree with you on the potential additional indications. We discussed internally, that MCEF might be needed depending on IoT devices coming in the market. TS 23.501/502 does not suggest its necessity and we will not propose to it, but if someone else proposes, we are fine with that. That said, even if MCEF is to be included, we need to think again if it is a good idea to merge it here in the same resource. “renaming the current MWD resource” is also fine for us. Maybe “change its description” might be less harmful considering the stage 3. The current MWD resource includes at least one SC data. Therefore the above approach does not allow to set SMSF Registration Notification Flag and not to include any SC data. But we don’t see this situation happens Ulrich: for my clarification please: Isn’t it so that, whenever the UDM detects that an SMSF registers, it checks the (existing) mwdList within the MessageWaitingData and alerts all the service centres stored therein. Can we not safely assume that SMSF registration implies UE presence? Why is an additional flag needed? Anders: After some internal discussion, we notice that the IpSmGwRegistration already supports the unriIndicator. Hiroshi: We agree with you. We believe it would also make sense to have similar indicators for SMSF 3GPP and SMSF non-3GPP (mnrf-SMSF-3GPP and mnrf-SMSF-Non3GPP) in the respective SMSF Registration resource. [Hiroshi] We agree with you. If we happen to decide to introduce MCEF, these resources are the appropriate places to define them The UDM can then set the correct flag based on the Delivery Outcome if an SMS was not delivered even if the SMSF is registered but delivery was not possible (from 29.336): Hiroshi: We agree with you. 5.3.3.27 SMSF-3GPP-SM-Delivery-Outcome The SMSF-3GPP-Delivery-Outcome AVP is of type grouped and shall indicate the outcome of the SM delivery for setting the message waiting data in the HSS when the SM delivery is with an SMSF registered for 3GPP access. AVP format: MME-SM-Delivery-Outcome::= <AVP header: 3336 10415>> [ SM-Delivery-Cause ] [ Absent-User-Diagnostic-SM ] 5.3.3.28 SMSF-Non-3GPP-SM-Delivery-Outcome The SMSF-Non-3GPP-Delivery-Outcome AVP is of type grouped and shall indicate the outcome of the SM delivery for setting the message waiting data in the HSS when the SM delivery is with an SMSF registered for Non-3GPP access. AVP format: MME-SM-Delivery-Outcome::= <AVP header: 333710415>> [ SM-Delivery-Cause ] [ Absent-User-Diagnostic-SM ] 5.3.3.19 SM-Delivery-Cause The SM-Delivery-Cause AVP is of type Enumerated and shall indicate the cause of the SMP delivery result. The following values are defined: - UE_ MEMORY_CAPACITY_EXCEEDED (0) [Hiroshi] This corresponds to MCEF. But so far SA2 (and CT4) has not decided this error needs to be taken care of. - ABSENT_USER (1) [Hiroshi] This corresponds to URRP. This is already specified in Amf3GppAccessRegistration and in AmfNon3GppAccessRegistration. - SUCCESSFUL_TRANSFER (2) And subsequently, there would no need to maintain a separate SMSFRegistrationNotificationFlag outside the SMSF registration resources. [Hiroshi] This is a separate discussion. SMSFRegistrationNotificationFlag can exist even if SMSF has not registered What do you think? CC Ulrich it is sufficent to have an SMSF registered. No separate flag is needed Hiroshi in his understanding Stage 2 requires it. Anders have alos some problems with this additional flag and its usage. Marco: supports Anders and ulrich there is no need for a new flag. Hiroshi: Based on the discussion in the conf call on Monday, I assume CT4 is in favor of not introducing a dedicated SMSF registration notification flag. However, as I indicated in the call, stage 2 in TS 23.502 indicates a dedicated flag, and therefore if we proceed with the CT4’s current majority opinion stage 2 and 3 is not in sync. Therefore, if the proposed CR (or its revision) is not acceptable, we propose to send an LS to SA2 asking whether a dedicated flag is needed based on the consensus in CT4 and to revisit what is specified. I have created a draft LS to ask SA2, and have uploaded in the inbox. https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.1/C4-204xxx_new%20LS%20on%20SMSF%20Regisration%20Notification%20Flag.docx Thank you. Do we have to send LS to SA2? CC Anders would support sending an LS. We need to wait for the reply from SA2
4437	LS out LS on SMSF Registration Notification Flag	Hiroshi	To: SA2 Hiroshi: Based on the discussion in the conf call today, I have provided a new LS (C4-204377, LS out, LS on SMSF Registration Notification Flag) and is now available in the inbox. https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.1/ Apart from the headings, the content is the same as provided without a tdoc number shown in the link below
4215	CR 29.504 0103 Rel-16 Addition of SMSF registration notification flag	NTT DOCOMO	Agreed	WI 5G_eSBA CAT F
4246	CR 23.527 0024 Rel-16 Reselection when the Routing Binding Indication unavailable	Ericsson	Revised to C4-204456	WI 5G_eSBA CAT F Use of non-breaking spaces in references Bruno: Clause 6.5.3:, the new reqt (“the SCP may use it to perform a NF service discovery procedure and reselect a NF (service) instance”) may ONLY apply if any of the conditions of the preceding bullets are met. This should be clarified. "may include the"3gpp-Sbi-Producer-Id" header in the request ": this is different from what cover sheet says "the SCP may use use NF service discovery factors which are conveyed by the"3gpp-Sbi-Discovery-target-nf-instance-id" request header if the NF Service Consumer includes in the request message;. We are fine with using 3gpp-Sbi-Producer-Id" header in the HTTP requests, extended with an NF set ID, see our comments to C4-204247. So cover page of the CR should be aligned. Note also that description of the producer-id header in 5.2.3.2.1 of 29.500 needs to be updated (if CT4 agrees with the proposal to use this header in HTTP requests). Clause 6.x: "session context" -> "resource context" (in several occurences) Clause 6.x.1: typo: "all available NF (Service) Instances within the NF (service) set is able .." "an NF Service Consumer in an NF (Service) Set may create a session context for callback ": the rest of the procedure in the CR actually assumes the consumer in an NF set always does so. We should specify that if an NF consumer does not support so, it should update the callback URIs towards the producer when the consumer NF changes, as described in step 6 of 29.500 clause 6.5.3.2. Clause 6.x.2: We should also add a reference to clause 6.5.3.2 of 29.500 Clause 6.x.3: In the first bullet, reselection of an alternative service instance in the NF instance should only be allowed if NFProfile of consumer indicates support of resource storage persistence. This also assumes that producer gets by some means the consumer NF instance iD. typo: "the the name " 2nd bullet: same NF (service) set How does the producer indicates the Consumer ID to the SCP for indirect communication? Bruno: I have one more question/comment to this CR (repeating below the last comment I have just made on C4-204247): Last but not least, regarding the reselection of a consumer instance when no binding info has been received in the subscription request (cf CR in C4-204246), how does the producer know the NF instance id of the consumer to include in the notification / callback request sent to SCP (for potential reselection of the consumer instance at the SCP) ? [Frank] I know SMF knows AMF NF ID/GUAMI and will be able to reselect another AMF The CR does not define how to do so, e.g. for all subscription requests of APIs which do not support today providing the ID of the subscribing NF? Does this imply that reselection of a consumer instance is only supported for these APIs whose subscription requests (or requests providing a callback URIs) include today the requester NF instance ID? [Frank] Yes, it is depending on per service API. Or should it be considered whether a Consumer ID header should be defined to enable any subscription request of any API to convey info about the NF instance ID, NF Set ID or Group ID of the consumer to the producer (when binding procedures are not supported)? [Frank] This can be done at next step; but I prefer this can be determined per service API Frank: I want to just highlight; reselection of consumer is NOT a must when there is no binding information provided earlier by the consumer. If NF producer is lack of consumer information, e.g. NF ID, it will certainly not able to reselect an alternative, the procedure fails. See also reply as above. The rest is also depending on the conclusion for 4247, which alternative we should go for. Bruno: Thanks. So then it should be captured in your CR that consumer reselection when binding procedures are not supported is only supported for APIs where the subscription request includes the NF instance id of the subscribing NF. Frank: Will capture the sentence below in the revision.
4456	CR 23.527 0024 Rel-16 Reselection when the Routing Binding Indication unavailable	Ericsson
CC1	continued in next column	4247	CR 29.500 0158 Rel-16 Reselection with indirect communication	Ericsson	WI 5G_eSBA CAT F Bruno: we do not like/agree with the principle that consumers need to generate the Routing Binding info on their own when no Binding Info has been received from the NF service producer. This is a misuse of the binding procedures, consumers have no clue on producer binding level (e.g. service instance, service set), and with delegated discovery, the consumer cannot do so as it has not interacted with the NRF. We have two main concepts: NF (service) set for 5GC resiliency and scalability Binding procedures that provides efficiency by enabling to reselect a preferred producer service instance of the NF service producer, based on producer binding information. If binding procedures are not supported by the producer, consumers shall not try to guess the binding information of the producer. Consumers or SCP will reselect an alternative producer service instance (when needed) based on NF (service) set concept and data storage persistency across service instances property of NF profile. [Frank] What we proposed is not to require the sender to guess the binding information of resource context in the service producer; Bruno: as a matter of fact, this is what your proposal requires. Binding level is a required parameter of the binding information, and consumer would need to provide a producer binding level on its own. And in delegated discovery scenarios, consumer has not interacted with the NRF and so has no clue about whether the producer instance is part of an NF (service) set or if the producer instance supports data storage persistency across service instances. [Frank2] First we are mainly aiming for reselection at a request towards the existing resource context in the NF producer or session context in the NF consumer. For indirect communication with delegation, for initial establishment of resource context, the consumer will use discovery factor*; and the consumer will receive 3gpp-Producer-Id inserted by the SCP. If using Routing Binding Indication, it will be the same as what is included in 3gpp-Producer-Id. in our view, routing binding indication is solely used by SCP to enable it perform a reselection, without such reselection parameter/information, the SCP has to populate the failure back the sender, so in such case (when the receiver has not provided binding indication) and if the sender would have to reselect a receiver, it may provide routing binding indication if it wishes to reselect at the failure to reach the target, otherwise it may not include such reselection parameter (basically if the target is reachable, the procedure fails). Bruno: your alternative proposal to include the producer id in the HTTP request enables the SCP to do a reselection What is problem if a sender includes a routing binding indication (which is built by itself)? Bruno: see above. In scenarios where producer does not return binding indication, the consumer gets the 3gpp-Sbi-Producer-Id from SCP (or consumer has selected the producer itself). So it is logical and straight forward to include the same 3gpp-Sbi-Producer-Id in subsequent HTTP requests. So we propose, when binding info is not available or supported, that consumer includes the 3gpp-Sbi-Producer-Id header in subsequent HTTP requests targetting an existing resource, as you also propose (it’s not clear actually why you propose two different mechanisms), that allows the SCP to reselect an alternative producer instance. And we propose to expand the producer id header to also include the NF set ID when available to cover the case where the original NF producer instance profile is no longer registered in the NRF e.g. as a result of a scale-in operation. [Frank] Yes, we proposed two mechanisms, either using Routing Binding Indication, or using 3gpp-Sbi-Producer-Id. We think using Routing Binding Indication (the sender creates it ) has following benefits: It covers both cases when the sender is a NF consumer or a NF producer; the sender It has no impact on the SCP, and SCP continues to use Routing Binding Indication. Bruno BUT in any case, there is one impact on SCP in your proposal since your CR ALSO proposes to support the option to include the 3gpp-Sbi-Producer-Id in subsequent HTTP requests. For what purpose is this if this is not to be used by the SCP? We think for a notification or callback request, it is strange for a service producer to use 3gpp-Sbi-Producer-Id; however such request messages need SCP (when indirect communication applies) also perform a re-selection. Bruno you need to define how to convey the consumer ID in notifications, as part of your other CR (dealing with reselection of a consumer). You may define a Consumer ID header [Frank2] Yes, using 3gpp-Sbi-Producer-Id will impact SCP. In our view, using Routing Binding Indication will simplify implementation in both sender (if it support binding indication concept) and the SCP. The summary below (you proposed) does not cover the reselection for notification or callback requests from a NF producer, we think it is not complete. Bruno see above So in summary, the system would work as follows: When binding is supported, producer returns Binding header; subsequent requests contain Routing Binding header. (this is per existing spec) When binding is not supported and SCP selects a producer instance, SCP includes Producer ID in HTTP response; subsequent requests contain the same Producer ID header. When binding is not supported and NF consumer selected itself the producer instance (e.g. model C), subsequent requests contain the Producer ID header set by consumer to the NF instance id of the producer. In other words, either Binding/Routing Binding headers are used, or Producer-Id (incl. NF Inst ID and Set ID) is used in HTTP response/subsequent HTTP requests. Using Producer-Id in subsequent request (rather than a discovery header) is also an indication that no discovery is required to be made by the SCP unless the Target-apiRoot is not reachable. Detailed comments 5.2.3.2.5: "otherwise the sender may create a Routing Binding Indication if possible, e.g. based on the NF Profile of the target NF (service) Instance to enable the SCP perform a reselection, e.g. when the NF Service resource owner instance is part of an NF set (or AMF set) or an NF service set, or its NF profile indicates that its supports NF service persistence within the NF instance (see clause 6.5 of 3GPP TS 23.527 [38])." cf: comment above In any case, this is not ether the right place to document consumers behaviour. It is not clear whether consumer includes Producer ID header or a Routing Binding header that it has computed on its own in subsequent requests targetting an existing resource, when no binding header has been received during resource creation. 6.10.3.4: - first change: clash with our CR (C4-204188). We can accept always including the Producer ID regardless of presence of Binding header. - 2nd change: not the right clause to specify these reqts. We should also strengthen the reqt "The NF Service Consumer may include "3gpp-Sbi-Producer-Id" request headers, " for subsequent requests targetting an existing resource when the Routing Binding header is not available. 6.10.5.1: NOK with the first change, see above 2nd change is already specified in the spec, no need to repeat [Frank] 2nd change is not specified yet, the existing requirement is just for indirect communication with delegation. Frank: comments inline above First to clarify, our CR is to address reselection at failure to reach the target, and we proposed two mechanism, using Routing Binding Indication or 3gpp-Sbi-Producer-Id. For Routing Binding Indication, we propose a sender (either a NF consumer or a NF producer) may create Routing Binding Indication on its own based on the knowledge to the receiver, to enable the SCP to perform a reselection. Note, the routing binding indication is solely for SCP to perform a reselection of the target if target is NOT reachable. Bruno: Please see my replies inline above. I maintain my earlier comments. We don’t agree with the proposal with its current content. Frank: However, I didn't find concrete drawback using Routing Binding Indication to enable SCP to perform a reselection. If the receiver didn't provide a binding indication which truly reflects the resilience level of session context, the reselection can only be done at best effort, the reselection may or may not work; enabling the sender to build and transfer "routing binding indication" just a method to convey reselection parameters to the SCP, so that to make a reselection and avoid failure be populated back to the sender. And, routing binding indication can contain more information, e.g. service name, to make SCP to have a Correct and better reselection for existing resource context. CC Frank main purpose is to trigger SCP reselection Bruno: why we need 2 Solutions? Companies are requested to provide their opinion. One topic is the case when consumer does not support binding indication. Ravi CR in this area is also C4-204128 but this is for Rel-17. Bruno: Just to capture some of the points I made during today’s CT4 call: We already have a complete solution today in CT4 specs for NF service instance reselection when binding procedures are supported. We agree with the principle of further defining how to reselect a target NF service instance in subsequent HTTP requests with indirect communication when binding procedures are not supported end to end (or no binding header has been received from the producer/consumer) – assuming that discovery headers are not meant to be used in subsequents requests targeting an existing resource. But this should also encompass the case where the consumer (or producer for notification) does not support binding procedures, e.g. deployments where binding procedures are not supported yet in the entire network. In this case, a consumer is likely not capable to build a routing-binding header. What the consumer has is the Producer ID received from SCP (if SCP selected the producer instance), so consumer could easily insert the same producer id header in subsequent requests. That would allow the SCP to retrieve the producer profile if the request cannot be delivered to the target apiRoot, and to reselect an alternative service instance (e.g. based on NF set, NF service set or data storage persistency property in NF profile). [Frank3] When the sender has the NF profile of receiver available, i.e. it has access to the NRF, e.g. for Indirect communication without discovery delegation or a notification request from a service producer, it can easily build a routing binding indication; while using using 3gpp-sbi-producer-id can not precisely provide a re-selection range, e.g. the consumer want to reselect a service producer in a service set, or a producer want to reselect an alternative endpoint which can be retrieved using a specific service name. (this has been supported in Rel-15 for AMF set). The routing binding indication can do that. For indirect communication with discovery delegation, the consumer may only have 3gpp-sbi-producer-id; and according to the sematic of existing routing binding indication, the SCP can only select an alternative endpoint within the NF instance. The consumer may not be able to build on its own a correct Routing-Binding header since it cannot know e.g. how the producers handle its context (e.g. persistency across service instances of an Nf instance, service set or NF set) i.e. how to set the binding level and binding IDs and it may not have part of such information e.g. in scenarios with delegated discovery. So consumer would end up building a Routing-Binding header that incorrectly and/or incompletely reflects what the producer can support (e.g. context persistency across NF set, or across NF service instance). [Frank3]The reselection parameter conveyed in routing binding indication (if it is not copied from binding indication) are the same as the one used when the consumer has to perform a reselection; it, of course, may not precisely reflect how the producers handle its context, but it is the same if we use 3gpp-sbi-producer-id. However, requirement in 6.5.3 of TS 23.527 specifies some requirements when binding indication is not available, these requirements will ensure that the reselection of NF service instance will be successful. NOTE that, to precisely reflect how the producer handles the context, the producer needs provide the Binding Indication for the context. Your CR actually proposes 2 solutions for the use case where binding is not supported end to end. All the comments you raise related to the solution based on using producer id header in HTTP requests also apply to your CRs. So e.g. how SCP identifies service name or how producer indicates consumer id to the SCP in a notification request. [Frank3] As commented above, maybe the best is: Use 3gpp-producer-id for indirect communication with discovery delegation, the SCP uses it to perform a reselection; (in this scenario, the SCP does initial selection anyway; Use Routing Binding Indication for other cases, i.e. when the sender has NF profile of receiver available, so the sender can precisely instruct SCP to perform reselection. In the CR, I wanted to give more freedom to the implementation, so I have avoided to specify which solution should be used in which case. Bruno: One more point wrt: And, routing binding indication can contain more information, e.g. service name, to make SCP to have a Correct and better reselection for existing resource context Please note that in a service request towards a producer, the Routing-Binding header cannot anyhow indicate a service name. It can only indicate a specific service instance ID, which the consumer would actually not know with indirect communication with delegated discovery or w/o delegated discovery when consumer only selects the NF set. So the only possible solution per existing specs is that the SCP derives the service name from the HTTP URI. Frank: Thanks for comments, those comments are valuable. The whole intention of CR (4246 and 4247) is to ALLOW a sender to provide some reselection parameters (for the SCP) in a request message (addressing existing resource (session) context in the receiver), to enable the SCP to perform a reselection of receiver (either a consumer or a producer) if the receiver as indicated in the target URI (or 3gpp-Sbi-Target-ApiRoot) is not reachable, when the receiver didn't provide a Binding Indication earlier. These reselection parameters will be used by the sender if the sender needs to perform a reselection; with indirect communication, the sender just delegate such reselection to the SCP, in order to avoid SCP to populate the failure back to the sender. The solution should support to convey such parameters in a service request (from consumer to the producer) but also in a notification or callback request from a producer to a consumer. The Routing Binding Indication seems a right candidate to convey such parameter. Please see further inline above Yue: didn't follow the whole discussion yesterday nor go through the email serial. Just provide my view on this topic below: Is it possible for the NF consumer to differentiate the cases where a) binding is in principle needed but due to some reason the binding indication is not included in the message; and b) binding is not needed i.e. the binding indication is not included intentionally? For the later case, the implementation may have fully stateless NF instances, and the subsequent messages are not forced to be routed to the initial NF instance for sakes like load balance. I wonder if the NF consumer has the full information to construct routing binding indication, I mean, if the NF consumer is able to create a routing binding solely based on the NF profile why do we need binding indication at all? Bruno A consumer does NOT have the full information from an NF profile to build the routing binding information, e.g. it has no clue on whether the producer supports a binding level of NF set (e.g. stateless NF) or a binding level of NF Instance or NF service instance (e.g. when a specific producer instance keeps a resource context locally), and when using delegated discovery, whether the producer is part of an NF set or NF group or whether it supports NF service set. To respond to your first question, Yue, a consumer cannot determine whether a producer does not support binding or did not intentionally include binding information. I don’t think the consumer needs to differentiate this. There is actually a simpler solution to enable an SCP to reselect a different target service instance when the target apiRoot of an subsequent HTTP request targeting an existing resource is not reachable: this is to use the existing discovery headers, identifying e.g. the target NF instance id, target NF set id, Group ID, and/or service name, exactly like a request that creates a resource. This does not cause any new SCP impact, does not require any new protocol change (no need even to send the producer id header in an HTTP request), this is fully flexible (this even supports e.g. sending requests to a UDM/AUSF/UDR/PCF/CF group if these NFs do not support the set concept), this works fine also for notification/callback requests and this is future-proof (as this will support any new parameter we may introduce later for the (re-)selection of an NF). There is absolutely no ground for not allowing so. So if binding is not supported or if binding information is not available, the HTTP sender includes the appropriate discovery headers in the subsequent requests, that the SCP can use when it cannot send the request to the target URI. This approach is actually not precluded in the existing specification, although it might not be mentioned explicitly. Additionally, I still think that it would also make sense to extend the 3gpp-Sbi-Producer-Id returned in the HTTP response with optional parameters conveying the producer NF set ID or Producer NF Group ID, for indirect communication with delegated discovery, to enable the SCP to reselect an alternative producer instance using the discovery header identifying the target NF set or Group ID, when the SCP cannot send the request to the target apiRoot and the NF profile of the original producer id is no longer registered in the NRF (e.g. after a scale-in operation). But this could be considered as a separate CR at the next meeting. Last but not least, regarding the reselection of a consumer instance when no binding info has been received in the subscription request (cf CR in C4-204246), how does the producer know the NF instance id of the consumer to include in the notification / callback request sent to SCP (for potential reselection of the consumer instance at the SCP) ? The CR does not define how to do so, e.g. for all subscription requests of APIs which do not support today providing the ID of the subscribing NF? Does this imply that reselection of a consumer instance is only supported for these APIs whose subscription requests (or requests providing a callback URIs) include today the requester NF instance ID? Or should it be considered whether a Consumer ID header should be defined to enable any subscription request of any API to convey info about the NF instance ID, NF Set ID or Group ID of the consumer to the producer (when binding procedures are not supported)? So I believe the issues raised by these CRs can be easily solved with the above solution, with minimal changes to the existing specs, and w/o misusing the binding headers when binding is not supported or available.
CC4	continued in next column	4247	CR 29.500 0158 Rel-16 Reselection with indirect communication	Ericsson	continued Frank: As commented earlier, the whole intention of CR (4246 and 4247) is to ALLOW a sender to provide some reselection parameters (for the SCP) in a request message (addressing existing resource (session) context in the receiver), to enable the SCP to perform a reselection of receiver (either a consumer or a producer) if the receiver as indicated in the target URI (or 3gpp-Sbi-Target-ApiRoot) is not reachable, when the receiver didn't provide a Binding Indication earlier. These reselection parameters will be used by the sender if the sender needs to perform a reselection; with indirect communication, the sender just delegate such reselection to the SCP, in order to avoid SCP to populate the failure back to the sender. Now there seems three different alternatives on the table: Using Routing Binding Indication, the sender MAY construct a routing binding indication based on the NF profile of the receiver; Bruno> this approach does not work e.g. when HTTP client (consumer or producer) does not support binding indication, and it has all the flaws I already mentioned. I cannot agree on it. Using 3gpp-Sbi-producer-id, received from the SCP earlier in a response message, and include it in the subsequent request message; Using 3gpp-Sbi-discovery*, allowing sender (either consumer or producer) to include 3gpp-Sbi-discovery* in the request message, to request SCP to perform reselection. (@Landais, Bruno (Nokia - FR/Lannion)Not sure I understand you correctly from what you describe below as highlighted in yellow, please confirm. ) Bruno> this is NOT to “request SCP to perform reselection”, but to provide the necessary discovery information to the SCP if the SCP needs to do a reselection (because the target URI is not reachable). A question to this new alternative, whether SCP can differentiate the initial establishment of resource context from the subsequent modification of an existing resource context, since for the first case, the SCP shall use discovery* to select, while for the second case, the SCP only use those discovery* when the target is not reachable. Bruno SCP selects a target NF service instance when none has been indicated by the HTTP client i.e. when the target-apiRoot is not present (this is the case of an initial request, when the consumer has not selected a specific producer service instance). SCP may reselect a target NF service instance when it cannot reach the target-apiRoot it has received from the client. So SCP always know whether it shall or it may reselect a target NF service instance (based on the presence or absence of the target-apiRoot header). I recommend moving forward with the 3rd approach above, for the reasons I explained in my earlier email. CC Frank ask for comments on Bruno’s new alternative. The intention is to discuss it on Friday 21st conference call. Frank summary status on Thursday 20th: Continued I try to summarize the intention of CR and make a fair analysis, considering other's comments. Hopefully it helps to lead a conclusion. The CRs (4246 and 4247) is addressing, when Indirect communication is deployed, and the Binding Indication is not provided by the receiver earlier. We need a way to provide some reselection parameters (to the SCP) in a request message (addressing existing resource (session) context in the receiver), to enable the SCP to perform a reselection of a receiver (either a consumer or a producer) if the original receiver as indicated in the target URI (or 3gpp-Sbi-Target-ApiRoot) is not reachable, When the Binding Indication is not provided by the receiver, such reselection is ultimately controlled by the sender, i.e. these reselection parameters would be used by the sender if the sender needs to perform a reselection (in case of direct communication); with indirect communication, the sender just delegate such reselection to the SCP, in order to avoid SCP to populate the failure back to the sender. Of course, the sender may also decide to not include such reselection parameter, e.g. to decide whether to perform reselection by itself. Now there seems three different alternatives on the table to convey such reselection parameters to the SCP: 1. Using Routing Binding Indication, the sender MAY construct a routing binding indication (if it supports Binding Indication) based on the NF profile of the receiver (if such information is available); Pros: the SCP can always use Routing Binding Indication as if Binding Indication is available; Bruno> however with possibly incomplete and incorrect information When the sender has the NF profile of receiver available, i.e. it has access to the NRF, e.g. for Indirect communication without discovery delegation or a notification request from a service producer, it can easily build a routing binding indication; Bruno> even if consumer has access to the producer profile, it would have to set a producer binding level in the Routing Binding level w/o knowing the producer implementation, this can result in incorrect information and sub optimal reselection by SCP, and different reselection approaches by SCP based on how each consumer would set this binding level Using routing binding indication can precisely provide a re-selection range that the sender wishes to select, e.g. the consumer wants to reselect a service producer in a service set, or a producer want to reselect an alternative endpoint which can be retrieved using a specific service name. (this has been supported in Rel-15 for AMF set). Cons: Bruno> this solution deviates from 23.501 which specifies that that : “If the request recipient had previously provided a Binding Indication, then the request sender shall include a Routing Binding Indication with the same contents in subsequent related requests. » Bruno> This solution does not support all scenarios so different solutions need to be supported (in addition to the already defined solution when binding is supported end to end)this approach does not work e.g. when HTTP client (consumer or producer) does not support binding indication; BL> does not support reselection in a NF group if target NF is part of a NF group and does not support set concept , (Bruno>) and where the consumer needs to include in the Routing Binding header a producer binding level set on its own (when it has no clue on what producer supports) and based on this NF Id, the constructed Routing Binding Indication may limit SCP only select alternative endpoint WITHIN the NF (identified NF ID); A possible enhancement to improve 3gpp-Sbi-Producer-id, so require SCP to return more information, e.g. NF (service) set, but this will have a protocol change. . (Bruno>) Consumer needs to set a producer binding level on its own (e.g. to NF instance or NF set), causing possibly different SCP reselection approaches for different requests sent to the same producer from different consumers, when delegated discovery is meant to delegate such tack to the SCP and to achieve an harmonized network behaviour Bruno> does not support reselection in a NF group if target NF is part of a NF group and does not support set concept 2. Using 3gpp-Sbi-producer-id, received from the SCP earlier in a response message, and include it in the subsequent request message; Pros: Easy implementation in the consumer. Bruno> Absence of disc headers in a subsequent request is an immediate indication that no selection is needed unless the SCP cannot send the request to the target apiRoot Cons: new requirement for the consumer to include 3gpp-Sbi-producer-id in the request, and new requirement for SCP to use this information to perform reselection; and the logic in the SCP is different from using Routing Binding Indication where the reselection range is defined, and here it requires SCP to determine a reselection range via NRF procedure according the target NF profile; It works only when the sender is a consumer, not supporting notification / callback request; Bruno>so additional mechanism would be needed to support reselection of a consumer with indirect communication when binding procedures are not supported (e.g. a new consumer ID header) In case of indirect communication without delegation, the consumer may wish to perform reselection based on its own logic, not rely on what is provided by SCP in the 3gpp-Sbi-producer-id. Bruno> does not support reselection in a NF group if target NF is part of a NF group and does not support set concept 3. Using 3gpp-Sbi-discovery*, allowing sender (either consumer or producer) to include 3gpp-Sbi-discovery* in the request message, to provide the necessary discovery information to the SCP if the SCP needs to do a reselection (because the target URI is not reachable). Bruno> Note: only a very small subsets of existing discovery headers are necessary for subsequent HTTP requests (those identifying the target nf instance id, target NF set, and possible target Group ID, and for a notification: service name) Pros: The sender can well control reselection (within a range it wishes) at failure by using 3gpp-Sbi-discovery* to delegate SCP to do so; The SCP can use the same logic as doing initial selection for resource context establishment with only difference that it would be done when the original target is not reachable; (the SCP can well determine if reselection is needed) It can work regardless if the sender is consumer or producer; No protocol changes. . Bruno> And very minimal updates to existing specs Bruno> the solution also supports reselection of a target instance in an NF Group ID (if the producer does not support NF set, e.g. UDM) Bruno> Unique solution covering all scenarios where binding procedures are not supported end to end Bruno> complies with 23.501 reqts that : “If the request recipient had previously provided a Binding Indication, then the request sender shall include a Routing Binding Indication with the same contents in subsequent related requests. » Cons: The NF is forced to support discovery* header; for indirect communication without discovery delegation, the consumer always selects a service producer on its own. So, in such case, the consumer is not required to support discovery* headers. . Bruno> NFs will likely support indirect communication with and w/o delegation, for different use cases / APIs, so this is not an issue the NF with only service producer function is required to support discovery* header; Bruno> NF producer needs anyhow to support e.g. a new callback header (for intra PLMN communication), so having to support discovery header identifying the consumer id is a minimal extra effort Now, Nokia prefers alt 3, and Ericsson is proposing 1 + 2. Bruno> it is clear to me that alt 3 should be the way forward. The important is that we should fix the issue as soon as possible, as Rel-16 implementation has started. Abdessamad Many thanks Bruno and Frank for summarizing the status of the discussions on this topic and possible solutions. Before providing our view, I would like to understand how critical this issue (i.e. indirect communications are used and the binding mechanism is not supported) actually is because I have the impression that the 3 solutions below introduce impacts on existing specifications and/or more importantly impose additional requirements to consumers and producers (for notifications). One can also say that maybe the case where indirect communications are used but the consumers/producers do not support both the binding mechanism and whatever alternative solution (from the 3 ones below) we agree on. I am just wondering if such matters should not be simply handled by the SCP by configuration. In case of indirect communication without delegated discovery, there are 2 cases: When the consumer performs the selection, then it is able to perform re-selection as well. [Frank] The consumer can always do re-selection if the failure is detected. The point is that we don't want the failure traverse through the whole network back, that's why we want to delegate SCP to do reselection. If we want the SCP to perform re-selection as well, then it is maybe better to delegate to it the initial selection as well ! [Frank] Yes, current spec already requires so, in case the consumer selects a NF (service) Set, it includes discovery* header to denote NF (service) Set The point I want to make here is that it does not make sense to be in this scenario where the intention is to leave the control of the discovery and selection to the consumer and at the same time request the SCP to perform re-selection. [Frank] It is not the case One possible way to improve this and enable the SCP to perform re-selection is maybe to require the consumer to send NF set and NF service set information in a similar way as for the next scenario. This way, the SCP will be able to use this information for re-selection. When the SCP performs the selection, it receives the NF set and/or NF service set information from the consumer to be able to perform this task. This same information is more than sufficient for the SCP to perform re-selection afterwards in case of failure. [Frank] I don't think the SCP is stateful for next HTTP transaction for a given session. The reselection parameters need to be conveyed in the same message. In case of indirect communication with delegated discovery, the SCP performs the discovery and selection based on the discovery parameters. In case it needs to perform re-selection for subsequent requests, then it has all the information it needs to perform re-selection for subsequent requests. [Frank] I don't think the SCP is stateful for next HTTP transaction for a given session; guess it is also impossible. The reselection parameters need to be conveyed in the same message Frank: I think the issue is important to resolve, otherwise it loose one of most important benefit of introducing indirect communication and SCP. The SCP should be able to do non-functional reselection of the target at both initial (establishment) and subsequent (modification) requests. With (Routing) Binding Indication available (supported), SCP can do the reselection perfectly, the SCP should be able to do it when (Routing) Binding Indication is NOT available. See above. CC4 Frank, Bruno we need to solve. Abdessamad would like to hear more voices Giorgi needs more time. Bruno alternative 3 has minimal impact Abdessamad does not agree. Scenario is indirect communication with stateless SCP. Zhijun: would prefer alternative 3. Bruno: we should go for a solution with minimal changes Frank to prepare a revision of the CR on alternative 3
CC5	3rd column	4247	CR 29.500 0158 Rel-16 Reselection with indirect communication	Ericsson	Revised to C4-204457	Giorgi: Sorry for joining this discussion this little late, but I have few questions on the reason for change. The CR tries to solve the problem for Rel-15 NFs, which do not support binding. Is this a correct understanding? Frank] Not really. The CR is intended for a network scenario where not all Rel-16 entities support (routing) Binding indication. See TS 23.527, where the reselection is divided into two scenarios, when binding is available and when binding is NOT available. The CR is addressing when Binding is not available The CR assumes that Rel-16 NFs shall support binding. Is this a correct understanding? Frank] No, see above The CR assumes that Rel-16 NFs shall always send binding indication if model C or D is deployed. Is this a correct understanding? Yue and Abdessamad asked similar question. [Frank] No, if Binding Indication is available, and the sender also supports Binding Indication, it can use Routing Binding Indication then. If the answers to the above questions clarify that there is a valid use case for a Rel-16 NF for not sending a binding indication on purpose, then I would question the reason for the change. Frank Please see my answer above. Please also find revisions: https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.1/C4-204246_v1_Reselection_when%20routing%20binding%20indication%20not%20available%20A.zip https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.1/C4-204247_v1_Reselection_with_indirect_communication%20A.zip Giorgi Thanks for the answers. Quote from the revised CR, which relates to my 3rd question: “An NF service consumer may also include "3gpp-Sbi-Discovery-*" headers in an HTTP/2 request targeting an existing resource context in the NF service producer, if the "3gpp-Sbi-Routing-Binding" header is not included in the HTTP/2 request message (e.g. when no binding information was received from the NF service producer during the resource creation, or if the NF service consumer does not support the binding procedures)…”. If a Rel-16 producer that supports BI decides not to send BI for some reason, the proposal is that the consumer should do something about this and send "3gpp-Sbi-Discovery-*" headers to the SCP. My question was, would the proposal somehow go contrary to what Rel-16 producer wanted? Frank: We didn't propose a NF service consumer "should" include "3gpp-Sbi-Discovery-*" headers to the SCP, we have used "may" if Routing Binding Indication is not included in the request message. And it has nothing to do with what "producer" wants, it just provides means to enable SCP perform a reselection if the NF producer is not reachable. CC Frank this is not for interworking bwith Rel-15 it is for interworking with Rel-16 not supporting binding. Bruno: this applies also for indirect communication with delegated discovery. Bruno: Nokia supports the draft revision. Frank: the solution is optional reflected by “may”
4457	CR 29.500 0158 Rel-16 Reselection with indirect communication	Ericsson
4253	CR 29.500 0159 Rel-16 API Root Change Handling	Ericsson	Revised to C4-204439	WI 5G_eSBA CAT F Other specs effected? Bruno: 6.10.4: - "unless the SCP did not change the target URI when forwarding the request from the NF as HTTP client to the NF as HTTP server" : it would be clearer to specify it the other way around, i.e. "if the SCP changed the target URI when forwarding the request from the HTTP client to HTTP server, it shall ..." /Jones: Refined. "NOTE 3:The NF as HTTP client can updates the locally stored URI " /Jones: fixed. Ravi: In general I am okay with the CR and support the concept. However I have following comments/clarifications – highlighted in Red Text below. Clause 5.3.2.1. This header is used by an HTTP client to indicate the apiRoot of the target URI when communicating indirectly with the HTTP server via an SCP, and used by SCP to indicate the apiRoot of the target URI if a new HTTP server is selected or reselected and there is no Location header included in the response. Ravi) The sentence is too long and slightly confusing. Can we break this into 2 sentences ( just like section 5.2.3.2.4) to make it more clear. Here is my suggestion “This header is used by an HTTP client to indicate the apiRoot of the target URI when communicating indirectly with the HTTP server. This can also be used by SCP to indicate the apiRoot of the target URI, if a new HTTP server is selected or reselected and there is no Location header included in the service response.” Jones: Yes, I will take your rephrased two sentences in V1 draft. Clause 6.10.4 NOTE 3: The NF as HTTP client can update the locally stored URI (e.g. resource URI or notification callback URI) used in the request with the target apiRoot received in the HTTP response, and thus send subsequent request to the updated target URI. Ravi) Clarification: my understanding is that if HTTP client updates the local URI and use the target apiRoot then SCP would not have to do the reselection in the subsequent message (unless the server is down/unavailable again). If this is true then can we reflect this in the NOTE3 as “To avoid reselection of server by SCP, the NF as HTTP client …….” /Jones: Your understanding is correct. I will indicate it in NOTE 3 in V1 draft. Abdessamad Just one question regarding the solution proposed here, can the SCP make use of the Location header instead of using the 3gpp-Sbi-Target-apiRoot in this case? I would more appropriate in my opinion and the SCP has all the information to do so. Jones We also considered this alternative. Location Header by HTTP definition only meaningful for certain responses, e.g. 201 or 3xx response, which makes it even more misleading when adding the Location header for other messages. Another risk is that a HTTP intermediate may reform the message and filter standard headers while let the custom headers pass. And only pass the apiRoot use less bytes in traffic, consider some URL may be really long… 😊 Abdessamad: Many thanks for these clarifications. No additional comments on my side so far Jones: V1 draft is uploaded in /Inbox/drafts/7.1.1 Bruno: Thanks, the revision looks good. Just one point for clarification: This header contains the apiRoot of the selected or changed target URI in a response sent to an HTTP client, when SCP selected or reselected a new HTTP server to route the request and no Location HTTP header is included in the HTTP response Which use case do you consider for an SCP “selecting” a new server and no location header happens to be returned by the server? Jones: What I thought is that certain service operation doesn’t return 201 as the successful operation, e.g. when AMF update authorized slice information on an NSSF (with a PUT and 200 OK response). If the AMF invokes the service operation on NSSF with Option-D or Option-C with Set, the AMF will not include target-apiRoot to SCP and SCP will select a NSSF instance to relay the message. As 200 OK doesn’t include a Location header, the SCP can use the mechanism to inform the selected target API root to AMF.
4439	CR 29.500 0159 Rel-16 API Root Change Handling	Ericsson
4254	CR 29.500 0160 Rel-16 Default Subscription Binding	Ericsson	Revised to C4-204440	WI 5G_eSBA CAT F Other specs effected? Bruno: like for many of your CRs, you need to fix the cover page for the other affected specs. The rest looks good. Jones: Please find V1 draft in /Inbox/Drafts/7.1.1 The only change is to untick the affected spec field.
4440	CR 29.500 0160 Rel-16 Default Subscription Binding	Ericsson
4255	CR 29.500 0161 Rel-16 Notification for Default Subscriptions	Ericsson	Revised to C4-204442	WI 5G_eSBA CAT F Other specs effected? Bruno: There is a typo in the CR title. /Jones fixed Other specs affected ticked but w/o dependency indicated /Jones Fixed 6.10.2.4: "it shall use pseudo target URI for default subscription ("/scp-default-sub-notify-uri") in the ":path". But ":path" contains "optional deployment-specific string of the SCP and the path. /Jones: added optional deployment-specific string of SCP. 6.10.3.3: new bullets have a wrong style (B3 instead of B2) /Jones: Change to B2, and combined into one bullet. Jones Please find draft v1 in /Inbox/Drafts/7.1.1 Bruno: Thanks. There is one typo and a few editorials: When an HTTP client sending a notification request corresponding to default notification subscription where the target URI is unknown (e.g. for Indirect Communicatoin with Delegated Discovery, as specified in clause 6.10.3.3), it shall include the optional deployment-specific string of the SCP and the pseudo target URI for default subscription ("/scp-default-sub-notify-uri") in the ":path". - if the pseudo target URI for default subscription ("/scp-default-sub-notify-uri") is present in the ":path", the SCP shall replace it with the real path of the target URI registred in the selected default subscription.
4442	CR 29.500 0161 Rel-16 Notification for Default Subscriptions	Ericsson
4260	CR 29.510 0382 Rel-16 Connected SCP and NF ID	Ericsson	WI 5G_eSBA CAT F Other specs effected? Bruno: This CR depends on the SA2 reply to the LS sent by CT4 at earlier meeting. I still do not see the need for these parameters since we have the SCP domain concept. And this would cause overhead to provision every single NF instance served by an SCP in the SCP profile. Typo in Reason for change: "3GPP TS 23.510 specified” -> 29.510. Other specs affected needs to be fixed too, with the stage 2 CR dependency Zhijun: We share the opinion from Bruno. As the NF profile already indicates the SCP to which the NF belongs, it is no need to duplicate the NF list in the SCP profile Jones: Please find v1 draft in /Inbox/Draft/7.1.1. Fixed issues on cover page. For the motivation of the CR: We considered that the servingNfId could still be useful, when a request is to be delivered to a specific NF instance, e.g. the NF consumer received from the producer-id, the SCPc then may use this NF instance Id to directly find a SCPp to relay the message, otherwise, it will need to first query the NF profile form NRF, then subsequently use SCP domain to query an SCPp. Interconnected SCP may be used in scenario when not all the SCP are connected to each other between SCP Domains, e.g. to explicitly use different SCPs to avoid redundancy path failure. Anyway, let’s see how SA2 reply to us.
4261	CR 29.510 0383 Rel-16 Correction on attributes for SCP	Ericsson	Revised to C4-204446	WI 5G_eSBA CAT F Other specs effected? Giorgi: Please elaborate on the “Consequences if not approved”. Current text is little vague when it comes to exact FASMO details. /Jones: Refined the CoNA with more direct consequence. Also, in many CRs, e.g. 4253-55, 4260-62 “Other specs affected” is checked with ‘Y’, but referenced CRs are missing. Guess, ‘N’ should be checked. Jones: Thanks a lot for the comments. I will try to elaborate the text in draft V1. And “other specs affected” on these CRs will be fixed in draft revisions. Bruno: Other specs affected: to be unticked /Jones: Fixed 6.1.6.2.2 : - NOTE 14: "… should be accessed preferably via an SCP that belongs to … /Jones: Fixed ditto in 6.2.6.2.3 /Jones: Fixed Jones: Thanks for your comments. Please find V1 draft in /Inbox/Drafts/7.1.1. Bruno: , your revision is fine by me.
4446	CR 29.510 0383 Rel-16 Correction on attributes for SCP	Ericsson
CC1	4262	CR 29.510 0384 Rel-16 Default Subscription Binding	Ericsson	Revised to C4-204447	WI 5G_eSBA CAT F Other specs effected? Bruno: “Other specs affected” needs to be corrected on cover page. Zhijun: One principle question from my side: - The binding information can be varied in different situation. But the value stored in NRF is regarded as static and cannot be varied according to the real need Jones My understanding is that for the working entities handling default subscriptions (which sharing the similar callback URIs) can be considered like pre-created resources in the NF consumer, usually could be implemented/deployed/configured with rather stable redundancy context, that can be mapped to a stable binding information registered in NF profile. I agree that the binding information may be updated (we believe infrequently, like binding information update for already created resources) and then the NF consumer could update the binding indication in NRF accordingly. After updated, once next time a NF producer will need to deliver a default notification towards the consumer, it will fetch the updated binding information from NRF. CC Zhijun still have some doubts. Not clear in which situation this applies Jones will try to add some use cases Jones: Thanks for the comments. Please find V2 draft in /Inbox/Drafts/7.1.1. Per your request, I’ve added a table NOTE indicating the usage of the binding indication. Please check whether you have further comments. Bruno: A few editorials in v2: When present, this IE shall contain the value of the Binding Indication for the default subscription notification (i.e. the value part of "3gpp-Sbi-Binding" header), as specified in clause 6.12.4 of 3GPP TS 29.500 [4]. (see NOTE) NOTE: The binding indication for default subscription may be used by a NF service producer or an SCP to reselect an alternative NF service consumer instance, when delivering a notification for a default subscription towards a specific NF consumer but the latter it is not reachableavailable. E.g. an AMF notifies corresponding uplink LPP/NRPPa messages via default subscription, to the LMF instance who previously sent downlink LPP/NRPPa message during a location procedure, If the original LMF instance is not available, the AMF selects an alternative LMF instance using the binding indication and delivers the
4447	CR 29.510 0384 Rel-16 Default Subscription Binding	Ericsson
4263	CR 29.510 0385 Rel-16 Message and Information Class for Default Subscription	Ericsson	Revised to C4-204448	WI 5G_eSBA CAT F Other specs effected? Bruno: “Other specs affected” needs to be corrected on cover page. Jones Please find V1 draft in Inbox/Drafts/7.1.1. The only change is to untick the affect spec field.
4448	CR 29.510 0385 Rel-16 Message and Information Class for Default Subscription	Ericsson
7.1.2	CT aspects of Enhancing Topology of SMF and UPF in 5G Networks	ETSUN
4019	CR 29.244 0466 Rel-16 Interworking between ETSUN and URLLC/TSC	Huawei	Revised to C4-204345	WI Vertical_LAN, ETSUN, 5G_URLLC CAT F Jones: Small editorial, unbreakable space should be used for clause references in new text: Stage 2 requirements for the support of Ultra Reliable Low Latency Communication (URLLC) are specified in clauses 5.33 and 5.34 of 3GPP TS 23.501 [28] and also in clause[ ]4.24 of 3GPP TS 23.502 [29]. The 5GS may support Time Sensitive Communication (TSC) sessions, as specified in clauses 4.4.8, 5.27, 5.28 and 5.34 of 3GPP TS 23.501 [28] and also in clause[ ]4.24 of 3GPP TS 23.502 [29]. The related procedures between SMF and UPF are defined in this clause. Giorgi Will fix this in v1 Bruno: I don’t see the need for this CR. Stage 2 specifies that: "In this Release, how TSC (as defined in clauses 5.27 and 5.28) is supported for PDU Sessions involving an I-SMF is not specified. In this Release, Redundant User Plane Paths as defined in clause 5.33.2.2 is not supported for PDU Sessions involving an I-SMF." Adding a reference to these clauses would suggest this is supported and specified in stage 2. If this is not supported or specified, so be it, let’s not specify this either in stage 3. By the way, clause 4.24 of 23.502 is about CIoT (you meant actually 4.23) Giorgi: The purpose of this CR is to add specific references to stage 2, where it is specified which features are not specified. I know, this looks little odd. Anyway, without these specific references, e.g. URLLC developer will look into 23.501 clause 5.33 and there it will not find the statement saying Rel-16 URLLC is not supported for PDU Sessions involving an I-SMF. That’s misleading. And, yes, I meant clause 4.23 of 23.502, thanks for catching the error. . Bruno: Adding these references in stage 3 causes even more confusion IMO, as this might implicitly suggests that these procedures are supported for a PDU session with an I-SMF. Example: 5.26 Support of Time Sensitive Communications (for 5GC) 5.26.1 General The 5GS may support Time Sensitive Communication (TSC) sessions, as specified in clauses 4.4.8, 5.27, 5.28 and 5.34 of 3GPP TS 23.501 [28] and also in clause 4.24 of 3GPP TS 23.502 [29]. The related procedures between SMF and UPF are defined in this clause. while this is not supported or specified actually. So I am not keen on adding these references. You may instead add informative notes stating that "In this Release, how TSC (as defined in clauses 5.27 and 5.28) is supported for PDU Sessions involving an I-SMF is not specified. In this Release, Redundant User Plane Paths as defined in clause 5.33.2.2 is not supported for PDU Sessions involving an I-SMF." Which will be much clearer and immediate for an reader rather than having to go to a reference that would say this is not specified/supported. Giorgi I was about to suggest the same thing: adding NOTEs. Will do this in v1. Revised CR 4019_v1 in in the Drafts/7.1.2 folder.
4345	CR 29.244 0466 Rel-16 Interworking between ETSUN and URLLC/TSC	Huawei	Revised to C4-204346	Bruno Some typos: “ NOTE x: In this release of scecification URLLC is not supported for PDU Sessions involving an I-SMF. See 3GPP TS 23.501 [28] clause 5.34 and 3GPP TS 23.502 [29] clause 4.24. Redundant transmission is applied for supporting the highly reliable URLLC services, there are three different methods: dual connectivity based end to end redundant user plane paths, redundant transmission on N3/N9 interfaces or redundant transmission at transport layer. “ NOTE: How TSC is supported for PDU Sessions involving an I-SMF is not specified in this release of scecification. See 3GPP TS 23.501 [28] clause 5.34 and 3GPP TS 23.502 [29] clause 4.24. Besides, the first note above is not fully correct. This is not supported for redundant transmission on N3/N9, but can be supported for other methods if I remember well. Please check SA2 response / stage 2. Giorgi: Thanks, done in the revised CR in 4436, which is in the Inbox
4346	CR 29.244 0466 Rel-16 Interworking between ETSUN and URLLC/TSC	Huawei
4020	CR 29.244 0467 Rel-17 Interworking between ETSUN and URLLC/TSC	Huawei	withdrawn	WI Vertical_LAN, ETSUN, 5G_URLLC CAT A
4106	CR 29.518 0378 Rel-16 Clarification on hSmfId in PduSessionContext transferred to target AMF	ZTE	Revised to C4-204364	WI ETSUN CAT F Jones Some comments with texts in red: This IE shall be present for non-roaming and home-routed PDU sessions. (is this condition still valid? Looks like this IE shall be present for any PDU session now…) When present, it shall indicate the associated : - home SMF, for HR PDU Session, or - SMF, for non-roaming PDU session, or LBO PDU Session, or PDU session with I-SMF.(This is not needed. I-SMF involved or not is regardless here.) This IE shall be present, if available. When present, this IE shall contain the NF Set ID of the home SMF or SMF indicated by hsmfId IE. This IE shall be present, if available. When present, this IE shall contain the NF Service Set ID of the home SMF'ss selected PDUSession service instance in the home SMF or SMF indicated by hsmfId IE. This IE shall be present if available, for a non-roaming PDU session or LBO PDU Session. When present, this IE shall contain the SBI binding level of the SMF's SM context resource. Zhijun Thanks for your good comments. I will take them into account. For the changes to "hsmfId", it looks that PDU session with I-SMF is already covered by the following: HR PDU session, non-roaming PDU session, roaming with LBO PDU session. As in most cases, when we talk about the PDU sessions, we normally pick out the PDU session with I-SMF as an important scenario and describe it explicitly. So would you mind I take the following description: When present, it shall indicate the associated : - home SMF, for HR PDU Session, or - SMF, for non-roaming PDU session or LBO PDU Session, regardless whether I-SMF is involved or not. Jones I am fine with the suggest text above Giorgi: There is already an attribute indicating the use case: ismfId NfInstanceId C 0..1 This IE shall be present if I-SMF is involved in the PDU session. When present, it shall indicate the associated I-SMF for the PDU Session. DTSSA I remember CT4 decided to add explicit I-SMF specific attributes to tell them apart from the ordinary roaming. So, I believe this CR is not needed Zhijun: Yes, ismfId is there to carry the I-SMF ID. The problem is not able to carry the I-SMF ID, but not able to carry the A-SMF ID when I-SMF is involved, as the exiting description (hSmfId) is only used to carry H-SMF ID. Giorgi: Now it’s clear to me. Zhijun I uploaded v1 to the server, incorporating Jones' comments. https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.2/C4-204106_v1_ETSUN_29518_hSmfId%20in%20PduSessionContext.docx Jones: The revision is fine by me
4364	CR 29.518 0378 Rel-16 Clarification on hSmfId in PduSessionContext transferred to target AMF	ZTE	Bruno: hsmfId : you propose to strike the reqt that “this shall be present for … “ , which looks weird; with your CR, this IE becomes no longer required (“when present, …”). Zhijun: Thanks for the comments. Jones proposes to strike that requirement "this shall be present for .." due to it originally only target HR PDU sessions. Now it looks anyway the hsmfId will alreadys be included. However, the existing IE is marked as Conditional. Should we change the C to M, or just let's say: "It shall be present, if available"? It looks not a very good idea to change it from C to M. Jones: Yes, the original comments is from me, as it seems this IE should be included for any kind of PDU sessions now. We can either add “LBO PDU session” into original text; or we can say as you said “This IE shall be present if available”. I am OK for both ways. Or you can propose other ways as well. Bruno: The Rel-15 condition is as follows, the condition should not be changed. Adding “if available” suggests that it could now not always be present for a non-roaming or HR PDU session. hsmfId: This IE shall be present for non-roaming and home-routed PDU sessions. When present, it shall indicate the associated home SMF for the PDU Session I recommend to add the statement that “This IE should also be present for LBO PDU sessions. When present, …” Are there use cases where the information wouldn’t be available? /Jones: with adding the LBO PDU session now, I didn’t see any use cases that this IE will not be available… That is actually my original motivation trying to remove the condition as it is now looks like mandatory. Jones I am fine with your suggested change. Zhijun: Actually it now covers all cases. As we should change the Conditional, lets' adopt your statesment “This IE should also be present for LBO...”
4107	CR 29.502 0367 Rel-16 Correct the Condition of upCnxState in SmContextCreateData	ZTE	Revised to C4-204365	WI ETSUN CAT F Bruno; The changes you do in clause 6.1.6.2.2 apply for a registration procedure only if the UE requested to activate the PDU session. This condition should be stated in the description of the attribute. Zhijun: Thanks for the comments. I will reflect it in v1 update later. Please find v1 revision from the server. Comments from Bruno are incorporated. https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.2/C4-204107_v1_ETSUN_29502_upCnxState.docx
4365	CR 29.502 0367 Rel-16 Correct the Condition of upCnxState in SmContextCreateData	ZTE	Bruno Thanks. there is a typo in the revision - during Regisration procedure with an I-SMF insertion / change / removal, or with a V-SMF change (see clause 5.2.2.2.7), if this PDU session is requested to be activated by the UE. Also why does this exclude V-SMF insertion / removal? See e.g. 29.502: 5.2.2.2 Create SM Context service operation 5.2.2.2.1 General - Registration procedure for a UE with a PDU session with I-SMF or V-SMF insertion, change and removal (see clause 4.23.3 of 3GPP TS 23.502 [3]); Zhijun: Thanks for spotting this, I will correct them. It should be with a V-SMF insertion / change / removal, it is just due to copy from the first bullet but forgot to update it.
4158	CR 29.244 0475 Rel-16 End marker handling in service request procedure	Huawei	Revised to C4-204386	WI ETSUN CAT F Bruno: 5.2.3.1: “In 5GC, if the UP function receives an end marker packet as the first downlink packet, the UP function shall not notify the CP function and shall discard the end marker packet(s) silently” Bruno> the receipt of end marker packets do never result in generating a Data Notification Report to the CP function. I don’t think this change is necessary, or if we keep it, it shall not be specific to 5GC. Caixia: Would it be OK if I remove the in 5GC, and keep the sentence to avoid the incorrect implementation? Bruno: Yes, this is fine by me. Caixia: Draft V1 is available in inbox of [7.1.2] with the change to remove the in 5GC. Frank I have some problem with change in 5.2.3.1, as I commented earlier, I prefer to add a note instead of normative requirement, e.g. : The end marker packet is not considered as Downlink Data packets so that it doesn't trigger the UP function to notify the CP function. The UP function can discard the received end marker packet(s) silently when it is not possible to be forwarded. The point is that End marker is not part of user plane data, thus it is not eligible to trigger sending a DL data report. And we have already introduced a function as documented in 5.2.2.5End Marker Reception Reporting, i.e. receiving End Mark can trigger UP to notify the CP Caixia: Change to informative NOTE is fine for me, please check the revision in V2 https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.2/C4-204158_V2_ETSUN%2029.244-End%20Marker.docx Frank, Bruno It is fine
4386	CR 29.244 0475 Rel-16 End marker handling in service request procedure	Huawei
4159	CR 29.502 0368 Rel-16 PDU session deactivation	Huawei	Revised to C4-204387	WI ETSUN CAT F Jones In the reason for change, rejection of PDU session establishment is clear to me. For mobility, SMF trigger the PDU session release involving an I-SMF is not clear to me on the SMF behavior, e.g.: Shall the SMF accept the I-SMF insertion first, then trigger the PDU session release via N16a with new clause? or Shall the SMF reject the I-SMF insertion directly the new application error, the subsequently release the PDU session directly via N11 with new cause? Some clarifications like above should be helpful in clause 5.2.2.7.1 for SMF handling. “INTERWORK_WITH_ISMF_FAILURE” may be rephrase to “INTERWORK_WITH_ISMF_NOT_ALLOWED”? Is this also applied to V-SMF insertion? Caixia: Thank you for your comments. For mobility procedure, the requirement from stage 2 is defined as below: In TS 23.502 if the UE moves out of SMF Service Area, the SMF may, based on local policy, release the PDU Session after the mobility procedure. This applies to following procedures: Registration procedure, Service Request procedure, Xn based handover procedure, N2 based handover procedure. SMF accepts the I-SMF insertion firstly, and trigger the release after mobility procedure. I will add some description in clause 5.2.2.7.1. The contribution also apply the V-SMF insertion, for the cause name, I am fine with your proposal. Bruno: The cause could alternatively be rephrased to "NOT_SUPPORTED_WITH_ISMF". And in Table 6.1.6.3.8-1, the description could read: "PDU session release due to a requested functionality that is not supported for a PDU session with an I-SMF/V-SMF." Caixia: I will include the changes. Please check the draft v1 in inbox with the following changes: Update the error or cause name; Add description to clause 5.2.2.7.1. Bruno: Thanks. Small edits 5.2.2.7.1 General For UE mobility with I-SMF/V-SMF insertion procedure, if a requested functionality that is not supported for a PDU session with an I-SMF/V-SMF, the SMF shall accept the POST request and release the PDU Session after the mobility procedure, as specified in clause 4.23.1 of 3GPP TS 23.502 [3]. - a ProblemDetails structure with the "cause" attribute set to one of the application error listed in Table 6.1.3.5.3.1-3. The application error is set to "NOT_SUPPORTED_WITH_ISMF" during a UE requested PDU Session Establishment, if a requested functionality that is not supported for a PDU session with an I-SMF/V-SMF. Caixia: Thank you, I correct the typos in draft v2: https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.2/C4-204159_V2_ETSUN%2029.502-PDU%20session%20deactivation.docx
4387	CR 29.502 0368 Rel-16 PDU session deactivation	Huawei
CC2	4194	CR 29.502 0373 Rel-16 Error handling for PDU sessions with an I-SMF or V-SMF	Nokia, Nokia Shanghai Bell	Revised to C4-204463	WI ETSUN, TEI16 CAT F Frank: I don’t think the “I-SMF/V-SMF” is just relaying the HTTP request/response, it handles the request (related to SmContext) from AMF and send another requests (PDUSession) to A-SMF/H-SMF. So, I also don’t think to use the “Via” or "Server" header is a good way for this case; these headers are used a HTTP proxy, which transparently relay the message. Considering the approach in GTPv2, the Cause IE itself indicates the source making the rejection (SGW or PGW). We can do similar, to define a new cause or modify problemDetail to indicate cause is from the hSmf/smf. Yue: I agree with Frank that I/V-SMF are not simply relaying the HTTP error responses. The story is AMF invokes service provided by I/V-SMF, and this triggers the I/V-SMF invoking service provided by SMF. The error response returned by SMF will be fully terminated at I/V-SMF, then based on that error the I/V-SMF generates a new error response towards AMF. Bruno: Thanks for your comments. I understand your point, but still when the H-SMF/SMF sends e.g. the following errors, I expect the V/I-SMF to do the same towards the AMF (unless the V/I-SMF can select an alternative H-SMF/SMF). Examples: An 500 Internal Server Error with the cause INSUFFICIENT_RESOURCES, SYSTEM_FAILURE, NF_FAILOVER, NF_SERVICE_FAILOVER or NF_CONGESTION But I am fine with extending the ProblemDetails structure with a new attribute indicating whether the error is originated by a remote node (i.e. H-SMF/SMF) or by the node sending the response (i.e. V/I-SMF). If this is agreeable to all, I am going to submit a new 29.571 CR extending the ProblemDetails structure with a new attribute that allows to indicate that the error was originated by a remote entity. And I will revise the 29.502 CR to require the use of this new attribute (no OpenAPI change). Note: the alternative to extend the ProblemDetails in 29.502 and not in 29.571 (following the guidelines in clause 4.8.3 Extending ProblemDetails for API Backward Compatibility of 29.501) would require to change the data types of all the attributes defined as ProblemDetails in the “XXXError” data types in 29.502 (e.g. SmContextCreateError) but also to redefine all the errors in the OpenAPI file (e.g; as those copied below) to no longer refer to the error definitions in 29.571 but to new error definitions in 29.502 using the extended ProblemDetails. So extensive changes. type: string '411': $ref: 'TS29571_CommonData.yaml#/components/responses/411' '413': $ref: 'TS29571_CommonData.yaml#/components/responses/413' '415': $ref: 'TS29571_CommonData.yaml#/components/responses/415' '429': $ref: 'TS29571_CommonData.yaml#/components/responses/429' Please let me know if this approach is fine. Giorgi: During PDU session establishment, PCF may also be the source of the rejection. We believe a common mechanism defined in clause 6.10.8 in TS 29.500 should be used, or enhanced if necessary. With such approach, we won’t need changes similar to those in this CR to be applied to other APIs. Bruno: the current 29.502 CR relies on similar principles as defined in clause 6.10.8 of 29.500, but Frank and Yue suggest to use a different approach (new property in ProblemDetails) similar to what we have in the Cause IE in GTP-C. So I plan to update contributions accordingly. I assume that reporting to the AMF that the error was caused at the H-SMF/SMF is sufficient, like we do in GTP-C, i.e. that we don’t need to indicate that this was an error generated e.g. by the PCF. So we only need to apply the mechanism between the AMF, V-SMF and H-SMF, and this will be further described in 29.502, with the new ProblemDetails property in 29.571 telling that this is an error originated by the remote node. Please let me know if you have any pb with this approach. CC Bruno raised the question if everybody is fine with the approach: Alternative define new attribute in problem details. Proposed to define this as common parameter not limited to SMF (29.502) means change/enhancement to 29.571. Jesus this would effect all APIs. Question is it useful to signal in all APIs that an error is generated by a different source than the source who sends the error. Yue can we use a specific error cause. Frank: Should we indicate the entity in the new parameter? Bruno. Is not my intention. Frank in this case may be preferred to limit the extension to SMF. We will continue discussing the topic limited to SMF. Bruno: I have uploaded V1 in the draft inbox incorporating your comments. https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.2/C4-204194_v1_29502_Rel16_Error%20handling%20for%20PDU%20sessions%20with%20I-SMF%20or%20V-SMF.docx
4463	CR 29.502 0373 Rel-16 Error handling for PDU sessions with an I-SMF or V-SMF	Nokia, Nokia Shanghai Bell
4195	CR 29.500 0155 Rel-16 Error handling for PDU sessions with an I-SMF or V-SMF	Nokia, Nokia Shanghai Bell	Withdrawn	WI ETSUN, TEI16 CAT F Bruno: C4-204195 is withdrawn (considering we have chosen a different approach based on extending ProblemDetails)
4239	CR 29.244 0482 Rel-16 Correcting the example of addition of PSA2 and UL CL controlled by I-SMF	Nokia, Nokia Shanghai Bell	Agreed	WI ETSUN CAT F
CC4	4257	CR 29.502 0376 Rel-16 QosRules during I-SMF and V-SMF Insertion	Ericsson	Revised to C4-204444	WI ETSUN CAT F Other specs effected? Bruno: The cover page (other specs affected) needs to be corrected. Giorgi: Please refresh my mind by pointing to stage 2 statement that supports this on the cover page: “during I-SMF/V-SMF insertion during UE idle mobility, the Nsmf_PduSession_Create operation is used by I-SMF/V-SMF to create N16/N16a association to the (H-)SMF. During these procedures, there is no QosRules N1 info to be sent to the UE”. Also, WIC reads TEI16, but the CR is on the ETSUN agenda. Jones: Please refer to 4.23.3 of TS 23.502 Registration procedure with I-SMF insertion, the I-SMF invoke Nsmf_PduSession_Create on SMF to establish the N16a interface. If no PDU session is to be activated for the registration, No N1/N2 information will not be provided by SMF to AMF and the only N1 message to be returned to the UE is Registration Accept managed by AMF. Also for Service request procedure with I-SMF insertion, 4.23.4.3 of 23.502, step 8c only Tunnel Info is potentially included: 8c. The SMF responds to the new I-SMF with Nsmf_PDUSession_Update Response (the DNAI(s) of interest for this PDU Session in the case of I-SMF change) or Nsmf_PDUSession_Create Response (the DNAI(s) of interest for this PDU Session, Tunnel Info at UPF(PSA) for UL data in the case of I-SMF insertion if it is allocated in step 8b). In these procedures, if the PCF detects PCC changes due to e.g. UE location change, it will be handled via an explicitly V-SMF Update procedure to change the QoS settings to the UE/RAN. This CR does related to ETSUN in my view, I can update it to TEI16, ETSUN. Giorgi For complete clarity, which of the below is the actual reason for change: SMF does not have any valid value to populate qosRules attribute I-SMF does not need to send QoS rules to the UE If the second one (2) is the reason, then we cannot agree the CR, because in this case a trivial solution would be that I-SMF simply discards the QoS rules. Jones: The reason for not providing QosRules in these stage 2 procedures is closer to bullet 1, i.e. the (H-)SMF does not have any QoS update to be exchanged with the UE during the PDU Session Create step. It is not that the I-SMF decided to not forward the QosRules. Instead, if the I-SMF received QoS Rules from the SMF, the I-SMF should act and forward the QosRules accordingly. Hope this clarify the reasoning. Giorgi: So, (H-)SMF does have QosRules, but the SMF does not have a need to update UE on QosRules. For this use case, I would argue it should be an I-SMF decision not to send the QosRules to the UE. We could clarify this in the revised CR. Jones: Actually the (H-)SMF mains the PCC rules, and derives the QosRules/updated QosRules when need to exchange with UE. If SMF knows there is nothing to be exchanged, why bother derived the existing QoS and send to the I-SMF? On the other hand, I-SMF doesn’t keep the QosRules thus I-SMF cannot identify the received QosRules from SMF is an real update or just the existing one already exchanged with UE. By 3GPP design, PCC Rules are managed by SMF and it should the more proper node to make the decision whether to send to UE or not, instead of by I-SMF. Bruno: I fully agree with Jones. Caixia: I-SMF can just ignore the IE, if it is received during mobility with the V-SMF/I-SMF insertion procedure. PduSessionCreatedData is designed for the PDU session establishment procedure, there are several IEs may related to the UE, like the sessionAmbr. Currently, based on NOTE2, I-SMF overwrite the IEs received earlier and will not trigger the message to RAN or UE. For the QoSRules, I propose to also add a Table NOTE to indicate in scenarios with a V-SMF/I-SMF insertion, the I-SMF/V-SMF just ignore this IE. Jones: Could you please clarify what is the benefits for SMF to pass the QosRules when it exactly knows the QosRules is not changed and is not needed to exchange to the UE? The information returned by SMF to I-SMF is useful for I-SMF to configure the UPF or to store it for late use (like the Session AMBR for future UP activation), thus the SMF should return the latest information to the I-SMF, but not the QosRules here. Caixia: Is it the backward compatible change? According to the current definition, the SMF will return the non-null QoSRules to the I-SMF. /Jones: For OpenAPI perspective, it is backward compatible. The QosRules IE is not “null” but empty string which is allowed (see the QosRules in the SmContext). From application logic perspective, are you suggesting that the I-SMF will explicitly inspect the content of QosRules while it will be ignored? I don’t see it is necessary thus should not break backward compatibility. Caixia: It is backward incompatible change for SMF, shall send the empty string to I-SMF based on the contribution, but currently there is no such restriction. And for the session AMBR, actually the I-SMF already retrieves from the SMF during SM Context, but it is still allowed to send the session AMBR from SMF again in PduSessionCreatedData. So I do not see the problem to send the non-null QoSRules to I-SMF, I-SMF can simply ignore the Information. /Jones: This is exactly the difference. The AMBR is needed and managed in I-SMF this is why it is received from the SmContext (QosRules are set to empty string in SmContext, in opposite). Caixia: For PduSessionCreatedData, it is similar, the parameter may no need to send to I-SMF. Session AMBR, I-SMF already has this information. QoSRules, I-SMF does not need this information. But we allow the SMF to send session AMBR to I-SMF again, why the QoSRules cannot be allowed. At least I see the benefit here: For I-SMF, the difference is receiving empty string or real value string, and discard the IE. But for SMF, it is simple, no need to distinguish the procedure, just send the real value string same as in PDU session establishment or UE mobility with I-SMF insertion procedure. We should not require the SMF to provide the un-updated QosRules (which are not expected to be exchanged to UE) to the I-SMF, which should be fixed when it is not too late for a Rel-16 feature Caixia: To be honest, it is already late change for Rel-16 feature, ETSUN feature is completed earlier than other features. If you really want this change, the only way I can accept is not mandate to send empty string from SMF, non-empty string is also allowed. If as you indicated the I-SMF will not inspect the content of QosRules while it will be ignored, the proposal will not impact the I-SMF and the SMF. Jones: Even though I didn’t agree your interpretation on the backward compatibility, but anyway we can find some way to move forward. How about I change the shall to may in the new text? “The qosRules attribute of the QosFlowSetupItem may be set to an empty string, if there is no Qos Rule(s) associated to the Qos flow to be sent to the UE, e.g. during I-SMF or V-SMF insertion in UE mobility procedures.” Giorgi Great idea, thanks. Below is a draft wording, which should make things crystal clear: If the Qos Rule(s) associated to the Qos flow have not changed, e.g. during UE mobility with I-SMF insertion, then the Qos Rule(s) shall not be sent to the UE. In this case, depending on the implementation the H-SMF/SMF may send the latest Qos Rule(s) to the SMF/I-SMF, or may send an empty sting with the qosRules attribute in the QosFlowSetupItem. The wording may look too long, but IMHO it completely eliminates ambiguity. We need to explain that (a) in the said scenario I-SMF shall not be sent Qos Rule(s) to the UE and (b) that I-SMF shall expect either latest Qos Rule(s) or an empty string. What you reckon? Jones: Please find updated V2 draft in ‘/Inbox/Drafts/7.1.2/C4-204257_v2_CR0376_29502_QosRules%20during%20I-SMF%20and%20V-SMF%20Insertion.docx” Update the new text capturing the proposal from Giorgi Update WIC with ETSUN Untick the affected Spec field Giorgi: Please correct the typo ‘sting’ to ‘string’  Bruno: But how does the I-SMF/V-SMF know whether the received QoS rules have changed or not (if they are received from the H-SMF/SMF), i.e. whether it shall send the QoS rules to the UE e.g. during a handover with I-SMF insertion or even idle mode mobility? PCF could trigger a change of QoS e.g; because a new service is requested at the same time as the mobility scenario Jones: I fully agree. This is also my thought thus proposed the CR as in the original revision “-“. The revision to allow both alternatives is to find a way to move forward, at least towards the right direction. Recapture here the objection opinion from Huawei mainly from backward compatibility consideration: “It is backward incompatible change for SMF, shall send the empty string to I-SMF based on the contribution, but currently there is no such restriction. Caixia: To be honest, it is already late change for Rel-16 feature, ETSUN feature is completed earlier than other features. If you really want this change, the only way I can accept is not mandate to send empty string from SMF, non-empty string is also allowed. If as you indicated the I-SMF will not inspect the content of QosRules while it will be ignored, the proposal will not impact the I-SMF and the SMF.” We could discuss it at conference meeting trying to reach an agreement. Giorgi: I thought we reached the deal. Ok, our objection is based on the fact that there are ways around the problem that already work and we don’t see a need for changing protocol. We however decided to compromise for reaching consensus and saving the meeting time for other, equally important matters. Concerning Bruno’s question, if PCF triggers the QoSRules update, then the SMF shall initiate the update to I-SMF, which is different from the procedure in question. Bruno: The latest draft CR speaks about V-/I-SMF determining whether the QoS rules have changed, and based on that, ignore or not the received QoS rules. V-/I-SMF cannot do so. So now you come with an alternative proposal precluding the anchor SMF to change the QoS rules during the mobility scenarios with I-SMF insertion. This needs to be carefully checked IMO if this is acceptable or not. Giorgi: My understanding of stage 2 is this: During the UE mobility with I-SMF insertion, I-SMF assumes the rules have not changed and therefore it does not send the rules to the UE. If PCF triggers the rules update, then the SMF initiates another procedure, an update procedure. So, I-SMF will know it needs to sends the rules to the UE. CC Caixia: Qos rule update procedure should be take into account. Jones will do a revision Jones: Thanks for the swift discussion. Please find V3 draft of the CR: ftp://ftp.3gpp.org/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.2/C4-204257_v3_CR0376_29502_QosRules%20during%20I-SMF%20and%20V-SMF%20Insertion.docx Please check whether the changes are aligned with what we agreed during the meeting. Giorgi: Sounds good to me. Bruno: the style of the text is not correct (check w/o change marks). More importantly, this text is too loosely defined IMO. You use an “e.g.” for the H-SMF/SMF , so how does V-SMF/I-SMF know when it shall ignore or not this IE. We need to specify explicitly in which exact scenarios all this text applies, so that there is no ambiguity both on the anchor SMF side and intermediate SMF side on how to behave. And we had also agreed to capture that the anchor SMF shall not change the QoS flows in the CreatedData in these scenarios. This IE shall be present, except when Control Plane CIoT 5GS Optimisation is enabled for the PDU session. When present, this IE shall contain the full set of QoS flow(s) to establish for the PDU session. It shall contain at least the Qos flow associated to the default Qos rule. If the Qos Rule(s) associated to the Qos flow have not changed thus shall not be sent to the UE, e.g. during UE mobility procedures with I-SMF/V-SMF insertion, the qosRules attribute in the QosFlowSetupItem may be set to the latest Qos Rule(s) associated to the Qos flow or set to an empty string, and the I-SMF/V-SMF shall ignore the Qos Rule(s) received in qosRules attribute in the QosFlowSetupItem. Jones: Thanks for the comments. Please find V4 draft in /Inbox/Drafts/7.1.2. Please check whether all your concerns are addressed.
4444	CR 29.502 0376 Rel-16 QosRules during I-SMF and V-SMF Insertion	Ericsson
4316	CR 29.502 0378 Rel-16 SMF sending IPv6 Interface Identifier to I-SMF	Huawei	Revised to C4-204332	WI ETSUN CAT F
CC2	4332	CR 29.502 0378 Rel-16 SMF sending IPv6 Interface Identifier to I-SMF	Huawei	Revised to C4-204343	WI ETSUN CAT F Jones: The comments of Ipv6Addr common data type could be more general like “IPv6 Address”. There is no need to explicitly indicate all the usages, e.g. maybe it will be used by other attributes later (Same comments to the Rel-15 CR 0379/C4-204333) Ipv6Addr 3GPP TS 29.571 [13] In this specification this data type is used for IPv6 Interface Identifier attribute (ueIpv6InterfaceId). ueIpv6InterfaceId attribute in PduSessionCreatedData shall incorporate the description of the Rel-15 CR, and remove the applicability to DTSSA. Zhijun: I propose more description on which information is included when the IE is present, in addition to Jones's comment. This IE shall be present if the SMF has assigned IPv6 interface identifier to the UE during the PDU session activation. When present, it shall carry ...... Giorgi: Thanks for the comments, will include them in v1. Just want to highlight that Rel-15 CR in 4334 is not mirroring this one. Bruno: Can you please explain the following text in the reason for change and CoNA and how this relates to the UE IPv6 interface identifier used for LL address (the interface identifier is used during the PDU session establishment, so which scenario do you consider here?): “During interworking with 4G, an MME needs to send a complete UE IPv6 address to an AMF over N26 interface. AMF gets from I-SMF a UE IPv6 address with SmContext (see 3GPP TS 23.502 clause 4.11.1).” Consequences if not approved: When I-SMF is inserted, a PDU session establishment procedure and interworking with 4G may not work. Why do we need this information in the SmContext? For which usage? Why do you propose to encode the UE IP interface identifier (64 bits) as a UE IP address (128 bits) and not as 8 octets (this is defined as 8 octets in 24.501 clause 9.11.4.10)? So why not the following Pattern: "^[A-Fa-f0-9]{8}$" ? Why also is it specific to an PDU session with an I-SMF and applicable only to DTSSA, when it actually applies from Rel-15 onwards for HR PDU sessions too ? so where is the mirror part of your new Rel-15 CR? ueIpv6InterfaceId Ipv6Addr C 0..1 This IE shall be present if I-SMF is inserted and if the SMF has assigned IPv6 interface identifier to the UE during the PDU session activation. DTSSA The WI code should also include TEI16, 5GS_Ph1-CT (to reflect this also apply beyond ETSUN). CR title should also not hint this is for I-SMF only. CoNA should also not be specific to ETSUN. Other comments: we shall say either “correction” or “new feature”, not “changes”, since OpenAPI versioning differs depending on whether this is the “correction” or “new feature”. Other comments: This CR adds backward compatible changes to OpenAPI. CC Bruno this CR should mirror all changes form the Rel-15 CR in C4-204333 which is not the case. Giorgi: In today’s telco we agreed on the new string pattern being fixed to 64 bits. I’ll implement that. I also agree that the change is not specific to DTSSA. Now, concerning the change to SmContext. Currently, SmContext type contains only ueIpv6Prefix attribute, i.e. it does not contain any attribute that can store a full IPv6 address. For interworking with 4G, we believe that a full UE IPv6 address shall be sent over N26 interface. Below are few quotes from 23.502 to support this assumption. Clause 4.11.1.1 General reads: “Interworking between EPS and 5GS is supported with IP address preservation by assuming SSC mode 1”. Clause 4.11.1.2.1 5GS to EPS handover using N26 interface: Step 2a: “The AMF determines for a PDU Session whether to retrieve context including mapped UE EPS PDN Connection from the V-SMF (in the case of HR roaming) or the PGW-C+SMF”. Step 2c: “When Nsmf_PDUSession_Context Request is received in the V-SMF or the PGW-C+SMF, the V-SMF or the PGW-C+SMF provides context that includes the mapped EPS PDN Connection”. So, the SMF sends SmContextRetrievedData type, which contains SmContext type. Step 3: “The AMF sends a Forward Relocation Request” to the MME. We believe this contains full UE IPv6 address, because in EPS, the source MME receives the full IPv6 address from PGW and send the full IPv6 address to target MME. Therefore, in order to send full UE IPv6 address to the MME in the above step 3, the AMF needs to get this from the SMF in step 2c. For this to happen, the SMF needs to store the full IPv6 address in the SmContext. There are two ways for doing this for SmContext: either by adding IPv6 suffix, or adding full IPv6 address. Hope, this clarifies the reason for adding the missing Iv6 suffix to the SmContext type in the CR. Bruno: Your CR addresses the IPv6 interface identifier that is assigned to the UE for the link local address (used only between the UE and PSA). The IPv6 address exchanged during inter MME/AMF mobility is the (routable/SGi/N6) UE IP address assigned to the PDU session. When using Stateless IPv6 Address Autoconfiguration, the SMF actually only assigns the IPv6 prefix and the UE builds on its own its full IPv6 address. So the SMF cannot provide the IPv6 interface identifier of this address. See 23.501 5.8.2.2.3 The procedure of Stateless IPv6 Address Autoconfiguration If Stateless IPv6 Address Autoconfiguration is used for IPv6 address allocation to the UE, after PDU Session Establishment the UE may send a Router Solicitation message to the SMF to solicit a Router Advertisement message. The SMF sends a Router Advertisement message (solicited or unsolicited) to the UE. The Router Advertisement messages shall contain the IPv6 prefix. After the UE has received the Router Advertisement message, it constructs a full IPv6 address via IPv6 Stateless Address Autoconfiguration in accordance with RFC 4862 [10]. To ensure that the link-local address generated by the UE does not collide with the link-local address of the UPF and the SMF, the SMF shall provide an interface identifier (see RFC 4862 [10]) to the UE and the UE shall use this interface identifier to configure its link-local address. For Stateless Address Autoconfiguration however, the UE can choose any interface identifier to generate IPv6 addresses, other than link-local, without involving the network. … So I don’t understand your comments and which exact use case you discuss (and how this relates to the interface identifier used for the link local address). Giorgi: The Rel-16 CR in 4332 addresses two separate use cases. The first one addresses, as you pointed out a PDU session establishment with IPv6 autoconfiguration. This is also the scope of the Rel-15 CR in 4333. The other use case is about 5GS to EPS handover using N26 interface. Here, AMF shall act the same way as source MME acts in EPC when sending Forward Relocation Request to the target MME. GTPv2 spec defines that MME/SGSN/AMF UE EPS PDN Connections IE contains UE IPv6 Address, which is a complete IPv6 address (see clause 8.9). Question, how can AMF fill the suffix part if it will receive from the SMF only a prefix with SmContext?
4343	CR 29.502 0378 Rel-16 SMF sending IPv6 Interface Identifier to I-SMF	Huawei	Revised to C4-204427	Bruno: We should not mix the Rel-15/16 CRs enabling the anchor SMF to return the IPv6 interface identifier for Link Local address, and the other discussion on 4G-5G mobility. I still don’t understand what is the issue with the latter (in light of my earlier explanations further down). An AMF that got an IPv6 prefix can set an IPv6 address over N16 by setting e.g. the interface identifier to all zeros (the SMF has anyway NO clue on the exact interface identifier the UE selects for this prefix). So I don’t agree either on the extension proposed in the SmContext. Other comment: ueIpv6InterfaceId: This IE shall be present if the H-SMF/SMF has assigned IPv6 interface identifier to the UE during the PDU session establishment for a Home-routed Roaming or for a PDU session with an I-SMF when an I-SMF is inserted. When present, it shall encodes the UE IPv6 Interface Identifier to be used by the UE for its link local address with 8 hex digits. Pattern: "^[A-Fa-f0-9]{8}$" Giorgi: Ok, I reserved new tdoc/CR number for Rel-16 mirror of the Rel-15 CR in 4342. Rel-16 mirror CR number is 4426. I will soon upload 4426 into Inbox. Back to this CR in 4343. I will revise it to focus specifically on 4G-5G mobility, which will also be explained in the reason for change. It is true that IPv6 address/prefix is primarily allocated via stateless autoconfiguration, but there are also other methods available like DHCPv6 or some other external IPv6 address source. This CR addresses such cases. So, the SMF may get a complete IPv6 address with meaningful suffix via these other methods, like PGW did in EPC. So, I don’t think populating suffix with 0’s would work. Would you agree? Bruno: Here is what we have in 29.244: 5.21 UE IP address/prefix Allocation and Release 5.21.1 General Stage 2 requirements for UE IP address allocation in the EPC and 5GC are specified in clause 5.8.2.2 of 3GPP TS 23.501 [28] and clause 4.6.2 of 3GPP TS 23.316 [57]. The following types of UE IP addresses may be assigned over N4 or Sxb: - IPv4 address; - /64 IPv6 Prefix; - IPv6 prefix other than default /64, including individual /128 IPv6 address, if the UPF indicates supports of the IP6PL feature (see clause 8.2.25), for IPv6 address allocation using DHCPv6 specified in clause 4.6.2.2 of 3GPP TS 23.316 [57]; - IPv6 prefix shorter than the default /64 prefix for support of IPv6 prefix delegation as specified in clause 4.6.2.3 of 3GPP TS 23.316 [57] and clause 5.14. An IPv6 prefix can also indicate an individual /128 IP address. So which use case do you assume for your CR? In which case cannot the @ be expressed as a prefix? Also if there was any pb (which I still don’t see), why do you suggest to extend the SmContext, that e.g; would not allow the V/I-SMF to get the info during e.g. a PDU session with I-SMF insertion? Giorgi: I added 4427 to the subject line to inform the group 4343 is revised to 4427, which is in The Inbox. Thanks for highlighting the quote, but that’s coming from 29.244. I’m not sure 29.502 permits conveying individual /128 IPv6 address within ueIpv6Prefix attribute. Quote from 29.502: ueIpv6Prefix Ipv6Prefix C 0..1 This IE shall be present if a UE IPv6 prefix to the PDU session. I’d be fine adding clarification that an individual /128 IPv6 address may also be carried by ueIpv6Prefix attribute. To be honest, I don’t have strong opinion on which way to go, but I believe it would be a cleaner solution to keep the proposed ueIpv6InterfaceId attribute. Let’s discuss this shortly in today’s telco to hear other opinions. CC Bruno we should not mix discussion We already have the IPV6 prefix What is the real issue it is confusing. Giorgi; has split the CR this CR is just for mobility. Frank about which IE in 29.274 do you talk about. Bruno: wants to know the stage 2 reference for the requirement. Giorgi: does this /128 fits to the prefix pattern definition in 29.571. Jesus: the pattern support /128 Giorgi will analyse the problem and will try to clarify the issue taking into account that IPv6 prefix defined in 29.571 supports /128. Split out part is covered in 4342 4433
CC6	4427	CR 29.502 0378 Rel-16 SMF sending IPv6 Interface Identifier to I-SMF	Huawei	Giorgi: In today’s telco we discussed the CR in 4427 that proposes storing a complete, routable IPv6 address in SmContext structure. Jesus has kindly checked that Ipv6Prefix type in 29.571 permits attributes of this type to contain a complete, 128 bits long IPv6 address with meaningful suffix. Therefore, ‘ueIpv6Prefix’ attribute can convey 128 bits of IPv6 address and the proposed new attribute ‘ueIpv6InterfaceId’ is not necessary anymore. Back to the reason for change, i.e. the justification of the use case that the CR is addressing. During 5GS to EPS handover using N26 interface, the source AMF shall act the same way as source MME acts in EPC when sending Forward Relocation Request to the target MME. Let’s examine GTPv2 spec on what kind of UE IPv6 address (only prefix or prefix+suffix) the source MME sends to the target MME in EPC. Below are quotes from 29.274: Table 7.3.1-1: Information Elements in a Forward Relocation Request. The message contains “MME/SGSN/AMF UE EPS PDN Connections” IE. Table 7.3.1-2: MME/SGSN/AMF UE EPS PDN Connections within Forward Relocation Request. The type contains “IPv6 Address” IE of type “IP Address”. Clause 8.9 IP Address reads: “IP Address is coded as depicted in Figure 8.9-1. The Length field may have only two values (4 or 16) that determine if the Value field contains IPv4 or IPv6 address”. Therefore, “IPv6 Address” IE in the above Table 7.3.1-2 must contain all 128 bits. Now, MME gets UE IPv6 address from PGW with CSResp: Table 7.2.2-1: Information Elements in a Create Session Response. The message contains “PDN Address Allocation” (PAA) IE. PAA IE presence condition reads: “When assigning an IPv6 address the PGW shall send a non-zero Interface Identifier. See NOTE 8”. NOTE 8 reads: “The Interface Identifier value of zero is a reserved value (see IETF RFC 5453 [58]). Clause 5.3.1.2.2 of 3GPP TS 23.401 [3] specifies the mechanism for preventing UE's link-local address collision with the PGW's link-local address”. I know you may say that this proves your point that the suffix is used only for autoconfiguration, which I don’t deny. But I’d argue that NOTE 8 does not say configuring link-local address is the only reason for sending a non-zero suffix. We believe PGW may assign a complete, routable IPv6 address to the UE.
7.1.3	CT aspects of Enhancement to the 5GC LoCation Services	5G_eLCS
4026	CR 24.080 0069 Rel-16 ASN.1 Corrections	Nokia, Nokia Shanghai Bell	Agreed	WI 5G_eLCS CAT F
4142	CR 29.515 0012 Rel-16 API name correction	Nokia, Nokia Shanghai Bell	WI 5G_eLCS CAT F Peter: Other comments is missing.
4156	CR 29.572 0071 Rel-16 Optionality of ProblemDetails in TS29.572 cleanup	Huawei	Revised to C4-204388	WI 5G_eLCS CAT F Pallab: Couple of minor comments. Otherwise I am fine with the CR. Table 6.1.4.2.2-1, typo "Deterrmine Location"  change to "Determine Location" I think the changes in Table 6.1.5.1-1 should be reverted. The column heading should remain "Resource URI". The callback URI will be used as the Resource URI Caixia: I am fine with your 1st comment, and will correct the typo in the revision. For the 2st comment, actually, we have clear structure definition for resource URI, as defined in clause 6.2.1：{apiRoot}/<apiName>/<apiVersion>/<apiSpecificResourceUriPart> But for callback URI, there is no structure restriction, it can be any structure. That’s why we shall not call the callback URI as resource URI. Pallab: I understand your point and it is not a major concern for me. I just wanted to keep it uniform across all specs. Currently in other specs also e.g. in 29.503, 29.518 etc, this column heading is “Resource URI” Caixia: We also provide the contributions C4-204335 for template update, C4-204168 for TS 29.518 to correct the incorrect name. For other specifications, we can update the name in future meetings. Ulrich: And actually the existing text is inline with the template attached to 29.501 Caixia: We also provide contribution C4-204335 to update the template, please double check. Caixia: have uploaded draft v1 in folder [7.1.3] of draft inbox to correct the typo: Deterrmine
4388	CR 29.572 0071 Rel-16 Optionality of ProblemDetails in TS29.572 cleanup	Huawei
CC1	4232	CR 29.572 0072 Rel-16 Adding the validity time information of deferred MT-LR	CATT	withdrawn	WI 5G_eLCS CAT F Other comments is missing. Jones: I checked 23.273 and it is clearly stated that validity time is for LCS clients via OMA MLP, and it is maintain in GMLC for validation of LCS requests, i.e. will not pass it to AMF/LMF. I also checked with CT3 colleagues and even though LcsTimeWindow is specified, the usage of it is not concluded yet, and further clarification maybe needed. Additionally, even it is decided to support it on SBI, how will it be collaborated with other configurations in event, like the report duration, shall be further clarified. At current stage, we don’t think the CR is intended. Same comment to 4233 and 4234. Scott: It seems that your opinion makes sense. Can I withdraw the papers regarding 29.572 and 29.518 and keep the validity time value in 29.515, saying the value is used to specify the validity time of deferred MT-LR. Jones: For now, I prefer to postpone this CR and wait for more stable conclusion is made in Stage 2 and CT3. It is always easier to add, but difficult to remove CC1 Jones : propose to postpone the CRs Scott should we send an LS? Waqar: We would second that, i.e. CRs C4-204232, C4-204233, and C4-204234 are not needed. Some discussion on issues has already been done below. Scott: The start time and end time is not clear in 23.273 of stage 2. I think the validity time of start time and end time originated from 4G LCS and there are detailed description on the usage of these values in TS 23.271. Can I implements the validity time based on the specification in 4G LCS and appeal my SA2 colleague to update in TS 23.273 accordingly. If you are unhappy with the way forward, I can postpone the 29.515 paper. Anyway, I don’t think it is a big problem. And I suggest to withdraw the drafting LS to SA2 and CT3.
CC1	4233	CR 29.515 0013 Rel-16 Adding the validity time information of deferred MT-LR	CATT	WI 5G_eLCS CAT F Other comments is missing. Jones: See 4232
4336	LS out the validity time information of deferred MT-LR	Scott	To SA2 CC CT3
4234	CR 29.518 0393 Rel-16 Adding the validity time information of deferred MT-LR	CATT	Withdrawn	WI 5G_eLCS CAT F Other comments is missing. Jones: See 4232
4235	CR 29.572 0073 Rel-16 Adding missing navigation satellite systems for positioning	CATT	WI 5G_eLCS CAT F Peter: Other comments is missing.
4236	CR 29.572 0074 Rel-16 Including VGMLC address towards LMF when requesting LMF’s Location service	CATT	WI 5G_eLCS CAT F Peter: Other comments is missing.
4274	CR 29.171 0055 Rel-16 Updating positioning SIBs in Ciphering Data Set	Qualcomm Incorporated	WI 5G_eLCS CAT F 4 Octets are reserved this CR uses the 5th Octet Ulrich: in 7.4.39 the IE SIB Types is extended with 7 new bits (in addition to 27 existing bits) so that we have 34 bit in total; however, these do not fit into the OCTET STRING of Size 4. Waqar: Changing data types to accommodate extra bits would have backward compatibility issue so adding a new IE to accommodate all the data would be needed to address this. V1 provided https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.3/C4-204274_29171_PosSIB_r1.docx Ulrich: thank you for the revision in draft 4274. For backwards compatibility reasons: shouldn’t the new IE SIB Types Ext be optional rather than mandatory? And then absence of this IE shall be treated as all bits set to zero? I also noted that your CR clashes with 4301. Waqar: The updated draft is here: https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.3/C4-204274_29171_PosSIB_r2.docx I’ve gathered now all Rel-16 pos SIBs under the new IE Ulrich: the revision in r2 looks good to me Waqar: Please see draft merged CR in revision of 4274: https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.3/C4-204274_29171_PosSIB_r3.docx Qingfen: Thanks for your new revision, it looks good to me.
CC6	4275	CR 29.518 0398 Rel-16 Removal of EN on CP 5G CIoT Optimisation	Qualcomm Incorporated	WI 5G_eLCS CAT F Other comments is missing. Scott I suggest to evaluate whether the EN should be removed or not until the LS out from SA2 about the lower power 5GC-MT-LE procedure is released. My concern is that if AMF replies SERVICE ACCEPT message without waiting for Eventreport Ack from LMF, why do you need to include 5G CIoT CP optimization indication from AMF to LMF? Waqar: To review, the LS you are mentioning is an CT1-SA2 LS and most likely CT4 won’t be addressed in the reply as well, so I think this is strange that we attempt to postpone a CT4 CR based on this. Scott Technically, the solution has something to do with CT4 as I said in last email. Can you agree with it? In last CT1 meeting, CT1 LS is not sent to UE due to deadline of revision has passed. But CT1 think is needed to CC CT4. My SA2 colleague will suggest to CC CT4 in their LS out. So I suggest to wait for a while. Sunghoon The solution has two fold: 1) between UE and AMF, 2) between AMF and LMF. The LS sent from CT1 was about 1), and currently SA2 CR and reply LS are also for 1). I haven’t seen any proposal or discussion about 2). It means that whatever outcome is, there is no impact on 2) part. If you clarify how 1) affects to 2) in details, it would be better to understand your concern. Scott: Thank you for your clarification. In SA2, I think there are two solutions. HW suggests to reply Service Accept message without waiting for LMF’s Eventreport Ack. If this the case, I will urge my SA2 colleague to remove CP CIOT optimization indication from AMF to LMF. I think the indication make no sense. QC proposes to reply DL NAS TRANSPORT message as an acknowledgement of CPSR. If SA2 follows that way. I am OK to keep CP CIOT optimization indication and agree to remove EN. But right now, I don’t see an conclusion right now in SA2. So SA2 or maybe CT1 ‘s conclusion matter for the way forward in CT4.
4276	CR 29.515 0014 Rel-16 Correction of CodeWord Checking for UE Notification and Verification	Qualcomm Incorporated	WI 5G_eLCS CAT F Other comments is missing. Scott: The font of new content in Applicability feature should be changed from “Times new roman” to “Arial” Jones I am fine with the motivation. Some comments: According to the definition, If the CodeWord Check will not be checked at UE (codeWordCheck is false), the GMLC will not pass the CodeWord to AMF. The description “Checking of the Codeword parameter applies only when the Codeword parameter is present and when the codeWordCheck parameter is present and set to TRUE.” May be better rephased to “If CodeWord is to be checked in the UE, the Codeword received in the request shall be passed to UE.” Waqar] On this specific aspect, I think this does not capture the relatively simple motivation of this CR. To review, we have a duplicate mechanism of signaling for the applicability of the CodeWord: its presence or absence, and correspondingly the value of codeWordCheck Boolean being true and false, respectively. This actually makes the Boolean redundant in a way, but the CR only plans to anchor/map the values: CodeWord present only when codeWordCheck True, CodeWord absent only when codeWordCheck False. Hence the main motivation of the note in the CR is to rule out other nonsensical combinations (e.g. CodeWord absent  codeWordCheck TRUE!). So in this regard, your proposed alternative “If CodeWord is to be checked in the UE, the Codeword received in the request shall be passed to UE.” does not seem to fulfil the same purpose. Can you please recheck in this context? Thanks The text should be added as a table note, instead of applicability. Additionally, we also add a similar clarification for CodeWord attribute in InputData, with reference to codeWordCheck. Question: Per above definition, if GMLC only pass Codeword when it is required to check in UE, does AMF still need to check codeWordCheck again? Shall we make clarification on AMF API that the AMF should always pass the CodeWord received to the UE? Waqar Reply question above Jones: My concern is that the “checkCodeWord” indicates the CodeWord to be checked in UE or not, not for checking CodeWord or not. Actually (H-)GMLC will retrieve the privacy requirement form the subscription data from UDM, which specifies whether CodeWord to be checked in GMLC or in UE. So: If CodeWord is not received from NEF/AF/LCS Client, and subscription data specified CodeWord is to be check (in UE or in GMLC), the (H-)GMLC will reject the request; If CoddWord is received and subscription data specified CodeWord is to be check GMLC, the (H-)GMLC will perform CodeWord Check and will not pass CodeWord to the V-GMLC/AMF/UE. If CoddWord is received and subscription data specified CodeWord is to be check UE, the (H-)GMLC will pass CodeWord to the V-GMLC/AMF/UE and with privacy requirement with checkCodeWord always set to “TRUE”. (This is what I mean the checkCodeWord boolean attribute seems redundant. As long as the CodeWord is passed by (H-)GMLC, it already confirmed that it should be checked in UE). Maybe it is too late to remove the checkCodeWord attribute. If we want to clarify, maybe we could rephrase description “Checking of the Codeword in UE applies only when the Codeword parameter is present and when the codeWordCheck parameter is present and set to TRUE.” Waqar: Thanks Jones for the details. This and other comments addressed in updated draft: https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.3/C4-204276%20(CR%2029.515%20Correction%20of%20Codeword%20checking%20for%20eLCS)-r1.doc As for question on clarification for AMF, there is little that could be done now and perhaps we would need to have a CR in the next meeting. Jones: The V1 draft is fine by me.
4277	CR 29.515 0015 Rel-16 Correction of Notification or Verification only for UE Positioning	Qualcomm Incorporated	WI 5G_eLCS CAT F Other comments is missing. CR number of 29.571 is missing Jones: Some comments: The changes are better move to “InputData” data type where both attributes are specified. Other comments field is empty: should be filling with something like “this CR does not require version update on OpenAPI file”. Qingfen: Based on comments from Jones, I have one more minor comment: “Other specs affected:” on cover page should be either removed or add the affected CR Number and TS number. Waqar: Thanks Qingfen, Jones, updated draft with comments incorporated here: https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.3/C4-204277%20(CR%2029.515%20Corrections%20to%20Notification%20Verification%20for%20eLCS)-r1.doc
4278	CR 29.518 0399 Rel-16 Correction of Notification or Verification only for UE Positioning	Qualcomm Incorporated	WI 5G_eLCS CAT F Other comments is missing. Jones: Some comments: The changes are better move to “RequestPosInfo” data type where both attributes are specified. Other comments field is empty: should be filling with something like “this CR does not require version update on OpenAPI file”. Waqar: Thanks Jones, updated draft with comments integrated here: https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.3/C4-204278%20(CR%2029.518%20Corrections%20to%20Notification%20Verification%20for%20eLCS)-r1.doc
4279	CR 29.571 0235 Rel-16 Correction of Notification or Verification only for UE Positioning	Qualcomm Incorporated	withdrawn	WI 5G_eLCS CAT F Editorials: Use of strait quotes is recommended, unbreakable space in references. Other comments is missing. Jones: With changes in InputData in 29.515 (comments to 4277) and RequestPosInfo in 29.518 (comments to 4278), the modification in this CR is not needed. In general, constraints in enumeration definition with reference to other attributes are not obvious. It is better describe the conditions in data types using of the enumerations. Waqar Agreed, we withdraw the CR. Thanks for reviewing
4293	CR 29.505 0297 Rel-16 Store Broadcast Location Assistance Data	Huawei	Revised to C4-204374	WI 5G_eLCS CAT F Ulrich: -The query parameter „fields“ in 5.2.xx.3.1 is not needed (and shall be removed) as there is just one attribute (mandatory) in LcsBroadcastAssistanceTypesData. -In 5.2.1 the new resource LcsBroadcastAssistanceSubscriptionData was added under /subscription-data/{ueId}/lcs-bca-data (figure 5.2.1-2); however this is provisioned data per serving plmn and should go under /subscription-data/{ueId}/{servingPlmnId}/provisioned data/lcs-bca-data. (Note that in 29.503 clause 5.2.2.2.19 the service offered by the UDM to retrieve LCS Broadcast Assistance Subscription Data has plmn-id as a query parameter) -In table 5.2.1.-1 column Resource URI the new URI should not have /{supi} Qingfen: Thanks for your comments, I’m fine with them. The new draft version v1 was uploaded on server, please see https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.3/draftv1-C4-204293-CR0297-5G_eLCS-29505-Store%20Broadcast%20Location%20Assistance%20Data-R16.docx Ulrich: thank you for providing draftv1. You may want to add in A.2 Between parameters: - name: ueId in: path description: UE id required: true schema: $ref: 'TS29571_CommonData.yaml#/components/schemas/VarUeId' And - name: supported-features in: query description: Supported Features schema: $ref: 'TS29571_CommonData.yaml#/components/schemas/SupportedFeatures' The following: - name: servingPlmnId in: path description: PLMN ID required: true schema: $ref: '#/components/schemas/VarPlmnId' Qingfen Thanks so much for spotting this, the missing definition in yaml has been corrected in draftv2, draftv2 was uploaded on server, the link is https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.3/draftv2-C4-204293-CR0297-5G_eLCS-29505-Store%20Broadcast%20Location%20Assistance%20Data-R16.docx
4374	CR 29.505 0297 Rel-16 Store Broadcast Location Assistance Data	Huawei
4294	CR 29.504 0104 Rel-16 Store Broadcast Location Assistance Data	Huawei	Revised to C4-204375	WI 5G_eLCS CAT F Ulrich: See comments to 4293. 4294 needs to be revised to align with the revision of 4293. Qingfen: I’ll provide V1 later based on your comments. The new draft version v1 was uploaded on server, please see https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.3/draftv1-C4-204294-CR0104-5G_eLCS-29504-Store%20Broadcast%20Location%20Assistance%20Data-R16.docx Ulrich: thank you, the revision looks good to me.
4375	CR 29.504 0104 Rel-16 Store Broadcast Location Assistance Data	Huawei
4295	CR 29.515 0016 Rel-16 Corrections on EventNotify service operation	Huawei	Revised to C4-204376	WI 5G_eLCS CAT F Jones: Some comments: The new figure 5.2.2.2.1 is still wrong, Should be provide Location; ---[Qingfen] ok In 5.2.2.5.1, the new text “the callback URI of NEF registered in the NRF if the NEF registered to the NRF with notification endpoints for location notifications (see clauses 6.1.6.2.4 and 6.1.6.3.4 of 3GPP TS 29.510 [29]) and the callback URI is not provided during requesting the ProvideLocation service operation by the NEF, or ;” is not suitable. When eventNotify is sent for deferred location, the LDR reference is included which is assigned by the NEF previously invoking the ProvideLocation. i.e. the GMLC cannot randomly select a NEF to deliver the EventNotify. So the callback URI could either be passed by the NEF in InputData (proposed in the CR), or locally configured for specific deployments. I suggest we remove this bullet. -----[Qingfen]LDR Reference can also be assigned by GMLC, maybe I add more constrains that “the callback URI of NEF registered in the NRF if the NEF registered to the NRF with notification endpoints for location notifications (see clauses 6.1.6.2.4 and 6.1.6.3.4 of 3GPP TS 29.510 [29]) and the callback URI and LDR reference are not provided, and s during requesting the ProvideLocation service operation by the NEF, or ;” Jones: please find my reply to 4297. Ecgi/ncgi and barometricPressure are not intended to be included in EventNotify. They are only needed in MT-LR for regulatory service. ----[Qingfen] I have the same question that I indicated in reply of C4-204296, i.e. if Ecgi/ncgi and barometricPressure are not intended to be included in EventNotify, why are they included in the event notify of Namf_loctaion /Jones: Same to 4296. 6.1.5.1, data type start with Upper case ---[Qingfen]OK In OpenAPI, callbacks should be specified for new eventNoticationUri as well (similar to hgmlcCallbackUri): Jones: I mean that callback object should be specified for new added eventNotificationuri as well, like below callbacks: EventNotify: '{$request.body#/hgmlcCallBackUri}': post: requestBody: description: UE Event Notification content: application/json: schema: $ref: '#/components/schemas/EventNotifyData' responses: '204': description: Expected response to a valid notification '400': $ref: 'TS29571_CommonData.yaml#/components/responses/400' '401': $ref: 'TS29571_CommonData.yaml#/components/responses/401' '403': $ref: 'TS29571_CommonData.yaml#/components/responses/403' '404': $ref: 'TS29571_CommonData.yaml#/components/responses/404' '411': $ref: 'TS29571_CommonData.yaml#/components/responses/411' '413': $ref: 'TS29571_CommonData.yaml#/components/responses/413' '415': $ref: 'TS29571_CommonData.yaml#/components/responses/415' '429': $ref: 'TS29571_CommonData.yaml#/components/responses/429' '500': $ref: 'TS29571_CommonData.yaml#/components/responses/500' '503': $ref: 'TS29571_CommonData.yaml#/components/responses/503' '504': $ref: 'TS29571_CommonData.yaml#/components/responses/504' default: $ref: 'TS29571_CommonData.yaml#/components/responses/default' EventNotifyNEF: '{$request.body#/eventNotificationUri}': post: requestBody: description: UE Event Notification content: application/json: schema: $ref: '#/components/schemas/EventNotifyData' responses: '204': description: Expected response to a valid notification '400': $ref: 'TS29571_CommonData.yaml#/components/responses/400' '401': $ref: 'TS29571_CommonData.yaml#/components/responses/401' '403': $ref: 'TS29571_CommonData.yaml#/components/responses/403' '404': $ref: 'TS29571_CommonData.yaml#/components/responses/404' '411': $ref: 'TS29571_CommonData.yaml#/components/responses/411' '413': $ref: 'TS29571_CommonData.yaml#/components/responses/413' '415': $ref: 'TS29571_CommonData.yaml#/components/responses/415' '429': $ref: 'TS29571_CommonData.yaml#/components/responses/429' '500': $ref: 'TS29571_CommonData.yaml#/components/responses/500' '503': $ref: 'TS29571_CommonData.yaml#/components/responses/503' '504': $ref: 'TS29571_CommonData.yaml#/components/responses/504' default: $ref: 'TS29571_CommonData.yaml#/components/responses/default' ----[Qingfen]Sorry, I didn't get this. Qingfen: I get all your points now, I’ll take all of them onboard in new revision, and I’ll finish and upload the new revision later. Scott: My some comments: Figure 5.2.2.2.1-1 is wrongly implemented by the rapporteur, which should be rolled back. C4-204233 involved partially this problem. If (H)GMLC is selected to initiate Location Request for LCS client/AF, the NEF is exclusive. So I did see the benefit of including NEF callback URI during Location Request to GMLC. Qingfen: I’ll remove the change on (1) Figure 5.2.2.2.1-1 and leave the revision in your C4-204233, I’ll keep the revision in description in steps. The change to Figure 5.2.2.2.1-1 is incorrect. Serviceoperation of Eventnotify of AMF and LMF should be changed if we follow your reason for change. If the NEF is used to Location Request, VGMLC is not selected by AMF/LMF to event report. The arrow of procedure is reversed, which is not needed. ----Qingfen: I guess this comment is for clause 5.2.2.5.1? Actually VGMLC is selected by AMF/LMF. At least,VelocityEstimate, ecgi, ncgi, altitude and targetNode are not only included in EventNotify from VGMLC to HGMLC. I am not sure if barometricPressure is exposed to LCS client/AF. If needed to expose, it is also not only included in EventNotify from VGMLC to HGMLC ----Qingfen: ecgi, ncgi, barometricPressure won’t be exposed to AF according to the clarification from Jones, therefore I’ll remove them from EventNotifyData. If the AMF is changed, the information in EventNotify from old AMF should be serving AMF, why not make the Attribute name/Description descriptive, for example servingAMF, the change of the serving AMF for target UE. And it had better add an EN to describe the Event of serving AMF change ----Qingfen: in existing definition in EventNotifyData, there’s already amfId defined, but the data type of amfId is AmfId which different from data type (NfInstanceId) of the target serving AMF identifier reported by AMF, I’m not sure whether the target AMF node reported by AMF can be put in amfId, if could, I’ll move the newly defined targetNode and add the description (for mobility, amfId will carry the target serving AMF node identifier) in existing amfId. Qingfen: The new draft v1 was uploaded in server, please see https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.3/draftv1-C4-204295-CR0016-5G_eLCS-29515-Corrections%20on%20EventNotify%20service%20operation-R16.docx Jones: The V1 draft looks good to me. Thanks! Scott: Thank you for your work. I am fine with it.
4376	CR 29.515 0016 Rel-16 Corrections on EventNotify service operation	Huawei
CC1	4296	CR 29.572 0075 Rel-16 Corrections on EventNotify service operation	Huawei	Revised to C4-204377	WI 5G_eLCS CAT F Jones: Ecgi/ncgi and barometricPressure are not intended to be included in EventNotify. They are only needed in MT-LR for regulatory service. Qingfen: Thanks for your comment. I’m a little confused, if Ecgi/ncgi and barometricPressure are not intended to be included in EventNotify, why are they included in the event notify of Namf_location, could you please help to clarify that? Jones: Namf_Location_EventNotify can be used by e.g. 5GC-NI-LR for emergency call (see below flow). AMF invoke determine location request and get the information from LMF, then use AMF EventNotify to inform GMLC/LRF and GMLC/LRF will inform external client (e.g. emergency call center). But LMF Event Notify and GMLC Event Notify are used only for deferred location for commercial location services. Qingfen: thanks for clarification, I’ll remove Ecgi/ncgi and barometricPressure from eventNotify of Nlmf_location and eventNotify of Ngmlc_location. Qingfen: The new draft v1 was uploaded on server, please see https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.3/draftv1-C4-204296-CR0075-5G_eLCS-29572-Corrections%20on%20EventNotify%20service%20operation-R16.docx
4377	CR 29.572 0075 Rel-16 Corrections on EventNotify service operation	Huawei
CC1	4297	CR 29.510 0387 Rel-16 Corrections on definition of NotificationType	Huawei	Revised to C4-204378	WI 5G_eLCS CAT F Jones: NEF for eventnotify is not suitable to be handled with default subscription. When eventNotify is sent for deferred location, the LDR reference is included which is assigned by the NEF previously invoking the ProvideLocation. i.e. the GMLC cannot randomly select a NEF to deliver the EventNotify. So the callback URI could either be passed by the NEF in InputData, or locally configured for specific deployments as stated in CR 4295. Qingfen: LDR Reference can also be assigned by GMLC, if both LDR Reference and callback uri are both not provided by NEF, I think GMLC get the default callback uri of NEF works. CC Qingfen need to check stage 2 procedures. Jones: If the location request is received form NEF, the LDR is allocated by NEF and passed to (H-)GMLC, if the location request is received form an LCS client (via OMA MLP) then the LDR reference number can be assigned by GMLC. Please see TS 23.273: 6.3 Deferred 5GC-MT-LR Procedure for Periodic, Triggered and UE Available Location Events 6.3.1 Initiation and Reporting of Location Events … 4. This step is skipped for a non-roaming UE. For a roaming UE, the HGMLC obtains a VGMLC address if not received at step 3 and invokes the Ngmlc_Location_Provide Location Request service operation to forward the location request to the VGMLC as described for step 4 of in clause 6.1.2. The (H)GMLC also includes a contact address for the (H)GMLC (Notification Target Address, e.g. a URI) and an LDR reference number (Notification correlation ID) to be used for event reporting at steps 20 and 29. The LDR reference number is either allocated by (H-)GMLC based on predefined rule, e.g. operator's policy if the location request is received in step 1a, or allocated by NEF, if the location request is received in step 1b. Actually the LDR reference is essential for NEF to correlate the notification request as the notification correlation ID, which is why it is assigned by NEF for AFs. Caixia: Thanks for your clarification. I agree with you, I removed the text “Notification of Location Information by GMLC towards NF Service Consumers (e.g NEF)”from the 4297. Add the new revision was upload on server, see https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.3/draftv1-C4-204297-CR0387-5G_eLCS-29510-Corrections%20on%20definition%20of%20NotificationType-R16.docx.
4378	CR 29.510 0387 Rel-16 Corrections on definition of NotificationType	Huawei
4321	CR 29.515 0017 Rel-16 Corrections on Application Errors in provide-location response	Huawei	Revised to C4-204412	WI 5G_eLCS CAT F Pallab: I think the description for PEER_NOT_RESPONDING in Table 6.1.6.3-1 needs more clarity. There can be below possibilities 1. No response received by the AMF from LMF, so it sent 504 with PEER_NOT_RESPONDING to (V)GMLC, and consequently (V)GMLC sends 504 with PEER_NOT_REPONDING 2. (V)GMLC did not receive any response from AMF, so it sends 504 with PEER_NOT_RESPONDING Qingfen: Pallabs comments looks good to me, I’ll take them onboard in the new version. Scott: If “DETACHED_USER” is reusing existing defination, then at least the description should specify the target UE is deregistered in the AMF. Qingfen: I’m fine with Scott's comments, and I’ll take it onboard in the new revision. The new draft v1 was uploaded on server, please see https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.3/draftv1-C4-204321-CR0017-5G_eLCS-29.515-Corrections%20on%20Application%20Errors%20in%20provide-location%20response-R16.docx
4412	CR 29.515 0017 Rel-16 Corrections on Application Errors in provide-location response	Huawei
4322	CR 29.515 0018 Rel-16 Corrections on LocationData	Huawei	Revised to C4-204413	WI 5G_eLCS CAT F Text in revison history should be in Other comments. Jones: Some comments: For BarometricPressure, it is only for emergency which is handled completely in VPLMN when roaming. For ECgi/Ncgi, they are not intended to be transferred to H-PLMN which has no context of the information. (CGI information are sensitive data thus usually not intended to exposure to other PLMNs). Usually the V-GMLC may convert them to geo-location and transfer the geo-location to H-GMLC instead. Qingfen The comments look good to me, thanks a lot! New revision draft v1 was uploaded on server, please see https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.3/draftv1-C4-204322-CR0018-5G_eLCS-29515-Corrections%20on%20LocationData-R16.docx
4413	CR 29.515 0018 Rel-16 Corrections on LocationData	Huawei
4323	CR 29.515 0019 Rel-16 Provide Location for Bulk Operation	Huawei	WI 5G_eLCS CAT F Pallab: I would like to proposes to postpone the CR, as reply to LS sent out from CT4 to SA2 (C4-203629), seeking clarification on stage 2 specification is still pending. It would be premature to implement stage 3 before getting a clarification from SA2. Qingfen: There will be some discussion on LS from CT4 to SA2 on the ongoing S2 meeting, maybe we can get the response from the ongoing SA2. I’m fine to postpone it a bit to the later timing during this meeting in order to wait for the response from S2. If there is still no response at the end of the ongoing S2 meeting, I’m fine to postpone this CR to next CT4 meeting. Scott: I echo your suggestion to suspend the paper’s discussion until SA2’s LS out is received. Qingfen: I’m fine with your suggestion, thanks! Postpone until we receive feedback from SA2.
CC1	4324	CR 29.518 0402 Rel-16 Add Response Codes on operation provide-pos-info	Huawei	Revised to C4-204414	WI 5G_eLCS CAT F Other comments and revison history/Clauses effected contradiction. Jones: We don’t think it is necessary to introduce async mode for location request. Usually positioning location request does take quite long time (depends on the positioning methods involved) thus GMLC should prepare to wait for such processing time. And whether a location request takes very long time or short time is not decided by AMF, rather by LMF. ---Qingfen: According to the real interworking test data, the time taken for the procedures between AMF, RAN, UE, LMF may be in seconds level depending on the positioning methods involved, therefore you mentioned above “positioning location request does take quite long time” is not the true case. If GMLC sets too big timer, some performance problems may rise when huge messages are handling, Jones: I don’t think this really introduces performance problems. Like you said, if the location request is returned in seconds level (already quite long in telecom context), regardless how long GMLC set the timer internally, it will stop the timer and continue the processing once received response from AMF and another problem is that the timer on NFs after GMLC (e.g. NEF, LCS client) is set as the same big as one on GMLC, these NFs will think positioning fails after timer expires but actually the positioning is still ongoing in AMF side. And if GMLC sets too small timer, GMLL itself will consider that positioning fails after timer expires but actually the positioning is still ongoing in AMF side. Therefore the existing mechanism indeed have some issues in the scenarios I mentioned above. /Jones: Usually we can think the GMLC TIMEOUT time could be configurable and could be adapted for different services. Furthermore, I don’t see how this scenario could be avoided with proposed mechanism in the CR… Can you explain. At least for now, we cannot agree to directly introduce such a new mechanism directly in Stage 3. If this is really considered necessary, we should trigger this at stage 2 and get agreed. Using 204 for deferred location request may not be a good option. Even though the location data is not ready for deferred location response, the AMF also needs to provide other information in the response, e.g. the Serving LMF identification should be returned in deferred location response for subsequent potential cancel-location operation, also supported features may be carried to exchange the capability between the NFs. As all the IEs in the ProvidePosInfo is optional, it is safe for AMF to continue using it for deferred location response. ----Qingfen: May I ask a question: for clause 6.3.1 step 6 in 23.273, which existing attributes need be delivered to AMF? I don’t think Serving LMF identification need to be delivered to GMLC in this step because the serving LMF isn’t selected yet. /Jones: You are right, the LMF selection happens after UE becomes active. Emm… then I am think why we have LMF Identification in Location Response… So the only other information to exchange could be the supported features bits. I think this might also be important as this is the first service operation between the NF consumer and producer. But on the other hand, if there is no supported features to be exchanged, then return 204 seems better option then an empty JSON object. So could we add the 204 response code and in the service description say “shall return 204 if no information is to be returned” instead of “204 is always returned for deferred MT-LR”. Above all, we don’t think the CR is really needed. Scott I am not sure about asynchronous positioning , could you clarify: What does the URI of the positioning resource mean? Do you mean GMLC may release the resource after receiving 202 accepted. If not what is the benefit of asynchronous positioning? Bruno: The terminology "ASYNCHRONOUS_POSITIONING" is nowhere defined, not either in stage 2, and is confusing as this could mistakenly suggest this relates to asynchronous communication defined in stage 2. Table 6.4.3.2.4.2.2-2 (and other places in the CR) does even refer to "asynchronous communication" when I understand this does actually not relate to the asynchronous communication concept of stage 2. ---Qingfen: your understanding is right, the mechanism in my CR is not actually related to the asynchronous communication concept of stage 2. The motivation of the CR is to solve the issue that the response may take very long time (maybe seconds level )from angle of the interface implementation "[solution suggested] An asynchronous mechanism is added. When the GMLC send ProvidePostionInfo request to AMF, GMLC indicates that asynchronous mechanism will apply, if AMF supports the mechanism, AMF responds 202 Accepted and URI of the positioning resource, then GMLC can get the position from the URI provided by AMF after all the procedures related positioning are handled": it is not clear how the GMLC knows when the positioning result is available. I would also expect the GMLC to provide a callback URI in such a proposal, where it would receive the location result when available. ----Qingfen: I absolutely and fully agree with you about the points you mentioned above. Firsly,Negotiation between GMLC and AMF about supporting 202 Accepted may be necessary from the angle of backward capability, one option is to add an indication on whether mechanism is supported or not by GMLC in the request body, and if AMF support the 202 accepted and indication in request set to true, AMF send the response with 202 accepted. Secondly about how GMLC kowns when the positioning result is available, one way is that GMLC queries the AMF via provided URI of the positioning resource by AMF per period of time before obtaining the result, another way is GMLC provides a callback URI to AMF and AMF notifies the GMLC after result is obtained. Other comments: "This CR won't introduce any impact on OpenAPI specification files." is incorrect ---Qingfen: You are correct. I’ll correct it. Figure 5.5.2.2.1-1: typo "No Content" ---Qingfen: You are correct. I’ll correct it. A.5: "'204': description: Expected response to accept a valid request" confusing ----Qingfen: how about “Successful accept of deferred location request” The CR seems actually to challenge the stage 2 call flow and propose a different solution/call flow than what SA2 specified. If so, this should be discussed in coordination with SA2. ----Qingfen: If the first way I mentioned above is used, maybe stage 2 call flow won’t be impacted? CC Qingfen need more time to check the details. Qingfen: Maybe the using words “asynchronous positioning” is incorrect, actually it is not the asynchronous mechanism which is indicated in stage 2. Actually the mechanism used in 4324 is based on the HTTP 202 accepted, the AMF response the GMLC with 202 accepted and positioning resource uri in location header if AMF accepted the positioning and start to deal with the positioning, GMLC can get the positioning result by visiting positioning resource uri after positioning finishes on AMF. This mechanism is good for that the dealing on server side may take long time and the client have to set a very long timer to wait the response or the set timer on client is not long enough to wait the response. Waqar: To add to the following discussion, the CR does not seem to be necessary correction per se, and more like a proposed enhancement that will even impact stage-2 (in TS 23.273 clause 6.1.2 and 6.3.1). Even there, we’re not sure if this is a needed enhancement since a GMLC knows from QoS information how long to wait for a location response (for a regular MT-LR) and already gets informed by an AMF on acceptance of a deferred MT-LR request. Qingfen: not every positioning request has a high requirement on response time, If the response time is the most import thing for positioning request, the situation I mentioned above will exist. Jones: This GET service operation and corresponding resources are not specified in anywhere. Also how GMLC will get known that AMF has done the positioning? If GMLC doesn’t perform the GET on this resource, how long should AMF keep it? All these complexities are needs to be considered. If we want to introduce such a change, we should discuss and get agreed first at stage 2. CC Qingfen we need to remove 202 case from this CR and ask SA2 to align/introduce 202 use case. Bruno not sure if we need SA2 interaction. Needs further checking. Qingfen will summarise the 202 use case in an email. Qingfen: Based on the discussion on last Friday CC meeting, the summary of why I insist that “asynchronous positioning” is necessary is as below： According to the real interworking test data, the time taken for the procedures between AMF, RAN, UE, LMF may be in seconds level depending on the positioning methods involved, UE state, and network deployment, therefore the period between positioning request and response is at seconds level, this will result in that the http layer timer set for waiting positioning response need be at seconds level and the timer is uncertain too (because it depends on several factors, e.g. network deployment). /Jones: This is similar to the measurements in EPS and legacy systems, why it is not seen as a serious problem in legacy system but a specific risk in 5GS? If the HTTP layer timer is set too big, firstly the resource is occupied very long to supervise the timer and wait the response, then this will cause the performance issue if signaling on GMLC is huge, secondly the HTTP layer timer shares in the service level or even upper level, if the timer for provide position service operation is set big, it means that the timer for other service operations will be big too, and this will cause the issue that the client need to spend too long time to obtain the real failure of the timeout (but for other service operations, the response only takes very short time). /Jones: Long HTTP timeout maybe an issue for HTTP 1/x where each HTTP transaction consumes a TCP connection (when connection is not reused). For HTTP/2 and later, HTTP message are stream based sharing HTTP connections, and NF peers will also maintain parallel connections in between, so what will be the extra resources cost here? For upper layer, regardless what kind of mechanism we taken at HTTP level, the transaction context needs to be maintained before the final result is received or derived, i.e. the upper layer timeout for service operation is independently managed according only to the application logic from business needs. Even worse, if with the proposed asynchronized mechanism, the upper layer needs to maintain the context and perform a periodically fetching operation towards the AMF attempting to get the location result. This does leads to extra traffics in network which are not necessary. On the other hand, regardless how long the GMLC will wait for the response, e.g. 1 hour (impossible in practice of course 😊), when most of the requests are responded within seconds (for other service operations, it should be shorter as you stated), the GMLC will just handle the responses and cleanup the timer as soon as the response is actually received. BTW, what other kind of service operation in GMLC you are referring here? The issue mentioned above not only exist between step 4 and 15, and also exist between step 1b-2 and 24b-1 (the issue is more serious for that NEF get the response of providelocation response) in the below figure of procedure of GC-MT-LR Procedure for the commercial location services in 23.273. Figur from stage 2 removed email 24/08/2020 03:48 /Jones: as you can see, for a legacy LCS client, the same procedure is applied for 1a and 24a which is exactly the same use case and same possibility of service operation lasting time. Therefore that’s why I suggested involving S2 and asking them to analyze the issues above and consider whether asynchronous positioning is necessary to be introduced or not for GC-MT-LR Procedure. Jones Reply above
4414	CR 29.518 0402 Rel-16 Add Response Codes on operation provide-pos-info	Huawei	Agreed
4325	CR 29.518 0403 Rel-16 Corrections on N2InformationNotification	Huawei	Agreed	WI 5G_eLCS CAT F
CC1	4329	CR 29.515 0020 Rel-16 Essential correction to OpenAPI specification for LocationUpdateNotify service operation	Orange	WI 5G_eLCS CAT F Jones: The current specification of callbacks at top level is a compromised selection after consideration. The Location Update Notify is a unsolicited notification without any parent service operation, there could be two options: Specify a fake service operation to be the parent service operation of this callback, which will never be invoked by any NF consumer, just to host the callbacks objects in OpenAPI. Then it requires unnecessary resource tree and specification in the document body which are useless. (BTW, the current proposal in this CR is targeting this way, but not correct. Location Update Notify is not callback resulted by Location Update thus putting this way is really misleading). Specify a top level callback objects. We acknowledge this is currently not supported in Open API specification 3.0, but very similar to the webhooks concept in OpenAPI specification 3.1 (they added a "webhooks" keyword, at the top level): https://github.com/OAI/OpenAPI-Specification/blob/v3.1.0-dev/versions/3.1.0.md#openapi-object Even though both ways are not really satisfying the real needs of the definition, after consideration (and stated in previous meeting) we choose the second option for the specification which is more aligned with future trends in our view. We can hear voices from others. If we really need to take option-1, then the CR should be revised to introduce the dummy parent operation and complete with documentation accordingly. CC Abdessamad need more time to check. Jones other should also check. Abdessamad: Thanks for your comments, I knew that what I proposed was not really complete ! I am OK with both ways, but my understanding from last meeting’s discussion is that option 2 cannot be adopted as per the current version of the OpenAPI (i.e. 3.0). That was the main reason why our proposal in C4-203351/3352/3353/3354 was not accepted/considered. Therefore, I think that option 1 is more suitable, even if I fully agree with that it is not the optimal solution. At least, it would be correct as per the current version of OpenAPI. I am however open to discussion if there are other views/opinions. Jones: I am also OK for both ways. If option 1 is preferred, I think that we should make the CR more complete for approval 😊
7.1.4	CT Aspects of Media Handling for RAN Delay Budget Reporting in MTSI	E2E_DELAY
7.1.5	User data interworking, Coexistence and Migration	UDICOM
4012	CR 23.632 0022 Rel-16 Removal of Editor's Notes	Nokia, Nokia Shanghai Bell	Agreed	WI UDICOM CAT F
4064	CR 29.503 0461 Rel-16 Deregistration Reason Clarification	Hewlett-Packard Enterprise	Agreed	WI UDICOM CAT F
4067	CR 29.563 0007 Rel-16 UeId correction for the EE Subscription	Hewlett-Packard Enterprise	Agreed	WI UDICOM CAT F
CC2	4072	CR 29.503 0463 Rel-16 NodeType in HssAuthenticationInfoRequest	Hewlett-Packard Enterprise	WI UDICOM CAT F Jesus Adding a Mandatory IE to an existing data type is not backwards compatible. Overall, we believe that adding the requesting node type should not be needed, if the type of node can be derived from the type of vectors requested. This is the same reason for which "requesting node type" was removed from S6a/AIR Diameter command, back in the early days of EPS. See CR#0089 to TS 29.272. Anyway, if we eventually conclude that requesting node type should be added, it should be O, or C, but not M, for the BC reason indicated above. CC The intention should be to make the change backward compatible Anders: The requesting Node type was mainly added to help disambiguate the EAP-AKA from the lastIndexes values of GAN_AAA_SERVER and WLAN_AAA_SERVER as EAP_AKA is applicable to both. EAP-AKA’ may also be applicable to both. Related to the discussion on the mme-sgsn value in C4-204330 but perhaps more relevant here, is that if a combined MME/SGSN node request both UTRAN and E-UTRAN vectors from the HSS, there is no way for the HSS to request two vectors from the UDM with a single command. I.e., the HSS can only request one type of vectors as defined in the HssAuthType. Even with the addition of requestingNodeType, it would be optional and would clash with HssAuthType if set to e.g. mme-sgsn, which we don’t want. The UDM can also only return one set of Vectors: HssAuthenticationVectors: oneOf: - type: array items: $ref: '#/components/schemas/AvEpsAka' minItems: 1 maxItems: 5 - type: array items: $ref: '#/components/schemas/AvImsGbaEapAka' minItems: 1 maxItems: 5 - type: array items: $ref: '#/components/schemas/AvEapAkaPrime' minItems: 1 maxItems: 5 I wanted to bring it up here to see if there is any consensus in enhancing the spec to allow for the HSS to request two vectors in order to support the combined MME/SGSN node as it might not be totally straight forward to do it in a 100% backward compatible way. The HSS can of course request vectors twice, but it might result in some significant additional latency if it does. If there is interest, HPE is willing to revise the 4072 to accommodate. Anders: I have uploaded draft v1 to the draft inbox where the NodeType is no longer mandatory
4092	CR 23.632 0023 Rel-16 Missing error conditions in SMSF registration information retrieval	Ericsson	Agreed	WI UDICOM CAT F
4093	CR 29.503 0468 Rel-16 Definition of missing error conditions in SMSF registration information retrieval	Ericsson	Agreed	WI UDICOM CAT F
CC2	4127	CR 29.563 0008 Rel-16 Correction of HSS Event Exposure data types	Ericsson	WI UDICOM CAT F Anders: In 6.4.6.2.x1, the new text does not describe the behavior when maxNumberofReports is missing. Compare 29.336: If both Maximum-Number-of-Reports and Monitoring-Duration AVPs are absent, the monitoring event configuration shall be considered as a one-time monitoring request (same behaviour as setting Maximum-Number-of-Reports to 1) Would it be worthwhile to include similar text here? Similar text might also be applicable to 6.4.6.2.2 if reportingOptions is missing, it implies a one-time report. Also note that I have the same comments on 4110 and 4111 as it seems worthwhile to harmonize the behavior around the “maximum number of reports” across specifications. Jesus I agree that some clarification is appropriate. But I would not go necessarily in the same direction as in 29.336. In my opinion, we should follow 23.502 for that, where we have for Event Exposure: "The requester shall include 2) Maximum number of reports or 3) Maximum duration of reporting, or both, depending on 1) Event reporting mode." Ulrich in A.5 there is still (two occurrences): $ref: 'TS29503_Nudm_EE.yaml#/components/schemas/EventType' CC Jesus would prefer to handle 5G different than 4G/EPS How to interpret presence or absence should be clarified. Jesus would prefer not to follow MONTE approach.
CC2	4330	CR 29.505 0299 Rel-16 Incorrect index type	Hewlett-Packard Enterprise	WI UDICOM CAT F Jesus: The index type (mme-sgsn) was introduced for alignment with EPS. In 29.002 we have: RequestingNodeType ::= ENUMERATED { vlr (0), sgsn (1), ..., s-cscf (2), bsf (3), gan-aaa-server (4), wlan-aaa-server (5), mme (16), mme-sgsn (17) } So, I wonder, if such value was used with no problems in EPS, why is it a problem now in 5GC? CC We agreed to align index types. Anders: The mme-sgsn value in MAP was added in CR 0892 as part of the Gr+ enhancements to allow the IWF to translate between S6a/d to MAP Gr+. Since a combined MME/SGSN can request both E-UTRAN and UTRAN vectors in the AIR (29.272): A combined MME/SGSN may include both the Requested-EUTRAN-Authentication-Info AVP and the Requested-UTRAN-GERAN-Authentication-Info AVP in the request If the Requested-EUTRAN-Authentication-Info AVP is present in the request, the HSS shall download E-UTRAN authentication vectors to the MME. If the Requested-UTRAN-GERAN-Authentication-Info AVP is present in the request, the HSS shall download UTRAN or GERAN authentication vectors to the SGSN. The IWF would use the mme-sgsn value of RequestedNodeType to the HLR which would result in two vectors being returned. So we don’t believe a value of mme-sgsn is applicable as a sequence number index as the MME and SGSN ranges should be managed separately even if requested by a combined node.
7.1.6	Service based Interface protocol improvements	SBIProtoc16
4025	CR 29.504 0100 Rel-16 Scopes for Resource Level Authorization	Nokia, Nokia Shanghai Bell, Ericsson	Agreed	WI SBIProtoc16 CAT F
4056	CR 29.503 0460 Rel-16 UE Context Retrieval	Hewlett-Packard Enterprise	Agreed	WI SBIProtoc16 CAT F
4083	CR 29.501 0086 Rel-16 Handling of JSON Arrays	Ericsson	WI SBIProtoc16 CAT F Yue I fully support the principle of this CR. May it be improved by adding text describing more about how the NFs should handle the array? E.g. "if the NF needs to cache the JSON information received in HTTP message, it shall use exact the same representation of arrays as received" "when sending notification or modification with json-patch, NF shall use exact the same representation of arrays as previously signalled", something like that. Jesus I'll try to add some text similar to what you proposed. Yue: BTW, please add China Mobile as co-signing company, thank you Jesus: I have uploaded a draft revision in: https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.6/draft-C4-204083-Handling-Of-Array-Updates-29501-v1.docx
4086	CR 29.510 0371 Rel-16 NF Group ID	Ericsson	WI SBIProtoc16 CAT F Yue If the NF only includes Group ID during NF registration, should the NRF generate xxInfo attributes e.g. supiRanges and include in the NF profile? Is it possible that during the initial registration to the NRF the NF only includes Group ID, then upon subsequent modification of NF profile, the NF includes xxInfo attributes like supiRanges? Bruno: C4-204086 overlaps with Nokia/Verizon CR in C4-204204, both CRs having very similar contents. I would be fine to merge our CRs with the Ericsson CR, with the following comments: WI should be TEI16, 5GS_Ph1-CT (as this is a correction of an error made in Rel-15, not an improvement) Chfinfo needs also to be corrected with similar changes (like in our CR). There is a copy/paste mistake in clause 6.1.6.2.8: "the AUSF can serve any SUPI managed by the PLMN of the UDM instance": -> AUSF Additionally, we propose to add in the note, after the new text, that "The NRF may also add a deduced supiRanges parameter that includes the SUPI(s) that are mapped to the UDMs Group ID when conveying the UDM profile to the NF Consumers": This can help improving interoperability with NF that reuse cached profiles but do not support this CR Conveying the supiRanges allows also NFs reusing cached Profiles and selecting UDM/AUSF from correct Group without having to do a NRF Query for each new UE. This also helps SCP caching such information especially if Model D is used. We might need to also clarify the case where e.g. supiRanges is provided but e.g. .groupId and gspiRanges not, since this does not fall into any of the two case defined up to now ( “none of these parameters” nor “when the groupId parameter is provided”). In this case “some -but not all- of these parameters are provided and groupId is absent”, my interpretation is that the UDM (or other NF) supports only the indicated SUPI ranges, i.e. it cannot be assumed that it supports any GPSI; no info would be available then for NF selection based on GPSI, so this assumes that there would be no need to do such NF selection based on GPSI. My comments above respond to the first question from Yue: we should allow this NRF option. My answer to Yue’s second question is yes. Jesus: Thanks for the comments. We are fine merging the CRs and I'll try to come up with a common version. The first comments are ok (to cover ChfInfo and fixing AusfInfo), but I'll check a bit further the proposal to add ranges in the discovery response. In principle, a problem I see is that the discovery responses might be huge; one of the reasons for introducing GroupIDs, if I'm not wrong, was to avoid managing ranges at the NFs themselves, and delegate that to the NRF (to a backend DB); then, if an NF registers in NRF providing just a groupID (so the NF profile size is quite small in size), but then the discoveries of such profile result if several MB's of ranges, then I'm not sure if that defeats the purpose of having groupID at all. [Yue] if the NF discovery result only contains groupID, then the result is less re-usable. For instance, AMF queries NRF for an UDM which can serve SUPI#1, and get UDM profile contains only group#1. Then there comes another UE with SUPI#2, the AMF has no idea whether the previously discovered UDM can serve this UE or not, because the AMF has no idea of "group#1". In that sense, more signalling will be triggered. Jesus: Yes, I agree it is a tradeoff between signalling and manageability of ranges. Anyway this approach does not result necessarily into a query per UE, since the AMF may detect which Group ID serves a new UE based on the Routing ID of the new UE and the cached UDM profiles. Still, I agree that a totally new UE, for which you don't know GroupID/RoutingID would need a new NRF query, that's right. Also, from a more fundamental point of view, this approach results in a huge deviation from what a producer registers in NRF, and what consumers discover from NRF. And this may lead us to problems similar to what we saw in the last meeting. E.g. if a consumer discovers an NF profile, and it receives ranges, and subscribes to it, it will never receive any update of such ranges, even if they change in NRF, since those ranges were not available in the profile that the producer registered. CC Jesus: We agreed to merge but will only contain baseline. What about Rel-15? We agreed to start from Rel-15. Jesus: I have uploaded a draft revision of the R16 CR and also a draft R15 CR (new), as agreed in the conf. call. R15 CR: https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.6/draft-C4-204xyz-NF-Group-ID-29510-Rel15.docx R16 CR: https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.6/draft-C4-204086-NF-Group-ID-29510-Rel16-v1.docx I have put as co-source Nokia, Nokia SB, and Verizon. Please confirm. Both CRs are cat F, since the R16 version introduces changes not present in the R15 version. The WI has been changed to 5GS_Ph1-CT (adding TEI16 in the R16 version), but I have left both CRs under this agenda item (7.1.6), for easier traceability. Bruno: In clause 6.1.6.2.8 (AusfInfo), you need to strike the highlighted text below: List of ranges of SUPIs that can be served by the AUSF instance. If not provided, the AUSF can serve any SUPI. (NOTE) Any feedback to the following comment: We might need to also clarify the case where e.g. supiRanges is provided but e.g. .groupId and gspiRanges not, since this does not fall into any of the two case defined up to now ( “none of these parameters” nor “when the groupId parameter is provided”). In this case “some -but not all- of these parameters are provided and groupId is absent”, my interpretation is that the UDM (or other NF) supports only the indicated SUPI ranges, i.e. it cannot be assumed that it supports any GPSI; no info would be available then for NF selection based on GPSI, so this assumes that there would be no need to do such NF selection based on GPSI. I confirm that Nokia & Nokia Shanghai Bell co-sign this revision. Jesus: Thanks for the comment, and confirming the co-signature of the CR. I have corrected the description of supiRanges in AusfInfo, per your suggestion, in both R15 and R16 CR. Regarding your question below, about absence of other parameters (e.g. gpsiRanges) I agree with your interpretation, but I don't think that any further clarification text is needed. After we have removed from all "xxxRanges" attributes the statement that says "If not provided, the NF server any XXX", then there is only one logical interpretation of its absence: the NF does not indicate anything about its support of ranges of users for those identifiers, so there is no reason to think that the NF may support all users. So, this is inline to your statement below: my interpretation is that the UDM (or other NF) supports only the indicated SUPI ranges, i.e. it cannot be assumed that it supports any GPSI; no info would be available then for NF selection based on GPSI, The revisions have been made available here: R15: https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.6/draft-C4-204xyz-NF-Group-ID-29510-Rel15-v1.docx R16: https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.6/draft-C4-204086-NF-Group-ID-29510-Rel16-v2.docx Please let me know if you have further comments. Bruno: Revisions are fine
4087	CR 29.503 0467 Rel-16 UDM parameter provision datakey	Ericsson	WI SBIProtoc16 CAT F Qingfen: Some comments below： We can see data keys for different parameter provisions (see description stage 2 below) are different, although some the parameter provisions share the same resource and service operation, it is necessary to clarify which data key will be used for different kind of Parameter Provision somewhere, this will be clearer for implementation. Table 5.2.3.6.1-2 of TS 23.502 has defined Parameter Provision Data Types keys for Nudm_ParameterProvision Service. Table 5.2.3.6.1-2: Parameter Provision data types keys Parameter Provision Data Types Data Key Expected UE Behaviour parameters GPSI or External Group ID Network Configuration parameters GPSI 5G-VN group data External Group Identifier 5G VN group membership management parameters External Group Identifier Location Privacy Indication parameters. GPSI Enhanced Coverage Restriction Informaton GPSI Jesus But isn't it enough with the table you just showed? The specs of the 5GS are not just the stage-3 specs, but also the stage-2 specs, which must be taken onboard in the same way as stage-3 specs, for implementation. So, to my knowledge, in other parts of this spec (or in other APIs), when we have a UE variable in the resource path that may contain different identities (e.g. SUPI, GPSI, …) we don't usually specify in detail (in stage-3 specs) _when_ each type of identity is used (this is usually derived from the tables and signaling flows specified in stage-2).
4088	CR 29.510 0372 Rel-16 Handling of S-NSSAI per PLMN	Ericsson	Agreed	WI SBIProtoc16 CAT F
CC5	4089	CR 29.500 0146 Rel-16 Asserted PLMN-ID Header	Ericsson	WI SBIProtoc16 CAT F Hiroshi: If the given mandatory requirement from TS 33.501 in the “reason for change” is from Release 15, why is this new header “3gpp-Sbi-Asserted-Plmn-Id” proposed only from Release 16? [Jesus] As a general principle, we try to not modify R15 unless the flaw is really a FASMO case. This scenario is definitely frequent, but we (CT4) may not be in the best position to assess how serious it is the potential security issue resulting from not meeting the requirement from SA3. SA3 is currently evaluating CRs on the same topic, so if SA3 decides to cover this in R15, we (CT4) can do that as well Are there any other NF apart from AUSF that requires pSEPP to provide the serving network? Perhaps the condition in the CR can be clarified, as it seems that if OAuth2 is not used, it becomes mandatory for pSEPP to include this header towards AUSF, while the CR makes the inclusion optional. [Jesus] There are several APIs in which the PLMN-ID of the remote PLMN is passed as input data, either as a query parameter (e.g. in the NRF Discovery request, and also in UDM APIs) or in the request payload (UDM APIs). In those, the producer NF does not have the means to check whether the PLMN-ID that the consumer NF is sending is actually correct. Hiroshi: Thank you for your clarification. Bruno: The intention of the CR looks fine, but I am aware of related discussions in SA3, i.e. this CR depends on agreement of SA3 CRs S3-201917/1918 (DP in 1916). Do you know what is the status of these SA3 CRs/discussions? Note that S3-201917 is proposed against Rel-15. The SA3 CR speaks about the “receiving SEPP” including the asserted PLMN-ID, which is not necessarily the p-SEPP, i.e. this can also be a c-SEPP for a callback/notification request sent from producer to consumer. Do you also confirm that the p-SEPP determines the asserted PLMN ID of the source PLMN by using the n32fContextId received in the N32-f HTTP request and by retrieving from the corresponding context the source PLMN FQDN used during the N32-c handshake? Should the N32-c handshake also be extended to exchange the SEPP’s PLMN ID(s) ? Which PLMN ID should be used for a PLMN supporting multiple MNC? Jesus: In our view the discussion in SA3 is more tightly related to the CT4 CR in C4-204091 (for TS 29.509). The mechanism proposed in this CR (to 29.500) is applicable to such scenario (if SA3 agrees on the related CRs) but also to several other APIs where the receiving NF can use the proposed header to ensure that the PLMN info included by the sending NF is legitimate. Regarding the specific mechanism in N32, by which the SEPP checks the PLMN of the peer SEPP, I don't have a strong view, other than the SEPPS MUST know with what PLMN they are talking, since this is a requirement by SA3. If the N32 protocol, as of today, signals only FQDNs, and the MCC/MNC cannot be extracted from such FQDN, then we have several choices: either the receiving SEPP has mapping tables of "free-form" FQDNs to MCC/MNC's, or the MCC/MNC is explicitly signalled via N32 itself. Both are fine with me. Bruno: The SA3 CR specifies the new following reqts, which is exactly what C4-204089 specifies. So we see a dependency on the SA3 CR. Before sending the incoming N32-f message to the receiving NF, the receiving SEPP may include the PLMN ID of the related N32-f context from which the incoming N32-f message was received within the incoming N32-f message. This can be further used at the receiving NF as the remote PLMN ID asserted by the SEPP (e.g. for serving network name verification at AUSF). I don’t have any strong view either on how the receiving SEPP determines the PLMN of the remote SEPP. It’s not clear to me how PLMN ID assertion works for PLMN supporting several MNC. Which PLMN ID is signalled? Jesus I just checked with my SA3 colleagues, and the SA3 CRs will be discussed next week. The reason for saying that there is not such a clear dependency is that SA3 might decide to move forward with the CR on the basis on the specific requirement of the AUSF to check the SNN of the AMF. But that's only one use case among many. The proposed header in the CT4 CR can be used by any API that needs to check the validity of a PLMN-ID parameter in any incoming message. Regarding this: It’s not clear to me how PLMN ID assertion works for PLMN supporting several MNC. Which PLMN ID is signalled? I don't think that the scenario has been ever discussed, or considered, during the design of the N32 protocol. The requirement from SA3 is that SEPPs must know the PLMN-ID of the peer SEPP. So, one possibility is that whenever a SEPP needs to initiate a N32-c session, it does it with a specific PLMN-ID (MCC/MNC), corresponding to the signalling scenario in which the N32-c setup occurs. If eventually, the SEPP needs to convey traffic associated to a different MCC/MNC (in the same PLMN), it does it by setting up a different N32-c session. But, as said before, this multi-MNC scenario, to my knowledge, is not currently specified. CC Bruno no issue with defining a header. Caixia: discussion in SA3 is not limited to the AUSF. We need to follow the SA3 discussion.
4091	CR 29.509 0099 Rel-16 Serving Network Name	Ericsson	Agreed	WI SBIProtoc16 CAT F
4122	CR 29.501 0087 Rel-16 Naming requirements for resource/operation-level scopes	Nokia, Nokia Shanghai Bell	Agreed	WI SBIProtoc16 CAT F
4123	CR 29.505 0291 Rel-16 Security for Authentication Subscription Data	Nokia, Nokia Shanghai Bell	Agreed	WI SBIProtoc16 CAT F
CC5	4145	CR 29.501 0088 Rel-16 Data types with string type	Huawei	Revised to C4-204389	WI SBIProtoc16 CAT F Jones: We can agree on the motivation of the CR, but we disagree on the proposal. Normally string value should be handled by default as case sensitive, e.g. user names can be differed with different cases, folder names in some systems are case sensitive, credentials and security keys as sting are case sensitive, etc. String value could be case insensitive e.g.: Contain a string value of a data type, where the data type has been define as case insensitive, like DNN, FQDN, etc. Characters representing binary encoding, e.g. hexadecimal form of some binary ID The above scenarios are fitting for simple data types definition and they are commonly done in current specification. Thus, we suggest that string values should be case sensitive, unless explicitly specified otherwise Zhijun: From our point of view, whether string type is case sensitive or not, should be considered case by case. For example, for kinds of Identifier defined in 23.003, we should regard the value of these ID(s) are not case sensitive. Otherwise, it may easy cause interoperatability issues between different vendors' NF. For those string type IEs whose usage are restricted e.g. within the NF itself or within its NF Set, the string value may be case sensitive Ulrich: I also agree with Jones and Zhijun, especially as enums are considered to be strings and are case sensitive and also pattern matching is cases sensitive Caixia: Thank you for your valuable comments, I agree with you, we cannot simply define all of the string type are can insensitive. Let me summarize the comments from all of you, and we can discuss how to move forward on the revision. Case sensitive by default Case sensitive Case insensitive Jones Y Explicitly specified the IE is case insensitive in specifications. Zhijun String type IEs whose usage are restricted e.g. within the NF itself or within its NF Set, the string value may be case sensitive Explicitly specified the IE is case insensitive, e.g. 23.003 Ulrich enums are considered to be strings and are case sensitive and also pattern matching is cases sensitive Would be OK to revise the definition as below? Characters in a string data type specific for the API or common to multiple APIs shall be handled as below: Case sensitive Enumerations; String pattern matching defined is case sensitive; Case insensitive Explicitly specified the IE is case insensitive in specifications, e.g. TS 23.003; String pattern matching defined is case insensitive. Caixia: Draft V1 is available as below, based on the proposal in the last E-MAIL: https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.6/C4-204145_V1_SBIProtoc16%2029.501-Data%20type%20with%20string.docx Ulrich: string pattern matching is always case sensitive. If the intention is to make it case insensitive, we need to define the pattern accordingly, e.g. as in Autn: type: string pattern: '^[A-Fa-f0-9]{32}$' Jones: Additionally, enumerations are listed as separate data type, side by side with simple data type and structure data types Jesus: Let me jump in, after I discussed a bit with Jones about this topic. In our (E///) view, an API, based on JSON, should be by definition 100% case sensitive (as far as the API / protocol, is concerned). All these considerations about enums, patterns, etc.. are already part of the processing of JSON Schema, and we cannot override them. Then, the _business logic_ of a give application (after the API/JSON) has been deemed as correct, may consider the IE as case insensitive (e.g. a DNN, or whatever, I don't know). So, we would suggest to state clearly the distinction between the API definition (which is always case sensitive) and, as pointed out below, specific IEs on specific applications business logic, which may happen to be case insensitive, and this should be specified on a case by case basis. Caixia: May be a general question about this issue, is there any reference/specification for JSON defines the IEs shall be case sensitive? If there has definition, maybe we can refer to the reference/specification. Jesus: In RFC 8259 (JSON RFC), you can find such conclusion, although the text may be implicit. Chapter 7 "Strings", makes it clear that a JSON string is handled in the same way as in most programming languages (e.g. as in C); strings are compared based on their content (UTF-8 encoded, in this case), and therefore "foo" and "FOO" at totally different strings, with no hint whatsoever that these strings are supposed to be the same string. Then, in the OpenAPI spec, you can find: "All field names in the specification are case sensitive. This includes all fields that are used as keys in a map, except where explicitly noted that keys are case insensitive." So, basically, the same conclusion. In general, everything is case sensitive. The only example I could find of case-insensitive keys is the "headers" map in a Response Object in OpenAPI, but that's only because in HTTP, the headers are case insensitive (so not related to JSON, but to HTTP itself). Also note that this latter comment is about OpenAPI spec itself, not about the payload of messages exchanged over a given API instance. CC Strings are cased sensitive by default. Caixia: After offline checking, I am fine to define the string as can sensitive by default, please check the proposed text in draft v2. https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.6/C4-204145_V2_SBIProtoc16%2029.501-Data%20type%20with%20string.docx And one more question from my side, if we define the pattern of string like below, does it mean the IE is case insensitive? Pattern: '^[0-3][A-Fa-f0-9]{2}$'
4389	CR 29.501 0088 Rel-16 Data types with string type	Huawei	Agreed
4047	LS in N32-f Error Responses - Mapping	GSMA 5GIS	5GIS11_02 LS GSMA 5GIS to 3GPP CT4 N32f_ErrorTypes v3 To: CT4 CC: SA3 Contact: Rel- WI – Actions to CT4: GSMA 5GIS requests 3GPP CT4 group to consider these errors and provide responses to the following questions: What is the correct mapping for these error types? Do additional N32fErrorType values need to be assigned within TS 29.573 if the existing errors do not map to the currently defined enumerated types? Postponed to Agenda item: 7.1.6 Proposed treatment: provide feedback to GSMA on cause mapping and clarify in TS 29.573 if seen needed. See C4-204146
4146	CR 29.573 0040 Rel-16 N32f Error Type	Huawei	Revised to C4-204390	WI SBIProtoc16 CAT F Bruno: I suggest to strike from the reason for change the following text: "Telescopic FQDN not found Callback URL not found Action: Not clear about the error cases, shall be further discussed." I agree with your assessment, but we will report this in the reply LS. Few small editorials: "The integrity keys in the receiving SEPP have expired." "The encryption keys in the receiving SEPP have expired." "The encryption policy verification on the received N32-f message has failed" Caixia: Thank you, I am fine to update the reason for change and the also the editorials in the revision. Draft V1 is now available in the draft inbox, please kindly check whether other changes are needed. Bruno: V1 is fine by me. thanks
4390	CR 29.573 0040 Rel-16 N32f Error Type	Huawei
4147	LS out Rel-16 Reply LS on N32-f Error Responses – Mapping	Huawei	Revised to C4-204391	Bruno: Thanks for preparing the reply LS. "CT4 evaluates " -> has evaluated "For Telescopic FQDN not found and Callback URL not found errors, CT4 wants to know the detailed scenarios which leads to these errors.": Bruno I agree with your assessment that this is not applicable to N32, so it would be better to reply and explain so to GSMA. "has agreed to attached CR ": agreed the attached CR In the action, I suggest to strike " and provide feedback if other N32fErrorType values are needed. CT4 also asks GSMA FASG 5GIS to clarify the scenarios lead to the Telescopic FQDN not found and Callback URL errors." Caixia: I have updated the LS to Draft V1 and uploaded onto the server to give the reason why the Telescopic FQDN not found and Callback URL not found errors are not applicable to N32f, and also do other changes based on your comments. CC some rewording proposed by Bruno Caixia: I capture the comments during conference call into draft v2, please check whether other changes are needed. https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.6/C4-204147_V2_LS%20on%20reply%20LS%20on%20ErrorType.docx Bruno: Thanks, looks good to me.
4391	LS out Rel-16 Reply LS on N32-f Error Responses – Mapping	Huawei
4046	LS in N32-f Protection Policy IE Data-Type Mapping	GSMA 5GIS	Noted	5GIS11_01 LS GSMA 5GIS to 3GPP CT4 IEData-Type v3 To: CT4 CC: SA3 Contact: Rel- WI - Actions to CT4: GSMA 5GIS requests the 3GPP CT4 group to consider these Data-Type mapping guidelines and provide responses to the following questions: Are these guidelines correct, or are there alternative guidelines which can be given? Is it an objective for 3GPP to define the correct Data-Type for IEs? Postponed to Agenda item: 7.1.6 Proposed treatment: provide feedback to GSMA and clarify in TS29.573 if seen needed. See C4-204146
4148	LS out Rel-16 Reply LS on N32-f Protection Policy IE Data-Type Mapping	Huawei	Revised to C4-204392	Bruno: Thanks for preparing the draft response On the 1st point, I am fine to let SA3 answer, but it would be worth then updating TS 29.273 to either refer to precise guidelines specified in 33.501 or to document the GSMA/SA3 guidelines within TS 29.573. TS 29.573 & TS 33.501 seem a bit loosely defined and also not necessarily in line with each other: Table 6.1.5.3.5-1: Enumeration IeType Enumeration value Description "UEID" IE of type UE identity (e.g SUPI). "LOCATION" IE carrying location information. "KEY_MATERIAL" IE carrying keying material. "AUTHENTICATION_MATERIAL" IE carrying authentication material like authentication vectors and EAP payload. "AUTHORIZATION_TOKEN" IE carrying authorization Token "OTHER" IE carrying other data requiring encryption. "NONSENSITIVE" IE carrying information that are not sensitive. TS 33.501 13.2.3.2 Data-type encryption policy The SEPP shall contain an operator-controlled protection policy that specifies which types of data shall be encrypted. The data-types defined are the following: - Data of the type 'SUPI'; - Data of the type 'authentication vector'; - Data of the type 'location data'; - Data of the type 'cryptographic material'; - Data of the type 'authorization token'. So we could mention that CT4 intends to update TS 29.573 further with these guidelines or with a reference to 33.501, after getting the SA3 answer. On the 2nd point, the policy of which type of data shall be protected is up to roaming partners, but the categorisation of API IEs (i.e. the nature of the info carried by each attribute, e.g. location data, key material, authorization token, etc) should be unique and not operator specific. As a matter of fact, each SEPP vendor needs today to go through all APIs and categorize all message information elements into IE types, which can result in different implementations. So I understand why GSMA asks us whether this is something 3GPP intends to specify. On the other hand, specifying the data type for every IEs in 3GPP would require 3GPP to define how to do so, and extensive updates for all 5GC APIs (~115) in CT4 and other WGs (e.g. CT3, SA5), i.e. extensive work to do and maintain. I suggest to simply answer that there is no such work foreseen in the current 3GPP work plan. Caixia: Thank you for your comments. I have updated the answer to 1st and 2nd points accordingly, please check the v1 in inbox. CC Editorials from Bruno Caixia: Based on the discussion during conference call, the LS is updated to draft V2 as below: https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.6/C4-204148_V3_LS%20on%20reply%20LS%20on%20IE%20mapping.docx Bruno: Thanks, looks good to me.
4392	LS out Rel-16 Reply LS on N32-f Protection Policy IE Data-Type Mapping	Huawei
4149	CR 29.500 0149 Rel-16 API URI correction and template udpate	Huawei	withdrawn	WI SBIProtoc16 CAT F Contains a CR to 29.501 to be checked if the CR number is correctly requested.
4335	CR 29.501 0091 Rel-16 API URI correction and template udpate	Huawei	Revised to C4-204384	Same content as C4-204149 Abdessamad: I am OK with the CR, I am just wondering if clause 5.2.2 should also be corrected as follows? This is in order to be aligned with clauses 4.4.1 and 4.4.2. Resource URI: {apiRoot}/<apiName>/{<apiVersion>}/<apiSpecificResourceUriPart> Caixia: I am fine with your comment, clause 5.2.2 is updated accordingly, please check the draft V1 in inbox, thank you. Bruno: In clause 4.4.2, {custOpName} should also be corrected with “<>” (this is not a variable). Caixia: I have updated the {custOpName} with <> in draft V1, which is available in Inbox Abdessamad: 4335_v1 is OK for me, thank you !
4384	CR 29.501 0091 Rel-16 API URI correction and template udpate	Huawei
4201	CR 29.510 0377 Rel-16 NF Profile Retrieval procedure with NF Services Map	Nokia, Nokia Shanghai Bell	Agreed	WI SBIProtoc16 CAT F
4210	CR 29.505 0294 Rel-16 Corrections to default responses	Ericsson	Agreed	WI SBIProtoc16 CAT F
4212	CR 29.505 0295 Rel-16 Corrections to the Event Group Subscription	Ericsson	Agreed	WI SBIProtoc16 CAT F
4286	CR 29.501 0089 Rel-16 Content of Location header when TLS is used	Ericsson	WI SBIProtoc16 CAT F Yue 1) Does this only apply to Location header? 2) Is it a general requirement for all use cases of URI? Jesus: The general requirement is that, when TLS is used, the consumer NF must check the certificate of the producer NF, and validate it, so it needs to do that based on FQDN. The 2 main cases where this happens is when the consumer NF discover URIs of the producer NF via NRF (and there is already text covering that), and when new resources are created so the URI of the new resource is sent from the producer to the consumer in the location header. For other scenarios in which there might be dynamic URIs involved (e.g. in a callback URI provided by the consumer to the producer), I don't think that SA3 has put the same requirements, in terms of mutual authentication
CC3	4287	CR 29.510 0386 Rel-16 Default TCP Port	Ericsson	WI SBIProtoc16 CAT F Yue The problem concerned in this CR is understood. But we need to first discusse "are we really going to preclude the use of SRV query?" Currently I don't have a clear position on this, we need more time to study this internally Jesus: The use of SRV queries is not precluded; the intention of this CR is to make it clear that they (so far) should not be made _mandatory_ for all consumer NFs; the current text of the TS is not clear, but it might be interpreted (implicitly) as if the consumer NF must always be prepared to do DNS SRV queries (depending on what information it received in the NFProfile from the NRF). And if the consumer NF eventually does an SRV query, the overall behavior is underspecified in the TS, since the information received in the SRV record may contain, not only a port information, but also priority and weight, which the NRF TS does not say anything about. That's why we propose simply to not mention SRV queries at all (until the full behavior is properly specified). In the meantime, if an existing NF does an SRV query, that's fine, it will not become non-compliant as a result of this CR, but the usage of DNS SRV should not be required for all NFs. Yue: This CR says "if the ipEndPoints attribute does not contain a "port" attribute, it shall use the default HTTP port number". If there is no "port" attribute in the profile and the NF issues SRV query, then which port number should be used, default port number or which contained in the SRV result? Jesus: The proposal is to use default port number. This NOTE 5, in fact, does not even mention SRV queries/records (it only indirectly implies such possibility). But the consumer NF may perfectly resolve FQDN to IP address(es) based on A or AAAA queries/records. Bruno: we concur with the problem statement and proposed resolution. But you need to correct the proposed changes in the NOTE 5 which contradicts with the following reqts specified in NOTE 1, which give precedence to any addressing info at NF service level: NOTE 1: The NF Service Consumer shall construct the API URIs of the service using: - for intra-PLMN signalling: the FQDN and IP addresses related attributes present in the NF Service Profile, if any, otherwise the FQDN and IP addresses related attributes present in the NF Profile. - for inter-PLMN signalling: the FQDN present in the NF Service Profile, if any, otherwise the FQDN present in the NF Profile (see NOTE 3). So if an fqdn is provided on Service Level, it shall take priority over NF Profile IP address and not vice versa. Only if both fqdn and IP address ipEndPoints in the NF Service do not exist should the NF Profile IP address be used. Also we can clarify further the behaviour when -NF Profile has FQDN but not IP -NF Service: no FQDN, no IP but ipEndPoints include a "port" attribute to say explicitly that in this case the NF Profile level FQDN should be used in combination with the port acquired from the Service level ipEndPoints. CC Jesus comment s form Bruno are ok will take them on board. If an NF wants to use something different than the default port it must register in the NRF this has to be made more clear in the CR.
4306	CR 29.500 0163 Rel-16 Corrections on expressions based on ABNF	Huawei	Revised to C4-204410	WI SBIProtoc16 CAT F Bruno: Regarding the change proposed in clause 5.2.3.2.2, C4-204305 (Huawei, Rel-15) proposes a different/opposite correction, i.e. to add an OWS instead of modifying the example. We should align C4-204306 accordingly IMO Qingfen: Thanks for your spotting the inconsistency between revision in 4305 and 4306. I have already corrected the revision in 4306 to keep in line with that in 4305. And I also correct another revision error in clause 5.2.3.2.6 spotted by myself. The new draft v1 was uploaded on server, please see https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.6/draftv1-C4-204306-CR0163-SBIProtoc16-29500-Corrections%20on%20expressions%20based%20on%20ABNF-R16.docx
4410	CR 29.500 0163 Rel-16 Corrections on expressions based on ABNF	Huawei	Bruno: Regarding your 2nd change Corrected the changes in clasue 5.2.3.2.6, i.e. reverted the removing " scope = "other-service" / "callback" / "subscription-events", and changed parametername = "nfinst" / "nfset" / "nfservinst" / "nfserviceset" / "servname" / "scope" to parametername = "nfinst" / "nfset" / "nfservinst" / "nfserviceset" / "servname" / scope because scope is a parameter not a string. I think the original version of your CR was correct. scope is a parameter name/string used in the header, see the examples, e.g. EXAMPLE 6: Subscription request from one NF on behalf of another NF, with 2 binding indications: 3gpp-Sbi-Binding: bl= nf-set; nfset=set1.udmset.5gc.mnc012.mcc345; servname=nudm-ee;scope=subscription-events 3gpp-Sbi-Binding: bl= nf-set; nfset=set1.nefset.5gc.mnc012.mcc345; servname=nnef-event-exposure And it can take any of the value "other-service" / "callback" / "subscription-events"
4307	CR 29.501 0090 Rel-16 Miscellaneous corrections	Huawei	Revised to C4-204422	WI SBIProtoc16 CAT F Ulrich: in clause 5.3.3 curly quotes in version: ‘1.0.0’ shall be corrected Qingfen: Thanks for comments, it was taken onboard in draftv1, please see https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.6/drafv1-C4-204307-CR0090-SBIProtoc16-29501-Miscellaneous%20corrections-R16.docx
4422	CR 29.501 0090 Rel-16 Miscellaneous corrections	Huawei
4308	CR 29.503 0482 Rel-16 Corrections on reference of common data structures	Huawei	Revised to C4-204423	WI SBIProtoc16 CAT F Ulrich in resource URIs {apiVersion} should be replaced with <apiVersion>, not with v2. Qingfen: Thanks for your comment, I took them onboard in draftv1 which was uploaded on server, please see https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.6/draftv1-C4-204308-CR0482-SBIProtoc16-29503-Corrections%20on%20reference%20of%20common%20data%20structures-R16.docx
4423	CR 29.503 0482 Rel-16 Corrections on reference of common data structures	Huawei
4309	CR 29.504 0105 Rel-16 Corrections with regard to references	Huawei	Agreed	WI SBIProtoc16 CAT F
4310	CR 29.505 0298 Rel-16 Correct mismatches of definition between table and yaml	Huawei	Agreed	WI SBIProtoc16 CAT F
4317	CR 29.503 0484 Rel-16 Storage of YAML files in ETSI Forge	Huawei	Revised to C4-204415	WI SBIProtoc16 CAT F
4415	CR 29.503 0484 Rel-16 Storage of YAML files in ETSI Forge	Huawei
4318	CR 29.503 0485 Rel-16 Corrections on UPU	Huawei	Revised to C4-204424	WI SBIProtoc16 CAT F Ulrich: in 6.1.3.19.2 {apiVersion} should be replaced with <apiVersion>, not with v2 Qingfen Thanks for the comment, they was taken onboard in new revision draftv1, see https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.6/draftv1-C4-204318-CR0485-SBIProtoc16-29503-Corrections%20on%20UPU-R16.docx
4424	CR 29.503 0485 Rel-16 Corrections on UPU	Huawei
4319	CR 29.509 0105 Rel-16 Corrections on UPUProtection Service	Huawei	Agreed	WI SBIProtoc16 CAT F
4320	CR 29.544 0006 Rel-16 Miscellaneous corrections	Huawei	Revised to C4-204425	WI SBIProtoc16 CAT F Ulrich: Other comments says: This CR won’t introduce any impacts to the OpenAPI specification files. However there are impacts in A.2. Qingfen: Thanks for your comment, it was taken onboard in new revision draftv1, please see https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.6/draftv1-C4-204320-CR0006-SBIProtoc16-29544-Miscelaneous%20corrections-R16.docx
4425	CR 29.544 0006 Rel-16 Miscellaneous corrections	Huawei
4327	CR 29.503 0486 Rel-16 Miscellaneous corrections	Huawei	Agreed	WI SBIProtoc16 CAT F
7.1.7	CT aspects of optimisations on UE radio capability signalling	RACS
4069	CR 29.674 0005 Rel-16 Correction to DicEntryData Retrieval	Samsung, Ericsson	Agreed	WI RACS CAT F
4133	CR 29.673 0007 Rel-16 DicEntryId in DicEntryData	Nokia, Nokia Shanghai Bell	Agreed	WI RACS CAT F
4134	CR 29.673 0008 Rel-16 UE Radio Capability ID retrieval	Nokia, Nokia Shanghai Bell, Ericsson	Agreed	WI RACS CAT F
4135	CR 29.674 0006 Rel-16 UE Radio Capability ID retrieval	Nokia, Nokia Shanghai Bell, Ericsson	Agreed	WI RACS CAT F
4162	CR 29.673 0009 Rel-16 Optionality of ProblemDetails in TS29.673 cleanup	Huawei	Agreed	WI RACS CAT F
4280	CR 29.518 0400 Rel-16 Managing RACS ID for mobility across ePLMNs	Qualcomm Incorporated	WI RACS CAT F Caixia: The CR is depending on the related stage 2 CR as indicated in the coversheet. And I propose to add the stage2 reference in the NOTE Waqar: Thanks Caixia, please see the revision here with reference added to stage-2: https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.7/C4-204280_AMF_RACS_r1.docx Caixia: Thank you, I am fine with this version. Bruno: The reference is incomplete (put the right “x”): NOTE 1: If the AMF supports RACS, and the AMF detects that the selected PLMN in the Service Request is different from the currently registered PLMN for the UE, the AMF removes the plmnAssiUeRadioCapId in the MmContext, as specified in clause 4.2.3.2 of 3GPP TS 23.502 [x]. Also: This IE shall be present if the source AMF supports RACS feature and if available. When present it shall be the PLMN-assigned UE Radio Capability ID. See(NOTE 1)
4281	CR 29.274 1994 Rel-16 Managing RACS ID for mobility across ePLMNs	Qualcomm Incorporated	WI RACS CAT F Caixia: The CR is depending on the related stage 2 CR as indicated in the coversheet. And I propose to change the description to informative NOTE, and add the stage2 reference in the NOTE. There is changes over change in the contribution Waqar: Thanks Caixia for the comments, updated draft with changes incorporated is available here: https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.7/C4-204281_MME_RACS_r1.docx
7.1.8	CT aspect of single radio voice continuity from 5GS to 3G	5G_SRVCC
7.1.9	CT Aspects of 5G URLLC	5G_URLLC
CC2	4104	CR 29.244 0472 Rel-16 Correct IE Type of Redundant Transmission Parameters	ZTE	Revised to C4-204362	WI 5G_URLLC CAT F CR does not propose any change to table 8.1.2-1 would be needed for a new type value. Bruno: clause 8.1.2 should be updated accordingly (new entry to allocate a new code point). There is not any change to clause 7.5.2.2. This clause should be removed from the CR. Frank The CR may be fine, however, in my view, it is to improve the readability, but I don't think it can be a problem since they are different level in different group IE. If we go ahead the CR, while agreeing Bruno's comment - we should have a change in 8.1.2, to create a new IE type. I think it would be better to have a different name. We could also update the requirement, the requirement you have referred should only be applicable under the message level or in the same group IE. Do you agree? Zhijun: Existing principle in TS29.244 prefers having different IE types for even the same IE in different usages. And as these two IEs actually have different inner attributes, I agree that a different name should be better. If you agree, I will try to find better names to differentiate these two IEs. About the principle / requirement I referred, I am fine to update it if you have better wording, maybe in other CR. Caixia: Actually I also do not see the problem with the current IE definition. May be we can update the principle. CC: The intention of the CR is to improve the readability. Zhijun: I made v1 revision to the CR: - Update the principle of assigning IE type value for grouped IEs. It is suggested to not assign same IE type value to grouped IEs with different inner content. - Rename the existing two Redundant Transmission Parameters IEs, and assign new value for one of these IEs. Those two IEs are proposed to be renamed. please find v1 from the server: https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.9/C4-204104_v1_URLLC_29244_Redundent%20Transmission%20Parameters%20IE.docx
4362	CR 29.244 0472 Rel-16 Correct IE Type of Redundant Transmission Parameters	ZTE	Caixia: Thank you for the revision, two comments from my side. The table shall be updated: 255 Redundant Transmission Detection Parameters Extendable / Table 7.5.2.2-5, Table 7.5.2.3-4 2xx Redundent Transmission Forwarding Parameters Extendable / Table 7.5.2.2-5, Table 7.5.2.3-4 And as you change the IE name, 5.24.2.2 GTP-U tunnel setup for redundant transmission, shall also be updated to reflect the correct IE names. Bruno: Some editorials: If more than one grouped IEs of the same type, but for a different purpose are sent within the same message level, these IEs shall have different IE types. If more than one grouped IEs of the same type and for the same purpose are sent within the same message level, these IEs shall have exactly the same IE type to represent a list. Assigning the same IE type to grouped IEs which don’t have the same content is not recommended suggested, even if these grouped IEs are in different message levels. 2xx Redundent Transmission Forwarding Parameters Zhijun: Thanks,Got.
CC2	4105	CR 29.244 0473 Rel-16 Time Stamp in QoS Monitoring Report IE	ZTE	Revised to C4-204363	WI 5G_URLLC CAT F Define new time stamp or reuse Event time stamp? Caixia: Please check my comments below: Clause 7.4.5.1.4 Clock Drift Report IE within PFCP Node Report Request, there also have a IE named Time Stamp 2. Clause 7.4.5.1.5, GTP-U Path QoS Report IE within PFCP Node Report Request, already uses the Event Time Stamp IE for Time Stamp I propose to re-use the Event Time Stamp IE as we already used in GTP-U Path QoS Report IE, any how the description of the Event Time Stamp IE shall be updated. Zhijun: I am fine to either re-use existing IE, if there is no mis-leading, or define common Time Stamp IE for others to use. Let's see opinions of other people and then make decision which way to go. CC Check if reuse is inline with guideline in 7.3.4. Zhijun: Please find the v1 from the server. The "Event Time Stamp" is renamed to "Time Stamp" and description is updated correspondingly. To be noted that, the "Event Time Stamp" is not only used in "GTP-U Path QoS Report" IE, but also used in "Usage Report" IE. https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.9/C4-204105_v1_URLLC_29244_Time%20Stamp%20IE.docx
4363	CR 29.244 0473 Rel-16 Time Stamp in QoS Monitoring Report IE	ZTE
4179	CR 29.502 0371 Rel-16 QoS Monitoring Reporting Frequency	Huawei	Revised to C4-204393	WI 5G_URLLC, ETSUN CAT F Jones: What is the motivation to use DurationSecRm for the new attribute? Are we suppose that the report Period will be removed dynamically? Caixia: The information can be sent from PCF to SMF, in TS 29.512, PCF defines the DurationSecRm, so I propose to keep alignment between interfaces. Frank: Can "DurationSecRm" be null? When should it be set to "null" and what does this mean? And can " DurationSecRm" be "0", what does this mean? Any minimal value? I think, e.g. 1s, apparently will lead a lot of signaling traffic for monitoring reports… What is the status for TS 38.413 CR? Tdoc? Caixia: R3-204751 is the related RAN3 contribution to TS 38.413, which is being discussing in this RAN3 meeting. https://www.3gpp.org/ftp/tsg_ran/WG3_Iu/TSGR3_109-e/Docs For the value part, may be it is better to refer the definition in TS 38.413. And for the DurationSecRm, null value normally means to remove the DurationSec. If you do not think the null is needed, I am fine to change the type to DurationSec. Bruno: How does the anchor SMF indicate that QoS monitoring is no longer required (and therefore that reporting period is also no longer applicable)? qosMonitoringReq: This IE may be present to indicate the measurement of UL, or DL, or both UL/DL delays for the associated QoS flow. See clause 9.3.1.12 of 3GPP TS 38.413 [9]. repPeriod: This IE may be present to indicate the reporting period. See clause 9.3.1.12 of 3GPP TS 38.413 [9]. 29.502: Table 6.1.6.2.20-1: Definition of type QosFlowAddModifyRequestItem qosFlowProfile: When present, this IE shall contain the description of the QoS Flow level QoS parameters. When modifying a QoS flow, the IE shall only contain the QoS Flow profile's attributes which are modified Which period does the RAN use if the reporting period is not signalled, a default period configured in the RAN? By the way, TS title is not correct on the cover page. Caixia: My RAN3 colleague told me, RAN will not support the report frequency IE in R3-204751, and the related contribution to send the period from SMF to I-SMF is not needed. NG-RAN may left to implementation to decide the period or retrieve from other function, e.g. MDT? And about how to indicate the QoS Monitoring is no longer required, my assumption is if the qosMonitoringReq is not sent to NG-RAN, it means the QoS monitoring shall be stopped. Based on this feedback, I may revise the contribution to remove the EN only: Editor's note: It is FFS how to support the QoS Monitoring Reporting Frequency on N16a for QoS Flow QoS Monitoring, the QoS monitoring policy and QoS Monitoring Result on N16a for GTP-U Path QoS Monitoring. In addition, for GTP-U Path QoS Monitoring, I am not sure about the status in RAN3, do you have any information, e.g. will RAN3 support this function in R16? Is it OK to remove the entire EN in the revision? Bruno: Thanks for the information. Does this mean RAN3 will report this to SA2 to align stage 2? My question was how to stop QoS monitoring over N16/N16a? Table 6.1.6.2.20-1: Definition of type QosFlowAddModifyRequestItem QosFlowProfile When present, this IE shall contain the description of the QoS Flow level QoS parameters. When modifying a QoS flow, the IE shall only contain the QoS Flow profile's attributes which are modified. We should keep the editor’s note on N16a for GTP-U Path QoS Monitoring. I intend to contribute at the next meeting. Caixia: I will check with our RAN3 colleague, whether they will report to SA2. For time being, we can keep the EN, and decide how to handle this in next meeting. N16/N16a, I think we need to enhance to support the stop of QoS Monitoring. May be we can add a stop indication in qosFlowProfile, or add a enum in QosMonitoringReq. If you are fine with this, I can capture this in the revision. Caixia: The contribution is revised to stop the QoS monitoring in NG-RAN: https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.9/C4-204179_V1_URLLC%2029.502-QoS%20Monitoring.docx Bruno: A possible alternative to request to stop QoS monitoring for a QoS flow could be to define a new enumeration value 6.1.6.3.21 Enumeration: QosMonitoringReq The enumeration QosMonitoringReq indicates the measurement of UL, or DL, or both UL/DL delays. Table 6.1.6.3.21-1: Enumeration QosMonitoringReq “NONE” No measurements are required. This value shall be used to stop on-going UL and/or DL measurements. Then we don’t need to define a new attribute. Caixia: Thank you, I am fine with this proposal, will revise the contribution to capture this
4393	CR 29.502 0371 Rel-16 QoS Monitoring Reporting Frequency	Huawei
4180	CR 29.502 0372 Rel-16 Dynamic CN PDB	Huawei	withdrawn	WI 5G_URLLC, ETSUN, 5WWC CAT F
4036	LS in Rel-16 Reply LS on Stage 3 for V2X QoS	SA2	Noted	S2-2004445 To: RAN3, CT3, CT4 CC: Contact: Vodafone Rel-16 WI: 5G_V2X_NRSL / eV2XARC SA 2 thanks RAN 3 for informing them of their Working Assumption (WA) to proceed with stage 3 design as shown in the Text Proposals attached to their LS SA 2 have discussed the topic and agreed to change the SA2 specifications to align with the QoS attributes in the endorsed RAN3 CRs attached to the received incoming LS. However, SA2 believes that it is important that the NG-RAN shall enable the SMF to determine that the gNB supports the feature but cannot fulfill even the least preferred Alternative QoS Profile. Attached CR is agreed to capture this feature. ACTION: SA 2 respectfully ask RAN 3 to add the above to their Text Proposals/CRs. Remarks in last meeting Related to CRs on alternative QoS profiles We may need to do a final checking until next meeting. Postponed to Agenda item: 7.1.9 Bruno: Related CR is provided in C4-204198
4198	CR 29.502 0374 Rel-16 Indicating that NG-RAN cannot fulfil the least preferred Alternative QoS Profile	Nokia, Nokia Shanghai Bell	Agreed	WI 5G_URLLC, eV2XARC, ETSUN CAT F Caixia: In principle I am fine with the contribution, just one question, is it backward compatible change to update the currentQosProfileIndex from O to C? Bruno: Yes, this is backward compatible. The CR covers the case where no alternative QoS profile is met. In such a case, the existing version of the spec says that the currentQosProfileIndex is not included. And this is also what the CR still says, the CR only adding a new attribute in this scenario (nullQoSProfileIndex).
4298	CR 29.571 0236 Rel-16 Dynamic CN PDB	Huawei	Revised to C4-204394	WI 5G_URLLC, ETSUN, 5WWC CAT F Bruno I assume that packetDelayBudget (that is a mandatory attribute) shall be ignored (in reception) if extPacketDelBudget is supported and also present, right? if so, this should be specified explicitly. Caixia: You are right, if the extPacketDelBudget is present, the packetDelayBudget shall be ignored. I will modify the description to make a clear statement. Caixia: The following NOTE 3 is added into the draft v1, which is uploaded onto the server, please double check. NOTE 3: Unless specified otherwise in an API: if both the packetDelayBudget IE and the extPacketDelBudget IE are received, the value in the extPacketDelBudget IE shall be used if the receiver supports ExtPacketDelBudget data type, otherwise the value in the packetDelayBudget IE shall be used. Bruno: Thanks, V1 is fine by me.
4394	CR 29.571 0236 Rel-16 Dynamic CN PDB	Huawei
7.1.10	SBA interactions between IMS and 5GC	eIMS5G_SBA
4009	CR 29.562 0021 Rel-16 P-CSCF restoration	Nokia, Nokia Shanghai Bell	WI eIMS5G_SBA CAT F Jesus We support the principle of the CR. However, we wondered whether it would be easier to simply extend the enum imsRegistrationType with a new value for P-CSCF restoration, since the intention of this notification is to de-register the user AND notify MME so that the UE registers again in IMS. Having a separate flag might lead to the user being de-registered in IMS but without the guarantee of forcing the user to register again. What's your view on this approach? Ulrich: I actually prefer to align with Cx where a separate flag is used in addition to Server-Assignment-Type ( corresponds to imsRegistrationType) ; see 29.229 clause 6.3.63 6.3.63 SAR-Flags The SAR-Flags AVP is of type Unsigned32 and it contains a bit mask. The meaning of the bits is defined in the following table: Table 6.3.63.1: SAR-Flags Bit Name Description 0 P-CSCF Restoration Indication This bit, when set, indicates that the P-CSCF-Restoration-mechanism feature shall be executed, as described in 3GPP TS 23.380 [24], clause 5.4. This AVP is optionally present only when Server-Assignment-Type takes the value ADMINISTRATIVE_DEREGISTRATION or UNREGISTERED_USER. Note: Bits not defined in this table shall be cleared by the sending S-CSCF and discarded by the receiving HSS. Furthermore it is clearly specified in 23.380 (see clause 5.8.4.3) that the procedure results in re-registration of the UE towards a new P-CSCF. Jesus: Thanks for the feedback, Ulrich. That's ok. We are also fine with such approach and can accept the CR as is.
CC2	4085	CR 29.510 0370 Rel-16 HSS NF Profile Update	Ericsson	WI eIMS5G_SBA CAT F Ulrich: in my understanding the proposed change in A.2 imsiRanges: type: array items: $ref: '#/components/schemas/ImsiRange' minItems: 1 is not backwards compatible. This should be reflected on the cover page. Jesus: This type of problems has been discussed extensively in the past and we normally say that this is a backwards-compatible (BC) change, for these reasons: Table 6.1.6.2.57-1 shows that the correct name of the attribute should be "imsiRanges", based on the Attribute Name and Description columns, that mention that this is a range of IMSI's; so, in the past, this misalignment due to clear typos are always categorized as BC The attribute is optional, meaning that this change is equivalent to removing an old optional attribute "imsRanges" and introducing a new optional attribute called "imsiRanges", both BC operations. The old OpenAPI text basically says "if there is ever an attribute called imsRanges, its schema must comply with following definition…"; but it does not force the presence of such attribute in the HssInfo object. CC Ulrich agrees in principle but would not like see this as something general to accept we need to discuss these kind of errors case by case. Farni I am just wondering, what would be the new version of the Nnrf_NFManagement API? Currently it is info: version: '1.1.0' title: 'NRF NFManagement Service' Jesus: If the correction is marked as BC, the next version would be 1.1.1 If the correction is marked as NBC, it would be 2.0.0
4090	CR 29.562 0022 Rel-16 Missing Resource Scopes	Ericsson	Agreed	WI eIMS5G_SBA CAT F
CC5	4203	CR 29.510 0378 Rel-16 Missing NF types for SBA interactions between IMS and 5GC	Nokia, Nokia Shanghai Bell	WI eIMS5G_SBA CAT F Yue: I have a general question, did we agree on that for each possible consumer of 5G APIs a corresponding NF type shall be defined? Bruno: the NF type of a consumer is signalled in different headers or IEs, e.g. in the User Agent header. See 29.500: User-Agent: This header shall be mainly used to identify the NF type of the HTTP/2 client. The pattern of the content should start with the value of NF type (e.g. udm, see NOTE 1) and followed by a "-" and any other specific information if needed afterwards In an access token request In an discovery request or subscription request In a binding header (in subscription request) So yes, NF type values should be defined for all known consumer types. Yue: Then does it mean all the 5GC APIs that we have defined can ONLY be invoked by entities whoes "type" has also been defined in 29.510? Isn't there a fundamental assumption, when developing SBA, that the 5G services can be reused by any possible consumers? Bruno: NFType is defined as extendable, so it does allow to convey by any consumers. But for all 3GPP NF types, a specific enumeration value is defined. CC We have defined NF type for each 3GPP NF consumer this is mandated by our protocol.
4290	CR 29.562 0023 Rel-16 IMS restoration amendments II	Huawei, HiSilicon	WI eIMS5G_SBA CAT F Anders: In 29.228, Table 6.1.2.2: S-CSCF registration/deregistration notification response, there is an Associated-Identities AVP and an Associated-Registered-Identities AVP described, where, according to the description, the Associated-Registered-Identities AVP is applicable for IMS Restoration Procedures. Would it make sense that 29.562 be aligned with 29.228, i.e. having both associatedImpis (as it is defined now) and a (new) assocatedRegisteredImpis as well? Bill Many thanks for your review and suggestion. I’m fine with having both. Please check the draft revision at the following link: https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.10/C4-204290_r1_Rel-16_29562_CR0023%20IMS%20restoration%20amendments%20II.docx
4291	CR 29.562 0024 Rel-16 Miscellaneous Corrections	Huawei, HiSilicon	Agreed	WI eIMS5G_SBA CAT F Consequences if not approved room for improvement
7.1.11	Load and Overload Control of 5GC Service Based Interfaces	LOLC
4202	CR 29.500 0156 Rel-16 3gpp-Sbi-Oci and 3gpp-Sbi-Lci headers	Nokia, Nokia Shanghai Bell	Agreed	WI LOLC CAT F
7.1.12	5GS Enhanced support of OTA mechanism for configuration parameter update	5GS_OTAF
7.1.13	CT aspects of support for integrated access and backhaul	IABARC-CT
7.1.14	Nudsf Service Based Interface	NUDSF
4160	CR 29.598 0010 Rel-16 Optionality of ProblemDetails in TS29.598 cleanup	Huawei	Agreed	WI NUDSF CAT F
7.1.15	Nsoraf Service Based Interface	NSORAF
CC2	4313	CR 29.503 0483 Rel-16 Corrections on 5G SoR	Huawei	Revised to C4-204411	WI NSORAF CAT F Varini: We agree with the support of “403 Forbidden” error for a detached UE as it will avoid unnecessary messages from SORAF for a detached UE. I would like to request for clarification on following changes: Clause 5.6.2.2.4 : The CR proposes that if, post initial registration, SORAF wants to send updated SoR information to UE, depending on value of flag “sorInfoExpectInd” in UE subscription, UDM may send it. My reading of 23.122 is different. 23.122 specifies that during initial registration it is optional for UDM to include the SoR information depending on setting of above variable. UDM, in such case won’t even request SORAF to provide SoR information. If SORAF wants to send SoR information to UE later, UDM should always send it. I am not sure if there is any scenario in which you would want UDM to NOT send the SoR information that SORAF is recommending? Clause 6.1.6.2.4: Change in description of variable “sorInfoExpectInd” indicates that UDM may send “No change” indication if this variable is set to false. I don’t think this is correct. During initial registration, not sending SoR Info is as good as no change? Abdessamad: Please find below some comments on my side. The only part of this CR that I agree on is the addition of the error code 403. Most of the remaining changes are not necessary and even go against what was defined in stage 2 in Annex C of 3GPP TS 23.122. In this sense: I fully agree with Varini on his point 1 below regarding the changes in clause 5.6.2.2.4. There is absolutely no dependency on the value of the sorInfoExpectInd in this case. This attribute is only used for the “during registration” use case and shall not be used in the “after registration” use case. I propose hence to revert all the changes in this clause, except the change on the figure and the addition of the 403 error code (2b). In 6.1.6.2.4, the changes to sorInfo attribute description should also be reverted in my opinion as sorInfo is sent within the AccessAndMobilitySubscriptionData only in the “during registration” case (i.e. sent within ppData in the “after registration” case). Otherwise, there will be a misalignment with stage 2. Also 6.1.6.2.4, I can agree on the changes to sorInfoExpectInd attribute description, but I don’t see why an operator would send a no change indication if the UE is not expecting to receive SoR during initial registration. In this sense, I also agree with Varini’s second comment below. Also 6.1.6.2.4, the changes to sorafRetrieval attribute description are OK for me. Also 6.1.6.2.4, related to the changes to sorUpdateIndicatorList attribute description, I don’t see why we would make the sending of this attribute dependent on whether or not the UE in expecting SoR information during registration. This is not correct as per stage 2 again. I propose hence to revert this change. Hiroshi: I support the views from Varini and Abdessamad, and the proposals made in the thread. CC Qingfen ok with all the comments Qingfen: Thanks for all your comments, I accept all of them, and take them onboard in new draft v1. Draft v1 was uploaded in server, please see https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.15/draftv1-C4-204313-CR0483-NSORAF-29503-Corrections%20on%205G%20SoR-R16.docx Abdessamad: 2313_v1 is OK for me. Many thanks for taking onboard our comments Hiroshi: Thank you for sharing, and is fine also from my side Varini: Thanks. The draft looks fine to me.
4411	CR 29.503 0483 Rel-16 Corrections on 5G SoR	Huawei
4314	CR 29.509 0104 Rel-16 Corrections on SoRProtection service	Huawei	WI NSORAF CAT F
4315	CR 29.550 0012 Rel-16 Miscellaneous Corrections	Huawei	WI NSORAF CAT F
7.2	CT4 Supported WIs
7.2.1	CT aspects on Enablers for Network Automation for 5G	eNA
7.2.2	CT aspects of Access Traffic Steering, Switch and Splitting support in 5G system	ATSSS
7.2.3	CT aspects of 5GS enhanced support of vertical and LAN services	Vertical_LAN
4023	CR 29.244 0469 Rel-16 Editor's note on Bridge name	HuaWei	Merged into 4196	WI Vertical_LAN CAT F Clash with C4-204196, C4-204209 Is there a stage 2 CR to the ongoing SA2 meeting? Bruno: This CR overlaps with Nokia CR (C4-204196). The Huawei CR does actually not contain any change. Cover page also refers to a stage 2 CR whose reference is not provided. I suggest to mark this CR as merged into C4-204196, with Huawei added as co-source in a revision of the latter. Is this agreeable to you?
4196	CR 29.244 0477 Rel-16 Editor's Note on TSN Bridge Name	Nokia, Nokia Shanghai Bell	Revised to C4-204464	WI Vertical_LAN CAT F Clash with C4-204023, C4-204209
4464	CR 29.244 0477 Rel-16 Editor's Note on TSN Bridge Name	Nokia, Nokia Shanghai Bell, Huawei
4209	CR 29.244 0481 Rel-16 Clarification regarding Bridge ID	Intel /Thomas	WI Vertical_LAN CAT F Clash with C4-204196, C4-204023 Frank: It seems true that in the previous SA2 meeting the Bridge ID was moved inside the container. On the other hand, this change has not yet been implemented in a consistent way in the spec. If you search on Bridge ID in 23.502, you will still find a few occurrences, e.g. in F.1. So, the current situation is that this is inconsistent in the SA2 specs. I would rather wait for the outcome of this SA2 meeting. If you have an SA2 accompany CR, please let us know. My personal preference would be to keep the Bridge ID outside the container. Having such a Bridge ID outside the container could be helpful for the future e.g. in cases when a single physical UPF supports multiple virtual bridge instances. At least, I don't really see the harm. Bruno: TS 23.501 specifies that Bridge ID is used to distinguish between bridge instances within 5GS, so the SMF needs to be aware of the Bridge ID returned by the UPF to be able to handle subsequent PCF/TSN-AF requests targeting this Bridge ID. Accordingly, the Bridge ID needs to be signalled (also) outside of the BMIC container over N4, as currently defined in TS 29.244 TS23.501 clause 5.28.1: ”The granularity of the 5GS TSN bridge is per UPF. The bridge ID of the 5GS TSN bridge is bound to the UPF ID of the UPF as identified in TS 23.502 [3].” and further: “Information for 5GS Bridge: Bridge ID Bridge ID is to distinguish between bridge instances within 5GS. The Bridge ID can be derived from the unique bridge MAC address as described in IEEE 802.1Q [98], or set by implementation specific means ensuring that unique values are used within 5GS;” TS23.502 clause 4.3.2.2.1: “20. If the UE has indicated support of transferring Port Management Information Containers, then SMF informs PCF that a manageable Ethernet port has been detected. SMF also includes the port number of the DS-TT Ethernet port, port numbers of the serving NW-TT Ethernet port(s), MAC address of the DS-TT Ethernet port, 5GS Bridge ID, Port Management Information Container and UE-DS-TT Residence Time as provided by the UE.” The TS 23.502 Annex F.1 defines for PDU Session Establishment procedure: “1. …During this procedure, the SMF receives the UE-DS-TT residence time, DS-TT MAC address for this PDU Session and port management capabilities from the DS-TT/UE in PDU Session Establishment request, and receives the allocated port number for DS-TT Ethernet port, port number(s) for the serving NW-TT Ethernet port(s) and Bridge ID in N4 Session Establishment Response message. The UPF allocates the port number for DS-TT and decides port number for NW-TT, Bridge ID after receiving N4 Session Establishment Request message. 2. The SMF sends the information received in step 1 to the TSN AF via PCF to establish/modify the 5GS Bridge. The TSN AF stores the binding relationship between 5GS Bridge ID, MAC address of the DS-TT Ethernet port, the port number of the DS-TT Ethernet port, port numbers of NW-TT Ethernet ports for the 5GS Bridge and also updates 5GS bridge delay as defined in clause 5.27.5 of TS 23.501 [2] for future configuration.” Based on these the SMF (and PCF) need to know the 5GS Bridge ID (also part of SMF constructed 5GS bridge information). Even the TSN AF holds the binding relationship between the Bridge ID and other information of the TSN stream and is able to communicate with bridge/NW-TT via the BMIC, the SMF would not be able to select the correct bridge to handle the request and route the BMIC to correct bridge/NW-TT. So I do not agree with the proposed changes, apart from the one removing the Editor’s Note on the Bridge Name which is covered already by C4-204196. I propose to produce a revision of C4-204196 and add Intel and Huawei, if agreeable to all.
4071	CR 29.244 0470 Rel-16 Editor's note on multiple NW-TT ports	HuaWei	merged	WI Vertical_LAN CAT F Clash with C4-204197 Zhijun: It clashes with C4-204197, and I think the change in 4197 is better, as the NW-TT port is not PDU session specific. Proposed to be marked as merged into C4-204197 Bruno: thanks for your comments. yes, this is fine and I will produce a revision of C4-204197 with Huawei added as co-source.
4197	CR 29.244 0478 Rel-16 Editor's Note on NW-TT ports	Nokia, Nokia Shanghai Bell	Revised to C4-204465	WI Vertical_LAN CAT F Clash with C4-204071 To be revised to add Huawei as co-source company Frank: I also think 4197 is better. In the revision, you need re-number the note. In addition, there is ongoing discussion in SA2 (CR23.502-2337), proposing some changes in F.1 of 23.502, removing allocates ports for NW-TT, as they are common for PDU sessions. We may keep the revision of 4197 open, see if we can adapt the SA2 change. Possible dependency with a stage 2 CR.
4465	CR 29.244 0478 Rel-16 Editor's Note on NW-TT ports	Nokia, Nokia Shanghai Bell Huawei
4081	CR 29.503 0465 Rel-16 DN-AAA secondary authentication	Ericsson	WI Vertical_LAN CAT F Yue Is it proper that this CR uses work item "Vertical_LAN"? I mean, is it triggered by certain vertical LAN requirement? If yes, what's the difference from those attributes defined in "5GVnGroupData" data type? [Maria Liang] Yes, this CR still belong to the work item “Vertical_LAN” to enable the UDM to notify the SMF on the 2nd Auth and DNAAA address originally provisioned by AF via NEF to UDM, still need this CR with N10 i/f notify SMF to trigger SMF enforcement of Subscription based action, including 2nd auth and use the AF provisioned DNAAA address instead of SMF local configured DN AAA server address. The difference from those attributes defined in “5GVnGroupData”data type mainly upon different OpenAPI in different CR, ie. 5GVnGroupData type is used in Nudm_PP API, while DnnConfiguration Type in used in Numd_SDM API to transfer these parameters to the actual receiver, i.e. SMF to initiate 5GLAN wanted 2nd Auth to the AF provisioning DN AAA server. See e2e in TS 23.502 , clause 4.15.6.2 flow procedures more clearly. If e.g. "secondaryAuth" presents in both "5GVnGroupData" and "DnnConfiguration", then which one take precedence? [Maria Liang] For the Nudm service, The relationship is not PK precedence, but input then output consistently. Ie. "5GVnGroupData" as the provision input from NEF in Numd_PP API vs. “DnnConfiguration” as the Subscription data output to SMF in Nudm_SDM API Jesus Sorry for the slow reply but I wanted to double check some details with my CT3 colleagues. See below comments (from my CT3 colleague Maria Liang), please. One additional aspect that I discussed with my CT3 colleagues, and forgot to comment, is that there is a misalignment between how 5GVnGroupData defines the attribute "secondaryAuth" (in which the default value false is equivalent to absent) and how it is defined in the DnnConfiguration (in which: true / false / absent, have distinct meaning). In our view, per stage-2 reqs, the correct interpretation is the latter (as in DnnConfiguration definition proposed in this CR). If people agree, I'd suggest to align in this CR the definition of secondaryAuth in 5GVnGroupData (to remove the default setting, and have the same interpretation of absence as in DnnConfiguration). Any views? Jesus I have updated the CR to include the change commented below, regarding the alignment of 5GVnGroupData and DnnConfiguration, for the "secondaryAuth" attribute. Find it available here: https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.2.3/draft-C4-204081-DN-AAA-29503-v1.docx Please let me know you have further comments. Zhijun Thanks for the v1 update. Just one thing in my mind: as there are twice copy of DN authorizatio info and AAA Server information there, in th 5GVnGroupData and DnnConfiguration data, do we need to address in some place that operators should keep these attributes aligned together? Otherwise, it may case unpredictable issues. Jesus: I think that your concern is addressed in my response to bullet 2) from Yue, above. If e.g. "secondaryAuth" presents in both "5GVnGroupData" and "DnnConfiguration", then which one take precedence? [Maria Liang] For the Nudm service, The relationship is not PK precedence, but input then output consistently. Ie. "5GVnGroupData" as the provision input from NEF in Numd_PP API vs.“DnnConfiguration” as theSubscription data output to SMF in Nudm_SDM API So, the information that NEF configures in UDM via Nudm_PP should be made available to the subscribing SMF via notifications, as indicated in TS 23.502: Figure was providedin email Figure 4.15.6.2-1: Nnef_ParameterProvision_Create / Nnef_ParameterProvision_Update / Nnef_ParameterProvision_Delete request/response operations Zhijun: Thanks for your response. Yes, I saw the explaination and I agree it is correct. What I mean is, whether we need additional explaination to the newly added attribute, e.g. a NOTE, to say that the configuration in DnnConfiguration shall be consistent with that in the 5GVnGroupData Jesus If you have a suggestion about where to put such clarification, and what text do you expect, maybe we can give it a try. But, in principle, I think it should be enough with the stage-2 signaling flows and requirements. Zhijun: How about this NOTE? Just an example. It is used to ease potential confusion to people on such configuration in different places. NOTE X: If the configuration to secondary authentication and authorization also appears in 5GVnGroupData, consistence shall be taken in different places. Added to: secondaryAuth and dnAaaAddress
4084	CR 29.503 0466 Rel-16 Providing configured human-readable readable name for CAG-ID	Ericsson	WI Vertical_LAN CAT F Zhijun: Typos in CR coversheet: human-readable readable name --> human-readable network name. [Jesus] Thanks I have corrected them. Some question for clarification / comments: - TS23.501 defined the HRNN may be associated to one NID, or a CAG ID. This CR only covers the HRNN associated to CAG ID. Is their any intention to cover the other one? Jesus] The CR only addresses HRNN for CAG-ID. UE configuration for SNPN (including HRNN for SNPN) is out of scope of 3GPP in this release of the specification, according to 23.122 subclause 4.9.3.0 NOTE 3. - Common understanding is one CAG ID is only associated to one HRNN. But using the array(CAG ID, HRNN) it allows duplicated records to one CAG ID with different HRNNs. [Jesus] A particular CAG-ID should be included in the list at maximum once. I have gone with the proposal from Ulrich to make this a map, instead of an array, which enforces the case of only 1 HRNN per CAG Id May be additional description is needed here to remove the misleading. Ulrich in 6.1.6.2.37 the new attribute cagHrnnList is an array but should better be a map as it maps cagId to hrnn. Jesus: Please see my comments above, and find a draft revision uploaded here: https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.2.3/draft-C4-204084-HRNN-for-CAG-ID-29503-v1.doc Zhijun: It looks good. Ulrich thank you for the revision. Would it make sense to: -replace in table 6.1.6.1-1 CagIdHrnn 6.1.6.2.x CAG Id to HRNN mapping With CagHrnn 6.1.6.2.x CAG Human Readable Networkname -replace in table 6.1.6.2.37-1 cagIdHrnnList map(CagIdHrnn) O 1..N A map of CAG Id to HRNN mappings, where the CagId string value (see 3GPP TS 29.571 [7], Table 5.3.2-1) serves as a key of the map. With cagHrnnList map(CagHrnn) O 1..N A map (list of key-value pairs where CagId (see 3GPP TS 29.571 [7]) serves as key) of CAG Human Readable Network Names. -replace 6.1.6.2.x Type: CagIdHrnn Table 6.1.6.2.x-1: Definition of type CagIdHrnn Attribute name Data type P Cardinality Description hrnn string M 1 Human-readable network name for a certain CAG Id With 6.1.6.2.x Type: CagHrnn Table 6.1.6.2.x-1: Definition of type CagHrnn Attribute name Data type P Cardinality Description hrnn string M 1 Human-readable network name -replace cagIdHrnnList: type: object additionalProperties: $ref: '#/components/schemas/CagIdHrnn' minProperties: 1 CagIdHrnn: type: object required: - hrnn properties: hrnn: type: string with cagHrnnList: description: A map (list of key-value pairs where CagId serves as key) of CagHrnn type: object additionalProperties: $ref: '#/components/schemas/CagHrnn' minProperties: 1 CagHrnn: type: object required: - hrnn properties: hrnn: type: string Use array or map? Ulrich proposed twice Jesus: I agree, and I have taken onboard all your comments. Find the v2 version here: https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.2.3/draft-C4-204084-HRNN-for-CAG-ID-29503-v2.doc Ulrichj: v2 looks good.
4282	CR 23.003 0595 Rel-16 Adding definition for HRNN	Qualcomm Incorporated, Deutsche Telekom	Agreed	WI Vertical_LAN CAT F
7.2.4	CT aspects of Cellular IoT support and evolution for the 5G System	5G_CIoT
CC2	4152	CR 29.244 0474 Rel-16 Small data rate control and Serving PLMN rate control	Huawei	Revised to C4-204395	WI 5G_CIoT CAT F Bruno; In clause 5.4.15.3, I don't agree with the new bullet for Serving PLMN rate control: "the QER shall be associated to all the DL PDRs of all the PDN connections/PDU sessions of the UE to the same PLMN, using the QER Correlation ID (see clause 5.2.1)". Serving PLMN rate control is per PDU session. See 23.501 5.31.14.2 “ -The UE shall limit the rate at which it generates uplink NAS Data PDUs to comply with the Serving PLMN policy. In the UE the indicated rate control applies only on the PDU Session where it was received, and therefore the UE shall limit the rate of its uplink NAS Data PDUs to comply with the rate that is indicated for the PDU Session. The indicated rate is valid until the PDU Session is released. -The UPF/NEF shall limit the rate at which it generates downlink Data PDUs. In the UPF/NEF the indicated rate control applies only on the PDU Session where it was received, and therefore the UPF/NEF shall limit the rate of its downlink Data PDUs to comply with the rate that is indicated for the PDU Session. “ 7.5.2.5: we need accordingly to revert "or for serving PLMN rate control of multiple UE's PDN connections/PDU sessions to the same PLMN." 8.2.63: I don’t think we need the proposed changes, this should be transparent to the UPF. This can be at most captured as an informative note. Frank: I concur Bruno's comments. In addition, the following new sentence is ambiguous: " If both Serving PLMN rate control and Small Data Rate Control are applied in 5GS, or both Serving PLMN rate control and APN rate control are applied in EPS, the SMF/PGW-C shall control packet rate enforcement in the UP function by provisioning different QERs for Serving PLMN rate control and for Small Data Rate Control/APN rate control, and by associating DL PDRs to both of the QER(s). " e.g. for PSA UPF in home, I don't think it is required to enforce Serving PLMN rate, no QER for that. Stage 2 has a note, "" NOTE 3 It is assumed that the Serving PLMN Rate is sufficiently high to not interfere with the Small Data Rate Control as the Small Data Rate Control, if used, is assumed to allow fewer messages. " " Communicate Serving PLMN rate to hSmf lets home PLMN knows when provision small data/APN rate, it seems sufficient to apply small date rate or APN rate in the PSA UPF. Even for non-roaming case, whether/why a UPF can receive QERs corresponding to Serving PLMN rate control and for Small Data Rate Control/APN rate control at the same time? Caixia: Thank you for your valuable comments. I am fine to change the Serving PLMN rate control per PLMN to per PDU session, we may have misunderstanding on the mechanism. It is not clear if both the Serving PLMN rate control and Small Data Rate Control applied, how to notify the UPF by the SMF. Serving PLMN rate control: Serving PLMN Rate Control is intended to allow the Serving PLMN to protect its AMF and the Signalling Radio Bearers in the NG-RAN from the load generated by NAS Data PDUs. Serving PLMN Rate Control is applied to downlink NAS Data PDUs. the CP function shall indicate to the UP function to not report the status of the packet rate usage Small Data Rate control: Small Data Rate Control is intended to allow HPLMN operators to offer customer services such as "maximum of Y messages per day". The Small Data Rate Control applies to data PDUs sent on that PDU Session by either Data Radio Bearers or Signalling Radio Bearers (NAS Data PDUs). The rate control information is separate for uplink and downlink. the CP function shall indicate to the UP function to report the status of the packet rate usage Our proposal: SMF can send both of the parameters to UPF in different QERs, one QER indicates the report of status of the packet rate usage is not needed, another QER indicates the report of status of the packet rate usage is needed. Otherwise, if only Serving PLMN rate control or Small Data Rate control can be sent to SMF, it is difficult for the SMF to decide how to set the IEs in QER. CC Caixia will provide a draft version. Caixia: Based on the discussion during conference call and the comments received, I have made a revision and uploaded into the draft inbox, please check whether it is acceptable for you. Serving PLMN rate control is per PDU session ,so I revert the changes; Description in IE is added into NOTE; And add the alternative to only enforce the small data rate control if bot the serving PLMN rate control and small data rate control applied. Frank: Just request a small change in the change in 5.4.15.3 PGW and SMF behaviour. (should this change be considered as next change after the first change😊) If both Serving PLMN rate control and Small Data Rate Control are applied in 5GS, or both Serving PLMN rate control and APN rate control are applied in EPS, the SMF/PGW-C may control packet rate enforcement in the UP function by provisioning: a QER for Small Data Rate Control/APN rate control, and by associating DL/UL PDRs to the QER; or alternatively, different QERs for Serving PLMN rate control and for Small Data Rate Control/APN rate control, and by associating DL PDRs to both of the QER(s). We can't really use "Shall", e.g. a SMF is controlling a I-UPF and PSA UPF, in such case, I-UPF may enforce Serving PLMN rate, while PSA UPF enforces small data rate. Caixia: Thank you, comments are captured in draft v2, please double check. https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.2.4/C4-204152_V2_5G_CIoT%2029.244-Rate%20Control.docx Frank: . I am fine with the revision Bruno: Thanks, V2 is fine by me.
4395	CR 29.244 0474 Rel-16 Small data rate control and Serving PLMN rate control	Huawei
4153	CR 29.503 0474 Rel-16 Invoke NEF indication	Huawei	Agreed	WI 5G_CIoT CAT F
4154	CR 29.503 0475 Rel-16 Maximum response time/latency time	Huawei	Revised to C4-204396	WI 5G_CIoT CAT F Ulrich I was wondering whether the proposed change is backwards compatible. Can you please clarify. Caixia: the change is backwards incompatible, would be OK to define new IEs without Snssai and Dnn? Ulrich: I was more concerned about the change in table 6.1.6.2.4 and the corresponding OpenAPI change to remove the arrays. However, reading the response from Jesus to 4085, I may be wrong and also your change is compatible (in some way). Jones Besides the consideration of the backward compatibility issue Ulrich has indicated, I also have other concerns. After talking with colleagues I also checked back again in SA2, seems something contradict to what have proposed in the CR (Or we can say stage 2 is not consistent with each other), e.g.: 4.15.3.2.3b Specific NEF service operations information flow for loss of connectivity and UE reachability … 2. [Conditional] If the subscribed periodic registration timer has not been set according to any subscription request, or a Network Configuration as defined in clause 4.15.6.3a the UDM shall set the subscribed periodic registration timer using the Maximum Detection Time or Maximum Latency; otherwise if the subscribed periodic registration timer was previously set by a different subscription identified by a different Notification Target Address (+ Notification Correlation ID), or set by a different Network Configuration identified by a different NEF reference ID for the same UE, and if the newly received Maximum Detection Time or Maximum Latency is lower than the provided subscribed periodic registration timer, the UDM shall set the subscribed periodic registration timer using the newly received Maximum Detection Time or Maximum Latency. If Nudm_EventExposure_Unsubscribe request is performed in step 1, the UDM shall recalculate the subscribed periodic registration timer based on the remaining event subscriptions and/or Network Configurations. In addition for UE reachability subscription, if the newly received Maximum Response Time is longer than the provided subscribed Active Time (i.e. previously provided Maximum Response Time), the UDM shall set the subscribed Active Time using the newly received Maximum Response Time. If the suggested number of downlink packets is newly received, the UDM shall add the newly received suggested number of downlink packets to the currently used value of suggested number of downlink packets if the aggregated value is within the operator defined range. If Nudm_EventExposure_Unsubscribe request is performed in step 1, the UDM shall recalculate the subscribed Active Time and/or Suggested Number of Downlink Packets based on the remaining event subscriptions and/or Network Configurations. If the subscribed periodic registration timer or the subscribed Active Time are set or modified, the UDM sends the Nudm_SDM_Notification request to related serving AMF(s). If the AMF receives a subscribed periodic registration timer value from the UDM, it allocates the received value to the UE as the periodic registration timer at subsequent Registration procedure. The AMF starts monitoring of the expiration of the mobile reachable timer for Loss of Connectivity (if required) and starts monitoring of the UE entering connected mode for UE reachability (if required). It seems that UDM is performing the calculate and setting the active time/periodic registration and notify to AMF. This may also related to the cardinality of the recorded max response time/latency as well. It is clear that DNN/Slice based MAX response time/latency is no longer required (Thanks God 😊), the max response time/latency triggered by each subscription / configuration shall all be recorded, which will be used for calculation e.g. when unsubscribing / cancel provisioning happens. Further clarification should be ready before we move this forward. Caixia: Thank you for your detailed explanation. So If my understanding correct, the UDM will set the subscribed periodic registration timer or subscribed Active Time based on the Maximum Detection Time or Maximum Latency/ Maximum Response Time. And the AMF can just use the activeTime as the Active Time for UE, and subsRegTimer as the Periodic Registration Timer for UE. Please check whether the following description is acceptable: Original proposed text: When receiving the maximumResponseTime, the AMF shall use the maximumResponseTime as the Active Time for UE. If not, when the AMF receives the activeTime, the AMF shall use the activeTime as the Active Time for UE. When receiving the maximumLatency, the AMF shall use the maximumLatency as the Periodic Registration Timer for UE. If not, when the AMF receives the subsRegTimer, the AMF shall use the subsRegTimer as the Periodic Registration Timer for UE. Changed to: AMF shall use the activeTime as the Active Time for UE, and shall use the subsRegTimer as the Periodic Registration Timer for UE. Whether other changes needed? Caixia: Please check the draft v1 in inbox: https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.2.4/C4-204154_V1_5G_CIoT%2029.503-maximum%20response%20time%20r2.docx Jones: Thanks for the update. The tricky thing is that 23.502 also mentioned in 4.15.6.3a: The parameters Maximum Response Time and Maximum Latency are classified in the UDM as AMF-Associated parameters and sent to the AMF. The AMF may use the Maximum Latency parameter to configure the time between UE reachability events (e.g. MICO mode duration, Periodic Registration Timer value). The AMF may use the Maximum Response Time parameter as guide to configure: - Active Time or Extended Connected time for MICO mode; - when to send reachability notifications to AF relative to expected reachability events (e.g. paging occasions). If the UDM received multiple Network Configuration requests, the UDM shall accept the request as long as the Maximum Latency (if received) and/or the Maximum Response Time (if received) are within the range defined by operator policies. The UDM shall use the minimum value of Maximum Latency(s) and/or the maximum value of Maximum Response Time(s) as the AMF-Associated parameters. If the configured value is changed comparing to the one last time sent to the AMF, the UDM notify the AMF of the updated value via Nudm_SDM_Notification message. If there is a deletion of Network Configuration request, the UDM re-calculates the values (see step 2 in clause 4.15.3.2.3b) and notify the AMF if needed. It is really not clear what to be informed to the AMF. e.g. if UDM always calculate and apply the last change to Active Time and Periodic Reg Time, why UDM needs to pass max response time and latency to AMF; If UDM does pass the max response time / latency to AMF, then why bother modify the Active time. May I ask to only keep the change of removal Dnn/Slice from Max response time/latency, and revert other changes form this CR. This is what we considered can be agreed for now. We will bring CRs for stage 2 clarification and for Stage 3 adaptation on next meeting. Caixia: am fine with your proposal, the changes related to how AMF use these information is removed in draft v2, we can fix the issue in next meeting as your proposed. https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.2.4/C4-204154_V2_5G_CIoT%2029.503-maximum%20response%20time%20r2.docx Jones: Thanks for the update. Please also revert change in clause 6.1.2.4 which changes array to singleton. Please also update the reason for change correspondingly. We can discuss offline in stage 2 and stage 3 to get a better agreed approach for next meeting. Thanks! Caixia: For keeping the array of IEs, it is just backward compatibility consideration, or other reason? Jones: Backward compatibility is one aspects, another aspects is whether and why UDM really need to pass it AMF in case it always translate to active/periodic Reg which related to the confusion we would figure out for a solution in next meeting. For now, we don’t think it is not necessary to introduce this change, which remove two IEs and add two new uncertain IEs. Caixia: Please check draft v3 in inbox, I can live with your proposal, and just remove the snssai and dnn in the revision. https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.2.4/C4-204154_V3_5G_CIoT%2029.503-maximum%20response%20time%20r3.docx Jones: Thanks. V3 draft is fine by me Farni: our email last week said this was backwards incompatible. Then other emails said it was. Can you confirm whether this change is Backward Compatible or not? What would be the new version of the API?
4396	CR 29.503 0475 Rel-16 Maximum response time/latency time	Huawei
4155	CR 29.542 0005 Rel-16 Optionality of ProblemDetails in TS29.542 cleanup	Huawei	Revised to C4-204397	WI 5G_CIoT CAT F Yvette: The cover page (title, summary of change) and the proposed changes are not compatible with each other. Could you please check? Caixia: Thank you for your comments, I will update the contribution to indicate the changes correctly. I have updated the coversheet, like title and reason for change, and draft V1 is available in draft inbox of [7.2.4]. Could you please check whether it is fine for you?
4397	CR 29.542 0005 Rel-16 Optionality of ProblemDetails in TS29.542 cleanup	Huawei
CC3	4271	discussion Rel-16 Event Configuration Sync Between 4G&5G	Ericsson	Jones: This discussion paper focuses on issues for Event Configuration synchronization between 4G&5G in Stage 2 specification we discovered when trying to model stage 3 protocol. With listed facts, we proposed to send an LS to SA3 to clarify and possibly consider to provide better solution accordingly. We would like to get approval from CT4 to send such an LS. So far there is no feedback received. Please check the DISS and provide your opinion. @Peter Schmitt, could you please reserve a short slot for this in tomorrow’s meeting if possible? If we could agree on sending an LS, I can draft it as earlier as possible. CC Ulrich it is ok to send an LS to SA2 to clarify the requirements.
4338	LS out LS on Event Configuration Synchronisation between 4G&5G	Ericsson/ Jones	Approved	To: SA2 CC: CT3 Jones: Draft of C4-204338 LS on Event Configuration Synchronisation between 4G&5G is uploaded in Inbox: ftp://ftp.3gpp.org/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.2.4/draft%20C4-204338_LS%20on%20Event%20Configuration%20Synchronisation%20between%204G%265G.docx CC No comments to change, Ulrich LS is ok for him
4289	CR 23.003 0596 Rel-16 Correction on Truncated 5G-S-TMSI	Huawei	Revised to C4-204373	WI 5G_CIoT CAT F Bruno: In the reason for Change, “29.501” needs to be corrected to “23.501” (twice). Please also correct the reference below within the actual changes: "described in 3GPP TS 24.501 [125] "
4373	CR 23.003 0596 Rel-16 Correction on Truncated 5G-S-TMSI	Huawei
7.2.5	CT aspects on enhancement of network slicing	eNS
4010	CR 29.526 0001 Rel-16 Missing reference clauses	Huawei	Merged into revision of 4099	WI eNS CAT F Zhijun: C4-204010 clashes with C4-204099, and can be merged. And as C4-204011 is target R17 while we don't have R17 spec released yet, I think C4-204011 is not needed. Giorgi: I’m fine to merge 4010 into 4099, because 4099 is more complete. I’ll shortly post my comment on 4099.
4011	CR 29.526 0002 Rel-17 Missing reference clauses	Huawei	Withdrawn	WI eNS CAT A No Rel-17 version, no mirror CR needed
4018	CR 29.526 0003 Rel-17 Removimg editor's note on AAA-S address provision	Huawei	withdrawn	WI eNS CAT F
4063	CR 29.526 0004 Rel-17 Removimg editor's note on AAA-S address provision	Huawei	revised to C4-204077	Revision of C4-204077 WI eNS CAT F
4077	CR 29.526 0004 Rel-16 Removing editor's note on AAA-S address provision	Huawei	WI eNS CAT F Zhijun: C4-204077 clashes with C4-204100. As C4-204100 includes more changes of the AAA-S address, I proposes to merge C4-204077 to C4-204010. Giorgi; Fine by me, if you meant merging 4077 into 4100. Varini: I want to request for a clarification on removal of editor’s note. I believe this note was added in last meeting as we wanted clarification from SA2 whether AAA-S address should be provided to an AMF in V-PLMN, and then AMF to provide it back to NSSAAF in H-PLMN. I see competing proposals in SA2’s current meeting against this. Do we want to wait for SA2’s decision before removing the note? Zhijun: Yes, we will expect SA2 decision. But at least we can fix the errors in this CR for now. Giorgi: I believe we should wait for the outcome of the SA2 discussions. This CR is assumes one particular, more probable outcome, but can be used for another.
4099	CR 29.526 0005 Rel-16 Update References	ZTE	Revised to C4-204357	WI eNS CAT F Giorgi: after merging 4010 into 4099, the following changes are necessary to clause 4.1: The AMF shall make use of the NSSAAF service when it needs to invoke network slice-specific authentication and authorization for a specific UE and a specific S-NSSAI (see 3GPP TS 23.502 [3] clause 4.2.9.2, and 3GPP TS 33.501 [14] clause 16.2 and 16.3). The NSSAAF service shall also be used by the AMF to receive slice re-authentication notification or slice authorization revocation notification sent from the AAA-S (see 3GPP TS 23.502 [3] clause 4.2.9.3, and 3GPP TS 33.501 [14] clause 16.4 and 16.5). Also, hard breaks before ‘clause’ as in 4010. Zhijun Got. Thanks. V1 is now in /INBOX/Drafts/7.2.5. Huawei is added as co-sourcer https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.2.5/C4-204099_v1_eNS_29526_Update%20References.docx
4357	CR 29.526 0005 Rel-16 Update References	ZTE
4100	CR 29.526 0006 Rel-16 AAA Server Address	ZTE	Revised to C4-204358	WI eNS CAT F Giorgi: In clause 6.1.6.2.4 please correct the type of the serverAddress attribute to IpAddress. Zhijun: Will do it in the v1 revision. Thanks for spotting this error Ulrich: On the cover page the text in other comments is wrong (“does not introduce backward compatible changes”) Zhijun: Thanks for pointing out the errors. Now the v1 is uploaded in /INBOX/Drafts/7.2.5. https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.2.5/C4-204100_v1_eNS_29526_AAA%20Server%20Address.docx
4358	CR 29.526 0006 Rel-16 AAA Server Address	ZTE
4101	CR 29.526 0007 Rel-16 Release PDU Session if NSSAA Re-Authentication and Re-Authorization Fails	ZTE	Revised to C4-204359	WI eNS CAT F Caixia Comments from my side: /Consequences if not approved is missed. /For revocation or the re-authentication is success but the result is EAP-failure, does the AMF also need to release the PDU session? Why the change is dedicated to authentication failure? Zhijun For re-authentication, the AMF will check whether the NSSAA procedure is finally failed, by inspecting the response code and the Authentication Status returned, if it fails it will release the PDU session. I can refine the text to reflect your consideration. For re-vocation, there is some text says that it causes the AMF to release the PDU session. Jesus: I think the CR is a bit misleading because the clause where you have put the new text is a procedure for notification of slice-specific reauthn. (i.e. the NSSAAF notifies the AMF that it needs to trigger the reauthn. procedure). So, if the notification itself succeeds, then the subsequent reauthn. may not succeed for a number of reasons (e.g. the AMF cannot initiate the reauthn. procedure probably because the UE is not reachable or because the S-NSSAI is no longer in use in the AMF). So, in our view, in those cases, the PDU sessions do not need to be released; instead, the AMF shall not report an error and shall then initiate the NSSAA procedure via the NSSAAF instead. Zhijun: Thanks for you comments. I will take your comments into account. So in general if the NSSAA procedure fails, the AMF <MAY> trigger PDU session release depending on the actuall reason causing the NSSAA procedure failure. I will try to find suitable text for this.
4359	CR 29.526 0007 Rel-16 Release PDU Session if NSSAA Re-Authentication and Re-Authorization Fails	ZTE
4102	CR 29.502 0366 Rel-16 Release PDU Session if NSSAA Re-Authentication and Re-Authorization Fails	ZTE	Revised to C4-204360	WI eNS CAT F Caixia am fine with this paper, but Consequences if not approved is empty Zhijun: I remember that people said it may not always needed. Anyway, I will add it. Bruno: CoNA is empty. And one small editorial: "see clauses 4.2.9.2, 4.2.9.3 and 4.2.9.4 Zhijun: Thanks for your comments. The coversheet and editorial errors are fixed. V1 is now uploaded: https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.2.5/C4-204102_v1_eNS_29502_Release%20PDU%20if%20Re-Authentication%20Fails.docx
4360	CR 29.502 0366 Rel-16 Release PDU Session if NSSAA Re-Authentication and Re-Authorization Fails	ZTE
CC2	4103	CR 29.518 0377 Rel-16 Transfer N2 SM Info Received from SMF to Target AMF	ZTE	Revised to C4-204361	WI eNS CAT F Varini: Thanks for the paper. I want to request for following clarification on this CR: UeContextCreateData already has N2SmInformation as part of pduSessionList. Why do we need a new variable n2SmInfoFromSmf to convey this info? Zhijun: During HO, RAN may provide N2 SM Information targeting the SMF and this N2 SM is then transferred to target AMF. However, the SMF may also provide N2 SM Information targeting RAN, but it may fails to delivered to RAN during HO. As per 23.502 described, such N2 SMF Information from SMF needs to forwarded to target AMF and finally target AMF will transferred to target RAN. Currently we missed this N2 SMF towards RAN side Varini: Got it, thanks for clarifying  Jones: Stage 2 specified using CreateUeContext for AMF-Relocation, where UeContextCreateData is carried in the HTTP POST body. In current definition, there are mandatory IEs e.g. pduSessionList contain “Handover Required Transfer” but are not available during EPS to 5GS handover with AMF relocation case. Also for “Handover Command Transfer” in UeContextCreatedData as well. Definition of type UeContextCreateData pduSessionList: This IE shall be included to contain the list of N2SmInformation, where each N2SmInformation includes the "Handover Required Transfer" received from the source RAN per PDU session Definition of type UeContextCreatedData: pduSessionList This IE shall be included to contain the list of N2SmInformation, where each N2SmInformation includes the "Handover Command Transfer" received from the SMF, per We’d better find a backward compatible way to fix it, before we should agree this CR. Any view? Zhijun: Maybe a possible way as we indicate empty string to other IEs, how about we indicate this empty array in these specific scenarios? Jones: Other mandatory IEs are also structure data types that cannot be simply set to empty strings. Actually I think specify new service operation for AMF relocation (e.g. RelocateUeContext) maybe a better option, i.e. keep Create UE Context for N2 based handover usage only, which perfectly fits the current definition. If we agree, we could align Stage 2 accordingly. Zhijun: Now it looks not an easy change. But we can discuss if it is possible. Bruno: 6.1.6.2.41: - the description of the new IE should indicate that “ach N2SmInformation includes the "PDU Session Resource Setup Request Transfer" received from the SMF. - why cardinality 0..N ? I rather expect 1..N CC. Once we have agreed on the CR we may need to ask SA2 to align their specification. The needs to be updated to reflect the comments. If no conclusion this CR may be postpone to the next meeting
4361	CR 29.518 0377 Rel-16 Transfer N2 SM Info Received from SMF to Target AMF	ZTE	Postponed to next meeting	Zhijun I create a draft C4-204361 to define new service operation - RelocateUeContext for transfering N2 SM info received from SMF between two AMFs. It looks the change impacts a lot of sections, and seems not an easy one. We can use this as base document for further discussion. Bruno: Thanks. I agree with you, better to postpone the CR but use it as basis for further work for the next meeting, so as to allow us to check all the changes carefully.
CC2	4119	CR 29.531 0075 Rel-16 Feature negotiation for NSSAA at AMF re-allocation	NEC Europe Ltd	withdrawn	WI eNS CAT F Varini Thanks for the paper. I want to request following clarifications on this CR: IMO, Supported feature attribute in an API indicates the features supported by NF consumer (in request) or producer (in response). In this scenario, we are requesting NSSF to provide a list of AMFs which support NSSAA, hence whether requesting AMF supports NSSAA or not should not matter? IMO, if we want to request AMFs supporting NSSAA, it should be sent as a separate IE in the request. Slices supporting NSSAA are identified using a separate S-NSSAI. If an AMF is configured to support a specific S-NSSAI (which requires NSSAA), that itself means AMF supports NSSAA. Else, this is a configuration issue. From this point of view, we don’t really need to let NSSF know that request is for NSSAA-supporting-AMF? As long as NSSF knows requested NSSAI and subscribed NSSAI, From UE point of view, whether UE supports NSSAA or not will be known to target AMF too, as I believe original registration request itself is sent to target AMF. Hence, sending UE’s capability may also not be required? Correct the CR number in the subject Bruno: Cover page: Revision nb should be corrected to "-" (and now “1” in next revision) Please correct the typos in Reason for Change and CoNA 6.1.6.2.2: - the technical changes are incorrect. The existing attributes newly marked with "Nssaa" are not specific to the Nssaa feature. What you wish to do cannot be done as you propose. Also the condition for selecting an AMF that supports NSSAA cannot be only “When a NF consumer detects the UE support Network Slice-Specific Authentication and Authorization feature”; I assume this should also depend on whether NSSAA is required in subscription data. 6.1.8: changes need to be reverted Tsuyoshi: Reading the comment, I felt that there may be a basic difference in implementation assumption. With that says, let me have an internal discussion first. Please keep it open. Zhijun Having some feature to detect whether target AMF supports NSSAA procedure looks reasonable. But the change to TS29.531 doesn't look a good idea. The NSSF service is normally used for S-NSSAI mapping, and gives some candidate AMF which support the indicated S-NSSAI. Till now we have not define any AMF feature in NSSF. Normally, the supported features are configured in NF profile in NRF, or exchanged by signalling between two NFs.
4120	CR 29.526 0008 Rel-16 NSSAA status management	NEC Europe Ltd	Revised to C4-204429	WI eNS CAT F Zhijun: Some editorial comments: - in the coversheet, the revision number starts from "-". It will be "1" if you generate new formal revision. - in the change to clause 2 and other clauses, instead of numbering reference number to [16], keep it as [x]. Rapporteur will fix the numbering when implementing agreed CRs Caixia: one more comment from my side, the other comments in coversheet is missed. Tsuyoshi: thank you for your comment. And, I will take them all in the next revision Tsuyoshi Please find the revision draft. https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.2.5/C4-204120_v1_eNS_29526_NSSAA%20status%20management.docx
4429	CR 29.526 0008 Rel-16 NSSAA status management	NEC Europe Ltd
CC2	4157	CR 29.518 0381 Rel-16 SNSSAI during mobility procedure	Huawei	Revised to C4-204398	WI eNS CAT F Zhijun: Instead of introducing new IE to differentiate the inter-PLMN mobility, maybe we can clearly describe the “allowedNssai” / “nssaiMappingList” as per the differentiated cases: - if source AMF is in same PLMN as target AMF, "allowedNssai" carries the VPLMN S-NSSAI and "nssaiMappingList" carries the S-NSSAI mapping list from VPLMN S-NSSAI…. - if source AMF is in different PLMN as target AMF, "allowedNssai" carries the HPLMN S-NSSAI … Caixia: either way is fine by me, let’s see the opinions for others. Bruno: WI code should be TEI16, 5GS_Ph1-CT Small The editorials (missing words): "if the source AMF and the target AMFs are in the same PLMN and if available" "if the source AMF and the target AMFs are in different PLMN " Caixa: I will make the changes accordingly CC Zhijun: Can we reuse exiting IE Bruno: using new IE looks more cleaner we should not overload definitions. Agreed to proceed with new IEs Caixia: Draft v1 is uploaded onto [7.2.5] with the changes to update the work item code and add the missing words accordingly. Bruno: One small editorial: This IE shall be present if the source AMF and the target AMF are in the different PLMNs and if available. When present, this IE shall contain the home S-NSSAIs corresponding to the allowed NSSAI for the access type. Caixa: Thank you, I will fix it in formal revision.
4398	CR 29.518 0381 Rel-16 SNSSAI during mobility procedure	Huawei
7.2.6	CT aspects of System enhancements for Provision of Access to Restricted Local Operator Services by Unauthenticated Ues	PARLOS
7.2.7	CT aspects on wireless and wireline convergence for the 5G system architecture	5WWC
4200	CR 29.244 0480 Rel-16 IPv6 Prefix Delegation via DHCPv6	Nokia, Nokia Shanghai Bell	Revised to C4-204466	WI 5WWC CAT F Frank: I agree with the intention of the CR as described in the Reason for change. However, I am not sure if the actual changes are really reflecting the intention. There is also ambiguous to make use of UE IP Address IE. See below: I felt you wants to allow multiple UE IP address instance (even when IP6PL feature is not supported) with the following wording "if the UPF indicated support of the IP6PL feature (see clause 5.21) or prefix delegation is used", if we limit the use case as specified 23.316, the yellow highlighted text should be removed; BTW, Prefix Delegation is already supported, but /64 must be part of /shorter of 64 (per 23.401). CP function can use UE IP Address with IPv6D set. Bruno 29.244 supports the following UE IP Address allocation mechanisms: 5.21.1 General Stage 2 requirements for UE IP address allocation in the EPC and 5GC are specified in clause 5.8.2.2 of 3GPP TS 23.501 [28] and clause 4.6.2 of 3GPP TS 23.316 [57]. The following types of UE IP addresses may be assigned over N4 or Sxb: - IPv4 address; - /64 IPv6 Prefix; - IPv6 prefix other than default /64, including individual /128 IPv6 address, if the UPF indicates supports of the IP6PL feature (see clause 8.2.25), for IPv6 address allocation using DHCPv6 specified in clause 4.6.2.2 of 3GPP TS 23.316 [57]; - IPv6 prefix shorter than the default /64 prefix for support of IPv6 prefix delegation as specified in clause 4.6.2.3 of 3GPP TS 23.316 [57] and clause 5.14. IPv6 prefix delegation is supported from Rel-15 onwards (w/o any specific UP function feature defined for it). The IP6PL feature has been defined in Rel-16 (WWC) as follows : 8/6 IP6PL N4 UPF supports UE IPv6 address(es) allocation with IPv6 prefix length other than default /64 (including allocating /128 individual IPv6 addresses), as specified in clause 4.6.2.2 of of 3GPP TS 23.316 [57]. So the IP6PL feature does not apply to support of prefix delegation per my understanding. And accordingly, my intention is indeed to “allow multiple UE IP address instance (even when IP6PL feature is not supported) with the following wording "if the UPF indicated support of the IP6PL feature (see clause 5.21) or prefix delegation is used". Can you please clarify what is wrong then? Frank] I understand before we introduce IP6PL feature, a PDU session can be allocated only one instance of UE IP Address. IPv6 delegation is supported since Rel-15, however, it was introduced based on the requirement in TS 23.401, where the /64 prefix is part of /x where X is shorter than 64, the CP function will provision an instance of UE IP Address with IPv6D flag set to "1". In Rel-16, upon 5WWC, according to TS 23.316, we added above two bullets as highlighted in cyan, where we need support IPv6 prefix delegation: /64 prefix is NOT part of /x where X is shorter than 64; and  this requires two instances UE IP address IE; /64 prefix is part of /x where X is shorter than 64; And we need support multiple Multiple IPv6 prefix(es) other than default /64 including /128;  this requires more than one instances UE IP address IE; These new requirements (from 23.316) is formed as IP6PL feature, and it should be also reflected in the flag "IP6PL" in the UE IP Address IE; If we want to only address 23.216 requirement, the existing IP6PL feature is defined as the UP support multiple UE IP Addresses, so, the text should be: "More than one UE IP address may be assigned to a PDU session, e.g. multiple /128 IPv6 addresses, if the UPF indicates supports of the IP6PL feature (see clause 8.2.25) or prefix delegation is used, by provisioning multiple instances of the UE IP Address IE in a same PDI or Traffic Endpoint, or by provisioning multiple PDIs or Traffic Endpoints with a different UE IP Address, where the UE IP Addresses may convey: - multiple /128 IPv6 addresses; or - an /64 default prefix used for IPv6 stateless autoconfiguration or an IP IPv6 prefix (with IP6PL bit is set)shorter than the default /64 prefix for IPv6 Prefix Delegation including the /64 IPv6; - an IPv6 prefix (with IP6PL bit is set)shorter than the default /64 prefix for IPv6 Prefix Delegation not including the /64 IPv6 Prefix (i.e. when the total IPv6 address space available for the PDU Session cannot be aggregated into one single IPv6 prefix). " Bruno for the 3rd bullet above, I had proposed the following text: “- an /64 default prefix used for IPv6 stateless autoconfiguration and an IPv6 prefix shorter than the default /64 prefix for IPv6 Prefix Delegation not including the /64 IPv6 Prefix (i.e. when the total IPv6 address space available for the PDU Session cannot be aggregated into one single IPv6 prefix).“ What is wrong (letting aside which flags to use) with the formulation I proposed (which reads better IMO, i.e. we better see that we have two UE IP Addresses IE respectively for the /64 prefix and the shorter prefix)? [Frank] I modified it, because I see we need 2 UE IP Address Instances to convey them, one is with /64, and the other IP6PL flag set together with IPv6 Prefix Length. I am confused by the flags you use ( “IP6PL”) for IPv6 prefix delegation. I expect the IPv6D flag to be used for IPv6 prefix delegation (as defined in Rel-15). Why do you propose something else, and when then would IPv6D be used? [Frank] As I explained above, I regard multiple UE IP Address instance are part of IP6PL feature, so propose to use IP6PL accordingly. Why also the 2nd bullet? In this use case (where the total IPv6 address space can be aggregated into a single IPv6 prefix) why do we need to send 2 UE IP Address IE? [Frank] yes, only one instance UE IP Address can support these two cases " 1) an /64 default prefix used for IPv6 stateless autoconfiguration or 2)an IP IPv6 prefix (with IP6PL bit is set)shorter than the default /64 prefix for IPv6 Prefix Delegation including the /64 IPv6" . I proposed to say, the UE IP Address IE may convey: It would be good to update the IE definition for UE IP Address, add another example, e.g. " The IPv6 Prefix Length in octet s, when present, shall be encoded as a 8 bits binary integer, e.g. if /72 prefix is used, the value shall be set to to (decimal) 72, if /56 prefix is used, value shall be to (decimal) 56. The prefix length value "128" indicates an individual /128 IPv6 address." Bruno> just to clarify, why do you wish to add this example (56) when we already have a very similar example with /72? [Frank] I understand the coding you suggested (in previous meeting) can also cope with provisioning IPv6 prefix delegation. - Bit 7 – IP6PL (IPv6 Prefix Length): this bit is only applicable when the V6 bit or CHV6 bit is set to "1" and the "IPv6D" bit is set to "0", for an IPv6 prefix other than default /64 when UP function supports IP6PL feature as specified in clause 8.2.25. If this bit is set to "1", then the IPv6 Prefix Length field shall be present. Bruno> this addition is fine What do you think? Bruno: I have uploaded V1 in the draft inbox capturing most of your comments and further clarifying the specification on how to request the allocation of IPv6 prefix for IPv6 prefix delegation. https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.2.7/C4-204200_v1_29244_Rel16_IPv6%20Prefix%20Delegation%20via%20DHCPv6.docx Frank: Just found a small typo as below, should 5.21.1: NOTE: The IPv6 prefix shorter than the default /64 prefix for IPv6 Prefix Delegation can include the /64 default prefix used for IPv6 stateless autoconfiguration (in EPS and 5GS) or not (5GS). In the latter case, the total IPv6 address space available for the PDU Session cannot be aggregated into one single IPv6 prefix; support of this latter case requires support of the IP6PL feature (see clauses 5.31.1 and 8.2.25). Could you please add Ericsson as supporting company? Bruno: hanks. Done in V2 uploaded in draft folder. https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.2.7/C4-204200_v2_29244_Rel16_IPv6%20Prefix%20Delegation%20via%20DHCPv6.docx
4466	CR 29.244 0480 Rel-16 IPv6 Prefix Delegation via DHCPv6	Nokia, Nokia Shanghai Bell, Ericsson
CC2 CC6	4208	CR 29.571 0233 Rel-16 N5GC Location	CableLabs	Revised to C4-204455	WI 5WWC CAT F Caixia: I think HFC Node ID is defined in the User Location, is it OK to use the HFC Node ID? And is the GCI supported in TS 38.413? Omkar: For using HFC Node ID for ULI info, as per TS 23.316 clause 4.10a “When it provides (over N2) ULI to be associated with a N5GC device, the W-AGF builds the N5GC's ULI using the GCI (see clause 4.7.9) of the CRG connecting the N5GC device.” So the W-AGF uses GCI for ULI and not the HFC Node ID. For your other comment, I agree that we need to update TS 38.413 with N5GC aspects including the GCI for the user location of a N5GC. Bruno: the proposed encoding is indeed not compatible with what has been defined in 23.003. C4-204208 GCI encoding: Global Cable Identifier uniquely identifying the connection between the 5G-CRG or FN-CRG to the 5GS. See clause 28.15.4 of 3G PP TS 23.003 [7]. This shall be encoded as a string with format "byte" as defined in OpenAPI Specification [23], i.e. base64-encoded characters, representing the GCI value (up to 6 bytes) encoded as specified in CableLabs WR-TR-5WWC-ARCH [32]. TS 23.003 28.15.3 User Location Information for RG accessing the 5GC via W-5GCAN (HFC Node ID) The User Location information for a 5G-CRG/FN-CRG accessing the 5GC via a Wireline 5G Cable Access network (W-5GCAN) shall take the form of an HFC Node ID. The HFC Node ID consists of a string of up to six characters as specified in CableLabs WRTR5WWCARCH [134]. . 28.15.4 GCI The GCI uniquely identifies the line connecting the 5G-CRG or FN-CRG to the 5GS. The GCI is a variable length opaque identifier, encoded as specified in CableLabs WRTR5WWCARCH [134] and CableLabs DOCSIS MULPI [135]. It shall comply with the syntax specified in clause 2.2 of IETF RFC 7542 [126] for the username part of a NAI. NOTE: The GCI contains an HFC_Identifier, see WRTR5WWCARCH [134] and CableLabs DOCSIS MULPI [135]. EXAMPLE: 00-00-5E-00-53-00 The following definitions in 29.571 also look wrong: HfcNId, string, This IE represents the identifier of the HFC node Id as specified in CableLabs WR-TR-5WWC-ARCH [32]. It is provisioned by the wireline operator as part of wireline operations HfcNId: type: string maxLength: 6 since as shown in the example, the JSON attribute will encode 16 characters (representing 6 bytes of the MAC address). So this should be corrected too. EXAMPLE: 00-00-5E-00-53-00 Omkar I think the HFC Identifier value mentioned as “up to 6 bytes” in the original CR has created a confusion and is being mixed with HFC Node ID which is “a string of up to six characters”. Just wanted to clarify that HFC Identifier and HFC Node ID are two separate attributes. Section 28.15.3 talks about the HFC Node ID which is used to build User Location Information and has nothing to do with GCI or the CR. The GCI contains the HFC Identifier. HFC Identifier may contain a cable modem MAC address or an overall HFC account identifier as defined in TS 23.316 clause 4.7.6. Also the example value of “00-00-5E-00-53-00" in TS 23.003 clause 28.15.4, is for GCI or HFC Identifier that can be a CM MAC address and not for HFC Node ID which is a string of six characters. I have revised and uploaded a new version of the CR that removes any reference to “6 bytes”, as shown below: Gci Global Cable Identifier uniquely identifying the connection between the 5G-CRG or FN-CRG to the 5GS. See clause 28.15.4 of 3G PP TS 23.003 [7]. This shall be encoded as a string with format "byte" as defined in OpenAPI Specification [3], i.e. base64-encoded characters, representing the GCI value as specified in CableLabs WR-TR-5WWC-ARCH [32]. Please let me know if you have any further comments on the revised version. Bruno: The proposed CR defines the Gci as follows: Gci, Bytes, Global Cable Identifier uniquely identifying the connection between the 5G-CRG or FN-CRG to the 5GS. See clause 28.15.4 of 3G PP TS 23.003 [7]. This shall be encoded as a string with format "byte" as defined in OpenAPI Specification [3], i.e. base64-encoded characters, representing the GCI value as specified in CableLabs WR-TR-5WWC-ARCH [32]. TS 23.003 28.15.2 NAI format for SUPI containing a GCI A SUPI containing a GCI shall take the form of a Network Access Identifier (NAI). The NAI for SUPI shall have the form username@realm as specified in clause 2.2 of IETF RFC 7542 [126], where: - the username part shall be the GCI, as defined in clause 28.15.4; - the realm part shall identify the operator owning the subscription; if the operator owns a PLMN ID, the realm part should be in the form: "5gc.mnc<MNC>.mcc<MCC>.3gppnetwork.org" EXAMPLE 1: 00-00-5E-00-53-00@5gc.mnc012.mcc345.3gppnetwork.org EXAMPLE 2: 00-00-5E-00-53-00@operator.com 28.15.4 GCI The GCI uniquely identifies the line connecting the 5G-CRG or FN-CRG to the 5GS. The GCI is a variable length opaque identifier, encoded as specified in CableLabs WRTR5WWCARCH [134] and CableLabs DOCSIS MULPI [135]. It shall comply with the syntax specified in clause 2.2 of IETF RFC 7542 [126] for the username part of a NAI. NOTE: The GCI contains an HFC_Identifier, see WRTR5WWCARCH [134] and CableLabs DOCSIS MULPI [135]. EXAMPLE: 00-00-5E-00-53-00 28.16.4 GLI The GLI uniquely identifies the line connecting the 5G-BRG or FN-BRG to the 5GS. The GLI is a variable length opaque identifier, consisting of a string of up to 200 base64-encoded characters, representing the GLI value (up to 150 bytes) encoded as specified in BBF WT-470 [133]. NOTE: The GLI contains an identifier of the Line ID source and the Line ID value, see BBF WT-470 [133]. So per existing 23.003 spec, GCI encodes a MAC address as 00-00-5E-00-53-00. Note that the GCI definition of 23.003 28.15.4 does not refer to “base64-encoded characters”, contrarily to the GLI definition. Your CR defines the GCI as base64-encoded characters, which cannot yield to “00-00-5E-00-53-00”. Besides, TS 23.316 says: 4.7.6 HFC identifier The HFC_Identifier may contain a cable modem MAC address or an overall HFC account identifier, as defined by CableLabs in DOCSIS MULPI [8]. Can you please quote how an “overall HFC account identifier” is encoded in the CableLabs spec, since it would be good to provide an example with such information (we only have examples with a MAC address). My question now is whether the GCI conveys the MAC address (as formatted in 23.003, examples above => easy to read SUPI and GCI), or whether it conveys base64 encoded characters representing the MAC address (=> not easy human readable string in SUPI and GCI), for the case where the GCI contains a MAC address. If we go for base64 encoded characters, then we need to update 28.15.2 & 28.15.4 of TS 23.003. Note that there is also a typo: See clause 28.15.4 of 3G PP TS 23.003 [7]. CC Omkar will provide a new draft. There is a inconsistency between our TS 23.003 definition and the CR Omkar: Thank you for your very helpful continued review and comments on the N5GC location CR. Please find the updated revision uploaded to: https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.2.7/C4-204208_v2_CT4#99e_N5GC_Location.docx We believe the updated revision incorporates your comments. We would prefer to stay compliant to the existing text in 23.003 with our CT4 CR. It was not our intent to drive an update to 23.003. We apologize for the confusion by incorrectly referring to Base64, which we have now deleted in the revision. The latest CR update requires the GCI to be compliant with the format specified in clause 28.15.4 of 3GPP TS 23.003 and the referenced RFC. The HFC Account ID is referred in DOCSIS as a string. The format described in RFC 7542 is extensive to cover the HFC account ID as well. The focus of the CR is on the GCI per the 23.003 format per RFC 7542. The examples in 23.003 show the CM MAC address in this format, which is by far our most common case. Please check if the we have correctly updated the API for GCI Bruno: Thanks. I agree with your revision that is now in line with 23.003. Small editorial: you need to use hard space in all your new references, e.g. This shall be encoded as a string per clause 28.15.4 of 3GPP TS 23.003 [7], and compliant with the syntax specified in clause 2.2 of IETF RFC 7542 [126] for the username part of a NAI. The GCI value is specified in CableLabs WR-TR-5WWC-ARCH [32]. CC Issue from Bruno is now addressed. Omkar: I have incorporated the editorial change suggested by Bruno. C4-204208 has been revised to C4-204455 and is uploaded to the Inbox folder. https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/C4-204455.zip
4455	CR 29.571 0233 Rel-16 N5GC Location	CableLabs
7.2.8	CT aspects of architecture enhancements for 3GPP support of advanced V2X services	eV2XARC
7.2.9	CT aspects of application layer support for V2X services	V2XAPP
7.2.10	CT aspects on Enhancement of 3GPP Northbound APIs	eNAPIs
7.3	AoB for Rel-16	TEI16
7.3.1	CUPS/PFCP	TEI16
CC4	4073	discussion Rel-16 UE IP address allocation alternatives	Huawei	Noted	Clash with C4-204251,C4-204272,alternative proposal. Bruno: I don't understand the argumentation of this DISC paper. When the CP fct requests the UP fct to assign a UE IP address for a given network instance or UE IP address pool, the UP function necessarily knows the IP@ not yet assigned for this network instance or Pool ID. If a network instance or Pool ID can be served by several PFCP entities, than there must be some way in the UP function to coordinate the IP address allocation (and usage) for the network instance or UE IP address pool across all these PFCP entities. I do not agree to overload the heartbeat procedure with this new functionality. I also agree with Ericsson’s comments in C4-204251 that this would newly require to send Heartbeat requests even when there is regular Sx or N4 traffic, and so this would cause extra traffic. Giorgi: I am not talking about multiple PFCP entities. Within a single PFCP entity one has multiple atomic processing units. My point is, the units that handle session managing messages may be completely independent. Implementation dependent architecture may break the common IP address pool into smaller chunks and allocate these sub-pools to each of these units. Therefore, the atomic units may not have info about the remaining capacity of other pools.
CC4	4074	CR 29.244 0471 Rel-16 Using Heartbeat for the UE IP address allocation	Huawei	Revised to C4-204417	WI CUPS-CT, TEI16 CAT F Clash with C4-204251,C4-204272,alternative proposal. Bruno: We do not agree with this CR. Please see our comments to the related discussion paper. Giorgi: Please see my reply to your comments on 4073. How to proceed with the CR
CC6	4417	CR 29.244 0471 Rel-16 using Association message for the UE IP address allocation	Huawei	Giorgi: Frank has kindly provided 4417_v2 of the draft, which is in the Drafts/7.3.1 folder. Let’s further develop the CR based on this version. I’m fine with the revision, but have minor comments. I will also fix the cover sheet little later.
CC Bruno: only the Ericsson proposal would not introduce any extra signalling Association message based solution introduce extra signalling. Frank clear preference for the session management message based solution shares the view see analysis in 4251. Frank ask for the reason why Giorgi cannot accept the session related signalling. Giorgi: session management message can only send message on the IP address pool. Frank: network instance is used in session management message. Bruno: the session management message are distributed to .. We should select only one solution to avoid interoperability problems. Preferences: Session based (4272) Nokia, Ericsson, ZTE Association based (4417 discusison basis needs enhancements) Huawei, Vodafone, Deutsche Telecom, China Mobile, Orange To reach consensus Nokia and Ericsson could accept a solution based on association message.
CC4	4251	discussion Rel-16 Discussion on Report of UE IP address Allocation Status in the UP function	Ericsson	Noted	Clash with C4-204073, C4-204074 alternative proposal. Bruno: we agree with the conclusions and way forward proposed in this DISC paper. I will post separately a few technical comments on the related CR. Giorgi: I’m afraid we sustain our reservations about the proposal. Key point is, a node level info should be sent with a node level message. By the way, to facilitate the discussion, it makes sense to formally define terms “PCFP node” and “PFCP entity” with one of the CRs. As a way forward, I would like to propose the third alternative. Let’s consider using PFCP association procedure for delivering UE IP address pool’s remaining capacity. Please give this a thought. Frank: But Heartbeat request/response message are not node level message. Just to make it clear, NOW you are proposing to use PFCP Association Update request message from the UP to CP? Please confirm. Using this option just introduces a few extra signalling, but it should be acceptable. Giorgi: It is true that Heartbeat is not a node level message, but it has coarser granularity than session management ones. Another advantage is that there is already a central handling unit for a Heartbeat, which has a path granularity. Anyway, I didn’t sense sufficient support for the Heartbeat alternative and therefore was trying to find a way forward. So, I do propose to reuse association messages for this purpose. Great to hear you are inclined to agree Bruno: I do not agree with this alternative approach, that would result in lots new node level signalling, and that would require the CP function to dispath the received information to all its PFCP entities. Giorgi: We discussed the matter in the Friday’s CC. Let me clarify our position and also summarize the state of the stalemate. Session message based solution (4251). I absolutely cannot accept this. Heartbeat message based solution (4073). Frank and Bruno absolutely cannot accept this. Association message based solution (explained in 4251). Frank can accept this, but Bruno cannot. We need to find a common ground. I’m willing to resolve the matter in this meeting and move forward by using Frank’s Rel-16 CR in 4272 as a basis. Looks like the third alternative is the only one that has realistic chance to succeed. Please give this another thought. Yvette: The DT view is if the information is at node level it makes sense that its signalling is also at node level. But using the heart beat procedure for that is wrong. The functionality is different. So any other proper node level message could be acceptable
CC4 CC6	4272	CR 29.244 0483 Rel-16 Report of UE IP address Allocation Status	Ericsson	Merged into a revison of 4417	WI CUPS-CT, TEI16 CAT F Clash with C4-204073, C4-204074 alternative proposal. Bruno: We support the principle of the CR. Please find below few technical comments: We should define a new feature to enable the CP or UP fcts to know whether the peer supports this functionality (e.g. no need for the UPF to report such information to CP function if the latter does not support the feature; also if the CP function supports this feature, the absence of @ status info from UPF would mean that there is no shortage of IP addresses if the UPF supports the feature, while it would not say necessarily so if the UPF does not support the feature). [Frank] Ok, I can define a feature which is applicable for CP and UP. But please have a second thought: In my view, an UP may be controlled by multiple CPs, regardless if the CP support the feature or not, the UP will provide anyway such information; It simplifies UP implementation; a CP need not really know if UP supports the feature, as long as it receives such information, the CP should consider the risk that UE IP address is running out and so to reduce/or not send further establish requests. Your suggestion below, to add a validity timer, would help when this information is changed from present to absent. In clause 5.21.3: "The UP function may report the UE IP address Allocation information to the CP function in the PFCP Session Establishment Response message ": Bruno> I don’t think this should be signalled only in PFCP session response, i.e. I would suggest to also allow reporting this info in PFCP Session Deletion Response? [Frank] Yes, I can add. "The UP function may include the UE IP address Allocation Information IE to the CP function in the PFCP Session Establishment Response message (with either rejection cause or acceptance cause), when the ratio of occupied IP addresses for certain UE IP Address Pool(s) and/or Network Instance(s) exceeds a configurable threshold, which triggers the inclusion; otherwise, the UP function may stop to include the UE IP address Allocation Information": Bruno> The solution shall not force to send the UE IP Address Information in every PFCP Session Establishment (/Deletion) Response, when the IP address usage is above the reporting threshold. So the absence of the UE IP address Allocation Information IE in a response shall not be interpreted as ‘usage of addresses has decreased below threshold’. The UPF should be able to report that the usage of @ has decreased beyond the threshold explicitly. Maybe it would also be useful to indicate a validity time such that if an SMF does not receive this new IE for a given network instance and/or UE IP address pool, it considers this info as no longer valid (otherwise, the UPF would need to track to which PFCP entity it has sent the info that there was a high usage of @). [Frank] Yes, I will add Validity timer Also when the UPF includes this new IE in a given response, I assume the UPF is free to include this IE for one, several or all network instances and/or IP address pool. In other words, it is not required to always include IEs for all network instances and/or IP address pools whose @ usage exceeds the threshold, right? [Frank]Yes. Table 7.5.3.x-1: Number of UE IP Addresses: "The available number of UE IP addresses ": what does ''available" mean here: all configured addresses (assigned and not assigned yet)? [Frank] Yes I understand that this nb actually depend on the type of addresses to be assigned, e.g. /64 prefix, /48 prefix, /128 addresses. So how is this number determined? [Frank] I think we could leave it as implementation specific. Is it OK ? Though I would assume it could be based on /64. Assuming we have 128 address, if it is requested to allocated /60, then 16 addresses are gone. And the rest comments will be captured in the revision 8.2.1: "All dynamic addresses are occupied": I propose to say “already assigned”. Typo: "assigned by UP functionbut, when all " 5.21.3 “The CP function may optimize the selection of UP functions based on the UE IP address Allocatoin” 8.2.x: please correct the (fixed) length in the figure. Ravi: We support this CR but have some question for clarification/comments. The following sentence needs some clarification: “The UP function may include the UE IP address Allocation Information IE to the CP function in the PFCP Session Establishment Response message (with either rejection cause or acceptance cause), when the ratio of occupied IP addresses for certain UE IP Address Pool(s) and/or Network Instance(s) exceeds a configurable threshold, which triggers the inclusion; otherwise, the UP function may stop to include the UE IP address Allocation Information.” Did you mean ratio or something else? [Frank] Yes, I meant ratio, e.g. a threshold may be configured with 90, so there is a risk that subsequent establishment request messages are rejected. Is there a typo here. If not then why and/or it should be just and. Please clarify? [Frank] UE IP Address Pool is optional on top of Network Instance; so the information is provided per UE IP address pool + network instance or per network instance My understanding of this parameter (UE IP address Allocation Information) is that it will indicate how much of UE Ips are already allocated. [Frank] Yes, through the UE IP Address Allocation Metric (ratio) x Number of UE IP Address 2. The IE UE IP address Allocation Information is not clearly defined. Can you clearly define it in the clause 5.21.3 before talking about it? [Frank] The UE IP address Allocation Information group IE definition is in PFCP Session Establishment Response message. Clause 5.21.3 is general description; in this spec, we always need read general description and detail IEs in the message (for group IE) and IE definition 3. In the subclause 7.5.3.1, can you please include brief description about this IE like other IEs are described in the table. [Frank] Yes, I can enhance it with yellow highlighted text as below " The UP function may include this IE to report the status of UE IP address allocation, if it supports the UP function allocating UE IP address feature and the feature is activated in the network. See also the clause 5.21.3. Is it OK? Ravi: Thanks Frank. I am okay with the proposed changes. Bruno: Thanks for your response. I still think it is worth defining a CP feature, to enable the UPF to not include the UE IP Address Info when the CP fct does not support this feature. I am fine on the other hand to not define a UP feature. For the Nb of IP addresses, cannot we suggest that this reports the nb of /64 prefixes by default, unless configured otherwise for a specific Network Instance and/or IP address pool, e.g. supporting individual 128 addresses? CC Bruno using association setup/update will increase the signalling additional messages. Giorgi: UE IP address is node level information Bruno: load and overload is also node level information and we put it in session management messages. Giorgi: the load overload solution should not dictate future solutions. Zhijun asks for more time. WE agreed to come to a conclusion in this meeting. Companies are asked to check and provide their opinion next week. Frank: I have made a v1 and hopefully captured all your comments. The link of the revision. https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.3.1/C4-204272_v1_3240_CR0448_29244_UE%20IP%20address%20Allocation.zip
CC5	4166	CR 29.244 0476 Rel-16 Number of occurrences for an event	Huawei	Revised to C4-204399	WI TEI16 CAT F Frank: Honestly I don't really see much value of the proposal. In case of threshold of event is reached, the SMF can easily know the number; otherwise, counting the number of time stamp(s) is also rather straight forward. Note that Event Time Stamp shall be included. Event Time Stamp: This IE shall be present, if the report is related to an event. When present, it shall be set to the time when the event occurs. Several IEs with the same IE type may be present to report multiple occurrences for an event for this URR ID. Caixia: Thank you, would be ok to add the new optional IE, and change the description to may as proposed by Bruno to avoid the counting of the time stamps? Bruno This CR does not solve a FASMO. Consequences if not approved: Extra handling in SMF; All of the Event Time Stamps included may be u nuseful. Bruno> The CR does not remove anyway the reqt to report the timestamp. It just adds a new meast nb in addition to the existing timestamps. 7.5.8.3: "This IE shall be present if an event measurement needs to be reported. (NOTE 2)": this looks a very strong reqt, e.g. this may be useless when reporting only 1 event (e.g. start of application traffic). I suggest to change to "may" (which is also in line with "O"). And this not applicable to Sxa. We also need to clarify that Event Measurement indicates the number of times the event was detected. 8.2.y: typo : “It contains an Unigned16 binary integer value.” Caixia: Draft v1 is available as below: https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.3.1/C4-204166%20TEI16%2029.244-Event%20Amount.docx Comments from Bruno are captured. Frank: We don't agree the change. As commented earlier, in case of threshold of event is reached, the SMF can easily know the number; otherwise, counting the number of time stamp(s) is also rather straight forward. And note that Event Time Stamp shall be included per existing specification. I don't think it is really an enhancement CC Frank the information is already there via time stamps no need send the numbers excplecitely.
4399	CR 29.244 0476 Rel-16 Number of occurrences for an event	Huawei	Postponed
4199	CR 29.244 0479 Rel-16 Interface Type of Traffic Endpoint	Nokia, Nokia Shanghai Bell	Agreed	WI TEI16 CAT F
4288	CR 29.244 0484 Rel-16 SMF-Set ID in PFCP Association Messages	Samsung	WI TEI16 CAT F Frank: We are fine with the changes. Just a few minor comments: In the Reason for change... incomplete sentence... e.g. " PFCP association (establishment) can be triggered by either SMF or UPF. " ; I think clause 5.22.3 should be also updated accordingly, e.g. in the step 1. "1) Each SMF in the SMF set shall establish its own PFCP association with the UPF and shall provide the Node ID IE set to an FQDN or IP address of the SMF and the SMF Set ID IE set to an FQDN representing the SMF set. All SMFs of an SMF set shall indicate the same SMF Set ID." Varini: Thank you for the review. I agree with your comments, I will update the CR and provide revision. Bruno: Cover page: please remove "The CR makes no changes to OpenAPI." (that is not applicable to this specification) How should the UPF behave when the SMF Set ID is changed by an SMF, e.g. wrt to existing PFCP sessions that were established in the SMF set with this SMF ? Varini Thank you for the review. I will update the same in revision. On your question, my first impression is that if the SMF Set ID changes, there need not be a tearing down of the sessions. Depending on UPF implementation, the UPF may need to update individual UE contexts, to indicate new backup SMFs, if any. I will further check this and get back. Frank: I agree with Varini's assumption, the existing PFCP sessions will stay. At failure, the UP function will look for alternatives pertaining to the new SMF set. Any issue? Bruno: Yes, I am fine with this behaviour and I suggest to specify this explicitly in clauses 5.22.2 & 5.22.3 Frank Should be only for 5.22.3 for MAPS. Ravi: I agree that PFCP session should not be teared down but still SMF needs to update the new SMF Set Id in all the ongoing PFCP sessions. This should be captured in the section “PFCP Association Update Request”. @Frank, I did not get your second point “At failure, the UP function will look for alternatives pertaining to the new SMF set.” What kind of failure you are hinting at? Giorgi Looks like the CR should also harmonize statements between with clause 7.4.4.3, which is in the CR and clause 5.22.3, which is not. Likely, 5.22.3 should be updated, I mean this one: “Likewise, when an SMF is added or removed from the SMF set, this SMF shall establish or tear down its PFCP association with the UPF”. Varini: I agree, I will update this in the revision. Giorgi: We support the CR. Few comments: Cover sheet: remove “The CR makes no changes to OpenAPI”. You introduced new IE type, the SMF Set ID. This needs to be added to the Table 8.1.2-1: Information Element Types and also defined separately. Varini: Thank you for the kind review and support. I will update the same in revision. On your 2nd bullet point, SMF Set ID is already used in PFCP Association Request message and defined in 8.1.2-1, we are just reusing it in the two new messages. Giorgi: My bad, you are right 
7.3.2	23.003	TEI16
4024	CR 23.003 0592 Rel-16 Editor's note in introduction sections	HuaWei	Revised to C4-204354	WI TEI16 CAT F Ulrich Work item code should be TEI16 Peter: Thanks draft v1 in Inbox: https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.3.2
4354	CR 23.003 0592 Rel-16 Editor's note in introduction sections	HuaWei
7.3.3	Diameter	TEI16
4080	CR 29.230 0687 Rel-16 AVP Codes for TS 29.214	Ericsson	Agreed	WI TEI16 CAT F
4213	CR 29.272 0823 Rel-16 Immediate Event Report in IDA	Ericsson	Agreed	WI TEI16 CAT F
4301	CR 29.171 0056 Rel-16 Corrections on Ciphering Data Set	Huawei	Merged into revision of C4-204274	WI TEI16 CAT F Ulrich Clash with 4274 Waqar: @Qingfen, would you like to merge your CR 4301 with 4274, since there is a complete overlap? Qingfen: I’m fine that your 4274 merges my 4301. Waqar: Please see draft merged CR in revision of 4274: https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.1.3/C4-204274_29171_PosSIB_r3.docx
4302	CR 29.272 0824 Rel-16 Corrections on Broadcast-Location-Assistance-Data-Types	Huawei	Revised to C4-204379	WI TEI16 CAT F Yvette: Is the purpose of this CR only for information? If not, please indicate the delimitation of the proposed changes. Table : Line 31 => delete the superfluous space Qingfern Thanks for spotting the issue, this CR is for change, therefore the name of delimitation is not right, I corrected it in draftv1 which was uploaded in server, please see https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.3.3/draftv1-C4-204302-CR0824-TEI16-29272-Corrections%20on%20Broadcast-Location-Assistance-Data-Types-R16.docx Other specs effected Ulrich: please delete the other comments on the cover page. Also: why is this linked to 23.501 CR 2302? Qingfen: Thanks for comment, the other comments on the cover page was clean up in new revision draftv1, please see https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.3.3/draftv2-C4-204302-CR0824-TEI16-29272-Corrections%20on%20Broadcast-Location-Assistance-Data-Types-R16.docx Ulrich: there is still Other comments: This CR won't introduce any impact on OpenAPI specification files. which is not appropriate text for a CR to 29.272 (Diameter). Please remove. Qingfen: Thank you for spotting it, I cleaned the content of Other comments: in new revision C4-204379, I’ll upload it later
4379	CR 29.272 0824 Rel-16 Corrections on Broadcast-Location-Assistance-Data-Types	Huawei
7.3.4	AMF	TEI16
4111	CR 29.518 0379 Rel-16 Clarification on Max Number of Reports	ZTE	Revised to C4-204368	WI TEI16 CAT F Anders: The new proposed NOTE 1 as suggested reads: NOTE 1: If the AmfEventTrigger is set to "CONTINOUS", at lease one of the "maxReports" and "expiry" attributes shall be included. If the "maxReports" attribute is required while no value from UDM is receivce, maximum value shall be set to the "maxReports" attribute by default. In the discussion on C4-204127, Jésus indicated that the stage 2 states: "The requester shall include 2) Maximum number of reports or 3) Maximum duration of reporting, or both, depending on 1) Event reporting mode." Thus, it is not clear that if the maxReports is missing, the AMF should use a default value for maxReports, rather it seems to suggest that the AMF should report until the expiry time has been reached and thus the number of reports is unbound. Also, on the cover sheet, the spec# should be 29.518. Zhijun: The intention is to make it clear how to set the "maxReports" if no value is received from the UDM. One possibility is: if the "expiry" is set, the AMF keeps reporting until the time expires. Another possibililty is to set a configured default value to the "maxReports" and don't expect to keeping reporting until the timer expires. Both are fine for us because the intention is just to get clear instruction on how to set this "maxReports". I am fine to update it to "set the maxReports to a default value (e.g. by local configuration)". I will reflect your comments to the v1 and correct the errors. Anders: It was my bad; I did not mean that there should be a default value by configuration, I meant the opposite, that if the expiry time is given, but no maxReports, then the AMF will have to submit reports until the timer expires, i.e. there is no limit on the number of reports, just the time Zhijun: Sorry I didn't catch your point correctly. So you proposal is to either use the "expiry" or "maxReports" to control the report when "CONTINOUS" report is required? Then the condition to "maxReports" needs to be updated, because it currently says: "This IE shall be present if the trigger is set to "CONTINUOUS"." How about the following changes: This IE shall be present if the trigger is set to "CONTINUOUS" while "expiry" is not present. When present NOTE 1: If the AmfEventTriggeris set to "CONTINOUS",at least one of the "maxReports" and "expiry"attributes shall be included. Jones: I share the same view with Anders. Also, the expiry shall anyway be assigned by the service producer (AMF here) and indicated it to the subscriber (in fact this is regardless of whether maxReports is included or not). Expiry: This IE shall be included in an event subscription response, if, based on operator policy and taking into account the expiry time included in the request, the AMF needs to include an expiry time. This IE may be included in an event subscription request. When present, this IE shall represent the time after which the subscribed event(s) shall stop generating report and the subscription becomes invalid. If the trigger value included in an event subscription response is "ONE_TIME" and if an event report is included in the subscription response then the value of the expiry included in the response shall be an immediate timestamp. (NOTE 1) Additionally, in the reason for change, it is said “However, in the Nudm interface, the maxNumOfReports is not required to be included if the ReportMode set to "PERIODIC", as specified in clause 6.4.6.2 of TS29.503.”, but then “repPeriod” shall be present to control the reporting duration. repPeriod: This IE shall be present if the trigger is set to "PERIODIC". When present, this IE describes the period time for the event reports. If the AMF event subscription is for a group of UEs, this parameter shall be applied to each individual member UE of the group. Together with expiry, the AMF/UDM can safely avoid any possibility of endless subscription with current specification. Yvette: Same comments as C4-204110. Please correct some misspelling in the new added text in NOTE 2 as follows …at lease one => at least one Also on the cover page : Missspelling in the title : Clairification on Max Number of Reports In the reason for change : at lease one => at least one „Consequence if not approved“ is missing Zhijun: Thank you for spotting these errors. I have corrected them in v1. https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.3.6/C4-204110_v1_TEI16_29503_Max%20Number%20of%20Reports.docx Caixia: Please check my comments for this contribution: Consequences if not approved is empty. The added NOTE indicates at least one of the "maxReports" and "expiry" attributes shall be included. Which means the maxReports can not be included, but the following sentence give a hint the maxReports shall be included, update the NOTE is needed. Bruno: Cover page: wrong TS nb, CoNA is empty. Typo in CR title. The reason for change is not clear to me (the 2 following statements relate to different report mode): "In the Namf interface, the maxReports attribute is required to be inlucded if the AMF event trigger is set to "CONTINUOUS", as specified in clause 6.2.6.2.6 of TS29.518. However, in the Nudm interface, the maxNumOfReports is not required to be included if the ReportMode set to "PERIODIC", as specified in clause 6.4.6.2 of TS29.503." 6.2.6.2.6: NOTE 1 : "If the AmfEventTrigger is set to "CONTINOUS", at lease one of the "maxReports" and "expiry" attributes shall be included. If the "maxReports" attribute is required ") This contradicts existing reqt that maxReports "shall be present if the trigger is set to "CONTINUOUS". " Typos in NOTE 1. NOTE 1 is also not clear: "If the AmfEventTrigger is set to "CONTINOUS", at lease one of the "maxReports" and "expiry" attributes shall be included. If the "maxReports" attribute is required while no value from UDM is receivce, maximum value shall be set to the "maxReports" attribute by default." Yellow statements seem to contradict. What does the blue statement mean? maxReports is defined as an integer, so which value would be indicated?
4368	CR 29.518 0379 Rel-16 Clarification on Max Number of Reports	ZTE	Bruno: Typo: NOTE 1: If the AmfEventTrigger is set to "CONTINOUS", at lease one of the "maxReports" and "expiry" attributes shall be included.
4112	CR 29.518 0380 Rel-16 Event Reort in Response to AMF Event Subscription Update	ZTE	Revised to C4-204369	WI TEI16 CAT F Jones I am fine with the concept to carry immediate event report in Subscription update response, but it should be applicable to newly added events in the subscription modification, instead of “immediateFlag attribute in at least one of the AMF event subscription(s) is changed to true”, i.e. the immediate flag should only be appliable to new subscribed event but not ongoing events. Immediate report in response should not be applicable for subscriptions on behalf of another NF, see NOTE 1 in AmfCreatedEventSubscription. It should be helpful to provide some text in clause 5.3.2.2.3 to complete the CR, similar like in 5.3.2.2.2. Zhijun: Thanks for the comments, I will check the details of your suggestion. Before that, let me confirm the basic principle you said: I understand for newly subscribed event set the "immediateFlag" is fine. But not sure: Do we forbid to change the "immediateFlag" attribute from "false" to "true" for an existing subscription? Caixia: Similar comments, the Consequences if not approved is missed. And I think if the immediateFlag is changed to true, the AMF needs to report only if the event is happened, right? Bruno: Cover page: CoNA empty, typo in CR title Other Comments: "This CR introduces backward compatible changes " -> corrections. Is this really FASMO ?? 6.2.6.2.15: NOTE: "If immediateFlag attribute in at least one of the AMF event subscription(s) is changed to true, immediate event report(s) of the corresponding AMF event subscription shall be provisioned if available." "shall be provisioned if available." -> "provided". "is changed to true" or "is set to true"? Zhijun: Thanks for the comments. I will correct those errors. Regarding the FSMAO, as Jones indicated, if there is new subscription added with "immediateFlag" set to "true" during AMF event subscription update procedure, the report shall be returned if any. What's is remaining is, as I commented to Jones, whether we can change an existing event subscription from "immediateFlag"="false" to ="true".
4369	CR 29.518 0380 Rel-16 Event Reort in Response to AMF Event Subscription Update	ZTE	Bruno: Repeating some of my earlier comments typo in CR title Other Comments: "This CR introduces backward compatible changes " -> corrections. 6.2.6.2.15: NOTE: "If immediateFlag attribute in at least one of the AMF event subscription(s) is changed to true, immediate event report(s) of the corresponding AMF event subscription shall be provisioned if available.": " -> "provided".
4168	CR 29.518 0382 Rel-16 Callback URI correction	Huawei	Agreed	WI TEI16 CAT F
4172	CR 29.518 0383 Rel-16 Definition of DRX	Huawei	Revised to C4-204383	WI TEI16 CAT F Bruno: This CR is an essential correction that needs to be agreed from Rel-15 onwards (since the DRX parameters are defined differently in the related 24.008 and 24.501 clauses). Caixa: Thank you, I will prepare and submit R15 CR, and revise this paper as R16 mirror CR.
4383	CR 29.518 0383 Rel-16 Definition of DRX	Huawei
4173	CR 29.518 0384 Rel-16 Update of the PRA Info	Huawei	Revised to C4-204400	WI TEI16 CAT F Bruno There are two issues addressed by this CR: misalignment between the OpenAPI and main specification on the PATCH Request Body when it contains an AmfUpdateEventSubscriptionItem: the OpenAPI only allows to encode oneAmfUpdateEventSubscriptionItem, whereas Table 6.2.3.3.3.1-2 specifies a 1..N cardinality. This means that with the current OpenAPI, one PATCH request can only modify one event of a subscription that would contain multiple events. the AMF API does not enable to modify individual attributes of an AMF event, it only allows to modify an AMF event by replacing it with a new AMF event description. On 1), the proposed corrections match the table definition and original intention of the spec, however the OpenAPI change as such is not backward compatible. Note that if we align the OpenAPI on Table 6.2.3.3.3.1-2 in Rel-16, Rel-15 needs also be corrected, otherwise we would have inconsistent OpenAPI definitions in Rel-15 & 16 and backward compatibility issues, since Rel-16 NF would support sending/receiving an array of (possibly one only) AmfUpdateEventSubscriptionItem, while Rel-15 NFs would support sending/receiving only a single AmfUpdateEventSubscriptionItem outside of any array. We agree that we need to fix asap the specification inconsistency (i.e. 1)). We could agree with the proposed corrections. On 2), it is disputable whether the issue is FASMO. The changes here appear more as providing additional flexibility i.e. as an enhancement of the existing API. I see no urgency to correct the 2nd issue in Rel-16: this can be done in Rel-17, in a separate CR, and this has to be specified in a backward compatible manner. Jones: 1/ The change to AmfUpdateEventSubscriptionItem as array in OpenAPI is not backward compatible change. It should be change in opposite, i.e. fix the cardinality in table to “1”. AmfUpdateEventSubscriptionItem object can modify the whole eventlist or one item in the event list. Using single AmfUpdateEventSubscriptionItem already allow the consumer to update multiple events by replace the whole event list. Actually manipulate multiple events in the list with multiple AmfUpdateEventSubscriptionItems within one PATCH is even risky because the json pointer to array item is based on index and the index may be changed when add/remove events from the list. 2/ To allow SMF to update PRA info maybe reasonable, but the proposed change to allow updating any information on the subscriptions is risky (this is why we explicitly created AmfUpdateEventSubscriptionItem and AmfUpdateEventOptionItem in order to indicate explicitly which information are allowed to be changed. Additionally, the proposed change is backward incompatible either. We need more time to evaluate the needs, and if needed to provide a better and compete solution on next meeting. Caixia: We are fine to give more time to evaluate and find backward compatible solutions on this issue. For the cardinality of AmfUpdateEventSubscriptionItem, I am OK to fix the table to 1, which can avoid the backward incompatible impact. Please check the draft v1 in inbox. One issue I have different understanding is, based on the above change, the consumer is only allowed to update one event, if multiple events in single subscription need to be modified, consumer has to send several Patch messages. We will also consider how to optimize this mechanism in next meeting. 6.2.6.2.14 Type: AmfUpdateEventSubscriptionItem Table 6.2.6.2.14-1: Definition of type AmfUpdateEventSubscriptionItem AmfEvent cardinality 0..1 Caixia: For 2nd issue, we are fine to consider the backward compatible manner in R17 to give the flexibility on update of the information in subscription, and avoid sending several PATCH messages to update the multiple events in single subscription. For 1nd issue, I have revised the contribution to change the cardinality to 1 to avoid the backward incompatible impact and inconsistent OpenAPI in Rel-15 and R16. Please check the draft v1 in inbox, contribution title is also updated Bruno I have the same understanding as Caixia on the first issue. With the current OpenAPI, the subscribing NF can modify only one event in a PATCH request. Path, string: This IE contains a JSON pointer value (as defined in IETF RFC 6901 [40]) that references a location of a resource on which the patch operation shall be performed. This IE shall contain the JSON pointer to a valid index of the "/eventList" array in the AMF Event Subscription, formatted with following pattern: '\/eventList\/[0-]$|\/eventList\/[1-9][0-9]*$' Example: "/eventList/0" stands for the first member of the array; "/eventList/10" stands for the 11th member of the array; "/eventList/-" stands for a new (non-existent) member after the last existing array element. Only allowed with "add" operation. Value, AmfEvent, This IE indicates a new AMF event to be added or updated value of an existing AMF event to be modified. It shall be present if the patch operation is "add" or "replace" Jones: Thanks for the change. V1 draft is fine for me. Concerning for the AmfUpdateSubscriptionItem, you are right that currently it only allows with change of only one event (as also stated by Bruno). I always has the impression that AmfUpdateSubscriptionItem supports modifying the whole eventlist with a JSON pointer without index in the specification. I am wrong, but maybe we could extend AmfUpdateSubscriptionItem this way to support update on multiple events with one PATCH instead of change the content in body to an array. Let’s discuss further on this for a solution for next meeting. Bruno: This CR corrects an inconsistency between the message table and the OpenAPI (cardinality 1.N vs. 1). Shouldn’t the CR be agreed from Rel-15 onwards, to avoid risks of interoperability issues?
4400	CR 29.518 0384 Rel-16 Update of the PRA Info	Huawei
4205	CR 29.518 0385 Rel-16 Identifier of the NF service consumer sending an N1 message	Nokia, Nokia Shanghai Bell	WI TEI16, 5GS_Ph1-CT CAT F Jones: I have a question on this CR: what are the expected behaviour for AMF to handling the nfId in N1N2MessageTransfer? Bruno: This enables the AMF to know the sender of the N1/N2 message and e.g. to not forward a late arriving N1/N2 PDU when the AMF would have reselected a different SMF producer instance during a PDU session establishment procedure. Cf the use case described in Reason for Change An AMF or SCP may reselect a different SMF producer instance during a PDU session establishment if it does not receive a Create SM Context response from the originally selected SMF instance. Upon receipt of a subsequent N1/N2 Message Transfer Request (e.g. including N1 and N2 PDUs), the AMF cannot determine whether this request was issued by the newly or originally selected SMF.” and the CoNA (problem found on the field).
4207	CR 29.518 0386 Rel-16 Clarifications to EBI Assignment procedure	Nokia, Nokia Shanghai Bell	Agreed	WI TEI16, 5GS_Ph1-CT CAT F
4264	CR 29.518 0394 Rel-16 Additional PraId	Ericsson	Revised to C4-204449	WI TEI16 CAT F Caixia: Clause affected is incomplete; Other specs affected, shall link to TS 29.500 CR? (See NOTE 1) (See NOTE x), change to (See NOTE 1, NOTE X) Please check whether multiple additional IDs are allowed. /Jones: replied in response to CR 4270. The plurality is handled with multiple event reports, instead of multiple additional PRA IDs in one PresenceInfo data type. And as the change to TS 29.571 will impact other APIs reuse the presenceInfo, but the additional PRA ID is only used in this interface, may be the better way forward is define in additional PRA ID in AmfEventArea. /Jones: we suggested to include the additional PRA ID in PresenceInfo, where the presenceState attribute is specified. Because the presence State will indicating the IN/OUT state associate with the additional PRA ID and should better be in the same place. Bruno: "If the AMF event is subscribed with a PRA identifier referring to a Set of Core Network predefined Presence Reporting Areas, the AMF shall report both the subscribed PRA Identifier and the additional PRA identifier(s) of the actually individual PRA(s) where the UE is currently IN / OUT, as specified in clause 5.6.11 of 3GPP TS 23.501 [2]." How to handle the case of an AMF supporting the changes and an SMF complying with the current version of the spec. The AMF may report in a same notification: - PRA SET ID X, PRA 1, OUT - PRA SET ID X, PRA 2, IN SMF would receive "PRA SET ID X, IN" and "PRA SET ID X, OUT". Jones: This is a really good point. First of all, I think specify a new feature (APRA: Additional PRA) could be helpful for AMF to decide how to proceed. Then, if the peer SMF doesn’t support APRA, the AMF may: Option1: Set the Additional RRA in PraId directly in event reports and hopefully the SMF will forward the PraId to the PCF, which is actually align with the SA2 expectation that PCF receive the Additional PRA ID; The risk is that if the SMF explicitly matching the PraId for certain internal logic, i.e., to correlate the subscription using the PRA ID, the matching will fail (PRA SET ID in Subscription creation and additional PRA ID in reports). Option2: AMF only report UE move in/out the large PRA representing the whole PRA Set, i.e. see the PRA Set as a very large PRA. This is compatible with legacy behavior and will 100% safe to pass the SMF behavior. The drawback is that the meaning of PRA SET is totally lost, where the expected granularity on PRA reporting will not working if Policy triggering really relay on this. Option3: Additional feature support negotiation of SMF supporting APAR via N7 between PCF/SMF, i.e. the PCF only subscribe the PRA set when the SMF indicated supporting it. Otherwise, it always subscribe to individual PRAs within the set accordingly. Any view? Jones: Please V1 draft in Inbox/Drafts/7.3.4. The main changes: Optional feature “APRA” specified to control the behavior of event reporting Table note added to specify the fallback behavior, i.e. , if NF consumer doesn’t support “APRA”, AMF sets the individual RRA ID in praId IE in event report (Option-1 below). Untick affected specs Correct affected clauses field Bruno: Thanks, I agree with the changes in principle. Few editorials below: 6.2.6.2.16 - first note needs to be renumbered NOTE 1 - NOTE x: If the subscription is for a Set of Core Network Predefined Presence Reporting Areas and both the AMF and the NF service consumer supports the "APRA' feature, the PRA Identifier for the Set shall be carried in the "praId" IE and the individual PRA identifier shall be carried in the "additionalPraId" IE; if the subscription is for a Set of Core Network Predefined Presence Reporting Areas and the AMF or the NF service consumer does not supports the "APRA' feature, the individual PRA identifier shall be carried in the "praId" IE and the "additionalPraId" IE shall not be present. 6.2.8 Additional Presence Reporting Area An AMF that supports this feature shall support subscription of "PRESENCE_IN_AOI_REPORT" event with a Set of Core Network Predefined Presence Reporting Areas and generating event report including both PRA Set ID and additional PRA ID referring to an individual PRA in the Set. An NF consumer that supports this feature shall support receiving "PRESENCE_IN_AOI_REPORT" event with additional PRA ID referring to an individual PRA in the Set.
4449	CR 29.518 0394 Rel-16 Additional PraId	Ericsson
4265	CR 29.518 0395 Rel-16 PCF Group Id	Ericsson	Revised to C4-204450	WI TEI16 CAT F Jones Please find V1 draft in /Inbox/Draft/7.3.4. The only change is untick the affected Spec field.
4450	CR 29.518 0395 Rel-16 PCF Group Id	Ericsson	Agreed
4283	CR 29.518 0401 Rel-16 Correction of n2InfoNotifyUrl in figures	Qualcomm Incorporated	WI TEI16 CAT F Bruno: The correction should be done in the other way around. n2InfoNotifyUri is correct. Changes to the figures should be reverted. Waqar: Thanks Bruno, I have updated this in: https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.3.4/C4-204283_29518_URL_v1.docx Though I’m still missing the linkage of n2InfoNotifyUri to where its configured by n2NotifyCallbackUri/n2NotifyCallbackUri, neither refer to their relation with the other, all have unique names. I don’t know if we have a consistent policy, e.g. referring to N2InfoNotify clause from description of e.g. n2NotifyCallbackUri could make things consistent. Anyway, I don’t want to open some can of worms here so would just let it be 😊
7.3.5	SMF	TEI16
CC5	4167	CR 29.502 0369 Rel-16 Callback URI correction	Huawei	Revised to C4-204401	WI TEI16 CAT F Bruno: We agree with the overall intent of the CR, which is to re-assert that there is no specific restriction in 29.502 on how the V-SMF/I-SMF sets the vsmfPduSessionUri or ismfPduSessionUri it sends to the H-SMF/SMF. The V-SMF/I-SMF is free to select any URI structure it wishes. The OpenAPI defines the “{vsmfPduSessionUri}/modify” as callback URI, where vsmfPduSessionUri is whatever URI provided in this attribute in the request. General comment on the proposed changes: you add “callback” in several places e.g. "a callback URI ({vsmfPduSessionUri} or {ismfPduSessionUri})". The callback URI is actually {vsmfPduSessionUri}/modify Zhijun: Comments from my side: - I understand that this URI is provided by V/-ISMF and it can be in customized structure. But in the specification the title of clause 6.1.3.7 says "Resource: Individual PDU session (V-SMF or I-SMF)". And the resource appears in the resource tree. - One more thing I fell not so much confortable is, we don't define any customize operator to the callback URI, but "/modify", "/release" are patched to you mentioned Callback URI as custom operation. Right? - If we let the I-SMF/V-SMF to generate the ismfPduSessionUri / vsmfPduSessionUri as per the resource tree expressed, is there any harm? Caixia: In OpenAPI, it is clearly defined the related URIs are callback URI, I do not want to make the backward incompatible changes to OpenAPI. callbacks: statusNotification: '{$request.body#/vsmfPduSessionUri}': statusNotification-ismf: '{$request.body#/ismfPduSessionUri}': update: '{$request.body#/vsmfPduSessionUri}/modify': update-ismf: '{$request.body#/ismfPduSessionUri}/modify': transferMtData: '{$request.body#/vsmfPduSessionUri}/transfer-mt-data': transferMtData-ismf: '{$request.body#/ismfPduSessionUri}/transfer-mt-data': If you think the Table 6.1.3.1-1: Resources and methods overview causes confusion, maybe we can discuss with Bruno on how to enhance the Table. Caixia: Draft V1 is available as below, updates the description in first and second changes: https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.3.5/C4-204167_V1_TEI16%2029.502-Callback%20URI.docx CC Zhijun will check latest draft Bruno does not think that the table has any ambiguity but he will check offline.
4401	CR 29.502 0369 Rel-16 Callback URI correction	Huawei	Bruno: - a callback URI ({vsmfPduSessionUri} or {ismfPduSessionUri}) representing the PDU session resource in the V-SMF or I-SMF, for possible use by the SMF to subsequently notify the status of the PDU session. Based on the {vsmfPduSessionUri} or {ismfPduSessionUri} received, the SMF shall modify or release the PDU session using the callback URI {vsmfPduSessionUri}/modify or {ismfPduSessionUri}/modify, or shall transfer mobile terminated data received from NEF using the callback URI {vsmfPduSessionUri}/transfer-mt-data or {ismfPduSessionUri}/ transfer-mt-data; The first highlighted text is just a subset of the possible operations. The 2nd highlithed part (release , modify) does not seem correct. Release is signalled via a status notify. More generally, this text will be hard to maintain, when we add new service operations; Can we replace all these changes by a simpler statement (e.g. saying that SMF shall construct the callback URIs based on the received ({vsmfPduSessionUri} or {ismfPduSessionUri} as defined in clause 6.1, e.g. the callback “{vsmfPduSessionUri}/modify” to modify a PDU session in the V-SMF).
4169	CR 29.502 0370 Rel-16 Request Type	Huawei	Revised to C4-204402	WI TEI16 CAT F Jones: The last change in the table NOTE brings no much value, it rather misleading with the added text because the first sentence and the rest are not consistent. I suggest we revert the last change, the current definition of Request Type is already good enough Bruno: we agree with the principle of the CR. 5.2.2.2.1: the proposed changes contradict with the following text by now precluding to insert this IE when it is not directly received from the UE: “ -the Request Type IE, if it is received from the UE for a single access PDU session and if the request refers to an existing PDU session or an existing Emergency PDU session; the Request Type IE shall not be included for a MA-PDU session establishment request; it may be included otherwise; “ We should then strike this last part. 5.2.2.2.1: "i.e. indicating that this is a request for an existing PDU session or an existing emergency PDU session requested by the UE)". We can just say: ""i.e. indicating that this is a UE request for an existing PDU session or an existing emergency PDU session". 5.2.2.7.1: ditto 6.1.6.2.2: "This IE shall be present if the request relates to an existing PDU session or an existing emergency PDU session requested by the UE, except during an EPS to 5GS idle mode mobility or handover using the N26 interface. It may be present otherwise" Ditto. The resulting text looks inconsistent with the changes. We need to strike the last sentence. 6.1.6.2.9: ditto 6.1.6.3.5: if we keep the changes: "defines corresponding values" "also defines a specific Request type " I am fine reverting these changes, as proposed by Jones. Caixia: Based on the comments received, I have revised the contribution into Draft v1. Last change it reverted. Description in other clauses updated to support the case--it may be included otherwise. One question is for the UE mobility with I-SMF insertion, based on the condition, seems it may also be allowed to include the request type, but I think the receiving node shall not consider it is an error if the request type is absent in this case. Is my understanding correct?
4402	CR 29.502 0370 Rel-16 Request Type	Huawei	Bruno: I thought your intention was to only allow to include the Request Type when this IE when this IE is received from the UE, and if so, we could have considered to strike the text “it may be included otherwise”. I think this was ok in principle. In reason for change: Create SM Context service operation and Create service operation are extended in R16 to support, e.g. the procedues with I-SMF/V-SMF insertion, change, it is shall also be indicated that the Request Type shall not be present. And your question below: One question is for the UE mobility with I-SMF insertion, based on the condition, seems it may also be allowed to include the request type, but I think the receiving node shall not consider it is an error if the request type is absent in this case. Is my understanding correct? In scenarios where Request Type is provided by UE, e.g. 3GPP to non-3GPP access mobility, or EPC to 5GC mobility w/o N26, with I-SMF insertion, this info will be sent to I-SMF and then forwarded to the anchor SMF. So the reason for change does not seem correct. Do you agree? Your changes in your revision are also agreeable to me (but cover page needs to be corrected).
4256	CR 29.502 0375 Rel-16 Handover Cancel 5GS to EPS	Ericsson	Revised to C4-204443	WI TEI16 CAT F Caixia: I think we can reuse the handover cancellation defined in clause 5.2.2.3.4.4 for source AMF to source SMF. Another alternative is to extend the 5.2.2.3.13A to support the removal from source AMF to source SMF. /Jones: We prefer to keep the change in clause for 5GS to EPS handover service procedure which best fits the scenario. Clause 5.2.2.3.4.4 is for N2 handover and 5.2.2.3.13A is for I-SMF involved procedures, which means if we include the change there, the clause will need to be re-titled. We prefer not to do that. Bruno: small editorial enhancements: "If indirect data forwarding tunnel(s) have been previously established during the handover preparation phase and the handover is cancelled" /Jones: Fixed. Jones: Please find V1 draft in /Inbox/Drafts/7.3.5. Caixia: For my suggestion, actually, I have a question on this scenario, how to support the handover cancel if the I-SMF is involved in source side? Jones: For 5GS to EPS handover cancellation, whether I-SMF is involved or not is regardless from AMF perspective. The indirect communication tunnel is setup if needed on the SMF where SM Context hosts. If I-SMF is not there, the indirect data forwarding tunnel will be setup by SMF; if I-SMF is there, the indirect data forwarding tunnel will be managed by I-SMF. If the handover is cancelled, then the indirect data forwarding tunnel will be removed on that SMF correspondingly. The clause 5.2.2.13A is for scenarios with I-SMF insertion/change/removal during N2 based handover, where the indirect forwarding tunnel is between I-SMF and SMF. Caixia: Actually, I think a separate clause for handover cancel during IWK with EPS using N26 may be better, either reuse the dedicated clauses I listed or a new subclause for this case if you do not want to change the title of the current clauses. As for clause 5.2.2.3.9, it is named as Figure 5.2.2.3.9-1: 5GS to EPS Handover using N26 interface (data forwarding tunnels setup), but you will define the forwarding tunnel removal. Similar with the 5.2.2.3.8 EPS to 5GS Handover using N26 interface, we can restructure the 5.2.2.3.9 similar like below: 5.2.2.3.9.1 general 5.2.2.3.9.2 5GS to EPS with data forwarding tunnels setup 5.2.2.3.9.3 5GS to EPS handover cancellation And you can simply add the description in 5.2.2.3.9.3, in addition, we may need to indicate for 5GS with I-SMF insertion, the message is sent from AMF to I-SMF, and will not trigger the message from I-SMF to SMF. Bruno: Thanks, your revision is fine by me. I agree with NOT re-using clause 5.2.2.3.4.4: hoState is not used in 5GS to EPS handover. Jones: Please find V2 draft in Inbox/Drafts/7.3.5. As per Caixia’s suggestion, new sub-clauses are added under 5.2.2.3.9 for indirect data forward tunnels setup and removal. Please check whether the changes are fine for you. Thanks!
4443	CR 29.502 0375 Rel-16 Handover Cancel 5GS to EPS	Ericsson
4258	CR 29.502 0377 Rel-16 Service Access Authorization between SMFs	Ericsson	Revised to C4-204445	WI TEI16 CAT F Giorgi: Editorials on the cover sheet: Other specs affected /Jones: Fixed. Other comments: please enable spellcheck for the cover sheet and apply it /Jones: Fixed. Bruno: 6.1.6.2.2.2 editorial "If present, this IE shall carry the NF instance ID(s) of H-SMF(s) as stated in additionalHsmfUri IE, in exactly the same order. (NOTE x)" /Jones: Fixed Typo in smContextSmfId description: "indeitified by smContextRef IE" /Jones: Fixed "NOTE x:If Oauth is enabled for the indicated SMF, the new SMF shall use the NF instance Identifier to acquire the access token for the Nsmf_PduSession service on the indicated SMF." Does this infer that the I/V SMF shall do a discovery of the H-SMF/SMF to determine if OAuth2 is required? How is this determined? /Jones: The SMF may discover it from the NRF. But by definition, absence of the oauthRequired doesn’t indicate it is not required. Thus better solution is to relay on response code e.g. “401 Unauthorized” to discover the Oauth is required. Of course, once the SMF has previously acquired access token for next hop SMF, it may cache the token with associated with the SMF ID. Thus next time, if the same next hop SMF is targeted, the SMF get known from the cache and include the access token. the term "new SMF" looks confusing, e.g. the reqts should also apply to the anchor SMF to retrieve the SM context from the old I-SMF (when removing an I-SMF). /Jones: change to “SMF” only, which means the SMF handling the service operation. I propose to rename SERVICE_AUTHORIZATION_FAILED_NEXT_HOP to SERVICE_NOT_AUTHORIZED_BY_NEXT_HOP /Jones: Fixed. "the SMF is not allowed to access service " -> not authorized /Jones: Fixed. Jones Please find V2 draft in /Inbox/Drafts/7.3.5. Giorgi: Thanks Bruno: Ok, thanks, v2 is fine by me.
4445	CR 29.502 0377 Rel-16 Service Access Authorization between SMFs	Ericsson
7.3.6	UDM	TEI16
4068	CR 29.503 0462 Rel-16 Deregistration Notification	Samsung, Hewlett-Packard Enterprise	WI TEI16 CAT F Ravi: We support this CR but have one question for clarification comments. Should we not take the decision of deregistration based on the outcome of registration? I think the decision of deregistration should depend on the outcome of registration. If the new registration fails then new AMF (same as old) should continue with the deregistration to clean up the UE context from UDM. What is your take on this? Varini: Thank you for your kind review and support. I agree with your comment that decision to remove UE in old AMF should be linked to registration progress in the new AMF. In case of connected-mode Inter-AMF handovers, Nudm_UECM_Regn is performed as part of registration procedure, which happens after successful handovers, hence this works fine. In case of idle-mode mobility, Nudm_UECM_Regn happens immediately after successful authentication, and hence deregistration notification will be triggered before UE receives registration accept in new AMF. This, however is ok IMO, as a) authentication happens after having retrieved UE context from old AMF, and b) if registration fails after this step (e.g. due to no slices available in new registration area), UE can anyway not be allowed service Varini: Revision v1 is available in drafts folder. This merges changes done for C4-204076 into this CR. https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.3.6/C4-204068v1.zip Anders The updated CR looks good to me
4109	CR 29.503 0469 Rel-16 S-NSSAI in SM Context Retrieval	ZTE	Revised to C4-204366	WI TEI16 CAT F Anders: There is a discrepancy in the CR in that in the data model, clause 6.1.6.2.17 – PduSession, the new attribute singleNssai is marked as Mandatory, but in the yaml section it is not. Given that introducing a new mandatory attribute is not backward compatible, is there a drawback in making the new attribute optional in both clauses? Zhijun: Thanks for your comments. Considering the backward compatibility issue you commented, I think it is fine to make it as optional. An NOTE is added to suggest to carry the S-NSSAI to support selection of same SMF, if UE requests multiple PDU sessions establishment with the same DNN and same S-NSSAI. V1 is uploaded to the server: https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.3.6/C4-204109_v1_TEI16_29503_S-NSSAI%20in%20SM%20Context%20Retrieval.docx Anders: Your proposed changes looks good to me
4366	CR 29.503 0469 Rel-16 S-NSSAI in SM Context Retrieval	ZTE
4110	CR 29.503 0470 Rel-16 Clarification on Max Number of Reports	ZTE	Revised to C4-204367	WI TEI16 CAT F Yvette Please correct some misspelling in the new added text in NOTE 2 as follows …at lease one => at least one Also on the cover page : Missspelling in the title : Clairification on Max Number of Reports In the reason for change : at lease one => at least one „Consequence if not approved“ is missing
4367	CR 29.503 0470 Rel-16 Clarification on Max Number of Reports	ZTE
4170	CR 29.503 0476 Rel-16 Dedicated SMF selection	Huawei, Samsung	Revised to C4-204415	WI TEI16 CAT F Ericsson to be added as co-source Caixia: Thank you, I will add Ericsson as co-source in the revision.
4415	CR 29.503 0476 Rel-16 Dedicated SMF selection	Huawei, Samsung, Ericsson
4259	CR 29.503 0481 Rel-16 Same SMF Indication	Ericsson	Merged into 4170	WI TEI16 CAT F Ulrich it seems that this one is clashing with 4170. Jones This CR can be merged to 4170.
7.3.7	NSSF	TEI16
4061	CR 29.531 0072 Rel-16 Essential correction to event SNSSAI_STATUS_CHANGE_REPORT	Orange, Huawei	Agreed	WI TEI16 CAT F
4070	CR 29.531 0073 Rel-16 Slice selection based on Load Analytics Information from NWDAF	Samsung	WI TEI16 CAT F Ravi In principle we support this CR. But I have one comment for using this line “The NSSF may consult NWDAF to determine slice load level information and exclude slices which are beyond a configured threshold.” Can you rephrase it with something like “NSSF may consider load level information for a Network Slice instance, provided by the NWDAF, to exclude slices which are overloaded.” Varini: Thank you for the kind review and support. I agree with your suggestion and will update it in revision Bruno I don't think that this CR is really necessary. It does not specify any protocol change and just partially replicates stage 2 reqts (i.e. criteria that NSSF may use to select the authorized S-NSSAIs). (If CT4 proceeds with this CR, I suggest to replace "intimate" by "include") Varini: The reason our engineering team wanted this to be reflected in NSSF Spec is to indicate that NSSF provides not just “Authorized” NSSAIs as per subscription and/or per-TA-capability; but also NSSAIs “allowed” as per load-level analytics provided by NWDAF. Without this, I think we would have to assume that this behaviour is implicit. I agree this does not involve any protocol change, but would like to add this for better clarity. Let me know if this would be fine. Varini: Revision v1 is available in drafts folder: https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.3.7/C4-204070v1.zip Bruno: Thanks for your response. I can accept proceeding with your revision.
4113	CR 29.531 0074 Rel-16 TAI Range List Served by an AMF	ZTE	Revised to C4-204370	WI TEI16 CAT F Jones: The new attribute should be applicable to ONSSAI optional feature. Consequence not approved is empty Jesus: In addition to the comment above, the CR needs to say how "taiList" (which is a mandatory attribute, and cannot be empty, per current spec) should be populated by a consumer that supports the "taiRangeList". Zhijun: Thanks for your comments. I accept them. For the existing "taiList", as it is mandatory, what I can suggest is: if "taiRangeList" is used, then the "taiList" can only carry a small part of the whole TAIs supported by the AMF. /Jones: carry a small part of TAIs is not an “accurate” description for implementation. Furthermore, it may be even misleading. How about using a solution like in 4269, to allow empty array of taiList with controlled by operation feature negotiation? This looks like a much leaner approach! I will reflect this in the v1 update, if you agree with such handling Bruno: The cover page says that the CR is backward compatible, but the CR doesn’t actually define any mechanism for backward compatibility with an NSSF that would not support the changes. CoNA is empty 6.2.6.2.8: "If taiRangeList is included, the TAI list indicated by the taiList shall be overriden."-> "ignored" Zhijun Thanks for your comments. To make it backward compatible, I would accept suggestion from Jones: - use feature to control this new "taiRangeList" - if "taiRangeList" is used, then keep the "taiList" as empty array. I will fix other errors as you pointed out.
4370	CR 29.531 0074 Rel-16 TAI Range List Served by an AMF	ZTE	Bruno: the feature definition should be expanded to reflect the new functionality added by the CR: Table 6.2.8-1: Features of supportedFeatures attribute used by Nnssf_NSSAIAvailability service In Table 6.2.6.2.8-1: Definition of type NssfEventSubscriptionCreateData taiList: 1..N taiRangeList: Identifies a list of TAI ranges supported by the NF service consumer (e.g. AMF). If taiRangeList is present, the TAI list indicated by the taiList shall be set to empty array. taiList cannot be an empty array (you need further changes to allow this, conditioned to the support of the new feature) Aren’t these cases where it could be appropriate to send TAIs in ranges and others in lists ? I would prefer an explicit condition that a consumer may include this new attribute only if the NSSF supports the ONSSAI feature.
4174	CR 29.531 0076 Rel-16 Availability notification	Huawei	WI TEI16 CAT F C4-204174, C4-204268, C4-204269 are clashing Jesus: E/// has the following comments on this CR: The proposed solution does not work, since the current definition of attribute "authorizedNssaiAvailabilityData" requires that there must always be at least 1 element in the array. This is enforced in the word table and in the OpenAPI, so the array can never be empty. authorizedNssaiAvailabilityData => 1..N NssfEventNotification: type: object required: - subscriptionId - authorizedNssaiAvailabilityData properties: subscriptionId: type: string authorizedNssaiAvailabilityData: type: array items: $ref: '#/components/schemas/AuthorizedNssaiAvailabilityData' minItems: 1 Caixia: I agree with you, the array marked as 1..N, and cannot be empty. As Ericsson has a contribution on the same issue in 4269, which change the array to 0..N, and introduce the feature negotiation on this enhancement, I will propose to merge our paper into 4269
4175	CR 29.531 0077 Rel-16 Request mapping of S-NSSAI	Huawei	Revised to C4-204403	WI TEI16 CAT F Bruno There is one typo in sNssaiForMapping: "during handed over within 5GS" Caixia: Typo is corrected, I change the description to during handover procedure within 5GS in draft V1, which is uploaded onto the server.
4403	CR 29.531 0077 Rel-16 Request mapping of S-NSSAI	Huawei
4176	CR 29.531 0078 Rel-16 Subscription modification	Huawei	Revised to C4-204404	WI TEI16 CAT F Jones: We agree the motivation of the CR. Some comments: 1/ AMF shall only update limited information of the subscription but not unrestricted, e.g. taiList or taiRangeList(ZTE CR) which are most possibly to be configured, or to prolong the expiry. We should state this in the specification. 2/ There is no need to support two service operations for subscription update, using PATCH is enough considering AMF only allowed to update limited information only Caixia: I am fine to only define the PATCH method to update the subscription. For the restricted update, which information contained in NssfEventSubscriptionCreateData are allowed to be updated? My understanding is except the NssfEventType, all of other parameters can be modified, please correct me if I am wrong. 6.2.6.2.8 Type: NssfEventSubscriptionCreateData Table 6.2.6.2.8-1: Definition of type NssfEventSubscriptionCreateData Table provided in email 24/08/2020 03:20 Bruno the principle of the CR is fine, but is this really FASMO? It looks more as a new enhancement for Rel-17. If this is not supported, when the list of TAs change, 2 messages have to be sent instead of one. Cover page says: "This CR introduces backward incompatible corrections to the OpenAPI file for Nnssf_NSSAIAvailability API." … And indeed it is backward incompatible if the NSSF does not support the change and AMFs sends a subscripition update, so the CR needs updates to be backward compatible (new feature). Caixia: I am fine to define a new feature for subscription modification. Would you accept to start the changes from R16? Jones: Agree on your interpretation. We considered update TAIs (also TAI ranges) are the most common needs to update the subscription, additionally update expiry for extending the subscription life could be another possibly usage. Update of notification Uri and Set Id we originally considered less likely to be used via modification, but we are Ok to support via modification. Event shall not be modified via modification, it should be explicitly stated in the specification. Additionally, the consumer (AMF) shall stick to the attribute provided in the Create Subscription. E.g. if the AMF provides tai list in subscription creation, it shall always use it, instead of replacing it with tai Ranges in modification. Caixia: Thank you, based on your suggestion, I will update the text as below: The NF Service Consumer (e.g. AMF) shall send a PATCH request to the resource URI identifying the individual subscription resource. The payload of the body shall contain the PatchDocument which contains one or more PatchItem instructions for updating the subscription data. The NF Service Consumer shall not change the event IE included in the NssfEventSubscriptionCreateData by invoking the PATCH request message. For updating the taiList or taiRangeList IE, the NF Service Consumer shall update the same IE included in subscription creation, e.g. if the AMF provides taiList IE in subscription creation, the AMF shall update the taiList IE during subscription modification, instead of replacing taiList IE with taiRangeList IE. Hope you are fine with this. Jones: Thanks. The suggested changes are fine by me. BTW, as the taiRangeList is introduced by ZTE CR, shall we add a related CR in cover page? Do we need to link the CRs? Caixa: I will add ZTE CR in cover page, and also indicate taiRangeList is defined in that CR Caixa: Draft v1 is uploaded onto the server. https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.3.7/C4-204176_V1_TEI16%2029.531-subscription%20modification.docx With changes: Add new feature for subscription modification; Revert the PUT method Restrict the scope of modification. Jones Thanks for the update. The v1 draft is fine by me.
4404	CR 29.531 0078 Rel-16 Subscription modification	Huawei	Bruno: thanks, I am fine with your revision. Just a couple of points: 5.3.2.3.2 Modification of a subscription The Subscribe Operation is used by a NF Service Consumer (e.g. AMF) towards the NSSF, when it needs to modify an existing subscription previously created by itself at the AMF. Can we state that The Subscribe Operation may be used by a NF Service Consumer (e.g. AMF) towards an NSSF supporting the SUMOD feature, when it needs … And for my info, what is the reason of the following restriction? For updating the taiList or taiRangeList IE, the NF Service Consumer shall update the same IE included in subscription creation, e.g. if the AMF provides taiList IE in subscription creation, the AMF shall update the taiList IE during subscription modification, instead of replacing taiList IE with taiRangeList IE.
4268	CR 29.531 0079 Rel-16 Authorized NSSAI Availability Empty Indication	Ericsson	Not pursued	WI TEI16 CAT F C4-204174, C4-204268, C4-204269 are clashing Bruno C4-204269 provides an alternative solution that is cleaner, so we prefer to not pursue 4268, as also discussed and agreed offline with you and Caixia
7.3.8	AUSF	TEI16
4171	CR 29.509 0101 Rel-16 Storage of YAML files in ETSI Forge	Huawei	Revised to C4-204405	WI TEI16 CAT F
4405	CR 29.509 0101 Rel-16 Storage of YAML files in ETSI Forge	Huawei
7.3.9	NRF	TEI16
4108	CR 29.509 0100 Rel-16 Custom Operation Correction	ZTE	Agreed	WI TEI16 CAT F
4204	CR 29.510 0379 Rel-16 UDM (UDR, AUSF, PCF, CHF) profile without subscriber identifiers	Nokia, Nokia Shanghai Bell, Verizon	Agreed	WI TEI16, 5GS_Ph1-CT CAT F
4206	CR 29.510 0380 Rel-16 supported-features query parameter	Nokia, Nokia Shanghai Bell	Agreed	WI TEI16, 5GS_Ph1-CT CAT F
4237	discussion 29.510 Rel-16 Inconsistency in Status Notification received to Consumer NF	Cisco Systems	Agreed
4238	CR 29.510 0381 Rel-16 Making reqNfType as Mandatory IE in SubscriptionData	Cisco Systems	Revised to C4-204430	WI 5GS_Ph1-CT, SBIProtoc16 CAT F Bruno: your CR would introduce backward incompatible changes in Rel-16, and thus is not agreeable with its current content (i.e. changing an Rel-15 attribute from O to M in Rel-16). One possible way forward to address the issues discussed in C4-204237 could be to recommend or require the subscribing NF to include its NF type, making the attribute conditional (and not changing the OpenAPI file), and with the condition that a subscribing NF complying with this version of the specification (i.e. with the version published after next plenary and following ones) should or shall include this attribute. The cover page contains many errors (Source to TSG empty, clauses affected empty, other specs affected not ticked at all, incorrect WI code, Other comments empty … ). Hiroshi It seems some wording needs to be modified in the proposed change, as in Table 6.1.6.2.16-1, the new row consists of “cardinality” with “0..1” and “description” that starts with “If included, …”, while the proposal itself is to make this attribute mandatory. Ravi: After some internal discussion we have agreed to incorporate the changes suggested by you. I will soon create a new version of the document and float it for review. Ravi: As per Bruno’s comment, I am going to change the IE from M->C. This would also take care of your comments below. I will soon float the next version for review Ravi: I have uploaded the version-1 in /draft/7.3.9/ folder after incorporating all the suggested changes. Please review and let me know if there are any further comments Ravi: I have taken a new TDoc number C4-204430 and the new version has been uploaded in /inbox after incorporating all the changes propose
4430	CR 29.510 0381 Rel-16 Making reqNfType as Mandatory IE in SubscriptionData	Cisco Systems
7.3.10	SMSF	TEI16
4177	CR 29.540 0056 Rel-16 Storage of YAML files in ETSI Forge	Huawei	Revised to C4-204406	WI TEI16 CAT F Yvette NOTE 1 needs be deleted. I mean the highlighted character. Caixia: Thank you, I have updated the contribution to remove the 1 in NOTE 1, draft v1 is uploaded onto the server Jesus: The title and the content of the CR refer to "ETSI Forge". However, I believe that there is intention to move the Forge platform, and the GitLab repositories from ETSI to 3GPP. I'm not sure if this transition has been officially communicated by 3GPP officials to the affected Working Groups, but the truth is that currently the ETSI-hosted repositories are marked as "read-only", and the 3GPP-hosted repositories are ready to be used. So, not sure what should we do. This affects not only this CR, but also 0484 and 0101 (for the current meeting), and also all the TS where the change was made in the last meeting. Any views on how to handle that? Caixia: Thank you for the information. For me, I am fine to update the contributions for the current meeting to refer to 3GPP-hosted repositories. And we also need to update all of the other APIs in future meetings. May be we can discuss this during the conference call to find a good way forward CC: Currently it is hosted by ETSI forge this is changed to “3GPP forge” We should update and should not mention etsi or 3GPP forge. Caixia: Based on the discussion in conference call, I simply remove the hosted in ETSI Forge in description as below: Informative copies of the OpenAPI specification files contained in this 3GPP Technical Specification are available on a Git-based repository hosted in ETSI Forge, that uses the GitLab software version control system (see 3GPP TS 29.501 [5] clause 5.3.1 and 3GPP TR 21.900 [16] clause 5B). Draft V2 is also available in draft inbox, would be changes acceptable?
4406	CR 29.540 0056 Rel-16 Storage of YAML files in ETSI Forge	Huawei
7.3.11	Common Data	TEI16
4178	CR 29.571 0232 Rel-16 Error corrections	Huawei	Revised to C4-204407	WI TEI16 CAT F Bruno: 5.4.4.2: "This IE shall be absent if no SD value is associated with the SST." 5.4.4.13: guamiList contains the list of GUAMIs (supported by the AMF) for which the backupAmf info applies. The current text seems to suggest that this contains all the AMF's GUAMIs Caixia: Draft V1 is uploaded with changes to clause 5.4.4.2 and 5.4.4.13 as proposed
4407	CR 29.571 0232 Rel-16 Error corrections	Huawei
4270	CR 29.571 0234 Rel-16 Additional PraId	Ericsson	Revised to C4-204454	WI TEI16 CAT F Remark: Other core specifications is marked but no CR listed. Caixia For the PRA SET issue, I think the mechanism is same as we defined in 4G, is it correct? Based on this, for praId, TS 29.274 has the following statement: The PRA Identifier in the Octets 5 to 7 shall be set to the PRA Set ID if the MME/SGSN is requested to report the change of UE presence in a PRA Set. /Jones: OK, I will update. I think we shall also update the description of praId. /Jones: Updated to state it may be for a Set of PRAs And for additionalPraId, is it only allowed to report one additionalPraId, or can report multiple? At least, in 4G, multiple is allowed. /Jones: The way of working for 4G and 5G of reporting maybe different. As you can see, in the Presence Report Area Information IE, it does allow including multiple APRAs, but at the same time it allows to make “IN/OUT” for each of the additional PRA. Where in 5G, the PresenceInfo data type only contain one presenceState attribute. If we go for 4G way, then we will need to add array of additional PRAs and at the same time add an array of presenceState (then for this case, the current presenceState attribute will not be used). This mechanism looks slightly more efficient, but changes too much on current way of working. We still suggest to use multiple event reports approach, and only add one additional PRA in the report and reuse the presenceState attribute. /Jones: Keep singleton for additional Pra ID in PresenceInfo data type. The way of working for 4G and 5G of reporting maybe different. As you can see, in the Presence Report Area Information IE, it does allow including multiple APRAs, but at the same time it allows to make “IN/OUT” for each of the additional PRA. Where in 5G, the PresenceInfo data type only contain one presenceState attribute. If we go for 4G way, then we will need to add array of additional PRAs and at the same time add an array of presenceState (then for this case, the current presenceState attribute will not be used). This mechanism looks slightly more efficient, but changes too much on current way of working. We still suggest to use multiple event reports approach, and only add one additional PRA in the report and reuse the presenceState attribute. For Other comments, the common data type API is impacted, even the new added IE is only used for Namf, I think the APIs reuse this data type shall be listed. Jones: OK /Jones: All affected APIs listed. Other specs will be impacted or not, as it is marked as Y? /Jones: A common error for me this time ☹ Jones: Fixed. Bruno: 5.4.4.27: I suggest some editorial enhancement: "This IE may be present if the praId IE is present and if it contains a PRA identifier referring to a set of Core Network predefined Presence Reporting Areas" /Jones: applied. We should also clarify that when the additionalPraId attribute is present, the presenceState attribute shall indicate the presence information of the UE for the additional PRA ID (not for the praId). /Jones: added a table note for the clarification Jones: Thanks for your comments. Please find V1 draft in /Inbox/Drafts/7.3.11. Replies see above. Bruno: thanks. I agree with the revision. One small editorial below: This IE shall be present if the Area of Interest subscribed or reported is a Presence Reporting Area or a Set of Core Network predefined Presence Reporting Areas
4454	CR 29.571 0234 Rel-16 Additional PraId	Ericsson
7.3.12	GTP	TEI16
4163	CR 29.060 1067 Rel-16 DCNR during mobility from Gn/Gp SGSN to MME	Huawei	WI TEI16 CAT F Frank: The intention of CR is fine, however per existing specification, the target SGSN or MME already get such information - UEs supporting Dual Connectivity with NR and not restricted from using NR by user subscription. In the MM Context, the Access Restriction Data includes NRSRNA(NR as Secondary RAT Not Allowed), and also UE Network Capability is included FRR and SGSN Context response message. So, I don't think the CR is needed. Caixia: Thank you, I think the solution you proposed make sense, I will postpone the paper and consider the solution you indicated, we may re-submit if we find problems in this solution. Bruno: The following text in clause 7.7.124 should be updated accordingly: "Bit 1 – DCNR (DCNR): if this bit is set to 1, it indicates to the PGW-C that it is desired to select a PGW-U optimized for Dual Connectivity with NR, e.g. for UEs indicating support of dual connectivity with NR in NAS signalling to the SGSN and without subscription restriction to use NR as secondary RAT."
4164	CR 29.274 1992 Rel-16 DCNR during mobility with SGW change	Huawei	WI TEI16 CAT F Frank: Beside the problem in the cover page, e,g, CR number is missing; I have similar comments as for your 4163 CR. The CR is not needed. MM Context in GTPv2 contains all necessary information – UE Network Capability, Access Restriction Data, to enable the target MME/SGSN to set DCNR flag. Caixia: Same to the paper on GTPv1, I will postpone the paper and consider the solution you indicated, we may re-submit if we find problems in this solution. Bruno CR and Tdoc nbs are missing on cover page.
CC4	4165	CR 29.281 0110 Rel-16 End marker in NG-RAN initiated QoS Flow mobility	Huawei	Revised to C4-204408	WI TEI16 CAT F Frank: I have different understanding of SA2 requirement. In TS 23.502, 4.14.1, step 6, SA2 says " In order to assist the reordering function in the Master RAN node and/or Secondary RAN node, for each affected N3 tunnel the UPF sends one or more "end marker" packets on the old tunnel immediately after switching the tunnel for the QFI. The UPF starts sending downlink packets to the Target NG-RAN." It is clear that the end-marker is sent per N3 tunnel, not per QoS flow in this scenario. So, the end-marker(s) is not sent with PDU session container including QoS flow Id. The NG-RAN related to the old N3 tunnel can determine that no more G-PDU pertaining the QoS flows which have been switched to the new N3 tunnel after receiving end-marker packets, however, I am not sure if we can specify the requirement " a G-PDU for the transferred QoS flows that arrives after an End Marker message on this tunnel may be silently discarded". Caixia: Thank you for your comments. As this issue needs to be discussed in RAN3, I will prepare a LS to RAN3, and we can update the description based on their agreement. The contribution will be revised just to restructure the clause to separate for EPC and 5GS, which will be better for future extending. Hope you are fine with this. Bruno: We should check with RAN3 first (who owns TS 37.340 - Multi-connectivity; Stage 2) which of the following option they expect. This has been discussed in the past by RAN3 but it seems that the conclusion has not been captured in their spec. UPF sends end marker for the whole PDU session (i.e. no QFI included) and RAN remembers that it corresponds to the offload of QFIs for which it just sent an NGAP PDU Session Modify Indication message. UPF sends end marker only for 1 QFI and RAN remembers that it corresponds to the offload of this QFI and other QFIs it is offloading for which it just sent an NGAP PDU Session Modify Indication message. UPF sends end marker per Qos flow. So I suggest to send an LS to RAN3 requesting them to clarify TS 37.340 on this issue, and we can then update 29.281 as necessary. Besides, the description in this clause becomes very messy as mixing 5GS and EPS requirements, and the proposed changes make this even worse. I think we should try to restructure properly this clause, e.g. with subclauses for the General aspects, for EPS reqts and for 5GS reqts. Caixia: Thank you, I will prepare the LS, and revise the contribution to only restructure of the clause. CC Bruno this was discussed in RAN3 but nothing is incorporated in their stage 2. In this meeting we will only restructure the subclause with regard to 5G and EPS Caixia: Based on discussion, the contribution is revised to restructure the clause of end marker, please check the draft version in inbox.
4408	CR 29.281 0110 Rel-16 End marker in NG-RAN initiated QoS Flow mobility	Huawei
CC5 CC6	4340	LS out LS on End marker in NG-RAN initiated QoS Flow mobility	Huawei/Caixia	To: RAN3 Caixa: I have uploaded the draft version of 4340 on LS (End marker in NG-RAN initiated QoS Flow mobility) in draft inbox of [7.3.12]. Frank: I made a revision on top of yours. https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.3.12/Draft%20C4-204340_LS%20on%20End%20Marker%20-frank.zip Caixia: Thank you, I am fine with your proposals, please check the draft v2 in the inbox. https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.3.12/Draft_v2_C4-204340_LS%20on%20End%20Marker.docx Bruno: This discussion relates to Rel-15 onwards. You may correct the release indicated in header of the LS. The text in yellow may confuse RAN3 IMO, since the UPF is not expected to send any further packet on the old N3 tunnel when it has sent an End Marker. At very least, we should clarify that “NG-RAN discards any subsequent user plane packets received on the old N3 tunnel pertaining …” . UPF sends one or more End Marker messages without any QFI included, NG-RAN discards any subsequent user plane packets pertaining to the QoS flows be switched to the new N3 tunnel after receiving the End Marker messages; UPF sends one or more End Marker messages including one QFI of those QoS flows be switched to the new N3 tunnel, NG-RAN discards any subsequent user plane packets pertaining to the QoS flows be switched to the new N3 tunnel after receiving the End Marker messages; UPF sends one or more End marker messages including the QFI for each of those QoS flows be switched to the new N3 tunnel, NG-RAN discards any subsequent user plane packets pertaining to the QoS flow be switched to the new N3 tunnel after receiving the corresponding End Marker messages (with QFI); CC This is also for Rel-15 Bruno: the situation that packets are received after end marker should not happen this would be an error case. Caixia: Thank you, I have updated the release and work item from R15, and also revise the description to revert the yellow part. https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.3.12/Draft_v3_C4-204340_LS%20on%20End%20Marker.docx Please check the proposal from my side Bruno: In the action to RAN3, I suggest to ask them first which alternative should be supported. After receiving the End Marker message, NG-RAN considers the user plane packets will be received in the new N3 tunnel, it is not clear how NG-RAN handle the subsequent user plane packets pertaining to the QoS flows be switched to the new N3 tunnel or the QoS flows kept in the old N3 tunnel. Regarding the highlighted text, the UPF should not send any subsequent user planes packets on the old N3 tunnel for ANY QoS flow moved to the new N3 tunnel (in Alternatives 1 & 2) once UPF has sent end marker packets. In other words, in Alt. 1 and 2, UPF shall first start switching all QoS flows, and only once done, it shall send End marker packets. So I am still not sure which use case you describe here. Another question I suggest to ask RAN3 is how to handle consecutive RAN initiates requests to move QoS flows if no QFI is included in the End Markers, or whether NG RAN shall always wait for the response of a first request before being able to trigger another request. Caixia: Thank you for your good suggestions, please check the updates from my side: CT4 discussed the following several alternatives to send the End Marker messages on the old tunnel in a NG-RAN initiated QoS Flow mobility procedure, as specified in step 6 of clause 4.14.1 of 3GPP TS 23.502 as below: "In order to assist the reordering function in the Master RAN node and/or Secondary RAN node, for each affected N3 tunnel the UPF sends one or more "end marker" packets on the old tunnel immediately after switching the tunnel for the QFI. The UPF starts sending downlink packets to the Target NG-RAN." 1) UPF sends one or more End Marker messages without any QFI included; 2) UPF sends one or more End Marker messages including one QFI of those QoS flows be switched to the new N3 tunnel; 3) UPF sends one or more End marker messages including the QFI for each of those QoS flows be switched to the new N3 tunnel; After receiving the End Marker message, NG-RAN considers the user plane packets will be received in the new N3 tunnel, it is not clear how NG-RAN handle the subsequent user plane packets pertaining to the QoS flows kept in the old N3 tunnel. Bruno> add an indentation for the questions for clarity as shown below: Question 1: CT4 would like to ask RAN3 to clarify which alternative is the expected solution and clarify how NG-RAN handle the subsequent user plane packets pertaining to the QoS flows kept in the old N3 tunnel after receiving the End Marker message? In addition, NG-RAN may need to trigger the consecutive NG-RAN initiated QoS Flow mobility procedures to switch QoS flows, if so, shall the NG-RAN always wait for the response of the previous N2 QoS Flow mobility Indication before triggering another request if no QFI is included in End Marker messages in alternative 1? If not, how does NG-RAN determine which QoS flows have been switched when receiving End marker packets (due to PFCP message retransmission, it is not guaranteed that the SMF answers first to the first request )? Question 2: CT4 would like to ask RAN3 to clarify how to handle the consecutive NG-RAN initiated QoS Flow mobility procedures if no QFI is included in End Marker messages in alternative 1? ACTION: CT4 kindly requests RAN3 to take the information above into account and provide responses to the questions and consider updating their specification accordingly. Bruno: Replies inline Caixia: Thank you, I make the changes accordingly. https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.3.12/Draft_V4_C4-204340_LS%20on%20End%20Marker.docx Frank: I have some problems for the second question, and I don't think it is relevant for the end marker. In my understanding, PDU SESSION RESOURCE MODIFY INDICATION/ PDU SESSION RESOURCE MODIFY CONFIRM as specified in 38.413 is class 1 procedure, for the same UE session the NG RAN has to wait for the response message from the AMF, before it can send a new request message. I don't understand, why the question is related to alt 1? In Alt 1, if the NG-RAN receives end-marker in Alt1, it can consider the switching is over; while for alt 3, the NG-RAN has to validate for each QoS flow to be switched, it has received the corresponding end marker… I can accept the list of alternatives, but NOT the following highlighted text except ask the question " Question 1: CT4 would like to ask RAN3 to clarify which alternative is the expected solution " The NG-RAN will of course forward the subsequent DL packets pertaining to the kept QoS flows to the UE. Frank: I don't agree the LS as commented in my another email. CC Frank does not like question 2. Bruno: endmarker is indication to NG-RTAN that no more packets are received from the node sending the end marker message. Yue what is the problem with asking the question does it harm? Frank: we should only ask question we need to ask. Frank: we should focus on essential questions regarding the protocol. Bruno: we should focus on the procedure that the procedure work salways properly. Bruno: lets raise only raise the first question. Caixa Companies who would like to raise their voice can provide a discussion paper to RAN3 Frank what is realy the problem with solution 1. Bruno the Huawei CR clearly shows Ericsson and Huawei has diffedr et interpretations so we should ask which solution is the propoer one. Caixa will provide a new draft and share it. Caixia: Please check the updates based on the discussion during conference call: CT4 discussed the following several alternatives to send the End Marker messages on the old tunnel in a NG-RAN initiated QoS Flow mobility procedure, as specified in step 6 of clause 4.14.1 of 3GPP TS 23.502 as below: "In order to assist the reordering function in the Master RAN node and/or Secondary RAN node, for each affected N3 tunnel the UPF sends one or more "end marker" packets on the old tunnel immediately after switching the tunnel for the QFI. The UPF starts sending downlink packets to the Target NG-RAN." 1 UPF sends one or more End Marker messages without any QFI included; 2 UPF sends one or more End Marker messages including one QFI of those QoS flows be switched to the new N3 tunnel; 3 UPF sends one or more End marker messages including the QFI for each of those QoS flows be switched to the new N3 tunnel; After receiving the End Marker message, NG-RAN considers the user plane packets will be received in the new N3 tunnel, it is not clear how NG-RAN handle the subsequent user plane packets pertaining to the QoS flows kept in the old N3 tunnel. Question: CT4 would like to ask RAN3 to clarify which alternative is the expected solution? Bruno: This is fine by me.
4248	CR 29.274 1993 Rel-16 Enhancement of network event reporting	Nokia, Nokia Shanghai Bell	WI TEI16 CAT F Frank: The intention of the CR is fine with me, but the proposed change is backward incompatible, we cannot accept it. The existing requirement has been introduced since Rel-13, "for PAA, for Non-IP or Ethernet PDN connections, the PDN Address and Prefix field shall not be present.". We need find a alternative solution, e.g. the PGW could include a new optional IE to carry IP address/prefix, together with a UDP port. The UDP port may be useful in case ptp tunnel is identified by IP address + port number, especially for IPv4 cases. If it is fine with you, could you please add Ericsson as supporting company. Pallab We agree with your comments and proposal to add a new optional IE. I have uploaded a new version (V1) and also added Ericsson as a supporting company. Kindly review and let me know if you have any comments. The updated version V1 is available here https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.3.12/C4-204248_V1_29274_Enhancement%20of%20network%20event%20reporting_Rel16.docx Giorgi: Editorial: in the first change please use hard space in “clause 4.3.17.8.3.3.2”. Concerning the second change, I think if it would be better to explicitly indicate if non-IP PAA contains IPv4 or IPv6 address. Something like this: PDN type value (octet 5) Bits 3 2 1 0 0 1 IPv4 0 1 0 IPv6 0 1 1 IPv4v6 1 0 0 Non-IP 1 0 1 Ethernet 1 1 0 Non-IP IPv4 1 1 1 Non-IP IPv6 Pallab: Based on inputs received from Frank (Ericsson), we have now provided an updated version of the document, introducing a new optional IE. So, I am not considering your comments below on the original document. Link to new version is available in my latest email with changed subject line “[TEI16] [7.3.12] [C2-204248] [V1] [CR 29.274 1993 Rel-16 Enhancement of network event reporting]” Frank: Just a small editorial comment, e.g. Bit 2 must be set to “0” when Bit 1 is set to “1”. Please use "shall" instead "must"; and please use ". Pallab Uploaded V2 now with correction.
7.3.13	DAPS hanover	TEI16
4032	LS in Rel-16 LS on S1/NG DAPS handover	RAN3	Noted	R3-202932 To: SA2, CT4 CC: Contact: CATT Rel-16 Wi: LTE_feMob-Core, NR_Mob_enh-Core RAN3 agreed to support S1/NG DAPS (Dual Active Protocol Stacks) Handover over S1 and NG. RAN3 agreed to introduce the below changes as described in the attached BL CRs for S1AP and NGAP: Add the DAPS related information in transparent containers between source and target in the Handover Preparation and Handover Resource Allocation procedures. Introduce two new class-2 procedures for transferring the COUNT value for the early data forwarding. The content of these messages is transparent to the core network. Introduce a new message (i.e. Handover Success from MME/AMF to source node) and enhance the Handover Notify message for indicating the successful access of the UE from target node to source node via MME/AMF. These changes may have impact on SA2 and CT4 specifications. To SA2 and CT4 working group: RAN3 kindly asks SA2 and CT4 to take the above RAN3 agreements into account and do corresponding change(s) to the specification(s) if needed. Postponed to Agenda item: 7.3.13 Proposed treatment: See reply from SA2 in C4-204038 and C4-204051. LS can be noted.
4038	LS in Rel-16 Reply LS on S1/NG DAPS handover	SA2	noted	S2-2004474 To: CT, SA, CT4, RAN3; Cc: RAN. Contact: Nokia Rel-16 WI: LTE_feMob-Core, NR_Mob_enh-Core SA2 thanks RAN3 for their LS. Considering that Core Network protocol change are required (to cover inter AMF/MME mobility) while SA2 ensures that CT specifications are frozen in this quarter, SA2 has agreed to the attached R16 CR(s) based on the condition that TSG CT and TSG SA plenary agree to their inclusion in R16 specifications. SA2 will also like to highlight another issue which is not addressed in RAN3’s LS and the attached RAN3 CR but considered in the attached SA2 CRs. It is assumed that S-RAN will only initiate the DAPS HO when both S-RAN and S-AMF support DAPS HO. T-RAN will only send the DAPS HO accept when both T-RAN and T-AMF support the DAPS HO. ACTION: SA2 kindly asks RAN3 and CT4 to take the above information into account. Remarks from last meeting: SA2 conditionally agreed CRs, depends if plenary agrees the CRs for Rel-16 or 17 CRs to CT4 in August meeting. Postponed to Agenda item: 7.3.13 Proposed treatment: See LS in C4-204032 and C4-204051. Related stage 2 CRs are approved at plenary in SP-200551 and SP-200607 for Rel-16 CRs provided in C4-204284, C4-204285.
4051	LS in Rel-16 Reply LS on S1/NG DAPS handover	TSG CT	noted	CP-201312 To: SA2, SA, RAN3, CT4 CC: RAN Contact Qualcom Rel-16 WI TEI16 CT thanks SA2 for their LS on S1/NG DAPS handover. CT has agreed that CT4 should work on completing the stage 3 changes required to enable S1/NG DAPS handover in Rel-16 at CT4#99-e. Consequently CT sees no issue with approving the CRs agreed by SA2 in S2-2004472 and S2-2004473 at SA#88. ACTION: CT asks CT4 to complete the stage 3 changes required to enable S1/NG DAPS handover in Rel-16 at CT4#99-e. Proposed treatment. See LS in C4-204032 and C4-204038. The LS can be noted.
4284	CR 29.518 0376 Rel-16 DAPS Handover information	Qualcomm Incorporated, Nokia, Nokia Shanghai Bell	WI TEI16, LTE_feMob-Core, NR_Mob_enh-Core CAT F Jones: The first change, clause 5.2.2.3.1.1: - PDU Session release (see clauses 4.3.4 and 4.9.1.3.3a of TS 3GPP 23.502 [3]) - Session continuity, service continuity and UP path management (see clause 4.3.5 of 3GPP TS 23.502 [3]) - Inter NG-RAN node N2 based handover (see clause 4.9.1.3 of 3GPP TS 23.502 [3]) 4.9.1.3.3a of TS 23.502 is for N2 handover with DAPS, instead of PDU session release. This change may not be needed, as the Inter NG-RAN node n2 handover below stated the parent clause 4.9.1.3 already. Waqar: Thanks Jones, I also think this change is not needed, updated in revision: https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.3.13/C4-204284_29518_v2.docx
4285	CR 29.274 1991 Rel-16 DAPS Handover information	Qualcomm Incorporated, Nokia, Nokia Shanghai Bell	WI TEI16, LTE_feMob-Core, NR_Mob_enh-Core CAT F Jones: Clause 7.3.3, there is an extra empty row in the CR, please remove: Waqar: Thanks Jones, fixed in the update: https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/7.3.13/C4-204285_29274_v2.docx
8	Release 15 and earlier
8.1	CT4 Led WIs
8.1.1	EPC enhancements to support 5G New Radio via Dual Connectivity, CT aspects	EDCE5-CT
8.1.2	CT aspects of unlicensed spectrum offloading system enhancements	USOS-CT
8.1.3	CT aspects of 5G Trace management	NETSLICE-5GTRACE-CT
8.2	CT4 Supported WIs
8.2.1	CT aspects on 5G System - Phase 1	5GS_Ph1-CT
4022	CR 29.244 0468 Rel-15 Reflective QoS	Huawei	Revised to C4-204341	WI 5GS_Ph1-CT CAT F Consequences if not approved states only " Misalignment with stage 2." Should be enhanced. Bruno: In clause 7.5.4.5, changes have been applied to the wrong IE, should be done against the Reflective QoS IE Giorgi thanks for catching this, will fix in v1.
4341	CR 29.244 0468 Rel-15 Reflective QoS	Huawei
4027	CR 29.338 0036 Rel-15 SMSF Address Corrections	Hewlett-Packard Enterprise, Nokia, Nokia Shanghai Bell, AT&T	Agreed	WI 5GS_Ph1-CT CAT F
4057	CR 29.338 0037 Rel-16 SMSF Address Corrections	Hewlett-Packard Enterprise, Nokia, Nokia Shanghai Bell, AT&T	Agreed	WI 5GS_Ph1-CT CAT A
4065	CR 29.273 0524 Rel-15 AAA Deregistration due to EPC restriction	Hewlett-Packard Enterprise	withdrawn	WI 5GS_Ph1-CT CAT F Bruno: I agree with the proposed changes, but is this really correcting a FASMO? I doubt this is a frequent use case. Rel-15 is deeply frozen and we should only accept Rel-15 CRs correcting FASMOs. I would suggest to agree the changes from Rel-16 onwards. Anders: Thanks Bruno, yes that is acceptable. I will withdraw the rel-15 version and revise the rel-16 version and make it a cat F CR.
4066	CR 29.273 0525 Rel-16 AAA Deregistration due to EPC restriction	Hewlett-Packard Enterprise	WI 5GS_Ph1-CT=> TEI16, 5GS_Ph1-CT CAT A=> F Anders The rel-16 CR – C4-204066 has been revised in C4-204428 and is available in the Inbox
4150	discussion Misalignment between TS 33.501 and TS 29.573 on JSON object	Huawei	Noted
CC4	4151	LS out Misalignments on JSON object	Huawei	Revised to C4-204409	To SA3 Jones: I checked with my SA3 colleague and was told that SA3 has already aware of this issue with ongoing discussion and hopefully a decision is made next week. The misalignment is caused by CT4 missed implementation of SA3 CR 0465r1 to TS 33.501 (S3-183685) as a fix of robustness risks that the sending NF accidentally sends HTTP messages that interfere with the message rewriting at the sending SEPP, which was agreed at SA3#93 and approved at SA#82 (SP-181025). We read that SA3 and SA plenary has already acknowledged the needs for the robustness of protocol with agreeing the fix. Based on all these, I am not sure whether an LS is still needed to be sent, even though we are not really against to do so. We can wait for the SA3 outcome. CC Bruno there is a clear misalignment. SA3 solution is backward incompatible to our 29.573. What is our preferred solution. Jones: Ericsson is in favour of the SA3 solution. Does this mean we need to have a backward incompatible CR to Release 15? LS need to reflect current situation not just referring to stage 3 solution. Nokia would be OK to go for a backward incompatible change. Companies need to check that there is no deployment of current stage 2 . Caixia: Based on our discussion during conference call, I have updated the LS to indicate the impact to CT4, please check the draft v1 in inbox. Bruno: Thanks. I have proposed some updates in the draft inbox. Caixia: Thank you, I have updated accordingly in draft v2. https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/8.2.1/C4-204151_V2_LS%20on%20Misalignments%20on%20HTTP%20message%20format%20over%20N32-f.docx Bruno: Thanks Caixia. V2 is OK for me. Jones: Thanks. I am fine with the draft in the Inbox, with updates from Bruno. Caixia: Thank you for your quick confirmation. C4-204151 is revised to C4-204409, and available in inbox, and I will request to approve and send to SA3 during today’s conference call
KIMMO!	4409	LS out Misalignments on JSON object	Huawei	Approved	To SA3 C4-204150 (DISC paper) needs to be attached Kimmo is asked to attach the discussion paper and send the LS out to SA3.
4216	CR 29.518 0387 Rel-15 Correction of UE Context Transfer payload in case of UE initial registration	NTT DOCOMO	Agreed	WI 5GS_Ph1-CT CAT F
4217	CR 29.518 0388 Rel-16 Correction of UE Context Transfer payload in case of UE initial registration	NTT DOCOMO	Agreed	WI 5GS_Ph1-CT CAT A
4218	CR 23.003 0593 Rel-15 SMSF FQDN	NTT DOCOMO	WI 5GS_Ph1-CT CAT F Anders: The realm part is described in a NOTE and thus not normative. Is there a reason why the realm couldn’t be specified normatively (without a NOTE) as well? Hiroshi: We are fine with this being made a normative text. I have drafted that changes it to normative and is made available in the inbox. Please refer to the following link. https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/8.2.1/draft%20v1%20-%20C4-204218%20R15_23003_SMSFfqdn.docx Hiroshi: I have not received back the response, but based on the last comment have provided v1 and is available in the inbox. The text was updated to reflect what was commented previously, i.e. to change the added note to be a normative text. Mirror CR is updated accordingly. Please let me know if this is fine Anders: Apologies for the late response. Thank you for revising. I’m would it make sense to also reference 28.2 wrt to the realm: This format shall be used as a Diameter identity of an SMSF. A Diameter realm of an SMSF shall be a Home Network Domain Name (see clause 28.2), i.e.: as described below: 5gc.mnc<MNC>.mcc<MCC>.3gppnetwork.org
4219	CR 23.003 0594 Rel-16 SMSF FQDN	NTT DOCOMO	WI 5GS_Ph1-CT CAT A See 4218
4220	CR 29.503 0477 Rel-15 Introduction of NOTE for “freeze 5G-TMSI” in case of Purge	NTT DOCOMO	Agreed	WI 5GS_Ph1-CT CAT F
4221	CR 29.503 0478 Rel-16 Introduction of NOTE for “freeze 5G-TMSI” in case of Purge	NTT DOCOMO	Agreed	WI 5GS_Ph1-CT CAT A
4222	CR 29.518 0389 Rel-15 Correction of UE Context Transfer after the integrity check failure in case of UE initial registration	NTT DOCOMO	WI 5GS_Ph1-CT CAT F Jones I understood that for mobility registration the new AMF perform UE Context Transfer again after successfully authentication of the UE, after a integrity check failure at old AMF, in order to fetch the PDU session context from the old AMF for continuation of the ongoing PDU sessions. For initial registration, the new AMF first try to get the UE Context from the old AMF to get information like UE ID, Security Context, etc. thus it can skip certain steps if possible. After the successful authentication of the UE, these information should be already available at the new AMF. E.g. in EPS, the new MME doesn’t perform Identification Request again to the old MME. Could you please clarify what are the motivation for the new AMF to perform secondary UE Context Transfer after integrity checked failed for Initial Registration? Hiroshi: In the Initial Registration, the old AMF can retrieve not only UE ID and security context, but can retrieve PCF instance and SMSF instance. With this, discovering these instances can be optmised. As far as I understand, the stage 2 does not distinguish Initial and Mobility Registration, and stage3 seems to be missing, and this is the reason for proposal. Jones: For initial registration, I understood that it happens usually when the UE has previously deregistered from the system. IIRC, during the UE deregistration, the AMF will deactivate the UE Context in SMSF and also terminate both AM Policy and UE policy Association from the PCF. So for a deregistered UE, there should be no SMSF instance or PCF instance in the UE Context in the old AMF. The above information will be available in old AMF when the UE is exceptionally terminated (e.g. battery removed) before deregistration can be triggered, and the UE INIT REGISTER back to the system before NW triggered deregistration is performed. This is however not common scenario and secondary fetching after first UE context transfer failure under such a condition makes it even more rare. Based on these facts, maybe we should not formally introduce this secondary UE Context Transfer for initial registration. Bruno: Thanks for your replies. We share the same views as expressed by Jones. During a sunny day AMF initial registration, the new AMF can retrieve the security information from the old AMF, which allows to skip authentication and save several message exchanges between the UE / AMF/AUSF. But if the integrity check fails at the old AMF, the new AMF needs anyhow to retrieve security information from AUSF/UDM and authenticate the UE. Subscription data is in any case also retrieved from the new AMF. Doing another round of N14 exchanges, after the new AMF has authenticated the UE, does not bring much value. This causes one extra N14 exchange, that would be rejected by AMF complying with the existing specification (you define a new code point for TransferReason that would not be comprehended). This is not worth for just retrieving the PCF or SMSF used by the old AMF. Also I understand that a different PCF could be required for the new registration e.g. depending on the new TA of the subscriber or the registration parameters (e.g. S-NSSAI). Same comments apply to the Rel-16 CR (C4-204223) Bruno: Can you please clarify what we would gain with the proposed changes. [Hiroshi] Discovery/selection of PCF and SMSF can be skipped at the new AMF What are the operational consequences if these changes are not supported? [Hiroshi] Less efficiency. Maybe not much for now. In Rel-17, we expect PCF discovery/selection becomes complicated and costly due to SA2 works SP-200446 and SP-200447. Hiroshi: We can accept that this is not a FASMO, and to be considered for Rel16 if this is your concern.
4223	CR 29.518 0390 Rel-16 Correction of UE Context Transfer after the integrity check failure in case of UE initial registration	NTT DOCOMO	WI 5GS_Ph1-CT CAT A See 4222
4224	CR 29.518 0391 Rel-15 Registration Status Update for PCF for UE Policy	NTT DOCOMO	WI 5GS_Ph1-CT CAT F Bruno: we agree with the CR, but Consequences if not approved should be strengthened to justify the Rel-15 correction. Hiroshi Would a following text work for you? --- The target AMF cannot select a new PCF for UE Policy other than the one which was included in the UeContext by the source AMF, in case PCF for AM Policy is not used. --- Hiroshi: I have not received back the response, but based on the last comment have provided v1 and is available in the inbox. The update is on the coversheet, for Consequences if not approved, and the original change remains the same. Mirror CR is updated accordingly. Please let me know if this is fine. Bruno: , yes this is fine
4225	CR 29.518 0392 Rel-16 Registration Status Update for PCF for UE Policy	NTT DOCOMO	WI 5GS_Ph1-CT CAT A See 4224
4226	CR 29.503 0479 Rel-15 Correction of creation of subscription by UDM at UDR	NTT DOCOMO	Agreed	WI 5GS_Ph1-CT CAT F
4227	CR 29.503 0480 Rel-16 Correction of creation of subscription by UDM at UDR	NTT DOCOMO	Agreed	WI 5GS_Ph1-CT CAT A
4228	CR 29.573 0043 Rel-15 Error handling of mismatch of polices at SEPP	NTT DOCOMO	revised to C4-204241	Revision of C4-204241 WI 5GS_Ph1-CT CAT F
4229	CR 29.573 0044 Rel-16 Error handling of mismatch of polices at SEPP	NTT DOCOMO	revised to C4-204242	Revision of C4-204242 WI 5GS_Ph1-CT CAT A
4230	CR 29.573 0045 Rel-15 Correction of flow description	NTT DOCOMO	revised to C4-204243	Revision of C4-204243 WI 5GS_Ph1-CT CAT F
4231	CR 29.573 0046 Rel-16 Correction of flow description	NTT DOCOMO	revised to C4-204244	Revision of C4-204244 WI 5GS_Ph1-CT CAT A
4241	CR 29.573 0043 Rel-15 Error handling of mismatch of polices at SEPP	NTT DOCOMO	Withdrawn	WI 5GS_Ph1-CT CAT F Caixia: Thank you for providing the contribution. I Propose to change the name to policy_mismatch, and Clause 6.1.6.3 shall be updated to add a new table for application errors. Other comments are missed. Hiroshi: Thanks for your comment. As indicated in another email in the thread, I uploaded a revision based on feedback from Jones, except “Other comments”. Can you kindly check? Jones: Some comments: The application specific errors should be specified in 6.1.6.3. e.g: 6.1.6.3 Application Errors The common application errors defined in the Table 5.2.7.2-1 in 3GPP TS 29.500 [4] may also be used for the N32-c Handshake service. The following application errors listed in Table 6.1.6.3-1 are specific for the N32-c Handshake service. Table 6.1.6.3-1: Application errors Table removed Also the response code table maybe adapted like other specification: 1/ The description of 409 could be removed, as it is already indicated by the application error, and may also with other application errors in future. 2/ Suggest remove the 4xx/5xx line, and replace it with a table NOTE like below (align with other specification). Table 6.1.4.3.2-2: Data structures supported by the POST Response Body on this resource ProblemDetails: This represents a parameter mismatch has been detected by the receiving SEPP, i.e. received data-type encryption or modification policy conflict with the one manually configured for the specific roaming partner and IPX provider. The "cause" attribute may be used to indicate one of the following application errors: - REQUESTED_PARAM_MISMATCH Problem details for 4xx/5xx to be removed in table Hiroshi: Thank you for providing feedback / suggestions. I have revised as you suggested, and have uploaded to the draft box. # I would need to revise it again, as I used the older version which had errors in the coversheet. One point, your proposal on table 6.1.4.3.2-2 is fine for Rel-16, but the Rel-15 of TS 29.573 has different style, and this is the reason why I had the Rel15 and 16 with different style, to be in line with each releases. So I left it so that it fits with each Release style. However, I am open for suggestion. The draft revision for C4-204241 (Rel15) is provided as: https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/8.2.1/C4-204228_v1%20N32-c%20correct_error_handling%2029573-f30.docx And draft revision for C4-204242 (Rel16) is provided as https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/8.2.1/C4-204229_v1%20N32-c%20correct_error_handling%2029573-g30.docx Bruno: I doubt that the CRs correct FASMO. So I would suggest to consider making these corrections from Rel-16 onwards. We should be very strict now on Rel-15 corrections. Hiroshi: Thank you for your comment. We are fine to have this change from Rel-16. I will change the coversheet accordingly for Rel-16 CR.
4242	CR 29.573 0044 Rel-16 Error handling of mismatch of polices at SEPP	NTT DOCOMO	WI 5GS_Ph1-CT CAT A Hiroshi: Based on the feedback on C4-204241 (Rel15), I have updated C4-204242 from a mirror to TEI16 CR. It is in the draft folder under the original agenda item 8.2.1. Please let me know if this should be moved, as well as whether the WI should be another one (e.g. SBIProtoc16).
CC4	4243	CR 29.573 0045 Rel-15 Correction of flow description	NTT DOCOMO	Withdrawn	WI 5GS_Ph1-CT CAT F Caixia My comments for this paper: The version shall be – or Rev1? In the reason for change: "This is incorrect to use “..” to represent the entire resource, as this is not in line with the rule as described in TS 29.500. This also has different semantics, and can imply that different resource is being referred" Which rule defined in TS 29.500? And what is the semantics for using '..'? I think the paper is not FASMO, and propose to start from R16. Hiroshi: The point is “..” is used for relative path, but this is not the case. So it is indicating the wrong path, and this is why it was proposed as FASMO. I made mistakes on the coversheet, excuse me for that and I will fix that. Giorgi: I quickly searched 29.500 for “..” string and did not hit any statement that says it shall be interpreted as a relative path. Just for curiosity, even if it were specified as a relative path, what would have been reason for FASMO? Jesus The usage of ".." is specified in RFC 3986 (the "URI" RFC), which is applicable to all 3GPP 5GC APIs. The path segments "." and "..", also known as dot-segments, are defined for relative reference within the path name hierarchy. They are intended for use at the beginning of a relative-path reference (Section 4.2) to indicate relative position within the hierarchical tree of names. This is similar to their role within some operating systems' file directory structures to indicate the current directory and parent directory, respectively. However, unlike in a file system, these dot-segments are only interpreted within the URI path hierarchy and are removed as part of the resolution process (Section 5.2). Giorgi: What’s FASMO? Jesus I did not address anything in my mail regarding FASMO or not 😊 I can agree this is not FASMO. My mail was only directed to this comment: I quickly searched 29.500 for “..” string and did not hit any statement that says it shall be interpreted as a relative path. To make it clear that TS 29.500 is not the right place to look up the meaning of ".." Giorgi: Ok But the reason for change on the cover sheet refers to 29.500… Bruno: This CR does not correct a FASMO. We should agree on the corrections from Rel-16 onwards. Just for my info: reason for change says “as this is not in line with the rule as described in TS 29.500”. To which rule from 29.500 do you refer to? How to proceed with this CR CC Bruno: not FASMO we can agree starting form Rel-16 Hiroshi: As we discussed in the conf call, we are fine with this to have it from Rel-16. And thank you for the explanation from Jesus. I will change the coversheet for the Rel-16 CR in C4-204244.
CC4	4244	CR 29.573 0046 Rel-16 Correction of flow description	NTT DOCOMO	WI 5GS_Ph1-CT CAT A Bruno: According to my comments to 4243, 4244 should be revised to update the cover page (WI code and CR category). Hiroshi: Based on the feedback on C4-204243 (Rel15), I have updated C4-204244 from a mirror to TEI16 CR. It is in the draft folder under the original agenda item 8.2.1. Please let me know if this should be moved, as well as whether the WI should be another one (e.g. SBIProtoc16).
4303	CR 29.572 0076 Rel-15 Correct mismatch on GeographicArea between table and yaml	Huawei	WI 5GS_Ph1-CT CAT F Jones: This CR is not needed. Using “anyOf” in OpenAPI is intentionally corrected (by CR0022) to fix OpenAPI validation problem of GeographicArea data type. Qingfen: Thanks for the comment. Could you please paste the Tdoc number of CR0022 in this email in order to my double-check? Qingfen I looked into CR0022, and understand why anyOf is used now. but if anyOf is used in yaml, the text part need be changed from “Table 6.1.6.2.5-1: Definition of type GeographicArea as a list of mutually exclusive alternatives” to “Table 6.1.6.2.5-1: Definition of type GeographicArea as a list of non-exclusive alternatives” accordingly, right? Jones: Sorry to say but by type definition “mutually exclusive alternatives” is the exactly the right one to use. The “anyOf” in OpenAPI is not intended to change type definition to “non-exclusive alternative”, instead it is a compromise to only allow OpenAPI inspection successful Qingfen: But the existing definition is really confusing if not know the background, I think we need add some clarification somewhere to make things understandable. BTW, I have another question, could you help to clarify: The Reason for change of CR0022 is below, it says “A PointUncertaintyCircle by definition will always pass the validation with both PointUncertaintyCircle and Point”, but for PointUncertaintyCircle, attribute uncertainty is mandatory, it means that uncertainty shall be present in PointUncertaintyCircle, but for Point, uncertainty is definitely absent, my question is why PointUncertaintyCircle will always pass the validation with both PointUncertaintyCircle and Point? From my understanding, the validator can distinguish whether the object is PointUncertaintyCircle or Point depending on the presence or absence of attribute uncertainty. In 3GPP TS 29.518, OpenAPI specification has defined GeographicArea Data using "one of": GeographicArea: oneOf: - $ref: '#/components/schemas/Point' - $ref: '#/components/schemas/PointUncertaintyCircle' - $ref: '#/components/schemas/PointUncertaintyEllipse' - $ref: '#/components/schemas/Polygon' - $ref: '#/components/schemas/PointAltitude' - $ref: '#/components/schemas/PointAltitudeUncertainty' - $ref: '#/components/schemas/EllipsoidArc' But some of the types in the list is not distinguishable with attributes: Point: allOf: - $ref: '#/components/schemas/GADShape' - type: object required: - point properties: point: $ref: '#/components/schemas/GeographicalCoordinates' PointUncertaintyCircle: allOf: - $ref: '#/components/schemas/GADShape' - type: object required: - point - uncertainty properties: point: $ref: '#/components/schemas/GeographicalCoordinates' uncertainty: $ref: '#/components/schemas/Uncertainty' A PointUncertaintyCircle by definition will always pass the validation with both PointUncertaintyCircle and Point, which breaks the requirement of "oneOf" and fail the validation of GeographicArea. There are two options to correct the issue: Option-1: Redefine the GAD Shapes to make the distinguishable by attribute names, e.g. to redefine "point" attribute of PointUncertaintyCircle to "pointUC". This leads to backward incompatible changes in OpenAPI. Option-2: Redefine the "oneOf" requirement to "anyOf" of GeographicArea, this introduces backward compatible change in OpenAPI. This CR propose to take the option-2 as backward compatible correction. Jones: The problem is, when OpenAPI perform validation for Point, it only validate wither mandatory IE “point” exists or not, whether the object contains other attributes or not is regardless (this allows extensibility with optional attributes). So a PointUncertainCircle which always contain a ‘point’ attribute will always qualify as a valid “Point” object, i.e. when validate PointUncertainCircle is being validated with Point schema, the ‘uncertainty’ is treated as optional attributes thus just ignored. Only the other hand, an Point object contains only “point” attribute will not be validated as “PointUncertaintiyCircle” as it lacks mandatory “uncertainty” attribute. This is how OpenAPI works. For us, we think the data type definition already self-descriptive enough. But I am not against adding clarification if it really helps 😊. Qingfen Thanks for your detailed explanation. I still think the clarification is necessary because I am indeed confused by the current definitions in table and yaml. I added a note in the new review draftv1 to avoid confusion other readers. Please the new draftv1 in https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/8.2.1/draftv1-C4-204303-CR0076-5GS_Ph1-CT-29572-Correct%20mismatch%20on%20GeographicArea%20between%20table%20and%20yaml-R15.docx And another new draftv1 of mirror CR https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/8.2.1/drafv1-C4-204304-CR0077-5GS_Ph1-CT-29572-Correct%20mismatch%20on%20GeographicArea%20between%20table%20and%20yaml-R16.docx Jones: Thanks for the update. I don’t think this CR is FASMO, let’s do it from Rel-16 onwards. The sentence in the table note is too long. May be rephrase like: NOTE: The "anyOf" keyword (instead of “oneOf” keyword which is normally used for mutually exclusive alternatives) is used for GeographicArea type in yaml file to avoid validation failure of OpenAPI. According to current definition, a PointUncertaintyCircle object will always pass the validation with both PointUncertaintyCircle and Point, which fails the qualification of “oneOf” keyword. Qingfen: I’m fine with doing it from R16 onwards. And your comment on NOTE was taken onboard in draftv2, please see https://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_99e_meeting/Inbox/Drafts/8.2.1/draftv2-C4-204304-CR0077-5GS_Ph1-CT-29572-Correct%20mismatch%20on%20GeographicArea%20between%20table%20and%20yaml-R16.docx
4304	CR 29.572 0077 Rel-16 Correct mismatch on GeographicArea between table and yaml	Huawei	Revised to C4-204438	WI 5GS_Ph1-CT CAT A
4438	CR 29.572 0077 Rel-16 Correct mismatch on GeographicArea between table and yaml	Huawei
4305	CR 29.500 0162 Rel-15 Corrections on expressions based on ABNF	Huawei	Agreed	WI 5GS_Ph1-CT CAT F
4311	CR 29.509 0102 Rel-15 SoR Header	Huawei	Agreed	WI 5GS_Ph1-CT CAT F
4312	CR 29.509 0103 Rel-16 SoR Header	Huawei	Agreed	WI 5GS_Ph1-CT CAT A
4380	CR 29.501 0092 Storage of YAML files in 3GPP Forge	Huawei	Agreed	WI 5GS_Ph1-CT CAT F
4381	CR 29.501 0092 Storage of YAML files in 3GPP Forge	Huawei	Agreed	WI 5GS_Ph1-CT CAT A
8.2.2	IMS impact due to 5GS IP-CAN	IMSo5G
8.2.3	CT aspects of Northbound APIs for SCEF – SCS/AS Interworking	NAPS-CT
8.2.4	CT aspects of support of voice services over WLAN Access	VoWLAN-CT
8.2.5	CT aspects on enhanced VoLTE performance	eVoLP-CT
8.2.6	Increasing the number of EPS bearers (stage 3)	INOBEAR-CT
8.3	AoB for Rel-15 and earlier	TEI8, TEI9, TEI10, TEI11, TEI12, TEI13, TEI14, TEI15
8.3.1	Diameter	TEI15
CC4	4079	CR 29.230 0686 Rel-15 AVP Codes for TS 29.214	Ericsson	WI TEI15 CAT F No Rel-16 mirror CR, Rel-16 mirror part of this CR is in CR in C4-204080 Ulrich: reason for change says: …indicated by CT3 in LS C3-204xyz… can you please indicate the correct tdoc number. Chairman’s notes in the DAD seem to hint that this relates to the LS in C4-204049, which actually is not the case. Is there another LS which we are missing? Jesus: This LS is expected from the ongoing CT3 meeting these weeks. As soon as they approve the LS, I'll update the CR cover sheet accordingly. Peter Just to clarify the chairman's notes I noted there is no release 16 mirror CR for 4079 but it seems 4080 covers the changes form Rel-15 CR in Rel-16. Jesus Yes, that was the intention for bringing the Rel-16 as cat. F; it contains also the changes done by the Rel-15 CR, plus several additional AVP CC We are waiting for the LS from CT3
8.3.2	AMF	TEI15
4266	CR 29.518 0396 Rel-15 Selected EPS NAS Security Algorithm_Rel15	Ericsson	Revised to C4-204451	WI TEI15 CAT F Other specs effected is yes but nothing referenced Bruno: Please correct the cover page: - WI code: remove TEI15 - Other specs affected: You may also indicate in “Other comments” that Void references should be included when implementing the CR since new references have been added in Rel-16. Jones: Thanks for the comments. Please find V1 draft in /Inbox/Drafts/8.3.2. The draft address comments from Bruno: - Remove TEI15 from “WI Code” - Untick “Other specs affected” - Added “Other comments” indicating “Void references should be included when implementing the CR since new references have been added in Rel-16.”
4451	CR 29.518 0396 Rel-15 Selected EPS NAS Security Algorithm_Rel15	Ericsson
4267	CR 29.518 0397 Rel-16 Selected EPS NAS Security Algorithm_Rel16	Ericsson	Revised to C4-204452	WI TEI16 CAT A Other specs effected is yes but nothing referenced Jones Please find V1 draft in /Inbox/Drafts/8.3.2. The only change is to untick “Other specs affected” in cover page.
4452	CR 29.518 0397 Rel-16 Selected EPS NAS Security Algorithm_Rel16	Ericsson
4382	CR 29.518 0404 Rel 15 Definition of DRX	Huawei	WI TEI15
8.3.3	NSSF	TEI15
4269	CR 29.531 0080 Rel-15 Notify Empty Authorized NSSAI Availability_Rel15	Ericsson	Revised to C4-204453	WI TEI15 CAT F What about Rel-16? C4-204174, C4-204268, C4-204269 are clashing Bruno: We are fine with the principle, but this CR does not correct a FASMO (this should happen very rarely as this means the AMF does not provide any further service in this case). So the CR is only acceptable from Rel-16 onwards. Editorials: . 6.2.6.2.8/9: full stop missing in the description of new Ies /Jones: Fixed 6.2.6.2.10: When there is no supported S-NSSAIs authorized by the NSSF for all Tas "NOTE: The NSSF shall only send notification with an empty array to an NF Service Consumer which has previously indicated support of the "EANAN" feature," /Jones: Fixed 6.2.8: "A NSSF supporting this feature shall send a notification to NF consumer (as subscriber) with an empty array of Authorized NSSAI Availability Data, when there is no supported NSSAI Authorized by the NSSF for all TAs after latest update and the NF consumer indicated support of this feature. A NF Consumer which supports this feature shall accept an empty array of Authorized NSSAI Availability Data in a notification from the NSSF and delete locally stored Authorized NSSAI Availability Data. previously received." /Jones: Fixed Also why do we restrict this CR solely to the notifications? If we want to support this use cace shouldn’t the AuthorizedNssaiAvailabilityInfo be allowed to be empty e.g. in the PUT/patch response? See e.g. Table 6.2.3.2.3.1-2 Table 6.2.3.2.3.1-2: Data structures supported by the PUT Response Body on this resource /Jones: We didn’t purpose the change for PUT and PATCH because we have agreed using 204 response code to indicate the authorized supported NSSAIs are empty after update. If we also apply, then PUT and PATCH will have two alternative to provide the information to the AMF, and AMF needs to prepare to receive both from NSSF Jones: Thanks for your comments. Please find V1 draft in Inbox /Inbox/Drafts/8.3.3. Main changes: Change CR baseline to Rel-16 Add Huawei as co-source Caixia: Thank you for the draft revision. As Huawei’s contribution C4-204174 is merged into this paper, please also include the changes to clause 6.2.5.1 and 6.2.5.2.2 in Huawei’s paper into C4-204269. Jones: I am very sorry for missed this! Please check V2 draft in /Inbox/Drafts/8.3.3. Bruno: Thanks, V2 is fine
4453	CR 29.531 0080 Rel-15 Notify Empty Authorized NSSAI Availability_Rel15	Ericsson
8.3.4	SMF	TEI15
CC2	4333	CR 29.502 0379 Rel-15 H-SMF sending IPv6 Interface Identifier to V-SMF	Huawei	Revised to C4-204342	WI TEI15 CAT F Bruno: The WI code is incorrect (should be 5GS_Ph1-CT). Other comments: we shall say “correction”, not “changes”, since OpenAPI versioning differs depending on whether this is the “correction” or “new feature”. Other comments: This CR adds backward compatible changes to OpenAPI. ueIpv6InterfaceId Ipv6Addr C 0..1 This IE shall be present if the H-SMF has assigned IPv6 interface identifier to the UE during the PDU session activation for the Home-routed Roaming scenario. “establishment” is the proper term. Why do you propose to encode the UE IP interface identifier (64 bits) as a UE IP address (128 bits) and not as 8 octets (this is defined as 8 octets in 24.501 clause 9.11.4.10)? So why not the following Pattern: "^[A-Fa-f0-9]{8}$" ? Giorgi: I’ll fix the WIC, thanks. Back to the man issue. I’ll be okay with using a string pattern "^[A-Fa-f0-9]{8}$", if other agree. The drawback is that "^[A-Fa-f0-9]{8}$" pattern does not let us to use IPv6 string compression mechanism, meaning “::”. So, if there are consecutive 0’s in a suffix, these 0’s shall be explicitly written in to fill 64 bits. On the pro side, "^[A-Fa-f0-9]{8}$" is a way simpler Regex expression, then Ipv6addr or Ipv6Prefix ones are. Please share your views so that I could revise this CR and also companion one for Rel-16 (4332). Giorgi: Revised draft Rel-15 CR 4333_v1 is in the Drafts/8.3.4 folder. Summary: Data type for the new attribute changed to a simple string and therefore there is no need to apply changes to clause 6.1.6.1. Cover sheet updated (WIC, etc.).
4342	CR 29.502 0379 Rel-15 H-SMF sending IPv6 Interface Identifier to V-SMF	Huawei	Bruno Other comments: This CR adds backward compatible new feature to OpenAPI. Bruno> No. “corrections” (this is a Rel-15 Cat F CR) This IE shall be present if the H-SMF has assigned IPv6 interface identifier to the UE during the PDU session establishment for the Home-routed Roaming scenario. When present, it shall encodes the UE IPv6 Interface Identifier to be sent to the UE to build it IPv6 link local address with 8 hex digits. Pattern: "^[A-Fa-f0-9]{8}$"
4426	CR 29.502 0xxx Rel-16 H-SMF sending IPv6 Interface Identifier to V-SMF	Huawei	Revised to C4-204433	A Giorgi: Just noticed this cannot be a mirror, because in Rel-16 we need to address also I-SFM case. Need to revise this once again.
4433	CR 29.502 0xxx Rel-16 H-SMF sending IPv6 Interface Identifier to V-SMF	Huawei	F
4334	CR 29.502 0380 Rel-15 H-SMF sending IPv6 Interface Identifier to V-SMF	Huawei	Withdrawn	WI TEI15 CAT A Mirror CR to be capture by revision of C4-204332
9	Update of the Work Plan
Work Plan Work Plan	CT4 Chairman
10	AoB
11	Future meetings
Meetings in Q4 E-meeting as well: CT4#101e: 3rd November till 13th November. Regarding Q1 Do we need the meeting in January expected to be an e-meeting if needed.
12	Check of Approved Output Documents
other Output Documents	CT4 Chairman
13	Closing of the Meeting (16:00 Friday)

Procedure for CT#89 Plenary:

Rapporteurs will implement the CRs agreed in the CTx meetings handled in the Plenary cycle in both main body and OpenAPI specification. Changes will be identified with the CR number. Rapporteurs will also generate the yaml file by using a proper text editor (e.g. NotePad++)

Rapporteurs will store by Wednesday 02nd September, 17:00 CET the updated TSs in a zip file that will contain the yaml file in the following directories:

CT3: : ftp://ftp.3gpp.org/Email_Discussions/CT3/CT89/Draft

CT4: ftp://ftp.3gpp.org/Email_Discussions/CT4/CT89/Draft

Use EOL account to get access to the repository.

Rapporteurs will indicate in the CTx reflector when the file is available and will also upload the yaml files in ETSI Forge.

The stored version will also include corrections on the topics identified by the rapporteur in the implementation process.

All syntax errors identified by the rapporteur or any other delegate after the 3GPP meeting will be solved by bringing company CRs to the CT Plenary.

Rapporteurs will provide the updated TS version and yaml file by Friday 04th September, 17:00 CET in the following directories:

CT3: ftp://ftp.3gpp.org/Email_Discussions/CT3/CT89/Stable

CT4: ftp://ftp.3gpp.org/Email_Discussions/CT4/CT89/Stable

After the Plenary, rapporteurs will prepare the final TS version, including yaml file, ensuring that all the approved CRs are implemented and will store them under:

ftp://ftp.3gpp.org/Email_Discussions/CT3/CT89/Final

ftp://ftp.3gpp.org/Email_Discussions/CT4/CT89/Final

MCC will ensure that all CRs are correctly implemented and will share the draft TSs by the end of the week after the Plenary.

Rapporteurs & delegates are encouraged to check that all CRs are properly implemented and to use ETSI Forge tool for that purpose.

Email approval, provision of new draft TR/TSs:

draft versions available:	Wednesday	02nd September, 18:00 CEST

Deadline for comments:	Thursday	03rd September, 18:00 CEST

Final versions available:	Friday	04th September, 18:00 CEST

Reminder: 29.501 Annex B (informative): Backward Incompatible Changes

This Annex provides information about the changes in the API that are considered as backwards compatible and those that are considered as backwards incompatible. This list is to be considered informative and it may be expanded in future releases, when necessary.

Backward compatible changes are additions or changes in the API that do not break the existing Service Consumer behaviour. Examples of backward compatible changes include:

-	Adding a new, optional child resource/URI;

-	Supporting a new HTTP method;

-	Adding new elements to a resource representation;

-	Changing the order of fields in a resource representation;

-	Addition of a new status code:

NOTE 1:	When a NF / NF Service receives a HTTP status code that it cannot recognize it will treat it as the corresponding x00 status code as specified in subclause 5.2.7.3 of 3GPP TS 29.500 [2].

-	Corrections of obvious errors in an OpenAPI file required to enable a correct parsing of the file such as misspelled references;

-	Corrections that only relate to smaller and optional parts of the functionality (e.g. a supported feature, see 3GPP TS 29.500 [2] subclause 6.6.2), even if the changes are backward incompatible with respect to that part of the functionality; and

NOTE 2:	It is recommended to only apply corrections which are also backward compatible with respect to such smaller and optional parts of the functionality. If this is not possible a new supported feature can be introduced to enable a negotiation of the support of the correction, and the old corresponding supported feature can be marked as "withdrawn" in the table defining the supported features of an API.

-	Backward-compatible changes related to the semantics (i.e. functional behaviour) specified for an API.

Backward incompatible changes are additions or changes in the API that break the existing Service Consumer behaviour. Here is a list of backward incompatible changes that shall require incrementing the 1st field (MAJOR) of the API version number unless they only relate to smaller and optional parts of the functionality (see above):

-	Removing a resource/URI:

-	Removing support for an HTTP method;

-	Renaming a field in a resource representation;

-	Adding mandatory parameters to a resource URI or resource representation;

-	Attribute data type changes;

-	Cardinality changes (NOTE 3); and

NOTE 3:	Whether attribute cardinality changes are backward compatible depend on the type of change. Examples of non-backward compatibility changes include decreasing the upper bound of a cardinality range for attributes sent by the NF service consumer, changing the meaning of the default behavior associated to the absence of an attribute of cardinality 0..N, etc.

-	Backward incompatible changes related to the semantics (i.e. functional behaviour) specified for an API.