MinuteMan TDoc list by agenda item at 2019-11-15 22:06 Romance Standard Time

Agenda item: 16.30.2 : TEI16 for Packet Core

Current TDoc: C3-195446

Agenda Topic TDoc Title Source Type For Avail Treated Decision Wdrn Repl-by Replaces
1 Opening of the meeting                      
2 Agenda/Schedule                      
2.1 Approval of the agenda C3‑195000 Draft Agenda for the CT3#107 Meeting CT3 chairman agenda Information Yes
Yes
approved No    
2.2 Proposed Schedule C3‑195001 Proposed Schedule for CT3#107 CT3 chairman other Information Yes
YesThe Chairman outlined the proposed schedule, and this was accepted with a minor change at the request of Samsung. Huawei had delivered some technical comments by mail, and the company would not participate in those sessions. Ericsson also wished for a rearrangement.
noted No    
3 Registration of documents C3‑195002 Allocation of documents to agenda items (at Deadline) CT3 chairman other Information Yes
Yes
noted No    
    C3‑195003 Allocation of documents to agenda items (Start of Day 1) CT3 chairman other Information Yes
Yes
noted No    
    C3‑195004 Allocation of documents to agenda items (Start of Day 2) CT3 chairman other Information Yes
Yes
noted No    
    C3‑195005 Allocation of documents to agenda items (Start of Day 3) CT3 chairman other Information Yes
Yes
noted No    
    C3‑195006 Allocation of documents to agenda items (Start of Day 4) CT3 chairman other Information Yes
Yes
noted No    
    C3‑195007 Allocation of documents to agenda items (Start of Day 5) CT3 chairman other Information Yes
YesThe Chairman drew delegates' attention to the actions needed after the meeting.
noted No    
    C3‑195008 Allocation of documents to agenda items (End of Day 5) CT3 chairman other Information No
No
reserved No    
4 Reports                      
4.1 Report from previous CT3 meeting C3‑195011 Minutes of CT3#106 MCC report Approval Yes
Yes
approved No    
4.2 Report from previous CT plenary C3‑195010 reserved CT3 chairman report   No
Yes
withdrawn Yes    
4.3 Reports from other groups                      
5 Items for immediate consideration                      
5.1 IPR disclosures                      
5.2 Antitrust declarations                      
5.3 Statement Regarding Engagement with Companies Added to the U.S. Export Administration Regulations (EAR) Entity List in 3GPP Activities                      
Agenda Topic TDoc Title Source Type For Avail Treated Decision Wdrn Repl-by Replaces
5.4 Other items for immediate consideration                      
6 Received Liaison Statements C3‑195173 Reply LS to LS on maximum value of MDBV CT4 LS in Discussion Yes
YesThe Chairman drew attention to the LS from SA2 in C3-195181.
noted No    
    C3‑195181 Reply LS on LS on maximum value of MDBV SA2 LS in Discussion Yes
YesThe Chairman drew attention to the CRs on this topic.
noted No    
    C3‑195174 LS on NID structure and length CT4 LS in Discussion Yes
YesThe Chairman proposed to discuss this LS in conjunction with that in C3-195195 to determine whether any feedback was required. The document was presented by Ericsson. It was concluded that the LS confirmed "business as usual". Nokia agreed, CT3 did not need to provide a response.
noted No    
    C3‑195195 Reply LS on NID structure and length SA2 LS in Discussion Yes
YesEricsson introuduced the document, noting that the CT3 interfaces would follow rather than set any new aspects.
noted No    
    C3‑195175 LS on Support of Network Address Translation in the User Plane function CT4 LS in Discussion Yes
YesThe Chairman observed that there was no action on CT3.
noted No    
    C3‑195176 LS on Enhanced coverage restriction CT4 LS in Discussion Yes
YesThe Chairman observed that there was no action on CT3.
noted No    
    C3‑195177 Reply LS on Nudr_DM evolution CT4 LS in Discussion Yes
YesThe Chairman observed that the LS had already been checked in meeting CT3#106 and there had been no comments. No further action was required.
noted No    
    C3‑195178 Reply LS on "SMF Event Exposure enhancement for service experience" SA2 LS in Discussion Yes
YesThe document was introduced by Huawei. No CR had been provided at this meeting, but one would be seen at meeting #108.
postponed No    
    C3‑195179 Reply LS on N6 routing information in AF acknowledgement SA2 LS in Discussion Yes
YesHuawei also proposed to come back to this LS in the next meeting.
postponed No    
    C3‑195180 Reply LS on Nsmf_EventExposure and Nnef_EventExposure service handling of the "Downlink data delivery status" and "Availability after DDN Failure" events. SA2 LS in Discussion Yes
YesNokia introduced the document, indicating that the topic was complex. A number of questions needed to be addressed. No CRs had been provided to the present meeting. The Chairman noted that Rel-16 freeze was just round the corner.
postponed No    
    C3‑195182 Reply LS on AUSF role in slice specific authentication SA2 LS in Discussion Yes
YesThe Chairman drew attention to the related CR. Ericsson introduced the LS. The action was on SA3. There might be some action needed by CT3 after SA3 had made its response.
noted No    
    C3‑195183 LS on QoS mapping procedure SA4 LS in Discussion Yes
YesThe LS was presented by Ericsson. No CRs were available at the present meeting. The necessary CRs were still in preparation, and were dependent on SA3 work.
postponed No    
    C3‑195393 Reply LS (S6-192023) on clarifications regarding SEAL services SA6 LS in Action Yes
Yes
revised No C3‑195397  
    C3‑195397 Reply LS (S6-192023) on clarifications regarding SEAL services SA6 LS in Action Yes
Yes
noted No   C3‑195393
7 Release 7 and earlier releases                      
8 Release 8                      
8.1 Release 8 IMS/CS Work Items                      
8.2 Release 8 Packet Core Work Items                      
9 Release 9                      
Agenda Topic TDoc Title Source Type For Avail Treated Decision Wdrn Repl-by Replaces
9.1 Release 9 IMS/CS Work Items                      
9.2 Release 9 Packet Core Work Items                      
10 Release 10                      
10.1 Release 10 IMS/CS Work Items C3‑195417 Corrrection for setting conditrion of the Contact header field NTT CR Agreement Yes
Yes
agreed No    
    C3‑195418 Corrrection for setting conditrion of the Contact header field NTT CR Agreement Yes
Yes(Cover sheet errors.)
revised No C3‑195427  
    C3‑195427 Corrrection for setting conditrion of the Contact header field NTT CR Agreement Yes
Yes
agreed No   C3‑195418
    C3‑195419 Corrrection for setting conditrion of the Contact header field NTT CR Agreement Yes
Yes(Cover sheet errors.)
revised No C3‑195428  
    C3‑195428 Corrrection for setting conditrion of the Contact header field NTT CR Agreement Yes
Yes
agreed No   C3‑195419
    C3‑195420 Corrrection for setting conditrion of the Contact header field NTT CR Agreement Yes
Yes(Cover sheet errors.)
revised No C3‑195429  
    C3‑195429 Corrrection for setting conditrion of the Contact header field NTT CR Agreement Yes
Yes
agreed No   C3‑195420
    C3‑195421 Corrrection for setting conditrion of the Contact header field NTT CR Agreement Yes
Yes(Cover sheet errors.)
revised No C3‑195430  
    C3‑195430 Corrrection for setting conditrion of the Contact header field NTT CR Agreement Yes
Yes
agreed No   C3‑195421
    C3‑195422 Corrrection for setting conditrion of the Contact header field NTT CR Agreement Yes
Yes(Cover sheet errors.)
revised No C3‑195431  
    C3‑195431 Corrrection for setting conditrion of the Contact header field NTT CR Agreement Yes
Yes
agreed No   C3‑195422
    C3‑195423 Corrrection for setting conditrion of the Contact header field NTT CR Agreement Yes
Yes(Cover sheet errors.)
revised No C3‑195432  
    C3‑195432 Corrrection for setting conditrion of the Contact header field NTT CR Agreement Yes
Yes
agreed No   C3‑195423
10.2 Release 10 Packet Core Work Items                      
11 Release 11                      
11.1 Release 11 IMS/CS Work Items                      
11.2 Release 11 Packet Core Work Items                      
Agenda Topic TDoc Title Source Type For Avail Treated Decision Wdrn Repl-by Replaces
12 Release 12                      
12.1 Release 12 IMS/CS Work Items                      
12.2 Release 12 Packet Core Work Items                      
13 Release 13                      
13.1 Release 13 IMS/CS Work Items                      
13.2 Release 13 Packet Core Work Items                      
14 Release 14                      
14.1 Release 14 IMS/CS Work Items                      
14.2 Release 14 Packet Core Work Items                      
15 Release 15                      
15.1 Study on Policy and Charging for Volume Based Charging [FS_PC_VBC]                      
15.2 CT aspects on 5G System - Phase 1 [5GS_Ph1-CT]                      
15.2.1 Technical Report (TR 29.890)                      
15.2.2 Access and Mobility Policy Control Services (TS 29.507) C3‑195147 Correction on 307 error, 29.507 Ericsson CR Agreement Yes
YesIn the second change, Samsung noted an error concerning termination. There was some discussion between Ericsson and Nokia over the handling of HTTP messages, particularly 308. There had been an ambiguity in the previous text of this spec. All subsequent communications would be sent to the new URI, following a 308 message. Meanwhile error 404 was a temporary, not found, indication. Ericsson maintained that the correct message was 307. A lengthy discussion ensued.
revised No C3‑195265  
    C3‑195265 Correction on 307 error, 29.507 Ericsson CR Agreement Yes
Yes
agreed No   C3‑195147
    C3‑195148 Correction on 307 error, 29.507 Ericsson CR Agreement Yes
Yes
revised No C3‑195266  
    C3‑195266 Correction on 307 error, 29.507 Ericsson CR Agreement Yes
Yes
agreed No   C3‑195148
15.2.3 Session Management Event Exposure Service (TS 29.508) C3‑195149 Correction on 307 error, 29.508 Ericsson CR Agreement Yes
YesVodafone requested in minor clarification of the text.
revised No C3‑195302  
    C3‑195302 Correction on 307 error, 29.508 Ericsson CR Agreement Yes
Yes
agreed No   C3‑195149
    C3‑195150 Correction on 307 error, 29.508 Ericsson CR Agreement Yes
Yes
revised No C3‑195303  
Agenda Topic TDoc Title Source Type For Avail Treated Decision Wdrn Repl-by Replaces
    C3‑195303 Correction on 307 error, 29.508 Ericsson CR Agreement Yes
Yes
agreed No   C3‑195150
15.2.4 Session Management Policy Control Services (TS 29.512) C3‑195035 CHF addresses as apiRoot in the form of an FQDN Nokia, Nokia Shanghai Bell CR Agreement Yes
Yes
agreed No    
    C3‑195036 CHF addresses as apiRoot in the form of an FQDN Nokia, Nokia Shanghai Bell CR Agreement Yes
Yes
agreed No    
    C3‑195076 Request of SM Policy Association Termination during the Update procedure Oracle Corporation CR   Yes
YesHuawei prefered only to make this change from Rel-16. Nokia agreed, but noted that there was already a procedure PCF to send a termination request. This new procedure effectively replaced that procedure. This would reduce the number of messages. This would be clear to do from Rel-16 onwards. Oracle agreed but noted that the old procedure would remain, and not be made obsolete. The CR offered an additional supported procedure. Huawei recalled a CR agreed in the previous meeting, and Oracle agreed that the same could be used.
rejected No    
    C3‑195077 Request of SM Policy Association Termination during the Update procedure Oracle Corporation CR   Yes
YesThe CR was originally a mirror treated under agenda item 15.2.4. But it was decided not persue the Rel-15 version. It was moved to agenda item 16.4.
revised No C3‑195304  
    C3‑195089 Correction to delete a PCC rule requested by the UE Huawei CR Approval Yes
Yes
agreed No    
    C3‑195090 Correction to delete a PCC rule requested by the UE Huawei CR Approval Yes
Yes
agreed No    
    C3‑195091 Termination action Huawei CR Approval Yes
Yes
agreed No    
    C3‑195092 Termination action Huawei CR Approval Yes
Yes
agreed No    
    C3‑195153 Correction of AF Charging Identifier data type Ericsson CR Agreement Yes
YesIt had to be decided whether to go for a backward compatible or incompatible solution. Huawei preferred not to move to a v2 of the API, but they were not sure whether this would be possible to solve all CRs at this meeting with only backward compatible solutions. (The Chairman recalled the discussions on supi.) Ericsson recalled a change in CT4, and the solution was to introduce an optional flag to indicate that the mandatory attribute should be ignored. CT4 had even considered addting this as a rule to 29.500, thus enshrining this "diirty" approach for all time. This led to some debate as to the desirabilty of this.What would be the case if the producer supported the flag but the consumer did not? The consumer would probably reject it with an arror message and the session would terminate. This might differ from implementation to implementation, and from feature to feature. The discussion concentrated on the specific supi case. Openet was unsure of the meaning of the second note. The wording of the second sentence could be improved. Nokia questioned the naming of the supported feature: it was a bit restrictive to mention IMS. Huawei queried the charging identifiers in the core and radio access networks. Ericsson had investigated this and was confident that the proposed mechanism was valid. After off line consideration, the Chairman again asked whether to stay with v1 of the API, or to move to v2. Nokia and China Mobile expressed a strong desire to remain with v1. This was well supported by others. A flag or feature would be introduced. But Orange insisted that a solution (cf 29.501) really was needed. Ericsson believed the solution was more complex than this decision. The spec would only move to v2 when some architectectural change was introduced. A feagure "Emergency with non-required supi" could be introduced, and for emmergency sessions, the PCF would ignore the supi contents. Openet was concerned about the details of such a solution, which would require careful specification. The feature would have to handle an "invalid" supi carefully depending on whether or not it was an emergency session, and not react with an error. Oracle thought this was dangerous, but a solution like that proposed in CT4 by coding in the JSON could work. It was essential to upgrade the PCF. The Chairman reported that there was precedence for this using a dummy ISDSN in an old application. So the same approach could be taken for a dummy supi. China Mobile asked for more time for off line discussion. Ericsson believed either solution would in effect result in backward incompatibility. Nokia believed the main problem was that if the server moved to v2, then interworking with a v1 client would no longer be possible. Both sides would have to upgrade. But retaining v1, this problem was avoided, except for the emergency situation. This was far preferable, excepting that a way would have to be found of handling the emergency, exceptional, case. Ericsson wondered if it was viable to change supi from mandatory to optional. The problem was compounding itself with each bodge. Oracle proposed a low risk solution using IMSI'. This was more elegant than a "we did it wrong" flag!
revised No C3‑195305  
    C3‑195305 Correction of AF Charging Identifier data type Ericsson CR Agreement Yes
