Apex Standards 3GPP Meeting Tracker

---

updated as of Mon, Apr 17, 2023, 08:21 PM UTC (5 hours ago)
Mon, Apr 17, 01:21 PM California
Mon, Apr 17, 10:21 PM Berlin/Paris
Tue, Apr 18, 04:21 AM Beijing

3GPP-S5-148-e    Agenda Item 2 : Approval of the agenda

3GPP-S5-148-e    Agenda Item 3 : IPR and legal declaration

3GPP-S5-148-e    Agenda Item 4.1 : Last SA5 meeting report

3GPP-S5-148-e    Agenda Item 5.1 : Administrative issues at SA5 level

3GPP-S5-148-e    Agenda Item 5.2 : Technical issues at SA5 level

3GPP-S5-148-e    Agenda Item 5.3 : Liaison statements at SA5 level

Provisioning of UE identities/authentication keys: SA3 did not standardize or plan to standardize a mechanism for provisioning information related to the identity of a subscription (i.e., UE Ids or authentication keys) into the 5G core. (TDoc S5-233202)

Authorization: In addition to authorization based on OAuth 2.0, the exposure points might limit the scope of API calls in a fine granular way based on implementation specific policy checks. The currently defined scopes allow authorization on the level of services. (TDoc S5-233202)

Security events/logging information: SA3 interprets the terms event and logging information as originating from the 5G core and includes information relating to successful and unsuccessful authentications of UE and information relating to applied protection of user plane traffic. (TDoc S5-233202)

Network resource management: SA6 has specified Network Resource Management service, Edge enabler service, and 5G Messaging service which specifies procedures and APIs that can be used for managing traffic profile (QoS) for network connections. (TDoc S5-233213)

UE-to-UE QoS bearer: 5G ACIA recognizes that SEAL provides the support for establishing UE-to-UE (UNU) QoS bearer with a single API call. Procedures for Network Slice Capability Exposure for Application Layer Enablement Service specified in 3GPP TS 23.435. (TDoc S5-233213)

TDoc S5-233201:

- SA2 suggests 5G-ACIA member companies contribute directly to the respective 3GPP working groups
- SA2 has discussed aspects highlighted by 5G-ACIA that are not supported by 5GS currently in Rel-18 but there are different views on such aspects being gaps
- Several items within SA2 scope have already been discussed since Rel-16 (Vertical_LAN, IIoT, GMEC)

TDoc S5-233209:

- SA4 Gender Diversity Committee invites SA WGs to RSVP to upcoming invitations at future co-located meetings
- Committee plans to meet every Tuesday evening of face-to-face meetings and invites everyone attending other co-located 3GPP WGs to join dinner meetings
- Committee has re-started regular dinner meetings and invited SA2 and SA3 WGs to join at SA4#122 in Athens

TDoc S5-233210:

- CT4 understands that "optional security" is a deployment aspect for NF Service Producers to configure which security mechanism to use
- CT4 concluded that OpenAPI constructs used in API descriptions of 3GPP 5G Core are in line with recommendations on official OpenAPI 3.0.x documentation
- CT4 points GSMA to detailed description of OAuth/2.0 authorization procedures in 3GPP TS 29.500 and 3GPP TS 29.501

TDoc S5-233328:

- GSMA OPG informs about new versions of several documents and a new document for User-Network Interface APIs
- New versions include GSMA PRD OPG.02 Operator Platform Telco Edge Requirements version 4.0, GSMA PRD OPG.03 Southbound Interface Network Resources APIs version 2.0, and GSMA PRD OPG.04 East-Westbound Interface APIs version 2.0
- GSMA OPG asks 3GPP to take the above information into consideration and directs questions/feedback to GSMA Liaisons (GSMALiaisons@gsma.com)

3GPP-S5-148-e    Agenda Item 6.1 : OAM&P Plenary

TDoc S5-233194: Technical differences highlighted in this document include the target specification of intent for radio network and radio service, the use of msc:ManagedSystem_Operator1 as a managed system connector, and the collection of values or measurements for 3gpp_28312:WeakRSRPRatio.

TDoc S5-233196: This document discusses enhancements for network performance analytics based on statistics information retrieved from OAM, with a focus on collecting information on a per 5QI basis for GBR and Delay-critical GBR traffic to support AI/ML based services.

TDoc S5-233198: This document announces the consent of draft new Recommendation ITU-T Y.3183, which specifies a framework for network slicing management assisted by machine learning leveraging QoE feedback from verticals.

TDoc S5-233199: This document discusses the support of MBSR in the 3GPP 5GS, including the need for MBSR to securely access the serving PLMN OAM server, and the option to configure UE security credentials at registration time by the PLMN or through offline methods.

TDoc S5-233200: This document discusses the applicability of TS 32.404 for solutions based on NR architecture, such as those being defined by the O-RAN Alliance, and the key principles of the O-RAN Alliance in leading the industry towards open, interoperable interfaces, RAN virtualization, and big data enabled RAN intelligence.

TDoc S5-233203: This document discusses user consent for trace reporting and the feasibility and benefit of a Rel-18 user consent mechanism for provisioning information subject to user consent.

TDoc S5-233204: This document discusses user consent of non-public network and the signaling of private network identifiers (CAG ID) to the NG-RAN, which can be covered by signaling public network identifiers (PLMN ID) to the NG-RAN.

TDoc S5-233205: This document discusses QoE metrics and applicable area scope of QoE configuration provided to the UE as part of the QoE configuration container.

TDoc S5-233206: This document discusses the collection of MBS specific QoE metrics per MBS session and the provision of area scope of a QoE configuration within the QoE configuration container.

TDoc S5-233208: This document discusses secured and trusted access to the serving PLMN OAM server by a MBSR.

TDoc S5-233212: This document discusses handover failures related to MRO for inter-system mobility.

TDoc S5-233214: This document discusses the governance of network slice management capabilities exposure and the interface between the consumer and the management system (OSS).

TDoc S5-233243:

- Intent repository provides relevant data of intent model for intent management module and mapping relationship between intent and configuration.
- Intent management module manages the original intent, including capture, categorization, negotiation, and validation of intent, and complete lifecycle management of intent.
- Intent recognition module recognizes the input intent, analyzes the intent, formulates the corresponding configuration based on the analysis results in the intent repository, and outputs the results to intent verification module.
- Supports intent-driven management to strengthen the intelligence and automation of the telecom operation management system.

Example snippet: "By analyzing the input intent and completing the issuance and execution of network instructions through intelligent closed-loop control, intent-driven management can strengthen the intelligence and automation of the telecom operation management system."

TDoc S5-233244:

- Mapping of qualifiers of Analysis|IS-defined constructs to the qualifiers of corresponding SS-constructs is defined.
- Documentation from implementation design phase consists of a technology-dependent data specification.
- Defines a repertoire of types to specify type information in the conceptual model.

