Managing data analysis (MDA) reports

Abstract

The present disclosure describes apparatuses and systems for managing various methods of data analysis (MDA) reporting. A management data analysis service (MDAS) producer receives a request to create a management object instance (MOI) for an MDA request. The MDAS producer requests to create the MOI for the MDA, responds to the MDAS consumer to the result of the creation of the MOI, and performs the MDA. Then, the MDAS producer subscribes to the reporting target or establishes a streaming connection with the reporting target based on a reporting method selected from a plurality of reporting methods, creates an MDA report based on the MDA, and transmits the MDA report to the reporting target in accordance with the reporting method.

Description

[0001] Priority claim

[0002] This application claims the benefit of priority to U.S. Provisional Patent Application Serial No. 63 / 394,837, filed on August 3, 2022, which is incorporated by reference into this disclosure in its entirety. Technical Field

[0003] Embodiments relate to 5th generation (5G) wireless communications. In particular, some embodiments relate to management data analysis reporting in 5G networks. Background Art

[0004] The use and complexity of next generation (NG) systems, which include 5G networks and are beginning to include sixth generation (6G) networks, has increased due to the increase in the types of device user equipment (UE) using network resources and the increase in the amount of data and bandwidth used by various applications running on these UEs (such as video streaming). With the significant increase in the number and diversity of communicating devices, the corresponding network environment has become increasingly complex. As expected, the emergence of any new technology brings many problems, including the complexity associated with managing data analysis and reporting. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] In the accompanying drawings, which are not necessarily drawn to scale, the same numerals may describe similar components in different views. The same numerals with different letter suffixes may represent different instances of similar components. These drawings generally illustrate various embodiments discussed in the present disclosure by way of example and not limitation.

[0006] Figure 1A A network architecture according to some aspects is shown.

[0007] Figure 1B A non-roaming 5G system architecture is shown according to some aspects.

[0008] Figure 1C A non-roaming 5G system architecture is shown according to some aspects.

[0009] Figure 2 A block diagram of a communication device according to some embodiments is shown.

[0010] Figure 3 A management data analysis (MDA) request and report workflow is shown in accordance with some embodiments.

[0011] Figure 4 A process for providing an MDA report according to some embodiments is shown. DETAILED DESCRIPTION

[0012] The following description and drawings sufficiently illustrate specific embodiments to enable those skilled in the art to practice them. Other embodiments may incorporate structural, logical, electrical, process and other changes. Portions and features of some embodiments may be included in portions and features of other embodiments, or replace portions and features of other embodiments. The embodiments set forth in the claims encompass all available equivalents of those claims.

[0013] Figure 1A A network architecture according to some aspects is shown. Network 140A includes 3GPP LTE / 4G and NG network functions that are extendable to 6G functions. Therefore, although 5G will be mentioned, it should be understood that this will be able to extend to 6G structures, systems and functions. The network functions can be implemented as discrete network elements on dedicated hardware, as software instances running on dedicated hardware, and / or as virtualized functions instantiated on an appropriate platform (e.g., dedicated hardware or cloud infrastructure).

[0014] Network 140A is shown to include user equipment (UE) 101 and UE 102. UE 101 and 102 are shown as smartphones (e.g., handheld touch screen mobile computing devices that can connect to one or more cellular networks), but may also include any mobile or non-mobile computing devices, such as portable (laptop) or desktop computers, wireless phones, drones, or any other computing devices that include wired and / or wireless communication interfaces. UE 101 and 102 may be collectively referred to as UE 101 in the present disclosure, and UE 101 may be used to perform one or more of the techniques disclosed in the present disclosure.

[0015] Any radio link described in the present disclosure (e.g., as used in network 140A or any other illustrated network) may operate according to any exemplary radio communication technology and / or standard. Any spectrum management scheme, including, for example, dedicated licensed spectrum, unlicensed spectrum, (licensed) shared spectrum (such as Licensed Shared Access (LSA) in 2.3-2.4 GHz, 3.4-3.6 GHz, 3.6-3.8 GHz and other frequencies and Spectrum Access System (SAS) in 3.55-3.7 GHz and other frequencies). Different single carrier or orthogonal frequency domain multiplexing (OFDM) modes (CP-OFDM, SC-FDMA, SC-OFDM, filter bank based multi-carrier (FBMC), OFDMA, etc.) may be used by assigning OFDM carrier data bit vectors to corresponding symbol resources, and in particular 3GPP NR.

[0016] In some aspects, any one of UE 101 and 102 may include an Internet of Things (IoT) UE or a cellular IoT (CIoT) UE, which may include a network access layer designed for low-power IoT applications that utilize short-term UE connections. In some aspects, any one of UE 101 and 102 may include a narrowband (NB) IoT UE (e.g., such as an enhanced NB-IoT (eNB-IoT) UE and an additional enhanced (FeNB-IoT) UE). The IoT UE may utilize technologies such as machine-to-machine (M2M) or machine-type communication (MTC) to exchange data with an MTC server or device via a public land mobile network (PLMN), proximity-based services (ProSe) or device-to-device (D2D) communication, a sensor network, or an IoT network. The M2M or MTC data exchange may be a machine-initiated data exchange. The IoT network includes interconnected IoT UEs with short-term connections, which may include uniquely identifiable embedded computing devices (within the Internet infrastructure). The IoT UE may execute background applications (e.g., keep-alive messages, status updates, etc.) to facilitate connectivity to the IoT network. In some aspects, either of UEs 101 and 102 may include an enhanced MTC (eMTC) UE or a further enhanced MTC (FeMTC) UE.

[0017] UEs 101 and 102 may be configured to connect, e.g., be communicatively coupled, to a radio access network (RAN) 110. RAN 110 may be, for example, an Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN), a Next Generation RAN (NGRAN), or some other type of RAN.

[0018] UEs 101 and 102 utilize connections 103 and 104, respectively, each of which includes a physical communication interface or layer (discussed in further detail below); in this example, connections 103 and 104 are illustrated as air interfaces that enable communication coupling and may comply with cellular communication protocols, such as Global System for Mobile Communications (GSM) protocols, Code Division Multiple Access (CDMA) network protocols, Push-to-Talk (PTT) protocols, PTT over Cellular (POC) protocols, Universal Mobile Telecommunications System (UMTS) protocols, 3GPP Long Term Evolution (LTE) protocols, 5G protocols, 6G protocols, etc.

[0019] In one aspect, the UEs 101 and 102 may additionally exchange communication data directly via the ProSe interface 105. Alternatively, the ProSe interface 105 may be referred to as a sidelink (SL) interface, which includes one or more logical channels including, but not limited to, a physical sidelink control channel (PSCCH), a physical sidelink shared channel (PSSCH), a physical sidelink discovery channel (PSDCH), a physical sidelink broadcast channel (PSBCH), and a physical sidelink feedback channel (PSFCH).

[0020] UE 102 is shown as being configured to access access point (AP) 106 via connection 107. Connection 107 may include a local wireless connection, such as a connection compliant with any IEEE 802.11 protocol, according to which AP 106 may include wireless fidelity. In this example, AP 106 is shown connected to the Internet, but not to the core network of the wireless system (described in further detail below).

[0021] The RAN 110 may include one or more access nodes that implement connections 103 and 104. These access nodes (ANs) may be referred to as base stations (BSs), NodeBs, evolved NodeBs (eNBs), next generation NodeBs (gNBs), RAN nodes, etc., and may include ground stations (e.g., terrestrial access points) or satellite stations that provide coverage within a geographic area (e.g., a cell). In some aspects, the communication nodes 111 and 112 may be transmission / reception points (TRPs). In an example when the communication nodes 111 and 112 are NodeBs (e.g., eNBs or gNBs), one or more TRPs may function within the communication cell of the NodeB. The RAN 110 may include one or more RAN nodes for providing macro cells, such as a macro RAN node 111, and one or more RAN nodes for providing femto cells or micro cells (e.g., cells with smaller coverage areas, smaller user capacity, or higher bandwidth than macro cells), such as a low power (LP) RAN node 112.

[0022] Any of the RAN nodes 111 and 112 may terminate the air interface protocol and may be the first point of contact for the UEs 101 and 102. In some aspects, any of the RAN nodes 111 and 112 may implement various logical functions for the RAN 110, including but not limited to radio network controller (RNC) functions such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management. In one example, any of the nodes 111 and / or 112 may be a gNB, an eNB, or another type of RAN node.