YesAfter extensive discussion, no consensus could be reached and the topic was postponed to the next meeting.
postponed No   C3‑195153
    C3‑195154 Correction of AF Charging Identifier data type Ericsson CR Agreement Yes
Yes
revised No C3‑195306  
    C3‑195306 Correction of AF Charging Identifier data type Ericsson CR Agreement Yes
Yes
agreed No   C3‑195154
    C3‑195193 Correction to SUPI attribute Samsung CR Agreement Yes
NoNokia wondered whether supi was really conditional. The required attribute had now become optional, and there was concerned over backward compatibility. The Chairman shared this concern. The version of the API would need to be changed to v2. Huawei wondered whether some other solution might be possible, maintaining backward compatibility, but had no concrete proposal. Ericsson wished it to be confirmed that supi was optional - or mandatory with a "dummy" value. There was no resisstance amongst delegates to incrementing the OpenAPI version. Ericsson was concerned that the reason for change on the CR was deficient. In fact, many clauses of the spec should have been updated. Ericsson suggested that CT3 should take time for a detailed review of potential changes, but time was short. Perhaps this change should be postponed to the next meeting. Nokia agreed that further changes in the next meeting would probably be needed, and the API version could be upgraded then. Openet was concerned that there was a danger of breaking the protocol if insufficient care was taken with this change. They proposed including a note to indicate that more changes were to come. Nokia was concerned that this unclean solution would be mirrored to Rel-16, and this was undesirable. Huawei observed that CT4 was currently debating how to manage such dichotomies. The Huawei proposal was that supi should be ignored for an emergency session. Nevertheless, the Chairman insisted that a dummy value should be defined for this eventuality. But it was agreed that it was poor specification to allow a mandatory attribute to be ignored. Ericsson thought the best solution would be to postpone this CR and increment the version next time. Samsung noted that there were already implementations with supi as mandatory, but there was some doubt as to whether these implementations would work for emmergency sessions. Nokia believed that it was desirable to find a generic solution for cases such as this. Ericsson agreed that a "proper" fix should be found. China Mobile believed CT3 and CT4 solutions should be compatible, albeit with different APIs. There was a preference for having a dummy (invalid) supi patern rather than an "ignore me" flag. (Oracle, Samsung, ) but there was no agreement on what value to use. Openet still had a preference for changing from mandatory to optional, this was safer for backward compatibility. The TSG CT Chairman recalled a similar situation with SIP. In this case, a specific (valid) value had been selected. Ericsson recalled that the only use case which would fail at present was the emergency session. But the solution here would only work if both entities were upgraded. So why not do it properly and use the solution proposed by Samsung? Further exchanges of views took place. China Mobile supported the dummy supi value. Oracle proposed to leave the supi blank.But, it was countere, the problem was that the format of the IMSI was well established and outside the remit of CT3, in 23.003. In this case, why not explicitly define the new pattern as specifically valid and related to an emergency session. Huawei maintained that in an emergency session there would be no subscription check so the supi would be ignored, so its value was irrelevant, other than it should be invalid.
not concluded No    
    C3‑195194 Correction to SUPI attribute Samsung CR Agreement Yes
No
not concluded No    
15.2.5 Policy Authorization Services (TS 29.514) C3‑195118 Correct VLAN tag description Ericsson CR   Yes
Yes
agreed No    
    C3‑195119 Correct VLAN tag description Ericsson CR   Yes
Yes
agreed No    
    C3‑195155 Corrections to several mistakes Ericsson CR Agreement Yes
Yes
agreed No    
    C3‑195156 Corrections to several mistakes Ericsson CR Agreement Yes
Yes
agreed No    
15.2.6 Policy and Charging Control signalling flows and QoS parameter mapping (TS 29.513)                      
Agenda Topic TDoc Title Source Type For Avail Treated Decision Wdrn Repl-by Replaces
15.2.7 Network Data Analytics Services (TS 29.520)                      
15.2.8 Interworking between 5G Network and External Data Networks (TS 29.561)                      
15.2.9 Usage of the Unified Data Repository service for Policy Control Data and Structured Data (TS 29.519) C3‑195060 Definition of BdtData in OpenAPI Ericsson CR Agreement Yes
YesNokia noted that there was no change in the properties field, so it might be considered as backward-incompatible, but in this case it was acceptable. China Mobile had some concerns over this. Ericsson clarified the situation: it was a corner case. Openet agreed that this was an essential change to prevent misoperation of the protocol. It was acceptable to correct the name of the property in the requied fields in a backward compatible way.
agreed No    
    C3‑195061 Definition of BdtData in OpenAPI Ericsson CR Agreement Yes
Yes
agreed No    
15.2.10 Packet Flow Description Management Service (TS 29.551)                      
15.2.11 Network Exposure Function Northbound APIs (TS 29.522) C3‑195116 Correct cardinality in traffic influence Ericsson CR   Yes
Yes
agreed No    
    C3‑195117 Correct cardinality in traffic influence Ericsson CR   Yes
Yes
agreed No    
    C3‑195084 make the storage of traffic influence request in the UDR mandatory ZTE CR Approval Yes
YesNokia queried the first change, from optional to mandatory. There was in fact no alternative. The WI code was wrong.
revised No C3‑195325  
    C3‑195325 make the storage of traffic influence request in the UDR mandatory ZTE CR Approval Yes
Yes
agreed No   C3‑195084
    C3‑195085 make the storage of traffic influence request in the UDR mandatory ZTE CR Approval Yes
Yes
revised No C3‑195326  
    C3‑195326 make the storage of traffic influence request in the UDR mandatory ZTE CR Approval Yes
Yes
agreed No   C3‑195085
15.2.12 Binding Support Management Service (TS 29.521)                      
15.2.13 Background Data Transfer Policy Control Service (TS 29.554)                      
15.2.14 Spending Limit Control Service (TS 29.594)                      
15.2.15 UE Policy Control Service (TS 29.525) C3‑195145 Correction to PolicyUpdate Ericsson, ZTE CR Agreement Yes
Yes
agreed No    
    C3‑195146 Correction to PolicyUpdate Ericsson, ZTE CR Agreement Yes
Yes
agreed No    
    C3‑195151 Correction on 307 error, 29.525 Ericsson CR Agreement Yes
YesHuawei considered that this change was not needed from a technical point of view. There would be no subsequent message. Ericsson understood the point but preferred technical rigour. Oracle believed the change was indeed required. Nokia thought there would be no difference from a functional point of view, but it was indeed correct to make this change, in line with the 307 error response.
revised No C3‑195327  
    C3‑195327 Correction on 307 error, 29.525 Ericsson CR Agreement Yes
Yes
agreed No   C3‑195151
    C3‑195152 Correction on 307 error, 29.525 Ericsson CR Agreement Yes
Yes
revised No C3‑195328  
    C3‑195328 Correction on 307 error, 29.525 Ericsson CR Agreement Yes
Yes
agreed No   C3‑195152
Agenda Topic TDoc Title Source Type For Avail Treated Decision Wdrn Repl-by Replaces
    C3‑195080 the behavior of V-PCF for 202 ATTEMPTING response ZTE CR Approval Yes
YesThe WI code was wrong. Ericsson sought clarification of the procedures: did the V-PCF buffer the information? ZTE said yes, it would store it. Ericsson wondered whether it was necessary to receive policy information. Why would this message be stored in the V-PCF? And if so, why? Did this all relate to an unreachable UE? Huawei sought to clarify the procedure. Perhaps the text could be further clarified. The Chairman warned against attempting to specify matters beyond the scope of this TS. There was further discussion on the wider picture, and more detaill needed to be included in the TS.
revised No C3‑195329  
    C3‑195329 the behavior of V-PCF for 202 ATTEMPTING response ZTE CR Approval No
Yes
postponed No   C3‑195080
    C3‑195081 the behavior of V-PCF for 202 ATTEMPTING response ZTE CR Approval Yes
Yes
revised No C3‑195330  
    C3‑195330 the behavior of V-PCF for 202 ATTEMPTING response ZTE CR Approval No
Yes
postponed No   C3‑195081
15.2.16 Policy Control Event Exposure Service (TS 29.523)                      
15.2.17 5G Impacts in existing TSs                      
15.3 IMS Stage-3 IETF Protocol Alignment [IMSProtoc9]                      
15.4 CT aspects of Northbound APIs for SCEF-SCSAS Interworking [NAPS-CT] C3‑195125 Correct application port Ericsson CR   Yes
Yes
revised No C3‑195276  
    C3‑195276 Correct application port Ericsson CR - Yes
YesThe tdoc number had not been updated on the cover page.
revised No C3‑195399 C3‑195125
    C3‑195399 Correct application port Ericsson CR - Yes
Yes
agreed No   C3‑195276
    C3‑195126 Correct application port Ericsson CR   Yes
Yes
revised No C3‑195277  
    C3‑195277 Correct application port Ericsson CR - Yes
YesThere had ben an offline comment to merge two bullet points.
agreed No   C3‑195126
    C3‑195282 Correct SCEF aggregation Ericsson CR Agreement Yes
Yes
agreed No   C3‑194457
    C3‑195283 Correct SCEF aggregation Ericsson CR Agreement Yes
Yes
agreed No   C3‑194458
15.5 CT aspects of Enhanced Calling Name Service [eCNAM-CT]                      
15.6 EPC enhancements to support 5G New Radio via Dual Connectivity, CT aspects [EDCE5-CT]                      
15.7 Enhancements to Mission Critical Video - CT aspects [eMCVideo-CT]                      
15.8 IMS impact due to 5GS IP-CAN [5GS_Ph1-IMSo5G] C3‑195057 P-CSCF restoration in 5GS Ericsson CR Agreement Yes
YesOne typo was noted.
revised No C3‑195292  
    C3‑195292 P-CSCF restoration in 5GS Ericsson CR Agreement Yes
Yes
revised No C3‑195357 C3‑195057
    C3‑195357 P-CSCF restoration in 5GS Ericsson CR Agreement Yes
Yes
agreed No   C3‑195292
Agenda Topic TDoc Title Source Type For Avail Treated Decision Wdrn Repl-by Replaces
    C3‑195058 P-CSCF restoration in 5GS Ericsson CR Agreement Yes
Yes
revised No C3‑195293  
    C3‑195293 P-CSCF restoration in 5GS Ericsson CR Agreement Yes
Yes
revised No C3‑195358 C3‑195058
    C3‑195358 P-CSCF restoration in 5GS Ericsson CR Agreement Yes
Yes
agreed No   C3‑195293
    C3‑195365 Update of OpenAPI version and TS version in externalDocs field Samsung CR Agreement No
NoEmail agreement, see details in C3-195351.
not concluded No    
15.9 CT aspects on enhanced VoLTE performance [eVoLP-CT]                      
15.10 CT aspects of 3GPP PS data off function Phase 2 [PS_DATA_OFF2-CT]                      
15.11 Policy and Charging for Volume Based Charging [PC_VBC]                      
15.12 Common API Framework for 3GPP Northbound APIs [CAPIF-CT] C3‑195211 Correct the notificationDestination of ServiceSecurity object in yaml file China Mobile Communications Group Co.,Ltd. CR Agreement Yes
Yes
agreed No C3‑195278  
    C3‑195278 Correct the notificationDestination of ServiceSecurity object in yaml file China Mobile Communications Group Co.,Ltd. CR Agreement Yes
Yes
agreed No   C3‑195211
    C3‑195212 Correct the notificationDestination of ServiceSecurity object in yaml file China Mobile Communications Group Co.,Ltd. CR Agreement Yes
Yes
revised No C3‑195279  
    C3‑195279 Correct the notificationDestination of ServiceSecurity object in yaml file China Mobile Communications Group Co.,Ltd. CR Agreement Yes
Yes
agreed No   C3‑195212
    C3‑195213 Align the API name of Initiate_Authentication China Mobile Communications Group Co.,Ltd. CR Agreement Yes
Yes
revised No C3‑195280  
    C3‑195280 Align the API name of Initiate_Authentication China Mobile Communications Group Co.,Ltd. CR Agreement Yes
Yes
agreed No   C3‑195213
    C3‑195214 Align the API name of Initiate_Authentication China Mobile Communications Group Co.,Ltd. CR Agreement Yes
Yes
revised No C3‑195281  
    C3‑195281 Align the API name of Initiate_Authentication China Mobile Communications Group Co.,Ltd. CR Agreement Yes
Yes
agreed No   C3‑195214
15.13 SRVCC for terminating call in pre-alerting phase [bSRVCC-MT]                      
15.14 Mobile Communication System for Railways [MONASTERY]                      
15.15 Enhancements to Call spoofing functionality [eSPECTRE]                      
15.16 CT aspects of 5G Trace management [NETSLICE-5GTRACE-CT]                      
15.17 Technical Enhancements and Improvements [TEI15]                      
Agenda Topic TDoc Title Source Type For Avail Treated Decision Wdrn Repl-by Replaces
15.17.1 TEI15 for IMS/CS                      
15.17.2 TEI15 for Packet Core C3‑195113 Format for FEC framework configuration information in MB2 ENENSYS, Ericsson CR   Yes
YesIt was questioned why there was no Rel-16 mirror. This was because there was not yet a Rel-16 version.
agreed No   C3‑190446
    C3‑195114 Format for FEC framework configuration information in xMB ENENSYS, Ericsson CR   Yes