Example snippet: "The documentation from the implementation design phase will consist of two parts: 1) A technology-dependent data specification common for several interfaces, e.g., using GDMO or CORBA IDL, corresponding to an internal terminology schema according to the data architecture in [b-ITU-T Z.601]."

TDoc S5-233245:

- Evaluation session creation determines evaluation dimensions, evaluation sub-dimensions, evaluation tasks, and weight of each based on the result of evaluation requirement input block and subsequently creates a session.
- Automatic evaluating mechanism for IL-AITOM is recommended to get the result of intelligence level via monitoring and evaluating.
- Troubleshooting, quality optimization, and cutover maintenance are the activities in operation sub-stages.

Example snippet: "i) Troubleshooting: the activities in this operation sub-stage are to implement monitor, diagnosis and analysis of network and service faults, deal with complaints, generate fault recovery solution, etc. ii) Quality optimization: the activities in this operation sub-stage are to implement monitor to customer experience quality, service quality and network performance, analyse the deterioration issue, generate optimization solution, etc. iii) Cutover maintenance: the activities in this operation sub-stage are to implement cutover, upgrade and maintenance operations for network equipment, pipeline resources or services."

TDoc S5-233246:

- Proposed effectiveness indicators for AI enhanced telecom operation and management aim to evaluate intelligence level with quantitative methods and focus on showing effects and benefits of applying AI.
- Results of the evaluation should be value-oriented and provide more information on the effects and benefits of applying AI.
- Provides principle, overview, dimensions, and method of effectiveness indicators evaluation of AI enhanced telecom operation and management.
- Self-accounting refers to the effectiveness of intelligent capabilities about cost management.

Example snippet: "This draft Recommendation provides the principle, overview, dimensions and method of effectiveness indicators evaluation of AI enhanced telecom operation and management. Self-accounting refer to the effective of intelligent capabilities about cost management."

Technical Differences among TDocs:

1. TDoc S5-233215: This TDoc discusses the ongoing study item on network control repeater (NCR) and looks at how to support the identification and authorization of NCR. Solution 2 uses OAM to perform the authorization for NCR, and OAM provides the authorization response to the gNB. The TDoc also asks SA3 and SA5 to provide feedback on any security issues with the above requirements on OAM.

Example snippet: "For solution 2, OAM performs the authorization for NCR, and OAM provides the authorization response to the gNB. For solution 1 and solution 2, does SA5 foreseen any issue with the above requirements on the OAM?"

2. TDoc S5-233218: This TDoc highlights the key principles of the O-RAN Alliance, which aims to make radio access networks more open and smarter. It discusses the need for a logical connection/attachment point between “EP_Transport” in 3GPP NRM and an object class in IETF model to support cross-domain management of network slice. The TDoc also mentions O-RAN Working Group 9 (WG9) and its efforts in developing O-RAN Transport Network Element (TNE) management interfaces and best practices to support transport capabilities and service demands of RAN and Core subsystems.

Example snippet: "A logical connection / attachment point between “EP_Transport” in 3GPP NRM and an object class in IETF model is required in order to support the cross-domain (RAN, Transport, Virtualization, Core) management of network slice following an example depicted on Fig. 2 on this (https://datatracker.ietf.org/doc/draft-contreras-teas-3gpp-ietf-slice-mapping-00)."

3. TDoc S5-233385: This TDoc specifies requirements and solutions for fault management capabilities scoping NPN and 5G industry terminals while taking 5G ACIA requirements into account. It references 3GPP TR 28.907, which is a study on the enhancement of management of non-public networks. The TDoc states that 3GPP SA5 has initiated its Release 18 normative work on the enhancement of management of non-public networks, with the main objectives being to specify enhanced management of SNPN and PNI-NPN, and to specify requirements and solutions for SLA monitoring and evaluation in NPN scenarios.

Example snippet: "3GPP has published a new TR 28.907 (Study on enhancement of management of non-public networks) which is available at: 3GPP SA5 has now initiated its Release 18 normative work on enhancement of management of non-public networks. The main objectives are to: Specify enhanced management of SNPN and PNI-NPN. Specify requirements and solutions for SLA monitoring and evaluation in NPN scenarios."

4. TDoc S5-233527: This TDoc lists various discussions and proposals related to management aspects of 3GPP networks. The snippets include discussions on making Forge the main source of code, moving all code to Git, a new SID on management aspects of Digital Twin CMDI, and proposed ways forward for the Rel-18 work on EE, among others.

Example snippet: "S5-225594 Forge to become the main source of code Nokia CT WGs S5-225595 Moving all code to Git and Remove it from MsWord Ericsson 3GPP SA5#146 S5-227043 Discussion for a new SID on management aspects of Digital Twin CMDI S5-227069 DP on GSMA NBI Requirements Samsung GSMA OPAG S5-226830 R18 Discussion on Excess Packet Delay threshold for M6 Ericsson, Huawei RAN3 S5-226081 Identification of the Bursts on PDCP SDU Level in CU UP Nokia RAN WGs S5-231010 Proposed way forward for the Rel-18 work on EE Huawei S5-231011 Revised WID Rel-18 Work Item on 5G energy efficiency phase 2 Huawei S5-231032 Rel-18&Rel-19 time plan proposal for OAM SA5 Vice Chair (Huawei) S5-231082 Discussion paper on Using Forge-Git as the primary storage for Code Ericsson CT S5-231148 Discussion paper on KPI, KQI, QoE Nokia S5-231149 3GPP Rel-18 work on EE Huawei All 3GPP TSGs and WGs S5-231150 Ericsson ONAP Correcting the..."

Technical Differences among TDoc S5-233181 and TDoc S5-233188:

TDoc S5-233181:

- Focuses on 6.8.3-FS_URLLC_Mgt.
- WoP#1 (S5-233349 pCR 28.832) corrects terminologies and missing references.
- WoP#2 GROUP#1 (S5-233501/S5-233502) proposes a new solution for configuration of latency for URLLC in RAN.
- WoP#3 GROUP#1 (S5-233499/S5-233500/S5-233511/S5-233512) measures URLLC resource load and reliability.
- Huawei and China Unicom are contributors.

Example snippets:

- WoP#1 (S5-233349 pCR 28.832) proposes to reallocate 6.8.3.5->6.8.3.1.
- WoP#2 (S5-233501) proposes a new solution for configuration of latency for URLLC in RAN.
- WoP#3 (S5-233499) measures URLLC resource load and reliability.
- Contributors: Huawei and China Unicom.

TDoc S5-233188:

- Includes multiple Work Packages (WoPs) related to different areas of enhancement.
- Covers topics such as Basic SBMA enabler enhancements, 5G LAN management, and 5G energy efficiency phase 2.
- No specific contributors mentioned for the overall TDoc.

Example snippets:

- Includes multiple WoPs related to different areas of enhancement.
- Covers topics such as Basic SBMA enabler enhancements, 5G LAN management, and 5G energy efficiency phase 2.
- No specific contributors mentioned for the overall TDoc.

