Requesting Data from OAM

Abstract

Apparatus, methods, and systems for efficient data collection from OAM are disclosed. An apparatus (700) includes a processor (705) and a transceiver (725) that receives (805) a first request to provide data for at least one data type information from a first network function, where the first request includes an indication that the data is available as historical data. The processor (705) processes (810) the data required according to the first request and sends (815) a second request to a Data Repository Function ("DRF"), where the second request includes the data required and an indication that the data is available as historical data. The processor (705) provides (820) the required data to the first network function.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to U.S. Provisional Patent Application No. 63 / 150,508, filed February 17, 2021, in favor of Dimitrios Karampatsis and Ishan Vaishnavi, entitled "EFFICIENT DATA COLLECTION FROM AN OAM," which is incorporated herein by reference.

[0002] The subject matter disclosed herein relates generally to wireless communications, and more specifically, to efficient data collection from Operations, Administration and Maintenance ("OAM") systems. [Background technology]

[0003] In some wireless communication systems, a Data Collection Coordination Function ("DCCF") may be employed for Fifth-Generation ("5G") network analysis. The DCCF may coordinate the collection of data from one or more Network Functions ("NFs") based on data collection requests from one or more consumer NFs. Summary of the Invention [Problem to be solved by the invention]

[0004] Disclosed is a procedure for efficient data collection from an OAM, which may be implemented by an apparatus, a system, a method, or a computer program product. [Means for solving the problem]

[0005] A method in a data management device for processing data collection requests includes receiving a first request to provide data from a first network function, the first request including an indication that the data is available as historical data. The method includes processing the required data according to the first request. The method includes sending a second request to a Data Repository Function ("DRF"), the second request including the required data and an indication that the data is available as historical data. The method includes providing the required data to the first network function.

[0006] A method in a data collection coordination entity for coordinating data collection at a network entity includes receiving a first request to provide data from a first function, the first request including first information for identifying the requested data. The method includes determining whether the requested data is available at a DRF, the first information indicating that the requested data is to be retrieved from an Operations, Administration and Management ("OAM") platform. The method includes retrieving the requested data from the DRF when the requested data is available at the DRF and sending a second request to the OAM platform to retrieve the data when the requested data is not available at the DRF, the second request including a request for data based on the first information.

[0007] A more particular description of the embodiments briefly described above will be made by reference to specific embodiments illustrated in the accompanying drawings, in which it is noted that the embodiments have been described and explained with added specificity and detail through the use of the accompanying drawings, with the understanding that these drawings depict only some embodiments and are not to be considered limiting in scope as such. [Brief description of the drawings]

[0008] [Figure 1] FIG. 1 is a schematic block diagram illustrating an embodiment of a wireless communication system for efficient data collection from an OAM. [Diagram 2] FIG. 1 illustrates one embodiment of a procedure for data collection via DCCF. [Diagram 3] FIG. 1 illustrates one embodiment of a procedure for an OAM to store data in a DRF. [Figure 4] FIG. 1 illustrates one embodiment of a procedure for a consumer NF to determine whether data is available in a DRF. [Diagram 5] FIG. 1 illustrates one embodiment of a procedure for a consumer NF to request OAM data via a DCCF. [Figure 6] FIG. 1 illustrates one embodiment of a procedure for the DCCF to collect data from the OAM. [Figure 7] FIG. 2 is a block diagram illustrating one embodiment of a network device that may be used for efficient data collection from OAM. [Figure 8] FIG. 2 is a flow chart diagram illustrating one embodiment of a first method for efficient data collection from an OAM. [Figure 9] FIG. 11 is a flow chart diagram illustrating one embodiment of a second method for efficient data collection from an OAM. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] As will be appreciated by one skilled in the art, aspects of the embodiments may be embodied as a system, apparatus, method, or program product. Accordingly, the embodiments may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.) or an embodiment combining software and hardware aspects.

[0010] For example, the disclosed embodiments may be implemented as hardware circuitry including custom very-large-scale integration ("VLSI") circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. The disclosed embodiments may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, or the like. As another example, the disclosed embodiments may include one or more physical or logical blocks of executable code, which may be organized, for example, as objects, procedures, or functions.

[0011] Furthermore, embodiments may take the form of a program product embodied in one or more computer-readable storage devices storing machine-readable code, computer-readable code, and / or program code, hereinafter referred to as code. The storage devices may be tangible, non-transitory, and / or non-transmittable. The storage devices may not embody signals. In some embodiments, the storage devices employ only signals to access the code.

[0012] Any combination of one or more computer readable media may be utilized. The computer readable medium may be a computer readable storage medium. The computer readable storage medium may be a storage device that stores the code. The storage device may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, holographic, micro-mechanical, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing.

[0013] More specific examples (non-exhaustive list) of storage devices would include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random-access memory ("RAM"), a read-only memory ("ROM"), an erasable programmable read-only memory ("EPROM" or flash memory), a portable compact disc read-only memory ("CD-ROM"), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this specification, a computer-readable storage medium may be any tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device.