Yes
agreed No   C3‑190457
    C3‑195115 Format for FEC framework configuration information in xMB ENENSYS, Ericsson CR   Yes
Yes
agreed No    
    C3‑195127 Correct transit failure code for UE suspension Ericsson CR   Yes
Yes
agreed No    
    C3‑195128 Correct transit failure code for UE suspension Ericsson CR   Yes
Yes
agreed No    
    C3‑195129 LS on transit failure code in TS 29.212 Ericsson LS out   Yes
YesIt was proposed to send a single LS to CT4 to include all necessary aspects. But after discussion, it seemed that there was only one aspect.
approved No    
15.18 OpenAPI version updates C3‑195033 Update of TS version_Rel-15 Huawei CR Agreement Yes
YesEricsson questioned the reason for change, which was a little confusing. It should include all the relevant CRs which impacted the externalDocs version. Or a generic reason should be offered.
revised No C3‑195333  
    C3‑195333 Update of TS version_Rel-15 Huawei CR Agreement Yes
Yes
revised No C3‑195386 C3‑195033
    C3‑195386 Update of TS version_Rel-15 Huawei CR Agreement Yes
Yes
agreed No   C3‑195333
    C3‑195074 OpenAPI version update of Rel-15 Nudr_DataRepository API Huawei discussion Information Yes
YesIt was noted that there was an additional CR which should be included in the document.
revised No C3‑195334  
    C3‑195334 OpenAPI version update of Rel-15 Nudr_DataRepository API Huawei discussion Information Yes
Yes
noted No   C3‑195074
    C3‑195335 Update of OpenAPI version and TS version in externalDocs Huawei CR Agreement Yes
Yes
revised No C3‑195414  
    C3‑195414 Update of OpenAPI version and TS version in externalDocs Huawei CR Agreement Yes
Yes
revised No C3‑195424 C3‑195335
    C3‑195424 Update of OpenAPI version and TS version in externalDocs Huawei CR Agreement Yes
Yes
agreed No   C3‑195414
    C3‑195336 Update of OpenAPI version and TS version in externalDocs Ericsson CR Agreement Yes
Yes
agreed No    
    C3‑195337 Update of OpenAPI version and TS version in externalDocs Huawei CR discussion Yes
YesIt was believed that there were no other CRs iwhich updated the API.
revised No C3‑195413  
    C3‑195413 Update of OpenAPI version and TS version in externalDocs Huawei CR discussion Yes
Yes
agreed No   C3‑195337
    C3‑195359 Update of API version and TS version in OpenAPI file Nokia, Nokia Shanghai Bell CR Agreement Yes
Yes
agreed No    
    C3‑195362 Update of API version and TS version in OpenAPI file Huawei CR Agreement Yes
YesThe work item code was wrong.
revised No C3‑195412  
Agenda Topic TDoc Title Source Type For Avail Treated Decision Wdrn Repl-by Replaces
    C3‑195412 Update of API version and TS version in OpenAPI file Huawei CR Agreement Yes
Yes
agreed No   C3‑195362
16 Release 16                      
16.1 Rel-16 Work Items                      
16.1.1 New or revised Work Items C3‑195031 CT aspects of Cellular IoT support and evolution for the 5G System QUALCOMM Europe Inc. - Italy WID revised   Yes
Yes
revised No C3‑195372  
    C3‑195372 CT aspects of Cellular IoT support and evolution for the 5G System QUALCOMM Europe Inc. - Italy WID revised - Yes
YesAn off line comment had been received from CT4.
revised No C3‑195400 C3‑195031
    C3‑195400 CT aspects of Cellular IoT support and evolution for the 5G System QUALCOMM Europe Inc. - Italy WID revised - Yes
Yes
endorsed No   C3‑195372
    C3‑195040 Discussion for 5G_SRVCC WID update China Unicom, ZTE discussion Information Yes
YesZTE presented the document. Huawei had some reservations on the clarity of stage 2, but agreed that CT3 work would be needed after clarification of the stage 2.
noted No    
    C3‑195041 Revised WID on CT aspect of single radio voice continuity from 5GS to 3G China Unicom, ZTE WID revised Approval Yes
YesZTE presented the update in detail. The Chairman hoped that the text was sufficiently flexible. Ericsson noted there was no specified impact for 29.514, and doubted there was any impact on 29.571.
revised No C3‑195223 CP‑191062
    C3‑195223 Revised WID on CT aspect of single radio voice continuity from 5GS to 3G China Unicom, ZTE WID revised Approval Yes
YesIt was necessary to include the Rx impacts.
revised No C3‑195415 C3‑195041
    C3‑195415 Revised WID on CT aspect of single radio voice continuity from 5GS to 3G China Unicom, ZTE WID revised Approval Yes
YesIt was reported that the document had not been discussed in CT4.
endorsed No   C3‑195223
    C3‑195071 Revised WID on CT aspects on wireless and wireline convergence for the 5G system architecture Huawei, HiSilicon /Christian WID revised Endorsement Yes
YesHuawei indicated the updates, which did not impact CT3.
revised No C3‑195387 CP‑192079
    C3‑195387 Revised WID on CT aspects on wireless and wireline convergence for the 5G system architecture Huawei, HiSilicon /Christian WID revised Endorsement Yes
Yes
endorsed No   C3‑195071
16.1.2 Contributions on Work Items C3‑195042 Indication of PS to CS Handover for 5G SRVCC from SMF to PCF ZTE CR Approval Yes
YesZTE noted that discussion in CT4 would have an impact on CT3 treatment of this topic. Huawei remarked that SA2 work was still under weigh on the topic. Vodafone wondered whether the ps2CsHoIndication could be an enumerated type rather than boolean. It was noted that there was an embedded comment on ranNsasRelCauses. Vodafone proposed some improved wording for the first change. It would be useful to provide more detail, referring to the message flows shown in the figure above. Ericsson also thought the text was not optimal. Samsung agreed.
revised No C3‑195288  
    C3‑195288 Indication of PS to CS Handover for 5G SRVCC from SMF to PCF ZTE, Ericsson CR Approval Yes
YesThe type of ps2CsHoIndication had been changed to emumerated. Other commentrs received off line had also been incorporated.
revised No C3‑195401 C3‑195042
    C3‑195401 Indication of PS to CS Handover for 5G SRVCC from SMF to PCF ZTE, Ericsson CR Approval Yes
YesA minor editorial was detected. A clarifying internal reference could usefully be added.
revised No C3‑195409 C3‑195288
    C3‑195409 Indication of PS to CS Handover for 5G SRVCC from SMF to PCF ZTE, Ericsson CR Approval Yes
Yes
agreed No   C3‑195401
    C3‑195043 Indication of PS to CS Handover for 5G SRVCC from PCF to AF ZTE CR Approval Yes
Yes
revised No C3‑195221  
    C3‑195221 Indication of PS to CS Handover for 5G SRVCC from PCF to AF ZTE CR Approval Yes
YesSome off line comments had been provided to the author.
revised No C3‑195289 C3‑195043
    C3‑195289 Indication of PS to CS Handover for 5G SRVCC from PCF to AF ZTE CR Approval Yes
Yes
revised No C3‑195394 C3‑195221
    C3‑195394 Indication of PS to CS Handover for 5G SRVCC from PCF to AF ZTE CR Approval Yes
YesHuawei believed it was necessary to add a condition. ZTE had made a reference to cover this. Nevertheless some improvement of the text could be envisaged.
revised No C3‑195410 C3‑195289
Agenda Topic TDoc Title Source Type For Avail Treated Decision Wdrn Repl-by Replaces
    C3‑195410 Indication of PS to CS Handover for 5G SRVCC from PCF to AF ZTE CR Approval Yes
Yes
agreed No   C3‑195394
16.2 Multi-device and multi-identity [MuD] C3‑195059 Additional-Identity header in REFER request Ericsson CR Agreement Yes
Yes
agreed No    
16.3 IMS Stage-3 IETF Protocol Alignment [IMSProtoc16]                      
16.4 Enhancement of 5G PCC related services [en5GPccSer] C3‑195062 Usage of BdtReferenceId data type Ericsson CR Agreement Yes
Yes
agreed No    
    C3‑195063 Removal of non-breaking spaces, TABs and $ref descriptions Ericsson CR Agreement Yes
Yes
agreed No    
    C3‑195064 Removal of TABs from OpenAPI file Ericsson CR Agreement Yes
Yes
agreed No    
    C3‑195096 AMF change in the HR scenario Huawei CR Approval Yes
YesEricsson had some concerns with the logic of the CR. Why did this information have to be in the TS? The new text was not a requirement. The new text could be a note instead of main body text. Huawei remarked that this was in the stage 2.
revised No C3‑195284  
    C3‑195284 AMF change in the HR scenario Huawei CR Approval Yes
Yes
agreed No   C3‑195096
    C3‑195098 Same PCF selection for the same UE ID, S-NSSAI and DNN combination Huawei CR Approval Yes
YesSamsung had doubts over how the changes had been implemented in this CR. The solution should be with the PCF database. The Huawei proposal was too restrictive. Ericsson asked for clarification of the Samsung proposal. Would it not be easier to use a query parameter? But maybe this would make implementation more complex. China Mobile thought there would be many possible combinations with the Huawei proposal. The choice of PCF was not clear. Huawei indicating that the CR offered a solution for a fairly limited scenario. A lengthy discussion ensued. Ericssonn was concerned about the use of error code 409. This was a mechanism for controlling updates. But here it was impacting the creation of the resource, so a 303 error was to be preferred. A few typos were also identified.
revised No C3‑195285  
    C3‑195285 Same PCF selection for the same UE ID, S-NSSAI and DNN combination Huawei CR Approval Yes
YesZTE asked for the data type in 5.6.2.y. Ericsson said there was a typo. The new data type was the result of the combination of the other two types. The status code should have been 403. Some editorial improvements were identified. Oracle asked for clarification of clause 5.6.2.y concerning data types and attributes.
revised No C3‑195389 C3‑195098
    C3‑195389 Same PCF selection for the same UE ID, S-NSSAI and DNN combination Huawei CR Approval Yes
YesIt was clarified that at least one of the atributes in table 5.6.2.x-1 had to be present (and hence the note). Ericsson said the same applied to other tables, but no note appeared. But the note would have to be reworded if more attributes were added at a later date.
revised No C3‑195404 C3‑195285
    C3‑195404 Same PCF selection for the same UE ID, S-NSSAI and DNN combination Huawei CR Approval Yes
Yes
agreed No   C3‑195389
    C3‑195097 Same PCF selection for the same UE ID, S-NSSAI and DNN combination Huawei CR Approval Yes
YesSome of the same remarks applied to this CR as applied to the previous one. Ericsson wondered how the PCF could know all the parameters. First, did enough information exist to create the resource, and if the resource already existed (303 error), the PCF would have to request the parameter values for the binding. Huawei indicated that the scenario was described in the previous CR, in the table note. Ericsson were not convinced. Some typos were found.
revised No C3‑195286  
    C3‑195286 Same PCF selection for the same UE ID, S-NSSAI and DNN combination Huawei CR Approval Yes
YesEricsson was worried that excluding this flexibility, 29.521 would not be used. Huaway responded that the latter spec was for the future. Ericsson wished for more precision in the new text in 4.2.2.2. ZTE noted that this CR had a dependency on a CR which was not already decided. Oracle was concerned about the feature list for the N7 interface. What would be the reaction to a 308 error? An extended discussion with Oracle, Huawei and Ericsson ensued. An explanatory note would be added.
revised No C3‑195388 C3‑195097
    C3‑195388 Same PCF selection for the same UE ID, S-NSSAI and DNN combination Huawei CR Approval Yes
Yes
agreed No   C3‑195286
    C3‑195123 Correct the redirection server address to support dual stack UE Ericsson CR   Yes
NoVodafone questioned the backward compatibility. In Rel-15 it was posible to send multiple element, but now in Rel-16 only one would be possible. Ericsson explained the scenario, and this was one example justifying moving to a v2 of the API.
not concluded No    
    C3‑195304 Request of SM Policy Association Termination during the Update procedure Oracle Corporation CR - Yes
YesThe CR was originally a mirror treated under agenda item 15.2.4. But it was decided not persue the Rel-15 version. The Chairman noted that the release cause value in a CR at CT3#106 needed to be included. In fact, this had been revised by a Huawei CR to the present meeting. Ericsson identified a few typographical errors. Uawei requested the new bullet with that of the new clause. And the Release cause was an attribute rather than a parameter.
revised No C3‑195375 C3‑195077
    C3‑195375 Request of SM Policy Association Termination during the Update procedure Oracle Corporation CR - Yes
Yes
agreed No   C3‑195304
    C3‑195188 Subscription and notification to data changes related to a subset of resource data, Policy Data set Ericsson CR Agreement Yes
YesHuawei wondered if a simpler solution might be envisaged. Ericsson stated that this field was needed to identify the resource.
postponed No    
    C3‑195216 Serving 4G only UEs by SMF+PGW-C Vodafone Romania S.A. CR Agreement Yes
YesVodafone expressed some concern that "larger" decimal numbers greater than 15 might not be supported in the Session Id. This needed to be checked independently. The Chairman noted that the CR revision history had not been used. The original "reason for change" ought to have been retained. There was some concern over Vodafone revising a Huawei CR. But Huawei seemed to be happy with this.
revised No C3‑195287 C3‑194425
Agenda Topic TDoc Title Source Type For Avail Treated Decision Wdrn Repl-by Replaces
    C3‑195287 Serving 4G only UEs by SMF+PGW-C Huawei, Vodafone Romania S.A. CR Agreement Yes
YesThe document was now aligned with stage 2.
agreed No   C3‑195216
    C3‑195052 MCS Priority Level FirstNet CR Agreement Yes