[0023] RAN 110 is shown as being communicatively coupled to a core network (CN) 120 via an S1 interface 113. In various aspects, CN 120 may be an evolved packet core (EPC) network, a next generation packet core (NPC) network, or some other type of CN (e.g., as described in reference to FIG. Figure 1B-1C In this regard, the S1 interface 113 is divided into two parts: an S1-U interface 114, which carries service data between the RAN nodes 111 and 112 and the serving gateway (S-GW) 122; and an S1-mobility management entity (MME) interface 115, which is a signaling interface between the RAN nodes 111 and 112 and the MME 121.

[0024] In this regard, CN 120 includes MME 121, S-GW 122, Packet Data Network (PDN) Gateway (P-GW) 123, and Home Subscriber Server (HSS) 124. MME 121 may be similar in function to the control plane of a legacy Serving General Packet Radio Service (GPRS) Support Node (SGSN). MME 121 may manage mobility aspects in access, such as gateway selection and tracking area list management. HSS 124 may include a database for network users, including subscription-related information, to support network entities in handling communication sessions. Depending on the number of mobile subscribers, the capacity of the equipment, the organization of the network, etc., CN 120 may include one or several HSS 124. For example, HSS 124 may provide support for routing / roaming, authentication, authorization, naming / addressing resolution, location dependency, etc.

[0025] The S-GW 122 may terminate the S1 interface 113 towards the RAN 110 and route data packets between the RAN 110 and the CN 120. In addition, the S-GW 122 may be a local mobility anchor point for handovers between RAN nodes and may also provide an anchor point for inter-3GPP mobility. Other responsibilities of the S-GW 122 may include lawful interception, charging, and some policy enforcement.

[0026] The P-GW 123 may terminate the SGi interface toward the PDN. The P-GW 123 may route data packets between the CN 120 and an external network such as a network including an application server 184 (alternatively referred to as an application function (AF)) via an Internet Protocol (IP) interface 125. The P-GW 123 may also pass data to other external networks 131A that may include the Internet, an IP Multimedia Subsystem (IPS) network, and other networks. Typically, the application server 184 may be an element that provides applications (e.g., UMTS packet service (PS) domain, LTE PS data service, etc.) that use IP bearer resources with the core network. In this regard, the P-GW 123 is shown as being communicatively coupled to the application server 184 via the IP interface 125. The application server 184 may also be configured to support one or more communication services (e.g., Voice over Internet Protocol (VoIP) sessions, PTT sessions, group communication sessions, social networking services, etc.) for UEs 101 and 102 via the CN 120.

[0027] The P-GW 123 may also be a node for policy enforcement and charging data collection. The Policy and Charging Rules Function (PCRF) 126 is a policy and charging control element of the CN 120. In a non-roaming scenario, in some aspects, there may be a single PCRF associated with the UE's Internet Protocol Connectivity Access Network (IP-CAN) session in the Home Public Land Mobile Network (HPLMN). In a roaming scenario where the service is out of local, there may be two PCRFs associated with the UE's IP-CAN session: the Home PCRF (H-PCRF) within the HPLMN and the Visited PCRF (V-PCRF) within the Visited Public Land Mobile Network (VPLMN). The PCRF 126 may be communicatively coupled to the application server 184 via the P-GW 123.

[0028] In some aspects, the communication network 140A can be an IoT network or a 5G or 6G network, including a 5G new radio network that uses communications in licensed (5G NR) and unlicensed (5G NR-U) spectrum. One of the current implementers of IoT is narrowband IoT (NB-IoT). Operations in unlicensed spectrum may include dual connectivity (DC) operations and standalone LTE systems in unlicensed spectrum, whereby LTE-based technologies operate only in unlicensed spectrum without using an "anchor" in the licensed spectrum, referred to as MulteFire. Additional enhanced operations of LTE systems in licensed as well as unlicensed spectrum are expected in future releases and 5G systems. Such enhanced operations may include techniques for sidelink resource allocation and UE processing behavior for NR sidelink V2X communications.

[0029] The NG system architecture (or 6G system architecture) may include a RAN 110 and a 5G core network (5GC) 120. The NG-RAN 110 may include multiple nodes, such as gNBs and NG-eNBs. The CN 120 (e.g., 5G core network / 5GC) may include an access and mobility function (AMF) and / or a user plane function (UPF). The AMF and UPF may be communicatively coupled to the gNB and NG-eNB via an NG interface. More specifically, in some aspects, the gNB and NG-eNB may be connected to the AMF via an NG-C interface and to the UPF via an NG-U interface. The gNB and NG-eNB may be coupled to each other via an Xn interface.

[0030] In some aspects, the NG system architecture may use reference points between various nodes. In some aspects, each of the gNB and NG-eNB may be implemented as a base station, a mobile edge server, a small cell, a home eNB, etc. In some aspects, the gNB may be a master node (MN) in the 5G architecture and the NG-eNB may be a secondary node (SN).

[0031] Figure 1B A non-roaming 5G system architecture is shown according to some aspects. In particular, Figure 1B The 5G system architecture 140B is illustrated with reference point representation, which can be extended to the 6G system architecture. More specifically, the UE 102 can communicate with the RAN 110 and one or more other 5GC network entities. The 5G system architecture 140B includes multiple network functions (NFs), such as AMF 132, session management function (SMF) 136, policy control function (PCF) 148, application function (AF) 150, UPF 134, network slice selection function (NSSF) 142, authentication server function (AUSF) 144 and unified data management (UDM) / home subscriber server (HSS) 146.

[0032] UPF 134 may provide a connection to a data network (DN) 152, which may include, for example, operator services, Internet access, or third-party services. AMF 132 may be used to manage access control and mobility, and may also include a network slice selection function. AMF 132 may provide UE-based authentication, authorization, mobility management, etc. and may be independent of access technology. SMF 136 may be configured to set and manage various sessions according to network policies. Therefore, SMF 136 may be responsible for session management and assigning IP addresses to UEs. SMF 136 may also select and control UPF 134 for data transmission. SMF 136 may be associated with a single session of UE 101 or multiple sessions of UE 101. That is, UE 101 may have multiple 5G sessions. Different SMFs may be assigned to each session. Using different SMFs may allow each session to be managed separately. Therefore, the functions of each session may be independent of each other.

[0033] UPF 134 can be deployed in one or more configurations depending on the desired service type and can be connected to the data network. PCF 148 can be configured to provide a policy framework using network slicing, mobility management, and roaming (similar to PCRF in 4G communication systems). UDM can be configured to store subscriber profiles and data (similar to HSS in 4G communication systems).

[0034] AF 150 may provide information about packet flows to PCF 148, which is responsible for policy control, to support the desired QoS. PCF 148 may establish mobility and session management policies for UE 101. To this end, PCF 148 may use packet flow information to determine appropriate policies for appropriate operation of AMF 132 and SMF 136. AUSF 144 may store data for UE authentication.

[0035] In some aspects, the 5G system architecture 140B includes an IP multimedia subsystem (IMS) 168B and multiple IP multimedia core network subsystem entities, such as a call session control function (CSCF). More specifically, the IMS 168B includes a CSCF, which can act as a proxy CSCF (P-CSCF) 162B, a serving CSCF (S-CSCF) 164B, an emergency CSCF (E-CSCF) ( Figure 1BThe P-CSCF 162B may be configured to be the first contact point for UE 102 in the IM subsystem (IMS) 168B. The S-CSCF 164B may be configured to handle the session state in the network, and the E-CSCF may be configured to handle certain aspects of emergency sessions, such as routing emergency requests to the correct emergency center or PSAP. The I-CSCF 166B may be configured to be the contact point in the operator's network for all IMS connections sent to the subscribers of the network operator or roaming subscribers currently located in the service area of ​​the network operator. In some aspects, the I-CSCF 166B may be connected to another IP multimedia network 170B, such as an IMS operated by a different network operator.

[0036] In some aspects, UDM / HSS 146 may be coupled to an application server 184, which may include a telephony application server (TAS) or another application server (AS). AS 160B may be coupled to IMS 168B via S-CSCF 164B or I-CSCF 166B.

[0037] The reference point representation shows that there may be interactions between corresponding NF services. For example, Figure 1B The following reference points are illustrated: N1 (between UE 102 and AMF 132), N2 (between RAN 110 and AMF 132), N3 (between RAN 110 and UPF 134), N4 (between SMF 136 and UPF 134), N5 (between PCF 148 and AF 150, not shown), N6 (between UPF 134 and DN 152), N7 (between SMF 136 and PCF 148, not shown), N8 (between UDM 146 and AMF 132, not shown), N9 (between two UPFs 134, not shown), N10 (between UDM 146 and SMF 136, not shown), N11 (between AMF 132 and SMF 136, not shown), N12 (between AUSF 144 and AMF 132, not shown), N13 (between AUSF 144 and UDM 146, not shown), N14 (between two AMFs 132, not shown), N15 (between PCF 148 and AMF 132 in the case of non-roaming scenario, or between PCF 148 and visited network and AMF 132 in the case of roaming scenario, not shown), N16 (between two SMFs, not shown), and N22 (between AMF 132 and NSSF 142, not shown). Figure 1B Other reference points not shown are indicated.

[0038] Figure 1C A 5G system architecture 140C and a service-based representation are shown. Figure 1B In addition to the network entities described in , the system architecture 140C may also include a network exposure function (NEF) 154 and a network repository function (NRF) 156. In some aspects, the 5G system architecture may be service-based, and the interactions between network functions may be represented by corresponding point-to-point reference points Ni, or as service-based interfaces.

[0039] In some aspects, such as Figure 1C As shown, a service-based representation may be used to represent network functions within the control plane so that other authorized network functions can access their services. In this regard, the 5G system architecture 140C may include the following service-based interfaces: Namf 158H (a service-based interface presented by AMF 132), Nsmf 158I (a service-based interface presented by SMF 136), Nnef 158B (a service-based interface presented by NEF 154), Npcf 158D (a service-based interface presented by PCF 148), Nudm 158E (a service-based interface presented by UDM 146), Naf 158F (a service-based interface presented by AF 150), Nnrf 158C (a service-based interface presented by NRF 156), Nnssf 158A (a service-based interface presented by NSSF 142), and Nausf 158G (a service-based interface presented by AUSF 144). Figure 1C Other service-based interfaces not shown (e.g., Nudr, N5g-eir, and Nudsf).

[0040] The NR-V2X architecture can support high reliability, low latency sidelink communications with multiple business patterns, including periodic and aperiodic communications with random packet arrival times and sizes. The technology disclosed in this disclosure can be used to support high reliability in distributed communication systems with dynamic topology, including sidelink NR V2X communication systems.

[0041] Figure 2 Block diagram illustrating a communication device according to some embodiments. The communication device 200 may be a UE, such as a dedicated computer, a personal or laptop computer (PC), a tablet PC or a smart phone, a dedicated network equipment (such as an eNB), a server running software to configure a server to operate as a network device, a virtual device, or any machine capable of (sequentially or otherwise) executing instructions specifying actions to be taken by the machine. For example, the communication device 200 may be implemented as Figures 1A-1CNote that the communications described in the present disclosure may be encoded prior to transmission by a transmitting entity (e.g., UE, gNB) for reception by a receiving entity (e.g., gNB, UE), and decoded after reception by the receiving entity.

[0042] Examples as described in the present disclosure may include logic or multiple components, modules or mechanisms, or may operate thereon. Modules and components are tangible entities (e.g., hardware) that can perform specified operations and may be configured or arranged in some manner. In one example, circuits may be arranged in a specified manner (e.g., internally or relative to external entities such as other circuits) as modules. In one example, all or part of one or more computer systems (e.g., independent, client or server computer systems) or one or more hardware processors may be configured by firmware or software (e.g., instructions, application parts or applications) as modules that operate to perform specified operations. In one example, the software may reside on a machine-readable medium. In one example, the software causes the hardware to perform specified operations when executed by the underlying hardware of the module.

[0043] Thus, the term "module" (and "component") is understood to encompass a tangible entity, whether physically constructed, specifically configured (e.g., hardwired), or temporarily (e.g., temporarily) configured (e.g., programmed) to operate in a specified manner or to perform part or all of any operations described in the present disclosure. Considering an example where a module is a temporary configuration, each of the modules need not be instantiated at any one time. For example, where a module comprises a general-purpose hardware processor configured using software, the general-purpose hardware processor may be configured as corresponding different modules at different times. Thus, software may configure a hardware processor, for example, to constitute a particular module at one instance in time and to constitute a different module at a different instance in time.

[0044] The communication device 200 may include a hardware processor (or equivalently, a processing circuit system) 202 (e.g., a central processing unit (CPU), a GPU, a hardware processor core, or any combination thereof), a main memory 204, and a static memory 206, some or all of which may communicate with each other via an interconnection link (e.g., a bus) 208. The main memory 204 may include any or all of a removable storage device and a non-removable storage device, a volatile memory, or a non-volatile memory. The communication device 200 may additionally include a display unit 210 such as a video display, an alphanumeric input device 212 (e.g., a keyboard), and a user interface (UI) navigation device 214 (e.g., a mouse). In one example, the display unit 210, the input device 212, and the UI navigation device 214 may be a touch screen display. The communication device 200 may additionally include a storage device (e.g., a drive unit) 216, a signal generating device 218 (e.g., a speaker), a network interface device 220, and one or more sensors, such as a global positioning system (GPS) sensor, a compass, an accelerometer, or another sensor. The communication device 200 may additionally include an output controller, such as a serial connection (e.g., a universal serial bus (USB), a parallel connection, or other wired or wireless connection (e.g., infrared (IR), near field communication (NFC), etc.) to communicate with or control one or more peripheral devices (e.g., a printer, a card reader, etc.).

[0045] The storage device 216 may include a non-transitory machine-readable medium 222 (hereinafter referred to as a machine-readable medium) on which is stored one or more sets of data structures or instructions 224 (e.g., software) embodying or utilized by any one or more of the techniques or functions described in this disclosure. The instructions 224 may also reside, in whole or in part, within the main memory 204, within the static memory 206, and / or within the hardware processor 202 during execution thereof by the communication device 200. Although the machine-readable medium 222 is illustrated as a single medium, the term "machine-readable medium" may include a single medium or multiple media (e.g., a centralized or distributed database, and / or associated caches and servers) configured to store one or more instructions 224.

[0046] The term "machine-readable medium" may include any medium capable of storing, encoding, or carrying instructions executed by the communication device 200 and causing the communication device 200 to perform any one or more of the techniques of the present disclosure, or any medium capable of storing, encoding, or carrying data structures used by or associated with such instructions. Non-limiting examples of machine-readable media may include solid-state memory and optical and magnetic media. Specific examples of machine-readable media may include: non-volatile memory, such as semiconductor memory devices (e.g., electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM)) and flash memory devices; magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; random access memory (RAM); and CD-ROM and DVD-ROM disks.

[0047] The instructions 224 may additionally be transmitted or received over a communication network via the network interface device 220 using a transmission medium 226 using any of a variety of wireless local area network (WLAN) transmission protocols (e.g., frame relay, Internet Protocol (IP), transmission control protocol (TCP), user datagram protocol (UDP), hypertext transfer protocol (HTTP), etc.). Example communication networks may include a local area network (LAN), a wide area network (WAN), a packet data network (e.g., the Internet), a mobile phone network (e.g., a cellular network), a plain old telephone (POTS) network, and a wireless data network. Communications over the network may include one or more different protocols, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 family of standards (referred to as Wi-Fi), the IEEE 802.16 family of standards (referred to as WiMax), the IEEE 802.15.4 family of standards, the long term evolution (LTE) family of standards, the universal mobile telecommunications system (UMTS) family of standards, a point-to-point (P2P) network, a next generation (NG) / 5th generation (5G) standard, etc. In one example, the network interface device 220 may include one or more physical jacks (eg, Ethernet jacks, coaxial jacks, or telephone jacks) or one or more antennas to connect to the transmission medium 226 .

[0048] Note that the term "circuitry" as used in the present disclosure refers to, is part of, or includes hardware components such as electronic circuits, logic circuits, processors (shared, dedicated, or group) and / or memories (shared, dedicated, or group), application specific integrated circuits (ASICs), field programmable devices (FPDs) (e.g., field programmable gate arrays (FPGAs), programmable logic devices (PLDs), complex PLDs (CPLDs), high capacity PLDs (HCPLDs), structured ASICs, or programmable SoCs), digital signal processors (DSPs), etc., which are configured to provide the described functions. In some embodiments, the circuitry may execute one or more software or firmware programs to provide at least some of the described functions. The term "circuitry" may also refer to a combination of one or more hardware elements and program code (or a combination of circuits used in an electrical or electronic system and program code), where the one or more hardware elements are used to perform the functions of the program code. In these embodiments, the combination of hardware elements and program code may be referred to as a specific type of circuitry.

[0049] Therefore, as used in this disclosure, the term "processor circuit system" or "processor" refers to, is a part of, or includes a circuit system that is capable of sequentially and automatically performing a series of arithmetic or logical operations, or recording, storing, and / or transmitting digital data. The term "processor circuit system" or "processor" may refer to one or more application processors, one or more baseband processors, a physical central processing unit (CPU), a single-core or multi-core processor, and / or any other device capable of executing or otherwise operating computer-executable instructions such as program codes, software modules, and / or functional processes.

[0050] Any of the radio links described in the present disclosure may operate according to any one or more of the following radio communication technologies and / or standards, including but not limited to: Global System for Mobile Communications (GSM) radio communication technology, General Packet Radio Service (GPRS) radio communication technology, Enhanced Data Rates for GSM Evolution (EDGE) radio communication technology, and / or Third Generation Partnership Project (3GPP) radio communication technology, such as Universal Mobile Telecommunications System (UMTS), Freedom of Multimedia Access (FOMA), 3GPP Long Term Evolution (LTE), 3GPP Advanced Long Term Evolution (LTE-A), and / or 3GPP LTE-S. Advanced), Code Division Multiple Access 2000 (CDMA2000), Cellular Digital Packet Data (CDPD), Mobitex, Third Generation (3G), Circuit Switched Data (CSD), High Speed ​​Circuit Switched Data (HSCSD), Universal Mobile Telecommunications System (Third Generation) (UMTS (3G)), Wideband Code Division Multiple Access (Universal Mobile Telecommunications System) (W-CDMA (UMTS)), High Speed ​​Packet Access (HSPA), High Speed ​​Downlink Packet Access (HSDPA), High Speed ​​Uplink Packet Access (HSUPA), High Speed ​​Packet Access Plus (HSPA+), Universal Mobile Telecommunications System - Time Division Duplex (UMTS-TDD), Time Division - Code Division Multiple Access (TD-CDMA), Time Division - Synchronous Code Division Multiple Access (TD-CDMA), 3rd Generation Partnership Project Release 8 (Pre-4th Generation) (3GPP Rel.8 (Pre-4G)), 3GPP Rel.9 (3rd Generation Partnership Project Release 9), 3GPP Rel.10 (3rd Generation Partnership Project Release 10), 3GPP Rel.11 (3rd Generation Partnership Project Release 11), 3GPP Rel.12 (3rd Generation Partnership Project Release 12), 3GPP Rel.13 (3rd Generation Partnership Project Release 13), 3GPP Rel.14 (3rd Generation Partnership Project Release 14), 3GPP Rel.15 (3rd Generation Partnership Project Release 15), 3GPP Rel.16 (3rd Generation Partnership Project Release 16), 3GPP Rel.17 (3rd Generation Partnership Project Release 17) and subsequent versions (such as Rel.18, Rel.19, etc.), 3GPP 5G, 5G, 5G New Radio (5G NR), 3GPP 5G New Radio, 3GPP LTE Extra, LTE-Advanced Pro, LTE License Assisted Access (LAA), MuLTEfire, UMTS Terrestrial Radio Access (UTRA), Evolved UMTS Terrestrial Radio Access (E-UTRA), Advanced Long Term Evolution (4th Generation) (LTE Advanced (4G)), cdmaOne (2G), Code Division Multiple Access 2000 (3rd Generation) (CDMA2000 (3G)), Evolution Data Optimized or Evolution Data Only (EV-DO), Advanced Mobile Phone System (1st Generation) (AMPS (1G)), Total Access Communications System / Extended Total Access Communications System (TACS / ETACS), Digital AMPS (2nd Generation) (D-AMPS (2G)), Push to Talk (PTT), Mobile Telephone System (MTS), Improved Mobile Telephone System (IMTS), Advanced Mobile Phone System (AMTS), OLT (Norwegian Offentlig Landmobil Telefoni (public land mobile), MTD (Swedish acronym Mobiltelefonisystem D, or Mobile Phone System D), Public Automatic Land Mobile (Autotel / PALM), ARP (Finnish Autoradiopuhelin, "car radio telephone"), NMT (Nordic mobile), High Capacity Version (Hicap) of NTT (Nippon Telegraph and Telephone), Cellular Digital Packet Data (CDPD), Mobitex, DataTAC, Integrated Digital Enhanced Network (iDEN), Personal Digital Cellular (PDC), Circuit Switched Data (CSD), Personal Handyphone System (PHS), Broadband Integrated Digital Enhanced Network (WiDEN), iBurst, Unlicensed Mobile Access (UMA) (also known as the 3GPP Universal Access Network or GAN standard), Zigbee, Bluetooth(r), Wireless Gigabit Alliance (WiGig) standard, universal mmWave standard (wireless systems operating at 10-300 GHz and above, such as WiGig, IEEE 802.11ad, IEEE802.11ay, etc.), technologies operating in frequency bands above 300 GHz and THz (based on 3GPP / LTE or IEEE 802.11p or IEEE802.11bd and others), vehicle-to-vehicle (V2V) and vehicle-to-X (V2X) and vehicle-to-infrastructure (V2I) and infrastructure-to-vehicle (I2V) communication technologies, 3GPP cellular V2X, DSRC (dedicated short range communication) communication systems such as intelligent transportation systems and others (typically operating at 5850 MHz to 5925 MHz or above (typically up to 5935 MHz as proposed in CEPT Report 71)), European ITS-G5 system (i.e., based on IEEE European flavors of DSRC of 802.11p, including ITS-G5A (i.e., ITS-G5 operation in the European ITS band dedicated to ITS for safety-related applications in the frequency range of 5,875 GHz to 5,905 GHz), ITS-G5B (i.e., operation in the European ITS band dedicated to ITS non-safety applications in the frequency range of 5,855 GHz to 5,875 GHz), ITS-G5C (i.e., operation of ITS applications in the frequency range of 5,470 GHz to 5,725 GHz), Japanese DSRC in the 700 MHz band (715 MHz to 725 MHz inclusive), IEEE802.11bd-based systems, etc. .

[0051] The aspects described in the present disclosure may be used in the context of any spectrum management scheme, including dedicated licensed spectrum, unlicensed spectrum, license-exempt spectrum, (licensed) shared spectrum (such as LSA=Licensed Shared Access in 2.3-2.4GHz, 3.4-3.6GHz, 3.6-3.8GHz and further frequencies and SAS=Spectrum Access System / CBRS=Citizens Broadband Radio System in 3.55-3.7GHz and further frequencies). Applicable spectrum segments include IMT (International Mobile Telecommunications) spectrum as well as other types of spectrum / bands, such as bands with national allocations (including 450-470MHz, 902-928MHz (Note: for example, allocated in the United States (FCC Part 15)), 863-868.6MHz (Note: for example, allocated in the European Union (ETSI EN 10102)), and 1063-1069MHz (Note: for example, allocated in the European Union (ETSI EN 10102)). 300220)), 915.9-929.7MHz (Note: for example, allocated in Japan), 917-923.5MHz (Note: for example, allocated in South Korea), 755-779MHz and 779-787MHz (Note: for example, allocated in China), 790-960MHz, 1710-2025MHz, 2110-2200MHz, 2300-2400MHz, 2.4-2.4835GHz (Note: It is an ISM band with global availability and is used by the Wi-Fi technology family (11b / g / n / ax) and also used by Bluetooth), 2500-2690MHz, 698-790MHz, 610-790MHz, 3400-3600MHz, 3400-3800MHz, 3800-4200MHz, 3.55-3.7GHz (Note: for example, allocated in the United States for Citizens Broadband Radio Service), 5.15-5.25GHz and 5.25-5.35GHz and 5.47-5.725GHz and 5.725-5.85GHz bands (Note: for example, allocated in the United States (FCC part 15), consisting of four U-NII bands with a total of 500MHz spectrum), 5.725-5.875GHz (Note: allocated in the European Union (ETSI EN 301 893)), 5.47-5.65GHz (Note: allocated in South Korea, 5925-7125MHz and 5925-6425MHz bands (Note: under consideration in the United States and the European Union, respectively. The next generation of Wi-Fi systems is expected to include the 6GHz spectrum as an operating band, but note that as of December 2017, Wi-Fi systems are not allowed in this band.Regulations are expected to be completed in the 2019-2020 time frame), IMT-advanced spectrum, IMT-2020 spectrum (expected to include 3600-3800MHz, 3800-4200MHz, 3.5GHz band, 700MHz band, bands in the 24.25-86GHz range, etc.), spectrum available under the FCC's "Spectrum Frontier" 5G initiative (including 27.5-28.35GHz, 29.1-29.25GHz, 31-31.3GHz, 37-38.6GHz, 38.6-40GHz, 42-42.5GHz, 57-64GHz, 71-76GHz, 8 1-86 GHz and 92-94 GHz, etc.), 5.9 GHz (typically 5.85-5.925 GHz) and 63-64 GHz ITS (Intelligent Transportation System) bands, bands currently allocated to WiGig (such as WiGig Band 1 (57.24-59.40 GHz), WiGig Band 2 (59.40-61.56 GHz), and WiGig Band 3 (61.56-63.72 GHz) and WiGig Band 4 (63.72-65.88 GHz)), 57-64 / 66 GHz (Note: This band is almost globally designated for Multi-Gigabit Wireless System (MGWS) / WiGig). A total of 14 GHz spectrum is allocated in the United States (FCC part 15), while a total of 9 GHz spectrum is allocated in the European Union (ETSI EN 302 567 and ETSI EN 301 217-2 (for fixed P2P)), 70.2 GHz-71 GHz band, any band between 65.88 GHz and 71 GHz, bands currently allocated for automotive radar applications (such as 76-81 GHz), and future bands (including 94-300 GHz and above). In addition, the solution can be used in a supplementary manner on bands such as TV white space bands (typically below 790 MHz) (where the 400 MHz and 700 MHz bands are particularly promising candidate bands). In addition to cellular applications, specific applications for vertical markets can also be addressed, such as PMSE (programming and special events), medical, health, surgery, automotive, low latency, drones, etc.

[0052] As an enabler of automation and intelligence, Management Data Analysis (MDA) can be used to manage and orchestrate mobile networks and services. MDA provides the ability to process and analyze data related to network and service events and status, including performance measurements, key performance indicators (KPIs), trace / minimization of drive tests (MDT) / radio link failure (RLF) / RRC connection creation failure (RCEF) reports, quality of experience (QoE) reports, alarms, configuration data, network analysis data, and service experience data from application functions (AFs), etc., to provide analysis outputs, i.e., statistics or predictions, root cause analysis of problems, and may also include recommendations for actions to implement network and service operations.

[0053] MDA output is provided by Management Data Analysis Service (MDAS) producers to corresponding consumers requesting analysis. MDA can identify ongoing issues affecting network and service performance, and help identify potential issues that may lead to potential failures and / or performance degradation in advance.

[0054] MDA can also assist in predicting network and service requirements to enable timely resource provisioning and deployment, which will allow rapid time-to-market for network and service deployments.

[0055] MDAS, i.e., the services exposed by MDA, can be used by various consumers, including, for example, management functions (MnF) (i.e., management service (MnS) producers / consumers for network and service management), NFs (e.g., network data analysis functions (NWDAF)), self-organizing network (SON) functions, network and service optimization tools / functions, service level specification (SLS) assurance functions, human operators and AFs, etc.

[0056] The management function (MDAF) may play the role of MDA MnS producer, MDA MnS consumer, other MnS consumers, NWDAF consumer and LMF service consumer, and may also interact with other non-3GPP management systems.

[0057] The MDA MnS producer provides analysis about a specific network environment (i.e., network state) in which data is collected to generate the analysis. For example, the prediction of the load in the area of ​​interest may be different when all gNBs and potential additional RATs are operating compared to a situation where some gNBs or other RATs are experiencing a failure or are powered off to save energy. The analysis performed and generated by the MDA MnS producer for these two example scenarios will be different and directly affected by the specific state of the network. Although the network state (environment) affects the analysis generated by the MDA producer, the awareness of the network environment will fall on the consumer side to supplement the analysis results obtained. The network environment reflects the network state when data collection is achieved, and it is very important for MDA MnS consumers to understand the network conditions related to the analysis obtained and therefore be able to use such analysis more effectively.

[0058] MDA MnS consumers may not expect MDA producers to provide network environments, because the network environment interests of each MDA MnS consumer may differ depending on the usage and purpose of the analysis. Usage may include proprietary algorithms that assist the decision-making process. For example, a load balancing algorithm may use load and mobility information in neighboring gNBs, while other load balancing algorithms may also use load and mobility information from a larger geographical area. In addition, it may prove impractical for an MDA MnS producer to prepare and provide parameters and combinations thereof. Therefore, it is effective for an MDA MnS producer to prepare only MDA outputs without including any network environment and allow MDA MnS consumers to obtain the required network environment to supplement the analysis obtained, using a configuration management procedure as described in TS28.511 and TS28.531.

[0059] The analytical intelligence that MDA plays in the management loop can be open-loop (operator-controlled) or closed-loop (autonomous), generating value by processing and analyzing management and network data, where AI and ML techniques can be leveraged.

[0060] The management cycle consists of several elements including analysis and these elements are briefly described as:

[0061] Observation: Observation of managed networks and services. It involves monitoring and collecting events, status, and performance of managed networks and services, and providing observed / collected data.

[0062] Analysis: Analysis of data about the managed networks and services. MDA plays the role of analysis in the management cycle. It prepares, processes, and analyzes observed / collected data or time series of observed / collected data related to the managed networks and services. MDA reports may include root cause analysis of ongoing problems, predictions of potential problems and corresponding related causes, and recommended actions for prevention, and / or predictions of network and / or service demand.

[0063] Decisions: Decisions made on management actions for managed networks and services. Management actions are decided, if necessary, based on analysis reports (provided by the MDA) and other management data (e.g., historical decisions previously made). Decisions may be made by consumers of the MDAS (in a closed management control loop) or by human operators (in the case of an open management loop). Decisions may include, for example, what action to take and when to take the action.

[0064] Execute: Management actions are performed according to the decision. During the execution step, actions are performed on the managed networks and services, and reports (e.g., notifications, logs) of the performed actions are provided.

[0065] 3GPP TS28.104, v.17.0.1 defines MDA use cases, requirements, data definitions, information models, and MnS. TS28.104 also provides the service components of MDA MnS.

[0066] 10MDA-related service components

[0067] 10.1MDA MnS Service Components

[0068] 10.1.1 General

[0069] Taking into account the requirements defined in clause 7.3, the MDA capability data definition in clause 8 and the MDA information model defined in clause 9, the MDA MnS service components are defined as follows for MDA requests and controls and MDA reports.

[0070] 10.1.2 MDA Report Request and Control

[0071] 10.1.2.1 Service Components

[0072] Table 10.1.2.1-1: Components of MDA MnS for MDA request and control

[0073]

[0074]

[0075] 10.1.3 MDA Report

[0076] 10.1.3.1 Service Components

[0077] Table 10.1.3.1-1: Components of MDA MnS for MDA reporting

[0078]

[0079]

[0080] MDA reporting allows three methods. However, the workflow (as specified in TS28.104) only supports one option. In addition, embodiments of the present disclosure help provide an MDA workflow with all allowed reporting methods, thereby providing a complete picture of the workflow for MDA requests and reports.

[0081] Provides MDA workflow for MDA requests and reports taking into account all allowed reporting methods.

[0082] Figure 3 An MDA request and report workflow is described according to some embodiments.

[0083] 1. MDA Request and Report Workflow

[0084] 1. The MDAS Producer receives a createMOI (see the createMOI operation defined in TS 28.532, v.17.1.1, 2022-06-22) request from an authorized MDAS Consumer to create an MDARequest MOI (see clause 9).

[0085] 2. The MDAS producer creates an MOI for the MDARequest IOC according to the createMOI request.

[0086] 3. The MDAS producer sends a createMOI response with the DN of the MOI to the MDAS consumer.

[0087] 4. The MDAS producer subscribes to relevant notifications or establishes a streaming connection according to the selected reporting method (identified by the reportingMethod attribute in the MDARequest MOI):

[0088] If the reportingMethod specified in the MDARequest MOI is "file": then 4a. If there is no subscription to the reporting target (specified by the reportingTarget attribute in the MDARequest MOI), then the MDAS Producer subscribes to file data reporting related notifications for the reporting target (see TS28.532).

[0089] If the reportingMethod specified in the MDARequest MOI is "streaming": then 4b / 4c. If no streaming connection exists with the reporting target, the MDAS Producer calls the establishStreamingConnection operation (see TS 28.532) to create a streaming connection with the streaming target; 4d / 4e. The MDAS Producer calls the addStream operation (see TS 28.532) to add a stream for the expected MDA report. 4f / 4g. If the newly added stream is to replace an existing stream, the MDAS Producer calls the deleteStream operation (see TS 28.532) to delete the stream.

[0090] If the reportingMethod specified in the MDARequest MOI is "Notification": then 4h. If there is no subscription to the reporting target, then the MDAS Producer subscribes to the provisioning-related notifications (see TS28.532) of the reporting target.

[0091] 5. While the MDARequest is active, the MDAS producer continues to execute the MDA and produces an MDA report according to the MDARequestMOI (see the MDAReport IOC defined in Clause 9).

[0092] 5a. The MDAS producer prepares the MDA report and sends the MDA report to the reporting target according to the selected reporting method (identified by the reportingMethod attribute in the MDARequest MOI):

[0093] If the reportingMethod specified in the MDARequest MOI is "file":

[0094] Then 5b. The MDAS producer documents the MDA report.

[0095] 5c. The MDAS producer issues a notifyFileReady notification to the reporting target of the MDA report (see TS28.531).

[0096] If the reportingMethod specified in the MDARequest MOI is "stream":

[0097] Then 5d. MDAS producer makes the MDA report into a stream data unit.

[0098] 5e. Call the reportStreamData operation on the report target of the MDA report (see TS 28.531).

[0099] If the reportingMethod specified in the MDARequest MOI is "Notification":

[0100] Then 5f. The MDAS producer creates the MDAReport MOI for the MDA report (see Clause 9).

[0101] 5g. If notifyMOICreation is used, the MDAS producer sends a notifyMOICreation notification to the reporting target of the MDA report (see TS28.531).

[0102] 5h. If notifyMOIChanges is used, the MDAS producer sends a notifyMOIChanges notification to the reporting target of the MDA report (see TS28.531).

[0103] In some embodiments, the electronic device, network, system, chip or component of the above-mentioned figures or parts or implementations thereof may be configured to perform one or more processes, techniques or methods or parts thereof as described in the present disclosure. Figure 4 One such process that may be performed by an MDAS producer is depicted in . Figure 4 A process 400 for providing an MDA report according to some embodiments is described. For example, at operation 402, the process 400 may include receiving an MDA request including an indication of a reporting method from an MDAS consumer. At operation 404, the process 400 may also include receiving a notification from a reporting target. At operation 406, the process 400 may also include executing an MDA process based on the MDA request and the notification from the reporting target. At operation 408, the process 400 may also include sending an MDA report to the reporting target based on the executed MDA process.

[0104] Use Cases:

[0105] Coverage related analysis:

[0106] Coverage problem analysis: RAN coverage problems may cause the UE to be out of service or result in degradation of the network performance provided to the UE, such as random access, paging, RRC connection establishment or handover failure, low data throughput, abnormal release of RRC connection or UE context, and unsatisfactory QoE.

[0107] There are various types of coverage issues, such as weak coverage, coverage holes, pilot pollution, overshoot coverage or DL ​​and UL channel coverage mismatch, etc., which are caused by different kinds of reasons such as insufficient or weak transmission power, blocked by buildings and / or restricted by terrain.

[0108] 5G-related coverage issues may exist in NR, E-UTRA, or both.

[0109] To resolve coverage issues, the MDAS consumer determines details about when and where the problem occurred or may occur, as well as the type and cause of the problem. Therefore, the MDA is expected to correlate and analyze a variety of data (such as performance measurements, MDT reports, RLF reports, RCEF reports, UE location reports, and geographic, topographical and configuration data of the RAN) to detect and describe problems with detailed information.

[0110] RAN coverage-related issues can lead to degradation of network performance and, in extreme cases, degradation of service. Therefore, in addition to identifying issues after they occur, it is also desirable to proactively avoid RAN coverage-related issues before they occur.

[0111] In order to avoid coverage related problems or to take proactive actions to avoid them, consumers of MDA MnS may wish to know the characteristics and quality of RAN coverage. This can be represented graphically on a map called a radio environment map, which shows the coverage quality of a set of cells. For example, such a map can be constructed to show the RSRP or SINR of a cell derived from observed UE performance and / or from the radio configuration parameters of the cell (including transmit power, antenna gain, antenna tilt, etc.). It is expected that MDAS producers can provide the radio environment map in a suitable graphical form.

[0112] Furthermore, in case of configuration of new RAN nodes, the MDAS producer should be able to take into account the coverage of existing cells as defined by the radio environment map and derive the configuration of new and existing cells to optimize coverage. Image analysis should help identify a set of optimized initial radio configurations that can be assigned to the new RAN NE.

[0113] To help MDAS consumers resolve coverage issues as quickly as possible, the MDA can also provide a description of the problem and recommended remedial actions (e.g., reconfiguring or adding cells, beams, antennas, etc.).

[0114] Slice coverage analysis:

[0115] Slice coverage is one of the metrics when a slice request is made by a third party (i.e., slice tenant) and is mapped to the desired geographical coverage area, where the available radio coverage depends on base station planning and deployment. In order to perfectly map the desired slice coverage, MDA can be used to optimize the slice coverage at slice instantiation and runtime taking into account the following factors:

[0116] i) Slice-aware statistics, such as slice-UE distribution and mobility patterns;

[0117] ii) Slice SLA; and

[0118] iii) Access node capabilities.

