WO2022098713A1

WO2022098713A1 - Mda report request, retrieval and reporting

Info

Publication number: WO2022098713A1
Application number: PCT/US2021/057840
Authority: WO
Inventors: Yizhi Yao; Joey Chou
Original assignee: Intel Corporation
Priority date: 2020-11-04
Filing date: 2021-11-03
Publication date: 2022-05-12
Also published as: CN116368780A; WO2022098713A9

Abstract

An apparatus and system are described to provide Management Data Analytics (MDA) Reports are described. An MDAS producer receives a request for receiving MDA reports from an MDAS consumer and provides a response indicating the status of the request. The request includes an identifier of the request, a filter to indicate a scope of data, and a method of delivery for an MDA report. The method is file reporting or streaming data reporting. The appropriate data is collected analyzed, and the MDA report generated and delivered to the consumer using the method in the request. The producer also receives a historical request to retrieve historical MDA reports. The historical request includes a time frame and a filter to specify a scope of the historical MDA reports to be retrieved. The historical MDA reports are retrieved and delivered using the method in the retrieval request.

Description

MDA REPORT REQUEST, RETRIEVAL AND REPORTING

PRIORITY CLAIM

[0001] This application claims the benefit of priority to United States Provisional Patent Application Serial No. 63/109,759, filed November 4, 2020, which is incorporated herein by reference in its entirety.

TECHNICAL HELD

[0002] Embodiments pertain to next generation wireless communications. In particular, some embodiments relate to Management Data Analytics (MDA) reporting in 5G networks.

BACKGROUND

[0003] The use and complexity of wireless systems, which include 5^th generation (5G) networks and are starting to include sixth generation (6G) networks among others, has increased due to both an increase in the types of devices user equipment (UEs) using network resources as well as the amount of data and bandwidth being used by various applications, such as video streaming, operating on these UEs. With the vast increase in number and diversity of communication devices, the corresponding network environment, including routers, switches, bridges, gateways, firewalls, and load balancers, has become increasingly complicated. As expected, a number of issues abound with the advent of any new technology.

BRIEF DESCRIPTION OF THE FIGURES

[0004] In the figures, which are not necessarily drawn to scale, like numerals may describe similar components in different views. Like numerals having different letter suffixes may represent different instances of similar components. The figures illustrate generally, by way of example, but not by way of limitation, various embodiments discussed in the present document.

[0005] FIG. 1 A illustrates an architecture of a network, in accordance with some aspects. [0006] FIG. IB illustrates a non-roaming 5G system architecture in accordance with some aspects.

[0007] FIG. 1 C illustrates a non-roaming 5G system architecture in accordance with some aspects.

[0008] FIG. 2 illustrates a block diagram of a communication device in accordance with some embodiments.

[0009] FIG. 3 illustrates an MDA process in accordance with some embodiments.

[0010] FIG. 4 illustrates MDA report request and MDA report file reporting in accordance with some aspects.

[0011] FIG. 5 illustrates MDA report request and MDA report streaming in accordance with some aspects.

[0012] FIG. 6 illustrates MDA report retrieval based on MDA report file reporting in accordance with some aspects.

[0013] FIG. 7 illustrates MDA report retrieval based on MDA report streaming in accordance with some aspects.

[0014] FIG. 8 illustrates a flowchart of a MDAS process in accordance with some aspects.

DETAILED DESCRIPTION

[0015] The following description and the 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, or substituted for, those of other embodiments. Embodiments set forth in the claims encompass all available equivalents of those claims.

[0016] FIG. 1 A illustrates an architecture of a network in accordance with some aspects. The network 140 A includes 3GPP LTE/4G and NG network functions that may be extended to 6G functions. Accordingly, although 5G will be referred to, it is to be understood that this is to extend as able to 6G structures, systems, and functions. A network function can be implemented as a discrete network element on a dedicated hardware, as a software instance running on dedicated hardware, and/or as a virtualized function instantiated on an appropriate platform, e g., dedicated hardware or a cloud infrastructure. [0017] The network 140A is shown to include user equipment (UE) 101 and UE 102. The UEs 101 and 102 are illustrated as smartphones (e g., handheld touchscreen mobile computing devices connectable to one or more cellular networks) but may also include any mobile or non-mobile computing device, such as portable (laptop) or desktop computers, wireless handsets, drones, or any other computing device including a wired and/or wireless communications interface. The UEs 101 and 102 can be collectively referred to herein as UE 101, and UE 101 can be used to perform one or more of the techniques disclosed herein.

[0018] Any of the radio links described herein (e g., as used in the 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 multicarrier (FBMC), OFDMA, etc ), and in particular 3GPP NR, may be used by allocating the OFDM carrier data bit vectors to the corresponding symbol resources.

[0019] In some aspects, any of the UEs 101 and 102 can comprise an Intemet-of-Things (loT) UE or a Cellular loT (CIoT) UE, which can comprise a network access layer designed for low-power loT applications utilizing shortlived UE connections. In some aspects, any of the UEs 101 and 102 can include a narrowband (NB) loT UE (e g., such as an enhanced NB-IoT (eNB-IoT) UE and Further Enhanced (FeNB-IoT) UE). An loT UE can utilize technologies such as machine-to-machine (M2M) or machine-type communications (MTC) for exchanging data with an MTC server or device via a public land mobile network (PLMN), Proximity-Based Service (ProSe) or device-to-device (D2D) communication, sensor networks, or loT networks. The M2M or MTC exchange of data may be a machine-initiated exchange of data. An loT network includes interconnecting loT UEs, which may include uniquely identifiable embedded computing devices (within the Internet infrastructure), with short-lived connections. The loT UEs may execute background applications (e g., keepalive messages, status updates, etc.) to facilitate the connections of the loT network. In some aspects, any of the UEs 101 and 102 can include enhanced MTC (eMTC) UEs or further enhanced MTC (FeMTC) UEs.

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

[0021] The UEs 101 and 102 utilize connections 103 and 104, respectively, each of which comprises a physical communications interface or layer (discussed in further detail below); in this example, the connections 103 and 104 are illustrated as an air interface to enable communicative coupling, and can be consistent with cellular communications protocols, such as a Global System for Mobile Communications (GSM) protocol, a code-division multiple access (CDMA) network protocol, a Push-to-Talk (PTT) protocol, a PTT over Cellular (POC) protocol, a Universal Mobile Telecommunications System (UMTS) protocol, a 3GPP Long Term Evolution (LTE) protocol, a 5G protocol, a 6G protocol, and the like.

[0022] In an aspect, the UEs 101 and 102 may further directly exchange communication data via a ProSe interface 105. The ProSe interface 105 may alternatively be referred to as a sidelink (SL) interface comprising 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).

[0023] The UE 102 is shown to be configured to access an access point (AP) 106 via connection 107. The connection 107 can comprise a local wireless connection, such as, for example, a connection consistent with any IEEE 802.11 protocol, according to which the AP 106 can comprise a wireless fidelity (WiFi®) router. In this example, the AP 106 is shown to be connected to the Internet without connecting to the core network of the wireless system (described in further detail below). [0024] The RAN 110 can include one or more access nodes that enable the connections 103 and 104. These access nodes (ANs) can be referred to as base stations (BSs), NodeBs, evolved NodeBs (eNBs), Next Generation NodeBs (gNBs), RAN nodes, and the like, and can comprise ground stations (e g., terrestrial access points) or satellite stations providing coverage within a geographic area (e g., a cell). In some aspects, the communication nodes 111 and 112 can be transmission/reception points (TRPs). In instances when the communication nodes 111 and 112 are NodeBs (e g., eNBs or gNBs), one or more TRPs can function within the communication cell of the NodeBs. The RAN 110 may include one or more RAN nodes for providing macrocells, e g., macro RAN node 111, and one or more RAN nodes for providing femtocells or picocells (e g., cells having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells), e g., low power (LP) RAN node 112. [0025] Any of the RAN nodes 111 and 112 can terminate the air interface protocol and can be the first point of contact for the UEs 101 and 102. In some aspects, any of the RAN nodes 111 and 112 can fulfill 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 an example, any of the nodes 111 and/or 112 can be a gNB, an eNB, or another type of RAN node.