YesFirstnet had queried whether it would be good to combine all MC services and MM priority into one place, but there had been little reaction. The Chairman wondered whether there was any SA2 dependency. The Work item should have been en5GPccSer (the cover showed 5GS_Ph1-CT). References to clauses needed correcting. The Chairman asked could a non-MCS service be a MM Priority service? The spec as structured as if these two types were mutually exclusive. Firstnet agreed to clarify this by removing the offending sentence.
revised No C3‑195339  
    C3‑195339 MCS Priority Level FirstNet CR Agreement Yes
Yes
agreed No   C3‑195052
    C3‑195053 MCS Priority Level FirstNet CR Agreement Yes
YesIt was proposed to remove 7.3.2 in this TS.
revised No C3‑195340  
    C3‑195340 MCS Priority Level FirstNet CR Agreement Yes
Yes
agreed No   C3‑195053
    C3‑195054 MCS Priority Level FirstNet CR Agreement Yes
YesAs above, the text was based upoon that for MPS. An error in table 5.6.2.3-1 was detected.
revised No C3‑195341  
    C3‑195341 MCS Priority Level FirstNet CR Agreement Yes
Yes
revised No C3‑195369 C3‑195054
    C3‑195369 MCS Priority Level FirstNet CR Agreement Yes
Yes
agreed No   C3‑195341
    C3‑195055 MCS Priority Level FirstNet CR Agreement Yes
YesEricsson believed this was pure IMS signalling which did not apply for MCS. FirstNet believed 29.512 should be changed to align with this.
revised No C3‑195342  
    C3‑195342 MCS Priority Level FirstNet CR Agreement Yes
Yes
revised No C3‑195370 C3‑195055
    C3‑195370 MCS Priority Level FirstNet CR Agreement Yes
Yes
agreed No   C3‑195342
    C3‑195210 Add reference to TS 29.524 Orange CR Agreement Yes
YesThe work item code was wrong. Huawei did not think that the new note 3 was applicable to the overlapping case. Orange considered it unnecessary to add a note where it did not apply. Ericsson believed a CR to 29.524 to include the related value, since it was not already included there. This was under the responsiblilty of CT4, and maybe CT3 should send an LS requesting this inclusion. Pro tem, maybe an editor's note would be required. At present, there was no Rel-16 version of 29.524.
revised No C3‑195331  
    C3‑195331 Add reference to TS 29.524 Orange CR Agreement Yes
Yes
agreed No   C3‑195210
    C3‑195332 LS out on missing cause code mapping CT3 LS out Approval Yes
YesThe LS had been drafted by Orange.
revised No C3‑195374  
    C3‑195374 LS out on missing cause code mapping CT3 LS out Approval Yes
Yes
approved No   C3‑195332
16.5 CT aspects on Enablers for Network Automation for 5G [eNA] C3‑195016 Work plan for eNA Huawei Work Plan   Yes
YesThe Chairman asked Huawei how much work was outstanding. Ericsson questioned issue 18, noting that there was still outstanding SA2 work, and that 95% complete was over optimistic.Ericsson wished to be associated with line 18, as well as Huawei and China Mobile. However, no further update to the document was needed for the present meeting.
noted No    
    C3‑195017 Enhance the Nnwdaf_EventsSubscription service to support User Data Congestion Huawei CR   Yes
YesHuawei indicated that this was a revision of C3-194440. Ericsson wished a minor clarification in 5.3.6.1.X. A number of typos were identified. Ericsson wondered whether the new values were catered for by the corresponding API, possibly that in document C3-195022.
revised No C3‑195225 C3‑194440
    C3‑195225 Enhance the Nnwdaf_EventsSubscription service to support User Data Congestion Huawei CR - Yes
Yes
agreed No   C3‑195017
    C3‑195018 AnalyticsEventNotif and AnalyticsExposureSubsc Data Types Huawei CR   Yes
Yes
agreed No   C3‑194442
    C3‑195019 Inclusion of QoS requirements and thresholds for QoS sustainability Huawei CR   Yes
YesA lower case 'a' had been substituted for upper case 'A'.
agreed No   C3‑194461
Agenda Topic TDoc Title Source Type For Avail Treated Decision Wdrn Repl-by Replaces
    C3‑195021 OpenAPI file for AnalyticsExposure API Huawei CR   Yes
Yes
agreed No    
    C3‑195022 OpenAPI file Update for Nnwdaf_EventsSubscription API Huawei CR   Yes
YesEricsson believed there were other CRs which had an impact on the OpenAPI.
revised No C3‑195237  
    C3‑195237 OpenAPI file Update for Nnwdaf_EventsSubscription API Huawei CR - Yes
Yes
agreed No   C3‑195022
    C3‑195023 OpenAPI file Update for Nnwdaf_AnalyticsInfo API Huawei CR   Yes
YesThe Chairman asked whether any other CRs impacted this new text. Answer came there none.
agreed No    
    C3‑195024 Slice identification for all analytics types Huawei CR   Yes
YesThe second change was unclear.
revised No C3‑195363  
    C3‑195363 Slice identification for all analytics types Huawei CR - Yes
Yes
agreed No   C3‑195024
    C3‑195026 Corrections on Naf_EventExposure Service Huawei pCR   Yes
YesThe Chairman noted that the wrong template had been used.
revised No C3‑195226  
    C3‑195226 Corrections on Naf_EventExposure Service Huawei pCR - Yes
Yes
agreed No   C3‑195026
    C3‑195032 OpenAPI file Update for Naf_EventExposure API Huawei pCR   Yes
YesEricsson believed it was in incorrect version, reflecting the next versuib (0.5.0).
revised No C3‑195238  
    C3‑195238 OpenAPI file Update for Naf_EventExposure API Huawei pCR - Yes
Yes
approved No   C3‑195032
    C3‑195065 BDT renegotiation upon the network conditions change Ericsson CR Agreement Yes
YesIt was noted that some email comments had been made on this CR by Huawei, and it had been proposed to postpone the document until the next time. SA2 TSs would have been updated by the next meeting. China Mobile had some concerns with the third change, where three mandatory atributes were mentioned, and it was wondered whether this was also really the case for updates. Ericsson responded that this was indeed the case, and the logic of the CR was correct. Ericsson insisted that if the parameters had originally been included, then the same attributes needed to be included in any update. The Secretary pointed out "can" in the two notes.
postponed No    
    C3‑195066 Modification of "IndividualBdtData" resource Ericsson CR Agreement Yes
YesHuawei had supplied comments by email, and Ericsson agreed with them. ZTE also proposed some modifications to tables 5.2.9.3.2-2 and -3, and asked for alignment with the previoius agreements. This needed further investigation.
revised No C3‑195227  
    C3‑195227 Modification of "IndividualBdtData" resource Ericsson CR Agreement No
YesEricssion wished to pospone treatment until SA2 input had been received.
postponed No   C3‑195066
    C3‑195067 BDT renegotiation upon the network conditions change Ericsson CR Agreement Yes
YesHuawei had provided comments on this CR via email, indicating that a revision of the figure was required, to include UDR. ZTE proposed a reording of some of the steps 13 & 14 or removing them to the XBDT procedures. Ericsson believed that the changes shown were in line with the stage 2. ZTE believed that there was a typo in note 2. Ericsson agreed. There was also a question of alignment with the stage 2 in the case of multiple PCFs: was the procedure optional or mandatory in steps 5-6?
revised No C3‑195228  
    C3‑195228 BDT renegotiation upon the network conditions change Ericsson CR Agreement No
YesEricssion wished to pospone treatment until SA2 input had been received.
postponed No   C3‑195067
    C3‑195068 Definition of EventsSubs in OpenAPI Ericsson pCR Agreement Yes
Yes
approved No    
    C3‑195131 Pseudo-CR on Clarify target UE identity Ericsson pCR   Yes
YesHuawei had provided some remarks by email.
revised No C3‑195229  
    C3‑195229 Pseudo-CR on Clarify target UE identity Ericsson pCR - No
Yes
not pursued No   C3‑195131
    C3‑195132 Internal Group id in notification Ericsson CR   Yes
YesHuawei had provided comments by emial.
revised No C3‑195230  
    C3‑195230 Internal Group id in notification Ericsson CR - No
Yes
not pursued No   C3‑195132
Agenda Topic TDoc Title Source Type For Avail Treated Decision Wdrn Repl-by Replaces
    C3‑195133 Support updated BDT policy in notification Ericsson CR   Yes
YesHuawei had observed offlien that the API was missing. Nokia quiestioned the nature of the change regarding applicability, and Ericsson clarified the intent.
revised No C3‑195231  
    C3‑195231 openAPI correction for ExNotification Ericsson CR - Yes
Yes
agreed No   C3‑195133
    C3‑195134 Support updated BDT policy in notification Ericsson CR   Yes
YesHuawei had provided comments by email with which Erocsson agreed.
revised No C3‑195232  
    C3‑195232 openAPI correction for ExNotification Ericsson CR - Yes
Yes
agreed No   C3‑195134
    C3‑195196 NF Load analytics generalities Orange CR Agreement Yes
YesEricsson was concerned that the newly added text in 4.2.2.2 could be simplified. Also bullet 3 should have no condidtion, so some restructuring was needed. Orange was concerned that such a modification would result in too many notifications. Ericsson had checked the stage 2, which might be ambiguous in this respect. Huawei had also provided email comments on this CR. The Chairman noted that some elements were conditional, but the conditions had not been supplied.
revised No C3‑195233  
    C3‑195233 NF Load analytics generalities Orange CR Agreement Yes
YesThe new data types had been made optional. Ericsson assumed that the output would be an array with each element pertaining to a node instance.
revised No C3‑195376 C3‑195196
    C3‑195376 NF Load analytics generalities Orange CR Agreement Yes
Yes
agreed No   C3‑195233
    C3‑195197 Event Subscribe China Mobile Communications Group Co.,Ltd. , Huawei pCR Agreement Yes
YesEricson noted surplus leading and a number of other typos. SO Else also wished to see a change to clause 4.2.2.2.2.
revised No C3‑195234  
    C3‑195234 Event Subscribe China Mobile Communications Group Co.,Ltd. , Huawei pCR Agreement Yes
Yes
agreed No   C3‑195197
    C3‑195198 Support of Abnormal behaviour China Mobile Communications Group Co.,Ltd. , Huawei pCR Agreement Yes
YesEricsson note that the styles were confusing in the bulleted list in the procedures. An additional change in supported feature was needed. Ericsson also questioned the name of the feature abnormal behaviour, but it seemed there was a precedent for that term.
revised No C3‑195235  
    C3‑195235 Support of Abnormal behaviour China Mobile Communications Group Co.,Ltd. , Huawei pCR Agreement Yes
Yes
agreed No   C3‑195198
    C3‑195199 Patch Report to Nudr_DataRepository API for Policy data China Mobile Communications Group Co.,Ltd. , Huawei pCR Agreement No
Yes
withdrawn Yes    
    C3‑195202 Support of UE communication China Mobile Communications Group Co.,Ltd. , Huawei pCR Agreement Yes
YesEricsson proposed to add an internal group id, but China Mobile was not convinced. A correction to the leading was required.
revised No C3‑195236  
    C3‑195236 Support of UE communication China Mobile Communications Group Co.,Ltd. , Huawei pCR Agreement Yes
Yes
agreed No   C3‑195202
    C3‑195364 Presentation sheet for 29.517 Huawei TS or TR cover Agreement No
No
reserved No    
    C3‑195310 Draft TS 29.517 v0.5.0 Rapporteur (Yali Yan) draft TS Agreement No
NoThe new version would be provided after the end of the meeting.
not concluded No    
    C3‑195352 TS 29.517 v0.5.0 Huawei draft TS Agreement No
YesDuplicate of C3-195310 - withdrawn
withdrawn Yes    
    C3‑195353 TS 29.591 v0.3.0 Huawei draft TS Agreement No
NoThe new version would be provided after the end of the meeting.
not concluded No    
16.6 CT aspects on eSBA [5G_eSBA] C3‑195222 SMF callback URI update Huawei CR Agreement Yes
YesEricsson questioned the use case for this change. Huawei gave a lengthy justification. The WI code was wronglly rendered on the cover sheet.
postponed No    
16.7 CT aspects of Access Traffic Steering, Switch and Splitting support in 5G system [ATSSS]                      
Agenda Topic TDoc Title Source Type For Avail Treated Decision Wdrn Repl-by Replaces
16.8 CT aspects of 5GS enhanced support of vertical and LAN services [Vertical_LAN] C3‑195025 Corrections on 5GLANParameterProvision API Huawei CR   Yes
YesThe CR was essentially editorial.
revised No C3‑195257  
    C3‑195257 Corrections on 5GLANParameterProvision API Huawei CR - Yes
Yes
agreed No   C3‑195025
    C3‑195027 Transport of TSN information and containers between SMF and PCF Nokia, Nokia Shanghai Bell CR Agreement Yes
