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)