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 1

Agenda item:	2

Document for:	INFORMATION

Saved 18/08/2020 12:33 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	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	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	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	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	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.
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	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.
4082	discussion Rel-17 Rel-17 enhancements for non-public networks in stage-2 WGs	Ericsson
4095	WID new Rel-17 CT aspects on Dynamically Changing AM Policies in the 5GC	Ericsson	CT3 lead CT4 impacted Completion date September 2021
4096	WID new Rel-17 CT aspects on Dynamic Management of Group-based Event Monitoring	Ericsson	CT3 lead CT4 impacted Completion date June 2021
4097	discussion Rel-17 Impacts of eNS_Ph2 to CT WGs	ZTE
CC1	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	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.
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.	CT1 lead CT4 and CT6 impacted Completion date June 2021
4181	discussion Discussion paper on FS_enh_EC	Huawei
4182	discussion Status of study on enhanced support of IIoT in 5GS (FS_IIoT)	Nokia, Nokia Shanghai Bell
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
4273	discussion Rel-17 Discussion on TEI17_SPSFAS and TEI17_DCAMP	China Telecommunications
4299	discussion Analytics on eNA Phase 2 work	Huawei
4300	discussion Roaming Enhancement	Huawei	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.
4326	discussion Rel-17 Impacts of EDGEAPP to CT WGs	Samsung
4331	WID new Rel-17 New WID on Authentication and key management for applications based on 3GPP credential in 5G	China Mobile	CT3 lead CT4 impacted Completion date June 2021
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
6.1.2	Service based Interface protocol improvements	SBIProtoc17
4059	CR 29.510 0369 Rel-17 NF discovery based on SUCI information	China Mobile	WI SBIProtoc17 CAT B See discussion paper in C4-204078.
4078	discussion Discussion on information used for AUSF/UDM discovery based on SUCI	China Mobile Com. Corporation
4094	discussion Rel-17 Evolution of UE Parameter Update mechanism	Ericsson
4124	CR 29.571 0231 Rel-17 Ncgi typo correction	Nokia, Nokia Shanghai Bell	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
4126	CR 29.503 0472 Rel-17 Network Slices in AMF registrations	Nokia, Nokia Shanghai Bell	WI SBIProtoc17 CAT B
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
4136	CR 29.504 0101 Rel-17 Resource Level Authorization for Data Sets	Nokia, Nokia Shanghai Bell	WI SBIProtoc17 CAT B
4137	CR 29.505 0292 Rel-17 Resource Level Authorization for SubscriptionData	Nokia, Nokia Shanghai Bell	WI SBIProtoc17 CAT B
4138	CR 29.503 0473 Rel-17 Resource Level Authorization for UECM registrations	Nokia, Nokia Shanghai Bell	WI SBIProtoc17 CAT B
4139	CR 29.504 0102 Rel-17 Resource Level Authorization for registrations	Nokia, Nokia Shanghai Bell	WI SBIProtoc17 CAT B
4140	CR 29.505 0293 Rel-17 Resource Level Authorization for registrations	Nokia, Nokia Shanghai Bell	WI SBIProtoc17 CAT B
4183	CR 29.510 0374 Rel-17 NF Discovery procedure enhancements	Nokia, Nokia Shanghai Bell	WI SBIProtoc17 CAT B
4328	CR 29.503 0487 Rel-17 Shared Data Treatment	Nokia, Nokia Shanghai Bell	WI SBIProtoc17 CAT B
6.1.3	BEst Practice of PFCP	BEPoP
4028	pCR 29.820 Rel-17 Clarifying the scenario types	Huawei
4029	pCR 29.820 Rel-17 Key issues - general	Huawei
4058	pCR 29.820 Rel-17 Key issue of maintenance of NF deployed on customer side	China Mobile
4075	pCR 29.820 Rel-17 Additional Requirements	Deutsche Telekom AG
4114	pCR 29.820 Rel-17 Key Issue - Feature Classification and Feasibility for Different Services	ZTE	Clash with C4-204132
4115	pCR 29.820 Rel-17 Key Issue - Header Enrichment for HTTPS	ZTE
4116	pCR 29.820 Rel-17 Solution for Header Enrichment for HTTPS	ZTE
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
4130	pCR 29.820 Rel-17 Key Issue on Interoperability issues caused by multiple options co-existence	CATT
4131	pCR 29.820 Rel-17 Key Issue on Interoperability issues caused by vertical industry	CATT
4132	pCR 29.820 Rel-17 Key Issue on Necessary functionality set of PFCP for different use cases	CATT	Clash with C4-204132
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
4245	pCR 29.820 Rel-17 pCR on solution of UE IP address&prefix allocation by SMF in SMF set	China Mobile Com. Corporation
4249	pCR 29.820 Rel-17 KI on UPF Support for Multiple Network Slice Sharing	China Telecommunications
4250	pCR 29.820 Rel-17 Solution on enabling UPF to Support Multiple Network Slice Sharing	China Telecommunications
6.1.4	Port Allocation	PortAl
4031	other Rel-17 TR skeleton for Study on Port Number Allocation Alternatives for New Interfaces	Huawei
4039	discussion Rel-17 pCR on PortAl Introdction	Huawei
4040	discussion Rel-17 pCR on PortAl Scope	Huawei
4041	discussion Rel-17 pCR on PortAl References	Huawei	Withdrawn
4042	discussion Rel-17 pCR on PortAl Definitions of terms, symbols and abbreviations	Huawei
4043	discussion Rel-17 pCR on PortAl Requirements	Huawei
4044	discussion Rel-17 pCR on PortAl Key issues	Huawei
4045	discussion Rel-17 pCR on PortAl Solutions	Huawei
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
4118	other Rel-17 pCR on Introduction of Study on 5G SMS architecture enhancements to support SBASBI	China Telecom, 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
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
4006	CR 29.244 0465 Rel-17 Correction on Reference to RFC 6887	HuaWei	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.
6.3.2	Diameter	TEI17
4013	CR 29.272 0822 Rel-17 Monitoring Configurations in ULA	Nokia, Nokia Shanghai Bell	WI TEI17 CAT F
6.3.3	Common Data	TEI17
4008	CR 29.571 0229 Rel-17 Adding missing Reference to SUPI definition	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.
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.
6.3.4	SBA	TEI17
4014	CR 29.500 0144 Rel-17 Editorial fixes	Huawei	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.
4015	CR 29.500 0145 Rel-17 Fixing proofing language	Huawei	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	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	WI TEI17 CAT F
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
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	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.
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. 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. How to proceed with the CR? Withdrawn/ not pursued?
4185	CR 29.573 0041 Rel-16 TLS security with the 3gpp-Sbi-Target-apiRoot header on N32f	Nokia, Nokia Shanghai Bell, NTT DOCOMO	WI 5G_eSBA CAT F
4186	CR 29.500 0150 Rel-16 TLS security with the 3gpp-Sbi-Target-apiRoot header on N32f	Nokia, Nokia Shanghai Bell, NTT DOCOMO	WI 5G_eSBA CAT F
4187	CR 29.573 0042 Rel-16 Corrections to PRINS call flows	Nokia, Nokia Shanghai Bell	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	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
4189	CR 29.500 0152 Rel-16 Clarifications for Indirect Communications	Nokia, Nokia Shanghai Bell	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
4190	CR 29.510 0375 Rel-16 scpPrefix attribute in SCP profile	Nokia, Nokia Shanghai Bell	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.
4191	CR 29.500 0153 Rel-16 Incorrect references and editorial errors	Nokia, Nokia Shanghai Bell	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	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	WI 5G_eSBA CAT F
4214	CR 29.505 0296 Rel-16 Addition of SMSF registration notification flag	NTT DOCOMO	WI 5G_eSBA CAT F
4215	CR 29.504 0103 Rel-16 Addition of SMSF registration notification flag	NTT DOCOMO	WI 5G_eSBA CAT F
4246	CR 23.527 0024 Rel-16 Reselection when the Routing Binding Indication unavailable	Ericsson	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?
CC1	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; 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). What is problem if a sender includes a routing binding indication (which is built by itself)? 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. 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. 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. 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: Thanks for the comments. 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.
4253	CR 29.500 0159 Rel-16 API Root Change Handling	Ericsson	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 ..." "NOTE 3:The NF as HTTP client can updates the locally stored URI "
4254	CR 29.500 0160 Rel-16 Default Subscription Binding	Ericsson	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.
4255	CR 29.500 0161 Rel-16 Notification for Default Subscriptions	Ericsson	WI 5G_eSBA CAT F Other specs effected? Bruno: There is a typo in the CR title. Other specs affected ticked but w/o dependency indicated 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. 6.10.3.3: new bullets have a wrong style (B3 instead of B2)
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
4261	CR 29.510 0383 Rel-16 Correction on attributes for SCP	Ericsson	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. 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 6.1.6.2.2 : - NOTE 14: "… should be accessed preferably via an SCP that belongs to … ditto in 6.2.6.2.3
4262	CR 29.510 0384 Rel-16 Default Subscription Binding	Ericsson	WI 5G_eSBA CAT F Other specs effected? Bruno: “Other specs affected” needs to be corrected on cover page.
4263	CR 29.510 0385 Rel-16 Message and Information Class for Default Subscription	Ericsson	WI 5G_eSBA CAT F Other specs effected? Bruno: “Other specs affected” needs to be corrected on cover page.
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	WI Vertical_LAN, ETSUN, 5G_URLLC CAT F
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	WI ETSUN CAT F
4107	CR 29.502 0367 Rel-16 Correct the Condition of upCnxState in SmContextCreateData	ZTE	WI ETSUN CAT F
4158	CR 29.244 0475 Rel-16 End marker handling in service request procedure	Huawei	WI ETSUN CAT F
4159	CR 29.502 0368 Rel-16 PDU session deactivation	Huawei	WI ETSUN CAT F
4194	CR 29.502 0373 Rel-16 Error handling for PDU sessions with an I-SMF or V-SMF	Nokia, Nokia Shanghai Bell	WI ETSUN, TEI16 CAT F
4195	CR 29.500 0155 Rel-16 Error handling for PDU sessions with an I-SMF or V-SMF	Nokia, Nokia Shanghai Bell	WI ETSUN, TEI16 CAT F
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	WI ETSUN CAT F
4257	CR 29.502 0376 Rel-16 QosRules during I-SMF and V-SMF Insertion	Ericsson	WI ETSUN CAT F Other specs effected?
4316	CR 29.502 0378 Rel-16 SMF sending IPv6 Interface Identifier to I-SMF	Huawei	Revised to C4-204332	WI ETSUN CAT F
4332	CR 29.502 0378 Rel-16 SMF sending IPv6 Interface Identifier to I-SMF	Huawei	WI ETSUN CAT F
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	WI 5G_eLCS CAT F
4142	CR 29.515 0012 Rel-16 API name correction	Nokia, Nokia Shanghai Bell	WI 5G_eLCS CAT F Other comments is missing.
4156	CR 29.572 0071 Rel-16 Optionality of ProblemDetails in TS29.572 cleanup	Huawei	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
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.
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
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 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 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.
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?
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”
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.
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”.
4279	CR 29.571 0235 Rel-16 Correction of Notification or Verification only for UE Positioning	Qualcomm Incorporated	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.
4293	CR 29.505 0297 Rel-16 Store Broadcast Location Assistance Data	Huawei	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, and I’ll provide V1 based on your comments later.
4294	CR 29.504 0104 Rel-16 Store Broadcast Location Assistance Data	Huawei	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.
4295	CR 29.515 0016 Rel-16 Corrections on EventNotify service operation	Huawei	WI 5G_eLCS CAT F Jones: Some comments: The new figure 5.2.2.2.1 is still wrong, Should be provide Location; 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. Ecgi/ncgi and barometricPressure are not intended to be included in EventNotify. They are only needed in MT-LR for regulatory service. 6.1.5.1, data type start with Upper case altitude 3GPP TS 29.572 [12] Altitude barometricPressure 3GPP TS 29.572 [12] Barometric pressure In OpenAPI, callbacks should be specified for new eventNoticationUri as well (similar to hgmlcCallbackUri): 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' 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. 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. 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 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
4296	CR 29.572 0075 Rel-16 Corrections on EventNotify service operation	Huawei	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.
4297	CR 29.510 0387 Rel-16 Corrections on definition of NotificationType	Huawei	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.
4321	CR 29.515 0017 Rel-16 Corrections on Application Errors in provide-location response	Huawei	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
4322	CR 29.515 0018 Rel-16 Corrections on LocationData	Huawei	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.
CC1	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! What is the status in SA2? Postpone until we receive feedback from SA2.
CC1	4324	CR 29.518 0402 Rel-16 Add Response Codes on operation provide-pos-info	Huawei	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. 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. 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. "[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. Other comments: "This CR won't introduce any impact on OpenAPI specification files." is incorrect Figure 5.5.2.2.1-1: typo "No Content" A.5: "'204': description: Expected response to accept a valid request" confusing 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.
4325	CR 29.518 0403 Rel-16 Corrections on N2InformationNotification	Huawei	WI 5G_eLCS CAT F
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.
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	WI UDICOM CAT F
4064	CR 29.503 0461 Rel-16 Deregistration Reason Clarification	Hewlett-Packard Enterprise	WI UDICOM CAT F
4067	CR 29.563 0007 Rel-16 UeId correction for the EE Subscription	Hewlett-Packard Enterprise	WI UDICOM CAT F
4072	CR 29.503 0463 Rel-16 NodeType in HssAuthenticationInfoRequest	Hewlett-Packard Enterprise	WI UDICOM CAT F
4092	CR 23.632 0023 Rel-16 Missing error conditions in SMSF registration information retrieval	Ericsson	WI UDICOM CAT F
4093	CR 29.503 0468 Rel-16 Definition of missing error conditions in SMSF registration information retrieval	Ericsson	WI UDICOM CAT F
4127	CR 29.563 0008 Rel-16 Correction of HSS Event Exposure data types	Ericsson	WI UDICOM CAT F
4330	CR 29.505 0299 Rel-16 Incorrect index type	Hewlett-Packard Enterprise	WI UDICOM CAT F
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	WI SBIProtoc16 CAT F
4056	CR 29.503 0460 Rel-16 UE Context Retrieval	Hewlett-Packard Enterprise	WI SBIProtoc16 CAT F
4083	CR 29.501 0086 Rel-16 Handling of JSON Arrays	Ericsson	WI SBIProtoc16 CAT F
4086	CR 29.510 0371 Rel-16 NF Group ID	Ericsson	WI SBIProtoc16 CAT F
4087	CR 29.503 0467 Rel-16 UDM parameter provision datakey	Ericsson	WI SBIProtoc16 CAT F
4088	CR 29.510 0372 Rel-16 Handling of S-NSSAI per PLMN	Ericsson	WI SBIProtoc16 CAT F
4089	CR 29.500 0146 Rel-16 Asserted PLMN-ID Header	Ericsson	WI SBIProtoc16 CAT F
4091	CR 29.509 0099 Rel-16 Serving Network Name	Ericsson	WI SBIProtoc16 CAT F
4122	CR 29.501 0087 Rel-16 Naming requirements for resource/operation-level scopes	Nokia, Nokia Shanghai Bell	WI SBIProtoc16 CAT F
4123	CR 29.505 0291 Rel-16 Security for Authentication Subscription Data	Nokia, Nokia Shanghai Bell	WI SBIProtoc16 CAT F
4145	CR 29.501 0088 Rel-16 Data types with string type	Huawei	WI SBIProtoc16 CAT F
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	WI SBIProtoc16 CAT F
4147	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	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
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	Same content as C4-204149
4201	CR 29.510 0377 Rel-16 NF Profile Retrieval procedure with NF Services Map	Nokia, Nokia Shanghai Bell	WI SBIProtoc16 CAT F
4210	CR 29.505 0294 Rel-16 Corrections to default responses	Ericsson	WI SBIProtoc16 CAT F
4212	CR 29.505 0295 Rel-16 Corrections to the Event Group Subscription	Ericsson	WI SBIProtoc16 CAT F
4286	CR 29.501 0089 Rel-16 Content of Location header when TLS is used	Ericsson	WI SBIProtoc16 CAT F
4287	CR 29.510 0386 Rel-16 Default TCP Port	Ericsson	WI SBIProtoc16 CAT F
4306	CR 29.500 0163 Rel-16 Corrections on expressions based on ABNF	Huawei	WI SBIProtoc16 CAT F
4307	CR 29.501 0090 Rel-16 Miscellaneous corrections	Huawei	WI SBIProtoc16 CAT F
4308	CR 29.503 0482 Rel-16 Corrections on reference of common data structures	Huawei	WI SBIProtoc16 CAT F
4309	CR 29.504 0105 Rel-16 Corrections with regard to references	Huawei	WI SBIProtoc16 CAT F
4310	CR 29.505 0298 Rel-16 Correct mismatches of definition between table and yaml	Huawei	WI SBIProtoc16 CAT F
4317	CR 29.503 0484 Rel-16 Storage of YAML files in ETSI Forge	Huawei	WI SBIProtoc16 CAT F
4318	CR 29.503 0485 Rel-16 Corrections on UPU	Huawei	WI SBIProtoc16 CAT F
4319	CR 29.509 0105 Rel-16 Corrections on UPUProtection Service	Huawei	WI SBIProtoc16 CAT F
4320	CR 29.544 0006 Rel-16 Miscellaneous corrections	Huawei	WI SBIProtoc16 CAT F
4327	CR 29.503 0486 Rel-16 Miscellaneous corrections	Huawei	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	WI RACS CAT F
4133	CR 29.673 0007 Rel-16 DicEntryId in DicEntryData	Nokia, Nokia Shanghai Bell	WI RACS CAT F
4134	CR 29.673 0008 Rel-16 UE Radio Capability ID retrieval	Nokia, Nokia Shanghai Bell, Ericsson	WI RACS CAT F
4135	CR 29.674 0006 Rel-16 UE Radio Capability ID retrieval	Nokia, Nokia Shanghai Bell, Ericsson	WI RACS CAT F
4162	CR 29.673 0009 Rel-16 Optionality of ProblemDetails in TS29.673 cleanup	Huawei	WI RACS CAT F
4280	CR 29.518 0400 Rel-16 Managing RACS ID for mobility across ePLMNs	Qualcomm Incorporated	WI RACS CAT F
4281	CR 29.274 1994 Rel-16 Managing RACS ID for mobility across ePLMNs	Qualcomm Incorporated	WI RACS CAT F
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
4104	CR 29.244 0472 Rel-16 Correct IE Type of Redundant Transmission Parameters	ZTE	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. Principle Question: which statement applies for Redundant Transmission Parameters: -If more than one grouped IEs of the same type, but for a different purpose are sent with a message, these IEs shall have different IE types. -If more than one grouped IEs of the same type and for the same purpose are sent with a message, these IEs shall have exactly the same IE type to represent a list.
4105	CR 29.244 0473 Rel-16 Time Stamp in QoS Monitoring Report IE	ZTE	WI 5G_URLLC CAT F Define new time stamp or reuse Event time stamp?
4179	CR 29.502 0371 Rel-16 QoS Monitoring Reporting Frequency	Huawei	WI 5G_URLLC, ETSUN CAT F
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	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	WI 5G_URLLC, eV2XARC, ETSUN CAT F
4298	CR 29.571 0236 Rel-16 Dynamic CN PDB	Huawei	WI 5G_URLLC, ETSUN, 5WWC CAT F
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
4085	CR 29.510 0370 Rel-16 HSS NF Profile Update	Ericsson	WI eIMS5G_SBA CAT F
4090	CR 29.562 0022 Rel-16 Missing Resource Scopes	Ericsson	WI eIMS5G_SBA CAT F
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
4290	CR 29.562 0023 Rel-16 IMS restoration amendments II	Huawei, HiSilicon	WI eIMS5G_SBA CAT F
4291	CR 29.562 0024 Rel-16 Miscellaneous Corrections	Huawei, HiSilicon	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	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	WI NUDSF CAT F
7.1.15	Nsoraf Service Based Interface	NSORAF
4313	CR 29.503 0483 Rel-16 Corrections on 5G SoR	Huawei	WI NSORAF CAT F
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	WI Vertical_LAN CAT F Clash with C4-204196, C4-204209
4196	CR 29.244 0477 Rel-16 Editor's Note on TSN Bridge Name	Nokia, Nokia Shanghai Bell	WI Vertical_LAN CAT F Clash with C4-204023, C4-204209
4209	CR 29.244 0481 Rel-16 Clarification regarding Bridge ID	Intel /Thomas	WI Vertical_LAN CAT F Clash with C4-204196, C4-204023
4071	CR 29.244 0470 Rel-16 Editor's note on multiple NW-TT ports	HuaWei	WI Vertical_LAN CAT F Clash with C4-204197
4197	CR 29.244 0478 Rel-16 Editor's Note on NW-TT ports	Nokia, Nokia Shanghai Bell	WI Vertical_LAN CAT F Clash with C4-204071
4081	CR 29.503 0465 Rel-16 DN-AAA secondary authentication	Ericsson	WI Vertical_LAN CAT F
4084	CR 29.503 0466 Rel-16 Providing configured human-readable readable name for CAG-ID	Ericsson	WI Vertical_LAN CAT F
4282	CR 23.003 0595 Rel-16 Adding definition for HRNN	Qualcomm Incorporated, Deutsche Telekom	WI Vertical_LAN CAT F
7.2.4	CT aspects of Cellular IoT support and evolution for the 5G System	5G_CIoT
4152	CR 29.244 0474 Rel-16 Small data rate control and Serving PLMN rate control	Huawei	WI 5G_CIoT CAT F
4153	CR 29.503 0474 Rel-16 Invoke NEF indication	Huawei	WI 5G_CIoT CAT F
4154	CR 29.503 0475 Rel-16 Maximum response time/latency time	Huawei	WI 5G_CIoT CAT F
4155	CR 29.542 0005 Rel-16 Optionality of ProblemDetails in TS29.542 cleanup	Huawei	WI 5G_CIoT CAT F
4271	discussion Rel-16 Event Configuration Sync Between 4G&5G	Ericsson
4289	CR 23.003 0596 Rel-16 Correction on Truncated 5G-S-TMSI	Huawei	WI 5G_CIoT CAT F
7.2.5	CT aspects on enhancement of network slicing	eNS
4010	CR 29.526 0001 Rel-16 Missing reference clauses	Huawei	WI eNS CAT F
4011	CR 29.526 0002 Rel-17 Missing reference clauses	Huawei	WI eNS CAT A
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
4099	CR 29.526 0005 Rel-16 Update References	ZTE	WI eNS CAT F
4100	CR 29.526 0006 Rel-16 AAA Server Address	ZTE	WI eNS CAT F
4101	CR 29.526 0007 Rel-16 Release PDU Session if NSSAA Re-Authentication and Re-Authorization Fails	ZTE	WI eNS CAT F
4102	CR 29.502 0366 Rel-16 Release PDU Session if NSSAA Re-Authentication and Re-Authorization Fails	ZTE	WI eNS CAT F
4103	CR 29.518 0377 Rel-16 Transfer N2 SM Info Received from SMF to Target AMF	ZTE	WI eNS CAT F
4119	CR 29.531 0075 Rel-16 Feature negotiation for NSSAA at AMF re-allocation	NEC Europe Ltd	WI eNS CAT F
4120	CR 29.526 0008 Rel-16 NSSAA status management	NEC Europe Ltd	WI eNS CAT F
4157	CR 29.518 0381 Rel-16 SNSSAI during mobility procedure	Huawei	WI eNS CAT F
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	WI 5WWC CAT F
4208	CR 29.571 0233 Rel-16 N5GC Location	CableLabs	WI 5WWC CAT F
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
4073	discussion Rel-16 UE IP address allocation alternatives	Huawei	Clash with C4-204251,C4-204272,alternative proposal.
4074	CR 29.244 0471 Rel-16 Using Heartbeat for the UE IP address allocation	Huawei	WI CUPS-CT, TEI16 CAT F Clash with C4-204251,C4-204272,alternative proposal.
4251	discussion Rel-16 Discussion on Report of UE IP address Allocation Status in the UP function	Ericsson	Clash with C4-204073, C4-204074 alternative proposal.
4272	CR 29.244 0483 Rel-16 Report of UE IP address Allocation Status	Ericsson	WI CUPS-CT, TEI16 CAT F Clash with C4-204073, C4-204074 alternative proposal.
4166	CR 29.244 0476 Rel-16 Number of occurrences for an event	Huawei	WI TEI16 CAT F
4199	CR 29.244 0479 Rel-16 Interface Type of Traffic Endpoint	Nokia, Nokia Shanghai Bell	WI TEI16 CAT F
4288	CR 29.244 0484 Rel-16 SMF-Set ID in PFCP Association Messages	Samsung	WI TEI16 CAT F
7.3.2	23.003	TEI16
4024	CR 23.003 0592 Rel-16 Editor's note in introduction sections	HuaWei	WI TEI16 CAT F
7.3.3	Diameter	TEI16
4080	CR 29.230 0687 Rel-16 AVP Codes for TS 29.214	Ericsson	WI TEI16 CAT F
4213	CR 29.272 0823 Rel-16 Immediate Event Report in IDA	Ericsson	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.
4302	CR 29.272 0824 Rel-16 Corrections on Broadcast-Location-Assistance-Data-Types	Huawei	WI TEI16 CAT F
7.3.4	AMF	TEI16
4111	CR 29.518 0379 Rel-16 Clairification on Max Number of Reports	ZTE	WI TEI16 CAT F
4112	CR 29.518 0380 Rel-16 Event Reort in Response to AMF Event Subscription Update	ZTE	WI TEI16 CAT F
4168	CR 29.518 0382 Rel-16 Callback URI correction	Huawei	WI TEI16 CAT F
4172	CR 29.518 0383 Rel-16 Definition of DRX	Huawei	WI TEI16 CAT F
4173	CR 29.518 0384 Rel-16 Update of the PRA Info	Huawei	WI TEI16 CAT F
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
4207	CR 29.518 0386 Rel-16 Clarifications to EBI Assignment procedure	Nokia, Nokia Shanghai Bell	WI TEI16, 5GS_Ph1-CT CAT F
4264	CR 29.518 0394 Rel-16 Additional PraId	Ericsson	WI TEI16 CAT F
4265	CR 29.518 0395 Rel-16 PCF Group Id	Ericsson	WI TEI16 CAT F
4283	CR 29.518 0401 Rel-16 Correction of n2InfoNotifyUrl in figures	Qualcomm Incorporated	WI TEI16 CAT F
7.3.5	SMF	TEI16
4167	CR 29.502 0369 Rel-16 Callback URI correction	Huawei	WI TEI16 CAT F
4169	CR 29.502 0370 Rel-16 Request Type	Huawei	WI TEI16 CAT F
4256	CR 29.502 0375 Rel-16 Handover Cancel 5GS to EPS	Ericsson	WI TEI16 CAT F
4258	CR 29.502 0377 Rel-16 Service Access Authorization between SMFs	Ericsson	WI TEI16 CAT F
7.3.6	UDM	TEI16
4068	CR 29.503 0462 Rel-16 Deregistration Notification	Samsung, Hewlett-Packard Enterprise	WI TEI16 CAT F
4109	CR 29.503 0469 Rel-16 S-NSSAI in SM Context Retrieval	ZTE	WI TEI16 CAT F
4110	CR 29.503 0470 Rel-16 Clairification on Max Number of Reports	ZTE	WI TEI16 CAT F
4170	CR 29.503 0476 Rel-16 Dedicated SMF selection	Huawei, Samsung	WI TEI16 CAT F
4259	CR 29.503 0481 Rel-16 Same SMF Indication	Ericsson	WI TEI16 CAT F
7.3.7	NSSF	TEI16
4061	CR 29.531 0072 Rel-16 Essential correction to event SNSSAI_STATUS_CHANGE_REPORT	Orange, Huawei	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
4113	CR 29.531 0074 Rel-16 TAI Range List Served by an AMF	ZTE	WI TEI16 CAT F
4174	CR 29.531 0076 Rel-16 Availability notification	Huawei	WI TEI16 CAT F C4-204174, C4-204268, C4-204269 are clashing
4175	CR 29.531 0077 Rel-16 Request mapping of S-NSSAI	Huawei	WI TEI16 CAT F
4176	CR 29.531 0078 Rel-16 Subscription modification	Huawei	WI TEI16 CAT F
4268	CR 29.531 0079 Rel-16 Authorized NSSAI Availability Empty Indication	Ericsson	WI TEI16 CAT F C4-204174, C4-204268, C4-204269 are clashing
7.3.8	AUSF	TEI16
4171	CR 29.509 0101 Rel-16 Storage of YAML files in ETSI Forge	Huawei	WI TEI16 CAT F
7.3.9	NRF	TEI16
4108	CR 29.509 0100 Rel-16 Custom Operation Correction	ZTE	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	WI TEI16, 5GS_Ph1-CT CAT F
4206	CR 29.510 0380 Rel-16 supported-features query parameter	Nokia, Nokia Shanghai Bell	WI TEI16, 5GS_Ph1-CT CAT F
4237	discussion 29.510 Rel-16 Inconsistency in Status Notification received to Consumer NF	Cisco Systems
4238	CR 29.510 0381 Rel-16 Making reqNfType as Mandatory IE in SubscriptionData	Cisco Systems	WI 5GS_Ph1-CT, SBIProtoc16 CAT F
7.3.10	SMSF	TEI16
4177	CR 29.540 0056 Rel-16 Storage of YAML files in ETSI Forge	Huawei	WI TEI16 CAT F
7.3.11	Common Data	TEI16
4178	CR 29.571 0232 Rel-16 Error corrections	Huawei	WI TEI16 CAT F
4270	CR 29.571 0234 Rel-16 Additional PraId	Ericsson	WI TEI16 CAT F Remark: Other core specifications is marked but no CR listed.
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
4164	CR 29.274 1992 Rel-16 DCNR during mobility with SGW change	Huawei	WI TEI16 CAT F
4165	CR 29.281 0110 Rel-16 End marker in NG-RAN initiated QoS Flow mobility	Huawei	WI TEI16 CAT F
4248	CR 29.274 1993 Rel-16 Enhancement of network event reporting	Nokia, Nokia Shanghai Bell	WI TEI16 CAT F
7.3.13	DAPS hanover	TEI16
4032	LS in Rel-16 LS on S1/NG DAPS handover	RAN3	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	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	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
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
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	WI 5GS_Ph1-CT CAT F Consequences if not approved states only " Misalignment with stage 2." Should be enhanced.
4027	CR 29.338 0036 Rel-15 SMSF Address Corrections	Hewlett-Packard Enterprise, Nokia, Nokia Shanghai Bell, AT&T	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	WI 5GS_Ph1-CT CAT A
4065	CR 29.273 0524 Rel-15 AAA Deregistration due to EPC restriction	Hewlett-Packard Enterprise	WI 5GS_Ph1-CT CAT F
4066	CR 29.273 0525 Rel-16 AAA Deregistration due to EPC restriction	Hewlett-Packard Enterprise	WI 5GS_Ph1-CT CAT A
4150	discussion Misalignment between TS 33.501 and TS 29.573 on JSON object	Huawei
4151	LS out Misalignments on JSON object	Huawei
4216	CR 29.518 0387 Rel-15 Correction of UE Context Transfer payload in case of UE initial registration	NTT DOCOMO	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	WI 5GS_Ph1-CT CAT A
4218	CR 23.003 0593 Rel-15 SMSF FQDN	NTT DOCOMO	WI 5GS_Ph1-CT CAT F
4219	CR 23.003 0594 Rel-16 SMSF FQDN	NTT DOCOMO	WI 5GS_Ph1-CT CAT A
4220	CR 29.503 0477 Rel-15 Introduction of NOTE for “freeze 5G-TMSI” in case of Purge	NTT DOCOMO	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	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
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
4224	CR 29.518 0391 Rel-15 Registration Status Update for PCF for UE Policy	NTT DOCOMO	WI 5GS_Ph1-CT CAT F
4225	CR 29.518 0392 Rel-16 Registration Status Update for PCF for UE Policy	NTT DOCOMO	WI 5GS_Ph1-CT CAT A
4226	CR 29.503 0479 Rel-15 Correction of creation of subscription by UDM at UDR	NTT DOCOMO	WI 5GS_Ph1-CT CAT F
4227	CR 29.503 0480 Rel-16 Correction of creation of subscription by UDM at UDR	NTT DOCOMO	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	WI 5GS_Ph1-CT CAT F
4242	CR 29.573 0044 Rel-16 Error handling of mismatch of polices at SEPP	NTT DOCOMO	WI 5GS_Ph1-CT CAT A
4243	CR 29.573 0045 Rel-15 Correction of flow description	NTT DOCOMO	WI 5GS_Ph1-CT CAT F
4244	CR 29.573 0046 Rel-16 Correction of flow description	NTT DOCOMO	WI 5GS_Ph1-CT CAT A
4303	CR 29.572 0076 Rel-15 Correct mismatch on GeographicArea between table and yaml	Huawei	WI 5GS_Ph1-CT CAT F
4304	CR 29.572 0077 Rel-16 Correct mismatch on GeographicArea between table and yaml	Huawei	WI 5GS_Ph1-CT CAT A
4305	CR 29.500 0162 Rel-15 Corrections on expressions based on ABNF	Huawei	WI 5GS_Ph1-CT CAT F
4311	CR 29.509 0102 Rel-15 SoR Header	Huawei	WI 5GS_Ph1-CT CAT F
4312	CR 29.509 0103 Rel-16 SoR Header	Huawei	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
4079	CR 29.230 0686 Rel-15 AVP Codes for TS 29.214	Ericsson	WI TEI15 CAT F Rel-16 mirror part CR in C4-204080
8.3.2	AMF	TEI15
4266	CR 29.518 0396 Rel-15 Selected EPS NAS Security Algorithm_Rel15	Ericsson	WI TEI15 CAT F Other specs effected is yes but nothing referenced
4267	CR 29.518 0397 Rel-16 Selected EPS NAS Security Algorithm_Rel16	Ericsson	WI TEI16 CAT A Other specs effected is yes but nothing referenced
8.3.3	NSSF	TEI15
4269	CR 29.531 0080 Rel-15 Notify Empty Authorized NSSAI Availability_Rel15	Ericsson	WI TEI15 CAT F What about Rel-16? C4-204174, C4-204268, C4-204269 are clashing
8.3.4	SMF	TEI15
4333	CR 29.502 0379 Rel-15 H-SMF sending IPv6 Interface Identifier to V-SMF	Huawei	WI TEI15 CAT 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.