YesNokia noted that the stage 2 had already gone some way to allowing some of the (new) FFS items to be resolved. There were ongoing discussions on attributes, port types, etc, but so far there was no stage 2 agreement (TS 23.501). This CR did not make any change to the OpenAPI. Ericsson believed that 4.2.3.1 the bullet list coud be corrected to align with the clause title. Similarly in 4.2.3.tsn1, the term UE-DS-TT MAC was inappropriate. In 4.2.4.1, the new text could be clarified. What needed to be described was what the calling network was reporting the port capabilities, so better text would be Reporting of TSN information. This applied also to the title of 4.2.4.tsn2. Also, in this clause, further development was needed in the second paragraph. Further, in 5.6.1, second table, the byte type was to be prefered to binary. In 5.6.2.3, the change was unnecessary. But if it were retained, the Editor's note should be removed. In 5.6.2.4, the embedded comment should be removed, as should the line tsnBridgeInfo. (Nokia did not agree with this last aspect, but would check it.) And again, the byte data type was preferable to binary, and the same ff. There was a well-known type for MAC address, which should be used throughout. The type for dstResidence should be integer rather than binary. (Nokia believed there was a divergence in encoding specifications in different TSs.) Continuing, Ericsson did not think that all the attributes defined as mandatory were in fact mandatory. Reference needed to be taken to the stage 2 (which was not yet complete). The editor's note needed to be adjusted accordingly. The bane TSN_MANETHER_PORT could be changed. In 5.8, the TSN feature terminilogy was not aligned. Huawei questioned the definition of the term TSN: network or networking? It was questioned whether a special procedure existed for service creation, this was not covered in the CR - see 5.6.2.3. Also 5.6.2.4 needed revision to put the information in the PCC rule. In 4.2.3.tsn1 there needed to be a clear description how the forwarding of this information should be done. The table in 5.6.1 needed to include the new parameter.
revised No C3‑195258  
    C3‑195258 Transport of TSN information and containers between SMF and PCF Nokia, Nokia Shanghai Bell, Verizon, Ericsson CR Agreement Yes
YesThe procedure descriptions had been improved. The terminilogy had been aligned with stage 2. The "binary" types had been corrected. Clause 5.6.2.3 had been removed. There were a number of typographical corrections. Vodafone questioned the meeaning of an editor's note. Nokia replied that this related to the configuration of the TSN: a number of PDU sessions were allocated and several UE DS-TTs were possible. Ericsson proposed to remove this in the table, where only one PDU was allowed. Huawei reported an inconsistent feature name in 5.6.3.6. And in 4.2.3.tsn1, more detail was needed. Also in 4.2.4.tsn1.
revised No C3‑195377 C3‑195027
    C3‑195377 Transport of TSN information and containers between SMF and PCF Nokia, Nokia Shanghai Bell, Verizon, Ericsson CR Agreement Yes
YesThe change was in 4.2.3 and in 5.6.3.6. Some points had been removed in the TSN bridge info.
agreed No   C3‑195258
    C3‑195028 Transport of TSC assistance information between SMF and PCF Nokia, Nokia Shanghai Bell CR Agreement Yes
YesEricsson wanted to know where the mapping was done. An FFS note was needed pending the finalization of the stage 2. The clause should go to 29.544. Huawai believed a change was needed to the PCC rule. The data type and the procedure needed to be defined.
revised No C3‑195259  
    C3‑195259 Transport of TSC assistance information between SMF and PCF Nokia, Nokia Shanghai Bell, Verizon, Ericsson CR Agreement Yes
YesClause 4.2.3.1 had been included, and the procedures improved. Huawei wished for the clause title and bullet text to be aligned.
revised No C3‑195378 C3‑195028
    C3‑195378 Transport of TSC assistance information between SMF and PCF Nokia, Nokia Shanghai Bell, Verizon, Ericsson CR Agreement Yes
Yes
agreed No   C3‑195259
    C3‑195029 Transport of TSN information and containers between PCF and AF Nokia, Nokia Shanghai Bell CR Agreement Yes
YesEricsson wanted a more specific description of the topic in 4.2.2.1: provisioning of port management information. In 4.2.2.tsn2, the title needed to be corrected. And some wording changes were needed, including deletion of the third paragraph. In 4.2.3.tsn3, the title needed to be corrected, and similar comments applied to those above. The title of 4.2.5.tsn1 could be improved to Notification about TSG port detection. The Note should be replaced by an editor's note. The existing editor's note could be improved to be less specific, aligned with the previous .tsn3 clause. Nokia observed that this was a stage 2 dependency. Sundry other improvements were suggested by Ericsson. Ericsson noted that the style of the description was not correct, and in 5.6.3.7 there was a typo. Huawei had some remarks on 4.2.5.tsn1, but perhaps this concern had been covered by Ericsson's remarks. Ericsson thought that the procedure implied further notification when the context was established, and this was FFS.
revised No C3‑195296  
    C3‑195296 Transport of TSN information and containers between PCF and AF Nokia, Nokia S|hanghai Bell, Verizon, Ericsson CR Agreement Yes
YesHuawei wished titles and bullets to be aligned. And in 4.2.2.tsn2 wanted to remove the reference to AppSessionContext. But Ericsson believed it to be already correct.
revised No C3‑195379 C3‑195029
    C3‑195379 Transport of TSN information and containers between PCF and AF Nokia, Nokia S|hanghai Bell, Verizon, Ericsson CR Agreement Yes
Yes
agreed No   C3‑195296
    C3‑195030 Transport of TSC assistance information between PCF and AF Nokia, Nokia Shanghai Bell CR Agreement Yes
YesSome off-line comments had been offered by Ericsson. TsnQoSContainer should be defined elsewhere. Huawei wished to see definitions of the procedures. Ericsson wished a more rigorous treatment of the FFS aspect, including a modification to the cover sheet. Vodafone wondered what was the difference between TSC and TSN. Nokia could not explain it, but the difference came from stage 2, possibly relating to QoS aspects.
revised No C3‑195297  
    C3‑195297 Transport of TSC assistance information between PCF and AF Nokia, Nokia Shanghai Bell, Verizon, Ericsson CR Agreement Yes
Yes
agreed No   C3‑195030
16.9 CT aspects of Enhancing Topology of SMF and UPF in 5G Networks [ETSUN]                      
16.10 CT aspects of System enhancements for Provision of Access to Restricted Local Operator Services by Unauthenticated Ues [PARLOS]                      
16.11 CT aspects on enhancement of network slicing [eNS]                      
16.12 CT aspects of Enhancement to the 5GC LoCation Services [5G_eLCS]                      
16.13 CT Aspects of Media Handling for RAN Delay Budget Reporting in MTSI [E2E_DELAY]                      
16.14 Cellular IoT support and evolution for the 5G System [5G_CIoT] C3‑195112 5G CIoT work plan for CT3 QUALCOMM Europe Inc. - Italy WI status report   Yes
YesThe Chairman was concerned what might be the impact on the WI on some CT3 specs which had as yet not been modified under this WI. The work would be completed at the next meeting.
noted No    
    C3‑195120 Pseudo-CR on Clarify NEF southbound services Ericsson pCR   Yes
Yes
revised No C3‑195274  
Agenda Topic TDoc Title Source Type For Avail Treated Decision Wdrn Repl-by Replaces
    C3‑195274 Pseudo-CR on Clarify NEF southbound services Ericsson pCR - Yes
Yes
agreed No   C3‑195120
    C3‑195130 Support API capability change based on API filter Ericsson CR   Yes
YesOff line comments had been received.
revised No C3‑195275  
    C3‑195275 Support API capability change based on API filter Ericsson CR - Yes
Yes
agreed No   C3‑195130
16.15 CT aspects on wireless and wireline convergence for the 5G system architecture [5WWC] C3‑195015 Partial update of IPTVConfiguration API Huawei CR   Yes
YesEricsson drew attention to the tools available on ETSI Forge. It would be easier to show the complete yaml file in the CR rather than just the changed parts. The Chairman agreed this would be a good approach for the future.
agreed No   C3‑194406
    C3‑195158 Clarification of PEI format, TS 29.525 Ericsson, CableLabs CR Agreement Yes
YesVodafone questioned whether the "may" should be a "shall". Ericsson agreed that a previoius stage 2 meeting had implied this. There was also a rogue "can" and a rogue "is". Huawei believed the API version would also need to be incremented, but Ericsson defended the CR as is. But the OpenAPI would indeed change as a result of other CRs. Cablelabs asked for clarification on the intended changes to be made to the CR. Ericsson explained how the cover sheet and the text would be aligned. This discussion continued for some time.
revised No C3‑195239  
    C3‑195239 Clarification of PEI format, TS 29.525 Ericsson, CableLabs CR Agreement Yes
Yes
agreed No   C3‑195158
    C3‑195159 Wireline location information Ericsson CR Agreement Yes
YesIt was noted that there was a redundant extra file in the zip of this tdoc. The new text was intended to be added at the end of the new text of B.3.2.1 introduced in the previous CR (C3-195158). Cablelabs gave some pointers as to which specs covered wireline access. Vodafone was concerns that some defined terms were missing.It was proposed not to replicate acronyms defined elsewhere, but it was felt that this was not in line with CT3 practice.
revised No C3‑195240  
    C3‑195240 Wireline location information Ericsson CR Agreement Yes
Yes
agreed No   C3‑195159
    C3‑195160 Support of simultaneous registration in multiple accesses Ericsson CR Agreement Yes
YesHuawei wished to see explanations in a prior clause (possibly B.3.4.1), but was persuaded otherwise. It was noted that this CR had to be considered in conunction with 23.316 CR0010. A philosophical discussion ensued on what consitituted a 3GPP access. Nokia believed there was no real problem: either an access was 3GPP or it was not.
revised No C3‑195241  
    C3‑195241 Support of simultaneous registration in multiple accesses Ericsson CR Agreement Yes
Yes
agreed No   C3‑195160
    C3‑195161 Support of S-NSSAI for non-3GPP access Ericsson CR Agreement Yes
YesThe 4th change was an error: there was no change in this clause. (Though a double full-stop was noted.) Huaway questioned that in B.3.2.1 nneded to be corrected, there was no need for the feature "SliceSupport", but Ericsson believed not, but conceded that a wrong feature name (WirelineWirelessConvergence) had been used in table 5.6.2.3-1. The discussion centreed around whether "only non-3GPP access" was a valid scenario. Cablelabs saw a lot of value in slicing for 3GPP and for non-3GPP access, simultaneously, and strongly supported the CR.
revised No C3‑195242  
    C3‑195242 Support of S-NSSAI for non-3GPP access Ericsson CR Agreement Yes
Yes
revised No C3‑195380 C3‑195161
    C3‑195380 Support of S-NSSAI for non-3GPP access Ericsson, CableLabs CR Agreement Yes
Yes
agreed No   C3‑195242
    C3‑195162 Support of 5WWC, Service Area Restrictions Ericsson, CableLabs CR Agreement Yes
YesHuawai observed that the cover page mentioned a CR which was to be addressed this week. Should this not appear as a dependency. The Chairmen considered it was a hindrance to be too formal over this aspect, although it was true to say that the other CR had not in fact yet been agreed, but hopefully would be later on in the present meeting. Ericsson believed that "non-3GPP" acces implied more than just wirreline access. But this CR was clear that the two features would be needed. Vodafone drew attention to change 8. Was "ireline access" synonymous with "5G-CRG access". Ericsson agreed that this needed to be clearer. Also, on change 9, "tracking are" was a wireless concept, what was its relevance for wireline access? Ericsson agreed this was an error.
revised No C3‑195243  
    C3‑195243 Support of 5WWC, Service Area Restrictions Ericsson, CableLabs CR Agreement Yes
YesEricsson considered it might be necessary to align terminology throughout the entire specification. But it was decided not to do so.
agreed No   C3‑195162
    C3‑195163 Clarification of PEI format, 29.507 Ericsson, CableLabs CR Agreement Yes
YesA rogue "can" was spotted in the new text.
revised No C3‑195244  
    C3‑195244 Clarification of PEI format, 29.507 Ericsson, CableLabs CR Agreement Yes
Yes
agreed No   C3‑195163
    C3‑195164 HFC node Id in Location information Ericsson CR Agreement Yes
YesSimilar remarks about terminology surrounding cable / wireline access were aired. Huawei stated that there had been a clash of CRs at the last meeting, but Ericsson reassured the meeting that this had been solved by the removal of the editor's note. However, the other CR had retained the editor's note, but modified its wording. The Chairman understood that when both CRs were implemented, the editor's note would disappear. Huawei proposed to modify their CR to remove the editor's note and thus avoid any possible confusion. The present CR should be implemented by MCC after the other one, thus ensuring that the editor's note will indeed be completely removed.
revised No C3‑195245  
    C3‑195245 HFC node Id in Location information Ericsson CR Agreement Yes
Yes
agreed No   C3‑195164
    C3‑195165 Report of Wireline Location Information Ericsson, CableLabs CR Agreement Yes
YesHuawei made an inaudible intervention. Ericsson agreed that it might be wise to add an editor's note. The Chairman was not very enthusiastic about adding such a note - how and when would it be removed? A further inaudible intervention from Huawei. An editor's note would be added until CT3 had received an anticipated LS from SA2.
revised No C3‑195246  
Agenda Topic TDoc Title Source Type For Avail Treated Decision Wdrn Repl-by Replaces
    C3‑195246 Report of Wireline Location Information Ericsson, CableLabs CR Agreement Yes
YesNo confirmation by SA2 had yet been possible.
agreed No   C3‑195165
    C3‑195166 Support of 5WWC, supported PEI format Ericsson, CableLabs CR Agreement Yes
YesA rogue "can" was spotted. Also, the highlights on the deleted text had to be removed. Huawei had not been able to identify the stage 2 requirements for the second change. CableLabs believed it was useful to define MAC addresses for both accesses, and proposed to retain that text. Finally, what was needed was to define what sort of formats were allowed over N5.
revised No C3‑195247  
    C3‑195247 Support of 5WWC, supported PEI format Ericsson, CableLabs CR Agreement Yes
Yes
agreed No   C3‑195166
    C3‑195167 Support of Trusted non-3GPP accesses Ericsson CR Agreement Yes
YesThe invisible changes were due to the removal of highlight colour. Huawei questioned the removal of the editor's notes Ericsson insisted that in the body of the spec, this was certainly correct. And in the annex clauses, it was also correct because this had been covered in a separate CR. It was clear that the concerns of the editor's notes no longer applied because no encoding was impacted. It was suggested that this should have been indicated in the cover sheet. Vodafone noted some erroneous bullet numbering, which should be fixed.
revised No C3‑195248  
    C3‑195248 Support of Trusted non-3GPP accesses Ericsson CR Agreement Yes
Yes
agreed No   C3‑195167
    C3‑195168 Clarification of PEI format, TS 29.512 Ericsson, CableLabs CR Agreement Yes