[0014] The code for carrying out the operations of the embodiments may be any number of lines of code and may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Python, Ruby, Java, Smalltalk, C++, or the like, and traditional procedural programming languages ​​such as the "C" programming language or the like, and / or machine code such as assembly language. The code may run entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network ("LAN"), wireless LAN ("WLAN"), or wide area network ("WAN"), or the connection may be to an external computer (e.g., through the Internet using an Internet Service Provider ("ISP").

[0015] Furthermore, the described features, structures, or characteristics of the embodiments may be combined in any suitable manner. In the following description, numerous specific details are provided, such as examples of programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., to provide a thorough understanding of the embodiments. However, one skilled in the art will understand that the embodiments may be practiced without one or more of the specific details, or using other methods, components, materials, etc. In other cases, well-known structures, materials, or operations have not been shown or described in detail to avoid obscuring aspects of the embodiments.

[0016] References throughout this specification to "one embodiment," "an embodiment," or similar phrases mean that a particular feature, structure, or characteristic described with respect to that embodiment is included in at least one embodiment. Thus, all occurrences of the phrases "in one embodiment" or "in an embodiment" and similar phrases do not necessarily refer to the same embodiment, but mean "one or more, but not all, embodiments" unless otherwise noted. "Including," "comprising," "having," and variations thereof mean "including but not limited to" unless otherwise noted. Enumerated listings of items do not imply that any or all of the items are mutually exclusive unless otherwise noted. Additionally, the articles "a," "an," and "the" in the original English text refer to "one or more" unless otherwise noted.

[0017] As used herein, a list with the conjunction "and / or" includes any single item in the list or combination of items in the list. For example, a list of A, B, and / or C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C. As used herein, a list using the phrase "one or more of" includes any single item in the list or combination of items in the list. For example, "one or more of A, B, and C" includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C. As used herein, "one of" includes only one of any single item in the list. For example, "one of A, B, and C" includes only A, only B, or only C, and excludes the combination of A, B, and C. As used herein, "selected from the group consisting of A, B, and C" includes only one of A, B, or C, and excludes the combination of A, B, and C. As used herein, "selected from the group consisting of A, B, and C and combinations thereof" includes A only, B only, C only, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C.

[0018] Aspects of these embodiments are described below with reference to schematic flowchart illustrations and / or schematic block diagrams of methods, apparatus, systems, and program products according to the embodiments. It will be understood that each block of the schematic flowchart illustrations and / or schematic block diagrams, and combinations of blocks in the schematic flowchart illustrations and / or schematic block diagrams, may be implemented by code that is provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to generate machine instructions that, when executed by the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart illustrations and / or block diagrams.

[0019] The code may be stored in a storage device that can direct a computer, other programmable data processing apparatus, or other device to function in a particular manner, such that the instructions stored in the storage device produce an article of manufacture that includes instructions that implement the functions / acts specified in the flowchart illustrations and / or block diagrams.

[0020] The code may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause the computer, other programmable apparatus, or other device to perform a series of operational steps to generate a computer-implemented process such that the code executing on the computer or other programmable apparatus provides a process for implementing the functions / acts specified in the flowchart illustrations and / or block diagrams.

[0021] The call flow diagrams, flowchart diagrams, and / or block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of apparatus, systems, methods, and program products according to various embodiments. In this regard, each block in the flowchart diagrams or block diagrams may represent a module, segment, or portion of code, which contains one or more executable instructions of code for implementing the specified logical function(s).

[0022] It should also be noted that in some alternative implementations, the functions noted in the blocks may be performed out of the order shown. For example, two blocks shown in succession may in fact be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending on the functionality involved. Other steps and methods may be contemplated that are equivalent in function, logic, or effect to one or more blocks of the illustrated diagrams, or portions thereof.

[0023] Various types of arrows and lines may be employed in the call flow diagrams, flowchart diagrams, and / or block diagrams, but these are understood not to limit the scope of the corresponding embodiments. Indeed, some arrows or other connecting lines may be used to indicate only the logical flow of the depicted embodiments. For example, the arrows may indicate waiting or monitoring periods of unspecified duration between recited steps of the depicted embodiments. It should also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by a dedicated hardware-based system that performs the specified functions or actions, or a combination of dedicated hardware and code.

[0024] The description of an element in each figure may refer to the element in the series of figures, and like numbers refer to like elements in all figures, including alternative embodiments of like elements.

[0025] Generally, this disclosure describes systems, methods, and apparatus for efficient data collection from an OAM. In some embodiments, these methods may be performed using computer code embedded on a computer readable medium. In some embodiments, the apparatus or system may include a computer readable medium including computer readable code that, when executed by a processor, causes the apparatus or system to perform at least a portion of the solutions described below.

[0026] The Data Collection Coordination Function (DCCF) is a new network function that coordinates data collection from one or more NFs based on a data collection request from one or more consumer NFs. However, data collection from OAM requires specific services supported by the OAM platform where event IDs are not supported. Therefore, current network specifications do not support the DCCF to identify what data is required from the OAM platform based on a consumer request.

[0027] Described herein are solutions to solve these problems with data collection. The solutions below detail how a Network Data Analytics Function ("NWDAF") requests data available from the OAM via the DCCF, and how the DCCF determines what data is needed by a consumer NF (e.g., the NWDAF) from the OAM.

[0028] According to the first solution, data collected from the OAM may be stored in a Data Repository Function (DRF) in a Public Land Mobile Network (PLMN). In one embodiment of the first solution, when a data collection request from a consumer NF is sent to the OAM, the consumer NF may include in the request an indication that the data should be stored in the DRF in case a second consumer NF requires the same information. Such data is known as historical data. How the consumer NF determines that data should be available as historical data is up to the implementation of the NF. The OAM may also be configured by the network operator to store data in the DRF based on the network operator's expectation that such data will be required by multiple consumer NFs.

[0029] The OAM stores data in the DRF and updates the Network Function Repository Function (NRF) with information about the data stored in the DRF. This information includes data type (e.g., performance data file type, or performance data streaming), data type information (e.g., Reference Signal Received Power (RSRP), Reference Signal Received Quality (RSRQ), Channel Quality Indicator (CQI), downlink / uplink throughput, handover rate, etc.), measurement period and reporting target of the data (e.g., a specific User Equipment (UE), a specific group of UEs, or any UE), and data producer type (i.e., information identifying the data producer, e.g., OAM). When a second consumer NF needs the same data, the second consumer NF queries the NRF to identify whether there is a DRF that contains the required data. If a DRF is identified, the second consumer NF requests the data from the DRF directly or via the DCCF.

[0030] According to another embodiment of the first solution, a consumer NF that requires data from an OAM sends a request to the DCCF to collect the data, for example invoking an Ndccf service operation.

[0031] According to the second solution, data is collected in the DRF for OAM data via the DCCF. In one embodiment of the second solution, the consumer NF determines that data is required in the OAM. The consumer NF subscribes to the OAM to obtain the required data.

[0032] FIG. 1 illustrates a wireless communication system 100 for efficient data collection from OAM, according to an embodiment of the present disclosure. In one embodiment, the wireless communication system 100 includes at least one remote unit 105, a radio access network ("RAN") 120, and a mobile core network 140. The RAN 120 and the mobile core network 140 form a mobile communication network. The RAN 120 may be comprised of a base unit 121 with which the remote unit 105 communicates using a wireless communication link 123. Although a specific number of remote units 105, base units 121, wireless communication links 123, RAN 120, and mobile core network 140 are depicted in FIG. 1, one skilled in the art will recognize that any number of remote units 105, base units 121, wireless communication links 123, RAN 120, and mobile core network 140 may be included in the wireless communication system 100.

[0033] In one implementation, the RAN 120 is compliant with a Fifth-Generation ("5G") cellular system as specified in the Third Generation Partnership Project ("3GPP") specifications. For example, the RAN 120 may be a Next Generation Radio Access Network ("NG-RAN") that implements a New Radio ("NR") Radio Access Technology ("RAT") and / or a Long-Term Evolution ("LTE") RAT. In another example, the RAN 120 may include a non-3GPP RAT (e.g., Wi-Fi or an Institute of Electrical and Electronics Engineers ("IEEE") 802.11 family compliant WLAN). In another implementation, the RAN 120 is compliant with an LTE system as specified in the 3GPP specifications. More generally, however, the wireless communication system 100 may implement a number of other open or proprietary communication networks, such as a Worldwide Interoperability for Microwave Access ("WiMAX") or IEEE 802.16 family of standards network, among other networks. This disclosure is not intended to be limited to any particular wireless communication system architecture or protocol implementation.

[0034] In one embodiment, the remote unit 105 may include a computing device such as a desktop computer, a laptop computer, a personal digital assistant ("PDA"), a tablet computer, a smartphone, a smart television (e.g., a television connected to the Internet), a smart appliance (e.g., an appliance connected to the Internet), a set-top box, a gaming console, a security system (including security cameras), an in-vehicle computer, a network device (e.g., a router, a switch, a modem), or the like. In some embodiments, the remote unit 105 includes a wearable device such as a smart watch, a fitness band, an optical head mounted display, or the like. Additionally, the remote unit 105 may be referred to as a user equipment ("UE"), a subscriber unit, a mobile, a mobile station, a mobile device, a user, a terminal, a user terminal, a mobile terminal, a fixed terminal, a subscriber station, a wireless transmit / receive unit ("WTRU"), a communications device, or by other terms used in the art.

[0035] In various embodiments, the remote unit 105 includes a subscriber identity and / or identification module ("SIM") and mobile equipment ("ME") that provides mobile termination functions (e.g., radio transmission, handover, voice encoding and decoding, error detection and correction, signaling, and access to the SIM). In some embodiments, the remote unit 105 includes terminal equipment ("TE") and / or may be embedded in an appliance or device (e.g., a computing device as described above).

[0036] The remote units 105 may communicate directly with one or more of the base units 121 in the RAN 120 via uplink ("UL") and downlink ("DL") communication signals. Furthermore, the UL and DL communication signals may be carried over a wireless communication link 123. Furthermore, the UL communication signals may include one or more uplink channels, such as a Physical Uplink Control Channel ("PUCCH") and / or a Physical Uplink Shared Channel ("PUSCH"), while the DL communication signals may include one or more downlink channels, such as a Physical Downlink Control Channel ("PDCCH") and / or a Physical Downlink Shared Channel ("PDSCH"), where the RAN 120 is an intermediate network that provides the remote units 105 with access to the mobile core network 140.

[0037] In some embodiments, the remote unit 105 communicates with the application server 151 via a network connection with the mobile core network 140. For example, an application 107 (e.g., a web browser, a media client, a telephone and / or a Voice-over-Internet-Protocol (VoIP) application) in the remote unit 105 may trigger the remote unit 105 to establish a protocol data unit (PDU) session (or other data connection) with the mobile core network 140 via 5G-RAN. The mobile core network 140 then relays traffic between the remote unit 105 and the application server 151 in the packet data network 150 using the PDU session. The PDU session represents a logical connection between the remote unit 105 and the User Plane Function (UPF) 141.

[0038] To establish a PDU session (or PDN connection), the remote unit 105 must register with the mobile core network 140 (also referred to as "attached to the mobile core network" in the context of Fourth Generation ("4G") systems). It should be noted that the remote unit 105 may establish one or more PDU sessions (or other data connections) with the mobile core network 140. As such, the remote unit 105 may have at least one PDU session for communicating with the packet data network 150. The remote unit 105 may establish additional PDU sessions for communicating with other data networks and / or other communication peers.

[0039] In the context of a 5G system ("5GS"), the term "PDU Session" refers to a data connection that provides end-to-end ("E2E") user plane ("UP") connectivity between a remote unit 105 and a particular Data Network ("DN") through the UPF 141. A PDU Session supports one or more Quality of Service ("QoS") flows. In some embodiments, there may be a one-to-one mapping between QoS flows and QoS profiles, such that all packets belonging to a particular QoS flow have the same 5G QoS Identifier ("5QI").

[0040] In the context of 4G / LTE systems, such as the Evolved Packet System ("EPS"), a Packet Data Network ("PDN") connection (also referred to as an EPS session) provides E2E UP connectivity between a remote unit and a PDN. The PDN connectivity procedure establishes an EPS bearer, i.e., a tunnel between the remote unit 105 and a PDN Gateway ("PGW" (not shown) in the mobile core network 140). In some embodiments, there is a one-to-one mapping between EPS bearers and QoS profiles, such that all packets belonging to a particular EPS bearer have the same QoS Class Identifier ("QCI").

[0041] The base units 121 may be distributed over a geographic region. In some embodiments, the base units 121 may also be referred to as an access terminal, an access point, a base, a base station, a Node-B ("NB"), an evolved Node B (abbreviated as eNodeB or "eNB" and also referred to as an Evolved Universal Terrestrial Radio Access Network ("E-UTRAN") Node B), a 5G / NR Node B ("gNB"), a home Node B, a relay node, a RAN node, or other terms used in the art. The base units 121 are generally part of a RAN, such as the RAN 120, which may include one or more controllers communicatively coupled to one or more corresponding base units 121. These and other elements of a radio access network are not illustrated, but are generally familiar to those skilled in the art. The base units 121 connect to a mobile core network 140 via the RAN 120.

[0042] The base unit 121 may serve several remote units 105 in a serving area, e.g., a cell or a cell sector, via a wireless communication link 123. The base unit 121 may directly communicate with one or more of the remote units 105 via communication signals. In general, the base unit 121 transmits DL communication signals to serve the remote units 105 in the time, frequency, and / or spatial domains. Furthermore, the DL communication signals may be carried on the wireless communication link 123. The wireless communication link 123 may be any suitable carrier in a licensed or unlicensed radio spectrum. The wireless communication link 123 facilitates communication between one or more of the remote units 105 and / or one or more of the base units 121.

[0043] It should be noted that during NR operation in the unlicensed spectrum (referred to as "NR-U"), the base unit 121 and the remote unit 105 communicate over an unlicensed (i.e., shared) radio spectrum. Similarly, during LTE operation in the unlicensed spectrum (referred to as "LTE-U"), the base unit 121 and the remote unit 105 also communicate over an unlicensed (i.e., shared) radio spectrum.

[0044] In one embodiment, the mobile core network 140 is a 5G Core network ("5GC") or Evolved Packet Core ("EPC"), which may be coupled to a packet data network 150, such as the Internet and private data networks, among other data networks. The remote units 105 may have a subscription or other account with the mobile core network 140. In various embodiments, each mobile core network 140 belongs to a single mobile network operator ("MNO") and / or Public Land Mobile Network ("PLMN"). This disclosure is not intended to be limited to any particular wireless communications system architecture or protocol implementation.

[0045] The mobile core network 140 includes several network functions (“NFs”). As depicted, the mobile core network 140 includes at least one UPF 141. The mobile core network 140 also includes multiple control plane (CP) functions including, but not limited to, an Access and Mobility Management Function ("AMF") 142, a Session Management Function ("SMF") 143, an Application Function ("AF") 144, a Network Data Analytics Function ("NWDAF") 145, a Network Function Repository Function ("NRF") 146, a Data Repository Function ("DRF") 147, a Data Collection Coordination Function ("DCCF") 148, a Unified Data Management function ("UDM"), and a User Data Repository ("UDR") that provide services to the 5G-RAN. In some embodiments, the UDM is co-located with the UDR and is depicted as a combined entity "UDM / UDR" 149. Although a particular number and type of network functions are depicted in FIG. 1, those skilled in the art will recognize that any number and type of network functions may be included in the mobile core network 140.

[0046] The UPF 141 is responsible for packet routing and forwarding, packet inspection, QoS handling, and external PDU sessions for interconnecting Data Networks ("DNs") in the 5G architecture. The AMF 142 is responsible for Non-Access Spectrum ("NAS") signaling termination, NAS encryption and integrity protection, registration management, connection management, mobility management, access authentication and authorization, and security context management. The SMF 143 is responsible for session management (i.e., session establishment, modification, release), remote unit (i.e., UE) Internet Protocol ("IP") address allocation and management, DL data notification, and traffic steering configuration of the UPF 141 for proper traffic routing.

[0047] The AF 144 is responsible for application influence on traffic routing and / or interacting with a policy framework for policy control. In some embodiments, the AF 144 establishes quality of service ("QoS") for particular applications residing on the network and / or services provided by the network. In some embodiments, the AF 144 exposes services to end users, such as remote units 105.

[0048] The NWDAF 145 is responsible for collecting data from other network functions of the mobile core network 140 and providing analytics services to support, for example, network automation, closed-loop operation, self-healing, experience improvement, and / or reporting. The NWDAF 145 may interface with various network functions to collect events that may be subject to analysis.

[0049] The NRF 146 is responsible for providing registration and discovery of Network Function ("NF") services, allowing NFs to identify appropriate services in each other and communicate with each other via application programming interfaces ("APIs").

[0050] The DRF 147 is responsible for storing historical network-related data that is generated by one or more producer NFs in the mobile core network 140 and used (i.e., consumed) by one or more consumer NFs in the mobile core network 140.

[0051] The DCCF 148 coordinates the collection of data from one or more NFs based on data collection requests from one or more consumer NFs.

[0052] The UDM is responsible for generating Authentication and Key Agreement ("AKA") credentials, handling user identities, access authorization, and subscription management. The UDR is a repository of subscriber information and can be used to provide services to several network functions. For example, the UDR can store subscription data, policy related data, subscriber related data that is allowed to be exposed to third-party applications, and the like.

[0053] In various embodiments, the mobile core network 140 may also include additional NFs, such as an Authentication Server Function ("AUSF") (e.g., an authentication server and / or authentication proxy that allows the AMF 142 to authenticate the remote unit 105), a Policy Control Function ("PCF") (e.g., responsible for a unified policy framework, providing policy rules to the CP function, access subscription information for policy decisions in the UDR), a Network Exposure Function ("NEF") (e.g., responsible for making network data and resources easily accessible to customers and network partners), or other NFs defined for 5GC. In certain embodiments, the mobile core network 140 may include an authentication, authorization, and accounting ("AAA") server.

[0054] In various embodiments, the mobile core network 140 supports different types of mobile data connections and different types of network slices, each mobile data connection utilizing a particular network slice. A "network slice" refers to a portion of the mobile core network 140 optimized for a particular traffic type or communication service. For example, one or more network slices may be optimized for enhanced mobile broadband ("eMBB") services. As another example, one or more network slices may be optimized for ultra-reliable low-latency communication ("URLLC") services. In other examples, a network slice may be optimized for machine-type communication ("MTC") services, massive machine-type communication ("mMTC") services, Internet-of-Things ("IoT") services. In yet other examples, a network slice may be deployed for a particular application service, vertical service, a particular use case, or the like.

[0055] A network slice instance may be identified by a single-network slice selection assistance information ("S-NSSAI"), whereas a set of network slices that the remote unit 105 is authorized to use is identified by a network slice selection assistance information ("NSSAI"), where "NSSAI" refers to a vector value that includes one or more S-NSSAI values. In some embodiments, various network slices may include separate instances of network functions, such as the SMF 143 and the UPF 141. In some embodiments, different network slices may share some common network functions, such as the AMF 142. Different network slices are not shown in FIG. 1 for ease of illustration, although support for them is assumed.

[0056] The wireless communication system 100 includes an operations, administration, and management ("OAM") platform 160. The operations, administration, and maintenance ("OAM") platform 160 is responsible for the operation, administration, management, and maintenance of the system 100. "Operation" encompasses automatic monitoring of the environment, detection and determination of faults, and alerting administrators. "Management" involves collection of performance statistics, accounting data for billing purposes, capacity planning using usage data, and maintaining system reliability. Management may also involve maintenance of a service database used to determine periodic billing. "Maintenance" involves upgrades, modifications, new feature activation, backup and restore, and monitoring of media health. In some embodiments, the OAM platform 160 may also be involved in provisioning, i.e., setting up user accounts, devices, and services. It should be noted that the OAM platform 160 may receive parameters and / or configurations from a Business Support System ("BSS") and / or an Operations Support System ("OSS").

[0057] Management services for a mobile communication network (with or without network slicing) may be produced by any entity. For example, it may be a Network Function ("NF") or a network management function. An entity may provide (i.e., produce) management services, such as, for example, a performance management service, a configuration management service, a fault monitoring service, etc. A management service may be consumed by another entity and may then produce (i.e., expose) a service to other entities.

[0058] Although FIG. 1 depicts components of a 5G RAN and a 5G core network, the described embodiments for efficient data collection from OAM apply to other types of communication networks and RATs, including IEEE 802.11 variants, Global System for Mobile Communications ("GSM"), i.e., 2G digital cellular networks, General Packet Radio Service ("GPRS"), Universal Mobile Telecommunications System ("UMTS"), LTE variants, CDMA 2000, Bluetooth, ZigBee, Sigfox, and the like.

[0059] Further, in LTE variants where the Mobile Core Network 140 is the EPC, the depicted network functions may be replaced with appropriate EPC entities such as a Mobility Management Entity ("MME"), a Serving Gateway ("SGW"), a PGW, a Home Subscriber Server ("HSS"), and the like. For example, the AMF 142 may be mapped to the MME, the SMF 143 may be mapped to the control plane portion of the PGW and / or to the MME, the UPF 141 may be mapped to the SGW and the user plane portion of the PGW, the UDM / UDR 149 may be mapped to the HSS, etc.

[0060] In the following description, the term "gNB" is used for base station / base unit, but this can be replaced with any other radio access node, e.g., RAN node, ng-eNB, eNB, base station (BS), access point (AP), etc. In addition, the term "UE" is used for mobile station / remote unit, but this can be replaced with any other remote device, e.g., remote unit, MS, ME, etc. Furthermore, the operations are mainly described in the context of 5G NR. However, the solutions / methods described below are equally applicable to other mobile communication systems for efficient data collection from OAM.

[0061] 2 illustrates an exemplary procedure 200 for data collection via a DCCF according to an embodiment of the present disclosure. The procedure 200 includes a consumer NF 205 (e.g., an NWDAF), a DCCF 210, an NRF 215, and multiple data producer NFs (depicted here as an AMF 142, an SMF 143, and an AF 144). Note that the consumer NF 205 may be an embodiment of the NWDAF 145, the DCCF 210 may be an embodiment of the DCCF 148, and the DRF 225 may be an embodiment of the DRF 147. The procedure 200 for collecting data via the DCCF 210 includes the following:

[0062] In step 1, the consumer NF 205 requests data from the DCCF 210, for example, by invoking an Ndccf service operation on the DCCF 210. In the request, the consumer NF 205 includes an event ID for data collection. The event IDs are summarized in section 4.15 of 3GPP Technical Specification ("TS") 23.502, which includes event IDs supported by each NF (e.g., AMF 142, SMF 143, AF 144, etc.).

[0063] In step 2, the DCCF 210 determines the data producer NF type (i.e., AMF, SMF, AF) from the event ID requested by the consumer NF 205 since there are specific event IDs supported by each NF (e.g., AMF 142, SMF 143, AF 144, etc.).

[0064] In step 3, the DCCF 210 determines the NF instance that has the required data from the NRF 215.

[0065] In step 4, DCCF 210 subscribes to be notified of events from each NF type, for example, using the Nnf_Event_Exposure subscription.

[0066] As described above, data collection from the OAM requires specific services supported by the OAM platform for which event IDs are not supported. Thus, when a consumer NF 205 determines that data is required from an OAM entity 220, the DCCF 210 may map the consumer NF 205 request to an OAM-specific service procedure to request the data from the OAM entity 220, as described in more detail below.

[0067] In some embodiments, the consumer NF 205 may make a direct request for data collection to the OAM entity 220. In some embodiments, the consumer NF 205 may make a direct request to the NRF 215 to identify a DRF 225 that has the requested data. In such embodiments, the consumer NF 205 may then make a direct request for data collection to the identified DRF 225.

[0068] According to an embodiment of the first solution, data collection is facilitated via a data collection function, and data collected from the OAM may be stored in a DRF in the PLMN. In some implementations of the first solution, a consumer NF may request data directly from the OAM after determining that data is needed from the OAM.

[0069] In some embodiments, when a data collection request from a consumer NF is sent to the OAM, the consumer NF may include in the request an indication that the data needed will be stored in the DRF if a second consumer NF needs the same information. Such data is known as "historical" data. How the consumer NF determines that data should be available as historical data may be up to the implementation of the NF. The OAM may also be configured by the network operator to store data in the DRF based on the network operator's expectation that such data will be needed by multiple consumer NFs.

[0070] The OAM stores data in the DRF and updates the NRF with information about the data stored in the DRF. This information includes one or more of the following: data type (e.g., performance data file type, or performance data streaming), data type information (e.g., RSRP, RSRQ, CQI, throughput, handover rate), measurement period of the data, target of the report (e.g., a specific UE, a specific group of UEs, or any UE), and / or data producer type (information identifying the data producer, i.e., OAM). Note that the data type information may include data types defined in 3GPP TS 28.532 and 3GPP TS 28.550 based on the data requested by the consumer. When a second consumer NF needs the same data, the NF queries the NRF to identify whether there is a DRF that contains the required data. If a DRF is identified, the NF requests the data from the DRF directly or via the DCCF.

[0071] 3 illustrates an exemplary procedure 300 for storing data in a DRF in an OAM according to an embodiment of the first solution. The procedure 300 involves a consumer NF 205 (e.g., an NWDAF), an OAM entity and / or a DCCF (depicted as a combined entity "OAM / DCCF" 305), a DRF 225, and an NRF 215. The procedure for storing data in the DRF 225 includes the following steps:

[0072] In step 1, the consumer NF 205 determines that data is needed from the OAM plane, e.g., the OAM / DCCF 305 (see block 310). In one embodiment, the consumer NF 205 may check with the NRF 215 to determine whether the needed data is already available in the DRF, as described below with reference to Figure 4. In the depicted embodiment, it is assumed that the needed data is not already available in the DRF 225, and therefore the consumer NF 205 decides to request the data from the OAM / DCCF 305.

[0073] In step 2a, the consumer NF 205 may identify an OAM node (e.g., OAM entity 220) and request the needed data. Alternatively, the consumer NF 205 requests the OAM data from a DCCF (e.g., DCCF 210). In some embodiments, the OAM entity 220 may support a data collection and coordination function. In some embodiments, the consumer NF 205 requests the data using procedures described in 3GPP TS 28.532 and 3GPP TS 28.550.

[0074] In the depicted embodiment, the consumer NF 205 sends a subscribe request message (see Messaging 315) to the OAM / DCCF 305. As described above, the consumer NF 205 may include in the request an indication that the required data is to be stored in the DRF 225, i.e., as historical data.

[0075] In optional step 2b, the network operator may configure the OAM / DCCF 305 to store the collected data in the DRF 225 (see messaging 320), where this configuration may be OAM vendor specific.

[0076] In step 3, the OAM / DCCF 305 processes the required data (see block 325).

[0077] In step 4, the OAM / DCCF 305 stores the data in the DRF 225 (see Messaging 330). In some embodiments, the information provided to the DRF 225 may include one or more of a data type (i.e., performance data file type or performance data streaming type), data type information (i.e., a particular category of data type, e.g., RSRP), a measurement period for the data, a target of the report (e.g., a UE, a group of UEs, or any UE), and / or a data producer type (i.e., information identifying the data producer, e.g., OAM).

[0078] In step 5, the NRF 215 is updated with information stored in the DRF 225, for example, by either the OAM / DCCF 305 (option A) or the DRF 225 (option B).

[0079] Step 5a represents a first embodiment in which the OAM / DCCF 305 updates the NRF 215 with information stored in the DRF 225 (see messaging 335). Note that the information stored in the DRF 225 may include one or more of the following: data type, data type information, data measurement period, reporting target, and / or data producer type.

[0080] Step 5b represents an alternative embodiment in which the DRF 225 may update the NRF 215 with such data (see messaging 340). Again, the information stored in the DRF 225 may include one or more of the data type, data type information, measurement period of the data, target of reporting, and / or data producer type.

[0081] In step 6, the OAM / DCCF 305 may provide the data directly to the consumer NF 205 (see messaging 345). Alternatively, the OAM / DCCF 305 provides a DRF address where the data is available, so that the consumer NF 205 can fetch the information from the DRF 225.

[0082] 4 shows an example procedure 400 for determining by a consumer NF whether data is available at a DRF according to an embodiment of the first solution. The procedure 400 involves a consumer NF 205, an NRF 215, a DRF 225, and an OAM entity 220. The procedure for the consumer NF 205 to collect data directly from the DRF 225 includes the following steps.

[0083] In step 1, the consumer NF 205 requires data available in the OAM plane. The consumer NF 205 decides to check with the NRF 215 to determine whether the required data is already available in the DRF (see block 405).

[0084] In step 2, the consumer NF 205 queries the NRF 215 for a DRF address containing the required information (see messaging 410). The consumer NF 205 includes the required data by including in the request one or more of the following: a data type (i.e., performance data file type or performance data streaming type), data type information (i.e., a specific category of data type, e.g., RSRP), a measurement period of the data, a target of the report (e.g., a UE, a group of UEs, or any UE), a data producer type (i.e., information identifying the data producer, e.g., OAM), and / or an indication of whether the information is required only once or is provided at regular intervals (i.e., a subscription request).

[0085] In step 3, the NRF 215 checks its internal database and, if available, provides a response with the DRF address (eg, DRF instance ID and / or DRF IP address) containing the data (see messaging 415).

[0086] In step 4, the consumer NF 205 requests data from the DRF 225 (see messaging 420), where the request includes one or more of a data type (e.g., performance data), data type information (e.g., RSRP), a measurement period for the data, a target for the report (e.g., a specific UE, a specific group of UEs, or any UE), and whether the information is needed only once or is provided at periodic intervals (i.e., a subscription request).

[0087] In step 5, the DRF 225 obtains the data (see block 425). If the data is not already available locally at the DRF 225, the DRF 225 requests / retrieves the required data from the OAM entity 220, as shown in optional steps 6 to 8.

[0088] In step 6, the DRF 225 interfaces with the OAM entity 220, thereby fetching the requested data using procedures defined in, for example, 3GPP TS 28.532 and / or TS 28.550 (see messaging 430).

[0089] In step 7, the OAM entity 220 provides the requested data (see messaging 435).

[0090] In step 8, the DRF 225 stores the data in a database (see block 440).

[0091] In step 9, the DRF 225 provides the local data to the consumer NF 205 in response to the query data request (see messaging 445).

[0092] According to another embodiment of the first solution, a consumer NF 205 that requires data from the OAM entity 220 may send a request to collect the data to the DCCF 210, for example by invoking an Ndccf service operation. In the Ndccf service operation request, the consumer NF 205 may include one or more of the following information: ● Data Type: The type of data that is required to be collected. If data is required to be retrieved from the OAM, the data type field includes performance data file type, performance data streaming, trace data, or analytics data. ● Data type information: Data required based on the data type request, for example as defined in 3GPP TS 28.532 and 3GPP TS 28.550. ●The period during which the data was measured. • The target of the report (e.g., a specific UE, a specific group of UEs, or any UE). ● The data producer type (i.e., OAM).

[0093] Based on the service operation request, the DCCF 210 determines whether the required data is available in a DRF, such as the DRF 225. If the required data is not available in the DRF, the DCCF 210 requests the data from the OAM entity 220, for example, using procedures and APIs defined in 3GPP TS 28.532 and / or 3GPP TS 28.550. The DCCF 210 maps information in the Ndccf service operation request (e.g., data type, data type information, measurement period of the data, and / or target of the report) to the OAM entity 220, for example, based on APIs defined in 3GPP TS 28.532 and / or 3GPP TS 28.550. When the OAM entity 220 reports the data, the DCCF 210 may store the data in the DRF 225, for example, if the first request indicates that the data should be available as historical data in case a second consumer NF needs the same information.

[0094] 5 shows an example procedure 500 for a consumer NF to request OAM data via a DCCF according to an embodiment of the first solution. The procedure 500 involves a consumer NF 205, a DCCF 210, a DRF 225, and an OAM entity 220. The procedure for the consumer NF 205 to request OAM data via the DCCF 210 includes the following steps.

[0095] In step 1, the consumer NF 205 determines that data available from the OAM plane is required (see block 505).

[0096] In step 2, the consumer NF 205 sends a request to the DCCF 210 for data available from the OAM plane (see messaging 510). In the depicted embodiment, the consumer NF 205 sends a query data request that includes information to identify the data needed. For example, the consumer NF 205 may include in the request one or more of the following information: data type (e.g., performance data streaming, or performance data file type), data type information (e.g., RSRP), measurement period and reporting target of the data (UE, group of UEs, or any UE), data producer type (i.e., OAM), and whether the information is needed only once or is provided at regular intervals (subscription request). In one embodiment, the data producer type may also include the address of the OAM node (e.g., OAM entity 220).

[0097] In step 3, the DCCF 210 checks whether the data is available in the DRF 225 (see block 515). In one embodiment, the DCCF 210 may also check with the NRF 215 to identify the address of the DRF 225 that contains the data.

[0098] In step 4, the DCCF 210 sends a request to the DRF 225 with the data information provided in step 2 (see messaging 520).

[0099] In step 5, the DRF 225 responds as to whether the required data is available (see messaging 525).

[0100] In step 6, if the required data is not available in the DRF 225, the DCCF 210 determines (see block 530), i.e., based on the data producer type, that the required data must be collected by an OAM, e.g., the OAM entity 220. The DCCF 210 maps the parameters provided in step 2 to an OAM-specific service procedure to request the data from the OAM entity 220.

[0101] In step 7, the DCCF 210 locates the OAM entity 220 and requests the required data (see messaging 535), for example, using procedures described in 3GPP TS 28.532 and / or 3GPP TS 28.550.

[0102] In step 8, the OAM entity 220 reports the data to the DCCF 210 (see messaging 540), for example, using procedures described in 3GPP TS 28.532 and / or 3GPP TS 28.550.

[0103] In step 9, if the required data was not available in the DRF 225, the DCCF 210 may store the data in the DRF 225 using, for example, an Ndrf service operation (see messaging 545).

[0104] In step 10, the DRF 225 acknowledges the data storage operation (see messaging 550).

[0105] In step 11, the DCCF 210 provides the requested data to the consumer NF 205 in response to the query request (see messaging 555).

[0106] According to an embodiment of the second solution, data is collected in the DRF for OAM data via the DCCF. In one embodiment of the second solution, the consumer NF determines that data is required in the OAM. The consumer NF subscribes to the OAM to obtain the required data, for example using the procedures described in 3GPP TS 28.532 and 3GPP TS 28.550.

[0107] The OAM then starts processing the data. After the data is available, the OAM creates files containing the requested data and stores them in a local database. The OAM notifies the consumer NF that the data is available. The OAM includes in the response a fileInfoList parameter, which contains information about the location of the file to get the data from and the type of data in the file (i.e. performance, trace, analytics, proprietary) (note that the parameter fileInfoList can be optional). This is shown in Table 1 below.

[0108] [Table 1]

[0109] The consumer NF then requests the DCCF, for example using an Ndccf service operation, to collect the data from the specified location and optionally store the data in the DRF. The DCCF may include one or more of the following information in the request: File location ● Type of data (e.g. performance, analytics, trace, etc.) Data measurement period • The target of the report (e.g., a specific UE, a group of UEs, or any UE).

[0110] The DCCF then collects the data from the OAM database and stores it in the DRF. For subsequent requests from consumer NFs that require the same data, the DCCF provides the data available in the DRF.

[0111] 6 shows an exemplary procedure 600 for the DCCF to collect data from the OAM according to an embodiment of the second solution. The procedure 600 involves a consumer NF 205, a DCCF 210, a DRF 225, an OAM entity 220, and a data source 605. The procedure 600 for the DCCF 210 to collect data from the OAM entity 220 includes the following steps:

[0112] In step 1, the consumer NF 205 determines that data from the OAM plane is needed (see block 610). As an example, the consumer NF 205 may be an embodiment of an NWDAF 145 that needs data for analytics generation. As another example, the consumer NF 205 may be an embodiment of a DCCF that requests data from a different DCCF.

[0113] In step 2, the consumer NF 205 subscribes to the OAM entity 220 to obtain the required data, for example, according to procedures described in 3GPP TS 28.532 and / or TS 28.550 (see messaging 615). If the request is for streaming data, the consumer NF 205 provides a target address (e.g., the address of the data source 605) for sending the streaming data. One example of this process is when the consumer NF 205 requests to "create an MOI," where "MOI" refers to a managed object instance, as described in 3GPP TS 28.532 and TS 28.550.

[0114] In step 3, the OAM entity 220 sends a response acknowledging the request (see messaging 620).

[0115] In step 4, the OAM entity 220 processes the required data (see block 625).

[0116] In step 5, for file type data, after the required data is available, the OAM entity 220 notifies the consumer NF 205 of the availability of the required data and the location of the data (i.e., the address of the data source 605) (see messaging 630), for example, as described in 3GPP TS 28.532 and 28.550.

[0117] In optional step 6, the OAM entity 220 provides streaming or file type data to the data source 605 (see messaging 635).

[0118] In step 7, the consumer NF 205 discovers the DCCF 210 and requests the DCCF 210 to collect and store data (see block 640).

[0119] In step 8, the Consumer NF 205 sends a request to the DCCF 210 via an Ndccf Service Operation Request (see messaging 645). In the embodiment shown, the request includes one or more of the following information of the data required: location of the data (i.e., data source address), type of data, measurement period of the data, and / or target of the report (e.g., a specific UE, a group of UEs, or any UE).

[0120] In optional step 9, DCCF 210 collects data from specified locations (see messaging 650).

[0121] At step 10, the DCCF 210 stores the type of data collected (see block 655). In an alternative embodiment, the DCCF 210 may update the NRF 215 with the type of data collected and available in the DRF 225.

[0122] In step 11, the DCCF 210 initiates the Ndrf service which stores the data in the DRF 225 (see messaging 660).

[0123] In step 12, the DRF 225 stores the data locally (see block 665).

[0124] In step 13, the DRF 225 acknowledges the request (see block 670).

[0125] In step 14, the DCCF 210 provides the requested data in an Ndccf service operation response to the consumer NF 205 (see messaging 675).

[0126] 7 illustrates a network device 700 that may be used for efficient data collection from OAM, according to an embodiment of the present disclosure. In some embodiments, the network device 700 may be an embodiment of an OAM system and its supporting hardware, such as OAM platform 160 and / or OAM entity 220, as described above. In other embodiments, the network device 700 may be an embodiment of a DCCF and its supporting hardware, such as DCCF 148 and / or DCCF 210, as described above. Additionally, the network device 700 may comprise a processor 705, a memory 710, an input device 715, an output device 720, and a transceiver 725.

[0127] In some embodiments, the input device(s) 715 and the output device(s) 720 are combined into a single device, such as a touch screen. In some embodiments, the network apparatus 700 may not include the input device(s) 715 and / or the output device(s) 720. In various embodiments, the network apparatus 700 may comprise one or more of the processor 705, the memory 710, and the transceiver 725, and may not include the input device(s) 715 and / or the output device(s) 720.

[0128] As depicted, the transceiver 725 includes at least one transmitter 730 and at least one receiver 735, where the transceiver 725 communicates with one or more remote units 105. In addition, the transceiver 725 may support at least one network interface 740 and / or an application interface 745. The application interface 745 may support one or more APIs. The network interface 740 may support 3GPP reference points such as Uu, N1, N2, and N3. As will be appreciated by one of ordinary skill in the art, other network interfaces 740 may also be supported.

[0129] When implementing an OAM, the network interface 740 may include interfaces for communicating with a consumer NF, a DRF, an NRF, a DCCF, and / or a data source, e.g., using service operations, as described above. When implementing a DCCF, the network interface 740 may include interfaces for communicating with a consumer NF, a DRF, and / or an OAM, e.g., using service operations, as described above.

[0130] The processor 705, in one embodiment, may include any known controller capable of executing computer-readable instructions and / or performing logical operations. For example, the processor 705 may be a microcontroller, a microprocessor, a Central Processing Unit ("CPU"), a Graphics Processing Unit ("GPU"), an auxiliary processing unit, a Field Programmable Gate Array ("FPGA"), or a similar programmable controller. In some embodiments, the processor 705 executes instructions stored in the memory 710 to perform the methods and routines described herein. The processor 705 is communicatively coupled to the memory 710, the input device 715, the output device 720, and the transceiver 725.

[0131] In some embodiments, the network device 700 is a RAN node (e.g., gNB) that communicates with one or more UEs as described herein. In such embodiments, the processor 705 controls the network device 700 to perform the RAN operations described above. When operating as a RAN node, the processor 705 may include an application processor (also referred to as a “main processor”) that manages application domains and operating system (“OS”) functions, and a baseband processor (also referred to as a “baseband radio processor”) that manages radio functions.

[0132] In various embodiments, the network device 700 comprises an OAM entity that communicates with one or more entities in a mobile communications network (e.g., via the transceiver 725 and / or the network interface 740) as described herein. In such embodiments, the processor 705 controls the network device 700 to perform the OAM operations described above.

[0133] In some embodiments, the transceiver 725 (i.e., implementing the network interface 740) receives a first request from a first network function (e.g., from a consumer NF) to provide data for at least one data type information, where the first request includes an indication that the data is available as historical data. The processor 705 processes the data needed according to the first request and sends a second request to the DRF, where the second request includes the data needed and an indication that the data is available as historical data. Via the transceiver 725, the processor 705 provides the needed data to the first network function.

[0134] In some embodiments, providing the required data to the first network function includes transmitting an address of a DRF from which the required data can be retrieved. In some embodiments, the processor 705 further transmits a third request to the NRF, the third request including information of the data available in the DRF. In some embodiments, the information of the data available in the DRF includes one or more of A) data type, B) data type information, C) measurement period of the data, D) target of reporting, and / or E) data producer type.