3GPP-S5-148-e    Agenda Item 6.2.1 : Intelligence and Automation

3GPP-S5-148-e    Agenda Item 6.2.2 : Management Architecture and Mechanisms

3GPP-S5-148-e    Agenda Item 6.2.3 : Support of New Services

3GPP-S5-148-e    Agenda Item 6.7.1.1 : FS_eANL_WoP#1

3GPP-S5-148-e    Agenda Item 6.7.1.3 : FS_eANL_WoP#3

3GPP-S5-148-e    Agenda Item 6.7.1.4 : FS_eANL_WoP#4

3GPP-S5-148-e    Agenda Item 6.7.1.5 : Draft TR 28.910

3GPP-S5-148-e    Agenda Item 6.7.3.2 : FS_eIDMS_MN_WoP#2

TDoc S5-233228:

- Layer specific requirements for different services need to be prioritized with expectationTargets for downlink Throughput Per UE, downlink Latency, coverage, and UE Speed.
- This prioritization ensures users latch onto the desired network layer without reconnections.

Example snippet: "Accordingly, new expectationTargets stating the priorities of the different capabilities need to be added, specifically prioritisation levels for downlink Throughput Per UE, downlink Latency, coverage, UE Speed."

TDoc S5-233388:

- Intent driven MnS should provide current performance and context information for corresponding expectation targets.
- MnS consumer can use this information to validate intent fulfillment and update targets if needed.
- Configuration for report output is external to the Intent, allowing for different reports per Intent.

Example snippet: "The intent driven MnS should have the capability to enable the MnS consumer to obtain intent report information with current performance value for corresponding expectation targets."

TDoc S5-233390:

- Intent driven MnS should inform authorized MnS consumer about possible solutions for conflicts, including termination of intent instances or recommended intent instances.
- MnS consumer can modify or delete intent or intent expectations/targets to solve conflicts.
- MnS producer can provide solutions for conflicts and notify MnS consumer about additional information for the conflict.

Example snippet: "The intent driven MnS should have the capability to allow the authorized MnS consumer to modify or delete the intent, intent expectation or expectation targets, or give intent conflict handling guidelines to MnS producer to solve such intent conflict."

TDoc S5-233392:

- Intent driven MnS should provide current performance and context information for corresponding expectation targets.
- MnS consumer can use this information to validate intent fulfillment and update targets if needed.
- MnS consumer can obtain intent report information with intent conflict information and specify the content of the report.

Example snippet: "The intent driven MnS should have the capability to enable the MnS consumer to obtain intent report information with current performance value for corresponding expectation targets."

- The intent driven MnS Producer should allow the authorized MnS Consumer to provide the deadline expressing the maximum duration before the intent is initially satisfied or the latest time point by which the intent should be satisfied, or the maximum duration of the intent being satisfied.
- The MnS producer can optimize its intent fulfilment plan based on the maximum unfulfilled duration specified by the MnS Consumer.
- The authorized MnS Consumer can request intent fulfilment information periodically or event-triggered.
- The MnS producer needs to respond to intent fulfilment information at the beginning and during the execution of the intent.
- The intent driven MnS should have the capability to enable the MnS consumer to obtain intent report information with current performance value for corresponding expectation targets.
- The intent report should also contain the current and optional predicted value for performance indicated by corresponding expectation targets.
- The MnS consumer can use the intent report to validate whether the intent is really fulfilled and to evaluate whether the intent needs to be updated.
- The intent driven MnS should have the capability to enable the MnS consumer to obtain intent report information with current context information for corresponding expectation targets.
- The intent driven MnS should have the capability to enable the MnS consumer to obtain intent report information with intent conflict information.
- The intent driven MnS should have the capability to enable the MnS consumer to specify the content of the report.
- The solution extends the existing model in 28.312 by adding a new attribute "monitorIndicator" to the Intent IOC information needs to be specified as one of the consumer’s requirements for intent report.
- A new attribute "executionTime" is added to the Intent IOC to indicate when is to be executed and whether intent fulfilment information needs to be reported.

For example, TDoc S5-233394 and TDoc S5-233513 both highlight the need for the MnS Producer to allow the MnS Consumer to specify the maximum duration of the intent being satisfied, while TDoc S5-233476 and TDoc S5-233477 focus on the capability of the intent driven MnS to enable the MnS Consumer to obtain intent report information with current performance value and intent conflict information. Furthermore, TDoc S5-233513 introduces new attributes to the Intent IOC to indicate when the intent should be executed and whether intent fulfilment information needs to be reported. Overall, these technical differences emphasize the importance of providing flexibility and adaptability for the MnS Producer and empowering the MnS Consumer with relevant intent report information to ensure the intent is fulfilled effectively.

One technical difference highlighted in TDoc S5-233231 is the use of Closed-loop Control (CC) as a producer of CL management services. This involves the consumer sending a request in the form of an intent to the CLC for composition, providing information that may be used by the CLC to identify the required components. Figure 4.6.1-1 provides an example of the relations among closed loop components.

Another technical difference highlighted in TDoc S5-233473 is the use of the MnS consumer to update intent information based on infeasible reason and trigger the intent fulfillment feasibility check again. Feasibility check result info is recommended in the response to the intent creation and modification request to allow the MnS consumer to obtain the feasibility check result. The MnS producer may inform the intent fulfillment feasibility check result and the infeasible reason to MnS consumer when the intent fulfillment feasibility check is finished.

Example snippets from TDoc S5-233231:
- "Each CL may implement a Closed-loop Control (CC) as the producer of CL management services that support control capabilities used to manage or control the closed loop and to support interaction with the external world."
- "The consumer (e.g. the operator) sends a request in form of an intent to the CLC for composition, providing information that may be used by the CLC to identify the required components."
- "Given a set of deployed network functions and/or management functions, the Closed-Loop Control may configure different network and management functions to achieve the desired closed loop goals based on intents with the input “context” (e.g. capabilities, control or use case) provided by the operator."
- "The network optimization expectation targets may express the desired optimization outcomes."

Example snippets from TDoc S5-233473:
- "In case the intent fulfillment feasibility check result is infeasible, MnS consumer may update the intent information based on infeasible reason and may trigger the intent fulfillment feasibility check again."
- "Regarding the option#1, it is recommended to introduce the feasibility check result info (including feasibilityResult and inFeasibleReason) in the response to the intent creation and modification request(intent report model) to allow the MnS consumer to obtain the feasibility check result."
- "The MnS producer may inform the intent fulfillment feasibility check result and the infeasible reason to MnS consumer when the intent fulfillment feasibility check is finished."
- "MnS consumer requests intent-driven MnS producer to check the feasibility for intent fulfillment before requesting intent creation or modification."

TDoc S5-233229:

