TDoc list

Tdoc List

2019-01-09 16:05

Agenda	Topic	TDoc	Title	Source	Type	For	Avail	Treated	Decision	Wdrn	Replaced-by	Replaces
1	Opening of the meeting (Monday 8.30)
2	Approval of the agenda	S5‑187000	Agenda	WG Chairman	agenda		Yes	Yes	approved	No
3	IPR declaration	S5‑187001	IPR and legal declaration	WG Chairman	other		Yes	YesThe attention of the delegates to the meeting of this Technical Specification Group was drawn to the fact that 3GPP Individual Members have the obligation under the IPR Policies of their respective Organizational Partners to inform their respective Organizational Partners of Essential IPRs they become aware of. The delegates were asked to take note that they were thereby invited: to investigate whether their organization or any other organization owns IPRs which were, or were likely to become Essential in respect of the work of 3GPP. to notify their respective Organizational Partners of all potential IPRs, e.g., for ETSI, by means of the IPR Information Statement and the Licensing declaration forms. The attention of the delegates to the meeting was drawn to the fact that 3GPP activities were subject to all applicable antitrust and competition laws and that compliance with said laws was therefore required by any participant of the meeting, including the Chairman and Vice-Chairmen and were invited to seek any clarification needed with their legal counsel. The leadership would conduct the present meeting with impartiality and in the interests of 3GPP. Delegates were reminded that timely submission of work items in advance of TSG/WG meetings was important to allow for full and fair consideration of such matters. Delegates were reminded of the fair network use rules established by the PCG: 1. Users shall not use the network to engage in illegal activities. This includes activities such as copyright violation, hacking, espionage or any other activity that may be prohibited by local laws. 2. Users shall not engage in non-work related activities that can consume excessive bandwidth or cause significant degradation of the performance of the network.	noted	No
4	Meetings and activities reports
4.1	Last SA5 meeting report	S5‑187002	Report from last SA5 meeting (draft)	MCC	report		Yes	YesNo changes were proposed.	revised	No	S5‑187335
		S5‑187335	Report from last SA5 meeting (final)	MCC	report	-	Yes	Yes	approved	No		S5‑187002
4.2	Last SA meeting report
4.3	Inter-organizational reports
5	Cross-SWG issues
5.1	Administrative issues at SA5 level	S5‑187003	Leaders meeting agenda	WG Chairman	agenda		Yes	Yes	noted	No
		S5‑187004	Leaders meeting minutes	WG Chairman	report		Yes	YesIt was agreed that all new SA5 TRs and TSs should have as the top level title "Managhement and Orchestration" or "Charging management" as appropriate. The Chairman believed that some adjustment to the timing of future meetings was desirable - there seemed to be too many early in the year, with a dearth in the autumn. This was for historical reasons stemming from offers of hosting. A draft of a communicatons plan to enhance the external visibility of SA5 had been discussed, and a more systematic review of converences etc would henceforward be instigated.	noted	No
		S5‑187005	SA5 Working Procedures	WG Vice Chair (Huawei)	other		Yes	YesThe Secretary noted that some updates were probably needed, and he would work with Christian Toche off line.	noted	No
		S5‑187006	SA5 Meeting Facility Requirements	WG Vice Chair (Orange)	other		Yes	YesThe Secretary would also review this document off line to compare its contents with the general guidelines on the web site, with a view to harminize the sets of guidelines. The document would be revised for the next meeting.	approved	No
		S5‑187007	Process for management of draft TSs/TRs	WG Chairman	other		Yes	Yes	noted	No
		S5‑187008	CR Quality Check	MCC	other		Yes	YesThe Chairman proposed to check every CR against this document as the CR was treated.	noted	No
		S5‑187009	Status of email approvals	WG Vice Chair (Orange)	other		No	No	reserved	No
5.2	Technical issues at SA5 level
5.3	Liaison statements at SA5 level	S5‑187036	Resubmitted Reply LS from CT to SA5 on API specification and API version number maintenance	TSG CT	LS in		Yes	YesThe main objective of the tdoc was to ensure that all APIs were treated in the same way. The Secretary outlined the CT4 idea insofar as he understood it, noting that he had not been able to participatre in the teleconference on this subject the previous week. There was some concern over why CT groups would not use the industry-standard github service. It was noted that the SA5 Charging subgroup was already following the guidelines of 24.501. The Secretary also mentiooned the dificulty of applying 3GP's traditional change control mechanism, which was perhaps not compatible with other groups' methods.	replied to	No
		S5‑187336	Reply to: Resubmitted Reply LS from CT to SA5 on API specification and API version number maintenance	SA5 (Ericsson et al)	LS out	approval	Yes	Yes	approved	No
5.4	SA5 meeting calendar	S5‑187010	SA5 Meeting Calendar	WG Chairman	other		Yes	YesThe Chairman noted that TSG SA had urged WGs to reduce the number of meetings per year if possible. Nevertheless, SA5 might maintain that it was necessary in 2019 to hold six ordinary meetings and up to two ad hocs. Various options were mooted for evening out the meetings, andn it had to be born in mind that clashes with SA3. However, there was some reluctance to modify the current plans as given in this tdoc. It was recalled that MCC was not "obliged" to support ad hoc meetings. Some delegates believed that clashes with othe WGs (other, that is, than SA3) caused logistical problems for some companies, and too many meetings had obvious financial implications for all organizations. One option was to "move" the January meetin ghosted by NAF3 to October.	revised	No	S5‑187366
		S5‑187366	SA5 Meeting Calendar	WG Chairman	other	-	Yes	Yes	approved	No		S5‑187010
5.5	Review of the Work Plan	S5‑187011	3GPP SA5 Work Plan	MCC	other		Yes	Yes	noted	No
6	OAM&P
6.1	OAM&P Plenary	S5‑187012	Time Plan for OAM&P	WG Vice Chair (Huawei)	other		Yes	YesThe Session Chairman presented the document, noting that there were fewer tdocs to be addressed in the session than usual. The Session Chairman noted that late contributions would be address if time permitted at the end of the agenda item. Notwithstanding, rapporteurs should provide a running order for their documents. It was the intention to ensure all contributions would be addressed. It was noted that some adjustment to the proposed session timing might be required, bearing in mind the late contributions.	revised	No	S5‑187338
		S5‑187338	Time Plan for OAM&P	WG Vice Chair (Huawei)	other	-	Yes	Yes	approved	No		S5‑187012
		S5‑187013	OAM Executive Report	WG Vice Chair (Huawei)	report		Yes	YesSlide 10: it was noted that work item NETSLICE-ADPM5G was in fact 100% (despite its spec being only 80% complate).	revised	No	S5‑187543
		S5‑187543	OAM Executive Report	WG Vice Chair (Huawei)	report	-	Yes	Yes	noted	No		S5‑187013
		S5‑187014	OAM&P SWG action list	WG Vice Chair (Huawei)	other		Yes	YesChristian Toche provided the document.	revised	No	S5‑187493
		S5‑187493	OAM&P SWG action list	WG Vice Chair (Huawei)	other	-	Yes	Yes	noted	No		S5‑187014
		S5‑187015	Minutes of OAM&P SWG opening session	WG Vice Chair (Huawei)	report		Yes	YesMy Cornily presented the document.	noted	No
		S5‑187037	Reply LS from RAN2 to SA5 on L2 measurements	RAN2	LS in		Yes	YesThe document was presented by Huawei. Ericsson noted that SA5 would need to refer to the RAN2 spec in due course. SA5 would not define the triggers, but would refer to the RAN2 definitions. Thiw was "business as usual". Intel was concerned that RAN2 were making slow progress. Ericsson stated that it was up to SA5 to make speicific requests. Nokia and Huawei agreed.	noted	No
		S5‑187038	Reply LS to SA5 on L2 measurements	RAN3	LS in		Yes	YesHuawei presented the document. Intel believed that SA5 had a problem which needed to be fixed here. The word "mapped" could be removed: "5QI" was sufficient. Ericsson disagreed, believing that the RAN2 view was correct. SA5 should return to normal activity, requesting RAN2 for each case in turn. Cisco believed tjat a bearer copuld include multiple QoS flows, and each would have the same "mapped 5QI". But it was not clear how to handle the case where several QoS flows were needed.	noted	No
		S5‑187039	LS from SA2 to SA5 on QoS Monitoring	SA2	LS in		Yes	YesHuawei presented the document. SA2 put two questions to SA5. Intel believed that SA5 and SA2 needed to work together on thie question of latency. Ericsson agreed, but the effect on the RAN was unclear at this stage, and further evaluation was needed. For the second question, uplink measurements were a problem. Nokia thought there was a logistical problem concerning action 2: this was not in the scope of SA5. SA5 could benefit from the SA2 requirements, but the solution was in the hands of RAN. Huawei returned to the actions requested in the LS. RAN2 had defined six measurements, and SA5 needed to clarifiy this in its reply. Cisco agreed with what had been said so far. But SA5 could indeed make use of the measurements performed for statistical purposes. Nokia proposed an extension of MDT, where mechanisms could be further extended. Intel agreed. Maybe a new term was needed for MDT, however. Nokia believed that what was approved in this enhancement was an assurance. Cisco stated that end to end measurements were perfectly possible (some were already defined by IETF), and it was possible to analyse on a per packet basis if needed.. Huawei observed that there were two draft replies to this LS in '7293 and '7296.	replied to	No
		S5‑187293	LS reply on QoS monitoring	SA5 (Intel China Ltd.)	LS out	Approval	Yes	YesNokia were not happy with the mechanism described in this draft reply.	noted	No
		S5‑187296	Draft LS reply on QoS monitoring	SA5 (Huawei Tech.(UK) Co., Ltd)	LS out		Yes	YesNokia believed that the N6 interface was incorrect. Intel agreed that this would need to be reivisited. Also, the work item code on the document was incorrect. Ericsson believed the measurements were per packet, not per flow. Nokia greed but noted that this was not in the scope of SA5. After extensive discussions, the topic was taken off line.	noted	No
		S5‑187339	Reply to: LS from SA2 to SA5 on QoS Monitoring	SA5 (Huawei, Intel China)	LS out	approval	Yes	Yes	approved	No
		S5‑187041	Resubmitted LS from ITU-T to SA5 on cooperation on REST-based network management framework	ITU-T Study Group 2	LS in		Yes	YesIt was noted that this documenbt had been seen at the previous meeting. SA5 had been considering the topic since at least April 2018. Nokia thought that a response needed further work, but a holding response could be made. Ericsson suggested it needed discussion in methods coordination. Nokia questioned the benefits of some aspects of alignment with ITU.	replied to	No
		S5‑187340	Reply to: Resubmitted LS from ITU-T to SA5 on cooperation on REST-based network management framework	SA5 (Ericsson)	LS out	approval	Yes	YesWill become available after pCR incorporation in 32.160. Secretary to create v1.0.0 as soon as possible after email agreement of v0.2.0.	approved	No
		S5‑187042	LS/r from ITU-T to SA5 on Energy Efficiency (reply to 3GPP TSG SA5 - S5-182439)	ITU-T Study Group 5	LS in		Yes	YesThe document was presented by Orange. The nature of the proposed cooperation was a little unclear: did SG5 propose to initiate a WI in 3GPP? Huawei believed that cooperation was important. Perhaps SG5 would offer us a draft text at some time in the future. The LS was rather unclear. It was noted that cooperation with ETSI TC EE might be more appropriate than with SA5. Orange noted that EE was meeting concurrently with the present SA5 meeting. Huawei wondered whether 3GPP should be more proactive on this topic, but Orange noted that 3GPP was contribution driven, and without contributions, there would be little progress.	noted	No
		S5‑187043	LS/r from ITU-T ccSA5 on Energy Efficiency (reply to ETSI TC EE - EE(18)053033-E)	ITU-T Study Group 5	LS in		Yes	YesOrange recalled that there was a possibility of a joint meeting with ETSI TC EE on this topic, or perhaps just a conference call. A F2F joint meeting with EE in Sophia Antipolis was preferable. The document would be readdressed at the next meeting.	postponed	No
		S5‑187294	Outstanding questions from ETSI NFV ISG related to network slicing	Ericsson, Nokia, Huawei, ZTE	discussion	Discussion	Yes	YesNokia presented the document on behaf of the joint authors. Ericsson had had communication from one of the NFV vice-chairmen on this topic, and NFV had proposed a conference call with interested parties to discuss this topic; this was not mentioned in the present tdoc. But Nokia noted that SA5 could not express a WG-agreed position on such a call. Cisco wondered exactly what sort of reply NFV expected. Nokia endeavoured to reply to this, likening their expectations to "42", including prioritization of actions when resources were running low. SA5 had already promised a "simple" response. Cisco doubted that such a simple response would suffice.	noted	No
		S5‑187303	JSON Schema related IETF draft reference update	Ericsson LM (WG chairman)	discussion	Discussion	Yes	YesEricsson presented the document, noting that the text came from the IETF Coordinator (aka Chairman of TST CT). It was noted that the spec numbers for SA5 were incorrect. During the week there was further discussion on several email lists. However, the situation was not yet stable. It would be discussed at CT#82.	noted	No
		S5‑187341	Preparation of reply to ETSI NFV on network slicing	Nokia, Huawei, Ericsson	other	discussion	Yes	Yes	endorsed	No
		S5‑187488	Clarifications topics for NFV NS in context of Network Slicing	ETSI ISG NFV	LS in	Action	Yes	Yes	replied to	No
		S5‑187515	Reply to: Clarifications topics for NFV NS in context of Network Slicing	SA5 (Huawei)	LS out	approval	Yes	Yes	revised	No	S5‑187516
		S5‑187516	Reply to: Clarifications topics for NFV NS in context of Network Slicing	SA5 (Huawei)	LS out	approval	Yes	YesNokia wished to attach the related use cases to the LS.	revised	No	S5‑187539	S5‑187515
		S5‑187539	Reply to: Clarifications topics for NFV NS in context of Network Slicing	SA5 (Huawei)	LS out	approval	Yes	Yes	revised	No	S5‑187544	S5‑187516
		S5‑187544	Reply to: Clarifications topics for NFV NS in context of Network Slicing	SA5 (Huawei)	LS out	approval	Yes	Yes	approved	No		S5‑187539
6.2	New OAM&P Work Item proposals	S5‑187016	Minutes of New Work Item proposals - OAM&P	WG Vice Chair (Orange)	report		Yes	Yes	noted	No
		S5‑187288	Service Based Trace Management	Nokia Korea	WID new		Yes	YesNokia had observed that there was no workable Trace IRP for service-abased trace management. Such studdies should result in a TR, and the normative work could be expected to affect the listed TSs. Intel wondered whether it was really possible to procude the TR by December 2018. Nokia believed that discussions might reveal that no TR was actually needed. Deutsche Telekom was also concerned about a normative work item requiring a TR. They were concerned about the mechaniisms needed, an Nokia responded to how this could be accomplished (a new management service, or modifications to an existing one). Huawei wondered whewther 5G network related trace was also covered by the WID. Nokia replied that this aspect was already covered in other specs, and that there were no dedicated 5G trace specs. Huawei believed that no TR would be necessary. Nokia invited all interested parties to off line discussion, with a view to completing the WI in as short a time as possible. NEC was concerned about the list of affected specs, and Nokia sought to clarify that no new SBMA was intended, and no new TS was needed. NEC believed that a study phase was probably needed, and he required further elaboration of the text. Intel noted the intention to update the trace IRPs. Nokia explained the nature of the changes to the existing specs, and would be happy to generate a new TS if really necessary. The session chairman believed that a discussion paper would be required on this, or alternatively, to prepare a study item rather than the normative WI at this stage. However Nokia was concerned that the matter was relatively urgent, but it should be easy to complete in Rel-16.	revised	No	S5‑187342
		S5‑187496	Study on non-file-based trace reporting	Nokia Korea	SID new	-	Yes	Yes	revised	No	S5‑187518
		S5‑187342	Trace Management in the context of Services Based Management Architecture	Nokia Korea	WID new	-	Yes	Yes	revised	No	S5‑187517	S5‑187288
		S5‑187517	Trace Management in the context of Services Based Management Architecture	Nokia Korea	WID new	-	Yes	Yes	agreed	No		S5‑187342
		S5‑187518	Study on non-file-based trace reporting	Nokia Korea	SID new	-	Yes	YesNokia said there was no overlap between the WID above and the SID. Work would be undertaken on both in parallel.	agreed	No		S5‑187496