[0026] The RAN 110 is shown to be communicatively coupled to a core network (CN) 120 via an SI interface 113. In aspects, the CN 120 may be an evolved packet core (EPC) network, a NextGen Packet Core (NPC) network, or some other type of CN (e g., as illustrated in reference to FIGS. 1B-1C). In this aspect, the SI interface 113 is split into two parts: the SI -U interface 114, which carries traffic data between the RAN nodes 111 and 112 and the serving gateway (S-GW) 122, and the SI -mobility management entity (MME) interface 115, which is a signaling interface between the RAN nodes 111 and 112 and MMEs 121.

[0027] In this aspect, the CN 120 comprises the MMEs 121, the S-GW 122, the Packet Data Network (PDN) Gateway (P-GW) 123, and a home subscriber server (HSS) 124. The MMEs 121 may be similar in function to the control plane of legacy Serving General Packet Radio Service (GPRS) Support Nodes (SGSN). The MMEs 121 may manage mobility aspects in access such as gateway selection and tracking area list management. The HSS 124 may comprise a database for network users, including subscription-related information to support the network entities' handling of communication sessions. The CN 120 may comprise one or several HSSs 124, depending on the number of mobile subscribers, on the capacity of the equipment, on the organization of the network, etc. For example, the HSS 124 can provide support for routing/roaming, authentication, authorization, naming/addressing resolution, location dependencies, etc.

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

[0029] The P-GW 123 may terminate an SGi interface toward a PDN. The P-GW 123 may route data packets between the CN 120 and external networks such as a network including the application server 184 (alternatively referred to as application function (AF)) via an Internet Protocol (IP) interface 125. The P-GW 123 can also communicate data to other external networks

131 A, which can include the Internet, IP multimedia subsystem (IPS) network, and other networks. Generally, the application server 184 may be an element offering applications that use IP bearer resources with the core network (e g., UMTS Packet Services (PS) domain, LTE PS data services, etc ). In this aspect, the P-GW 123 is shown to be communicatively coupled to an application server 184 via an IP interface 125. The application server 184 can 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 the UEs 101 and 102 via the CN 120.

[0030] The P-GW 123 may further be a node for policy enforcement and charging data collection. Policy and Charging Rules Function (PCRF) 126 is the policy and charging control element of the CN 120. In a non-roaming scenario, in some aspects, there may be a single PCRF in the Home Public Land Mobile Network (HPLMN) associated with a UE's Internet Protocol Connectivity Access Network (IP-CAN) session. In a roaming scenario with a local breakout of traffic, there may be two PCRFs associated with a UE's IP-CAN session: a Home PCRF (H-PCRF) within an HPLMN and a Visited PCRF (V-PCRF) within a Visited Public Land Mobile Network (VPLMN). The PCRF 126 may be communicatively coupled to the application server 184 via the P-GW 123. [0031] In some aspects, the communication network 140A can be an loT network or a 5G or 6G network, including 5G new radio network using communications in the licensed (5G NR) and the unlicensed (5G NR-U) spectrum. One of the current enablers of loT is the narrowband-IoT (NB-IoT). Operation in the unlicensed spectrum may include dual connectivity (DC) operation and the standalone LTE system in the unlicensed spectrum, according to which LTE-based technology solely operates in unlicensed spectrum without the use of an “anchor” in the licensed spectrum, called MulteFire. Further enhanced operation of LTE systems in the licensed as well as unlicensed spectrum is expected in future releases and 5G systems. Such enhanced operations can include techniques for sidelink resource allocation and UE processing behaviors for NR sidelink V2X communications.

[0032] An NG system architecture (or 6G system architecture) can include the RAN 110 and a 5G core network (5GC) 120. The NG-RAN 110 can include a plurality of nodes, such as gNBs and NG-eNBs. The CN 120 (e g., a 5G core network/5GC) can include an access and mobility function (AMF) and/or a user plane function (UPF). The AMF and the UPF can be communicatively coupled to the gNBs and the NG-eNBs via NG interfaces. More specifically, in some aspects, the gNBs and the NG-eNBs can be connected to the AMF by NG-C interfaces, and to the UPF by NG-U interfaces. The gNBs and the NG-eNBs can be coupled to each other via Xn interfaces. [0033] In some aspects, the NG system architecture can use reference points between various nodes. In some aspects, each of the gNBs and the NG- eNBs can be implemented as a base station, a mobile edge server, a small cell, a home eNB, and so forth. In some aspects, a gNB can be a master node (MN) and NG-eNB can be a secondary node (SN) in a 5G architecture.

[0034] FIG. IB illustrates a non-roaming 5G system architecture in accordance with some aspects. In particular, FIG. IB illustrates a 5G system architecture 140B in a reference point representation, which may be extended to a 6G system architecture. More specifically, UE 102 can be in communication with RAN 110 as well as one or more other 5GC network entities. The 5G system architecture 140B includes a plurality of network functions (NFs), such as an 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.

[0035] The UPF 134 can provide a connection to a data network (DN)

152, which can include, for example, operator services, Internet access, or third- party services. The AMF 132 can be used to manage access control and mobility and can also include network slice selection functionality. The AMF 132 may provide UE-based authentication, authorization, mobility management, etc., and may be independent of the access technologies. The SMF 136 can be configured to set up and manage various sessions according to network policy. The SMF 136 may thus be responsible for session management and allocation of IP addresses to UEs. The SMF 136 may also select and control the UPF 134 for data transfer. The SMF 136 may be associated with a single session of a UE 101 or multiple sessions of the UE 101 . This is to say that the UE 101 may have multiple 5G sessions. Different SMFs may be al located to each session. The use of different SMFs may permit each session to be individually managed. As a consequence, the functionalities of each session may be independent of each other.

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

[0037] The AF 150 may provide information on the packet flow to the PCF 148 responsible for policy control to support a desired QoS. The PCF 148 may set mobility and session management policies for the UE 101. To this end, the PCF 148 may use the packet flow information to determine the appropriate policies for proper operation of the AMF 132 and SMF 136. The AUSF 144 may store data for UE authentication. [0038] In some aspects, the 5G system architecture 140B includes an IP multimedia subsystem (IMS) 168B as well as a plurality of IP multimedia core network subsystem entities, such as call session control functions (CSCFs). More specifically, the IMS 168B includes a CSCF, which can act as a proxy CSCF (P-CSCF) 162BE, a serving CSCF (S-CSCF) 164B, an emergency CSCF (E-CSCF) (not illustrated in FIG. IB), or interrogating CSCF (I-CSCF) 166B. The P-CSCF 162B can be configured to be the first contact point for the UE 102 within the IM subsystem (IMS) 168B. The S-CSCF 164B can be configured to handle the session states in the network, and the E-CSCF can be configured to handle certain aspects of emergency sessions such as routing an emergency request to the correct emergency center or PSAP. The I-CSCF 166B can be configured to function as the contact point within an operator's network for all IMS connections destined to a subscriber of that network operator, or a roaming subscriber currently located within that network operator's service area. In some aspects, the I-CSCF 166B can be connected to another IP multimedia network 170E, e g. an IMS operated by a different network operator.

(0039) In some aspects, the UDM/HSS 146 can be coupled to an application server 160E, which can include a telephony application server (TAS) or another application server (AS). The AS 160B can be coupled to the IMS 168B via the S-CSCF 164B or the I-CSCF 166B.