[0135] In some embodiments, the first request further indicates at least one characteristic of the requested data, the at least one characteristic being one or more of A) data type, B) data type information, C) measurement period of the data, D) target for reporting, and / or E) data producer type. In some embodiments, the second request further indicates at least one characteristic of the required data, the at least one characteristic being one or more of A) data type, B) data type information, C) measurement period of the data, D) target for reporting, and / or E) data producer type.

[0136] In various embodiments, the network device 700 comprises a DCCF that communicates with one or more entities in a mobile communications network (e.g., via the transceiver 725 and / or the network interface 740) as described herein. In such embodiments, the processor 705 controls the network device 700 to perform the operations of the DCCF described above.

[0137] In some embodiments, there is a transceiver 725 (i.e., implementing a network interface) that receives a first request to provide data from a first network function (e.g., from a consumer NF), where the first request includes first information for identifying the requested data.

[0138] The processor 705 determines whether the requested data is available in the DRF, and the first information indicates that the requested data is to be retrieved from the OAM platform. Via the transceiver 725, the processor 725 retrieves the requested data from the DRF when the requested data is available in the DRF, and transmits a second request to the OAM platform to retrieve the data when the requested data is not available in the DRF, the second request including a request for data based on the first information.

[0139] In various embodiments, the processor 705 further provides the required data to the first network function. In some embodiments, determining whether the requested data is available at the DRF includes sending a query to the NRF that identifies an address of the DRF that contains the requested data.