6.3	OAM&P Maintenance and Rel-16 small Enhancements	S5‑187017	Minutes of OAM&P Maintenance and Rel-16 small Enhancements	MCC	report		No	Yes	withdrawn	Yes
		S5‑187046	R16 CR 28.541 Add GUtranRelation Class	ZTE Wistron Telecom AB	CR	Agreement	Yes	YesHuawei questioned the provisions for handover to a UTAN cell, and wondered whether this was yet supported in RAN3. There was nothing about UTRAN generic cell in the definitions. Intel remarked a typo in the document shich needed correction. Ericsson was concerned about the symmetry and relationships of the classes. There was need for architecture alignment. There was contributions from Huwawei and others on this topic. MCC had noticed that the proposed WI code was not appropriate to a Rel-16 CR. A "phase 2" WI was needed. It was pointed out that there was a proposed new work item from the previous meeting but that was still not TSG approved. Alternatively, the CR could be Rel-15.	not pursued	No
		S5‑187047	R16 CR 28.541 Add Beam Class	ZTE Wistron Telecom AB	CR	Agreement	Yes	YesThe same MCC remarks about invalid WI code or invalid Release applied. Pivoltal Commware was worried about ensuring a harmonised approach with RAN groups relating to SON use cases. The NRM model was still open as far as these issues were concerned. Cisco assumed that the document related to static or semi-static configuraton of beams. How did the switching work? Intel pointed out that there were already attributes which defined the beams. For Rel-15, Pivoltal Commware suggested that beams were treated as sectors, and this needed improvement for Rel-16.	revised	No	S5‑187343
		S5‑187343	R16 CR 28.541 Add Beam Class	ZTE Wistron Telecom AB	CR	Agreement	Yes	YesHuwei thought their comment on layer 1 had not been taken into account. Ericsson wished to see proper requirements before going into the fine details presented here.	not pursued	No		S5‑187047
		S5‑187058	Rel-15 CR 28.530 Fix gap of requirement for Network Slicing priority	China Telecom Corporation Ltd.	CR	Agreement	Yes	YesEricsson believed it would be better to have separate sentences for allocation and re-allocation.	revised	No	S5‑187344
		S5‑187344	Rel-15 CR 28.530 Fix gap of requirement for Network Slicing priority	China Telecom Corporation Ltd.	CR	Agreement	Yes	Yes	agreed	No		S5‑187058
		S5‑187059	CR Rel-15 28662 on frequency band	Ericsson Inc.	CR	Agreement	Yes	YesNokia suggested some wording changes. There was a minor typo on the cover (clauses affected).	revised	No	S5‑187345
		S5‑187345	CR Rel-15 28662 on frequency band	Ericsson Inc.	CR	Agreement	Yes	Yeswrong documents uploaded	withdrawn	Yes	S5‑187541	S5‑187059
		S5‑187541	CR Rel-15 28662 on frequency band	Ericsson Inc.	CR	Agreement	Yes	YesIt was noted that the "other comments" should not include S5-187345.	agreed	No		S5‑187345
		S5‑187060	TD on NR cell frequency relation	Ericsson Inc.	discussion	Endorsement	Yes	YesThe proposal was to add NRM fragments to several specs. This document was an addition to the proposals from Huawei. Huawei proposed some corrections relating to the title relating to internal or external frequencies. Intel asked for a discription about the relation between frequencies and cell relations. This had been discussed at the previous meeting. This was to reduce the number of duplicate attributes. But care was needed to maintain backward compatibility. Nokia did not like the "lazy" UML representation and was concerned about the semantics of the use of different colours and symbols, which was not explained. Was the frequency now a property of the sub-network? (It was pointed out that IETF used this text method for drawing figures.	revised	No	S5‑187346
		S5‑187346	TD on NR cell frequency relation	Ericsson,Huawei	discussion	Endorsement	Yes	Yes	endorsed	No		S5‑187060
		S5‑187061	CR Rel-15 TS 28658 view (E-UTRAN) of cell and frequency relations	Ericsson Inc.	CR	Agreement	No	Yes	withdrawn	Yes
		S5‑187062	CR Rel-15 TS 28541 view (NR) of cell and frequency relation	Ericsson Inc.	CR	Agreement	No	Yes	withdrawn	Yes
		S5‑187063	CR Rel-15 TS 28541 Remove the ExternalENBFunction definition	Ericsson Inc.	CR	Agreement	Yes	YesEricsson noted that there was an error in the existing spec relating to an imported definition.	revised	No	S5‑187347
		S5‑187347	CR Rel-15 TS 28541 Remove the ExternalENBFunction definition	Ericsson Inc.	CR	Agreement	Yes	Yes	agreed	No		S5‑187063
		S5‑187064	CR Rel-15 TS 28541 plmnIdList RW	Ericsson Inc.	CR	Agreement	No	Yes	withdrawn	Yes
		S5‑187065	CR Rel-15 TS 28541 on ExternalGNBCUCPFunction	Ericsson Inc.	CR	Agreement	Yes	YesHuawei did not believe that the changes corresponded to the declared summary of change. There was also a difficultly of the tool used to provide the figure: Papyrus did not handle imports well.	revised	No	S5‑187348
		S5‑187348	CR Rel-15 TS 28541 on ExternalGNBCUCPFunction	Ericsson Inc.	CR	Agreement	Yes	Yes	agreed	No		S5‑187065
		S5‑187066	CR Rel-15 TS 28.622 Generic NRM IS on Measurement Control	Ericsson Inc.	CR	Agreement	Yes	YesIntel wanted clearer text for the new objects, and there was confusion over consumer and producer roles. Ericsson did not believe this last point to be valid. Cisco supposed hat the proposal was a replacement for a job-based paradigm, and what was the benefit? Ericsson explained the model at length. Intel noted that the attributes were repeated, was this really necessary? There was also concern over timers. Again, Ericsson explained the proposals. The category should have been B not F.	revised	No	S5‑187349
		S5‑187349	CR Rel-15 TS 28.622 Generic NRM IS on Measurement Control	Ericsson Inc.	CR	Agreement	Yes	YesHuawei questioned the significance of the yellow highlighted text. These would be eliminated at implementation. Intel proposed changes to the table in §4.3.12.2 which was not aligned with some other TS.	agreed	No		S5‑187066
		S5‑187067	CR Rel-15 TS 32432 on measurement type	Ericsson Inc.	CR	Agreement	Yes	YesIntel queried the new text introduced into table 4.1. It was also remarked that the term "NR" did not stand for "New Radio", and should not be defined as an abbreviation. The category should have been B not F. There were also a few typos.	revised	No	S5‑187350
		S5‑187350	CR Rel-15 TS 32432 on measurement type	Ericsson Inc.	CR	Agreement	Yes	Yes	agreed	No		S5‑187067
		S5‑187072	Discussion Paper on the management of disaggregated RAN	Cisco Systems Inc.	discussion	Endorsement	Yes	YesNokia agreed that both figures of clause 3.3 were possible, but there was no definition of the functionality of gNB-CU and gNB-DU. The gNB-CU of option 2 did not expose the full RAN. Ericsson believed tht the specification did not provide sufficient detail to allow either of these options to be implemented. Ericsson proposed some additional wording relating to management provisioning services. Nokia was worried that NF was not clearly defined, so additional definitions were not useful: the services should define to each MO defined, and no restatement of requirements was needed.Cisco did not agree. Intel agreed with having both options. But the service was for the NF, not its components: CU and DU were treated as network functions. Indeed some attributes were duplicated, and this needed to be fixed.	revised	No	S5‑187466
		S5‑187466	Discussion Paper on the management of disaggregated RAN	Cisco Systems Inc.	discussion	Endorsement	Yes	Yes	endorsed	No		S5‑187072
		S5‑187116	R15 CR TS 28.532 change alarmIRP to FaultSupervision MnS producer	ZTE Wistron Telecom AB	CR	Agreement	Yes	YesHuawei had some problems with the terminology surrounding "service", "producer", "consumer", and "capabilities". A discussion on semantics ensued. Intel wished to refer to the legacy terminology.	revised	No	S5‑187351
		S5‑187351	R15 CR TS 28.532 change alarmIRP to FaultSupervision MnS producer	ZTE Wistron Telecom AB	CR	Agreement	Yes	Yes	agreed	No		S5‑187116
		S5‑187141	Rel-15 CR TS 32.450 Add missing EE KPI for E-UTRAN	Huawei, Orange	CR	Agreement	Yes	YesEricsson had some concern over the formula at the end of 6.X.1.1. Most of the energy wastage was in the UK rather than the Node-B. It was noted that the formula had not been invented by SA5. Intel was concerned over the energy at cell level. Some other formula would be needed for this. It was questioned whether a new WI were needed to cover this particular measurement. Also, was this specification also needed for ealeer Releases? Further, the term "efficiency" was not appropriate in this context, since it was not expressed as a percentage. Huawei stated that the objective was to have some agreed way of measuring the KPI. But since the terminology had not been invented by SA5, it was difficult to change. ETSI TC EE and ITU-T SG5 had devised the terminology.	revised	No	S5‑187352
		S5‑187352	Rel-15 CR TS 32.450 Add missing EE KPI for E-UTRAN	Huawei, Orange	CR	Agreement	Yes	Yes	agreed	No		S5‑187141
		S5‑187142	Rel-15 CR TS 32.451 Add missing EE KPI for E-UTRAN	Huawei, Orange	CR	Agreement	Yes	YesNanjing Ericsson Panda suggested some wording changes and the correction of a typo. ETSI TC EE had done extensive work relating to, for example, subnetworks of base stations. ZTE was concerned how to make the measurements.Huawei clarified that, for shared RANs, it was currently not possible to determine efficiency on a per-operator basis.	revised	No	S5‑187353
		S5‑187353	Rel-15 CR TS 32.451 Add missing EE KPI for E-UTRAN	Huawei, Orange	CR	Agreement	Yes	Yes	agreed	No		S5‑187142
		S5‑187143	Rel-15 CR TS 32.425 Update measurements supporting EE KPI	Huawei, Orange	CR	Agreement	Yes	YesNanjing Ericsson Panda believed some addition was needed. There was some discussion over which base document ([13] or [20]) to use as a reference. The revised wording of point i) was questioned.	revised	No	S5‑187354
		S5‑187354	Rel-15 CR TS 32.425 Update measurements supporting EE KPI	Huawei, Orange	CR	Agreement	Yes	Yes	agreed	No		S5‑187143
		S5‑187144	Rel-16 CR TS 32.425 Update measurements supporting EE KPI	Huawei, Orange	CR	Agreement	Yes	YesThe Category should have been A rather than F.	revised	No	S5‑187355
		S5‑187355	Rel-16 CR TS 32.425 Update measurements supporting EE KPI	Huawei, Orange	CR	Agreement	Yes	Yes	agreed	No		S5‑187144
		S5‑187145	Rel-15 CR TS 28.532 Add stage 2 definition for provisioning management service related notifications	Huawei	CR	Agreement	Yes	YesThe session chairman questioned the usefulness of the additional use cases. Noka questioned whether it was useful to specify requirements for a "toolbox" such as this spec. Cisco questioned the wording of clause 5.1.X.1: was "because" correct? Perhaps the whole sentence was unnecessary. Ericsson considered that the correlatedNotifications was mandatory, not optional, in table 5.1.X.2 - this was a long-standing misunderstanding. It should have been Conditional Mandatory. This implied an extensive CR to correct all such existing cases. Ericsson was concerned over the distinction between MOI and MO. The text needed to be harmonized.	revised	No	S5‑187356
		S5‑187356	Rel-15 CR TS 28.532 Add stage 2 definition for provisioning management service related notifications	Huawei	CR	Agreement	Yes	Yes	agreed	No		S5‑187145
		S5‑187146	Rel-15 CR TS 28.532 Correct stage 3 definition for provisioning management servuce related notifications	Huawei	CR	Agreement	Yes	YesThe cover sheet had numerous problems. Nokia identified a number of shortcomings in the structure of the CR. The subscription resource mentioned in the code was not mentioned in the tables. Considerable rework was implied.	revised	No	S5‑187357
		S5‑187357	Rel-15 CR TS 28.532 Correct stage 3 definition for provisioning management servuce related notifications	Nokia, Nokia Shanghai Bell, Huawei	CR	Agreement	No	NoThe document would be for email approval. (Olaf to coordinate.)	not concluded	No		S5‑187146
		S5‑187147	Rel-15 CR TS 28.531 Correct procedures with reference to TS 28.541	Huawei	CR	Agreement	Yes	YesSome cover page issues were identified. The removed note needed to be voided, and an additional reference was needed.	revised	No	S5‑187358
		S5‑187358	Rel-15 CR TS 28.531 Correct procedures with reference to TS 28.541	Huawei	CR	Agreement	Yes	Yes	agreed	No		S5‑187147
		S5‑187148	Rel-15 CR TS 28.531 Add usecase and requirements for MnS Query	Huawei	CR	Agreement	Yes	YesNokia questioned some wording which seemed to preclude use of any exissting stage 3 solutions (clause 5.2.X). Cisco believed it was a good idea to make the management services discoverable, but this CR underestimated the complexity of the issue. The operator might have a multiple vendor network, and might manage different groups of devices. This should be reflected in this CR. The same applied to the CR in '7149. Ericsson thought the requirement was insufficient: what was the goal of the exercise? What was the point of knowing the capabilities of the service provider? Nokia believed a general discussion on how all this should work: was everything to be stored centrally or would a federated approach be better? The CR was replaced by S5-187360.	not pursued	No	S5‑187360
		S5‑187360	Rel-15 CR TS 28.533 Add usecase and requirements for MnS Query	Huawei	CR	Agreement	Yes	Yes	agreed	No		S5‑187148
		S5‑187149	Rel-15 CR TS 28.532 Add stage2 definition for MnS Query	Huawei	CR	Agreement	Yes	YesNokia and Ericsson believeed it was necessary to which filder language to use. This needed to be decided and documented centrally. Huawei considered it desirable to treat all the related CRs together. NEC thought that this was a very complex issue, and should be dealt with fully at Release 16 rather than dabbling at Release 15. Cisco supported the objectives of this document but wished it to be clarified what information was needed, what the service was to provide.	revised	No	S5‑187361
		S5‑187361	Rel-15 CR TS 28.532 Add stage2 definition for MnS Query	Huawei	CR	Agreement	Yes	Yes	revised	No	S5‑187519	S5‑187149
		S5‑187519	Rel-15 CR TS 28.532 Add stage2 definition for MnS Query	Huawei	draftCR	Approval	Yes	Yes	approved	No		S5‑187361
		S5‑187150	Rel-15 CR TS 28.532 Add stage3 definition for MnS Query	Huawei	CR	Agreement	Yes	Yes	revised	No	S5‑187362
		S5‑187362	Rel-15 CR TS 28.532 Add stage3 definition for MnS Query	Huawei	CR	Agreement	Yes	Yes	revised	No	S5‑187520	S5‑187150
		S5‑187520	Rel-15 CR TS 28.532 Add stage3 definition for MnS Query	Huawei	draftCR	Approval	Yes	Yes	approved	No		S5‑187362
		S5‑187151	Rel-15 CR TS 28.541 Update NR NRM with Cell Relation	Huawei	CR	Agreement	Yes	YesCisco wondered how the proposal would cater for carrier aggregation, so the server would operate on several channels simultaneously. Huawei explained figure 4.2.1.1-X ensured this capability. Ericsson believed this figure was ok, but was incomplete: the NR frequency relationship had attributes which justified this work. But further reductions were possible to eliminate common functionality. The structure of the classes was satisfactory, but the complete picture was needed. The session chairman wondered whether this CR could be combined with the ZTE one on the same topic. Ericsson had doubts about the viability of this, especially when Ericsson's views were taken into account. The session chairman believed the discussion paper was the first priority.	revised	No	S5‑187363
		S5‑187363	Rel-15 CR TS 28.541 Update NR NRM with Cell Relation	Huawei, Ericsson	CR	Agreement	Yes	Yes	agreed	No		S5‑187151
		S5‑187154	CR Rel-15 TS 28.541 Correction of missing 5G NRM NRSectorCarrier IOC attributes.	Pivotal Commware	CR	Agreement	Yes	YesMCC had detected some errors.	revised	No	S5‑187337
		S5‑187337	CR Rel-15 TS 28.541 Correction of missing 5G NRM NRSectorCarrier IOC attributes.	Pivotal Commware	CR	Agreement	Yes	YesPivotal Commware indicated the logic for using phi and theta rather than horizontal and vertical for reasons of alighment of terminoligy related to beams. Nokia was pleased to see correct terminology in this revised version. There was some doubt whether there was technical content change compared to the previous version or not. Ericsson noted the change from O to CM, but the condition was not given. The requirement was too general, so this solution was not really useful: did it actually support the requirement? Pivotal Commware endeavoured to respond to these remarks. Ericsson believed it was a big step to change from "monitoring" to "active management". The NRM needed functionality to handle this. The source company believed the market needed monitoring and measuring urgently. Huawei had some concerns over the four new attributes. Intel wondered whether the model handled single or multiple beams. Pivotal Commware stated that multiple, dynamic, beams were handled. A CR to 28.540 was needed to provide a definitive requirement statement.	revised	No	S5‑187364	S5‑187154
		S5‑187364	CR Rel-15 TS 28.541 Add read-only NRM Info Model definitions for beam IOC and attributes to NRSectorCarrier IOC	Pivotal Commware	CR	Agreement	Yes	YesThis could not be discussed until '7542 had been dealt with.	postponed	No		S5‑187337
		S5‑187365	CR Rel-15 TS 28.540 Support read-only mgmt of NR beams in NRM definitions	Pivotal Commware	CR	Agreement	Yes	Yes	revised	No	S5‑187514
		S5‑187514	CR Rel-15 TS 28.540 Support read-only mgmt of NR beams in NRM definitions	Pivotal Commware	CR	Agreement	Yes	YesEricsson repeated his remarks on the original version. The representation should use the term "class". But these were beam properties.	revised	No	S5‑187542	S5‑187365
		S5‑187542	CR Rel-15 TS 28.540 Support read-only mgmt of NR beams in NRM definitions	Pivotal Commware	CR	Agreement	Yes	YesZTE wondered what was meant by beam properties. ZTE also proposed to remove the read-only attribute. These points were clarified by several companies.	agreed	No		S5‑187514
		S5‑187189	Discussion paper about network slice priority handling in 3GPP management system	Huawei Telecommunication India	discussion	Discussion	Yes	Yes[Secretary busy, could not record discussion.]	noted	No
		S5‑187190	Rel-16 CR Introduce definitions of Network slice management priority and operation severity	Huawei Telecommunication India	CR	Agreement	Yes	YesThis was a consequence of the preceding discussion paper (which could not be agreed). Nokia believed that these changed were targeted at the wrong spec. This contribution was not needed. ZTE believed that MANO was responsible for network services, and some discussion with ETSI was needed. Deutsche Telekom was also not in favour of this approach. Cisco thought most of the text was not needed, and anyway the spec could not include an FFS statement. Telecom Italia questioned the new text to clause 4.3: should this be network slice type?	revised	No	S5‑187367
		S5‑187367	Rel-16 CR Introduce definitions of Network slice management priority and operation severity	Huawei Telecommunication India	CR	Agreement	No	YesNo agreement could be arrived at, so this document was not made available.	not pursued	No		S5‑187190
		S5‑187191	Rel-16 CR Add network slice management use case with priority	Huawei Telecommunication India	CR	Agreement	Yes	YesThere was some concern over the wording of the pre-conditions. Nokia believed this high level of detail was unnecessary, though general service prioritization was necessary but was the responsibility of SA1. Nanjing Ericsson Panda believed that a comprehensive use case was indeed needed. Deutsche Telekom stated that this was only focused on communication services. This was insufficient.	revised	No	S5‑187368
		S5‑187368	Rel-16 CR Add network slice management use case with priority	Huawei Telecommunication India	CR	Agreement	Yes	Yes	agreed	No		S5‑187191
		S5‑187192	Rel-16 CR Add network slice management interactions with severity type	Huawei Telecommunication India	CR	Agreement	Yes	YesThis was a continuation of the previous contribution. Nokia believed that this contribution was going in the right diirection but the text could be clarified and reduced. Deutsche Telekom did not like mixing severity with priority. Orange was puzzled by the need to create a 3GPP subnetwork.	revised	No	S5‑187369
		S5‑187369	Rel-16 CR Add network slice management interactions with severity type	Huawei Telecommunication India	CR	Agreement	Yes	YesCover page problems.	revised	No	S5‑187521	S5‑187192
		S5‑187521	Rel-16 CR Add network slice management interactions with severity type	Huawei Telecommunication India	CR	Agreement	Yes	YesSome check boxes were still not checked on the cover.	agreed	No		S5‑187369
		S5‑187193	Rel-16 CR Change NRM IOCs for network slice priority support	Huawei Telecommunication India	CR	Agreement	Yes	YesNokia did not like the approach. It was also indicated that the data type was wrong - it should be an integer. The changes should be perhaps coupled with those of tdoc 7260.	not pursued	No
		S5‑187194	Change NRM IOCs for network slice priority support stage 3	Huawei Telecommunication India	CR	Agreement	Yes	Yes	not pursued	No
		S5‑187217	RRM Policy enhancements	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes[revised wiithout presentation]	revised	No	S5‑187251
		S5‑187251	RRM Policy enhancements	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes[revised wiithout presentation]	revised	No	S5‑187359	S5‑187217
		S5‑187359	RRM Policy enhancements	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	YesEricsson proposed a wording change, and Huawei supported this. More precision over the meaning of radio resource was needed.	revised	No	S5‑187426	S5‑187251
		S5‑187426	RRM Policy enhancements	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No		S5‑187359
		S5‑187224	Discussion on TAC attributes in 28.541	Ericsson	discussion	Endorsement	Yes	Yes	revised	No	S5‑187420
		S5‑187420	Discussion on TAC attributes in 28.541	Ericsson	discussion	Endorsement	Yes	Yes	endorsed	No		S5‑187224
		S5‑187245	Fix containment issue in YANG definition	Nokia Korea	CR	Agreement	Yes	YesSome editorial corrections were neede	revised	No	S5‑187410
		S5‑187410	Fix containment issue in YANG definition	Nokia Korea	CR	Agreement	Yes	Yes	agreed	No		S5‑187245
		S5‑187246	Correction of reference	Ericsson Japan K.K.	CR	Agreement	Yes	Yes	revised	No	S5‑187421
		S5‑187421	Correction of reference	Ericsson Japan K.K.	CR	Agreement	Yes	Yes	agreed	No		S5‑187246
		S5‑187247	Discussion paper on the abbreviation of MF	Ericsson	discussion	Endorsement	Yes	YesHuawei proposed to introduced a new abbreviation for "management function". A lengthy discussion ensued.	revised	No	S5‑187422
		S5‑187422	Discussion paper on the abbreviation of MF	Ericsson	discussion	Endorsement	Yes	Yes	endorsed	No		S5‑187247
		S5‑187248	Rel-15 CR 28.530 Replace MF with managed function	Ericsson Limited	CR	Agreement	Yes	Yes	revised	No	S5‑187423
		S5‑187423	Rel-15 CR 28.530 Replace MF with managed function	Ericsson Limited	CR	Agreement	Yes	Yes	agreed	No		S5‑187248
		S5‑187249	Rel-15 CR 28.533 Replace MF with management function	Ericsson Limited	CR	Agreement	Yes	Yes	revised	No	S5‑187424
		S5‑187424	Rel-15 CR 28.533 Replace MF with management function	Ericsson Limited	CR	Agreement	Yes	YesRev marks on cover	revised	No	S5‑187522	S5‑187249
		S5‑187522	Rel-15 CR 28.533 Replace MF with management function	Ericsson Limited	CR	Agreement	Yes	Yes	agreed	No		S5‑187424
		S5‑187250	Rel-15 CR 28.622 Replace MF with ManagedFunction	Ericsson Limited	CR	Agreement	Yes	Yes	revised	No	S5‑187425
		S5‑187425	Rel-15 CR 28.622 Replace MF with ManagedFunction	Ericsson Limited	CR	Agreement	Yes	Yes	agreed	No		S5‑187250
		S5‑187260	Update NRM root IOCs to support slice priority	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	YesThe data type was given as deciman, being more versatile than integer. Nokia could accept this.	revised	No	S5‑187370
		S5‑187370	Update NRM root IOCs to support slice priority	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No		S5‑187260
		S5‑187263	Correct PLMN ID List Type in Solution Set Stage 2	Ericsson GmbH, Eurolab	CR	Agreement	Yes	YesHuawei suggested a definite type for the parameter rather than referring to allowedValues. A better work item code was found.	revised	No	S5‑187427
		S5‑187427	Correct PLMN ID List Type in Solution Set Stage 2	Ericsson GmbH, Eurolab	CR	Agreement	Yes	YesIt was noted that the data type was not provided. There was a reference to a stage 2 SA2 TS, but that had no definition either. However Ericsson thought that this was common practice, an undefined data type was not standardized.	postponed	No		S5‑187263
		S5‑187265	Correct PLMN ID List Type in Solution Set Stage 2	Ericsson GmbH, Eurolab	CR	Agreement	Yes	Yes	revised	No	S5‑187428
		S5‑187428	Correct PLMN ID List Type in Solution Set Stage 2	Ericsson GmbH, Eurolab	CR	Agreement	Yes	Yes	postponed	No		S5‑187265
		S5‑187266	Correct PLMN ID List Type in Solution Set Stage 2	Ericsson GmbH, Eurolab	CR	Agreement	Yes	Yes	revised	No	S5‑187429
		S5‑187429	Correct PLMN ID List Type in Solution Set Stage 2	Ericsson GmbH, Eurolab	CR	Agreement	Yes	Yes	postponed	No		S5‑187266
		S5‑187267	Correct PLMN ID List Type in Solution Set Stage 2	Ericsson GmbH, Eurolab	CR	Agreement	Yes	Yes	revised	No	S5‑187430
		S5‑187430	Correct PLMN ID List Type in Solution Set Stage 2	Ericsson GmbH, Eurolab	CR	Agreement	Yes	Yes	postponed	No		S5‑187267
		S5‑187268	Correct PLMN ID List Type in Solution Set Stage 2	Ericsson GmbH, Eurolab	CR	Agreement	Yes	Yes	revised	No	S5‑187431
		S5‑187431	Correct PLMN ID List Type in Solution Set Stage 2	Ericsson GmbH, Eurolab	CR	Agreement	Yes	Yes	postponed	No		S5‑187268
		S5‑187269	Correct Plmnid Type in Solution Set Stage 3	Ericsson GmbH, Eurolab	CR	Agreement	Yes	YesNokia and other companies objected to the change of type. The change was not backward compatible. Ericsson believed that there was a confusion with the original allocations of MCC/MNC values 011 and 11, which were not the same. Two operators were affected.	revised	No	S5‑187432
		S5‑187432	Correct Plmnid Type in Solution Set Stage 3	Ericsson GmbH, Eurolab	CR	Agreement	Yes	Yes	postponed	No		S5‑187269
		S5‑187270	Correct Plmnid Type in Solution Set Stage 3	Ericsson GmbH, Eurolab	CR	Agreement	Yes	Yes	revised	No	S5‑187433
		S5‑187433	Correct Plmnid Type in Solution Set Stage 3	Ericsson GmbH, Eurolab	CR	Agreement	Yes	Yes	postponed	No		S5‑187270
		S5‑187271	Correct Plmnid Type in Solution Set Stage 3	Ericsson GmbH, Eurolab	CR	Agreement	Yes	Yes	revised	No	S5‑187434
		S5‑187434	Correct Plmnid Type in Solution Set Stage 3	Ericsson GmbH, Eurolab	CR	Agreement	Yes	Yes	postponed	No		S5‑187271
		S5‑187272	Correct Plmnid Type in Solution Set Stage 3	Ericsson GmbH, Eurolab	CR	Agreement	Yes	Yes	revised	No	S5‑187435
		S5‑187435	Correct Plmnid Type in Solution Set Stage 3	Ericsson GmbH, Eurolab	CR	Agreement	Yes	Yes	postponed	No		S5‑187272
		S5‑187273	Correct Plmnid Type in Solution Set Stage 3	Ericsson GmbH, Eurolab	CR	Agreement	Yes	Yes	revised	No	S5‑187436
		S5‑187436	Correct Plmnid Type in Solution Set Stage 3	Ericsson GmbH, Eurolab	CR	Agreement	Yes	Yes	postponed	No		S5‑187273
		S5‑187274	Rel-15 CR 28.531 Implement minor corrections	Ericsson Limited	CR	Agreement	Yes	Yes	revised	No	S5‑187437
		S5‑187437	Rel-16 CR 28.531 Implement minor corrections	Ericsson Limited	CR	Agreement	Yes	Yes	revised	No	S5‑187480	S5‑187274
		S5‑187275	Rel-15 CR 28.532 Correct erroneous reference to notification header	Ericsson Limited	CR	Agreement	Yes	Yes	agreed	No
		S5‑187276	Rel-15 CR 28.533 Implement MnS naming agreement	Ericsson Limited	CR	Agreement	Yes	Yes	agreed	No
		S5‑187277	Rel-15 CR 28.541 Implement minor corrections	Ericsson Limited	CR	Agreement	Yes	Yes	agreed	No
		S5‑187279	Rel-15 CR 32.156 Inconsistent definition of composition	Ericsson Limited	CR	Agreement	Yes	Yes	revised	No	S5‑187438
		S5‑187438	Rel-15 CR 32.156 Inconsistent definition of composition	Ericsson Limited	CR	Agreement	Yes	Yes	revised	No	S5‑187481	S5‑187279
		S5‑187287	Correct stage 3 description of the Provisioning Management Service	Nokia, Nokia Shanghai Bell	CR		Yes	YesThe document was merged with the Huawei CR to become S5-187357.	merged	No	S5‑187357
		S5‑187289	Update NRM IRP Solution Set to support slice priority	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	YesThis CR was linked to S5-177260 and '7370.	revised	No	S5‑187439
		S5‑187439	Update NRM IRP Solution Set to support slice priority	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No		S5‑187289
		S5‑187290	Update Stage 3 NRM for RRM Policy enhancements	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No