[0119] In 5G, the concept of coverage is represented by a set of one or more Tracking Areas (TAs) included in a Registration Area (RA) that is assigned to a UE once it registers with the network. Based on the MDA MnS Producer output, TA and RA planning can be optimized, i.e., cells are grouped to form TAs and then TAs are grouped to form RAs, and RAN parameters can be adjusted to form cell edges and load distribution. The main goal is to achieve a given slice SLA involving as few cells as possible by taking advantage of adjusting the cell configuration to meet the required coverage.

[0120] Paging optimization analysis:

[0121] This MDA capability is used to implement various functions related to paging optimization. If the UE is out of coverage (OOC), paging initiated by the network AMF will fail. Retries continue to fail until the UE enters coverage and responds to the paging attempt. Such repeated paging attempts result in a waste of network resources. As examples, use cases include a user or a group of users entering an area where there is regularly no cellular coverage for a considerable duration, and users entering a shielded room at specified times every day for certain tests. Paging initiated by the network for such users will fail until they return to an area with cellular coverage. This will result in inefficient use of network resources.

[0122] It is expected that MDAS will be used to optimize the current paging procedures in 5G networks. The MDAS Producer provides analysis outputs including user paging analysis indicating that a group of users are regularly in time windows of OOC at a specific location. The MDAS Generator also provides a geographical map where the UE will experience paging problems and therefore will not be able to respond to network initiated paging. Based on the provided MDA output, the MDAS Consumer (e.g., AMF, gNB) decides whether, when and where to initiate or not initiate a paging procedure, thereby ensuring an efficient paging procedure and optimal network resource utilization, as paging can be initiated only when there is a greater chance for it to succeed.