[0040] A reference point representation shows that interaction can exist between corresponding NF services. For example, FIG. IB illustrates the following reference points: N1 (between the UE 102 and the AMF 132), N2 (between the RAN 110 and the AMF 132), N3 (between the RAN 110 and the UPF 134), N4 (between the SMF 136 and the UPF 134), N5 (between the PCF 148 and the AF 150, not shown), N6 (between the UPF 134 and the DN 152), N7 (between the SMF 136 and the PCF 148, not shown), N8 (between the UDM 146 and the AMF 132, not shown), N9 (between two UPFs 134, not shown), N10 (between the UDM 146 and the SMF 136, not shown), Ni l (between the AMF 132 and the SMF 136, not shown), N12 (between the AUSF 144 and the AMF 132, not shown), N13 (between the AUSF 144 and the UDM 146, not shown), N14 (between two AMFs 132, not shown), N15 (between the PCF 148 and the AMF 132 in case of a non-roaming scenario, or between the PCF 148 and a visited network and AMF 132 in case of a roaming scenario, not shown), N16 (between two SMFs, not shown), and N22 (between AMF 132 and NSSF 142, not shown). Other reference point representations not shown in FIG. IB can also be used.

[0041] FIG. 1C illustrates a 5G system architecture HOC and a servicebased representation. In addition to the network entities illustrated in FIG. 1 B, system architecture HOC can also include a network exposure function (NEF) 154 and a network repository function (NRF) 156. In some aspects, 5G system architectures can be service-based and interaction between network functions can be represented by corresponding point-to-point reference points Ni or as service-based interfaces.

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

[0043] NR-V2X architectures may support high-reliability low latency sidelink communications with a variety of traffic patterns, including periodic and aperiodic communications with random packet arrival time and size.

Techniques disclosed herein can be used for supporting high reliability in distributed communication systems with dynamic topologies, including sidelink NR V2X communication systems.

[0044] FIG. 2 illustrates a block diagram of a communication device in accordance with some embodiments. The communication device 200 may be a UE such as a specialized computer, a personal or laptop computer (PC), a tablet PC, or a smart phone, dedicated network equipment such as an eNB, a server running software to configure the server to operate as a network device, a virtual device, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine. For example, the communication device 200 may be implemented as one or more of the devices shown in FIGS. 1A-1C. Note that communications described herein may be encoded before transmission by the transmitting entity (e g., UE, gNB) for reception by the receiving entity (e g., gNB, UE) and decoded after reception by the receiving entity.

[0045] Examples, as described herein, may include, or may operate on, logic or a number of components, modules, or mechanisms. Modules and components are tangible entities (e g., hardware) capable of performing specified operations and may be configured or arranged in a certain manner. In an example, circuits may be arranged (e g., internally or with respect to external entities such as other circuits) in a specified manner as a module. In an example, the whole or part of one or more computer systems (e g., a standalone, client or server computer system) or one or more hardware processors may be configured by firmware or software (e g., instructions, an application portion, or an application) as a module that operates to perform specified operations. In an example, the software may reside on a machine readable medium. In an example, the software, when executed by the underlying hardware of the module, causes the hardware to perform the specified operations.