- Intent Driven Management Service enables MnS consumers to express cell selection priorities on frequency layers for a specific service or network slice.
- Network Management and Optimization can inform authorized MnS consumers about the enforcement status of cell selection priority for a specific service or network slice.
- Multi-layered networks with varying throughput, latency, and coverage capabilities require initial configuration for network layer prioritization suitable for each slice or service to ensure expected network coverage and capacity.
- Example of use case: many layer-specific requirements, such as coverage, capacity, mobility, and latency, differ for different network slices based on actual expectations from the network slices or their supported services.
- The initial configuration should ensure that the slice or service user latches onto the desired network layer to avoid reconnections.

TDoc S5-233389:

- Evaluating the influence of energy-saving actions on service experience, such as UL/DL RAN UE throughput and latency, is challenging.
- MnS consumers can express intent expectations for RAN energy saving in the specified area, including RAN energy saving target, service experience, frequencies, and RATs to be considered for energy saving.
- Intent approach for energy saving enables the 3GPP management system to balance energy saving effect and service experience using intelligence mechanisms.
- Investigating the model for intent expectation for RAN energy saving based on the generic intent model and radio network expectation defined in TS 28.312 is essential.

TDoc S5-233474:

- Reusing attribute "observationTime" defined in clause 4.5.1 to represent the period for evaluating the fulfilment information for corresponding Expectation Targets, IntentExpectation and Intent is proposed.
- Generic intent information model needs enhancement in aspects such as activating/deactivating intent management capabilities, defining applicable scope, and intent fulfilment evaluation period.
- Examples of performance KPIs related to 5GC that can be used as Expectation Targets are established PDU session number, maximum registered subscribers, and inter-AMF handover number for 5GC subnetwork.

TDoc S5-233475:

- Reusing attribute "observationTime" defined in clause 4.5.1 to represent the period for evaluating the fulfilment information for corresponding Expectation Targets, IntentExpectation and Intent is proposed.
- Enhancing the targetCondition attribute in ExpectationTarget<> and the contextCondition attribute in Context> with additional condition combination mechanism is proposed.
- The current targetCondition and contextCondition attributes can only represent simple conditions and cannot represent complex conditions composed of multiple conditions in logical relationships.

3GPP-S5-148-e    Agenda Item 6.7.3.5 : FS_eIDMS_MN_WoP#5

Technical differences between 3GPP intent management operations and TM Forum intent management operations:

- Definition: TM Forum defines the Intent Management operations in TMF921A, while 3GPP SA5 started the work item intent driven management for mobile networks in 2018 and completed its Release 17 work on the intent driven management services for mobile networks in June 2022, corresponding published specification is TS 28.312.
- Applicability: TM Forum intent management operations are applicable for TM Forum intent, while 3GPP intent driven MnS can be applicable for following kinds of standardized reference interfaces for the management of 3GPP network and services: Management interactions for Intent-NOP between NOP and NEP; Management interactions for Intent-CSP between CSP and NOP.
- Operations: TM Form intent management API defines the Management operations for Intent, which includes the intent management operations between MnS consumer and MnS producer for 3GPP intent. On the other hand, 3GPP SA5 specifies the concept, use cases, requirements and solutions (including intent management operations and intent model) for the intent driven management for service or network management.
- Scope: 3GPP SA5 covers aspects such as operation, assurance, fulfillment and automation, including management interaction with entities external to the network operator (e.g. service providers and verticals), while TM Forum intent management operations are focused on intent management operations between Intent Owner and Intent Handler for TM Forum intent.

Example snippets from the original TDoc:

- TMF921A [5] defines the Intent Management operations in TM Forum intent. (TDoc S5-233273)
- In this deployment scenario, 3GPP intent driven MnS can be applicable for following kinds of standardized reference interfaces for the management of 3GPP network and services: - Management interactions for Intent-NOP between NOP and NEP; - Management interactions for Intent-CSP between CSP and NOP. (TDoc S5-233273)
- TS 28.312 specifies the concept, use cases, requirements and solutions (including intent management operations and intent model) for the intent driven management for service or network management. (TDoc S5-233276)
- 3GPP SA5 covers aspects such as operation, assurance, fulfillment and automation, including management interaction with entities external to the network operator (e.g. service providers and verticals), while TM Forum intent management operations are focused on intent management operations between Intent Owner and Intent Handler for TM Forum intent. (TDoc S5-233276)

3GPP-S5-148-e    Agenda Item 6.7.3.6 : Draft TR 28.912

3GPP-S5-148-e    Agenda Item 6.7.4.1 : FS_NETSLICE_IDMS_WoP#1

3GPP-S5-148-e    Agenda Item 6.7.4.2 : FS_NETSLICE_IDMS_WoP#2

3GPP-S5-148-e    Agenda Item 6.7.4.3 : FS_NETSLICE_IDMS_WoP#3

3GPP-S5-148-e    Agenda Item 6.7.4.4 : FS_NETSLICE_IDMS_WoP#4

3GPP-S5-148-e    Agenda Item 6.7.5.1 : FS_AIML_MGMT_WoP#1

3GPP-S5-148-e    Agenda Item 6.7.5.2 : FS_AIML_MGMT_WoP#2

Technical Differences between TDoc S5-233271 and TDoc S5-233338:

1. TDoc S5-233271 includes an analytics deviation indicator which determines the prediction calculated by a data analytics function exceeds a configurable certain value. TDoc S5-233338 does not mention this.

Example snippet from TDoc S5-233271: "The analytics deviation indicator, such as a threshold (determining that the prediction calculated by a data analytics function exceeds a configurable certain value, corresponding to the prediction available at a different data analytics function, by a “threshold”)."

2. TDoc S5-233271 includes the area of interest, geographical area or TA while TDoc S5-233338 does not mention this.

Example snippet from TDoc S5-233271: "Area of interest, geographical area or TA."

3. TDoc S5-233338 includes the definition of one or more data features, minimum number of data samples to be obtained and criteria for obtaining the most supporting data samples while TDoc S5-233271 does not mention this.

Example snippet from TDoc S5-233338: "Definition of one or more data features - minimum number of data samples to be obtained - criteria for obtaining the most supporting data samples."

4. TDoc S5-233338 mentions the filtering of data samples in accordance with the one or more requested features and other provided criteria in order to obtain the most supporting data samples for re-training. TDoc S5-233271 does not mention this.

Example snippet from TDoc S5-233338: "All data samples that have been used for inference are filtered in accordance with the one or more requested features and other provided criteria in order to obtain the most supporting data samples for re-training."

5. TDoc S5-233271 mentions MLCapabilityCoordinationResponse which represents the response indicating the analytics or data obtained according to the MLCapabilityCoordinationRequest. TDoc S5-233338 does not mention this.

Example snippet from TDoc S5-233271: "MLCapabilityCoordinationResponse - this information element may represent the response indicating the analytics or data obtained according to the MLCapabilityCoordinationRequest."

6. TDoc S5-233271 mentions the target objects, e.g., gNBs, and the related characteristics while TDoc S5-233338 does not mention this.

Example snippet from TDoc S5-233271: "The target objects, e.g., gNBs, and the related characteristics."