6.4	Rel-15 Operations, Administration, Maintenance and Provisioning (OAM&P)
6.4.1	Assurance data and Performance Management for 5G networks and network slicing	S5‑187126	pCR 28.550 Add solution for performance data streaming	Intel, BT	pCR	Approval	Yes	YesIntel stated that the contribution was supported by additional companies. Nanjing Ericsson Panda identified some editorial problem with the title of clause 6.1.a.2 and with the text of 6.2.a.2. If the stream was a channel, the data would be captured, and the wording needed clarification. Nokia liked the proposal but was concerned that the job control and measuremeent reporting were mixed. It appeared that redundant steps resulted (in, eg, 6.1.a.1. Triggering a job should trigger measurement, but streaming should not. Which entity was responsible for establishing the streaming channel, producer or consumer? (Answer: consumer.) Multiple streams going through the same channel was an unnecessary complication. Cisco wondered that, in view of contribution '7066, this contribution was somewhat similar. Intel denied this. Nokia agreed with Cisco. Huawei offered another solution for the job creation, with the provider creating theh connection to the consumer. Ericsson thought the overhead was reasonable, but might be further reduced further by a few bytes. Also, the text was ambiguous: what was the meaning of "reliable"? Greater reliability implied additional overhead: reliable = slow!	revised	No	S5‑187372
		S5‑187372	pCR 28.550 Add solution for performance data streaming	Intel, BT	pCR	Approval	Yes	Yes	approved	No		S5‑187126
		S5‑187162	Rel-15 CR TS 28.552 Add the performance measurement of MCS distribution	Huawei	CR	Agreement	No	Yes	withdrawn	Yes
		S5‑187163	Rel-15 CR TS 28.552 Add Qos flow related performance measurements	Huawei	CR	Agreement	No	Yes	withdrawn	Yes
		S5‑187164	Rel-15 CR TS 28.552 Correction of the Packet loss measuremets	Huawei	CR	Agreement	Yes	YesEricsson considered that the current measurement defined in the spec was valid for three split and two split scenarios. The propsoed change would support only a two split gNode-B, and this would not be acceptable to all vendors. Either a new measurement needed to be provided, or a measurement for both two and three split could be provided (bullet point f). ZTE thought UP functions neeeded to refer to the CU cell, and the Huawei position was acceptable. Intel considered the Ericsson point was good. In the absence of a model, there was no way to measure at the cell level.	revised	No	S5‑187373
		S5‑187373	Rel-15 CR TS 28.552 Correction of the Packet loss measuremets	Huawei	CR	Agreement	Yes	Yes	agreed	No		S5‑187164
		S5‑187165	Rel-15 CR TS 28.552 Add PDCP data volume measurements	Huawei	CR	Agreement	No	Yes	withdrawn	Yes
		S5‑187166	Rel-15 CR TS 28.554 Add KPI of QoS flow Retainability	Huawei	CR	Agreement	No	Yes	withdrawn	Yes
		S5‑187278	Presentation of TS 28.550 for approval	Intel, CMCC	TS or TR cover	Approval	Yes	YesThe mapping tables and one solution were missing from the spec, so there was some debate over whether the TS was stable enough for approval. There was also concern that the solution set was not implementable. Nokia was concerned that this was stage 2, but there was no sign of a stage 3 yet in Rel-15. The spec was thought to be 80% complete. But the Chairman noted that the the WI was already declared as 100% complete. But in fact SA#81 has downgraded it to 80%, and the work plan needed to be updated. No exception sheet was needed according to SA#81 decision.	revised	No	S5‑187523
		S5‑187523	Presentation of TS 28.550 for approval	Intel, CMCC	TS or TR cover	Approval	Yes	Yes	approved	No		S5‑187278
		S5‑187018	Minutes of Assurance data and Performance Management for 5G networks and network slicing	Rapporteur (Intel)	report		Yes	Yes	noted	No
		S5‑187548	TS 28.550 incorporating pCRs approved at SA5#122	Rapporteur: Yizhi Yao	draft TS	Approval	No	No	reserved	No
6.5	Rel-16 Operations, Administration, Maintenance and Provisioning (OAM&P)
6.5.1	Management of QoE measurement collection	S5‑187114	Revised WID on Management of QoE measurement collection	Ericsson	WID revised		Yes	Yes	agreed	No
		S5‑187115	pCR R16 28.405-030 Include QoE parameters	Ericsson	pCR	Approval	Yes	YesEditorial: the yellowed highlighting would be removed on implementation.	approved	No
		S5‑187117	pCR R16 28.405-030 Add forced deactivation	Ericsson	pCR	Approval	Yes	YesEditorial: the yellowed highlighting would be removed on implementation.	approved	No
		S5‑187118	pCR R16 28.405-030 Add X2 handover	Ericsson	pCR	Approval	Yes	YesEricsson stated that some comments had been received off line. The Chairman questioned the (unbulleted) indentations: what was the significance of the indentation? Ericsson stated that this was clear from the text. The Chairman advised that each option should be introduced, and the options numbered. Huawei questioned the title of the new clause. There was no X2 interface in 3G. Also, it was believed that the RAN specifications already contained such an indication (second paragraph) and so a reference would be needed. Ericsson agreed to check this.	not pursued	No	S5‑187374
		S5‑187374	pCR R16 28.405-030 Add X2 handover	Ericsson	pCR	Approval	No	Yes	withdrawn	Yes		S5‑187118
		S5‑187040	Resubmitted Reply LS from SA4 to SA5 on Attributes for QoE measurement collection	SA4	LS in		Yes	YesEricsson presented the document. There was a document on this topic in the QoS. However, the files in the zip file was wrongly numbered and the SA5 tdoc header was missing. The LS had been seen at an earlier meeting of SA5.	revised	No	S5‑187375
		S5‑187375	Resubmitted Reply LS from SA4 to SA5 on Attributes for QoE measurement collection	SA4	LS in	-	Yes	Yes	replied to	No		S5‑187040
		S5‑187376	Reply to: Resubmitted Reply LS from SA4 to SA5 on Attributes for QoE measurement collection	SA5	LS out	approval	Yes	Yes	revised	No	S5‑187524
		S5‑187524	Reply to: Resubmitted Reply LS from SA4 to SA5 on Attributes for QoE measurement collection	SA5	LS out	approval	Yes	Yes	approved	No		S5‑187376
		S5‑187119	pCR R16 28.405-030 Reporting collected data	Ericsson	pCR	Approval	Yes	Yes	withdrawn	Yes
		S5‑187019	Minutes of Management of QoE measurement collection	Rapporteur (Ericsson)	report		Yes	Yes	noted	No
		S5‑187547	TS 28.405 incorporating pCRs approved at SA5#122	Rapporteur: Robert Petersen	draft TS	Approval	No	No	reserved	No
6.5.2	Energy Efficiency of 5G	S5‑187122	pCR TS 28.310 – Management services	Orange	pCR	Approval	Yes	YesOne minor editorial error was detected ("steam" -> "stream", last row of table 4.2-1).	revised	No	S5‑187377
		S5‑187377	pCR TS 28.310 – Management services	Orange	pCR	Approval	Yes	Yes	approved	No		S5‑187122
		S5‑187123	pCR TS 28.310 – Use cases and requirements for DV measurement	Orange, Huawei	pCR	Approval	Yes	YesOrange and Nanjing Ericssonn Panda discussed the details of the new text at length. It was agreed that the subclauses sould start with "1" not "0".	revised	No	S5‑187378
		S5‑187378	pCR TS 28.310 – Use cases and requirements for DV measurement	Orange, Huawei	pCR	Approval	Yes	Yes	approved	No		S5‑187123
		S5‑187124	pCR TS 28.310 – Use cases and requirements for PEE measurement	Orange, Huawei	pCR	Approval	Yes	YesOrange observed that the requirements of PEE measurement control etc were only applicable to physical networks, further study was required for virtual networks. Nanjing Ericsson Panda wondered if existing use cases for the provisioning services covered PEE. Ericsson proposed an alternative approach for general use cases, and these could go into 5.4.5. The Chairman spotted a few editorials. It was agreed that the subclauses sould start with "1" not "0".	revised	No	S5‑187379
		S5‑187379	pCR TS 28.310 – Use cases and requirements for PEE measurement	Orange, Huawei	pCR	Approval	Yes	Yes	approved	No		S5‑187124
		S5‑187125	Discussion paper on SS Burst set periodicity in NG-RAN	Orange	discussion	Endorsement	Yes	YesNanjing Ericsson Panda noted that the text had been drafted in the form of a CR, but it was clarified that this was just for the sake of convenience, and it was not intended that this tdoc be considered as a real CR. Orange clarified that E-UTAN had no need for configuration of the sleep timer, but was a new feature of NG-RAN (advanced sleep mode). Nanjing Ericsson Panda wondered whether an LS to ITU might be needed if this solution were eventually accepted. Huawai had detailed comments to the parameters. Should these parameters be set using an on-the-fly approach? The RAN specification implied that just one parameter should be set during the cell setup phase. Orange agreed that this was possible, depending on operator policy. Maybe different values might be used for day time and night time. Maybe an LS to RAN was needed to determine whether a concrete CR would be needed. But Orange had already discussed this internally and believed the solution to be viable. It was questioned whether support of sSBurstSetPeriodicity might be CM rather than M. In the RAN spec, this was Optional, and there was a default value. The subject would be persued at the next meeting.	noted	No
		S5‑187020	Minutes of Energy effciency of 5G	Rapporteur (ORANGE)	report		Yes	Yes	noted	No
		S5‑187545	TS 28.310 incorporating pCRs approved at SA5#122	Rapporteur: Jean Michel Cornil\|y	draft TS	Approval	No	No	reserved	No
6.5.3	OAM aspects of LTE and WLAN integration	S5‑187131	CR Rel-16 28.658 Add WLANMobilitySet IOC	Intel China Ltd.	CR	Agreement	Yes	YesIt was noted that some elements of new text did not bear revision marks. Also the semantics of the condition needed to be defined. Nanjing Ericsson Panda was concerned about the definition of the new atrribuge and its provision. Ericsson noted tht the new figure related to eNode-B management functions. Intel disagreed, but this needed to be checked. Nokia noted that the type of the new attribute was "string", but its structure was rather complex: it was in fact a list of functions realing to the WLAN, and a simple string was a lazy way of defining it. It needed a new type definition. Also, what was the meaning of not applicable?	revised	No	S5‑187380
		S5‑187380	CR Rel-16 28.658 Add WLANMobilitySet IOC	Intel China Ltd.	CR	Agreement	Yes	YesEricsson proposed an editorial correction.	revised	No	S5‑187525	S5‑187131
		S5‑187525	CR Rel-16 28.658 Add WLANMobilitySet IOC	Intel China Ltd.	CR	Agreement	Yes	Yes	agreed	No		S5‑187380
		S5‑187132	CR Rel-16 28.659 Add WLANMobilitySet IOC	Intel China Ltd.	CR	Agreement	No	Yes	withdrawn	Yes
		S5‑187133	CR Rel-16 28.659 Add WLANMobilitySet IOC	Intel China Ltd.	CR	Agreement	Yes	YesNokia proposed a structural change. (Stage 2/3 alignments.)	revised	No	S5‑187381
		S5‑187381	CR Rel-16 28.659 Add WLANMobilitySet IOC	Intel China Ltd.	CR	Agreement	Yes	Yes	agreed	No		S5‑187133
		S5‑187134	CR Rel-16 32.425 Add measurements related to user data transmission on Xw interface for non-collocated LWA	Intel Corporation (UK) Ltd	CR	Agreement	Yes	YesNanjing Ericsson Panda and others proposed some editorial improvements.	revised	No	S5‑187382	S5‑186236
		S5‑187382	CR Rel-16 32.425 Add measurements related to user data transmission on Xw interface for non-collocated LWA	Intel Corporation (UK) Ltd	CR	Agreement	Yes	Yes	agreed	No		S5‑187134
		S5‑187135	CR Rel-16 32.425 Add measurements related to XwAP procedures for non-collocated LWA	Intel Corporation (UK) Ltd	CR	Agreement	Yes	YesNokia was concerned about the clause title - number of "attempted" WG configuration updates. What were the criteria for success or failure? Why was it necessary to count them? - the decision is performed by the eNode-B. Measurement 2 was difficult - this (counting messages received from the WT at the end point) was a wrong approach. Intel sought to jusify the approach they had taken. Nanjing Ericsson Panda had similar concerns to those of Nokia. Maybe an alarm was needed.Nokia believed a deeper review of the intentions and requirements was needed.	revised	No	S5‑187383	S5‑186238
		S5‑187383	CR Rel-16 32.425 Add measurements related to XwAP procedures for non-collocated LWA	Intel Corporation (UK) Ltd	CR	Agreement	No	Yes	withdrawn	Yes		S5‑187135
		S5‑187136	CR Rel-16 32.425 Add measurements related to RRC procedures for LWA	Intel China Ltd.	CR	Agreement	Yes	YesNokia questoned the measured object: was the measurement per set or per member of the set? Intel replied that it was per set. Nokia was satisfied by this. Nokia observed that this CR was one of a set, and it were necessary to agree all or none of them.	revised	No	S5‑187384
		S5‑187384	CR Rel-16 32.425 Add measurements related to RRC procedures for LWA	Intel China Ltd.	CR	Agreement	Yes	Yes	agreed	No		S5‑187136
		S5‑187021	Minutes of Study on OAM aspects of LTE and WLAN integration	Rapporteur (Ericsson)	report		Yes	Yes	noted	No
6.5.4	Network policy management for mobile networks based on NFV scenarios	S5‑187175	Add Policy management architecture	China Mobile	pCR	Approval	Yes	YesNokia questioned the meaning of NM and EM. How did this pertain to 5G architecture? China mobile indicated that the scope of this was only LTE. Orange noted that the ddraft 28.311 was clearly covering 5G. Cisco believed the NM / EM model was not applicable to virtualized architecture. Nanjing Ericsson Panda shared these concerns: were 3GPP requirements different from those specified by ETSI? The work item scope was for NFV. Orange did not consider that the figure was an NFV policy as suggested by the immediately preceding text. The interfaces [reference points] should be explicitly named. Ericsson did not consider this document to cover policy on NFV, rather it was a behavioural description. The document's scope was unclear. Deutsche Telekom was puzzled by the diagram and its title: no reference points were indicated. Nokia believed there was a lot of unclarity over the scope of the contribution. A few minor editorials were noticed. The secretary noticed that this document, and many other pCRs, gave no indication of which (draft) spec was concerned, and not even an indication of the work item concerned, which could only be inferred from the title of the agenda item. The Chairman agreed that this aspect could be improved and encouraged contributors to explicity mention the spec and, if necessary, the work item in the tdocs themselves..	revised	No	S5‑187385
		S5‑187385	Add Policy management architecture	China Mobile	pCR	Approval	Yes	Yes	approved	No		S5‑187175
		S5‑187174	Add Business level requirements	China Mobile	pCR	Approval	Yes	Yes[…] Cisco undersood that this document refered only to NFV policies, and this term should be used rather than the wider interpretation of "network" policies. In reference to the first element, Orange noted that the term OSS was not defined (although there was a definition in ETSI). There were several cases of unclear text. Deutsche Telekom struggled with requirement 3. What was the underlying use case? China Mobile agreed that this could be clarified. Some minor editorial metters were noticed.	revised	No	S5‑187386
		S5‑187386	Add Business level requirements	China Mobile	pCR	Approval	Yes	Yes	approved	No		S5‑187174
		S5‑187022	Minutes of Network policy management for mobile networks based on NFV scenarios	Rapporteur (China Mobile)	report		Yes	Yes	noted	No
		S5‑187546	TS 28.311 incorporating pCRs approved at SA5#122	Rapporteur: Hao Zhang	draft TS	Approval	No	No	reserved	No
6.5.5	Methodology for 5G management specifications	S5‑187068	TD YANG solution style guide	Ericsson Inc.	discussion	Endorsement	No	Yes	withdrawn	Yes
		S5‑187069	TD YANG solution style guide	Ericsson Inc.	discussion	Endorsement	Yes	Yes[It was noted that this was a late document.] Ericsson indicated that the document covered the modelling rules, but the wording in the contribution was not directly appropriate for inclusion in a TS. The need was to map the UML to the protocol. YANG was itself a modelling tool, and some discussion on the style guide was needed. Nokia had already made several pertinent points. Nokia wondered what was the document's relation to REST and JSON. Both of these had similar concepts, eg inheritance. Could these things be coupled fo make migration easier. YANG was not a long term solution. What were the filtering capabilities? Cf NetConf. Ericsson apologised for the late appearance, and urged delegates to examine clauses 6.2, 5.1.4 and 5.3.1.2: these were very important and needed to be reviewed in depth. In view of the late availability of the document, no final position could be reached at the present meeting. Delegates were urged to review it as requested by Ericsson and be prepared to discuss it at the next meeting. Discussion should start on the OEM email exploder.	noted	No
		S5‑187218	add rules for Stage 2 to YANG mapping in NRM	Nokia, Nokia Shanghai Bell	pCR	Agreement	Yes	YesNokia sought delegates' views on the form of the presentation in the tables. The document was more detailed than a similar one from Ericsson. It was clarified that this text was a new annex to the draft spec [which one?! - 32.160]. Ericsson questioned whether the first two lines of the table in A.X.2 were really necessary. The author indicated that "supper" was meant to indicate the parent (superior) class. The Chairman wondered whether the final TS would include both of the options, and Nokia clarified that this was the case. The Chairman proposed to remove the word enhancement, and this was agreed. Ericsson questioned the difference between rule and template.Further improvement of the Scope clause was needed, and maybe even the title of the spec itself. Would the spec also cover the protocols? In view of the title of the spec, which covered stages 2 and 3, then probably yes. Further wording changes were suggested.	revised	No	S5‑187387
		S5‑187387	add rules for Stage 2 to YANG mapping in NRM	Nokia, Nokia Shanghai Bell	pCR	Agreement	Yes	Yes	approved	No		S5‑187218
		S5‑187219	add rules for generic JSON and YANG NRM definition	Nokia, Nokia Shanghai Bell	pCR	Agreement	Yes	YesEricsson asked what was meant by "root". It was clarified that this could be a subnet. The title of A.x.1.1 was felt to be confusing: Generic or root IOC. One or the other should suffice. Nokia stated that this was the consequence of different terminology in use in IOC and YANG. The term "root" was preferred. It was further clarified that this was a pCR to 28.160 (generic guidelines) but if accepted, there would also need to be an inclusion in 28.623.	revised	No	S5‑187408
		S5‑187408	add rules for generic JSON and YANG NRM definition	Nokia, Nokia Shanghai Bell	pCR	Agreement	Yes	Yes	approved	No		S5‑187219
		S5‑187220	add modulization rules in YANG NRM definition	Nokia, Nokia Shanghai Bell	pCR	Agreement	Yes	YesHuawei was puzzled by the clause numbering. They were in fact just bullet points rather than clause titles. Ericsson wondered whether it was implied that the sequence of steps was important. Nokia replied that the order was not important. Text could be added to indicate this. Ericsson also believed there was confusion over classes and managed objects. There was further confusing terminology. Ericsson further believed that A.X.2 was not independent: the stage 3 author had to decide which object was intended. There was evidently confusion over what was meant by an "independent" managed object. In A.X.6, how was the date to be determined? This was the date of upload of the spec (the cover of the spec showed year and month).	revised	No	S5‑187409
		S5‑187409	add modulization rules in YANG NRM definition	Nokia, Nokia Shanghai Bell	pCR	Agreement	Yes	Yes	approved	No		S5‑187220
		S5‑187221	add rules for Stage 3 NRM packing and change tracking	Nokia, Nokia Shanghai Bell	pCR	Agreement	Yes	YesAn example could be found in S5-187245. Huawei was worried about inconsistency between two copies of the code. Nokia agreed that this needed to be decided. The session chairman believed that CT4 already had a solution to this question. Huawei sought clarification on the tool needed. ZTE had further questions on the identification of the version. Ericsson thought the check is just to check the implementation of the CR, but did not check the syntax of the overall code. Why could the tool not do this? Nokia explained that the changes would be made on the YANG file. But Ericsson considered that this was the responsibility of MCC. How was the checking to be done? The secretary described the method proposed by CT4. Nokia believed that the current methods were error-prone.	noted	No
		S5‑187253	pCR 32.160 Insert guidelines and examples in NRM template	Ericsson Limited	pCR	Approval	Yes	YesNokia asked why 4.1.2 needed the new entity. Ericsson replied that the information had been taken from the existing specifications, or rather the template. Intel agreed with Ericsson's explanation. Nokia proposed to make an abbreviation for "support qualifier". This would make the table layout much more elegant (and indeed had already used it in some contributions). Ericsson thought this would need a separate contribution for the template and this would be a major revision to introduce everywhere. Huawei referred to the attributes, questioning how the table could fulfill all requirements of all different users. Ericsson was concerned that there was a danger of introducing untestable requirements into the stage 3. A standardized mechanism was needed. The secretary noticed that the verb "can" appeared in many places.	revised	No	S5‑187411
		S5‑187411	pCR 32.160 Insert guidelines and examples in NRM template	Ericsson Limited	pCR	Approval	Yes	Yes	approved	No		S5‑187253
		S5‑187255	pCR 32.160 Add stage 1 template	Ericsson Limited	pCR	Approval	Yes	YesEricsson pointed out the optionality offered by the last sentencew of the first paragraph of 4.1.	approved	No
		S5‑187256	pCR 32.160 Insert guidelines and examples in template for operations and notifications	Ericsson Limited	pCR	Approval	Yes	YesThere was some confusion over what had been agreed at the previous meeting concerning precondition and postcondition. Nokia wished to remove the old CORBA concept of exceptions. Ericsson defended their retention. Nokia preferred "error", but the concept needed to be retained.	revised	No	S5‑187412
		S5‑187412	pCR 32.160 Insert guidelines and examples in template for operations and notifications	Ericsson Limited	pCR	Approval	Yes	Yes	approved	No		S5‑187256
		S5‑187280	Rel-16 CR 32.156 Make the use of association roles optional	Ericsson Limited	CR	Agreement	Yes	Yes	agreed	No	S5‑187476
		S5‑187476	Rel-16 CR 32.156 Make the use of association roles optional	Ericsson Limited	CR	Agreement	No	Yes	withdrawn	Yes		S5‑187280
		S5‑187480	Rel-16 CR 28.531 Implement minor corrections	Ericsson Limited	CR	Agreement	Yes	Yes	agreed	No		S5‑187437
		S5‑187481	Rel-16 CR 32.156 Inconsistent definition of composition	Ericsson Limited	CR	Agreement	Yes	Yes	agreed	No		S5‑187438
		S5‑187281	Rel-16 CR 32.156 Make the use of the visibility symbol optional	Ericsson Limited	CR	Agreement	Yes	Yes	agreed	No	S5‑187477
		S5‑187477	Rel-16 CR 32.156 Make the use of the visibility symbol optional	Ericsson Limited	CR	Agreement	No	Yes	withdrawn	Yes		S5‑187281
		S5‑187295	Presentation of TS 32.160 to SA for information	Ericsson LM	TS or TR cover	Approval	Yes	YesIt was hoped that following the present meeting, the document would be sufficiently mature to present to TSG for information.	approved	No
		S5‑187023	Minutes of Methodology for 5G management specifications	Rapporteur (Ericsson)	report		Yes	Yes	noted	No
		S5‑187555	TS 32.160 incorporating pCRs approved at SA5#122	Rapporteur: Jan Groenendijk	draft TS	Approval	No	No	reserved	No
6.5.6	Intent driven management service for mobile networks	S5‑187155	pCR 28.812 Add concept for utilization of intent	Huawei	pCR	Approval	Yes	YesCisco asked how the figure would be standardized. Huawei replied that the intent was to standardize the intent. First it was necessary to recognize the scenarios. Cisco believed it was very complex to formulate such language. Intel believed that the figure represented a typical service. Huawei gave the example of handling five million smart meters. Orange believed the concept of intent was useful when two communicating entitiies did not have the same level of knowledge, for example rows in 28.530. Nokia agreed. The present document was not aligned with 28.530. The document did not discuss the level of detail of communication. He believed the text was lacking in substance. Huawei understood the problem but had difficulty in expressing the intentions in appropriate language. Ericsson thought some of the language was too vague, and repeated the arguments he had offered at the previous meeting. The scope of the TR was very wide. The scope of "intent" should be limited to avoid ambiguity. Deutsche Telekom wished to know if there was a definition of "communication service" and management of same. The study TR was as yet only a skeleton. Huawei understood that the last paragraph implied that one network could be consumer of information provided by another. This gave a very detailed intent.	revised	No	S5‑187413
		S5‑187413	pCR 28.812 Add concept for utilization of intent	Huawei	pCR	Approval	Yes	Yes	approved	No		S5‑187155
		S5‑187156	pCR 28.812 Update the figures for area cell load balance and cell rehome scenario	Huawei	pCR	Approval	Yes	YesThe only change was the replacement of the figure. NEC thought there was an assumption that all the mechanisms in the network would be triggered by the intent. But these mechanisms are run in the network to optimize performance. Maybe the use cases could be more explicit to avoid this confusion. Huawei sought to clarify the meaning. Nokia thought that things like ANR standardized many years ago, but it seemed from this text that these mechanisms no longer worked and needed to be replaced by "intent". Nokia believed that this contribution was re-inventing the wheel. Legacy products already did what was being described here. Huawei stated that the document only provided examples. Cisco was concerned with the whole approach which was difficult to use in practice: how could network optimization be expressed in terms of intent? Optimization was extremely complex, and had to balance multiple conflicting targets. Compromise and trade-off would always be needed. Orange agreed. There was no need for the concept of "intent". Ericsson proposed to add a note to distinguish this new approach from traditional SON. Was intent-based specification a higher level concept compared to the traditional approach. But there was nothing new here unless there was a mechanism to automatically translate natural language into operational rules. The proposed note would indicate that the distinction was FFS. Huawei cited the example of roaming, and how this was currently handled. Ericsson replied that of course roaming was already adequately handled by existing methods. Intel thought that there might be cases where target setting could be viewed as "intent". If no solution as to how "intent" was to be realized was offered, there was limited value in the Huawei proposal. Huawei stated that the intention was not to replace existing mechanisms by "intent", it was just a better way to express goals. Ericsson supported the inclusion of the note mentioned above if it could be very concrete. But there was little interest in standardizing this concept. For each well-known use case there was no interest in intent. Huawei believed their approach would simplify use cases by providing a generic approach. Ericsson still believed this was a solution looking for a problem.	revised	No	S5‑187414
		S5‑187414	pCR 28.812 Update the figures for area cell load balance and cell rehome scenario	Huawei	pCR	Approval	Yes	Yes	approved	No		S5‑187156
		S5‑187157	pCR 28.812 Add intent driven instant cell deletion scenario	Huawei	pCR	Approval	Yes	YesHuawei noted that the remarks made on '7156 would apply to this one.	revised	No	S5‑187415
		S5‑187415	pCR 28.812 Add intent driven instant cell deletion scenario	Huawei	pCR	Approval	Yes	Yes	approved	No		S5‑187157
		S5‑187158	pCR 28.812 Add intent driven network optimization scenario	Huawei	pCR	Approval	Yes	YesEricsson thought the previous tdoc's comments also applied here. The content of the document looked very much like SON and should be part of that study rather than this one. How did "intent" SON differ from traditional SON? Intel shared these concerns. Orange thought that in this case, perhaps it was human driven rather than automated. The consumer was a human.	revised	No	S5‑187416
		S5‑187416	pCR 28.812 Add intent driven network optimization scenario	Huawei	pCR	Approval	Yes	Yes	approved	No		S5‑187158
		S5‑187160	pCR 28.812 Update network provisioning scenario	Huawei	pCR	Approval	Yes	YesNokia questioned that GSMA NEST had done all the work and 3GPP just had to rubber-stamp it? Huawei said no, because NEST had not yet been successful in having their ideas widely adopted. Nokia preferred to rely on traditional SA1 requirements. It was not useful to use the GSMA example in the document. Orange proposed to use the same role names as used in 28.520. Intel questioned the meaning of the existing wording at the end of 5.1.2.	revised	No	S5‑187417
		S5‑187417	pCR 28.812 Update network provisioning scenario	Huawei	pCR	Approval	Yes	Yes	approved	No		S5‑187160
		S5‑187167	pCR 28.812 NSI resource utilization optimization	Huawei Tech.(UK) Co., Ltd	pCR	Approval	Yes	YesNokia wondered how this differed from SON configuration. There was no need for "intent". Huawei replied that this was a higher level than SON. This was a concern to Nokia: SON was not "legacy" technology, it was still applicable to 5G, and counld be considered atboth high and low levels. Huawei stated that there was no intention to make SON obsolete. This wold enable the network provider to optimize services, but the exact means of doing so was not yet specified. Huawei wished to concentrate on the meaing of "intent" but not go into fine details at this stage. It could be used to define a himan interface. Cisco had encountered the view that this sort of functionality could be standardized, but believed that this was not so due to the complexity and the number of parameters and trade offs to be resolved. Even the definition of terms ws difficult to standardize from one network provider or vendor to another. For example what did the intention "optimize network utilization" imply? Huawei understood the problem of complexity. The precondition was an attempt to limit the scope of the problem. Deutsche Telekom wished to understand what was the target. Was it a question of refinement of high level desires?	revised	No	S5‑187418
		S5‑187418	pCR 28.812 NSI resource utilization optimization	Huawei Tech.(UK) Co., Ltd	pCR	Approval	Yes	Yes	approved	No		S5‑187167
		S5‑187178	pCR 28.812 Add introduction for Intent Expression	Huawei Tech.(UK) Co., Ltd	pCR	Approval	Yes	YesNokia did not believe that this was a good example of an intent. The intent would be better expressed as "ensure telecommunications along highway 417 between points X and Y". ZTE thought an operator needed to have an intention to provide any service. Everything was an intent! Huawei thought that was too narrow an interpretation. Ericsson asked if the intent expression was to be standardized. If not, it was not at all clear what the topic intended. Huawei stated that this was explained by the second sentence in the first paragraph. Ericsson disagreed: what was the standardized language? Huawei recalled that the goal of standardizing expression was mentioned in the scope of the TR. Cisco understood that clause 4.1.2 intended to provide a solution in terms of a standardized language and syntax. Also, the example given was good insofar as it was incomplete. It should also describe the potential compromises in terms of, for example, QoS in the case where adequate network resources were not available. Huawei agreed on the complexity issue, but here was just an example of what information might be included in the intent. There was no plan to include semantics or syntax at this point. Deutsche Telekom proposed a top down approach, and the example was just that, only an example. But the target was not well expressed. What was it intended to standardize at the end of the day? It was only possible to standardize input and output. NEC believed that the idea here was to translate from high level language to low level language. But was it the intention to provide some algorithm to carry out this operation? Huawei stated that the translation part would not be standardized. How the translation was performed (eg to the configuration of a cell) was not within the scope of the TR.	revised	No	S5‑187419
		S5‑187419	pCR 28.812 Add introduction for Intent Expression	Huawei Tech.(UK) Co., Ltd	pCR	Approval	Yes	YesEricsson proposed some clarification of the text.	revised	No	S5‑187526	S5‑187178
		S5‑187526	pCR 28.812 Add introduction for Intent Expression	Huawei Tech.(UK) Co., Ltd	pCR	Approval	Yes	Yes	approved	No		S5‑187419
		S5‑187024	Minutes of Intent driven management service for mobile networks	Rapporteur (Huawei)	report		Yes	Yes	noted	No
		S5‑187552	TR 28.812 incorporating pCRs approved at SA5#122	Rapporteur: Lan Zou	draft TR	Approval	No	No	reserved	No
6.5.7	Enhancement of performance assurance for 5G networks including network slicing	S5‑187048	R16 CR 28.552 Add CQI measurements	ZTE Wistron Telecom AB	CR	Agreement	Yes	YesHuawei had a related contribution. Meanwhile, why was it necessary to differentiate non-PMI and PMI? Also why were the one-port and multiple-port cases distinguished? For information, China Mobile made the CQI calculation in both PMI and non-PMI modes. Ericsson wondered who was the receiver of this informoation. Ericsson also agreed with Huawei on the PMI separation question. Cisco believed that there was no definition of PMI or non-PMI mode, but the reason for change on this CR was helpful and might usefully be included in the text of the TS. ZTE agreed with this idea, bearing in mind the requirement of China Mobile.	revised	No	S5‑187440
		S5‑187440	R16 CR 28.552 Add CQI measurements	ZTE Wistron Telecom AB	CR	Agreement	Yes	Yes	not pursued	No		S5‑187048
		S5‑187049	R16 CR 28.552 Add RSRP measurements	ZTE Wistron Telecom AB	CR	Agreement	Yes	YesCisco wondered how the bins could be configured. ZTE said that the answer could be found in TS 38.214, but the solution was vendor-dependent. Intel agreed that there was no standardized solution. However, Ericsson stated that RAN had no measurement for NRCellDU.Beam. Huawei thought that the overall coverage measurements could not use this parameter (which was needed for handover). ZTE thought that coverage was used not only for handover, but for general statistics gathering such as coverage quality. Ericsson agreed.	revised	No	S5‑187442
		S5‑187442	R16 CR 28.552 Add RSRP measurements	ZTE Wistron Telecom AB	CR	Agreement	Yes	Yes	postponed	No		S5‑187049
		S5‑187050	R16 CR 28.552 Add Flow Setup measurements	ZTE Wistron Telecom AB	CR	Agreement	Yes	YesHuawei had a similar document in S5-187209, and ZTE document S5-187051 was also related. Merged to S5-187443.	merged	No
		S5‑187051	R16 CR 28.552 Add Flow release measurements	ZTE Wistron Telecom AB	CR	Agreement	Yes	YesMerged to S5-187443.	merged	No
		S5‑187209	Rel-16 CR TS 28.552 Add Qos flow related performance measurements	Huawei	CR	Agreement	Yes	YesThis document was considered with SP-187050 & '7051 from ZTE. Cisco wondered if there were definitions of bursty and continuous flow. Ericsson agreed with the idea to merge this with the two ZTE CRs, using remote mapped only. Ericsson also wanted subcounters in all cases. It was also noted that the E1 protocol (related to flow activity) was not yet available from RAN. Intel had a question on QCI, was this to support option 3? The NR cell CU could not be used here. Merged to S5-187443.	merged	No
		S5‑187443	QoS flow related measurements	Huawei, ZTE, Ericsson	other	Approval	Yes	Yes	approved	No
		S5‑187052	R16 CR 28.552 Add MCS Distribution measurements	ZTE Wistron Telecom AB	CR	Agreement	Yes	YesHuawei noticed that rank had not been considered, and this could have an impact on the outcome. The CQI case was similar. Huawei feared this would cost a lot of memory. Huawei also had a congribution on MCS distribution. Ericsson noticed that there was a similar measurement in S5-187208. Meanwhile it was noted that in pont I there was no family or group. Intel wished to see a reference to the stack. Nokia proposed an editorial modification.	revised	No	S5‑187491
		S5‑187491	R16 CR 28.552 Add MCS Distribution measurements	ZTE, Huawei	CR	Agreement	Yes	YesThe combination of the ZTE and Huawei contributions needed further refinement.	postponed	No		S5‑187052
		S5‑187208	Rel-16 CR TS 28.552 Add the performance measurement of MCS distribution	Huawei	CR	Agreement	Yes	YesThis CR was considered alongside that in S5-187052. ZTE believed it would be difficult to merge the two. Huawei believed statistics on only one dimension as proposed by ZTE was not workable. Intel could support either two separate counters or a combination of the two. Ericsson believed that one counter was preferable. Huawei preferred separate counters as being clearer. ZTE and Huawei could not agree on the better approach. Cisco stated that in 5G there could be simultaneous transmission based on different tables, and the Huawei contribution assumed always one table. Concerning the ove vs two dimention question, it should be possible to use the same index, thus solving the problem of dimentions. Huawei stated that for the three tables of their contribution, this would not be possible. ZTE believed merging was not possible, separate tables and indexes were needed. The document was merged into S5-187491.	merged	No	S5‑187491
		S5‑187459	Rel-16 CR TS 28.552 Add the performance measurement of MCS distribution	Huawei	CR	Agreement	No	Yes	withdrawn	Yes		S5‑187208
		S5‑187053	R16 CR 28.552 Add TB related measurements	ZTE Wistron Telecom AB	CR	Agreement	Yes	YesHuawei asked why 16- and 64-QAM counters were not considered. Also, in clause 5.1.1.X.3 , how would this work? What was the difference between 5.1.1.X.4 and the X.file. ZTE believed that MU-MIMO would need a lot of layers. Ericsson point d of 5.1.1.X.4 should indicate a set of integer values rather than a single one. In 5.1.1.X.5 the existing layer could not handle the transmission properly. It was not clear. For the uplink cases eg clause 5.1.1.X.8, was SU-MIMO excluded? ZTE explaned the situation for residential TBs. Intel wondered wihether the sub value should need a sepaate counter. ZTE referred to point g of 5.1.1.X.8 .	revised	No	S5‑187444
		S5‑187444	R16 CR 28.552 Add TB related measurements	ZTE Wistron Telecom AB	CR	Agreement	Yes	Yes	agreed	No		S5‑187053
		S5‑187054	R16 CR 28.552 Add RLC data volume measurements	ZTE Wistron Telecom AB	CR	Agreement	Yes	YesIntel agreed that measuring the data volume was useful. But for 5G, the protocol level needed to be considered. ZTE responded that different core network configurations could be expected, so the highest layer had been chosen to be common across all networks. Huawey had similar comments to that on the previous document. For example, point e of 5.1.1.X.1 was not implementable, it was difficult to see how the calculation could be performed. RLC level was not necessary, and for PDPC splitting, Huawei proposed a different approach. ZTE explained their approach in detail. Ericsson, at a previous meeting SA5 had asked RAN2 to define such measurements, so it was up to RAN2. The proposed measurement was not possible in a dual bearer configuration.There was a Huawei contribution on this in S5-187210. Orange wondered which criteria allowed measurement to be defined by RAN2 as opposed to SA5. Ericsson suggested that radio parameters were the province of RAN2. Intel said that the LTE approach was to distinguish between MAC layer and layer 2. But for LTE RRC there was no need to consult RAN2. Ericsson recalled that there was a long-standing agreement along these lines. RAN2 should detail the measurements in their own specs. Orange had noted that the LS which SA5 had sent to RAN2 had simply been noted and not taken any action. Ericsson indicated that RAN2 had been too busy to do this, so had allowed SA5 to do it.	revised	No	S5‑187445
		S5‑187445	R16 CR 28.552 Add RLC data volume measurements	ZTE Wistron Telecom AB	CR	Agreement	Yes	Yes	postponed	No		S5‑187054
		S5‑187055	R16 CR 28.552 Add PDCP data volume measurements	ZTE Wistron Telecom AB	CR	Agreement	Yes	YesHuawei's comments on the previouis document applied here. The solution might not be implementable. Ericsson agreed. SA5 should wait for a response from RAN2. Meanwhile, the data volume was defined by cell so was applicable only to two-split measurements, and this was not appropriate. But this could be solved. Cisco noted that the contribution refered of bits, but the management objects, whereas the data transfer was in fact between GNDU and GNCU. Intel believed that the comment from Ericsson was very important. It would then be possible to perform measurements down to cell level. The model should support this. Huawei suggested to examine the use case, using the LTE method. RAN2 should be consulted. Intel recalled that RAN2 was only consulted on layer 2 matters. Layer1 and layer 3 could be done by SA2. It seemed necessary to arrive at an agreed principle. Ericsson suggested toing back to the wording of the original ageement. Finally it was agreed to merge S5-187055 and '7210.	merged	No	S5‑187456
		S5‑187210	Rel-16 CR TS 28.552 Add PDCP data volume measurements	Huawei	CR	Agreement	Yes	YesZTE believed the CR mixed different concepts. Huawei insisted that their approach was valid. Ericsson preferred the Huawei approach. It might be desirable to merge this contribution with S5-187055. ZTE and Huawei could not agree with each other on the better way forward. Cisco believed that a merger was possible if the meeting concentrated on the common elements, with a view to extension in the future. Finally it was agreed to merge S5-187055 and '7210.	merged	No	S5‑187456
		S5‑187456	R16 CR 28.552 Add PDCP data volume measurements	Huawei, ZTE Wistron Telecom AB	CR	Agreement	Yes	Yes	agreed	No		S5‑187055
		S5‑187056	R16 CR 28.552 Add PDCP throughput measurements	ZTE Wistron Telecom AB	CR	Agreement	Yes	YesEricsson believed RAN2 should look into this with a view to improving it. Intel and Huawei agreed. This should be included in the LS to RAN2.	noted	No
		S5‑187057	R16 CR 28.552 Add TA related measurements	ZTE Wistron Telecom AB	CR	Agreement	Yes	YesEricsson believed this CR was premature because the measurement had not yet been defined. Intel thought there was a possible way forward. Huawei feared the contents of the measurements might be too large and this might be an issue for operators. Some disagreement remained at the end of a discussion on this point. Cisco believed it would be able to judge how many mobiles were close to / far from the base station, and this was an important measurement. Ericsson observed that the place where one measured could also be useful. Huawei referred to the LTE case, where the statistics were based on the cell.	revised	No	S5‑187457
		S5‑187457	R16 CR 28.552 Add TA related measurements	ZTE Wistron Telecom AB	CR	Agreement	Yes	Yes	postponed	No		S5‑187057
		S5‑187071	DP on PM terms for NSI and NSSI	Cisco Systems Inc.	discussion	Discussion	Yes	YesThe discusson paper was by way of justification for S5-187070. Intel wondered whether the new term NPI wholey replaced KPIs. Cisco replied that this was not the intention. Ericsson believed the original "confusion" over "KP"I and "measurement" was really just editorial. Was a new term really necessary, could not the objective be met by redefining the term KPI? Cisco stressed that different terms were needed for different concepts. End to end measurements were quite different from measurements made at a given point. It was important to avoid confusion over terminology. China Mobile wished for examples of different measureemtns. End to end KPIs were a different kettle of fish. Cisco that this only emphasised the need for well understood terms to be used. Huawei's main comment was that for the subnetwork and slice, new terms might be needed. The difference between performance measurements and KPIs was not always evident, and sometimes were used interchangeably. This was obviously wrong: KPIs were "key" whereas not all sundry measurements couls be so described. But maybe the new NPIs concept was in fact equivalent to KPIs. Cisco partially agreed, but noted that some KPIs comprised combinations of several measurments.	noted	No
		S5‑187070	PM terms for NSI and NSSI	Cisco Systems Belgium	CR	Agreement	Yes	YesNokia gave some detailed feedback and wondered whether there was really a need for the new term NPI. This could lead to some simplification of the text. Cisco feared over simplification, and was adamant that an agreed vocabulary was needed. Intel understood that performance indicators might be an aggregate of measurements. Intel clamed that it was possible to have a generic definition: it was necessary to clearly indicate the trigger and how the aggregation was performed. Huawei supported the idea, but some more discussion on NPI was needed. Text could be taken from the preceding discussion paper. Huawei was against the simplification of the initial text proposed by Nokia. Nokia agreed that it would be good to update the template to provide examples of different types of performance indicator.	revised	No	S5‑187458
		S5‑187458	PM terms for NSI and NSSI	Cisco Systems Belgium	CR	Agreement	Yes	Yes	agreed	No		S5‑187070
		S5‑187127	CR Rel-16 28.552 Add PDU Session Modification related measurements for SMF	Intel China Ltd.	CR	Agreement	Yes	YesEricsson thought there were too many use cases in the CR, some of which were rather similar. Intel explained that there were UE-initiated and SMF-initiated tests since performance could differ between these. Also there were measures of success and failure for each parameter. Ericsson questioned whether all use cases were really QoS related.	revised	No	S5‑187474
		S5‑187474	CR Rel-16 28.552 Add PDU Session Modification related measurements for SMF	Intel China Ltd.	CR	Agreement	Yes	Yes	agreed	No		S5‑187127
		S5‑187128	CR Rel-16 28.552 Add PDU Session Release related measurements for SMF	Intel China Ltd.	CR	Agreement	Yes	YesIn this case, only release requests initiated by the AMF were thought useful to measure. Ericsson had detaled remarks to be discussed off line.	revised	No	S5‑187475
		S5‑187475	CR Rel-16 28.552 Add PDU Session Release related measurements for SMF	Intel China Ltd.	CR	Agreement	Yes	Yes	agreed	No		S5‑187128
		S5‑187129	CR Rel-16 28.552 Add N4 Session Establishment related measurements for UPF	Intel China Ltd.	CR	Agreement	Yes	Yes	agreed	No
		S5‑187130	CR Rel-16 28.552 Add NF performance measurements related to VR	Intel China Ltd.	CR	Agreement	Yes	YesNokia observed that the measurements were at the function level, but there was not a 1:1 mapping to VRs. Intel had considered ths point, and the derivation algorithm was vendor-specific. Nokia believed the detail in the CR limited an implementor's algorithm. And ultimately, what use would an operator make of these measurements? ZTE thought that it was necesasry to differentiate the core network and network functions. Intel disagreed. Ericsson recalled discussions that had taken place on virtualization. If the measurements were to be split into all the different functions, MANO would provide values, but some software would be necessary in user applications. How should the vendor-specific combinations be achieved? Intel replied that the producer knew how to do this. Ericsson thought that the overal VNF operation was of interest, not the individual parameters.	revised	No	S5‑187460
		S5‑187460	CR Rel-16 28.552 Add NF performance measurements related to VR	Intel China Ltd.	CR	Agreement	Yes	Yes	agreed	No		S5‑187130
		S5‑187161	Rel-16 CR TS 28.552 Add the performance measurement of CQI distribution	Huawei	CR	Agreement	No	Yes	withdrawn	Yes
		S5‑187202	Rel-16 CR TS 28.552 Add the performance measurement of CQI distribution	Huawei	CR	Agreement	No	Yes	withdrawn	Yes
		S5‑187203	Rel-16 CR TS 28.552 Add the performance measurement of MCS distribution	Huawei	CR	Agreement	No	Yes	withdrawn	Yes
		S5‑187204	Rel-16 CR TS 28.552 Add Qos flow related performance measurements	Huawei	CR	Agreement	No	Yes	withdrawn	Yes
		S5‑187205	Rel-16 CR TS 28.552 Add PDCP data volume measurements	Huawei	CR	Agreement	No	Yes	withdrawn	Yes
		S5‑187206	Rel-16 CR TS 28.554 Add KPI of QoS flow Retainability	Huawei	CR	Agreement	No	Yes	withdrawn	Yes
		S5‑187207	Rel-16 CR TS 28.552 Add the performance measurement of CQI distribution	Huawei	CR	Agreement	Yes	YesThis CR was discussed in conjunction with that in S5-187048. ZTE believed that the measurements were different. The result would vary according to the different resources used. Ericsson thought the spectral efficiency information was not clear. The two CRs were not equivalent. SA5 had not much discussed beamforming, and it was perhaps premature to discuss that at this point. Cisco noted that which table should be used depending on the configuration, but the exact choice was not clear. Huawei agreed that the text was a little confusing and sought to clarify.	revised	No	S5‑187441
		S5‑187441	Rel-16 CR TS 28.552 Add the performance measurement of CQI distribution	Huawei	CR	Agreement	Yes	Yes	not pursued	No		S5‑187207
		S5‑187211	Rel-16 CR TS 28.554 Add KPI of QoS flow Retainability	Huawei	CR	Agreement	Yes	YesZTE believed the active number could not yet be calculated, and Huawei agreed. Ericsson agreed it would be necessary to wait until the measurements had been defined, but this KPI would be very useful for operators. Intel suggested a an editorial improvement. Nokia thought point d read like a discussion paper. The methodoloty of the template had not been followed, and there would seem to be a choice of methods here. The CR would be readdressed at the next meeting.	postponed	No
		S5‑187212	Draft LS on the slicing terminology and the role of S-NSSAI parameter	SA5 (Cisco Systems Belgium)	LS out	Approval	Yes	YesNokia concluded that within RAN space or core space, there could be multiple instances of NSSI. It would be better to ask this question directly. The difference between a slice and a slice instance was cosmetic. The question posed in the LS was not clear. Intel described their understanding of selecting a slice instance. A long discusson on the semantics ensued.	revised	No	S5‑187461
		S5‑187461	Draft LS on the slicing terminology and the role of S-NSSAI parameter	SA5 (Cisco Systems Belgium)	LS out	Approval	Yes	Yes	approved	No		S5‑187212
		S5‑187222	CR Rel-15 28.552 Add DRB setup related measurements and UC for gNB	Ericsson GmbH, Eurolab	CR	Agreement	Yes	YesIntel thought point c would be better served using the air interface, requesting the UE to set up the DRB. Ericsson was not sure this would be possible. Cisco thought this impled two different counters. A lenggthy discussion ensued. QoA and DRB measurements were in some way similar, but Ericsson prefered DRB. Both were required, and this would not represent an excessively large number of couonters.	revised	No	S5‑187462
		S5‑187462	CR Rel-15 28.552 Add DRB setup related measurements and UC for gNB	Ericsson GmbH, Eurolab	CR	Agreement	Yes	Yes	agreed	No		S5‑187222
		S5‑187223	CR R-15 28.554 Add DRB Accessibility KPI and Use Case	Ericsson GmbH, Eurolab	draftCR	Approval	Yes	YesThi intention was to complete this draft at the next meeting. Two of the missing measurements should have been submitted by the time of the next meeting. Intel asked whether sufficient connections had been available. Ericsson said no, this would be establshed earlier. Huawei believed all related CRs should be approved as a package, not individually. Some further clarifications were also needed.	noted	No
		S5‑187025	Minutes of Enhancement of performance assurance for 5G networks including network slicing	Rapporteur (Intel)	report		Yes	YesIntel thought a downward revision of the completion level was needed.	noted	No
6.5.8	Management service discovery in 5G network management (Preliminary work before SA approval)	S5‑187176	Rel-16 draftCR TS 28.531 Add usecase and requirements for MnS Registration	Huawei	draftCR	Approval	Yes	YesEricsson did not understand the relationship between this use case and Release 15. There seemed to be a different solution from that of Rel-15. Huawei explained that this had been discussed at the previous meeting. Nokia was confused by the post-conditions.The implication was that both services had to be produced by the same entity, and this was faulty logic. The granularity of services needed to be considered. Huawei suggested to replace "service" with "managemnt capability" to address this problem. The CR was replaced by that in S5-187463.	not pursued	No	S5‑187463
		S5‑187463	Rel-16 draftCR TS 28.533 Add usecase and requirements for MnS Registration	Huawei	draftCR	Approval	Yes	YesNokia objected to this contribution stating that this was not required and was poluting the TS with useless use cases. NEC and Huawei supported the draft CR. Intel agreed with Nokia. Huawei wished to establish the correct technical requirements, but a second step was into which spec to put it. Maybe a new TS was implied. In the end, it was proposed to update 28.531 instead of 28.533.	revised	No	S5‑187530	S5‑187176
		S5‑187530	Rel-16 draftCR TS 28.533 Add usecase and requirements for MnS Registration	Huawei	draftCR	Approval	Yes	Yes	approved	No		S5‑187463
		S5‑187195	Rel-16 DraftCR Update scope of TS 28.xxx	Huawei Telecommunication India	draftCR	Approval	Yes	YesNokia did not believe this change was necessary. No extension of the scope was needed. It was suggested to put such a change into 28.530 or 28.533. The clauses affected box needed correction. The document was replaced by S5-187464.	not pursued	No
		S5‑187196	Rel-16 DraftCR Add general information for discovery of MnS	Huawei Telecommunication India	draftCR	Approval	Yes	Yes[Claimed WI code = "5GMSD"] Nokia believed the change was misplaced. Cisco believed that discovery would yield the answer none, one, or some other number. The requester did not know how many responses would result. Ericsson believed that the request had to be specific, but use of the MnS provider was not appropriate: better would be to use the name of the service. NEC agreed that this was very basic, but it was really needed. Perhaps too much information was trying to be put into this one clause.	not pursued	No	S5‑187464
		S5‑187464	Rel-16 DraftCR Add general information for discovery of MnS	Huawei Telecommunication India	draftCR	Approval	Yes	Yes[Claimed WI code = "5GMSD"]	approved	No		S5‑187196
		S5‑187197	Revised WID on management service discovery in 5G network management	Huawei Telecommunication India	WID new	Approval	Yes	YesMinor typos were noted.	revised	No	S5‑187465
		S5‑187465	Revised WID on management service discovery in 5G network management	Huawei Telecommunication India	WID new	Approval	Yes	Yes	agreed	No		S5‑187197
		S5‑187291	Minutes of Management service discovery in 5G networks	Huawei	report		Yes	YesThis new WI was declared to be 10% complete.	noted	No
6.5.9	NRM enhancements (Preliminary work before SA approval)	S5‑187292	Minutes of NRM enhancements	Rapporteur (Nokia)	report		No	Yes	withdrawn	Yes
6.6	OAM&P Studies
6.6.1	Study on system and functional aspects of Energy Efficiency in 5G networks	S5‑187121	Presentation of TR 32.972 to SA for Approval	Orange	TS or TR cover	Approval	Yes	Yes	approved	No
		S5‑187026	Minutes for Study on system and functional aspects of Energy Efficiency in 5G networks	Rapporteur (ORANGE)	report		Yes	Yes	noted	No
6.6.2	Study on integration of ONAP DCAE and 3GPP management architecture	S5‑187159	pCR 28.900 Add example of 3GPP MnS Provider using interfaces provided by ONAP DCAE	Huawei	pCR	Approval	Yes	YesNanjing Ericsson Panda was not sure that ONAP DCAE had in fact provided an interface. Had this proposal been considered by RAN3? Nokia believed that ONAP did indeed provide services, and the interface was well documented. But did SA5 wish to edorse it. Further, concerning the data flow, DCAD supported plug-ins. Did 3GPP wish to endorse DNAP? Huawei wondered if other interfaces might be available. Nokia believed that the figure was disconnected from the text. Huawei responded that the change was still under development, and not everything had yet been decided. Nokia reported that the example interfaces did not in fact exist. Orange had similar comments. The figure was very general. Was it the intention to add this figure to the ONAP definition? DCAE interfaces were internal to ONAP, but once they were exposed to the outside, they became accessible. All ONAP components should be present. Nanjing Ericsson Panda thought a global picture would be needed, how to provide data to the outside. Cisco did not think the text agreed with the figure. The MDAS provider's services were not shown. The figure needed to have more detail. Analytics should be defined as part of a general scheme.	revised	No	S5‑187467
		S5‑187467	pCR 28.900 Add example of 3GPP MnS Provider using interfaces provided by ONAP DCAE	Huawei	pCR	Approval	Yes	Yes	approved	No		S5‑187159
		S5‑187236	pCR 28.900 Example of a notification header	Ericsson Japan K.K.	pCR	Approval	Yes	YesCisco observed that the text looked like that which should appear in a TS not a TR. Orange observed that the table looked very like a stage 2 spec. Nokia wondered whether the stage 2 of ONAP was similar to that of 3GPP. Was it the intention to compare the stages 3. The discussion ranged rather wider than the changes being offered in the contribution, which was simply providing a concrete example.	approved	No
		S5‑187254	Discussion Paper on options for mapping 3GPP 5G alarm notifications on ONAP VES JSON Collector API	AT&T, Deutsche Telekom, Orange	discussion	Endorsement	Yes	YesOrange believed that option 2 in the paper was preferred. Nokia asked for a clarification of the differences between columns 3 and 4 of the table in 5.2.2.3.1. It was suggested to delete the middle column. Nanjing Ericsson Panda tried to understand the two options. It seens there was a big difference between 3GPP and ONAP. Into which ONAP Release did SA5 wish to incorporate this? Orange stressed that this sas still very much a study, and no normative work was yet contemplated. Nokia stated that the ONAP Release targeted would be that which was current when 3GPP arrived at the normative phase. Huawei asked for clarification of option 2. Orange stated that the header already had a Domain fied, and a new value was proposed for this.	revised	No	S5‑187468
		S5‑187468	Discussion Paper on options for mapping 3GPP 5G alarm notifications on ONAP VES JSON Collector API	AT&T, Deutsche Telekom, Orange	discussion	Endorsement	Yes	Yes	endorsed	No		S5‑187254
		S5‑187257	pCR TS 28.900 – Options for mapping 3GPP 5G alarm notifications on ONAP VES JSON Collector API	AT&T, Deutsche Telekom, Orange	pCR	Approval	Yes	YesThis was the pCR arising from the previoius discussion document. Nokia was unsure whether changes to ONAP or 3GPP were targeted.	revised	No	S5‑187469
		S5‑187469	pCR TS 28.900 – Options for mapping 3GPP 5G alarm notifications on ONAP VES JSON Collector API	AT&T, Deutsche Telekom, Orange	pCR	Approval	Yes	Yes	approved	No		S5‑187257
		S5‑187258	pCR TS 28.900 – Mapping 3GPP 5G PM data reporting on ONAP VES JSON Collector API	AT&T, Deutsche Telekom, Orange	pCR	Approval	Yes	YesNanjing Ericsson Panda	revised	No	S5‑187470
		S5‑187470	pCR TS 28.900 – Mapping 3GPP 5G PM data reporting on ONAP VES JSON Collector API	AT&T, Deutsche Telekom, Orange	pCR	Approval	Yes	Yes	approved	No		S5‑187258
		S5‑187259	pCR TS 28.900 – ONAP Heartbeat and Event Throttling	AT&T, Deutsche Telekom, Orange	pCR	Approval	Yes	YesNanjing Ericsson Panda put a number of questions for clarification, to which Orange responded.	approved	No
		S5‑187261	pCR TS 28.900 – 3GPP Fault Supervision operations	AT&T, Deutsche Telekom, Orange	pCR	Approval	Yes	YesNanjing Ericsson Panda put a number of questions for clarification, to which Orange responded.	approved	No
		S5‑187262	Revised SID on integration of ONAP DCAE and 3GPP management architecture	AT&T, Orange	SID revised	Agreement	Yes	Yes	agreed	No
		S5‑187264	Presentation of TR 28.900 for Information to SA#82	AT&T, Orange	TS or TR cover	Agreement	Yes	Yes	approved	No
		S5‑187027	Minutes of Study on integration of ONAP DCAE and 3GPP management architecture	Rapporteur ORANGE)	report		Yes	YesTR 28.900 (under its new number) would be sent to SA sfor information.	noted	No
		S5‑187554	TR 28.900 incorporating pCRs approved at SA5#122	Rapporteur: Jean Michel Cornily	draft TR	Approval	No	No	reserved	No