[0140] In some embodiments, the first information for identifying the data includes one or more of the following fields: A) a data type field including a type of data that needs to be collected; B) a data type information field including metrics to be provided according to the data type field; C) information identifying a measurement period for the data; D) information identifying a target device for reporting the measurement data; and / or E) a data producer type identifying an OAM for retrieving the data.

[0141] In some embodiments, the data producer type field includes an address of the OAM platform. In some embodiments, the first information further indicates whether the information is required only once or is provided at regular intervals (i.e., a subscription request).

[0142] Memory 710, in one embodiment, is a computer-readable storage medium. In some embodiments, memory 710 includes volatile computer storage media. For example, memory 710 may include RAM, including dynamic RAM ("DRAM"), synchronous dynamic RAM ("SDRAM"), and / or static RAM ("SRAM"). In some embodiments, memory 710 includes non-volatile computer storage media. For example, memory 710 may include a hard disk drive, flash memory, or any other suitable non-volatile computer storage device. In some embodiments, memory 710 includes both volatile and non-volatile computer storage media.

[0143] In some embodiments, memory 710 stores data related to efficient data collection from the OAM and / or mobile operations. For example, memory 710 may store parameters, configurations, resource allocations, policies, and the like, as described above. In some embodiments, memory 710 also stores program code and related data, such as an operating system or other controller algorithms that operate on device 700.