7. TDoc S5-233338 mentions MLDataSamplesRequest which represents the request for obtaining the data samples that are likely to have more value for re-training from all data samples that have been used for inference. TDoc S5-233271 does not mention this.

Example snippet from TDoc S5-233338: "MLDataSamplesRequest - this IOC represents the request for obtaining the data samples that are likely to have more value for re-training from all data samples that have been used for inference."

TDoc S5-233340:
- The ML training MnS producer instantiates multiple MLTrainingProcess MOI(s) that are responsible for collecting and preparing training data for each ML entity in the group.
- Services should be supported to facilitate mapping between use cases and potentially multiple ML entities.
- ExpectedRunTimeContext may include information related to specific data extraction, transformation, and load.

TDoc S5-233382:
- Efficient ML entity re-training is supported through the use of MLDataSamplesRequest IOC.
- MLDataSamplesRequest represents the request for obtaining data samples that are likely to have more value for re-training.
- The amount of data used for re-training and the time needed for the model to converge towards maximum performance needs to be minimized in conditions of low processing power and/or limited energy consumption.

TDoc S5-233384:
- A large amount of data instances or measurement data points may not add value for ML model training.
- Analysis of data related to the importance of data instances during training is needed.
- The challenge of optimizing training data usage during model training can be left to the specific ML model training function.

TDoc S5-233539:
- The AI/ML inference producer can be queried to provide information on supported inference trustworthiness capabilities.
- The training data, testing data, and inference data used for ML training, testing, and inference may need to be pre-processed according to the desired trustworthiness measure of the ML model.
- ML training may need to be performed according to the desired trustworthiness measure of the ML model.

Technical differences between TDoc S5-233491, S5-233492, S5-233525, and S5-233526:

1. S5-233491 introduces the concept of ML entity joint training, which involves integrating multiple ML entities into a complete model or solution through joint learning. This allows for better performance and generalization, as potential information in related ML entities can be utilized.

Example snippet from S5-233491: "For some complex tasks, focusing on a single ML entity may ignore potential information in related ML entities that could improve the tasks."

2. S5-233492 focuses on ML entity re-training, which involves re-training a ML model using new data and learned model parameters as a starting point to continually learn the newest patterns and changes. This allows for adjustments to be made quickly and maintains good performance by constantly learning from past experience and newest data patterns.

Example snippet from S5-233492: "Re-training enables ML model to be adjusted quickly and then maintain a good performance by constantly learning from past experience and newest data patterns."

3. S5-233525 adds a description for ML entity joint training, similar to S5-233491, but with a focus on integrating multiple ML entities into a complete model or solution through joint learning.

Example snippet from S5-233525: "ML entity joint training refers to integrate multiple ML entities into a complete model or solution through joint learning."

4. S5-233526 adds a description for ML entity re-training, similar to S5-233492, but with a focus on how the ML entity needs to change and update as the data changes.

Example snippet from S5-233526: "The changes of data and context have a major impact on the performance of a trained model. As such, the ML entity needs to change and update as the data changes."

Technical Differences Among TDocs:

1. TDoc S5-233224: This TDoc discusses the possibility of requesting an improved version of ML entities and updating MLUpdateJobs directly by an authorized MnS consumer. The 3GPP management system should have a capability for the authorized MnS consumer to manage the request and subsequent process, and adjust the characteristics of the capability update. The prerequisite action for triggering the update of ML entities is re-training of the constituent AI/ML inference functions.

2. TDoc S5-233339: This TDoc lists the potential requirements for updating AI/ML capabilities or ML entities through an authorized MnS consumer. The 3GPP management system should have a capability for the AI/ML MnS producer to inform the authorized MnS consumer of the availability of AI/ML capabilities or versions of ML entities and readiness to update the AI/ML capabilities of the respective network function when triggered. The 3GPP management system should also have a capability for the authorized MnS consumer to manage the request and subsequent process, or to adjust the characteristics of the capability update. The 3GPP management system should enable the AI/ML MnS producer to inform the authorized MnS consumer about the process or outcomes related to any request for updating the AI/ML capabilities or ML entities.

3. TDoc S5-233515: This TDoc discusses the potential requirements for ML testing MnS producer to report the results of a specific instance of ML testing process with the result of a successful ML entity testing containing the inference output for each testing data example. The ML testing MnS producer may have a capability for an authorized consumer to request the joint testing of multiple ML entities. The ML testing MnS producer should have a capability to enable the authorized consumer to request the testing of a specific ML entity and define the reporting characteristics related to a specific instance of ML testing request.

Example Snippets from the Original TDocs:

- TDoc S5-233224: "In such cases, the consumer of the exposed AI/ML services (e.g., the operator, a management function, or a consumer network function) may wish to request for an improved version of the ML entities, i.e., to have the ML entities be updated."
- TDoc S5-233339: "the 3GPP management system should have a capability for the AI/ML MnS producer to inform an authorized MnS consumer of the availability of AI/ML capabilities or ML entities or versions thereof (e.g., as learned through a training process or as provided via a software update) and the readiness to update the AI/ML capabilities of the respective network function when triggered."
- TDoc S5-233515: "The ML testing MnS producer should have a capability to report to an authorized consumer the results of a specific instance of ML testing process with the result of a successful ML entity testing containing the inference output for each testing data example."

3GPP-S5-148-e    Agenda Item 6.7.5.3 : FS_AIML_MGMT_WoP#3

1. Technical differences in the process of ML Inference Emulation
- The emulation orchestration process involves choosing the right type and instance of an emulation environment to which an ML entity, AI/ML inference Function or the action thereof may be tested depending on the needs of the function to be tested and the available emulation environments and their resources.
- The emulation process may also involve executing the ML entity, AI/ML inference Function or its action on the real network but in a controlled fashion
- The producer of ML inference emulation orchestration MnS should have a capability to graduate an ML entity, AI/ML inference function or the different action thereof through different levels of trust each expressing a different degree to which the ML entity, AI/ML inference function, or action has been confirmed as trusted.

Example snippet from TDoc S5-233225: "The producer of ML inference emulation orchestration MnS should have a capability to graduate an ML entity, AI/ML inference function or the different action thereof through different levels of trust each expressing a different degree to which the ML entity, AI/ML inference function or action has been confirmed as trusted."

2. Technical differences in the reporting of AI/ML capabilities coordination
- The result of the coordination may be communicated towards the consumer(s) and hence there is a need to enhance the reporting in order to capture the deviation of predictions (and / or the related context) so the consumer can gain a better understanding regarding the coordination of AI/ML capabilities.
- The 3GPP management system should have a capability enabling a producer of coordination services to provide to a consumer of coordination services a specific objective for that network element or function.
- The 3GPP management system should have a capability enabling a network element or function consuming the coordination services to provide to a producer of coordination services information or feedback indicating the degree to which one or more of the specific objectives is achieved.

Example snippet from TDoc S5-233227: "The 3GPP management system should have a capability enabling a producer of coordination services to provide to a consumer of coordination services a specific objective for that network element or function."