6.6.3	Study on integration of ONAP and 3GPP configuration management services for 5G networks	S5‑187045	Revised SID on integration of ONAP and 3GPP configuration management services for 5G networks	Nanjing Ericsson Panda Com Ltd	SID revised	Agreement	Yes	Yes	revised	No	S5‑187471
		S5‑187471	Revised SID on integration of ONAP and 3GPP configuration management services for 5G networks	Nanjing Ericsson Panda Com Ltd	SID revised	Agreement	Yes	Yes	agreed	No		S5‑187045
		S5‑187152	pCR 28.900 Add example of 3GPP MnS Provider using interfaces provided by ONAP VF-C	China Mobile	pCR	Approval	No	Yes	withdrawn	Yes
		S5‑187153	pCR 28.900 Add example of 3GPP MnS Provider using interfaces provided by ONAP VF-C	China Mobile	pCR	Approval	Yes	YesNanjing Ericsson Panda thought the title of 6.3.X could be improved. It was a question of ONAP's exposing VF-C on the northbound interface. Nokia disagreed with some of those remarks. VF-C was already accessible in ONAP release 3. But VF-C did not expose services per se. The lollipops and chicken feet were not a good way of showing the entention in the figure. Nokia drew attention to the MANO stack of ONAP. Orange provided some improved wording to describe the interfaces.	revised	No	S5‑187472
		S5‑187472	pCR 28.900 Add example of 3GPP MnS Provider using interfaces provided by ONAP VF-C	China Mobile, Huawei	pCR	Approval	Yes	Yes	approved	No		S5‑187153
		S5‑187213	pCR 28.900 ONAP controllers and 3GPP provisioning service for CM purpose	Nanjing Ericsson Panda Com Ltd	pCR	Approval	Yes	YesNokia did not believe that VF-C was a controller. Orange proposed to remove the architecture figure from the document. Nanjing Ericsson Panda thought it was useful because of the differences between 3GPP and ONAP. Huawei wondered about 6.1.1.a para 2: what was this about. Also what was ithe intention of the secons sentence in the penultimate paragraph of 6.1.1.c. Cisco asked about the second line of 6.1.1.d and FCAPS. There was also a question on the title. What were the relations between the entities? Orange explained the structure of the document: 3GPP, ONAP, then comparison. Some cosmetic aspects were discussed (imported copyrighted figures, hanging paragraphs).	revised	No	S5‑187473
		S5‑187473	pCR 28.900 ONAP controllers and 3GPP provisioning service for CM purpose	Nanjing Ericsson Panda Com Ltd	pCR	Approval	Yes	Yes	approved	No		S5‑187213
		S5‑187214	pCR 28.900 update References for CM purposes	Nanjing Ericsson Panda Com Ltd	pCR	Approval	Yes	Yes	approved	No
		S5‑187215	pCR 28.900 add description for positioning	Nanjing Ericsson Panda Com Ltd	pCR	Approval	Yes	YesA lot of comments had been received prior to presenting this document. Orange sought more clarity for the new text, and Nanjing Ericsson Panda stated that they would already make changes to the new text to remove two of the sentences. PI Works also sought changes to the existing text.	revised	No	S5‑187478
		S5‑187478	pCR 28.900 add description for positioning	Nanjing Ericsson Panda Com Ltd	pCR	Approval	Yes	Yes	approved	No		S5‑187215
		S5‑187216	pCR 28.900 comparative analysis for CM purposes	Nanjing Ericsson Panda Com Ltd	pCR	Approval	Yes	YesNanjing Ericsson Panda Com proposed to simplify the contribution in a revision. Orange drew attention to the second sentence of the second paragraph of 6.2.z.1. Surely a decision was already to use YANG? But evidently NETCONF required something more. Nokia thought there was a misunderstanding at 6.2.1 between services and controlers. The present text was misleading. It had not been agreed that 3GPP would introduce NETCONF. Ericsson asked if there was a requirement for ONAP, and an expectation from vendors and operators. Orange believed that there were some requirement mentioned in a contribution. But Nokia disagreed that these were requirements. Evidently further analysis of theh gap was needed, to see if there was a requirement from ONAP.	revised	No	S5‑187479
		S5‑187479	pCR 28.900 comparative analysis for CM purposes	Nanjing Ericsson Panda Com Ltd	pCR	Approval	Yes	Yes	approved	No		S5‑187216
		S5‑187028	Minutes of Study on integration of ONAP and 3GPP configuration management services for 5G networks	Rapporteur (Ericsson)	report		Yes	Yes	noted	No