[0144] The input device 715, in one embodiment, may include any known computer input device, including a touch panel, buttons, a keyboard, a stylus, a microphone, or the like. In some embodiments, the input device 715 may be integrated with the output device 720, for example, as a touch screen or similar touch-sensitive display. In some embodiments, the input device 715 includes a touch screen such that text may be entered using a virtual keyboard displayed on the touch screen and / or by handwriting on the touch screen. In some embodiments, the input device 715 includes two or more different devices, such as a keyboard and a touch panel.

[0145] The output device 720, in one embodiment, is designed to output visual, auditory, and / or tactile signals. In some embodiments, the output device 720 includes an electronically controllable display or display device capable of outputting visual data to a user. For example, the output device 720 may include, but is not limited to, a liquid-crystal display ("LCD"), a light-emitting diode ("LED") display, an organic LED ("OLED") display, a projector, or a similar display device capable of outputting images, text, or the like to a user. As another non-limiting example, the output device 720 may include a wearable display that is separate from, but communicatively coupled to, the rest of the network apparatus 700, such as a smart watch, smart glasses, a head-up display, or the like. Additionally, the output device 720 may be a component of a smartphone, a personal digital assistant, a television, a table computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, or the like.

[0146] In some embodiments, output device 720 includes one or more speakers for generating sound. For example, output device 720 may generate an audible alert or notification (e.g., a beep or chime). In some embodiments, output device 720 includes one or more haptic devices for generating vibration, movement, or other haptic feedback. In some embodiments, all or a portion of output device 720 may be integrated with input device 715. For example, input device 715 and output device 720 may form a touch screen or similar touch-sensitive display. In other embodiments, output device 720 may be located near input device 715.