[0123] SLS analysis

[0124] The service experience of end users is a key indicator that directly reflects user satisfaction. In 5G systems, the diversity of network services continues to expand, and the requirements of different services, especially those from vertical users, are standardized. Considering these different requirements and expectations from the perspective of end users (for example, the priority of SLA-related attributes such as latency, throughput, maximum number of users, or different required values ​​of these attributes), it is necessary to extensively analyze the service experience as a comprehensive indicator.

[0125] Network Slicing Throughput Analysis

[0126] Throughput is very important, it represents the end-user experience and also reflects network problems, for example, low UE throughput can be caused by resource shortage. MDAS can be used for throughput related analysis / prediction of network slice instances. MDAS producers allow consumers to request analysis of network slice throughput related issues and identify the corresponding root causes to assist throughput assurance. Network slice throughput analysis can be domain-specific and / or cross-domain. Two levels of MDAS producers, domain-specific and cross-domain producers, can work together to ensure optimal throughput performance.

[0127] Network Slicing Traffic Prediction

[0128] It is expected that MDAS will be used to obtain network slice traffic forecasts, including individual traffic load forecasts for each constituent network function instance present in the network slice. The traffic load forecast for each constituent network function instance can be used to better configure the resources of the network slice. For example, resources can be pre-configured taking into account the predicted traffic on the network slice.