6.6.4	Study on protocol enhancement for real time communication	S5‑187029	Minutes of Study on protocol enhancement for real time communication	Rapporteur(Nokia)	report		No	Yes	withdrawn	Yes
6.6.5	Study on management aspects of edge computing	S5‑187235	pCR 28.803 edge computing network	Intel Corporation (UK) Ltd	pCR	Approval	Yes	YesIt was agreed to spell out "DN" in full as "data network" to avoid confusion with existing SA5 terminoloty. There was a discussion on application routeing vs network routeing. Telecom Italia questioned the use of UPF in the figure. Was this really what was meant? Nokia sought clarification over what was the objective of the whole thing. Samsung explained the meaning of "local data network".	revised	No	S5‑187482
		S5‑187482	pCR 28.803 edge computing network	Intel Corporation (UK) Ltd	pCR	Approval	Yes	YesNokia noted that rather than clarify the controlversial text, Intel had removed it.	revised	No	S5‑187531	S5‑187235
		S5‑187531	pCR 28.803 edge computing network	Intel Corporation (UK) Ltd	pCR	Approval	Yes	Yes	approved	No		S5‑187482
		S5‑187237	pCR 28.803 edge computing deployment scenarios	Intel Corporation (UK) Ltd	pCR	Approval	Yes	YesThe same remards concerning "DN" applied. There was also a hanging pragraph. Nokia believed that this was just a description of a deployment scenario specified elsewhere. But where? Intel stated that edge computing was defined elsewhere, but OSS was confusing. This claim proved somewhat contentious and a lengthy discussion involving Intel, Cisco, Nokia, Samsung and others ensued. It was recalled that the mobile edge computing environment had end-to-end objectives, and most (non-IMS) services did not have end-to-end control, but here was described a mechanism for achieving ultra-reliable, low-latency goals via E2E control. It had to be decided what mechanism was to be used for this. Intel agreed, and Nokkia also subscribed to this goal, but believed that there was no existing E2E OSS. Intel accepted that this was a valid concern. It was necessary to have a name for this E2E OSS concept. Ericsson agreed with the foregoing, but wondered what was so special about NR cells? Cisco believed the contribution was not helpful. Samsung clarified that the objective was to deliver QoS using whatever information was available.	revised	No	S5‑187483
		S5‑187483	pCR 28.803 edge computing deployment scenarios	Intel Corporation (UK) Ltd	pCR	Approval	Yes	YesEricsson took issue with the term Node-B, since this was not 3G.	approved	No		S5‑187237
		S5‑187238	pCR 28.803 use cases for UPF instantiation and termination	Intel Corporation (UK) Ltd	pCR	Approval	Yes	YesCisco was concerned over the maintenance of the UPF list. Nokia was worried that there was too much unnecessary text in this use case. There should be no importation from other groups' specifications in this document. Ericsson thought it was useful to indicate the context of the use case. Nokia then wondered what would remain when all the superfluity was removed. Ericsson believed that the application was pure software, and the pre-condition details were missing.	revised	No	S5‑187484
		S5‑187484	pCR 28.803 use cases for UPF instantiation and termination	Intel Corporation (UK) Ltd	pCR	Approval	Yes	YesSome futher wording improvements were discussed by Nokia, Cisco and Intel, repeading some of the arguments on the original document.	revised	No	S5‑187532	S5‑187238
		S5‑187532	pCR 28.803 use cases for UPF instantiation and termination	Intel Corporation (UK) Ltd	pCR	Approval	Yes	Yes	approved	No		S5‑187484
		S5‑187239	pCR 28.803 use cases for local DN deployment	Intel Corporation (UK) Ltd	pCR	Approval	Yes	YesNokia believed that the N6 was inappropriate. The use of "local DN" was not appropriate (same commenet as previous documents). Cisco was puzzled by some unclear wording. The whole use case was of limited interest. Samsung agreed: the objective was not to define how to construct a data network. The use case should describe what was needed, not how. Huawei had similar comments, and there ws no need for this use case. Intel defended it with reference to the work item description, and used the concept of the local data network defined by SA2. Telecom Italia asked whether the local data network was a DNF (Intel said yes), and a UPF could be configured to point to elements outside the scope of a 3GPP network.	revised	No	S5‑187485
		S5‑187485	pCR 28.803 use cases for local DN deployment	Intel Corporation (UK) Ltd	pCR	Approval	Yes	YesFurther changes were proposed by Nokia.	revised	No	S5‑187533	S5‑187239
		S5‑187533	pCR 28.803 use cases for local DN deployment	Intel Corporation (UK) Ltd	pCR	Approval	Yes	Yes	revised	No	S5‑187535	S5‑187485
		S5‑187535	pCR 28.803 use cases for local DN deployment	Intel Corporation (UK) Ltd	pCR	Approval	Yes	Yes	approved	No		S5‑187533
		S5‑187241	pCR 28.803 add use case for E2E OSS deployment scenario	Intel Corporation (UK) Ltd	pCR	Approval	Yes	YesCisco believed that everything should start from the use case, but this was not easy to agree with. Similar comments applied as had done for the previous use case documents. The terminology was unclear. Ericsson agreed that better definitions were needed, citing management systems defined by other organizations. Intel responded that network operators had complex environements. Cisco was in favour of end to end management systems, but there was no need to dramatically change the architecture or service model. It could be accepted that there were external components which needed to be communicated with. 3GPP should concentrate on its own management system. Samsung thought that management interfaces were already being considered, eg with ONAP, MEC, … A horizontal approach should be taken. Intel appreciated these comments, and agreed with the ideas put forward. This contribution sought to cover both cases (3GPP and external management systems) usng a service-basded approach, and seeking to avoid any unnecessary limitations.	revised	No	S5‑187486
		S5‑187486	pCR 28.803 add use case for E2E OSS deployment scenario	Intel Corporation (UK) Ltd	pCR	Approval	No	Yes	withdrawn	Yes		S5‑187241
		S5‑187243	pCR 28.803 add use case for RAN condition data	Intel Corporation (UK) Ltd	pCR	Approval	Yes	YesCisco believed that vehicles would be controlled by distributed systems, so did not think this use case was realistic. But it was a good aim to have RAN condition data available, but applied to a different use case. Ericsson wondered where this requirement had come from. Intel said that they had proposed the use case. Huawei observed there were four conditions which could be reported by the RAN, and wondered how the application would differentiate: surely the information was all important, and its reliability. Intel elaborated on the different conditions. Ericsson stressed that it was always important to know how the information received was to be treated. Telecom Italia focussed on the requirement: if APIs were exposed, any external user could make use of them. What was new about this use case? Samsung stated that the RAN already had to provide QoS: there was no need for this use case. Cisco suggested that a new application be defined to justify the use case.	revised	No	S5‑187487
		S5‑187487	pCR 28.803 add use case for RAN condition data	Intel Corporation (UK) Ltd	pCR	Approval	No	Yes	withdrawn	Yes		S5‑187243
		S5‑187030	Minutes of Study on management aspects of edge computing	Rapporteur (Intel)	report		Yes	YesThe work item was agreed to be 20% complete.	noted	No
		S5‑187549	TR 28.803 incorporating pCRs approved at SA5#122	Rapporteur: Joey Chou	draft TR	Approval	No	No	reserved	No