[0147] The transceiver 725 includes at least one transmitter 730 and at least one receiver 735. The one or more transmitters 730 may be used to communicate with network functions in a Public Land Mobile Network ("PLMN") and / or a RAN, as described herein. Similarly, the one or more receivers 735 may be used to communicate with network functions. Although only one transmitter 730 and one receiver 735 are illustrated, the network device 700 may have any suitable number of transmitters 730 and receivers 735. Furthermore, the transmitters 730 and receivers 735 may be any suitable type of transmitter and receiver.

[0148] 8 illustrates one embodiment of a method 800 for handling data collection requests according to embodiments of the disclosure. In various embodiments, method 800 is performed by a data management device, such as DCCF 148, OAM 160, DCCF 210, OAM entity 220, and / or network equipment 700, as described above. In some embodiments, method 800 is performed by a processor, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, or the like.

[0149] The method 800 starts by receiving 805 a first request to provide data from a first network function (e.g., a consumer NF), the first request including an indication that the data is available as historical data. The method 800 includes processing 810 the needed data according to the first request. The method 800 includes sending 815 a second request to the DRF, the second request including the needed data and an indication that the data is available as historical data. The method 800 includes providing 820 the needed data to the first network function. The method 800 ends.

[0150] 9 illustrates one embodiment of a method 900 for coordinating data collection at a network entity, according to an embodiment of the disclosure. In various embodiments, method 900 is performed by a data collection coordinating entity, such as DCCF 148, DCCF 210, and / or network device 700, as described above. In some embodiments, method 900 is performed by a processor, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, or the like.