[0046] Accordingly, the term “module” (and “component”) is understood to encompass a tangible entity, be that an entity that is physically constructed, specifically configured (e g., hardwired), or temporarily (e g., transitorily) configured (e g., programmed) to operate in a specified manner or to perform part or all of any operation described herein. Considering examples in which modules are temporarily configured, each of the modules need not be instantiated at any one moment in time. For example, where the modules comprise a general-purpose hardware processor configured using software, the general -purpose hardware processor may be configured as respective different modules at different times. Software may accordingly configure a hardware processor, for example, to constitute a particular module at one instance of time and to constitute a different module at a different instance of time. [0047] The communication device 200 may include a hardware processor (or equivalently processing circuitry) 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 interlink (e g., bus) 208. The main memory 204 may contain any or all of removable storage and non-removable storage, volatile memory or non-volatile memory. The communication device 200 may further 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 an example, the display unit 210, input device 212 and UI navigation device 214 may be a touch screen display. The communication device 200 may additionally include a storage device (e g., drive unit) 216, a signal generation device 218 (e g., a speaker), a network interface device 220, and one or more sensors, such as a global positioning system (GPS) sensor, compass, accelerometer, or other sensor. The communication device 200 may further include an output controller, such as a serial (e g., universal serial bus (USB), parallel, or other wired or wireless (e g., infrared (IR), near field communication (NFC), etc.) connection to communicate or control one or more peripheral devices (e g., a printer, card reader, etc ).

[0048] The storage device 216 may include a non-transitory machine readable medium 222 (hereinafter simply referred to as 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 herein. The instructions 224 may also reside, completely or at least partially, within the main memory 204, within static memory 206, and/or within the hardware processor 202 during execution thereof by the communication device 200. While 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 the one or more instructions 224.

[0049] The term “machine readable medium” may include any medium that is capable of storing, encoding, or carrying instructions for execution by the communication device 200 and that cause the communication device 200 to perform any one or more of the techniques of the present disclosure, or that is capable of storing, encoding or carrying data structures used by or associated with such instructions. Non-limiting machine readable medium examples may include solid-state memories, 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.

[0050] The instructions 224 may further be transmitted or received over a communications network using a transmission medium 226 via the network interface device 220 utilizing any one of a number of wireless local area network (WLAN) transfer 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), mobile telephone networks (e g., cellular networks), Plain Old Telephone (POTS) networks, and wireless data networks. Communications over the networks may include one or more different protocols, such as Institute of Electrical and Electronics Engineers (IEEE) 802.11 family of standards known as Wi-Fi, IEEE 802.16 family of standards known as WiMax, IEEE

802. 15.4 family of standards, a Long Term Evolution (LTE) family of standards, a Universal Mobile Telecommunications System (UMTS) family of standards, peer-to-peer (P2P) networks, a next generation (NG)/5^th generation (5G) standards among others. In an example, the network interface device 220 may include one or more physical jacks (e g., Ethernet, coaxial, or phonejacks) or one or more antennas to connect to the transmission medium 226.

[0051] Note that the term “circuitry” as used herein refers to, is part of, or includes hardware components such as an electronic circuit, a logic circuit, a processor (shared, dedicated, or group) and/or memory (shared, dedicated, or group), an Application Specific Integrated Circuit (ASIC), a field-programmable device (FPD) (e g., a field-programmable gate array (FPGA), a programmable logic device (PLD), a complex PLD (CPLD), a high-capacity PLD (HCPLD), a structured ASIC, or a programmable SoC), digital signal processors (DSPs), etc., that are configured to provide the described functionality. In some embodiments, the circuitry may execute one or more software or firmware programs to provide at least some of the described functionality. The term “circuitry” may also refer to a combination of one or more hardware elements (or a combination of circuits used in an electrical or electronic system) with the program code used to carry out the functionality of that program code. In these embodiments, the combination of hardware elements and program code may be referred to as a particular type of circuitry.

[0052] The term “processor circuitry” or “processor” as used herein thus refers to, is part of, or includes circuitry capable of sequentially and automatically carrying out a sequence of arithmetic or logical operations, or recording, storing, and/or transferring digital data. The term “processor circuitry” or “processor” may refer to one or more application processors, one or more baseband processors, a physical central processing unit (CPU), a single- or multi-core processor, and/or any other device capable of executing or otherwise operating computer-executable instructions, such as program code, software modules, and/or functional processes.

[0053] Any of the radio links described herein may operate according to any one or more of the following radio communication technologies and/or standards including but not limited to: a Global System for Mobile Communications (GSM) radio communication technology, a General Packet Radio Service (GPRS) radio communication technology, an Enhanced Data Rates for GSM Evolution (EDGE) radio communication technology, and/or a Third Generation Partnership Project (3GPP) radio communication technology, for example Universal Mobile Telecommunications System (UMTS), Freedom of Multimedia Access (FOMA), 3GPP Long Term Evolution (LTE), 3GPP Long Term Evolution Advanced (LTE 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 Releases (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 Licensed-Assisted Access (LAA), MuLTEfire, UMTS Terrestrial Radio Access (UTRA), Evolved UMTS Terrestrial Radio Access (E-UTRA), Long Term Evolution Advanced (4th Generation) (LTE Advanced (4G)), cdmaOne (2G), Code division multiple access 2000 (Third generation) (CDMA2000 (3G)), Evolution-Data Optimized or Evolution-Data Only (EV-DO), Advanced Mobile Phone System (1st Generation) (AMPS (1G)), Total Access Communication System/Extended Total Access Communication 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 Telephone System (AMTS), OLT (Norwegian for Offentlig Landmobil Telefoni, Public Land Mobile Telephony), MTD (Swedish abbreviation for Mobiltelefonisystem D, or Mobile telephony system D), Public Automated Land Mobile (Autotel/PALM), ARP (Finnish for Autoradiopuhelin, "car radio phone"), NMT (Nordic Mobile Telephony), High capacity version of NTT (Nippon Telegraph and Telephone) (Hicap), Cellular Digital Packet Data (CDPD), Mobitex, DataTAC, Integrated Digital Enhanced Network (iDEN), Personal Digital Cellular (PDC), Circuit Switched Data (CSD), Personal Handyphone System (PHS), Wideband Integrated Digital Enhanced Network (WiDEN), iBurst, Unlicensed Mobile Access (UMA), also referred to as also referred to as 3GPP Generic Access Network, or GAN standard), Zigbee, Bluetooth(r), Wireless Gigabit Alliance (WiGig) standard, mmWave standards in general (wireless systems operating at 10-300 GHz and above such as WiGig, IEEE 802. 1 lad, IEEE 802. Hay, etc.), technologies operating above 300 GHz and THz bands, (3GPP/LTE based or IEEE 802.11 p or IEEE 802.1 Ibd and other) Vehicle-to-Vehicle (V2V) and Vehicle-to-X (V2X) and Vehicle-to- Infrastructure (V2I) and Infrastructure-to-Vehicle (12 V) communication technologies, 3GPP cellular V2X, DSRC (Dedicated Short Range Communications) communication systems such as Intelligent-Transport-Systems and others (typically operating in 5850 MHz to 5925 MHz or above (typically up to 5935 MHz following change proposals in CEPT Report 71)), the European ITS-G5 system (i.e. the European flavor of IEEE 802. l ip based DSRC, including ITS-G5A (i.e., Operation of ITS-G5 in European ITS frequency bands dedicated to ITS for safety re-lated applications in the frequency range 5,875 GHz to 5,905 GHz), ITS-G5B (i.e., Operation in European ITS frequency bands dedicated to ITS non- safety applications in the frequency range 5,855 GHz to 5,875 GHz), ITS-G5C (i.e., Operation of ITS applications in the frequency range 5,470 GHz to 5,725 GHz)), DSRC in Japan in the 700MHz band (including 715 MHz to 725 MHz), IEEE 802.11 bd based systems, etc.

[0054] Aspects described herein can 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-24 GHz, 3.4-3.6 GHz, 3.6-3.8 GHz and further frequencies and SAS = Spectrum Access System / CBRS = Citizen Broadband Radio System in 3.55-3.7 GHz and further frequencies). Applicable spectrum bands include IMT (International Mobile Telecommunications) spectrum as well as other types of spectrum/bands, such as bands with national allocation (including 450 - 470 MHz, 902-928 MHz (note: allocated for example in US (FCC Part 15)), 863-868.6 MHz (note: allocated for example in European Union (ETSI EN 300220)), 915.9-929.7 MHz (note: allocated for example in Japan), 917-923.5 MHz (note: allocated for example in South Korea), 755-779 MHz and 779-787 MHz (note: allocated for example in China), 790 - 960 MHz, 1710 - 2025 MHz, 2110 - 2200 MHz, 2300 - 2400 MHz, 2.4-2.4835 GHz (note: it is an ISM band with global availability and it is used by Wi-Fi technology family (11b/g/n/ax) and also by Bluetooth), 2500 - 2690 MHz, 698-790 MHz, 610 - 790 MHz, 3400 - 3600 MHz, 3400 - 3800 MHz, 3800 - 4200 MHz, 3.55- 3.7 GHz (note: allocated for example in the US for Citizen Broadband Radio Service), 5.15-5.25 GHz and 5.25-5.35 GHz and 5.47-5.725 GHz and 5.725-5.85 GHz bands (note: allocated for example in the US (FCC part 15), consists four U-NII bands in total 500 MHz spectrum), 5.725-5.875 GHz (note: allocated for example in EU (ETSI EN 301 893)), 5.47-5.65 GHz (note: allocated for example in South Korea, 5925-7125 MHz and 5925-6425MHz band (note: under consideration in US and EU, respectively. Next generation Wi-Fi system is expected to include the 6 GHz spectrum as operating band but it is noted that, as of December 2017, Wi-Fi system is not yet allowed in this band. Regulation is expected to be finished in 2019-2020 time frame), IMT-advanced spectrum, IMT-2020 spectrum (expected to include 3600-3800 MHz, 3800 - 4200 MHz, 3.5 GHz bands, 700 MHz bands, bands within the 24.25-86 GHz range, etc.), spectrum made available under FCC's "Spectrum Frontier" 5G initiative (including 27.5 - 28.35 GHz, 29.1 - 29.25 GHz, 31 - 31.3 GHz, 37 - 38.6 GHz, 38.6 - 40 GHz, 42 - 42.5 GHz, 57 - 64 GHz, 71 - 76 GHz, 81 - 86 GHz and 92 - 94 GHz, etc), the ITS (Intelligent Transport Systems) band of 5.9 GHz (typically 5.85-5.925 GHz) and 63-64 GHz, 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 has near-global designation for Multi-Gigabit Wireless Systems (MGWS)/WiGig . In US (FCC part 15) allocates total 14 GHz spectrum, while EU (ETSI EN 302 567 and ETSI EN 301 217-2 for fixed P2P) allocates total 9 GHz spectrum), the 70.2 GHz - 71 GHz band, any band between 65.88 GHz and 71 GHz, bands currently allocated to automotive radar applications such as 76-81 GHz, and future bands including 94-300 GHz and above. Furthermore, the scheme can be used on a secondary basis on bands such as the TV White Space bands (typically below 790 MHz) where in particular the 400 MHz and 700 MHz bands are promising candidates. Besides cellular applications, specific applications for vertical markets may be addressed such as PMSE (Program Making and Special Events), medical, health, surgery, automotive, low-latency, drones, etc. applications. [0055] Aspects described herein can also implement a hierarchical application of the scheme is possible, e g., by introducing a hierarchical prioritization of usage for different types of users (e g., low/medium/high priority, etc ), based on a prioritized access to the spectrum e g., with highest priority to tier-1 users, followed by tier-2, then tier-3, etc. users, etc.

[0056] Aspects described herein can also be applied to different Single Carrier or OFDM flavors (CP-OFDM, SC-FDMA, SC-OFDM, filter bank-based multicarrier (FBMC), OFDMA, etc.) and in particular 3GPP NR (New Radio) by allocating the OFDM carrier data bit vectors to the corresponding symbol resources.

[0057] Some of the features in this document are defined for the network side, such as APs, eNBs, NR or gNBs - note that this term is typically used in the context of 3GPP 5G and 6G communication systems, etc. Still, a UE may take this role as well and act as an AP, eNB, or gNB; that is some or all features defined for network equipment may be implemented by a UE.

[0058] As above, alterations introduced in 5G systems include selforganizing networks (SONs), which operate based on SON algorithms.

Different types of SONs may be used. In a centralized SON (C-SON), the SON algorithm executes in a 3GPP management system. A C-SON solution may be a Cross Domain-Centralized SON solution, in which the SON algorithms are executed in the 3GPP Cross Domain layer, a Domain-Centralized SON solution, in which the SON algorithms are executed in the 3GPP Domain layer, or a hybrid SON. In a Distributed SON (D-SON) solution, the SON algorithms are executed in the Network Function layer of the 5G system.

[0059] The SON algorithm may include monitoring the network(s) by collecting management data, including the data provided by the management data analytics service (MDAS); analyzing the management data to determine if there are issues in the network(s) to be resolved; making the decision on the SON actions to resolve the issues; executing the SON actions; and evaluating whether the issues have been solved by analyzing the management data.

Accordingly, in a Cross Domain-Centralized SON, the management function(s) (MnF) in the 3GPP Cross Domain layer monitors the networks via the management data, analyzes the management data, makes decisions on the SON actions, and executes the SON actions. [0060] In the domain-centralized SON, the MnF(s) in the domain layer monitors the networks via management data, analyzes the management data, makes decisions on the SON actions, and executes the SON actions. The MnF(s) in the Cross Domain layer is responsible for management and control of the Domain-Centralized SON function. The management and control may include switching on/oflf of a Domain-Centralized SON function, making policies for a Domain-Centralized SON function, and/or evaluating the performance of a Domain-Centralized SON function.

[0061] In the D-SON, the SON algorithm is located in the NTs. Accordingly, the NFs monitors the network events, analyzes the management data, makes decisions on the SON actions, and executes the SON actions. The D-SON management function switches on/off a D-SON function and provides policies, targets, and supplementary information (e g., the range attributes) for a D-SON function. The D-SON evaluation function evaluates whether the issues have been resolved and may apply D-SON management actions.

[0062] In the hybrid SON, the SON algorithm is executed at two or more of the NF layer, the Domain layer or the 3GPP Cross Domain layer. The 3GPP management system (i.e., MnF(s) in the Domain or 3GPP Cross Domain) and the NFs work together, in a coordinated manner, to build up a complete SON algorithm. The decisions on SON actions may be made by 3GPP management system and/or NFs.

[0063] The MDA forms a part of a management loop (which can be an open loop or a closed loop, see TS 32.500) in which artificial intelligence (Al) and machine learning (ML) techniques may be utilized. The management loop includes observation, analytics, decision making, and execution of actions based on obtained data.

[0064] Observation includes observation of the managed networks and services. The observation involves monitoring and collection of events, status and performance of the managed networks and services, and providing the observed/collected data (e g., performance measurements,

Trace/MDT/RLF/RCEF reports, network analytics reports, QoE reports, alarms, etc).

[0065] Analytics includes data analytics for the managed networks and services; the MDA used herein provides the analytics in the management loop. The MDA prepares, processes and analyses the data related to the managed networks and services, and provides the analytics reports for root cause analysis of ongoing issues, prevention of potential issues and prediction of network or service demands. The analytics report contains the description of the issues or predictions with optionally a degree of confidence indicator, the possible causes for the issue and the recommended actions. Techniques such as Al and ML (e g., ML model) may be utilized by the MDA with the input data including not only the observed data of the managed networks and services, but also the execution reports of actions (taken by the execution step). The MDA classifies and correlates the input data (current and historical data), learns and recognizes the data patterns, and makes analysis to derive inference, insight and predictions. [0066] Decision includes decision making for the management actions for the managed networks and services. The management actions are decided based on the analytics reports (provided by MDA) and other management data (e g., historical decisions made previously) if used. The decision may be made by the consumer of MDAS (in the closed management loop), or a human operator (in the open management loop). The decision includes what actions to take, and when to take the actions.

[0067] Execution includes execution of the management actions according to the decisions. During the execution operation, the actions are carried out to the managed networks and services, and the reports (e g., notifications, logs) of the executed actions are provided.

[0068] There are two types of data analytics services: the network data analytics service provided by the Network Data Analytics Function (NWDAF) and the MDAS provided by the 3GPP management system. The MDAS producer provides the analytics data for management purposes based on the data related to different types of network functions (NFs) or entities in the network, e g., data reported from the gNB and other core network functions. Depending on the scenario and when desired, the MDAS producer may use the analytics results of the NWDAF as input.

[0069] The MDAS Producer may be deployed as 3GPP domain-specific (e g., RAN or CN) or as 3GPP cross-domain. In one example of the coordination between the NWDAF, gNB and MDAS producers) for data analytics purposes: [0070] 1. The NWDAF may consume the MDAS for identified scenarios and provide analytics service for a 5GC NF for control purposes.

[0071] 2. The CN Domain MDAS producer may consume the service provided by the NWDAF and other 5GC NFs and provide analytics data for management purposes.

[0072] 3. The gNB many consume the MDAS for identified scenarios for RAN control purposes.

[0073] 4. The RAN Domain MDAS producer may consume the service provided by the gNB and provide analytics data for management purposes.

[0074] 5. The 3 GPP cross domain MDAS Producer may consume

(acting as Domain MDAS consumer) MDAS provided by a domain-specific (RAN and/or CN) MDAS producer(s), and produce the MDAS that may be consumed by the 3GPP cross-domain MDAS consumers).

[0075] In another example of coordination between the NWDAF and

MDAS producer for data analytics purposes:

[0076] 1. The NWDAF may consume the MDAS for identified scenarios and provide analytics service for 5GC NF for control purposes.

[0077] 2. The gNB may consume the MDAS for identified scenarios for

RAN control purposes.

[0078] 3. The domain MDAS producer may consume the service provided by the NWDAF, other 5GC NFs and the gNB, provide analytic data for management purposes.

[0079] FIG. 3 illustrates an MDA process in accordance with some embodiments. In the MDA process scenario of FIG. 3, the ML model and the management data analysis module reside in the MDAS producer. The MDA may rely on ML technologies in which case the consumer may be involved to optimize the accuracy of the MDA results. The MDA process in terms of the interaction with the consumer, when utilizing ML technologies, is described in FIG. 3.

[0080] There are two kinds of processes for MDA: the process for ML model training and the process for management data analysis. In the process for ML model training, the MDA producer trains the ML model and provides the ML training report. The process for ML model training may also get the consumer involved, i.e., allowing the consumer to provide input for ML model training. The ML model training may be performed on an untrained ML model or a trained ML model. In the process for management data analysis, the MDA producer analyses the data by the trained ML model and provides the analytics report to the consumer. The MDAS consumer may validate the training report and analytics report and provide a report validation feedback to the MDAS producer. For each received report the MDAS consumer may provide a feedback towards the MDAS producer, which may be used to optimize ML model.

[0081] Data classification: The data input to the MDA producer may be used for ML model training or for the actual management data analysis. The MDA producer classifies the input data and passes the classified data along to corresponding step for further processing.

[0082] ML model training: The MDAS producer trains the ML model, i .e., to train the algorithm of the ML model to be able to provide the expected training output by analysis of the training input. The data for ML model training may be the training data (including the training input and the expected output) and/or the report validation feedback provided by the consumer. After the ML model training, the MDAS producer provides an ML model training report.

[0083] Management data analysis: The trained ML model analyses the classified data and generates the management data analytics report(s).

[0084] Report validation: The consumer may validate the report provided by the MDAS producer. The report to be validated may be the analytics report and/or the ML model training report. The consumer may provide a feedback to the MDAS producer.

[0085] As a result of validation, the consumer: (i) may also provide training data and request to train the ML model and/or (ii) provide feedback indicating the scope of inaccuracy, e g., time, geographical area, etc.

[0086] The use case and solutions on request (e g., subscription), and reporting of Management Data Analytics Reports. The use cases include, for example, coverage issue analysis, slice coverage optimization, paging optimization, RAN user plane congestion analysis, resource utilization analytics, cross-slice resource optimization, non-access stratum (NAS) level congestion control optimization, end-to-end (E2E) latency analysis, network slice load analysis, service experience analysis, network slice throughput analysis, uplink/downlink throughput per UE in network slice analysis, key performance indicator (KPI) anomaly analysis, jitter analysis, network slice traffic projection, alarm incident analysis, fault prediction analysis, alarm malfunction analytics, handover optimization, inter-gNB beam selection optimization, load balancing optimization, mobility performance analysis, handover optimization based on UE trajectory, handover optimization based on UE load, energy efficiency related issues, RAN node software upgrade, SON conflict prevention and resolution, security risk assessment, ML model training for MDA, requesting and reporting of MDA reports, retrieval of historical MDA reports, and confidence indicator in analysis results as described in TR 28.809. The streaming data reporting service and file reporting service defined in TS 28.532 are suitable for Management Data Analytics Reports reporting.

[0087] For example, various coverage issues could include weak coverage, a coverage hole, pilot pollution, overshoot coverage, or a DL and UL channel coverage mismatch as described in clause 5.1.1 of 3GPP TS 37.816. Weak coverage may result in low success rate of random access, paging, RRC connection establishment and handover, low data throughput, more abnormal releases of RRC connection, DRB retainability, QoS flow and/or PDU session resources, and dissatisfied QoE. A coverage hole may also lead to the UE being out of service in the area. The 5G related coverage issue may exist only in 5G (i.e., 5G issue only with good coverage provided by other RATs) or exist in all RATs (i.e., no RAT provides good coverage in the area). In this case, the coverage issue may be detected by MDA from various symptoms, together with the geographical and terrain data and the configuration parameters of the RAN. Once a coverage issue is detected, the MDAS producer provides an analytics report that describes the coverage issue, and contains sufficient information to enable the MDAS consumer (e g., SON CCO function) to take the remedial actions. The MDAS producer may also provide the recommended actions to solve the identified coverage issue in the analytics report, so that the MDAS consumer can execute the actions accordingly or by taking the recommended actions into account. The MDAS producer may be informed when the actions are taken by the MDAS consumer to solve the coverage issue described in the analytics report, so that the MDAS producer can start evaluating the result of the executed actions. The MDAS producer obtains the execution reports describing the actions taken by the MDAS consumer, and takes the execution reports into account to fine-tune the accuracy of the future (new or updated) analytics report. The MDAS producer also provide update(s) of the analytics report to indicate the status change (e g., solved, mitigated or deteriorated) of the coverage issue. In this case, the analytics report may contain, for the coverage issue: identifier, indication of the type (e g., weak coverage or coverage hole, pilot pollution, overshoot coverage, or DL and UL channel coverage mismatch), start and stop time, geographical area and location where the coverage issue exists, root cause (e g., weak transmission power, blocked by constructions, restricted by terrain, etc.), in which RATs the coverage issue exists, MOIs of the affected cells, severity level (e g., critical, medium, cleared), and recommended actions (e g., re-configurations of coverage related attributes, creation of new cells or beams, or manual operations to add or change the physical units).

[0088] For slice optimization: to provide a network slice, a 3^rd party may issue a slice request indicating a desired Service Level Agreement (SLA), which includes, among other parameters, the slice coverage (also referred to as coverage area of the network slice or area of service). To provide the slice coverage, the desired geographical coverage area is mapped the available radio coverage, which depends on base station planning and deployment. In 5G, coverage is represented by a set of one or more Tracking Areas (TAs), which are contained in a Registration Area (RA), which is assigned to a UE once the UE registers to the network. In mapping the desired slice coverage into a geographical coverage area: the coverage area in the service profile is to be mapped to a TA list assigned to cells that are selected to support the slice coverage, and the desired slice coverage may be unable to be mapped perfectly to the “coverage footprint” of a cell or set of cells (that belong to a TA) or the desired slice coverage may be unavailable since radio coverage may not be available in certain areas. Currently to resolve these problems, more TAs (and consequently cells) may be allocated to a slice to enhance the coverage, if such an option is available, or more capacity resources can be provisioned in the allocated cells. Each cell can only be associated to one TA at a time and an S- NSSAIList configured in all cells that form a TA should be the same. This approach may prove to be inefficient since it wastes network resources. The distribution of users, the expected radio resource availability and mobility patterns may govern the configuration parameters of each TA and cell (e g., antenna downtilt, SSB beamforming patterns determining the coverage of a cell, handover parameters, etc.), that can be allocated per slice. Cell configuration parameters may help to adjust the coverage. MDA can be used to translate the business slice coverage to the actual radio deployment without overprovisioning while leveraging the benefits of flexible gNB radio features adjustment. MDA can enable an MDAS consumer to optimize the slice coverage and load distribution on the slice instantiation and runtime considering (i) slice-aware statistics, e g., slice-UE distributions and mobility patterns, (ii) slice SLA and (iii) access node capabilities. Depending on the MDAS producer output, TA and RA planning, i.e., grouping cells to form a TA and then TAs to an RA, can be optimized and the RAN parameters can be adjusted to shape the cell edges and load distribution. Thus, the report may permit fulfillment of a given slice SLA involving as few cells as possible by leveraging the benefits of adjusting cell configurations for satisfying the desired coverage. In this case, the cross domain or RAN domain MDAS producer output analytics report for TA optimization may contain an identifier that indicates TA configuration case for slice coverage enhancement (or slice unavailability), type of analytics (statistics or prediction), and recommended actions including a mapping list that indicates, for each Network Slice Selection Policy (NSSP) (for cross-domain), a list of sub areas and associated tracking area identifiers (TAIs). For gNB optimization, an identifier that indicates the gNB configuration case for slice coverage enhancement (or slice unavailability), type of analytics, geographical location affected by the gNB incident, affected object attributes (Cell Configurations: Antenna Tilt, HO parameters, cell reselection parameters, beam configuration, compute resources, etc ), starts/stop time of the incident, root cause (originator - e g., user mobility, load peak, user distribution, beam configuration, etc ), severity level, and recommended actions (e g., antenna tilt configuration, HO parameters configuration, cell reselection configuration, beam configuration, compute resource configuration, enable slice support in determined cell(s)). (0089) For paging optimization: if the UE goes out-of-coverage (OOC) the paging initiated by the network AMF fails. The re-attempts continue to fail until the UE comes into coverage and reacts to the paging attempts. The repetitive paging attempts result in the wastage of network resources. As an example, the use case includes a user or a group of users in an area with no cellular coverage on a regular basis for a considerably long duration, for e g., the user enters a shielded room for testing every day for a defined period. Network initiated paging for such users fail until they are back in the area with cellular coverage, resulting in inefficient network resource usage. MDAS may be used to optimize the current paging procedures in 5G networks. An MDAS producer provides an analytics report containing the userfs) paging analytics indicating the time window at which the user is OOC on a regular basis at the particular location and hence will not be able to respond on a network-initiated paging. Based on the report MDAS consumer (e g., AMF, gNB) decides on whether, when and where to initiate or not to initiate the paging procedures, thereby ensuring the efficient paging procedures and optimal network resource utilization, as paging can be initiated only when there are more chances for it to be successful. In this case, the paging analytics report may contain identification of the user or a group of users, time window during which each UE is out-ofcoverage every day, last known location before the UE goes out-of-coverage every day, and recommended action (stopping paging the UE at the identified time window when in the identified location).