YesA further rogue "can" had been spotted. Huawei questioned the receipt of the PEI from the SMF. Off line discussion was needed.
revised No C3‑195249  
    C3‑195249 Clarification of PEI format, TS 29.512 Ericsson, CableLabs CR Agreement Yes
YesA minor typo was identified.
revised No C3‑195381 C3‑195168
    C3‑195381 Clarification of PEI format, TS 29.512 Ericsson, CableLabs CR Agreement Yes
Yes
agreed No   C3‑195249
    C3‑195169 HFC node Id in Location information, TS 29.512 Ericsson CR Agreement Yes
YesThe order of implementation of CRs would be important, ensuring that the first editor's note was indeed removed. Huawei remarked on the editor's note in the third change. No Netloc procedure had yet been defined. There was an inconsistency concerning the Netloc feature over N5 and N7. Huawei believed thie question would be answered at the forthcoming RAN WG meeting in the week following the present meeting. Ericsson stated that CT3 was awaiting clarification from stage 2.
revised No C3‑195250  
    C3‑195250 HFC node Id in Location information, TS 29.512 Ericsson CR Agreement Yes
Yes
agreed No   C3‑195169
16.16 Volume Based Charging Aspects for VoLTE [VBCLTE] C3‑195200 Adding Caller and Callee information China Mobile Communications Group Co.,Ltd. CR Agreement Yes
YesEricsson noted that this CR was not aligned with its naming conventions to the following CR. This one needed to be aligned with that of C3-195201. Ericsson questioned why a new CR number had been created rather than keep the same one that had been used last meeting. China Mobile apologised for this.
revised No C3‑195290  
    C3‑195290 Adding Caller and Callee information China Mobile Communications Group Co.,Ltd. CR Agreement Yes
YesA correction to the cover page was required.
revised No C3‑195390 C3‑195200
    C3‑195390 Adding Caller and Callee information China Mobile Communications Group Co.,Ltd. CR Agreement Yes
Yes
agreed No   C3‑195290
    C3‑195201 Adding Caller and Callee information China Mobile Communications Group Co.,Ltd. CR Agreement Yes
YesA draft revision of this CR had been circulated by email. Ericsson referred to comments from SA5 which were at odds with the first paragraph ew text in A16. CAT was always needed. Moreover, the note could be removed. P-CSCF could not provide more information than was available. The new text had a lot of unnecessary information, it was sufficient to refer to the charging spec (rather than replicate the text anew). Ericsson was also concerned about the changes to 4.4.2. The addition to table 5.4.1.2 needed to be more specific. China Mobile refered to table 5.4.0.1. Was it appropriate to put all calling information in the same place?
revised No C3‑195291  
    C3‑195291 Adding Caller and Callee information China Mobile Communications Group Co.,Ltd. CR Agreement Yes
Yes
revised No C3‑195391 C3‑195201
    C3‑195391 Adding Caller and Callee information China Mobile Communications Group Co.,Ltd. CR Agreement Yes
YesThe Chairman reminded China Mobile that an LS would have to be sent to CT4 concerning the new AVP.
revised No C3‑195438 C3‑195291
    C3‑195438 Adding Caller and Callee information China Mobile Communications Group Co.,Ltd. CR Agreement Yes
YesThe cover page needed updating.
revised No C3‑195442 C3‑195391
    C3‑195442 Adding Caller and Callee information China Mobile Communications Group Co.,Ltd. CR Agreement Yes
YesThe tdoc number had not been updated.
revised No C3‑195445 C3‑195438
    C3‑195445 Adding Caller and Callee information China Mobile Communications Group Co.,Ltd. CR Agreement Yes
Yes
agreed No   C3‑195442
    C3‑195416 LS New AVP in 29.214 CT3 LS out discussion Yes
YesA revision was needed due to the change of the CR from '5391 to 5438.
revised No C3‑195439  
Agenda Topic TDoc Title Source Type For Avail Treated Decision Wdrn Repl-by Replaces
    C3‑195439 LS New AVP in 29.214 CT3 LS out discussion Yes
YesIt was noted that the LS had Rel-15 and Rel-16 impacts, and the LS needed to draw attention to this.
revised No C3‑195440 C3‑195416
    C3‑195440 LS New AVP in 29.214 CT3 LS out discussion Yes
Yes
approved No   C3‑195439
16.17 CT aspects of optimisations on UE radio capability signalling [RACS] C3‑195051 RACS CT work plan Qualcomm Incorporated / Lena discussion Information Yes
YesFrom the CT3 point of view, the onlly remaining item was to remove an editor's note. This would be decided at the next meeting.
noted No    
    C3‑195354 Presentation sheet for TS 29.675 Ericsson TS or TR cover Agreement No
No
reserved No    
    C3‑195355 TS 29.675 v0.3.0 Ericsson draft TS Agreement No
NoThe new version would be provided after the end of the meeting.
not concluded No    
16.18 Service Based Interface Protocol Enhancement [SBIProtoc16] C3‑195189 Feature Negotiation for OperatorSpecificData resource Ericsson CR Agreement Yes
Yes
agreed No    
    C3‑195190 Feature Negotiation for Influence Data resource Ericsson CR Agreement Yes
Yes
agreed No    
16.19 CT aspects of eV2XARC [eV2XARC] C3‑195078 correction to PLMN change trigger ZTE CR Approval Yes
YesHuawei wished to clarify the text relating to multiple triggers, but already there was a CR to introduce more triggers. Ericsson noted a wrong stye right at the end of the CR.
revised No C3‑195299  
    C3‑195299 correction to PLMN change trigger ZTE CR Approval Yes
Yes
agreed No   C3‑195078
    C3‑195094 QoS Handling for V2X Communication Huawei CR Approval Yes
YesEricsson questioned the "reason for change" but the actual changes in 4.2.3.x did not reflect this. The text was not aligned with the table. The feature name was not rendered consistently. Other typographical improvements were identified.
revised No C3‑195300 C3‑194468
    C3‑195300 QoS Handling for V2X Communication Huawei CR Approval Yes
Yes
agreed No   C3‑195094
    C3‑195095 QoS Handling for V2X Communication Huawei CR Approval Yes
YesThe feature name needed to be corrected.
revised No C3‑195301 C3‑194460
    C3‑195301 QoS Handling for V2X Communication Huawei CR Approval Yes
YesEricsson detected a problem of a missing data type.
agreed No C3‑195426 C3‑195095
    C3‑195426 QoS Handling for V2X Communication Huawei CR Approval Yes
Yes
agreed No   C3‑195301
16.20 CT aspects of 5G URLLC [5G_URLLC] C3‑195109 5G_URLLC CT work plan Huawei discussion Information Yes
YesHuawei presented the document, considering that tit might be necessary to raise a LS to SA2. Ericsson also had concerns over whether or not CT3 was impacted - this was not yet clear.
noted No    
    C3‑195224 LS CT3 (Huawei) LS out Approval No
Yes
withdrawn Yes    
    C3‑195069 Definition of AfResultInfo in OpenAPI Ericsson CR Agreement Yes
YesNokia believed this change needed to be done in several specs, but in Rel-16 context it was acceptable.
agreed No    
    C3‑195110 Correction to the QoS monitoring Control Huawei CR Approval Yes
YesNokia wondered if the removal of reporting frequency was also based on stage 2, and Huawei answered that it was. Care needed to be taken with the applicability of table notes. Ericsson proposed an editorial style to a bullet point in 5.6.2.x. Openet proposed an additional correction. Care needed to be taken over unnecessary capitalization of leading letters. Vodafone pointed out that dlDelays was an error. Sundry other editorial matters were noted.
revised No C3‑195298  
    C3‑195298 Correction to the QoS monitoring Control Huawei, Cisco CR Approval Yes
Yes
agreed No   C3‑195110
    C3‑195207 QoS Monitoring for Service Data Flows Ericsson, Cisco CR Agreement Yes
Yes
agreed No   C3‑194430
Agenda Topic TDoc Title Source Type For Avail Treated Decision Wdrn Repl-by Replaces
16.21 Enhancement of 3GPP Northbound APIs [eNAPIs] C3‑195135 Supported feature in API publish service Ericsson CR   Yes
YesSamsung wanted clarification on Supported Features, and Ericsson explained the need for APIs for the feature because of CAPIF. Some comments from Huawei had been offered off line. Why was the description text needed? Off line discussions were received.
revised No C3‑195373  
    C3‑195373 Supported feature in API publish service Ericsson, Huawei CR - Yes
Yes
agreed No   C3‑195135
16.22 CT Aspects of 5GS Transfer of Policies for Background Data [xBDT] C3‑195020 Reference correction to BdtReferenceId Huawei CR   Yes
Yes
agreed No    
    C3‑195070 Retrieval of BDT policy data for a set of BDT reference identifiers Ericsson CR Agreement Yes
Yes
agreed No   C3‑194329
    C3‑195079 store BDT reference ID in SMPolicyData ZTE CR Approval Yes
YesIt needed to be clarified where the procedures took place.
revised No C3‑195251  
    C3‑195251 store BDT reference ID in SMPolicyData ZTE CR Approval Yes
Yes
agreed No   C3‑195079
    C3‑195082 include S-NSSAI and DNN in Application Data for xBDT ZTE CR Approval Yes
YesHuawei queried the format of the API. ZTE agreed.
revised No C3‑195254  
    C3‑195254 include S-NSSAI and DNN in Application Data for xBDT ZTE CR Approval Yes
Yes
agreed No   C3‑195082
    C3‑195083 remove 204 response on PUT request for AppliedBDTPolicyData ZTE CR Approval Yes
Yes
agreed No    
    C3‑195086 misssing ASP id in AF request for xBDT ZTE CR Approval Yes
YesEricsson believed the reference to 29.503 was omcprrect. In addition, Ericsson believed the new aspId was not needed. But this depended on the use of AF id.
revised No C3‑195253  
    C3‑195253 misssing required in ApplyingBdtPolicy API file ZTE CR Approval Yes
Yes
agreed No   C3‑195086
    C3‑195087 remove EN related to BDT reference ID storage in SMPolicyData ZTE CR Approval Yes
YesEricsson wished for some clarification of the first change; if a new policy was negotiated, did the previious state pertain. In short, did step 0 also include re-negotaiation? How many steps needed to be repeated? The Chairman reminded the meeting that the scope of this CR was simply to remove an editor's note! But in fact ZTE was inclined to agree with Ericsson. Ericsson believed a change was missing at step 3/4 (removal of another PUT).
revised No C3‑195255  
    C3‑195255 remove EN related to BDT reference ID storage in SMPolicyData ZTE CR Approval Yes
Yes
agreed No   C3‑195087
    C3‑195093 New cause value of association termination for xBDT Huawei CR Approval Yes
YesHuawei had merged two CRs agreed at meeting #106 (one from Vodafone). The origianal CRs were in C3-194288, C3-194292, and C3-195192. Thus these three CRs would be considered to have status "merged" and would not be forwarded to CT plenary for approval. Vodafone was happy with this treatment. In the first change, an "and" was thought to be missing on the third line, but on analysis this was determined not to be the case. Some improvement to the clarity of the third paragraph in the first change was needed. Further doubtless erudite but completely inaudible remarks were made. ZTE believed that some of the changes referred to features defied elsewhere and were not appropriate in this CR. Off line discussion was needed.
revised No C3‑195256 C3‑194415
    C3‑195256 New cause value of association termination for xBDT Huawei, Vodafone CR Approval Yes
YesThe Oracle CR would need to use the release clause given in this CR. ZTE found the first paragraph of 4.2.6.2.15 to be confusing. This led to a lengthy disussion with Ericsson and Huawei.
revised No C3‑195392 C3‑195093
    C3‑195392 New cause value of association termination for xBDT Huawei, Vodafone CR Approval Yes
Yes
agreed No   C3‑195256
    C3‑195136 URSP provisioning for xBDT Huawei, ZTE CR Agreement Yes
Yes
revised No C3‑195252 C3‑194290
    C3‑195252 URSP provisioning for xBDT Huawei, ZTE CR Agreement Yes
Yes
agreed No   C3‑195136
    C3‑195192 Support of BDT reference Id within Session Management data Ericsson CR Agreement Yes
YesC3-194288, C3-194292, and C3-195192 were merged into C3-195093.
merged No   C3‑194416
16.23 Mobile Communication System for Railways (MONASTERY) [MONASTERY2]                      
Agenda Topic TDoc Title Source Type For Avail Treated Decision Wdrn Repl-by Replaces
16.24 CT aspects of SBA interactions between IMS and 5GC [eIMS5G_SBA] C3‑195203 Correction of AF Charging Identifier data type Ericsson CR Agreement Yes
YesThere were no comments, but a decision was delayed awaiting the v1 / v2 decision..
agreed No    
    C3‑195204 P-CSCF restoration Ericsson CR Agreement Yes
YesHuawei did not think the restoration enhancements operation was needed for Rel-16. Minor editorial improvements and corrections were proposed.
revised No C3‑195308  
    C3‑195308 P-CSCF restoration Ericsson CR Agreement Yes
YesA further typo was discovered.
revised No C3‑195382 C3‑195204
    C3‑195382 P-CSCF restoration Ericsson CR Agreement Yes
Yes
agreed No   C3‑195308
    C3‑195205 Support of Maximum Supported Bandwidth and Minimum Desired Bandwidth Ericsson CR Agreement Yes
Yes
agreed No    
    C3‑195206 Support of the RAN-NAS Release Cause Ericsson CR Agreement Yes
Yes
agreed No   C3‑194277
    C3‑195208 QoS Parameter mapping at AF, N5 interface Ericsson CR Agreement Yes
YesHuawei raised some concerns. Additional comments had been received concerning the reservation priority. Ericsson suggested it would be necessary to have some introductory text to clarify this. Perhaps a annex on multimedia could be introduced. Huawei thought there might be a need for cause mapping. But Ericsson was concerned with mixing SDP and mutimedia. Perhaps this could be sovled with a note. There was an out of date reference to an RFC.
revised No C3‑195405  
    C3‑195405 QoS Parameter mapping at AF, N5 interface Ericsson CR Agreement Yes