[0151] The method 900 starts by receiving 905 a first request to provide data from a first network function (e.g., from a consumer NF), the first request including first information for identifying the requested data. The method 900 includes determining 910 whether the requested data is available in the DRF, the first information indicating that the requested data is to be retrieved from the OAM platform. The method 900 includes retrieving 915 the requested data from the DRF when the requested data is available in the DRF. The method 900 includes sending 920 a second request to the OAM platform to retrieve the data when the requested data is not available in the DRF, the second request including a request for the data based on the first information. The method 900 ends.

[0152] Disclosed herein is a first apparatus for handling a data collection request according to an embodiment of the present disclosure. The first apparatus may be implemented by a data management device, such as DCCF 148, OAM 160, DCCF 210, OAM entity 220, and / or network device 700, as described above. The first apparatus comprises a processor and a transceiver (i.e., implementing a network interface 740) that receives a first request to provide data for at least one data type information from a first network function (e.g., from a consumer NF), the first request including an indication that the data is available as historical data. The processor processes the data required according to the first request and sends a second request to the DRF, the second request including the required data and an indication that the data is available as historical data. The processor provides the required data to the first network function.

[0153] In some embodiments, providing the required data to the first network function includes transmitting an address of a DRF from which the required data can be retrieved. In some embodiments, the processor further transmits a third request to the NRF, the third request including information of the data available in the DRF. In some embodiments, the information of the data available in the DRF includes one or more of A) data type, B) data type information, C) measurement period of the data, D) target of reporting, and / or E) data producer type.

[0154] In some embodiments, the first request further indicates at least one characteristic of the requested data, the at least one characteristic being one or more of A) data type, B) data type information, C) measurement period of the data, D) target for reporting, and / or E) data producer type. In some embodiments, the second request further indicates at least one characteristic of the required data, the at least one characteristic being one or more of A) data type, B) data type information, C) measurement period of the data, D) target for reporting, and / or E) data producer type.