3. Technical differences in the pre-processing of data for ML training and inference
- The AI/ML inference producer can be queried to provide information on the supported inference trustworthiness capabilities enabling the AI/ML inference consumer to request for a subset of supported inference trustworthiness characteristics to be configured, measured, and reported.
- The training data, testing data, and inference data used for ML training, testing, and inference, respectively, may need to be pre-processed according to the desired trustworthiness measure of the ML model.
- This solution extends the MLTrainingRequest IOC by adding a new attribute, e.g., dataTrustworthinessRequirements, to allow the ML entity training MnS consumer to request the ML entity training MnS producer to pre-process the training data with specified data trustworthiness requirements before training the ML model.
- The ML assessment producer can be queried to provide information on the supported assessment trustworthiness capabilities enabling the ML assessment MnS consumer to request for a subset of supported assessment trustworthiness characteristics to be configured, measured, and reported.
- The ML assessment may need to be performed according to the desired trustworthiness measure of the ML model.

Example snippet from TDoc S5-233269: "The training data, testing data and inference data used for ML training, testing and inference, respectively, may need to be pre-processed according to the desired trustworthiness measure of the ML model."

TDoc S5-233270:

- This solution enables the AI/ML inference consumer to request for a subset of supported inference trustworthiness characteristics to be configured, measured, and reported by the AI/ML inference producer.
- The training, testing, and inference data used for ML may need to be pre-processed according to the desired trustworthiness measure of the ML model.
- The MLTrainingRequest IOC is extended by adding a new attribute, dataTrustworthinessRequirements, to allow the ML entity training MnS producer to pre-process the training data with specified data trustworthiness requirements before training the ML model.
- The ML Inference Request related IOC is extended by adding a new attribute, inferenceTrustworthinessRequirements, to allow the ML entity inference MnS producer to infer the decisions with specified inference trustworthiness requirements.
- The newly introduced attributes, trainingTrustworthinessRequirements and achievedTrainingTrustworthiness, are of data type modelTrustworthiness.

TDoc S5-233282:

- This IOC allows an MOI to be created on the ML inference MnS Producer with attributes such as data features, minimum data samples required, and criteria for obtaining supporting data samples.
- All data samples used for inference are filtered in accordance with the requested features and provided criteria to obtain the most supporting data samples for re-training.
- The MLDataSamplesResponse IOC represents the response indicating the data obtained according to the MLDataSamplesRequest.
- The training report is extended to include energy consumption aspects of an ML entity training, such as used energy saving strategy, actual start and finalization of the training process, information on hardware characteristics, and statistics on energy consumption.

TDoc S5-233341:

- This solution enables the ML assessment MnS consumer to request for a subset of supported assessment trustworthiness characteristics to be configured, measured, and reported by the ML assessment producer.
- The training, testing, and inference data used for ML may need to be pre-processed according to the desired trustworthiness measure of the ML model.
- The MLTrainingRequest IOC is extended by adding a new attribute, dataTrustworthinessRequirements, to allow the ML entity training MnS producer to pre-process the training data with specified data trustworthiness requirements before training the ML model.
- The ML assessment producer can be queried to provide information on the supported assessment trustworthiness capabilities enabling the ML assessment MnS consumer to request for a subset of supported assessment trustworthiness characteristics to be configured, measured, and reported.
- Robustness-related indicators: the robustness indicators of the data or the ML entity.

TDoc S5-233400:

- The request for updating ML capabilities may state the identifier of the specific AI/MLEntity that the MnS consumer wishes to be updated.
- The request for update may be constrained by specific requirements, i.e., the MnS consumer may request that the update only happens if certain characteristics/update-trigger conditions are fulfilled.
- The consumer of the exposed AI/ML services may wish to request for an improved version of the ML entities, i.e., to have the ML entities be updated.
- REQ-AIML_UPDATE-4: the 3GPP management system should have a capability for the AI/ML MnS producer to inform an authorized MnS consumer about the process or outcomes related to any request for updating the AI/ML capabilities or ML entities.

- TDoc S5-233226 describes technical differences in activation and deactivation methods for AI/ML inference capabilities.
- Instant activation and deactivation is supported by extending the generic framework described in clause 5.10.4.2.1 with attributes for instant activation and deactivation of the ML entity or inference function.
- Policy-based activation and deactivation is supported by extending the generic framework described in clause 5.10.4.3.1 with attributes for activation and deactivation based on a given policy.
- Schedule-based activation and deactivation is supported by extending the generic framework described in clause 5.10.4.3.1 with attributes for activation and deactivation based on a given schedule.
- MnS producers for AI/ML inference management may provide different steps for progressive activation of capabilities, enabling versatile activation.
- TDoc S5-233342 describes the use of IOCs, attributes, and performance data for interaction between MnS producers and consumers to support AI/ML inference emulation.
- A new IOC named AvailableEmulationEnvironment or EmulationSubNetwork, or the existing SubNetwork IOC with an attribute indicating it is used for emulation, represents the available emulation environment.
- This solution reuses existing capabilities and enables both co-located and distributed implementation and deployment of ML testing MnS and AI/ML inference emulation MnS producers using a consistent NRM-based approach.
- REQ-AI/ML_EMUL-1087 requires MnS producers for AI/ML inference emulation orchestration to have the capability to graduate an ML entity, AI/ML inference function, or different action through different levels of trust, each expressing a different degree of trustworthiness.

Example snippet from TDoc S5-233226 to support instant activation and deactivation: "The AI/ML inference capabilities to be instantly activated/deactivated on the ML entity or inference function."

Example snippet from TDoc S5-233226 to support policy-based activation and deactivation: "AI/ML inference capabilities to be activated/deactivation on the ML entity or inference function based on the given policy."

Example snippet from TDoc S5-233226 to support schedule-based activation and deactivation: "AI/ML inference capabilities to be activated/deactivation on the ML entity or inference function based on the given schedule."

Example snippet from TDoc S5-233226 to support versatile activation: "It enables a versatile activation of AI/ML capabilities."

Example snippet from TDoc S5-233342 to support IOC for available emulation environment: "The IOC representing the available emulation environment, e.g., a new IOC named as AvailableEmulationEnvironment, or EmulationSubNetwork, or the existing SubNetwork IOC with an attribute indicating it is a subnetwork used for emulation."

Example snippet from TDoc S5-233342 to support reuse of existing capabilities: "It does not only reuse the existing capabilities (provisioning MnS operations and notifications) to a greater extent, but also provides the flexibility to facilitate both co-located and distributed implementation and deployment of ML testing MnS and AI/ML inference emulation MnS producers by using the consistent NRM-based approach."

Example snippet from REQ-AI/ML_EMUL-1087 to support graduation of trust levels: "The MnS producer for AI/ML inference emulation producer of ML inference emulation orchestration MnS should have a capability to graduate an ML entity, AI/ML inference function or the different action thereof through different levels of trust each expressing a different degree to which the ML entity, AI/ML inference function or action has been confirmed as trusted."