[0090] The above are merely examples of the analysis reports. However, the manner in which the MDA reports reporting is supported by the streaming data reporting service and file reporting service is clarified herein.

[00911 6.99.2 Request of Management Data Analytics Reports

[00921 6.99.2.1 Use case

[00931 A MDAS Producer may provide several management data analysis reports. Multiple consumers may wish to receive a selection of these reports. The consumer submits a request to MDAS producer to subscribe to the MDA reports. This request may include a filter to specify the scope of MDA reports to be subscribed (e g., type of analytics report such as coverage issue analysis, resource utilization analysis, the managed functions to be analyzed, etc ). The MDAS producer activates the data collection if it is not already active. In the request, the consumer may indicate the method that the MDA reports are to be reported, i.e., by streaming data reporting for by file reporting. For all reports, the MDAS producer collects data, analyzes the data, and generates the analytics report.

[0094 ] The MDAS producer provides the MDA reports based on the reporting method designated in the request by the consumer. The consumer may send a request to MDAS producer to unsubscribe to the MDA report. If no subscribers remain for the MDA report, the MDA producer may decide to deactivate data collection for the present MDA process.

[0095] 6.99.2.2 Potential requirements

[0096] REQ-MDAJSUB-1 The MDAS producer should have a capability to allow an MDAS consumer to subscribe to an analytics report. The request should optionally allow the MDAS consumer to filter the scope of data in the analytics report.

[0097] REQ-MDA_SUB-2 The MDAS producer should have a capability to provide the analytics report to subscribed consumers.

[0098] REQ-MDA_SUB-3 The MDAS producer should have a capability to allow an MDAS consumer to unsubscribe to an analytics report.

[0099] 6.99.2.3 Possible solutions

[00100] The MDAS consumer sends the request (e g., MDAReportSubscription) to MDAS producer, with the following information included:

[00101] - identifier of the request/subscription;

[00102] - reporting method, i.e., file reporting or streaming data reporting;

[00103] - streaming target if the reporting method is designated to streaming data reporting;

[00104] - filter for the scope of the MDA report (e g., type of analytics report, managed functions to be analyzed, etc ).

[00105] The request (MDAReportSubscription) may be modelled as an information object class (IOC) and managed via provisioning related operations (such as CreateMOI, ModifyMOI, DeleteMOI), or sent by a dedicated operation (separated from the provisioning related operations). The MDAS producers provides a response indicating the status of the request. For the MDA report subscription designating the reporting method of file reporting, one solution in connection with the file reporting service defined in TS 32.532 is shown in FIG. 4. FIG. 4 illustrates MDA report subscription and MDA report file reporting in accordance with some aspects.

[00106] The MDAS producer generates the MDA reports according to the subscription. Once the MDA report is ready, the MDAS producer sends a notifyFileReady notification to the consumer to indicate that the MDA report file is ready, so that the MDAS consumer can download the file.

[00107] For the MDA report subscription designating the reporting method of streaming data reporting, the possible solution in connection with streaming data reporting service defined in TS 32.532 is shown in FIG. 5. FIG.

5 illustrates MDA report subscription and MDA report streaming in accordance with some aspects.

[00108] For ^a successful subscription, the MDAS producer sends an establishStreamingConnection operation request to the streaming target, and receives the response from the consumer to indicate the status of the operation. If the streaming connection is successfully established between the MDAS producer and the streaming target, the MDAS producer generates the MDA reports according to the subscription. Once the MDA report is ready, the MDAS producers sends the MDA report data by a reportStreamData operation to the streaming target.

[00109] 6.99.3 Retrieval of Management Data Analytics Reports

[00110] 6.99.3.1 Use case

[00111] A MDAS producer may provide several management data analysis reports. A consumer may wish to receive one of these reports. Besides the request and reporting of the MDA reports, the consumer may wish to retrieve some historical MDA reports. The consumer submits a request to MDAS producer to retrieve the historical MDA reports. This request may include a time frame and a filter to specify the scope of MDA reports to be retrieved (e g., type of analytics report such as coverage issue analysis, resource utilization analysis, the managed functions to be analyzed, etc.). The MDAS producer retrieves the historical MDA reports, and sends the results to the consumer using the same reporting method designated in the request. [00112] 6.99.3.2 Potential requirements

[00113] REQ-MDA REQ-l The MDAS producer should have a capability to allow an MDAS consumer to request a historical analytics report. The request should optionally allow the MDAS consumer to filter the scope of data in the analytics report.

[00114] REQ-MDA REQ-2 The MDAS producer should have a capability to provide the retrieved historical analytics report to the MDAS consumer.

[00115] 6.99.3.3 Possible solutions

[00116] The MDAS consumer sends the MDAReportRetrieval request to

MDAS producer, with the following information included:

[00117] - identifier of the retrieval request;

[00118] - time frame within which the MDA reports are to be retrieved;

[00119] - filter for the scope of the MDA report (e g., type of analytics report, managed functions to be analyzed, etc.)

[00120] The MDAReportRetrieval may be modelled as an IOC and managed via provisioning related operations (such as CreateMOI, ModifyMOI, DeleteMOI), or sent by a dedicated operation (separated from the provisioning related operations). The MDAS producers provides a response indicating the status of the request.

[00121] For the MDA report request designating the reporting method of file reporting, one possible solution in connection with file reporting service defined in TS 32.532 is shown in FIG. 6. FIG. 6 illustrates MDA report retrieval based on MDA report file reporting in accordance with some aspects. For a successful retrieval request, the MDAS producer retrieves the MDA reports and sends a notifyFileReady notification to the consumer to indicate that the retrieved MDA report file is ready, so that the MDAS consumer can download the file. For the MDA report request designating the reporting method of streaming data reporting, one possible solution in connection with streaming data reporting service defined in TS 32.532 is shown in FIG. 7. FIG. 7 illustrates MDA report retrieval based on MDA report streaming in accordance with some aspects. For a successful retrieval request, the MDAS producer retrieves the MDA reports and sends the retrieved MDA report data by a reportStreamData operation to the streaming target. [00122] FIG. 8 illustrates a flowchart of a MDAS process in accordance with some aspects. FIG. 8 may be implemented by a MDAS producer. Other operations may be present, but are not shown for convenience. For example, the process may include, at operation 802, receiving, from an MDAS consumer by the MDAS producer, a request for one or more MDA reports that includes a filter specifying a scope of the one or more MDA reports. At operation 804, the process may further include in response to the request, generating the one or more MDA reports. At operation 806, the process may further include providing the one or more MDA reports to the MDAS consumer.

[00123] Although an embodiment has been described with reference to specific example embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader scope of the present disclosure. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. The accompanying drawings that form a part hereof show, by way of illustration, and not of limitation, specific embodiments in which the subject matter may be practiced. The embodiments illustrated are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other embodiments may be utilized and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. This Detailed Description, therefore, is not to be taken in a limiting sense, and the scope of various embodiments is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled.

[00124] The subject matter may be referred to herein, individually and/or collectively, by the term “embodiment" merely for convenience and without intending to voluntarily limit the scope of this application to any single inventive concept if more than one is in fact disclosed. Thus, although specific embodiments have been illustrated and described herein, it should be appreciated that any arrangement calculated to achieve the same purpose may be substituted for the specific embodiments shown. This disclosure is intended to cover any and all adaptations or variations of various embodiments. Combinations of the above embodiments, and other embodiments not specifically described herein, will be apparent to those of skill in the art upon reviewing the above description. [00125] In this document, the terms "a" or "an" are used, as is common in patent documents, to include one or more than one, independent of any other instances or usages of "at least one" or "one or more." In this document, the term "or" is used to refer to a nonexclusive or, such that "A or B" includes "A but not B," "B but not A," and "A and B," unless otherwise indicated. In this document, the terms "including" and "in which" are used as the plain-English equivalents of the respective terms "comprising" and "wherein." Also, in the following claims, the terms "including" and "comprising" are open-ended, that is, a system, UE, article, composition, formulation, or process that includes elements in addition to those listed after such a term in a claim are still deemed to fall within the scope of that claim. Moreover, in the following claims, the terms "first," "second," and "third," etc. are used merely as labels, and are not intended to impose numerical requirements on their objects.

[00126] The Abstract of the Disclosure is provided to comply with 37 C.F.R. §1.72(b), requiring an abstract that will allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding 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 streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus, the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate embodiment.

Claims

CLAIMS What is claimed is:

1. An apparatus for a Management Data Analytics Service (MDAS) producer, the apparatus comprising: processing circuitry configured to: decode, from an MDAS consumer, a first request to receive MDA reports; encode, to the MDAS consumer, a response indicating a status of the first request; collect and analyze data related to at least one of the MDA reports; generate the at least one of the MDA reports based on the data; and provide the at least one of the MDA reports to the MDAS consumer; and memory configured to store the at least one of the MDA reports.

2. The apparatus of claim 1, wherein the processing circuitry is further configured to determine a scope of data in the at least one of the MDA reports to which the MDA consumer is to be subscribed based on a filter in the first request.

3. The apparatus of claim 2, wherein the scope of data in the at least one of the MDA reports includes a type of the analytics report selected from among managed functions to be analyzed, coverage issue analysis, slice coverage optimization, paging optimization, radio access network (RAN) user plane congestion analysis, resource utilization analytics, cross-slice resource optimization, non-access stratum (NAS) level congestion control optimization, end-to-end (E2E) latency analysis, network slice load analysis, service experience analysis, network slice throughput analysis, uplink and downlink throughput per user equipment (UE) in network slice analysis, key performance indicator (KPI) anomaly analysis, jitter analysis, network slice traffic projection, alarm incident analysis, fault prediction analysis, alarm malfunction analytics, handover optimization, inter- 5^th generation NodeB (gNB) beam selection optimization, load balancing optimization, mobility performance analysis, handover optimization based on UE trajectory, handover optimization based on UE load, energy efficiency related issues, RAN node software upgrade, selforganizing network (SON) conflict prevention and resolution, and security risk assessment.

4. The apparatus of claim 1, wherein the processing circuitry is further configured to: determine whether data collection for the data related to the MDA reports is active; and activate the data collection in response to a determination that the data collection is not active.

5. The apparatus of claim 1, wherein the processing circuitry is further configured to: determine a method that the at least one of the MDA reports is to be delivered based on information in the first request, the method selected from among file reporting and streaming data reporting; and use the method to deliver the MDA report.

6. The apparatus of claim 5, wherein the processing circuitry is further configured to: determine a streaming target from the information in the first request in response to a determination that streaming data reporting is to be used to deliver the MDA report; encode, for transmission to the streaming target, an establishStreamingConnection operation request; decode, from the streaming target, a response to indicate a status of the establishStreamingConnection operation request; and in response to a determination that the at least one of the MDA reports is ready, encode, for transmission to the streaming target, the at least one of the MDA reports by a reportStreamData operation.

7. The apparatus of claim 5, wherein the processing circuitry is further configured to encode, for transmission to the MDAS consumer, a notifyFileReady notification to indicate that the at least one of the MDA reports is ready for download by the MDAS consumer.

8. The apparatus of claim 5, wherein the processing circuitry is further configured to: decode, from the MDAS consumer, a second request to retrieve historical MDA reports, the second request including a time frame and a filter to specify a scope of the historical MDA reports to be retrieved; and in response to the second request, retrieve the historical MDA reports and encode, for transmission to the MDAS consumer, the historical MDA reports using the method.

9. The apparatus of claim 1, wherein the processing circuitry is further configured to: decode, from the MDAS consumer, a second request to unsubscribe from the MDA reports; terminate delivery of future MDA reports to the MDAS consumer in response to the second request; determine whether additional subscribers remain for the MDA reports; and in response to a determination that no other subscribers remain for the MDA reports, deactivate data collection for the future MDA reports.

10. The apparatus of claim 1, wherein the processing circuitry is further configured to manage the request via provisioning-related operations that include CreateMOI, ModifyMOI, DeleteMOI.

11. The apparatus of claim 1 , wherein the processing circuitry is further configured to deliver the MDAS report in a dedicated operation that is separate from provisioning-related operations.

12. An apparatus for a Management Data Analytics Service (MDAS) consumer, the apparatus comprising: processing circuitry configured to: encode, for transmission to an MDAS producer, a first request to receive MDA reports, the first request including a method of delivery for at least one of the MDA reports, the method selected from among file reporting and streaming data reporting; decode, from the MDAS producer, a response indicating a status of the first request; obtain the at least one of the MDA reports using the method in the request; and memory configured to store the at least one of the MDA reports.

13. The apparatus of claim 12, wherein the processing circuitry is further configured to indicate, in the first request, an identifier for the subscription and a filter to indicate a scope of data in the at least one of the MDA reports.

14. The apparatus of claim 12, wherein the processing circuitry is further configured to: decode, from the MDAS producer in response to the request indicating file reporting as the method of delivery, a notifyFileReady notification to indicate that the at least one of the MDA reports is ready for download; and in response to reception of the notifyFileReady notification, download the at least one of the MDA reports from the MDAS producer.

15. The apparatus of claim 12, wherein: the first request indicates streaming data reporting as the method of delivery, the first request indicates a streaming target for streaming delivery of the at least one of the MDA reports by the MDAS producer, and the processing circuitry is further configured to decode the at least one of the MDA reports from the streaming target.

16. The apparatus of claim 12, wherein the processing circuitry is further configured to: encode, for transmission to the MDAS producer, a second request to retrieve historical MDA reports, the second request including a time frame and a filter to specify a scope of the historical MDA reports to be retrieved; decode, from the MDAS producer, a response indicating a status of the second request; and obtain the historical MDA reports using the method in the first request.

17. The apparatus of claim 12, wherein the processing circuitry is further configured to encode, for transmission to the MDAS producer, a request to unsubscribe from the MDA reports.

18. The apparatus of claim 12, wherein the processing circuitry is further configured to manage the first request via provisioning-related operations that include CreateMOI, ModifyMOI, DeleteMOI or in a dedicated operation that is separate from provisioning-related operations.

19. A non-transitory computer-readable storage medium that stores instructions for execution by one or more processors of a Management Data Analytics Service (MDAS) producer, the one or more processors to configure the MDAS producer to, when the instructions are executed: decode, from an MDAS consumer, a first request to receive MDA reports, the first request including an identifier of the first request, a filter to indicate a scope of data, and a method of delivery for at least one of the MDA reports, the method selected from among file reporting and streaming data reporting; encode, to the MDAS consumer, a response indicating a status of the first request; collect and analyze data related to the at least one of the MDA reports; generate the at least one of the MDA reports based on the data; and deliver the at least one of the MDA reports using the method in the first request.

20. The non-transitory computer-readable storage medium of claim 19, wherein the instructions further configured the one or more processors to, when the instructions are executed: decode, from the MDAS consumer, a second request to retrieve historical MDA reports, the second request including a time frame and a filter to specify a scope of the historical MDA reports to be retrieved; and in response to the second request, retrieve the historical MDA reports and encode, for transmission to the MDAS consumer, the historical MDA reports using the method in the first request.