6.6.6	Study on tenancy concept in 5G networks and network slicing management	S5‑187201	pCR Concept of MnS consumed by tenant	Huawei Telecommunication India	pCR	Approval	Yes	Yes	revised	No	S5‑187489
		S5‑187489	pCR Concept of MnS consumed by tenant	Huawei Telecommunication India	pCR	Approval	Yes	YesNokia queried the first paragraph. Were 3GPP management services consumed directly by a third party?. Apparently this was aligned with 28.530.	approved	No		S5‑187201
		S5‑187198	pCR 28.804 Corrections of existing tenancy concept	Huawei Telecommunication India	pCR	Approval	Yes	Yes[…] Some cosmetic improvements were identified.	revised	No	S5‑187490
		S5‑187490	pCR 28.804 Corrections of existing tenancy concept	Huawei Telecommunication India	pCR	Approval	Yes	YesThe changes were not tracked.	revised	No	S5‑187534	S5‑187198
		S5‑187534	pCR 28.804 Corrections of existing tenancy concept	Huawei Telecommunication India	pCR	Approval	Yes	YesHuawei explained the difference between the two figures.	approved	No		S5‑187490
		S5‑187199	pCR 28.804 Concept of multiple exposure of same MnS	Huawei Telecommunication India	pCR	Approval	Yes	YesThis was a continuation of S5-187198. Nokia questioned what was meant by management services. Huawei clarified that this was what would be exposed for external use. Huawei clarified also that MnS Providers were not necessarily (other) network operators. Nokia thought that what was presented was nothing new. Huawei stated that the requirement could be met by either of the two architectural options presented; most secure was option 2, which had complete isolation via a dedicated MnS Consumer. Huawey believed that an operator would never offer CM data to tenants, so this was a poor example that Nokia had taken. PM data had to be isolated. This needed to be clarified. Cisoco thought the use case should provide examples of producers, tenants (business entities), and data descriptions. The use case as presented was too generic.	revised	No	S5‑187492
		S5‑187492	pCR 28.804 Concept of multiple exposure of same MnS	Huawei Telecommunication India	pCR	Approval	Yes	YesAn editor's note had been added. Nokia maintained that the sequence of events was still wrong. What did figure 4.2.X indicate? What was it the intention to isolate? The solution was ahead of the problem! TNO, on the contrary, felt that the discussion had been clear enough, and supported this contribution. Further elaboration could be brought to the next meeting. Ericsson agreed with the problems repeatedly expressed by Nokia. A TR was to record the results of study, and there was only reasonable way of achieving this goal.	not pursued	No		S5‑187199
		S5‑187031	Minutes of Study on tenancy concept in 5G networks and network slicing management	Rapporteur (Huawei)	report		Yes	YesThe WI was agreed to be 20% complate.	noted	No
		S5‑187550	TR 28.804 incorporating pCRs approved at SA5#122	Rapporteur: Lei Zhu	draft TR	Approval	No	No	reserved	No