[0129] E2E delay analysis

[0130] E2E latency is an important parameter for URLLC services. User data packets should be successfully delivered within certain time limits to meet the requirements of the end users. Latency can be affected by network capabilities and network configuration. If the latency requirement cannot be met, then these factors can be the root cause. If these factors change, then the packet transmission latency can change dynamically. Even if some network conditions can degrade, the latency requirement should be ensured. It is important for MDAS producers to analyze latency related issues to support SLS guarantees.

[0131] Network Slicing Load Analysis

[0132] The network slice load may vary at different time periods. Therefore, the initially allocated network resources may not always meet the service requirements, for example, the network slice may be overloaded or underutilized. Signaling overload in the control plane and / or user data congestion in the user plane will lead to poor network performance. In addition, allocating too many resources to lightly loaded network slices will reduce resource efficiency.

[0133] The analysis of network slice load should consider service loads with different characteristics (e.g., QoS information, service priority), load distribution, to derive the corresponding resource requirements. Load distribution analysis results, such as load distribution of network slices, different locations and / or time periods, etc., can be provided.

[0134] The MDAS Producer can utilize traffic and resource related performance measurements and UE measurements to identify degradation of performance measurements and KPIs recorded in the SLS due to load issues (e.g., radio resource utilization). The MDAS Producer can additionally provide recommendations for network slice load issues. This analysis result can be considered as input to support SLA assurance to perform further evaluations.