[0155] Disclosed herein is a first method for handling a data collection request according to an embodiment of the present disclosure. The first method may be performed by a data management device, such as DCCF 148, OAM 160, DCCF 210, OAM entity 220, and / or network device 700, as described above. The first method includes receiving a first request to provide data from a first network function (e.g., from a consumer NF), the first request including an indication that the data is available as historical data. The first method includes processing the required data according to the first request. The first method includes sending a second request to the DRF, the second request including the required data and an indication that the data is available as historical data. The first method includes providing the required data to the first network function.

[0156] In some embodiments, providing the required data to the first network function includes transmitting an address of a DRF from which the required data can be retrieved. In some embodiments, the first method includes transmitting a third request to the NRF, the third request including information of the data available in the DRF. In some embodiments, the information of the data available in the DRF includes one or more of A) data type, B) data type information, C) measurement period of the data, D) target of reporting, and / or E) data producer type.

[0157] In some embodiments, the first request further indicates at least one characteristic of the requested data, the at least one characteristic being one or more of A) data type, B) data type information, C) measurement period of the data, D) target for reporting, and / or E) data producer type. In some embodiments, the second request further indicates at least one characteristic of the required data, the at least one characteristic being one or more of A) data type, B) data type information, C) measurement period of the data, D) target for reporting, and / or E) data producer type.

[0158] Disclosed herein is a second apparatus for coordinating data collection at a network entity according to an embodiment of the present disclosure. The second apparatus may be implemented by a data collection coordination entity, such as DCCF 148, DCCF 210, and / or network apparatus 700, as described above. The second apparatus comprises a processor and a transceiver (i.e., implementing a network interface) that receives a first request to provide data from a first network function (e.g., from a consumer NF), the first request including first information for identifying the requested data.

[0159] The processor determines whether the requested data is available at the DRF, and the first information indicates that the requested data is to be retrieved from the OAM platform. Via the transceiver, the processor retrieves the requested data from the DRF when the requested data is available at the DRF, and transmits a second request to the OAM platform to retrieve the data when the requested data is not available at the DRF, the second request including a request for data based on the first information.

[0160] In various embodiments, the processor further provides the required data to the first network function. In some embodiments, determining whether the requested data is available at the DRF includes sending a query to the NRF that identifies an address of the DRF that includes the requested data.

[0161] In some embodiments, the first information for identifying the data includes one or more fields of A) a data type field including a type of data that needs to be collected; B) a data type information field including metrics to be provided according to the data type field; C) information identifying a measurement period for the data; D) information identifying a target device for reporting the measurement data; and / or E) a data producer type identifying an OAM for retrieving the data.

[0162] In some embodiments, the data producer type field includes an address of the OAM platform. In some embodiments, the first information further indicates whether the information is required only once or is provided at regular intervals (i.e., a subscription request).

[0163] Disclosed herein is a second method for coordinating data collection at a network entity according to an embodiment of the present disclosure. The second method may be performed by a data collection coordination entity, such as DCCF 148, DCCF 210, and / or network device 700, as described above. The second method includes receiving a first request to provide data from a first network function (e.g., from a consumer NF), where the first request includes first information for identifying the requested data. The second method includes determining whether the requested data is available in a DRF, where the first information indicates that the requested data is to be retrieved from an OAM platform. The second method includes retrieving the requested data from the DRF when the requested data is available in the DRF, and sending a second request to the OAM platform to retrieve the data when the requested data is not available in the DRF, where the second request includes a request for data based on the first information.

[0164] In various embodiments, the second method includes providing the required data to the first network function. In some embodiments, determining whether the requested data is available at the DRF includes sending a query to the NRF that identifies an address of a DRF that contains the requested data.

[0165] In some embodiments, the first information for identifying the data includes one or more fields of A) a data type field including a type of data that needs to be collected; B) a data type information field including metrics to be provided according to the data type field; C) information identifying a measurement period for the data; D) information identifying a target device for reporting the measurement data; and / or E) a data producer type identifying an OAM for retrieving the data.

[0166] In some embodiments, the data producer type field includes an address of the OAM platform. In some embodiments, the first information further indicates whether the information is required only once or is provided at regular intervals (i.e., a subscription request).

[0167] The embodiments may be embodied in other specific forms. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is therefore indicated by the appended claims rather than by the foregoing description. All changes that come within the meaning and range of equivalency of the claims are to be embraced within their scope. [Explanation of symbols]

[0168] 100 Wireless communication system 105 Remote Unit 107 Applications 120 Wireless Access Network 121 Base Unit 123 Wireless Communication Links 140 Mobile Core Network 141 User Plane Functions 142 Access and Mobility Management Features 143 Session Management Function 144 Application Features 145 Network Data Analytics Function 146 Network Functions Repository Functions 147 Data repository function 148 Data Collection and Adjustment Function 149 UDM / UDR 151 Application Server 160 Operation Management and Maintenance Platform 200 Steps 205 Consumer NF 210 DCCF 215 NRF 220 OAM Entities 225 DRF 300 Steps 305 OAM / DCCF 315 Messaging 320 Messaging 330 Messaging 335 Messaging 340 Messaging 345 Messaging 400 Steps 410 Messaging 415 Messaging 420 Messaging 430 Messaging 435 Messaging 445 Messaging 500 steps 510 Messaging 520 Messaging 525 Messaging 535 Messaging 540 Messaging 545 Messaging 550 Messaging 555 Messaging 600 steps 605 Data Source 615 Messaging 620 Messaging 630 Messaging 635 Messaging 645 Messaging 650 Messaging 660 Messaging 675 Messaging 700 Network Equipment 705 Processor 710 Memory 715 Input Devices 720 output device 725 Transceiver 730 Transmitter 735 Receiver 740 Network Interface 745 Application Interface 800 ways 900 methods

Claims

1. A method of a first network entity, comprising: receiving a first request to subscribe to data from a second network entity, the data being available as historical data; sending a second request for the data to a third network entity; and providing the data to the second network entity.

2. The method of claim 1 , wherein the step of providing data includes the step of providing an identifier of the third network entity.

3. the first network entity is an Operations, Administration and Maintenance (OAM) or a Data Collection Coordination Function (DCCF), or a combination thereof; the second network entity is a Consumer Network Function (CNF); The third network entity is a Data Repository Function (DRF). The method of claim 1.

4. sending a third request to a fourth network entity, the third request including information of data available at the third network entity; The fourth network entity is a Network Function Repository Function (NFRF). The method of claim 1.

5. The information includes one or more of a data type, a time period of the data, one or more user equipment for reporting the data, or a data producer type; The method of claim 4.

6. The first request further indicates at least one characteristic of the data, the at least one characteristic including one or more of a data type, a time period of the data, one or more user equipment for reporting the data, or a data producer type.

2. The method of claim 1.

7. The second request further indicates at least one characteristic of the data, the at least one characteristic including one or more of a data type, a time period of the data, one or more user equipment for reporting the data, or a data producer type.

2. The method of claim 1.

8. A first network entity, receiving a first request to subscribe to data from a second network entity, the data being available as historical data; sending a second request for the data to a third network entity; and providing the data to the second network entity. The first network entity.

9. In order to provide the data, the first network entity is configured to provide an identifier of the third network entity. The first network entity of claim 8.

10. the first network entity is an Operations, Administration and Maintenance (OAM) or a Data Collection Coordination Function (DCCF), or a combination thereof; the second network entity is a Consumer Network Function (CNF); The third network entity is a Data Repository Function (DRF). The first network entity of claim 8.

11. further configured to send a third request to a fourth network entity; the third request includes information of data available at the third network entity; The fourth network entity is a Network Function Repository Function (NFRF). The first network entity of claim 8.

12. The information includes one or more of a data type, a duration of the data, one or more user equipment (UE) for reporting the data, or a data producer type. The first network entity according to claim 11.

13. The first request further indicates at least one characteristic of the data, the at least one characteristic including one or more of a data type, a time period of the data, one or more user equipment for reporting the data, or a data producer type. The first network entity of claim 8.

14. The second request further indicates at least one characteristic of the data, the at least one characteristic including one or more of a data type, a time period of the data, one or more user equipment for reporting the data, or a data producer type. The first network entity of claim 8.

Images