6.6.7	Study on management aspects of communication services	S5‑187371	Study on management aspects of communication services	Rapporteur (Jan Groenendijk)	other	discussion	Yes	Yes	noted	No
		S5‑187169	pCR 28.805 Add requirements of MDA-Assisted network provision contributing to SLA assurance	Huawei	pCR	Approval	Yes	YesIt was questioned what was the value added by this document. Surely thiis was SA5 business as usual? Huawei responded that this use case might solicit real requirements. Cisco sought clarification on the first requirement, as did Intel on the function of the MDAF in requirement 1. Telecom Italia drew attention to the existing text, but noted that MDAF did not directly give topology..	revised	No	S5‑187494
		S5‑187494	pCR 28.805 Add requirements of MDA-Assisted network provision contributing to SLA assurance	Huawei	pCR	Approval	Yes	Yes	approved	No		S5‑187169
		S5‑187172	pCR 28.805 Add UC and requirements for multi-degree SLA assurance	Huawei	pCR	Approval	Yes	YesCisco liked the idea, but the title hinted at some other solution, noting that it was possible to have multiple SLAs, with manged degradation (eg of video). Ericsson believed that in practice, SLAs would be managed at BSS level, translated into service requirements which needed to be assure. Operators would have hundreds of SLAs. Should network elements be aware of these? And if not, where would the translation be performed? Duetsche Telekom noted there were several options, eg end to end via several domains, or levels within a single domain. The word "multi-degree" was misleading. At present there were operation level agreements. Clarification was needed.	revised	No	S5‑187495
		S5‑187495	pCR 28.805 Add UC and requirements for multi-degree SLA assurance	Huawei	pCR	Approval	No	Yes	withdrawn	Yes		S5‑187172
		S5‑187173	pCR 28.805 Add UC and requirements for SLA monitoring and assurance for network slicing	Huawei	pCR	Approval	Yes	YesIntel supported the intention of the document, but asked for separation of the different services in the figure of the rationale. Concerning requirement 2, Deitsshe Telekiom wondered what would be the outcome. It was too general. Nokia asked not to use any normative language in this TR.	revised	No	S5‑187497
		S5‑187497	pCR 28.805 Add UC and requirements for SLA monitoring and assurance for network slicing	Huawei	pCR	Approval	Yes	Yes	approved	No		S5‑187173
		S5‑187170	pCR 28.805 Add UC and requirements for creation of communication service instance	Huawei	pCR	Approval	Yes	YesEricsson wonered what is meant by "subscribed [to] the communication service". Huawei explained the concept of subscription to a communication service. Ericsson descrited this concept in a very different manner. On the requirements, the language could be improved. Telecom Italia wondered whether, in requirement 1, it was the operator or the service provider? Huawei confirmed that the text did indeed mean operator. Telecom Italia also proposed that the communicaton service provider also have this capability. PI Works thought that the words "have the capability" implies autonomous ability to configure, and this limited the scope of the capabilities. Orange returned to the first requirement. This was the responsibility of the communication service provider, rather than the operator. Deutsche Telekom questioned the need for a separate requirement 3. Some editorials were identified. This document was merged into S5-157504.	merged	No	S5‑187504
		S5‑187498	pCR 28.805 Add UC and requirements for creation of communication service instance	Huawei	pCR	Approval	No	Yes	withdrawn	Yes		S5‑187170
		S5‑187171	pCR 28.805 Add UC and requirements for termination of communication service instance	Huawei	pCR	Approval	Yes	YesThis was related to the previous contribution (S5-187170). Ericsson had a contribution with a similar title which was somewhat aligned, but some wording could be improved. The sequence of objectives could be improved. Deutsche Telekom made a similar comment about the first requirement as had been made for the previous document. It was not understood why it should be necessary to terminate the NSI, because an NSI might serve serveral users. PI Works aimed to allow control to the vertical users of the network. The proposal raised security concerns. Orange stressed that the operator really did manage the slices.	revised	No	S5‑187499
		S5‑187499	pCR 28.805 Add UC and requirements for termination of communication service instance	Huawei, Ericsson	pCR	Approval	Yes	Yes	revised	No	S5‑187527	S5‑187171
		S5‑187527	pCR 28.805 Add UC and requirements for termination of communication service instance	Huawei, Ericsson, Deutsche Telekom	pCR	Approval	Yes	YesNokia proposed two minor editorial changes. Huawei proposed to correct it in a later pCR.	approved	No		S5‑187499
		S5‑187168	pCR 28.805 Add definition of communication service	Huawei	pCR	Approval	Yes	YesEricsson thought that although the newly defined terms were in widespread use, there was as yet no formal definition. Nokia thought that a note to explain the context of the first definitoin would be userful. The term CSI should be avoided! Cisco noted that currently there was no definition of a communication class, and it was not necessary to define an instance. Orange drew attention to the use of "users" which tended to imply human uwers. This was inappropriate. Deutsche Telekom wished to clarify the first definition: what was a communication requirement. Nokia and Telekom Italia thought the term "communication service" could be improved. There was a danger of a circular definition. Some ediotiral matters were proposed.	revised	No	S5‑187500
		S5‑187500	pCR 28.805 Add definition of communication service	Huawei, Ericsson	pCR	Approval	Yes	Yes	revised	No	S5‑187528	S5‑187168
		S5‑187528	pCR 28.805 Add definition of communication service	Huawei, Ericsson,Deutsche Telekom	pCR	Approval	Yes	YesNokia queried the term "offered". Was "provided" not a better word?	approved	No		S5‑187500
		S5‑187252	pCR 28.805 Move key topics to Annex	Ericsson Limited	pCR	Approval	Yes	YesThe text in question would be removed from the final version of the TR. The editor's note had, however, been modified, and there was some discussion over this. However, it was cleear that the text in question could not remain in the final version of the TR, since it was a list of intended topics to cover, at when the TR was complete, these topics would either have been dealt with, or not. But some aspects of the text might be captured in the scope or in the conclusion of the final TR. Huawei strongly wished to eliminate the intention to delete the annex.	revised	No	S5‑187501
		S5‑187501	pCR 28.805 Move key topics to Annex	Ericsson Limited	pCR	Approval	Yes	Yes	approved	No		S5‑187252
		S5‑187282	Discussion paper on communication service management concept	Ericsson Limited	discussion	Endorsement	Yes	YesIn option C, the CSMF had elements in both the BSS and the OSS. Huawei wondered which entity would take responsibility for it? Ericsson confirmed it woud be the TMF. Deutsche Telekom found the first figure rather confusing. For the figure under Role of CSMF, surely the arrows should have been shown bidrectional. The OSS aspect were beyond the scope of SA5. Elements taken from Wikipedia were not appropriate for a 3GPP paper. Finally, there was no definition of communication services. Ericsson thought that, in this early stage document, it was ok to leave things slightly vague. Eircsson said that they had used the network slice because this was a well known concept. Cisco asked why it was necessary to decide whether an element belonged to either BSS or OSS. Ericsson recommended option C and had a pCR on this.	noted	No
		S5‑187283	pCR 28.805 Add description of communication service concept to background and concepts	Ericsson Limited	pCR	Approval	Yes	Yes[Wrong tdoc number shown on cover] Cisco asked what services were intended to be standardized. Was it really necessary to split the CSMF into two parts, unless it was intended to have an interface between the MSS part and the OSS part. Telecom Italia sopke further on interfaces: the reason for the split was surely to define what was the responsibility of 3GPP (SA5) and what was not.	revised	No	S5‑187502
		S5‑187502	pCR 28.805 Add description of communication service concept to background and concepts	Ericsson Limited, Deutsche Telekom	pCR	Approval	Yes	YesCisco still did not understand why the figure showed a split. Ericsson referred to the text by way of explanation, but Cisco was not convinced. Deutsche Telekom observed that the terms OSS and BSS were being excised, but the concepts of provider and consumer / customer were better.	revised	No	S5‑187536	S5‑187283
		S5‑187536	pCR 28.805 Add description of communication service concept to background and concepts	Ericsson Limited	pCR	Approval	Yes	Yes	revised	No	S5‑187540	S5‑187502
		S5‑187540	pCR 28.805 Add description of communication service concept to background and concepts	Ericsson Limited	pCR	Approval	Yes	Yes	approved	No		S5‑187536
		S5‑187284	pCR 28.805 Use case to realize a communication service in a single network slice	Ericsson Limited	pCR	Approval	Yes	YesDeutsche Telekom said requirements 2 and 3 were not focused on communication services. Orange found that requiirement 1 was a PSS function. In addition, the established terminology should be used. Huawai wondered how the split of the CSMF mapped to this scenario. This could be clarified. Ericsson responded that the text was neutral with respect to this. What was the -x2 requirement? - there seemed to be two options there. Deutsche Telekom also recommended to remove the term "enterprise": it could be a user, or requestor. Orange recommended to have a communication service instance.	revised	No	S5‑187503
		S5‑187503	pCR 28.805 Use case to realize a communication service in a single network slice	Ericsson Limited	pCR	Approval	No	Yes	withdrawn	Yes		S5‑187284
		S5‑187285	pCR 28.805 Use case to realize multiple communication services in a single network slice	Ericsson Limited	pCR	Approval	Yes	YesDeutsche Telekom proposed to clarify the requirements: what did the verb "maintain" mean, similarly "declare the result". There were overlapping requirements with other Ericsson documents.	revised	No	S5‑187504
		S5‑187504	pCR 28.805 Use case to realize multiple communication services in a single network slice	Ericsson, Huawei, DT	pCR	Approval	Yes	YesCisco questioned the terminology. Nokia proposed the inclusion of an editor's note as a place holder for "service instance". Orange objected to this. Huawei drew attention to the notes added for CSI; a similar approach could be taken.	approved	No		S5‑187285
		S5‑187286	pCR 28.805 Use case to remove a communication service from a network slice	Ericsson Limited	pCR	Approval	Yes	YesDeutsche Telekom's previous remarks also pertained here. Huawei waid that the definition of terms would have an effect on the wording used. Orange spotted a few editorial matters.	revised	No	S5‑187505
		S5‑187505	pCR 28.805 Use case to remove a communication service from a network slice	Ericsson Limited	pCR	Approval	No	Yes	withdrawn	Yes		S5‑187286
		S5‑187032	Minutes of Study on management aspects of communication services	Rapporteur (Ericsson)	report		Yes	Yes	noted	No
		S5‑187551	TR 28.805 incorporating pCRs approved at SA5#122	Rapporteur: Jan Groenendijk	draft TR	Approval	No	No	reserved	No
6.6.8	Study on Self-Organizing Networks (SON) for 5G	S5‑187302	Sequence of pCR discussion	Intel Corporation (UK) Ltd	other	Discussion	Yes	Yes	noted	No
		S5‑187225	pCR 28.861 Add SON concepts	Intel Corporation (UK) Ltd	pCR	Approval	Yes	YesNokia suggested there could be higher-level control loops. The hybrid SON view was slightly misleading because the coordination needed to be shown. Cisco opposed the controbution for many reasons: the methodology proposed was not helpful. Distributed SON was not the business of SA5. There was no longer a reference model in the 5G era. Huawei bellieved that a similar diagram had been seen at the preveious meeting; SA5 should use similar figures across the documents. Further it was not necessary to completely redefine things which had already been adequately defined elsewhere. Deutsche Telekom made reference to the open loop definition which had been used for LTE, which implied human intervention. Orange noted the NFs in the diagrams: these could be replaced by some management services. Intel saw the point, but wished to maintain a general level of desctiption. Orange also suggested showing more detail.	revised	No	S5‑187506
		S5‑187506	pCR 28.861 Add SON concepts	Intel Corporation (UK) Ltd	pCR	Approval	Yes	YesThere was a discussion on terminology relating to SON. Huawei cited the LS exchanged with SA2. The figures needed toi be aligned with the common terminology.	revised	No	S5‑187538	S5‑187225
		S5‑187538	pCR 28.861 Add SON concepts	Intel Corporation (UK) Ltd	pCR	Approval	Yes	Yes	approved	No		S5‑187506
		S5‑187226	pCR 28.861 Add key issues overview for 5G SON study	Intel Corporation (UK) Ltd	pCR	Approval	Yes	YesCisco opposed the controbution for many reasons: the methodology proposed was not helpful. The use case should include the goal but also includes a statement of the resources and the sequence of steps. This contribution gathered too many complex ideas to be sensibly treated together. It should be split into separate tdocs. Intel responded that use cases should be categorized to give better readability. Some of the aspects had been copied over from LTE. Nokia commented on the self-establishment topic. The network function could not estabish itself, so the wording was confusing. Intel stated that this had already been defined for LTE. Ericsson was puzzled that these elements were called "key issues". The information in this document should be recast into the structure proposed in a separate document by Ericsson. Intel had intended to give an overview of all the issues and wished to work with others on the structure. Orange maintained that automatic creation of NSSIs was not SON. Intel accepted this. The document was merged with several others into S5-187509.	merged	No	S5‑187509
		S5‑187073	pCR to 28.861 ANR SON function	Cisco Systems Inc.	pCR	Approval	Yes	YesIntel thought this was more about automatic ANR optimization (black list, white list, etc). But this was beyond ANR. Cisco agreed and proposed to change the name. Nokia agreed that this was a new concept for ANR, and this should not preclude other ANR use cases. Nokia recalled the D-SON / C-SON discussions of the past. Cisco agreed but this was not the onnly possible scenario. IP Works was concerned with what kind of optimization of measurements would be made. Cisco said it was not related necessarily to MRO because "mobility" was mentioned. IP Works thought further deliberation time was needed. Ericsson wished for the name to be changed, but maybe it would be good to give an indication of the relation between "traditional" ANR and this new concept. Ericsson and Nokia discussed the nature of open loop manaagement for some minutes. Huawei had seen many different management systems mentioned in the document. What was the relation between these and the ANR function? Cisco said that the goal was not quite accurate as presently stated. Huawei referred to the second paragraph o fthe pre-conditions. Was the ANR function a subscriber to the NR-RAN provisionaing amagement service? Cisco believed that the answer to this would be too detailed for this document. Thirdly Huaway saw that all measurements would be monitored and then action taken. There was no differentiation between steps, would this reuse the provisioning service. Cisco said yes. Finally, the document was merged with others into S5-187509.	merged	No	S5‑187509
		S5‑187507	pCR to 28.861 ANR SON function	Cisco Systems Inc.	pCR	Approval	No	Yes	withdrawn	Yes		S5‑187073
		S5‑187074	pCR to 28.861 CCO SON function	Cisco Systems Inc.	pCR	Approval	Yes	YesIntel questioned the rationale. There was no mention of 5GC in the proposed new text relating to the steps. Secondly, in the precondition, there was a need to cooperate with the charging group. There was a need to include steps. The requirements were rather too general and should relate more to the SON perspective. Cisco replied that SON did not require anything beyond performance measurement and configuration capability. Requirements were expressed in terms of performance indicators. A detailed discussion between Intel and Cisco ensued. Huawei recalled the case of NDEF in Rel-15. How did this fit into the scenario? Cisco thought there was a need for some general text relating to all use cases, and this would be the place to mention the analytics arising from NDEF. Intel thought that Huawei's point was good. Finally, the document was merged with others into S5-187509.	merged	No	S5‑187509
		S5‑187304	pCR 28.861 Legacy SON functions	Ericsson, Verizon	pCR	Approval	Yes	YesCisco liked this contribution but there were a number of contributions for this TR and there would be a clash of structure. Therefore it would be advisable to combine everything relating to legacy into a single contribution. Intel asked what was meant by "legacy", Ericsson stated that this meant LTE (or earlier). Intel also liked the contribution. Huawei referred to 4.x.5 and 4.x.19; these were essentially the same. Huawei also recommended to remove "distributed architecture" from the clause titles. Intel and others agreed. Orange wondered what "synchronization" implied in the rationale. Ericsson replied. Nokia believed that this was time synchronization. The discusssion proposed to merge S5-187226, 073, 074, 113, 304.	revised	No	S5‑187509
		S5‑187509	pCR 28.861 Legacy SON functions	Ericsson, Verizon, Intel, Cisco	pCR	Approval	Yes	YesIntel noted that the numbering would need to be adjusted by the rapporteur at implementation.	approved	No		S5‑187304
		S5‑187508	pCR to 28.861 CCO SON function	Cisco Systems Inc.	pCR	Approval	No	Yes	withdrawn	Yes		S5‑187074
		S5‑187113	Self-configuration for NG-RAN and 5GC	Cisco Systems Belgium	pCR	Approval	Yes	YesOrange noted that sometimes self configuration was a function and sometimes a service. Cisco responded that the distinction was deliberate. Nokia agreed, but the text was not very clear. There was also a debate as to use self configuration or self establishment. Intel believed that self configuration was a superset of self establishment. IP Works tried to interpret some wording [… off line] Finally, the document was merged with others into S5-187509.	merged	No	S5‑187509
		S5‑187112	pCR to 28.861 E2E Service Quality Optimization	Cisco Systems Belgium	pCR	Approval	Yes	YesNokia was uncomortable about generalization in the case of E2E and would like a concrete example because optimization criteria might differ from case to case. […] NEC was provisioning management service now taken care of by SON? Was this a new algorithm or a cooperation amongst algorithms. Cisco replied that the algorithm was beyond the scope of 3GPP.	revised	No	S5‑187510
		S5‑187510	pCR to 28.861 E2E Service Quality Optimization	Cisco Systems Belgium	pCR	Approval	Yes	YesChina Mobile felt that most their comments had not been addressed. Cisco denied this. Huawei believed this needed to be captured in 28.805. Again Cisco did not agree. Intel clarified that this was not an E3 service.	noted	No		S5‑187112
		S5‑187177	pCR 28.861 NSI resource utilization performance optimization	Huawei Tech.(UK) Co., Ltd	pCR	Approval	Yes	YesIntel was distressed by the table format. Intel thought it would be better not to mention MDAS specificatly. Also step 1 should lbe optional, and improvements were identified to several other steps. Acknowledgements were not needed at every step. Nokia agreed with Intel, and proposed some minor wording modifications. Cisco the resources mentioned should be included all entities mentioned below. Many small but essential elements needed to be corrected - for example, which policies were meant? The document was merged with S5-187227 to produce S5-187511.	merged	No	S5‑187511
		S5‑187227	pCR 28.861 add use case for eMBB, URLLC, and mMTC network slice	Intel Corporation (UK) Ltd	pCR	Approval	Yes	Yes[…] Nokia believed the contribution needed extensive revision. The document was merged with S5-187177 to produce S5-187511.	merged	No	S5‑187511
		S5‑187511	pCR 28.861 NSI resource utilization performance optimization	Huawei Tech.(UK) Co., Ltd, Intel Corporation (UK)	pCR	Approval	Yes	Yes	revised	No	S5‑187529	S5‑187177
		S5‑187512	pCR 28.861 add use case for eMBB, URLLC, and mMTC network slice	Intel Corporation (UK) Ltd	pCR	Approval	No	Yes	withdrawn	Yes		S5‑187227
		S5‑187529	pCR 28.861 NSI resource utilization performance optimization	Huawei Tech.(UK) Co., Ltd, Intel Corporation (UK)	pCR	Approval	Yes	Yes	revised	No	S5‑187537	S5‑187511
		S5‑187537	pCR 28.861 NSI resource utilization performance optimization	Huawei Tech.(UK) Co., Ltd, Intel Corporation (UK)	pCR	Approval	Yes	YesIt was noted that the tdoc number was wrong on the cover page. The revision included Intel's contribution.	approved	No		S5‑187529
		S5‑187228	pCR 28.861 add use case for beam coverage and capacity optimization	Intel Corporation (UK) Ltd	pCR	Approval	Yes	YesNokia believed that the requirements were wrong. In the introduction, the text should not denigrate LTE. Huawei questioned the method of writing the use cases. For LTE, it was done in more dtail. The beam-based scenario described for NR RAN was not as good. Intel cited another, Cisco, contribution on the subject. Huawei though the use case was the same as for LTE, but the solutions could use the enhanced features of NR. Nokia agreed wholeheartedly.Also, the text and the figure did not agree with each other.	revised	No	S5‑187513
		S5‑187513	pCR 28.861 add use case for beam coverage and capacity optimization	Intel Corporation (UK) Ltd	pCR	Approval	Yes	YesNokia thought the text, and the diagram, implied static beams. It mixed beams and sectors. Beams did not fix coverage problems, beams were dynamic. This was a radio use case. Intel defended it as relating to cells. Pivotal Commware agreed the diagram was inadequate, but beams could indeed be used to fill covererage holes.	not pursued	No		S5‑187228
		S5‑187033	Minutes of Study on Self-Organizing Networks (SON) for 5G	Rapporteur (Intel)	report		Yes	YesThe WI was considered to be 10% complete.	noted	No
		S5‑187553	TR 28.861 incorporating pCRs approved at SA5#122	Rapporteur: Joey Chou	draft TR	Approval	No	No	reserved	No