[0135] MDA-assisted fault management

[0136] There are multiple sources of failure that can cause 5G systems to fail to provide the expected services. These failures and associated faults require extensive troubleshooting. In order to reduce network and service downtime and performance degradation, it is desirable to monitor the status of various network functions and resources, and predict network operating trends and potential failures for early intervention. Management systems can use these predictions to autonomously maintain the health of the network, for example, by taking rapid recovery actions for network functions associated with predicted potential failures.

[0137] Due to the fact that fault prediction may depend on existing alarm events and related historical and real-time data (performance measurement information, configuration data, network topology information, etc.), it is possible for MDA to be used in conjunction with AI / ML techniques and model training to predict potential faults. In order to avoid the occurrence of faults and abnormal network states, consumers of analysis expect to obtain the expected details of potential faults and corresponding downward trends (abnormal KPIs, performance measurement information, possible alarm types, root causes of faults, etc.). Therefore, MDA may need to combine AI / ML techniques to obtain basic health maintenance knowledge (e.g., the relationship between faults or potential faults and related maintenance actions) through predefined expertise or model training in order to effectively predict potential faults. Basic health maintenance knowledge can be updated using feedback. If desired, MDA can also provide corresponding recommended actions for fault prevention.

[0138] Energy saving analysis

[0139] Operators aim to use energy-saving management solutions to reduce the power consumption of 5G networks to reduce their operating expenses. Energy saving is achieved by activating energy-saving modes of NR capacity enhancement cells or 5GC NFs (e.g., UPF, etc.). The energy-saving decisions made are based on the load information of the relevant cells / UPFs, the energy-saving strategies set by the operators, and the energy-saving recommendations provided by the MDAS producers. In order to achieve an optimized balance between energy consumption and network performance, MDA can be used to assist MDAS consumers in making energy-saving decisions.

[0140] In order to make energy-saving decisions, it is expected that MDAS consumers determine where energy efficiency problems (e.g., high energy consumption, low energy efficiency) exist and the causes of energy efficiency problems. Therefore, it is expected that MDA associates energy-saving related performance measurements (e.g., PDCP data volume of a cell, power consumption, etc.) with network analysis data (e.g., network data analysis related to observed service experience) and analyzes them to provide analysis results indicating current network energy efficiency. In some low-traffic scenarios, MDA MnS consumers may expect to reduce energy consumption to save energy. In this case, MDA MnS consumers may request MDAS producers to report only analysis results related to high energy consumption problems. When consumers want to improve energy efficiency, although this may lead to high energy consumption in the network or in some parts of the network, the related problem is low energy efficiency. In this case, consumers may request analysis results related to low energy efficiency problems. Therefore, the goal may be to enhance the performance of NFs at given energy consumption. This will improve the energy efficiency of the network.

[0141] In order to make energy-saving decisions, it is necessary for the MDAS consumer to determine which energy efficiency (EE) KPI-related factors (e.g., traffic load, end-to-end latency, number of active UEs, etc.) are affected or potentially affected. The MDAS producer can use historical data to predict EE KPI-related factors (e.g., load changes in the cell at a certain time in the future, etc.). The prediction results of this information can then be used by the operator to make energy-saving decisions to ensure the service experience. The MDAS producer can also provide energy-saving related recommendations for the energy-saving state to the MDAS consumer. In the energy-saving state, the expected network performance and network experience should be guaranteed. Therefore, it is expected to formulate appropriate energy-saving strategies (start time, dynamic threshold setting, base station parameter configuration, etc.). The MDAS consumer can consider the recommendations for the energy-saving state for analysis or to make energy-saving decisions. After implementing the recommendations, the MDA producer can start to evaluate and further analyze network management data to optimize the recommendations.

[0142] Mobile performance analysis

[0143] Early / late / ping-pong handovers due to inappropriate handover parameters can cause mobility performance related issues. MDAS can be used to analyze the service experience and network performance during the handover period under different mobility scenarios. MDAS producers can also provide recommendations for optimal handover parameters to MDAS consumers.

[0144] In different NSA and SA deployment architecture scenarios, the handover mechanism (e.g., DAPS, CHO, or RACH-free handover) will have different impacts on mobility performance. An analysis report for identifying the optimal handover mechanism can be provided by the MDAS producer.

[0145] Switch optimization analysis

[0146] Switching Optimization

[0147] Current handover procedures are mainly based on radio conditions for selecting the target gNB at the time of handover. The target gNB accepts or rejects the handover (HO) request based on various conditions. In a virtualized environment, the HO may be rejected due to insufficient available resources within the target gNB. The concept of resources may include virtual resources (e.g., compute, memory) and / or radio resources (e.g., PRBs, users of RRC connections). If the HO request is rejected, the UE will try to connect to a different gNB until the request is successfully accepted. Several target gNBs may be tried until the request is successfully accepted. This process may result in a waste of UE and network resources, while it may also cause service interruption due to increased latency and radio link failure (RLF). It also leads to inefficiencies in HO or other network procedures.

[0148] To address this handover optimization problem, it is desirable to use MDA (Management Data Analytics) to provision and / or select a specific target gNB for the handover in order to reduce or even avoid HO rejections. The MDAS Producer provides a HO optimization analysis output that includes the current and future / forecasted resource consumption, resource capabilities, and other KPI status of the available target gNBs. The analysis output also provides recommended actions to optimize the target gNB for the handover. This may include resource reconfiguration or updated selection criteria for the target gNB. Based on the output, the MDAS Consumer adjusts (e.g., extends / expands virtual resources, reschedules / optimizes radio resources) resources before proceeding with the handover, and / or adjusts the selection criteria for the target gNB by also considering the overlapping coverage of inter-frequency and inter-RAT deployments.

[0149] Handover optimization based on UE load

[0150] The target node eNB may not have enough resources to accept certain handover requests. In the context of network virtualization, these resources may include not only traditional radio resources, but also virtual resources such as processors and memory. Handover optimization may benefit from knowledge about the expected UE load on the target cell, including additional radio and virtual resources.

[0151] Inter-gNB beam selection optimization

[0152] With the deployment of 5G networks, Massive MIMO has been used on a large scale. Beamforming, as a key technology to reduce user interference, can suppress interference signals in non-target directions and enhance sound signals in the target direction, always combined with Massive MIMO to additionally reduce interference. A cell can use multiple beams to serve resident users (SSB or CSI-RS), where each user is served by a single beam at a time. Cell-level quality can be expressed as an aggregated metric over one or more beams. Therefore, although switching is performed between two 5G cells, the granularity of the switching can be further subdivided into beam levels.

[0153] If network resources or user status have changed to obtain better network performance, beam switching can be performed. Beam optimization includes switching between different beams and configuration of beam parameters.

[0154] To avoid selecting the wrong beam to perform RACH on the target cell and causing RLF of the UE, the MDA can be used to recommend a way to prioritize and / or select beams in case of handover to a specific target cell. The MDA can provide beam-level HO optimization analysis taking into account information about the handover performance of different beam combinations between the source and target cell pair. Beams of target cells that have successfully been handed over are prioritized in the selection.

[0155] MDA can also provide recommended actions and priority options for beam selection. Based on the recommended actions, the MDA MnS consumer adjusts the priority of beam selection at HO, i.e., beam combinations that are likely to succeed are given priority and suboptimal beam combinations are deprioritized. The target cell can also obtain analysis to allocate RACH resources in a way that ensures HO success.

[0156] In order to optimize antenna and beam configuration to reduce energy loss and enhance network performance, MDA can be used to analyze the current network status.

[0157] MDA-assisted critical maintenance management

[0158] RAN node software upgrade

[0159] According to the current mechanism of software upgrade at RAN nodes, service interruption or huge operating cost is caused. Consider a scenario when a RAN node needs to be manually shut down for critical maintenance in a very short time. Software upgrade can be a critical maintenance scenario. In this case, all resources (bearers, security functions, mobility management) managed by this RAN node need to be cleared and reconfigured at another RAN node (standby RAN node) or if another RAN node is not available, then when the previous RAN node comes up after the software upgrade, the resources will be reconfigured again. Both cases result in additional operating expenses and data loss. The operating expenses include all resources needing to be released / connected again and data loss for all GBR sessions / bearers.