3GPP-S5-148-e    Agenda Item 6.7.5.6 : FS_AIML_MGMT_WoP#6

3GPP-S5-148-e    Agenda Item 6.7.5.7 : FS_AIML_MGMT_WoP#7

3GPP-S5-148-e    Agenda Item 6.7.6.2 : FS_MANWDAF_WoP#2

3GPP-S5-148-e    Agenda Item 6.7.6.3 : Draft TR 28.864

3GPP-S5-148-e    Agenda Item 6.7.7.1 : FS_FSEV_WoP#1

3GPP-S5-148-e    Agenda Item 6.7.7.2 : FS_FSEV_WoP#2

3GPP-S5-148-e    Agenda Item 6.8.1.1 : FS_eSBMA_WoP#1

3GPP-S5-148-e    Agenda Item 6.8.1.3 : FS_eSBMA_WoP#3

1. TDoc S5-233330 refers to a proposal in document 28.621, while TDoc S5-233334 refers to a proposal in document 28.623.
- Example from TDoc S5-233330: "pCR 28.925 Proposal in 28.621 Document for: Approval"
- Example from TDoc S5-233334: "pCR 28.925 Proposal in 28.623 Document for: Approval"
2. The two TDocs have different agenda items.
- Example from TDoc S5-233330: "Agenda Item: 6.8.1.3"
- Example from TDoc S5-233334: "Agenda Item: 6.8.1.3"
3. Both TDocs request the group to discuss and approve.
- Example from TDoc S5-233330: "The group is asked to discuss and approval."
- Example from TDoc S5-233334: "The group is asked to discuss and approval."
4. The TDocs have the same sections, including references, rationale, detailed proposals, and conclusion/recommendation.
- Example from TDoc S5-233330: "2 References", "3 Rationale", "4 Detailed proposals", "5 Conclusion and Recommendation"
- Example from TDoc S5-233334: "2 References", "3 Rationale", "4 Detailed proposals", "5 Conclusion and Recommendation"

TDoc S5-233329:

- The group is asked to discuss and approve the inclusion of requirements for SBMA or the creation of a new TS for SBMA architecture requirements.
- The proposed solutions address issues in 3GPP TS 28.621, which currently only has IRP requirements.
- The issue is not covered in the current 3GPP TR28.925.

Example snippet: "The content has IRP only requirements."

TDoc S5-233332:

- Three alternative solutions are proposed to address issues in TS28.622: keep both IRP and SBMA information service in TS28.622, create a new TS for SBMA information service only and keep TS28.622 as is (with updates in a new TS after R18).
- References 3GPP TS 28.622 and 3GPP TR 28.925.

Example snippet: "Three alternative solutions are proposed in pCR S5-xxxxx to address the issues in TS28.622."

3GPP-S5-148-e    Agenda Item 6.8.1.5 : FS_eSBMA_WoP#5

3GPP-S5-148-e    Agenda Item 6.8.1.6 : FS_eSBMA_WoP#6

3GPP-S5-148-e    Agenda Item 6.8.2.1 : FS_eSBMAe_WoP#1

3GPP-S5-148-e    Agenda Item 6.8.2.2 : FS_eSBMAe_WoP#2

3GPP-S5-148-e    Agenda Item 6.8.2.3 : FS_eSBMAe_WoP#3

TDoc S5-233265 proposes potential requirements for a new key issue of advertising NRM properties by MnS producer. The proposal suggests changes to TR 28.831 and highlights the following differences:

- Proposed key issue for advertising NRM properties by MnS producer
- Potential requirements for the new key issue
- Revision of previous contribution S5-232099

Example snippet from TDoc S5-233265: "This contribution proposes the potential requirements for the mentioned key issue."

TDoc S5-233267 proposes a potential solution for the same key issue of advertising NRM properties by MnS producer. The proposal introduces a mechanism for the MnS producer to advertise the URI from where the MnS consumer can retrieve the advertised NRM properties. Attribute mnsAddressForNrmProperties is used to provide addressing information for the NRM properties of the Management Service producer.

Example snippet from TDoc S5-233267: "This potential solution introduces mechanism for the MnS producer to advertise the URI from where the MnS consumer can retrieve the advertised NRM properties described in potential solution #1 for each MnS producer."

TDoc S5-233268 proposes changes to clause 4.x of TR 28.831, which defines notifications supported by MnS producers. The proposal suggests that an MnS producer might support all, a subset, or none of the defined notifications, and introduces a new key issue for advertising notifications supported by MnS producer.

Example snippet from TDoc S5-233268: "List of notifications applicable for each IOC and attribute are defined in common, but an MnS producer might support all or a subset or none of the defined notifications."

TDoc S5-233292 proposes a harmonized approach for node selection by MnS consumers. The proposal suggests that a MnS consumer needs to specify the nodes to be returned in read requests, when requesting measurement collection or threshold monitoring. The proposal describes a method for node selection in the context of notification subscriptions and suggests that the 3GPP management system should support one harmonized method for node selection.

Example snippet from TDoc S5-233292: "The 3GPP management system shall support one harmonized method for node selection, at least as one alternative."

The "reason" property provides more details on the error conditions than the "type" property.
- Example: [TDoc S5-233289]

The "badObjects" property provides information about bad objects in 3GPP JSON Merge Patch requests.
- Example: [TDoc S5-233286]

The "details" and "instance" properties defined in IETF RFC 7807 are not mentioned in this TDoc.

The "status", "type", "title", and "reason" properties are applicable to all HTTP methods and request media types.
- Example: [TDoc S5-233286]

The "status", "type", "title", "reason", and "queryParams" properties are included in the error response JSON array of JSON objects.
- Example: [TDoc S5-233286]

The "badObjects" property is applicable only for 3GPP JSON Merge Patch.
- Example: [TDoc S5-233286]

The "reason" property has specific valid values for error responses related to HTTP GET with or without query parameters.
- Example: [TDoc S5-233288]

The "reason" property provides information on the type of error, such as "ATTRIBUTE_INVARIANT" or "NEW_OBJECT_PARENT_NOT_FOUND".
- Example: [TDoc S5-233289] [TDoc S5-233290]

The "badAttributes" property is used to indicate attributes that are not readable in an error response related to HTTP GET with query parameters.
- Example: [TDoc S5-233290]

The "status" property may repeat the same code in a problem description.
- Example: [TDoc S5-233286]

Valid values for the "reason" property related to 3GPP JSON Merge Patch request include "OBJECT_CREATION_NOT_ALLOWED".
- Example: [TDoc S5-233290]

Technical Differences among TDoc S5-233266 and S5-233291:

TDoc S5-233266:
1. This TDoc defines a JSON structure for IOCs.
2. It defines an array of multiple ClassA-Single objects.
3. It defines attributes for the ClassA-Single object as a JSON object.
4. It illustrates a JSON patch statement that removes an attribute from the ClassA-Single object.
5. It provides a response example for a GET request with an error message in JSON format.