7	Charging	S5‑187453	(reserved)	(charging subgroup)	other	discussion	No	Yes	withdrawn	Yes
		S5‑187454	(reserved)	(charging subgroup)	other	discussion	No	Yes	withdrawn	Yes
		S5‑187455	(reserved)	(charging subgroup)	other	discussion	No	Yes	withdrawn	Yes
7.1	Charging Plenary	S5‑187034	CH Agenda and Time Plan	CH SWG Chair	agenda		Yes	Yes	revised	No	S5‑187305
		S5‑187305	CH Agenda and Time Plan	CH SWG Chair	agenda	-	Yes	Yes	approved	No		S5‑187034
		S5‑187044	Reply LS from SA2 ccSA5 on Data Volume Reporting in 5GC	SA2	LS in		Yes	Yes	noted	No
		S5‑187035	CH Executive Report	CH SWG Chair	report		Yes	Yes	noted	No
7.2	New Charging Work Item proposals	S5‑187200	New WID on Network Exposure Charging in 5G System Architecture	Ericsson	WID new	Agreement	Yes	Yes	revised	No	S5‑187306
		S5‑187306	New WID on Network Exposure Charging in 5G System Architecture	Ericsson	WID new	Agreement	Yes	Yes	agreed	No		S5‑187200
		S5‑187244	New WID Charging AMF in 5G System Architecture Phase 1	Nokia, Nokia Shanghai Bell	WID new	Agreement	Yes	Yes	revised	No	S5‑187307
		S5‑187307	New WID Charging AMF in 5G System Architecture Phase 1	Nokia, Nokia Shanghai Bell	WID new	Agreement	Yes	Yes	agreed	No		S5‑187244
7.3	Charging Maintenance and Rel-16 small Enhancements	S5‑187075	Rel-15 CR 32.291 Correction of response code in flow for Notify	Ericsson	CR	Agreement	Yes	Yes	agreed	No
		S5‑187076	Rel-15 CR 32.255 Allow update of NotifyUri	Ericsson	CR	Agreement	Yes	Yes	revised	No	S5‑187322
		S5‑187322	Rel-15 CR 32.255 Allow update of NotifyUri	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S5‑187076
		S5‑187077	Rel-15 CR 32.290 Allow update of NotifyUri	Ericsson	CR	Agreement	Yes	Yes	revised	No	S5‑187323
		S5‑187323	Rel-15 CR 32.290 Allow update of NotifyUri	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S5‑187077
		S5‑187078	Rel-15 CR 32.291 Allow update of NotifyUri	Ericsson	CR	Agreement	Yes	Yes	revised	No	S5‑187324
		S5‑187324	Rel-15 CR 32.291 Allow update of NotifyUri	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S5‑187078
		S5‑187079	Rel-15 CR 32.291 Correction of overlapping results between Invocation result and Result code	Ericsson	CR	Agreement	Yes	Yes	revised	No	S5‑187325
		S5‑187325	Rel-15 CR 32.291 Correction of overlapping results between Invocation result and Result code	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S5‑187079
		S5‑187080	Rel-15 CR 32.255 Correction of Invocation Reslut at http ok	Ericsson	CR	Agreement	Yes	Yes	revised	No	S5‑187326
		S5‑187326	Rel-15 CR 32.255 Correction of Invocation Reslut at http ok	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S5‑187080
		S5‑187081	Rel-15 CR 32.290 Correction of Invocation Reslut at http ok	Ericsson	CR	Agreement	Yes	Yes	revised	No	S5‑187327
		S5‑187327	Rel-15 CR 32.290 Correction of Invocation Reslut at http ok	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S5‑187081
		S5‑187082	Rel-15 CR 32.291 Correction of Invocation Reslut at http ok	Ericsson	CR	Agreement	Yes	Yes	revised	No	S5‑187328
		S5‑187328	Rel-15 CR 32.291 Correction of Invocation Reslut at http ok	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S5‑187082
		S5‑187083	Rel-15 CR 32.255 Correction of Online non-blocking handling	Ericsson	CR	Agreement	Yes	Yes	revised	No	S5‑187329
		S5‑187329	Rel-15 CR 32.255 Correction of Online non-blocking handling	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S5‑187083
		S5‑187084	Rel-15 CR 32.291 Correction of Rating Group type to Uint32	Ericsson	CR	Agreement	Yes	Yes	revised	No	S5‑187331
		S5‑187331	Rel-15 CR 32.291 Correction of Rating Group type to Uint32	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S5‑187084
		S5‑187085	Rel-15 CR 32.255 Correction of UPF Id definition	Ericsson	CR	Agreement	Yes	Yes	revised	No	S5‑187333
		S5‑187333	Rel-15 CR 32.255 Correction of UPF Id definition	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S5‑187085
		S5‑187086	Rel-15 CR 32.255 Correction AMF Id definition	Ericsson	CR	Agreement	Yes	Yes	revised	No	S5‑187334
		S5‑187334	Rel-15 CR 32.255 Correction AMF Id definition	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S5‑187086
		S5‑187087	Rel-15 CR 32.291 Correction of name for Multiple Unit	Ericsson	CR	Agreement	Yes	Yes	revised	No	S5‑187388
		S5‑187388	Rel-15 CR 32.291 Correction of name for Multiple Unit	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S5‑187087
		S5‑187088	Rel-15 CR 32.291 Allow PDUSession reference in Notify	Ericsson	CR	Agreement	Yes	Yes	not pursued	No
		S5‑187089	Rel-15 CR 32.298 Correct PDU Session level trigger in CHF CDR	Ericsson	CR	Agreement	Yes	Yes	revised	No	S5‑187389
		S5‑187389	Rel-15 CR 32.298 Correct PDU Session level trigger in CHF CDR	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S5‑187089
		S5‑187090	Rel-15 CR 32.255 Correction of Unused Quota Timer naming	Ericsson	CR	Agreement	Yes	Yes	revised	No	S5‑187390
		S5‑187390	Rel-15 CR 32.255 Correction of Unused Quota Timer naming	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S5‑187090
		S5‑187091	Rel-15 CR 32.291 Correction of Unused Quota Timer naming	Ericsson	CR	Agreement	Yes	Yes	revised	No	S5‑187391
		S5‑187391	Rel-15 CR 32.291 Correction of Unused Quota Timer naming	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S5‑187091
		S5‑187092	Rel-15 CR 32.291 Correction of missing http status codes	Ericsson	CR	Agreement	Yes	Yes	revised	No	S5‑187392
		S5‑187392	Rel-15 CR 32.291 Correction of missing http status codes	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S5‑187092
		S5‑187093	Rel-15 CR 32.251 Correction of Supported Feature for EDCE5-CH	Ericsson	CR	Agreement	Yes	Yes	revised	No	S5‑187394
		S5‑187394	Rel-15 CR 32.251 Correction of Supported Feature for EDCE5-CH	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S5‑187093
		S5‑187097	R15 CR 32.255 Correction of errors from Edithelp	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No		S5‑186389
		S5‑187098	Rel-15 CR 32.255 Introduction Data Volume Reporting for Option 4&7	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	revised	No	S5‑187395
		S5‑187395	Rel-15 CR 32.255 Introduction Data Volume Reporting for Option 4&7	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No		S5‑187098
		S5‑187099	Rel-15 CR 32.298 Introduction Data Volume Reporting for Option 4&7	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	revised	No	S5‑187396
		S5‑187396	Rel-15 CR 32.298 Introduction Data Volume Reporting for Option 4&7	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No		S5‑187099
		S5‑187100	Rel-15 CR 32.291 Introduction Data Volume Reporting for Option 4&7	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	revised	No	S5‑187397
		S5‑187397	Rel-15 CR 32.291 Introduction Data Volume Reporting for Option 4&7	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No		S5‑187100
		S5‑187107	Rel-15 CR 32.291 Alignment on Session Identifier	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	revised	No	S5‑187398
		S5‑187398	Rel-15 CR 32.291 Alignment on Session Identifier	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No		S5‑187107
		S5‑187108	Rel-15 CR 32.290 Add description for Charging Notification	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	revised	No	S5‑187399
		S5‑187399	Rel-15 CR 32.290 Add description for Charging Notification	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No		S5‑187108
		S5‑187109	Rel-15 CR 32.291 Correction on Charging Notification message	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	revised	No	S5‑187400
		S5‑187400	Rel-15 CR 32.291 Correction on Charging Notification message	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No		S5‑187109
		S5‑187110	Rel-15 CR 32.291 Correction on Charging ID data type	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	revised	No	S5‑187401
		S5‑187401	Rel-15 CR 32.291 Correction on Charging ID data type	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No		S5‑187110
		S5‑187111	Rel-15 CR 32.255 Complete flows alignment with TS 23.502	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	revised	No	S5‑187404
		S5‑187404	Rel-15 CR 32.255 Complete flows alignment with TS 23.502	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No		S5‑187111
		S5‑187120	Rel-15 CR 32.291 Correction on Reauthorizationdetails	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	revised	No	S5‑187402
		S5‑187402	Rel-15 CR 32.291 Correction on Reauthorizationdetails	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No		S5‑187120
		S5‑187137	Correction of Data Volume Uplink and Downlink definition	Ericsson	CR	Agreement	Yes	Yes	revised	No	S5‑187298
		S5‑187298	Correction of Data Volume Uplink and Downlink definition	Ericsson	CR	Agreement	Yes	Yes	revised	No	S5‑187318	S5‑187137
		S5‑187318	Correction of Data Volume Uplink and Downlink definition	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S5‑187298
		S5‑187138	Correction of Data Volume Uplink and Downlink definition	Ericsson	CR	Agreement	Yes	Yes	revised	No	S5‑187299
		S5‑187299	Correction of Data Volume Uplink and Downlink definition	Ericsson	CR	Agreement	Yes	Yes	revised	No	S5‑187319	S5‑187138
		S5‑187319	Correction of Data Volume Uplink and Downlink definition	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S5‑187299
		S5‑187139	Correcting the definition of data counting at the tunnelling interface	Ericsson	CR	Agreement	Yes	Yes	revised	No	S5‑187300
		S5‑187300	Correcting the definition of data counting at the tunnelling interface	Ericsson	CR	Agreement	Yes	Yes	revised	No	S5‑187320	S5‑187139
		S5‑187320	Correcting the definition of data counting at the tunnelling interface	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S5‑187300
		S5‑187140	Correcting the definition of data counting at the tunnelling interface	Ericsson	CR	Agreement	Yes	Yes	revised	No	S5‑187301
		S5‑187301	Correcting the definition of data counting at the tunnelling interface	Ericsson	CR	Agreement	Yes	Yes	revised	No	S5‑187321	S5‑187140
		S5‑187321	Correcting the definition of data counting at the tunnelling interface	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S5‑187301
		S5‑187179	Rel15 CR 32.251 PRA charging clarification	Huawei	CR	Agreement	Yes	Yes	revised	No	S5‑187406
		S5‑187406	Rel15 CR 32.251 PRA charging clarification	Huawei	CR	Agreement	Yes	Yes	agreed	No		S5‑187179
		S5‑187180	Rel15 CR 32.255 PRA charging clarification	Huawei	CR	Agreement	Yes	Yes	revised	No	S5‑187407
		S5‑187181	Rel15 CR 32.251 Multi-PRAs charging clarification	Huawei	CR	Agreement	Yes	Yes	revised	No	S5‑187446
		S5‑187407	Rel15 CR 32.255 PRA charging clarification	Huawei	CR	Agreement	Yes	Yes	agreed	No		S5‑187180
		S5‑187446	Rel15 CR 32.251 Multi-PRAs charging clarification	Huawei	CR	Agreement	Yes	Yes	agreed	No		S5‑187181
		S5‑187233	Rel-15 CR 32.255 Add missing clause on formal description	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	revised	No	S5‑187403
		S5‑187403	Rel-15 CR 32.255 Add missing clause on formal description	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No		S5‑187233
		S5‑187330	LS to SA2 on Introduction of a special case of online charging method	SA5 (Ericsson)	LS out	Approval	Yes	Yes	approved	No
		S5‑187332	LS to CT4 CT3 on introduction of common data types	SA5 (Nokia)	LS out	Approval	Yes	Yes	approved	No
		S5‑187393	Rel-15 CR 32.291 Failure Handling Mechanism Clarification	Huawei	CR	Agreement	Yes	Yes(remaining part agreed in S5-18739: the other part is changed and relocated in S5-187325)	agreed	No
		S5‑187405	Rel-15 CR 32.255 Correction on flows for alignment with TS 23.502	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No
		S5‑187452	R15 CR 32.291 Correction of Serving Network Function ID definition	(charging subgroup)	CR	Agreement	Yes	Yes	agreed	No
7.4	Rel-15 Charging
7.4.1	SMS Charging in 5G System Architecture Phase 1	S5‑187094	Rel-15 CR 32.290 Addition of event charging	Ericsson	CR	Agreement	Yes	Yes	revised	No	S5‑187308
		S5‑187308	Rel-15 CR 32.290 Addition of event charging	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S5‑187094
		S5‑187095	Rel-15 CR 32.291 Addition of event charging	Ericsson	CR	Agreement	Yes	Yes	revised	No	S5‑187309
		S5‑187309	Rel-15 CR 32.291 Addition of event charging	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S5‑187095
		S5‑187096	Rel-15 CR 32.298 Addition of SMS info to CHF CDR	Ericsson	CR	Agreement	Yes	Yes	revised	No	S5‑187317
		S5‑187317	Rel-15 CR 32.298 Addition of SMS info to CHF CDR	Ericsson	CR	Agreement	Yes	Yes	agreed	No		S5‑187096
		S5‑187101	Rel-15 CR 32.274 Introduction of 5GS for SMS charging via Ro Rf	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No
		S5‑187102	Rel-15 CR 32.274 Introduction of offline charging for IP-SM-GW architecture and flows	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	revised	No	S5‑187310
		S5‑187310	Rel-15 CR 32.274 Introduction of offline charging for IP-SM-GW architecture and flows	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No		S5‑187102
		S5‑187103	Rel-15 CR 32.274 Introduction of offline charging for IP-SM-GW CDRs	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	revised	No	S5‑187311
		S5‑187311	Rel-15 CR 32.274 Introduction of offline charging for IP-SM-GW CDRs	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No		S5‑187103
		S5‑187104	Rel-15 CR 32.298 Introduction of 5GS for SMS charging via Ro Rf	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No
		S5‑187105	Rel-15 CR 32.298 Introduction of offline charging for IP-SM-GW	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	revised	No	S5‑187312
		S5‑187312	Rel-15 CR 32.298 Introduction of offline charging for IP-SM-GW	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No		S5‑187105
		S5‑187106	Rel-15 CR 32.298 Introduction of SMS Charging to ASN.1 CHF CDR	Nokia, Nokia Shanghai Bell	CR	Agreement	No	Yes	withdrawn	Yes
		S5‑187182	Rel15 CR 32.291 Data Type for SMS	Huawei	CR	Agreement	Yes	Yes	revised	No	S5‑187297
		S5‑187297	Rel15 CR 32.291 Data Type for SMS	Huawei, Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	revised	No	S5‑187314	S5‑187182
		S5‑187314	Rel15 CR 32.291 Data Type for SMS	Huawei, Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No		S5‑187297
		S5‑187229	Rel-15 CR 32.274 Introduction of Detailed message format	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	revised	No	S5‑187313
		S5‑187313	Rel-15 CR 32.274 Introduction of Detailed message format	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No		S5‑187229
		S5‑187230	Rel-15 CR 32.274 Introduction of clauses on formal description and binding	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No
		S5‑187231	Rel-15 CR 32.291 Introduce Binding for SMS charging	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	revised	No	S5‑187316
		S5‑187316	Rel-15 CR 32.291 Introduce Binding for SMS charging	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No		S5‑187231
		S5‑187232	Rel-15 CR 32.291 Introduce OpenAPI extension for SMS charging	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	revised	No	S5‑187315
		S5‑187315	Rel-15 CR 32.291 Introduce OpenAPI extension for SMS charging	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No		S5‑187232
		S5‑187234	R15 CR 32.274 Introduction of Message content charging SMSF	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No		S5‑186297
		S5‑187240	R15 CR 32.274 Introduction of CHF CDR description for SMSF	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No		S5‑186298
		S5‑187242	R15 CR 32.274 Introduction of SMS information converged charging	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	revised	No	S5‑187451	S5‑186299
		S5‑187451	R15 CR 32.274 Introduction of SMS information converged charging	Nokia, Nokia Shanghai Bell	CR	Agreement	Yes	Yes	agreed	No		S5‑187242
7.5	Rel-16 Charging
7.5.1	Volume Based Charging Aspects for VoLTE
7.5.2	Nchf Online and Offline Charging Services (Preliminary work before SA approval)	S5‑187183	Rel16 DraftCR 32.240 Change for Service Based Interface Implications	Huawei	other	Agreement	Yes	Yes	not pursued	No
		S5‑187184	Rel16 DraftCR 32.255 Add Nchf Offline Charging	Huawei	other	Agreement	Yes	Yes	not pursued	No
7.5.3	Charging Enhancement of 5GC interworking with EPC (Preliminary work before SA approval)
7.6	Charging Studies
7.6.1	Study on Charging Aspects of Network Slicing (Preliminary work before SA approval)	S5‑187185	Rel16 TR 32.xxx Skeleton	Huawei	other	Agreement	Yes	Yes	revised	No	S5‑187447
		S5‑187447	Rel16 TR 32.xxx Skeleton	Huawei	other	Agreement	Yes	Yes	approved	No		S5‑187185
		S5‑187186	Rel16 pCR 32.xxx Scope	Huawei	other	Approval	Yes	Yes	revised	No	S5‑187448
		S5‑187448	Rel16 pCR 32.xxx Scope	Huawei	other	Approval	Yes	Yes	agreed	No		S5‑187186
		S5‑187187	Rel16 pCR 32.xxx Update of the Skeleton	Huawei	other	Agreement	Yes	Yes	approved	No
		S5‑187188	Rel16 pCR 32.xxx Update of the Reference	Huawei	other	Agreement	Yes	Yes	revised	No	S5‑187449
		S5‑187449	Rel16 pCR 32.xxx Update of the Reference	Huawei	other	Agreement	Yes	Yes	approved	No		S5‑187188
		S5‑187450	TBD Study on Charging Aspects of Network Slicing (Preliminary work before SA approval)	Huawei	other	Agreement	No	NoThe document was for email approval.	not concluded	No
		S5‑187556	draft TR 32.xxx "Study on Charging Aspects of Network Slicing" incorporating pCRs approved at SA5#122	Rapporteur: Chen Shan	other	Approval	No	YesTdoc not used, this version to appear in S5-187450.	withdrawn	Yes
8	Any Other Business
9	Closing of the meeting (latest by Friday 16.00)