YesThis needed to be revised be revised to cater for the clash with a Qualcomm CR.
revised No C3‑195435 C3‑195208
    C3‑195435 QoS Parameter mapping at AF, N5 interface Ericsson, PerspectaLabs, Qualcomm Incorporated CR Agreement Yes
Yes
agreed No   C3‑195405
    C3‑195209 Skeleton for Annex B, Signalling Flows for IMS Ericsson CR Agreement Yes
YesHuawei wished also to include the Rx interactions. A reference to 29.214 was needed. There were other mechanisms than SDP.
revised No C3‑195309  
    C3‑195309 Skeleton for Annex B, Signalling Flows for IMS Ericsson CR Agreement Yes
YesHuawai had a concern about the third change. A clarification was agreed. There was a wrong reference.
revised No C3‑195383 C3‑195209
    C3‑195383 Skeleton for Annex B, Signalling Flows for IMS Ericsson CR Agreement Yes
Yes
revised No C3‑195406 C3‑195309
    C3‑195406 Skeleton for Annex B, Signalling Flows for IMS Ericsson CR Agreement Yes
YesA surplus quotation mark was observed.
revised No C3‑195411 C3‑195383
    C3‑195411 Skeleton for Annex B, Signalling Flows for IMS Ericsson CR Agreement Yes
Yes
agreed No   C3‑195406
16.25 CT aspects of application layer support for V2X services[V2XAPP] C3‑195101 OpenAPI file corrections Huawei pCR Agreement Yes
YesIt was noted that the CAPIF spec did not define all these details. Did this follow the same security regime as for Northbound APIs? Some editorial improvements were identified.
revised No C3‑195320  
    C3‑195320 OpenAPI file corrections Huawei pCR Agreement Yes
Yes
agreed No   C3‑195101
    C3‑195102 Reception Report Huawei pCR Agreement Yes
YesErricson drew attention to an SA6 discussion on this topic contemporaneously with the present CT3 meeting.
agreed No    
    C3‑195103 Resource deletion Huawei pCR Agreement Yes
YesSome editorial improvements were proposed. Ericsson had concerns over the addition to table 6.1.6.2.2-1. This needed to be consistent with the Northbound APIs.
revised No C3‑195321  
    C3‑195321 Resource deletion Huawei pCR Agreement Yes
Yes
agreed No   C3‑195103
    C3‑195104 Supported Features Huawei pCR Agreement Yes
YesIt was questioned what was meant by XXX API.
revised No C3‑195322  
Agenda Topic TDoc Title Source Type For Avail Treated Decision Wdrn Repl-by Replaces
    C3‑195322 Supported Features Huawei pCR Agreement Yes
Yes
agreed No   C3‑195104
    C3‑195105 VAE_V2X_Application_Requirement service Huawei pCR Agreement Yes
YesEricsson proposed a text change in 5.4.2.2.2 to align with stage 2. Ericsson wondered whether the editor's note could be removed, was it possible to apply the same mechanism for deletion as had been used elsewhere? If the note was removed, it would be necessary to define the procedure. Huawei needed to consider this further. In 6.3.3.1, there was no need for the box since it was not a custom operation; alternatively the DELETED operation should be removed. Clause 6.3.6.2.3 had a typo in the title. And it was proposed to change the type to enumeration. The title of 6.3.6.2.4 was not appropriate. Also, instead of the result attribute being a string, there was a well-known type which should be used in stead. Cf the editor's note below the table. Some editorial corrections were proposed.
revised No C3‑195323  
    C3‑195323 VAE_V2X_Application_Requirement service Huawei pCR Agreement Yes
Yes
agreed No   C3‑195105
    C3‑195106 VAE_V2X_Application_Requirement OpenAPI file Huawei pCR Agreement Yes
YesComments relating to ealier CRs were applicable here.
revised No C3‑195324  
    C3‑195324 VAE_V2X_Application_Requirement OpenAPI file Huawei pCR Agreement Yes
YesOne change was missing, and the externalDocs needed updating. There was (at least) onstance of "subclause subclause". The security aspects in the yaml was in the wrong position.
revised No C3‑195395 C3‑195106
    C3‑195395 VAE_V2X_Application_Requirement OpenAPI file Huawei pCR Agreement Yes
Yes
revised No C3‑195407 C3‑195324
    C3‑195407 VAE_V2X_Application_Requirement OpenAPI file Huawei pCR Agreement Yes
Yes
agreed No   C3‑195395
    C3‑195107 VAE_V2X_Dynamic_Group service Huawei pCR Agreement Yes
YesEricsson thought the reason for change was unclear. An editor's note in stage 2 proposed moving this functionality to somewhere else. The SA6 requirement was not stable. Huawei made an inaudible remark. Ericsson responded in like manner. But it seemed that there had been no contributions in SA6. There was scope for bypassing the V2X application server. It was proposed to wait one further meeting. Huawei was not happy with the delay to achieving stability. The Chairman believed it was time to make some assumptions, and inform other parties of those assumptions. An editor's note had been added by an Ericsson delegate (not at the meeting) so Ericsson proposed to postpone the pCR to the next meeting. Huawei was anxious to keep the spec consistent with SA6. It also seems tha there was some divergence from the SA2 status. Ericsson was concerned that time was running short before the Release freeze. SA6 would address this topic in its January 2020 meeting.
postponed No    
    C3‑195108 VAE_V2X_Dynamic_Group OpenAPI file Huawei pCR Agreement Yes
Yes
postponed No    
    C3‑195356 TS 29.486 v0.3.0 Huawei draft TS Agreement No
NoThe new version would be provided after the end of the meeting.
not concluded No    
16.26 xMB extension for mission critical services [MC_XMB-CT]                      
16.27 CT aspects of enhancements for Common API Framework for 3GPP Northbound APIs [eCAPIF] C3‑195137 eCAPIF work plan Samsung Work Plan Discussion Yes
YesSamsung presented the updates since last time. Huawei believed they would provide CRs to the next meeting. Currently, everthing seemed to be on schedule.
noted No    
    C3‑195121 Support query source verification in cascaded CAPIF discovery Ericsson CR   Yes
Yes
revised No C3‑195267  
    C3‑195267 Support query source verification in cascaded CAPIF discovery Ericsson CR - No
Yes
not pursued No   C3‑195121
    C3‑195138 Updates to Service Architecture and functional entities Samsung CR Agreement Yes
YesIt was necessary to add a NOTE describing the situation of CAPIF-7 interface. "PLMN" had to be replaced with "PLMN domain"
revised No C3‑195268 C3‑194358
    C3‑195268 Updates to Service Architecture and functional entities Samsung CR Agreement Yes
YesInconsistent capitalization was identified. A domain ws missing.
revised No C3‑195384 C3‑195138
    C3‑195384 Updates to Service Architecture and functional entities Samsung CR Agreement Yes
Yes
agreed No   C3‑195268
    C3‑195139 API invoker details update Service Definition Samsung CR Agreement Yes
YesA modification to in clause 5.5.2.X.2 was required.
revised No C3‑195269  
    C3‑195269 API invoker details update Service Definition Samsung CR Agreement Yes
Yes
agreed No   C3‑195139
    C3‑195140 API invoker details update API Definition Samsung CR Agreement Yes
YesOffline comments had been received.
revised No C3‑195270  
Agenda Topic TDoc Title Source Type For Avail Treated Decision Wdrn Repl-by Replaces
    C3‑195270 API invoker details update API Definition Samsung CR Agreement Yes
Yes
agreed No   C3‑195140
    C3‑195141 API Provider Registration and Update Service Definition Samsung CR Agreement Yes
Yes
revised No C3‑195271  
    C3‑195271 API Provider Registration and Update Service Definition Samsung CR Agreement Yes
Yes
agreed No   C3‑195141
    C3‑195142 API Provider Registration and Update API Definition Samsung CR Agreement Yes
YesThere was need to modify the wording in clause 8.X.2.2.1, modify the tree in clause 8.X.2.1 and modify the Description in Table 8.X.2.3.3.1-3.
revised No C3‑195272  
    C3‑195272 API Provider Registration and Update API Definition Samsung CR Agreement Yes
Yes(Wrong document uploaded under this number)
revised No C3‑195371 C3‑195142
    C3‑195371 API Provider Registration and Update API Definition Samsung CR Agreement Yes
YesIt was necessary to update "v1" To "{apiVersion1}" throughout. It was noticed en passant that this error existed in other TSs too. Cells needed to be merged in a table.
revised No C3‑195396 C3‑195272
    C3‑195396 API Provider Registration and Update API Definition Samsung CR Agreement Yes
Yes
agreed No   C3‑195371
    C3‑195143 Support for 3rd party API provider domain Samsung CR Agreement Yes
YesA note number needed to be removed, and the clauses affected were missing from the cover sheet.
revised No C3‑195273  
    C3‑195273 Support for 3rd party API provider domain Samsung CR Agreement Yes
Yes
agreed No   C3‑195143
16.28 CT aspects of Service Enabler Architecture Layer for Verticals [SEAL] C3‑195144 SEAL APIs work plan Samsung Work Plan Discussion Yes
YesSamsung presented the status report, and it was noted that there was some dependency on SA6 work. It was believed that the CT3 work could be fininwhed on time.
noted No    
    C3‑195157 Group and Configuration management API and Service operations Samsung pCR Approval Yes
YesEricsson understood that this pCR sought to align with SA6, but SA6 had not yet confirmed their status.
agreed No    
    C3‑195170 Group management Service definition Samsung pCR Approval Yes
YesSamsung noted that no Delete operation had been specified because stage 2 had not called for it. Email discussion was still on-going on this. Also ounder discussion was the separation or not of Create and Management. Ericsson thought separation was best. On examination of the document, it seemed that better alighmnet (and cross referencing) with stage 2 and with another pCR was needed. This needed to be discussed off line. Clause 5.3.2.2.4 was needed because a general description existed elsewhere. Samsung would handle these aspects at the next meeting, though Ericsson would prefer to do it at the present meeting, or alternatively it would be desirable to add an edditor's note to give forewarning of this. Samsung agreed to remove the subclauses. Huawei had concerns over this pCR which needed off line discussion, possibly resulting in editor's notes if no final solution could be arrived at.
revised No C3‑195260  
    C3‑195260 Group management Service definition Samsung pCR Approval Yes
Yes
approved No   C3‑195170
    C3‑195171 Group management API definition Samsung pCR Approval Yes
YesSamsung proposed to treat this pCR similarly to the previous one. Ericsson was happy with this approach. The same Huawei position pertained. The only remaining outstanding issue was the need or not for the Delete operation. Ericsson made comments with respect to Group Id and Group Document Id, Sansung noting that these were very different in nature. Ericsson referred to stage 2, and was concerned by the naming convention used in this TS. There was some confusion over whether the provisions of this document were part of the resource in CT1. Ericsson would like to see a reference to the CT1 definition. Ericsson had further remarks on 7.2.1.4.2.2, and Samsung sought to clarify their intentions.
revised No C3‑195261  
    C3‑195261 Group management API definition Samsung pCR Approval Yes
YesHuawei suggested to add an editor's note to draw attention to the misalignment with SA6 (where the request message was mandatory, whilst here it was optional). In the end, it was decided to align this CR with the SA6 spec. Oracle indicated a typographical correct ion clause 7.2.1.2.1.
agreed No C3‑195441 C3‑195171
    C3‑195441 Group management API definition Samsung pCR Approval Yes
Yes
agreed No   C3‑195261
    C3‑195172 Configuration management Service definition Samsung pCR Approval Yes
YesSamsung noted that there had been off line comments from Huawei on this document. It was important to align with stage 2. Similar comments from Ericsson to those on the previous pCR applied here.
revised No C3‑195262  
    C3‑195262 Configuration management Service definition Samsung pCR Approval Yes
Yes
approved No   C3‑195172
    C3‑195184 Configuration management API definition Samsung pCR Approval Yes
YesAn off line comment had been received from Huawei. Ericsson noted that figures had been removed without revision marks. Samsung appologiesed for this. There was concern over the existence of resources that served no purpose. This was not necessary simply to keep the structure regular. It was not recommended to dispense with containers, having a fixed prefix. Without this there might be difficulty in extending the capability later on. The Chairman drew attention to the way of refering to the API version. It was noted that there was no Create operation, only Get.
revised No C3‑195263  
    C3‑195263 Configuration management API definition Samsung pCR Approval Yes
YesIt was not agreed that 29.549 should be sent to TSG. This was odd because the WI was deemed to be 70% complete. But there was some debate that the completion percentage was rather lower. After some discussion, it was agreed to raise the TS to v1.0.0 and send it to the TSG.
agreed No   C3‑195184
Agenda Topic TDoc Title Source Type For Avail Treated Decision Wdrn Repl-by Replaces
    C3‑195185 Common design aspects - Data types Samsung pCR Approval Yes
Yes
approved No    
    C3‑195186 Using Common API Framework Samsung pCR Approval Yes
YesEricsson noticed an incomplete sentence above Note 2.
revised No C3‑195264  
    C3‑195264 Using Common API Framework Samsung pCR Approval Yes
Yes
approved No   C3‑195186
    C3‑195187 Coversheet for Information Samsung TS or TR cover Approval Yes
YesSamsung believed that the TS was 65% complete. Ericsson would like time to evaluate the degree of completion. Finally, it was decided to send the TS to TSG for information. But the cover sheet needed to identify the outstanding issues.
revised No C3‑195443  
    C3‑195443 Coversheet for Information Samsung TS or TR cover Approval Yes
YesIt was agreed that the TS was 60% complete.
agreed No   C3‑195187
    C3‑195307 Draft TS 29.549 v0.3.0 Rapporteur (Narendranath Durga Tangudu) draft TS Agreement No