[0160] The MDAS is expected to be used to optimize the software upgrade procedure at the RAN nodes by providing a suitable time for performing the upgrade. Once configured, the software upgrade should be automatically initiated by the OAM system during the time frame with the least expected impact (i.e., at the optimal time with the least expected operational cost and data loss). The optimal time (current or future) can be derived by collecting and analyzing data related to the DRB including GBR / non-GBR, status, modification count, ongoing handover, etc. The MDAS can utilize historical data and AI / ML (e.g., time series based) algorithms to derive the future optimal time frame for the software upgrade.

[0161] MDA MnS

[0162] An MDA MnS consumer may request an MDA MnS producer to provide MDA outputs for a specified list of MDA type analyses (i.e., MDA types), which correspond to MDA capabilities to support analysis of a set of data or analysis of specific PM, KPI, tracking, or QoE data. An MDA MnS consumer may introduce control attributes related to MDA outputs that relate to geographic location (i.e., area scope) and / or target objects, such as managed elements, schedules for obtaining MDA outputs, time conditions related to preparing MDA outputs (i.e., schedules for start, end, and duration of analysis, etc.), and potential filtering conditions to be met before the MDA outputs are available, such as load or latency threshold crossings related to target objects. The geographic location indicates the area of ​​interest and / or target objects for obtaining the MDA outputs, including affected objects or objects of interest for obtaining the MDA outputs.

[0163] MDA MnS consumers can control MDA output properties related to, for example, schedule, geographic location, target object, etc., and have the ability to modify them at any point in time. MDA MnS consumers can request MDA MnS producers to generate MDA outputs, which include numerical output results such as averages, normal distributions, etc.; suggested options such as potential handover target cells; or root cause analysis (e.g., alarm prediction).

[0164] If the request is successful, the MDA MnS consumer is notified via an acknowledgement. If the request is unsuccessful, the consumer is notified about the potential error and the reason is indicated. The MDA MnS consumer can also deactivate the MDA Report Control request once it is no longer needed.

[0165] Obtaining MDA Output

[0166] The MDA MnS Producer allows the Consumer to obtain the MDA Output when the conditions indicated in the MDA Request are met. The level of detail and granularity of the MDA Output results will depend on the nature of the MDA Request and the MDA Capabilities. Therefore, the complexity of the MDA Output may vary and may include one or more MDA Results, which may be:

[0167] i) Numbers, such as averages, etc.;

[0168] ii) suggest options, such as potential handover target cells; or

[0169] iii) Root cause analysis, such as alarm prediction.

[0170] These results may be associated with one or more MDA types, which correspond to MDA capabilities, and may also include information regarding the schedule or validity period of the provided MDA outputs.

[0171] The MDA MnS Producer may allow consumers to request and obtain different MDA output results. The MDA MnS Producer may also allow consumers to obtain information about geographic locations and / or target objects (eg, managed elements) associated with the provided MDA results from the corresponding elements.

[0172] MDA MnS producers can allow consumers to choose to obtain MDA output results through a pulling or pushing mechanism. Any MDA output can be obtained as soon as it is ready or when the specified MDA request and control conditions are met.

[0173] Streaming Data Reporting Service

[0174] establishStreamingconnection operation: This operation enables an MnS producer to create a connection with an MnS consumer (i.e., a streaming target). Creating a connection includes a metadata exchange phase (the producer notifies the consumer of its own identity and the nature of the data reported via the stream) and the actual connection (the data pipe of the stream) creation.

[0175] The created connection supports stream multiplexing (a connection supports one or more report streams simultaneously).

[0176] After successfully creating a connection, the MnS consumer knows the identity of the MnS producer, the list of reporting streams, and the nature of the data reported on each of the streams.

[0177] The created connection can be kept "alive" through the solution set's built-in functionality or through periodic reporting of empty flow data.

[0178] Input Parameters

[0179]

[0180]

[0181] Output Parameters

[0182]

[0183]

[0184] terminateStreamingConnection operation:

[0185] This operation enables the MnS producer to terminate the connection with the MnS consumer (ie, streaming target).

[0186] After a streaming connection is successfully terminated, the MnS producer stops reporting data to the MnS consumer on this connection.

[0187] Input Parameters

[0188]

[0189] Output Parameters

[0190]

[0191] reportStreamData operation:

[0192] This operation enables the MnS producer to send streaming data units to the MnS consumer.

[0193] Input Parameters

[0194]

[0195]

[0196] Output Parameters

[0197]

[0198] addStream Operation

[0199] This operation allows an MnS producer to add one or more report streams to an already created streaming connection.

[0200] Input Parameters

[0201]

[0202]

[0203] Output Parameters

[0204]

[0205]

[0206] deleteStream Operation

[0207] This operation allows an MnS producer to remove one or more report streams from an already created streaming connection.

[0208] Input Parameters

[0209]

[0210]

[0211] Output Parameters

[0212]

[0213] NotifyFileReady

[0214] When a new file is ready (available) on the MnS producer for upload by a MnS consumer, the MnS producer sends this notification to the subscribed MnS consumers. The "fileInfoList" parameter provides information (metadata) about the new file and optionally, in addition to this, information about all other files that were previously ready for upload and are still available for upload when the notification is sent.

[0215] The "objectClass" and "objectInstance" parameters of the notification header identify the object representing the function (process) that makes the file available for retrieval, such as "PerfMetricJob" or "TraceJob" defined in TS28.622

[11] . When there is no standardized or instantiated dedicated object, the "ManagedElement" that handles the file should be used. For the case where the file is handled on a management node, the "ManagementNode" that handles the file should be used instead.

[0216] Input Parameters

[0217]

[0218]

[0219]

[0220]

[0221] Operation Subscription

[0222] This operation allows an MnS consumer to subscribe to notifications from a File Data Reporting Service producer.

[0223] Input Parameters

[0224]

[0225] Output Parameters

[0226]

[0227]

[0228] Notification notifyMOICreation

[0229] This notification informs subscribed consumers that a new managed object instance has been created.

[0230] Input Parameters

[0231]

[0232]

[0233]

[0234] Example

[0235] Example 1 is a device for managing a system, the device comprising: a processing circuit system configured to operate as a management data analysis service (MDAS) producer to: receive a request from an MDAS consumer to create a management object instance (MOI) for an MDA request; create the MOI for the MDA request; execute the MDA while the MDA request is active; create an MDA report based on the MDA; and send the MDA report to a reporting target in accordance with a reporting method selected from a plurality of reporting methods; and a memory configured to store the MDA report.

[0236] In Example 2, the subject matter of Example 1 includes, wherein the processing circuitry is further configured to create the reporting method by at least one of: subscribing to notifications of the reporting target; or establishing a streaming connection with the reporting target.

[0237] In Example 3, the subject matter of Examples 1-2 includes, wherein the MOI is an instance of an MDARequest information object class (IOC).

[0238] In Example 4, the subject matter of Example 3 includes, wherein the processing circuitry is further configured to determine the reporting method from a reportingMethod attribute in an MDARequest MOI.

[0239] In Example 5, the subject matter of Examples 3-4 includes, wherein the processing circuitry is further configured to determine the reporting target from a reportingTarget attribute in an MDARequest MOI.

[0240] In Example 6, the subject matter of Examples 1-5 includes that the multiple reporting methods include "file", "stream" and "notification", wherein in "file", the processing circuit system is configured to: make the MDA report into a file, wherein in "stream", the processing circuit system is configured to make the MDA report into a stream data unit, wherein in "notification", the processing circuit system is configured to create an MDAReport MOI for the MDA report.

[0241] In Example 7, the subject matter of Examples 1-6 includes, wherein the processing circuitry is further configured to create a subscription for the reporting target based on the reporting method, and the subscription is at least one of a file data report-related notification or a configuration-related notification.

[0242] In Example 8, the subject matter of Examples 1-7 includes, wherein the processing circuit system is further configured to: determine whether there is a streaming connection with the reporting target; and in response to determining that there is no streaming connection with the reporting target, create the streaming connection with the reporting target using an establishStreamingConnection operation to establish the streaming connection with the reporting target.

[0243] In Example 9, the subject matter of Examples 1-8 includes, wherein the processing circuitry is further configured to add a first stream to the reporting target to provide the MDA report to the reporting target.

[0244] In Example 10, the subject matter of Example 9 includes, wherein the processing circuit system is further configured to: determine whether the first stream is to replace the second stream; and in response to determining that the first stream is to replace the second stream, delete the second stream to the reporting target after adding the first stream.

[0245] In Example 11, the subject matter of Example 10 includes wherein the processing circuitry is further configured to add the first stream using an addStream operation and to delete the second stream using a deleteStream operation.

[0246] In Example 12, the subject matter of Examples 1-11 includes, wherein the processing circuitry is further configured to send the MDA report to the report target via a notifyFileReady notification.

[0247] In Example 13, the subject matter of Examples 1-12 includes, wherein the processing circuitry is further configured to send the MDA report to the reporting target via a reportStreamData operation.

[0248] In Example 14, the subject matter of Examples 1-13 includes, wherein the processing circuitry is further configured to send the MDA report to the reporting target via a notifyMOICreation notification or a notifyMOIChanges notification.

[0249] Example 15 is a non-transitory computer-readable storage medium storing instructions executed by one or more processors of a management data analysis service (MDAS) producer, wherein when executing the instructions, the one or more processors configure the MDAS producer to: receive a request from an MDAS consumer to create a management object instance (MOI) for an MDA request; create the MOI for the MDA request; execute the MDA while the MDA request is active; subscribe to notifications based on a reporting method selected from a plurality of reporting methods including "file", "stream", and "notification"; create an MDA report based on the MDA; and send the MDA report in a file for reporting method "file", a stream data unit for reporting method "stream", and an MDAReport MOI for reporting method "notification".