Example snippet from TDoc S5-233266:
- The JSON patch statement that removes attributeE of ClassA-Single object:
[ { "op": "remove", "path": "/ClassA-Single/properties/attributes/properties/attributeE" } ]

TDoc S5-233291:
1. This TDoc defines HTTP error response codes and messages.
2. It defines a specific error message for an unsupported granularity period in metric collection.
3. It lists possible error reasons for the error type "APPLICATION_LAYER_ERROR".
4. It proposes modifications for TR 28.831[1] related to error reasons.

Example snippet from TDoc S5-233291:
- The error message for unsupported granularity period in metric collection:
[ { "type": "APPLICATION_LAYER_ERROR", "reason": "GRANULARITY_PERIOD_NOT_SUPPORTED", "title": "The requested granularity period for metric collection is not supported." } ]

1. TDoc S5-233285: Technical differences include:
- Supported 4xx client error status codes
- Indicates specific errors such as malformed request syntax, unsupported HTTP version, or missing Content-Length field
- Based on IETF RFC 7231
- Provides specific reference and description for each error code

Example snippet: "400 Bad Request indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing)."

2. TDoc S5-233287: Technical differences include:
- Error codes are not standard HTTP status codes
- Indicates errors specific to the MnS Producer application
- Provides more specific details for each error code, such as REQUEST_OBJECT_TREE_MISMATCH or UNSPECIFIED_SERVER_ERROR
- Includes validation of modifications against information model schema

Example snippet: "REQUEST_OBJECT_TREE_MISMATCH (HTTP error code: 422 Unprocessable ContentEntity): The request message is well formed and understood but cannot be completed due to the current state of the object tree on the MnS Producer."

3. VALIDATION_ERROR: Technical differences include:
- Indicates an error in the validation process
- Could be related to the information model schema or other validation rules
- Does not provide specific details about the error

Example snippet: "And validation of the modifications requested to be applied to the information model against the definition (schema) of the information model, for example if a new instance of a certain object class is allowed to be contained under the class of the specified parent object."

3GPP-S5-148-e    Agenda Item 6.8.2.4 : FS_eSBMAe_WoP#4

3GPP-S5-148-e    Agenda Item 6.8.2.5 : FS_eSBMAe_WoP#5

3GPP-S5-148-e    Agenda Item 6.8.2.7 : FS_eSBMAe_WoP#7

3GPP-S5-148-e    Agenda Item 6.8.3.2 : FS_URLLC_Mgt_WoP#2

3GPP-S5-148-e    Agenda Item 6.8.3.3 : FS_URLLC_Mgt_WoP#3

3GPP-S5-148-e    Agenda Item 6.8.3.5 : Draft TR 28.832

3GPP-S5-148-e    Agenda Item 6.8.4.3 : FS_MCVNF_WoP#3

3GPP-S5-148-e    Agenda Item 6.8.4.5 : Draft TR 28.834

3GPP-S5-148-e    Agenda Item 6.8.5.1 : FS_MANS_ph2_WoP#1

- The MOP in NG-RAN must have the capability to report different subscribed configuration and performance measurements for each POP based on their operation requirements.
- The management system of MOP must also be able to provide full or subscribed alarm data for each POP.
- The management architecture for MOCN should support for NG-RAN, and management requirements and solutions have been identified for different POP’s network operation in NG-RAN.
- For 5G MOCN Networking Sharing, different POP needs different data for personalized operation and maintenance services.
- The data flow of alarm data for NG-RAN MOCN network sharing scenario is depicted in figure 5.3-2.
- Operator-instance filtering for configuration and alarm data operation is defined in TS 28.532.
- The getMOIAttribute operation must have the capability to filter operator-specific managed objects and the getAlarmList operation must have the capability to filter operator-specific alarms.
- The pLMNId parameter is used to distinguish operator granularity and prevent data modification by MOP-NM while ensuring data fairness per POP.
- Different configuration and performance measurements for each POP on MOP-SR-DM need to be forwarded to MOP-NM.

Example snippets:
- "According to different POPs’ operation requirements, the 3GPP management system of the MOP shall have capability to report different subscribed configuration and performance measurements."
- "The management system of MOP shall have capability to report different subscribed configuration and performance measurements and to provide full or subscribed alarm data for each POP."
- "The study has identified management requirements and solutions for different POP’s network operation in NG-RAN."
- "For 5G MOCN Networking Sharing, different POP needs different data for personalized operation and maintenance services."
- "Operator-instance filtering for configuration data operation in TS 28.532."
- "The getMOIAttribute operation defined in TS 28.532[8] shall have capability to filter opetrator-specific managed objects."
- "The pLMNId parameter...is used to distinguish operator granularity and prevent data modification by MOP-NM while ensuring data fairness per POP."
- "Different configuration and performance measurements for each POP on MOP-SR-DM need to be forwarded to MOP-NM."

- Solution 2 proposes adding NRCellDU as a measurement object class to attempt and failure measurements of RRC connection related measurements.
- Solution 2 can meet potential new common performance measurement requirements of the NRCellCU, but cannot meet potential new common performance measurement requirements of the NRCellCU.
- The technical specifications TS 28.541 have a higher impact on the NR NRM to support NG-RAN sharing MOCN network sharing.
- The solution for collecting non-PLMN measurements is complex, causing a big migration of configurations.
- Only resolve issues with the attempt and failure measurements of RRC connection related measurements.
- TS 28.552 has a higher impact on the measurement object class of existing performance measurements.
- The proposed solutions suggest the new or existing IOCs should support the collection of these common and operator-specific measurements.

Example snippets from the original TDoc:
- "Solution 2 proposes that NRCellDU is added as the measurement object class to the attempt and failure measurements of RRC connection related measurements." (TDoc S5-233509)
- "The impacts of technical specifications TS 28.541: Higher impact on the NR NRM to support NG-RAN sharing MOCN network sharing." (TDoc S5-233509)
- "The solution for collecting non-PLMN measurements is complex, causing a big migration of configurations." (TDoc S5-233509)
- "Only resolve issues with the attempt and failure measurements of RRC connection related measurements." (TDoc S5-233509)
- "TS 28.552: Higher impact on the measurement object class of existing performance measurements." (TDoc S5-233509)
- "The proposed solutions suggest the new or existing IOCs should support the collection of these common and operator-specific measurements." (TDoc S5-233509)

3GPP-S5-148-e    Agenda Item 6.8.6.6 : FS_5GMDT_Ph2_WoP#6

3GPP-S5-148-e    Agenda Item 6.8.6.8 : FS_5GMDT_Ph2_WoP#8

3GPP-S5-148-e    Agenda Item 6.8.7.1 : FS_IOT_NTN_WoP#1

3GPP-S5-148-e    Agenda Item 6.8.7.3 : FS_IOT_NTN_WoP#3

3GPP-S5-148-e    Agenda Item 6.8.7.4 : Draft TR 28.841