NoThe new version would be provided after the end of the meeting.
not concluded No    
16.29 Load and Overload Control of 5GC Service Based Interfaces [LOCL]                      
16.30 Technical Enhancements and Improvements [TEI16]                      
16.30.1 TEI16 for IMS/CS C3‑195014 Interworking of Local Number Format in From Header Field Deutsche Telekom / Michael CR Agreement Yes
YesEricsson drew attention to the terminology in noe 4, which should be aligned with IETF.
revised No C3‑195294  
    C3‑195294 Interworking of Local Number Format in From Header Field Deutsche Telekom / Michael CR Agreement Yes
Yes
agreed No   C3‑195014
    C3‑195088 Correction for setting condition of the contact hedaer field NTT corporation CR   Yes
YesEricsson proposed to correct the reference. It was also proposed to modify the title page.
revised No C3‑195295  
    C3‑195295 Correction for setting condition of the Contact hedaer field NTT corporation CR - No
Yes
not pursued No   C3‑195088
    C3‑195191 Interworking of Local Number Format in Generic Number Deutsche Telekom CR Agreement Yes
Yes
agreed No   C3‑194401
16.30.2 TEI16 for Packet Core C3‑195037 Coverage and Handover Enhancements for Media (CHEM) Qualcomm UK Ltd CR Agreement Yes
YesComments had been received off line about two AVPs.
revised No C3‑195311 C3‑194465
    C3‑195311 Coverage and Handover Enhancements for Media (CHEM) Qualcomm UK Ltd CR Agreement Yes
YesSeveral minor modifications were requested. The AVP clauses had to be removed and a referrence to the relevant spec were needed. A change from "section" to "clause" was needed.
revised No C3‑195402 C3‑195037
    C3‑195402 Coverage and Handover Enhancements for Media (CHEM) Qualcomm UK Ltd CR Agreement Yes
YesSeveral editorial metters were identified.
revised No C3‑195408 C3‑195311
    C3‑195408 Coverage and Handover Enhancements for Media (CHEM) Qualcomm UK Ltd CR Agreement Yes
Yes
agreed No   C3‑195402
    C3‑195038 Coverage and Handover Enhancements for Media (CHEM) Qualcomm UK Ltd CR Agreement Yes
YesErcsson was in favour of the approach.
revised No C3‑195312 C3‑194466
    C3‑195312 Coverage and Handover Enhancements for Media (CHEM) Qualcomm UK Ltd CR Agreement Yes
Yes
revised No C3‑195403 C3‑195038
    C3‑195403 Coverage and Handover Enhancements for Media (CHEM) Qualcomm UK Ltd CR Agreement Yes
YesThere was an editorial correction to be done.
revised No C3‑195437 C3‑195312
Agenda Topic TDoc Title Source Type For Avail Treated Decision Wdrn Repl-by Replaces
    C3‑195437 Coverage and Handover Enhancements for Media (CHEM) Qualcomm UK Ltd CR Agreement Yes
Yes
agreed No   C3‑195403
    C3‑195039 Coverage and Handover Enhancements for Media (CHEM) Qualcomm UK Ltd CR Agreement Yes
YesEricsson noted that in the feature was not restricted to voice communication. The BCF internal logic would have to cope with this. But was this really necessary? The procedural part of the spec was based on local configuration only. This new feature was therefore unnecessary. Qualcomm observed that further changes would be needed to justify the logic.
revised No C3‑195313 C3‑194467
    C3‑195313 Coverage and Handover Enhancements for Media (CHEM) Qualcomm UK Ltd CR Agreement Yes
Yes
agreed No   C3‑195039
    C3‑195044 Coverage and Handover Enhancements for Media (CHEM) Qualcomm India Pvt Ltd CR   Yes
YesThe same diiscussion applied.
revised No C3‑195314  
    C3‑195314 Coverage and Handover Enhancements for Media (CHEM) Qualcomm India Pvt Ltd CR - Yes
YesEricsson identified a problem in the third change. There should be no AVP. Theer were a number of instances. And the type Meida Component was missing.
revised No C3‑195444 C3‑195044
    C3‑195444 Coverage and Handover Enhancements for Media (CHEM) Qualcomm India Pvt Ltd CR - Yes
YesThe names of attributes should have replaced the AVPs.
revised No C3‑195446 C3‑195314
    C3‑195446 Coverage and Handover Enhancements for Media (CHEM) Qualcomm India Pvt Ltd CR - No
No
reserved No   C3‑195444
    C3‑195045 Coverage and Handover Enhancements for Media (CHEM) Qualcomm India Pvt Ltd CR   Yes
YesThe same diiscussion applied. Ericsson drew attention to one of their CRs, and this needed to be coordinated dwith Qualcomm.
revised No C3‑195315  
    C3‑195315 Coverage and Handover Enhancements for Media (CHEM) Qualcomm India Pvt Ltd CR - Yes
YesThis revision created the tables from the original Qualcomm and Ericsson CRs, although there was no collision. This implied a revision of the Ericsson CR. It was necessary to change "can" to "may".
revised No C3‑195434 C3‑195045
    C3‑195434 Coverage and Handover Enhancements for Media (CHEM) Qualcomm India Pvt Ltd CR - Yes
Yes
agreed No   C3‑195315
    C3‑195046 Coverage and Handover Enhancements for Media (CHEM) Qualcomm India Pvt Ltd CR   Yes
YesThe same diiscussion applied.
revised No C3‑195316  
    C3‑195316 Coverage and Handover Enhancements for Media (CHEM) Qualcomm India Pvt Ltd CR - Yes
YesA corrected reference was needed.
revised No C3‑195436 C3‑195046
    C3‑195436 Coverage and Handover Enhancements for Media (CHEM) Qualcomm India Pvt Ltd CR - Yes
Yes
agreed No   C3‑195316
    C3‑195047 Increasing the maximum MDBV value Qualcomm Incorporated / Lena CR Agreement Yes
YesThe CR history box on the cover sheet provided the justification for this new version of the CR.
agreed No   C3‑194285
    C3‑195056 Update to NIDD APIs for RDS Dynamic Port Management Intel CR Agreement Yes
YesQualcomm had received extensive off line comments.
revised No C3‑195317 C3‑193173
    C3‑195317 Update to NIDD APIs for RDS Dynamic Port Management Intel CR Agreement Yes
Yes
revised No C3‑195425 C3‑195056
    C3‑195425 Update to NIDD APIs for RDS Dynamic Port Management Intel CR Agreement Yes
Yes
agreed No   C3‑195317
    C3‑195099 PFD partial failure notification Huawei CR Approval Yes
YesSome editorial improvements were noted. Ericsson proposed to change data structure to data type. The data type which was updated affected the yaml code. There was some doubt over the alignemnt with the table.
revised No C3‑195318 C3‑194374
    C3‑195318 PFD partial failure notification Huawei CR Approval Yes
Yes
agreed No   C3‑195099
    C3‑195100 PFD partial failure notification Huawei CR Approval Yes
YesSimilar considerations applied as to the previoius CR. Ericsson believed the new text should not appear in this TS but elsewhere. But the Chairman questioned how this could really be accomplished. Also, the caching time was not reported in the notification but in the initial response.
revised No C3‑195319 C3‑194421
Agenda Topic TDoc Title Source Type For Avail Treated Decision Wdrn Repl-by Replaces
    C3‑195319 PFD partial failure notification Huawei CR Approval Yes
Yes
agreed No   C3‑195100
    C3‑195122 Correct the redirection server address to support dual stack UE Ericsson CR   Yes
YesWuawei did not think the new AVP was needed. Multiple instances of the single AVP were permitted. Ericsson checked this off line.
revised No C3‑195343  
    C3‑195343 Correct the redirection server address to support dual stack UE Ericsson CR Agreement Yes
Yes
agreed No   C3‑195122
    C3‑195124 LS on new AVP in TS 29.212 Ericsson LS out   Yes
Yes
not pursued No    
16.31 OpenAPI version updates C3‑195034 Update of TS version_Rel-16 Huawei CR Agreement Yes
YesThere was some doubt over whether the new externalDocs versions were correct. This was checked off line.
revised No C3‑195338  
    C3‑195338 Update of TS version_Rel-16 Huawei CR Agreement Yes
Yes
agreed No   C3‑195034
    C3‑195072 Update of API version and TS version in OpenAPI file Huawei CR Agreement Yes
NoThis CR would be approved by email after the meeting.
not concluded No    
    C3‑195073 Update of API version and TS version in OpenAPI file Huawei CR Agreement Yes
YesThis CR could be approved by email after the meeting.
revised No C3‑195368  
    C3‑195368 Update of API version and TS version in OpenAPI file Huawei CR Agreement Yes
YesThe Chairman approved of the explit mention of the Release.
agreed No   C3‑195073
    C3‑195075 OpenAPI version update of Rel-16 Nudr_DataRepository API Huawei discussion Information Yes
YesIt was believed that there were other CRs to include. CT4 needed to be informed. Therefore Huawei believed it needed to be approved during the meeting.
revised No C3‑195366  
    C3‑195366 OpenAPI version update of Rel-16 Nudr_DataRepository API Huawei discussion Information Yes
Yes
noted No   C3‑195075
    C3‑195111 Update of API version and TS version in OpenAPI file Huawei CR Approval Yes
Yes
revised No C3‑195367  
    C3‑195367 Update of API version and TS version in OpenAPI file Huawei CR Approval Yes
Yes
agreed No   C3‑195111
    C3‑195344 Update of API version and TS version in OpenAPI file Ericsson CR Agreement Yes
Yes
agreed No    
    C3‑195345 Update of API version and TS version in OpenAPI file Nokia, Nokia Shanghai Bell CR Agreement Yes
YesEricsson had checked the CRs and the list was correct.
agreed No    
    C3‑195349 Update of API version and TS version in OpenAPI file Nokia, Nokia Shanghai Bell CR Agreement No
Yes(Withdrawn, duplicate of '5345)
withdrawn Yes    
    C3‑195346 Update of API version and TS version in OpenAPI file Nokia, Nokia Shanghai Bell CR Agreement No
NoEmail agreement, see details in C3-195351.
not concluded No    
    C3‑195347 Update of API version and TS version in OpenAPI file Nokia, Nokia Shanghai Bell CR Agreement Yes
Yes(Wrong document uploaded)
revised No C3‑195385  
    C3‑195385 Update of API version and TS version in OpenAPI file China Mobile CR Agreement No
NoEmail agreement, see details in C3-195351.
not concluded No   C3‑195347
    C3‑195348 Update of API version and TS version in OpenAPI file Nokia, Nokia Shanghai Bell CR Agreement Yes
Yes
revised No C3‑195398  
Agenda Topic TDoc Title Source Type For Avail Treated Decision Wdrn Repl-by Replaces
    C3‑195398 Update of API version and TS version in OpenAPI file Nokia, Nokia Shanghai Bell CR Agreement Yes
Yes
agreed No   C3‑195348
    C3‑195350 Update of API version and TS version in OpenAPI file Nokia, Nokia Shanghai Bell CR Agreement Yes
Yes
agreed No    
    C3‑195351 Update of API version and TS version in OpenAPI file Nokia, Nokia Shanghai Bell CR Agreement No
NoThe CR would be proveded for email approval and would include all the API changes stemming from this meeting. To be available by Wednesday 20 Nov, comments by Friday 12h CET.
not concluded No    
    C3‑195360 Update of API version and TS version in OpenAPI file Nokia, Nokia Shanghai Bell CR Agreement Yes
Yes
agreed No    
    C3‑195361 Update of API version and TS version in OpenAPI file Ericsson CR Agreement Yes
Yes
agreed No    
17 Work Organisation                      
17.1 Work Plan Review C3‑195009 Status of CT3 Work Items CT3 chairman Work Plan Information Yes
YesThe Chairman needed to add 5G SRVCC to the list of Wis addressed by CT3. That WI is under the control of CT4.
revised No C3‑195433  
    C3‑195433 Status of CT3 Work Items CT3 chairman Work Plan Information No
No
reserved No   C3‑195009
    C3‑195012 WI status report from MCC MCC Work Plan Information Yes
Yes
noted No    
17.2 Specification Review                      
17.3 Next meetings, allocation of hosts                      
17.4 Calendar C3‑195013 Meeting Calendar MCC other Information Yes
YesThe Chairman wondered if there was thought to be a need for an ad hoc in July 2020. That meeting would address Rel-17. The Secretary urged that ad hocs should preferably be held at or close to ETSI HQ to be assured of MCC support. Huawei believed it would be good to retain this meeting and cancel the August "ordinary" meeting since this was in the US, which was difficult for some Chinese delegates. But this was not acceptable. There was no strong support for retaining the July ad hoc. A firm decision would be made in February 2020.
noted No    
18 Joint Sessions C3‑195048 Increasing the maximum MDBV value Qualcomm Incorporated / Lena discussion Information Yes
Yes
noted No    
    C3‑195049 CT impacts of support for NR accessing through unlicensed bands (NR-U) in 5GS Qualcomm Incorporated / Lena discussion Discussion Yes
Yes
noted No    
    C3‑195050 Adding support for NR and E-UTRA accessing through unlicensed bands Qualcomm Incorporated / Lena discussion Information Yes
Yes
noted No    
    C3‑195215 Fourth field of API versions Ericsson, Verizon, Nokia, Nokia Shanghai Bell discussion Discussion Yes
Yes
noted No    
    C3‑195217 DNN Network Identifier and Operator Identifier Ericsson discussion Discussion No
Yes
withdrawn Yes    
    C3‑195218 DNN Network Identifier and Operator Identifier Ericsson discussion Discussion Yes
Yes
noted No    
    C3‑195219 Discussion on DNN Huawei discussion Agreement Yes
Yes
noted No    
    C3‑195220 CR 29.571 Definition of Dnn Huawei discussion Agreement Yes
Yes
noted No    
Agenda Topic TDoc Title Source Type For Avail Treated Decision Wdrn Repl-by Replaces
19 Summary of results                      
20 Any other business                      
21 Closing of the meeting