[0250] In Example 16, the subject matter of Example 15 includes, wherein the MOI is an instance of the MDARequest information object class (IOC), and when executing the instructions, the one or more processors configure the MDAS producer: determine the reporting method from the reportingMethod attribute in the MDARequest MOI, and determine the reporting target from the reportingTarget attribute in the MDARequestMOI.

[0251] In Example 17, the subject matter of Examples 15-16 includes, wherein, when executing the instructions, the one or more processors configure the MDAS producer: create a subscription for the reporting target based on the reporting method, and the subscription is selected from a group of subscriptions including file data report related notifications and configuration related notifications.

[0252] In Example 18, the subject matter of Examples 15-17 includes, wherein, when executing the instructions, the one or more processors configure the MDAS producer to: add a stream to the report target using an addStream operation. Send the MDA report to the report target via at least one of a notifyFileReady notification or a reportStreamData operation.

[0253] Example 19 is a device for a management system, the device comprising: a processing circuit system configured to operate as a management data analysis service (MDAS) reporting target to receive an MDA report including MDA data after creating a management object instance (MOI) for an MDA request in accordance with a reporting method selected from a plurality of reporting methods including files, streams, and notifications, the MDA report being sent in a file for reporting method "file", the MDA report being sent in a stream data unit for reporting method "stream", and the MDA report being sent in an MDAReport MOI for reporting method "notification"; and a memory configured to store the MDA report.

[0254] In Example 20, the subject matter of Example 19 includes, wherein the reporting method is based on one of a file data report related notification or a configuration related notification, and the MDA report is received via one of a notifyFileReady notification or a reportStreamData operation.

[0255] Example 21 is at least one machine-readable medium comprising instructions that, when executed by processing circuitry, cause the processing circuitry to perform operations to implement any of Examples 1-20.

[0256] Example 22 is an apparatus comprising means for implementing any of Examples 1-20.

[0257] Example 23 is a system that implements any one of Examples 1-20.

[0258] Example 24 is a method that implements any one of Examples 1-20.

[0259] Although the embodiments have been described with reference to specific example embodiments, it is apparent that various modifications and changes may be made to these embodiments without departing from the broader scope of the present disclosure. Therefore, the description and the drawings are considered to be illustrative rather than restrictive. The drawings constituting a part of the description illustrate specific embodiments of the practicable subject matter by way of illustration and not limitation. The illustrated embodiments are described in sufficient detail to enable those skilled in the art to practice the teachings of the present disclosure. Other embodiments may be utilized and derived therefrom so that structural and logical substitutions and changes may be made without departing from the scope of the present disclosure. Therefore, this detailed description should not be understood as limiting, and the scope of the various embodiments is limited only by the appended claims together with the full scope of equivalents to which these claims are assigned.

[0260] Subject matter may be referred to in this disclosure individually and / or collectively by the term "embodiment", which is merely for convenience and is not intended to actively limit the scope of the present application to any single inventive concept (if more than one is actually disclosed). Therefore, although the present disclosure has illustrated and described specific embodiments, it should be understood that any arrangement calculated to achieve the same purpose may replace the specific embodiments shown. The present disclosure is intended to cover any and all adaptations or variations of the various embodiments. After reading the above description, combinations of the above embodiments and other embodiments not specifically described in the present disclosure will be apparent to those skilled in the art.

[0261] In this disclosure, as is common in patent documents, the term "one" or "an" is used to indicate one or more than one, independent of any other instance or usage of "at least one" or "one or more". In this disclosure, the term "or" is used to refer to a non-exclusive "or", so that "A or B" includes "A but not B", "B but not A" and "A and B", unless otherwise indicated. In this disclosure, the terms "including" and "wherein" are used as the plain English equivalents of the corresponding terms "including" and "wherein". In addition, in the following claims, the terms "including" and "including" are open, that is, a system, UE, article, composition, composition or process including elements other than the elements listed after such terms in the claim is still considered to fall within the scope of the claim. In addition, in the following claims, the terms "first", "second" and "third" and the like are used only as labels and are not intended to impose numerical requirements on their objects. As indicated in this disclosure, although the present disclosure uses the term "one", one or more of the associated elements may be used in different embodiments. For example, the term "processor" configured to perform a specific operation includes both a single processor configured to perform all operations and multiple processors that are individually configured to perform some or all operations (which may overlap) so that the combination of processors performs all operations. In addition, the term "comprising" may be considered to be interpreted as "including at least" the following elements.

[0262] When submitting the Abstract of the present disclosure, it should be understood that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing detailed description, it can be seen that various features are grouped together in a single embodiment for the purpose of simplifying the disclosure. This disclosure method should not be interpreted as reflecting the intention that the claimed embodiments require more features than those expressly recited in each claim. On the contrary, as reflected in the following claims, the subject matter of the invention lies in less than all the features of a single disclosed embodiment. Therefore, the following claims are hereby incorporated into the detailed description, and each claim itself serves as a separate embodiment.

Claims

1. A device for managing a system, the device comprising: A processing circuit system is configured to operate as a managed data analysis service (MDAS) producer, the processing circuit system being used to: receiving a request from an MDAS consumer to create a managed object instance (MOI) for an MDA request; Requesting the MDA to create the MOI; executing the MDA while the MDA request is active; creating an MDA report based on the MDA; as well as Sending the MDA report to a reporting target according to a reporting method selected from a plurality of reporting methods; as well as A memory is configured to store the MDA report.

2. The apparatus of claim 1 , wherein the processing circuitry is further configured to establish the reporting method by at least one of: Subscribe to notifications from the reporting target; or A streaming connection is established to the reporting target.

3. The apparatus of claim 1, wherein the MOI is an instance of an MDARequest information object class (IOC). 4 . The apparatus of claim 3 , wherein the processing circuitry is further configured to determine the reporting method from a reportingMethod attribute in an MDARequest MOI.

5. The apparatus of claim 3, wherein the processing circuitry is further configured to determine the reporting target from a reportingTarget attribute in an MDARequest MOI.

6. The apparatus of claim 1, wherein the plurality of reporting methods include "file", "stream" and "notification", wherein in "file", the processing circuit system is configured to: make the MDA report into a file, wherein in "stream", the processing circuit system is configured to make the MDA report into a stream data unit, wherein in "notification", the processing circuit system is configured to create an MDAReport MOI for the MDA report.

7. The apparatus of claim 1, wherein the processing circuit system is further configured to: create a subscription for the reporting target based on the reporting method, and the subscription is: at least one of: file data report related notification or configuration related notification.

8. The apparatus of claim 1 , wherein the processing circuitry is further configured to: determining whether a streaming connection exists with the reporting target; and In response to determining that the streaming connection with the reporting target does not exist, creating a streaming connection with the reporting target using an establishStreamingConnection operation to establish the streaming connection with the reporting target.

9. The apparatus of claim 1, wherein the processing circuitry is further configured to add a first stream to the reporting target to provide the MDA report to the reporting target.

10. The apparatus of claim 9, wherein the processing circuitry is further configured to: determining whether the first stream is to replace the second stream; and In response to determining that the first stream is to replace the second stream, the second stream to the reporting target is deleted after the first stream is added.

11. The apparatus of claim 10, wherein the processing circuitry is further configured to add the first stream using an addStream operation and to delete the second stream using a deleteStream operation.

12. The apparatus of claim 1, wherein the processing circuitry is further configured to send the MDA report to the reporting target via a notifyFileReady notification.

13. The apparatus of claim 1, wherein the processing circuitry is further configured to send the MDA report to the reporting target via a reportStreamData operation.

14. The apparatus of claim 1, wherein the processing circuitry is further configured to send the MDA report to the reporting target via a notifyMOICreation notification or a notifyMOIChanges notification.

15. A non-transitory computer-readable storage medium storing instructions for execution by one or more processors of a managed data analysis service (MDAS) producer, which, when executed, configure the one or more processors to: receiving a request from an MDAS consumer to create a managed object instance (MOI) for an MDA request; Requesting the MDA to create the MOI; executing the MDA while the MDA request is active; Subscribe to notifications based on a reporting method selected from a variety of reporting methods including "file", "stream", and "notification"; creating an MDA report based on the MDA; as well as The MDA reports are sent to the report target in a file for reporting method "file", a stream data unit for reporting method "stream" and an MDAReport MOI for reporting method "notification".

16. A non-transitory computer-readable storage medium according to claim 15, wherein the MOI is an instance of the MDARequest information object class (IOC), and when executing the instructions, the one or more processors configure the MDAS producer to: determine the reporting method from the reportingMethod attribute in the MDARequest MOI, and determine the reporting target from the reportingTarget attribute in the MDARequest MOI.

17. A non-transitory computer-readable storage medium according to claim 15, wherein when executing the instructions, the one or more processors configure the MDAS producer to: create a subscription for the reporting target based on the reporting method, and the subscription is selected from a group of subscriptions including file data report related notifications and configuration related notifications.

18. The non-transitory computer-readable storage medium of claim 15, wherein when executing the instructions, the one or more processors configure the MDAS producer to: add a stream to the reporting target using an addStream operation; and send the MDA report to the reporting target via at least one of a notifyFileReady notification or a reportStreamData operation.

19. A device for managing a system, the device comprising: a processing circuit system configured to: operate as a management data analysis service (MDAS) reporting target to receive an MDA report including MDA data after creating a management object instance (MOI) for an MDA request in accordance with a reporting method selected from a plurality of reporting methods including file, stream, and notification, send the MDA report in a file for reporting method "file", send the MDA report in a stream data unit for reporting method "stream", and send the MDA report in an MDAReport MOI for reporting method "notification"; as well as A memory is configured to store the MDA report.

20. The apparatus of claim 19, wherein the reporting method is based on one of a file data report related notification or a configuration related notification, and the MDA report is received via one of a notifyFileReady notification or a reportStreamData operation.

Images