CN116998137A - Machine learning support for management services and management data analysis services - Google Patents

Machine learning support for management services and management data analysis services Download PDF

Info

Publication number
CN116998137A
CN116998137A CN202280021201.2A CN202280021201A CN116998137A CN 116998137 A CN116998137 A CN 116998137A CN 202280021201 A CN202280021201 A CN 202280021201A CN 116998137 A CN116998137 A CN 116998137A
Authority
CN
China
Prior art keywords
mda
capability
producer
report
mns
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202280021201.2A
Other languages
Chinese (zh)
Inventor
姚羿志
J·舒
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corp filed Critical Intel Corp
Priority claimed from PCT/US2022/024758 external-priority patent/WO2022221495A1/en
Publication of CN116998137A publication Critical patent/CN116998137A/en
Pending legal-status Critical Current

Links

Landscapes

  • Mobile Radio Communication Systems (AREA)

Abstract

The present disclosure describes systems, methods, and apparatus related to Machine Learning (ML) for management services (MnS). The device may obtain input data related to networks and services within the 5G system (5 GS) to provide MDA capabilities to MnS consumers within the 5 GS. The device may generate one or more MDA reports, wherein the one or more MDA reports include one or more common cells, at least one MDA type associated with MDA capabilities, and one or more MDA type specific cells. The apparatus may cause one or more MDA reports to be sent to the MnS consumer.

Description

Machine learning support for management services and management data analysis services
Cross Reference to Related Applications
The present application claims the benefit of U.S. provisional application No.63/175,482, filed on day 15 of 4 in 2021, and U.S. provisional application No.63/177,757, filed on day 21 of 4 in 2021, the entire disclosures of both provisional applications being incorporated herein by reference as if fully set forth herein.
Technical Field
The present disclosure relates generally to systems and methods for wireless communications, and more particularly to Machine Learning (ML) for management services (MnS) and Management Data Analysis Services (MDAS).
Background
Wireless devices are becoming more popular and increasingly request access to wireless channels. In the 5G system (5 GS), management Data Analysis (MDA) provides a function of processing analysis inputs related to networks and services.
Drawings
Fig. 1 is a network diagram illustrating an example network environment for Machine Learning (ML) of management services (MnS) according to one or more example embodiments of the present disclosure.
Fig. 2A-2C depict illustrative diagrams of ML for MnS in accordance with one or more example embodiments of the present disclosure.
Fig. 3-5 depict illustrative diagrams of ML for MnS in accordance with one or more example embodiments of the present disclosure.
Fig. 6 depicts an illustrative schematic of ML for MnS in accordance with one or more example embodiments of the present disclosure.
Fig. 7 shows a flowchart of a process for illustrative ML of an MnS system according to one or more example embodiments of the present disclosure.
Fig. 8 illustrates an example network architecture in accordance with one or more example embodiments of the disclosure.
Fig. 9 schematically illustrates a wireless network in accordance with one or more example embodiments of the present disclosure.
FIG. 10 illustrates components of a computing device in accordance with one or more example embodiments of the present disclosure.
Detailed Description
The following detailed description refers to the accompanying drawings. The same reference numbers may be used in different drawings to identify the same or similar elements. In the following description, for purposes of explanation and not limitation, specific details are set forth such as particular structures, architectures, interfaces, techniques, etc. in order to provide a thorough understanding of the various aspects of the various embodiments. However, it will be apparent to one skilled in the art having the benefit of this disclosure that the various aspects of the various embodiments may be practiced in other examples that depart from these specific details. In certain instances, descriptions of well-known devices, circuits, and methods are omitted so as not to obscure the description of the various embodiments with unnecessary detail. For the purposes of this document, the phrases "A or B" and "A/B" mean (A), (B) or (A and B).
Machine Learning (ML) capabilities may be used to support one or more management services (MnS), and the 3GPP TS lacks generic aspects (including scenarios, requirements, and solutions) of ML capabilities for supporting various mnss.
In particular, ML capabilities may be used to Manage Data Analysis Services (MDAS). However, there is a need to define the relationship between ML and MDAS, the requirements and solutions for implementing ML for MDAS. Thus, some embodiments of the present disclosure define methods and solutions for MnS and MDAS to implement ML.
The foregoing description is for the purpose of illustration and is not meant to be limiting. Many other examples, configurations, processes, algorithms, etc., some of which are described in more detail below, exist. Example embodiments will now be described with reference to the accompanying drawings.
Fig. 1 depicts an illustrative schematic of ML for MnS in accordance with one or more example embodiments of the present disclosure.
In one or more embodiments, ML for MnS systems may facilitate a generic aspect of ML support for MnS.
In one or more embodiments, mnS (e.g., MDAS) may be supported by ML capabilities.
In one or more embodiments, ML for MnS systems may provide ML capabilities for MnS.
In some embodiments, when ML is used for MnS, the following ML capabilities are provided to support MnS, as shown in FIG. 1.
In some embodiments, the ML capabilities may be provided to the consumer by the producer, and the ML model needs to be deployed in the ML capability producer. This document does not address how the ML model is deployed.
In one or more embodiments, in ML model training, ML capability producers train ML models (e.g., algorithms that train ML models) to be able to provide desired outputs when processing inputs for MnS. The ML capability producer may train the ML model based on the training data provided by the consumer (including training inputs and expected outputs) and provide training reports to the consumer. The ML capability producer may retrain the ML model based on consumer-provided verification feedback, including training report verification feedback and processing output verification feedback.
In one or more embodiments, in data processing, an ML capability producer processes input data using a trained ML model and generates a processing output for MnS. ML capability producers provide processing output to consumers.
In one or more embodiments, in verification, the ML capability consumer can verify training reports and/or process outputs related to MnS and provide verification feedback to the producer. The training report verification feedback may indicate whether the training meets expectations, and the processing output verification feedback may indicate whether the output is erroneous or accurate.
It is to be understood that the above description is intended to be illustrative and not restrictive.
Fig. 2A-2C depict illustrative diagrams of ML for MnS in accordance with one or more example embodiments of the present disclosure.
In one or more embodiments, ML for MnS systems may promote a relationship between ML and MnS. MnS may be supported by providing ML capability in the following possible ways:
1) MnS producers act as ML capability consumers. MnS producers act as ML-capability consumers, as shown in fig. 2A, and do not open ML-capability to MnS consumers.
2) MnS producers act as ML-capability producers and open ML-capability to MnS consumers. MnS producers act as ML capability producers, as shown in fig. 2B, and open ML capabilities to MnS consumers (e.g., mnS consumers also act as ML capability consumers).
3) MnS producers privately use ML capabilities and do not open ML capabilities to MnS consumers. MnS producers privately use ML capabilities (e.g., mnS producers act as both ML capability producers and ML capability consumers), as shown in fig. 2C, and do not open ML capabilities to MnS consumers.
In one or more embodiments, ML for MnS systems may facilitate specific aspects of ML support for MDA.
In one or more embodiments, the MDA may be supported by ML capabilities. The general aspects of ML capabilities provided for supported MnS may be applicable to MDA. Specific aspects of how ML can support MDA and possible relationships between ML and MDA are provided below.
Fig. 3-5 depict illustrative diagrams of ML for MnS in accordance with one or more example embodiments of the present disclosure.
In one or more embodiments, where the ML capability supports MDA, the generic relationship between ML and MnS may apply to MDA. This provides in particular a relationship between ML and MDAS. ML capability can support MDA by:
1) The MDAS producer acts as an ML capability consumer. The MDAS producer acts as an ML capability consumer, as shown in fig. 3, and does not open ML capability to the MDAS consumer.
2) The MDAS producer acts as an ML capability producer and opens ML capabilities to MDAS consumers. The MDAS producer acts as an ML capability producer, as shown in fig. 4, and opens up ML capabilities to MDAS consumers (e.g., MDAS consumers also act as ML capability consumers).
3) MDAS producers privately use ML capabilities and do not open ML capabilities to MDAS consumers. The MDAS producer privately uses the ML capability (e.g., the MDAS producer acts as both the ML capability producer and the ML capability consumer), as shown in fig. 5, and does not open the ML capability to the MDAS consumer.
When MDA is supported using ML capabilities, the MDAS producer may or may not open the ML capabilities to the MDAS consumer. In the case of opening up the ML capability to the MDAS consumer, the MDAS producer may train the ML model based on training data (including training inputs and expected outputs) provided by the MDAS consumer for the MDAS and provide training reports for the MDAS consumer to the MDAS consumer. The MDAS producer may retrain the ML model based on verification feedback provided by the MDAS consumer, including training report verification feedback and MDA report verification feedback.
Without opening up the ML capability to the MDAS consumer, the MDAS producer may: 1) Training (or retraining) the ML model when the MDAS producer supports ML capabilities, or 2) requesting training (or retraining) the ML model when the MDAS producer consumes ML capabilities from an external entity (e.g., a third party) without the MDAS consumer involvement, but taking into account MDA report verification feedback provided by the consumer.
In one or more embodiments, ML for MnS may provide the following requirements.
REQ-MDA_ML-FUN-1: the MDAS producer should have the ability to allow the consumer to provide ML model training data for the MDA and train the ML model according to the training data provided by the consumer.
REQ-mda_ml-FUN-2: the MDAS producer should have the ability to train (or retrain) the ML model for MDA taking into account the consumer provided MDA report verification feedback.
REQ-mda_ml-FUN-3: the MDAS producer should have the ability to provide ML model training (including retraining) reports to the consumer.
REQ-mda_ml-FUN-4: the MDAS producer should have the ability to allow the consumer to provide ML model training report verification feedback for MDA and retrain the ML model based on the training report.
It is to be understood that the above description is intended to be illustrative and not restrictive.
Fig. 6 depicts an illustrative schematic diagram for an MDA process in accordance with one or more example embodiments of the present disclosure.
In one or more embodiments, the MDA provides the ability to process analysis inputs (historical and current) related to networks and services (e.g., performance measurements, tracking/MDT/RLF/RCEF reports, quality of service (QoS) and experience (QoE) reports, alarms, configuration data, network analysis data, etc.) to generate analysis outputs, and the MDAs producer provides MDA reports (including analysis outputs) to the consumer.
MDA has the ability to analyze various problems and provide analysis outputs, respectively. The MDA may discover new problems, track status, and provide updates to existing problems. Analysis output for multiple related problems may be provided in one MDA report.
The MDA reports common cells. Details of the MDA capabilities are defined as follows, including a description for each MDA capability, MDA type, analysis inputs, and specific analysis outputs.
In addition, MDAS producers allow consumers to provide MDA report verification feedback, and can use this feedback to optimize the MDA process (e.g., ML model training in the case where ML capability is used for MDA) in order to provide a more accurate analysis output.
Table 1: the MDA reports common cells.
In one or more embodiments, common cells of the MDA report may be available and common to the MDA report. Some cells are common to MDA reports, e.g., the common cells are provided in various MDA reports. The common cells reported by MDA are defined in table 1.
In one or more embodiments, RAN coverage problems may cause the UE to cease service or cause degradation in network performance provided to the UE, such as random access, paging, RRC connection setup or handover failure, low data throughput, abnormal release of RRC connection or UE context, and QoE dissatisfaction.
There are various types of coverage problems such as weak coverage, coverage hole, pilot pollution, over-coverage, or DL and UL channel coverage mismatch, etc., which are caused by different kinds of reasons such as weak transmit power deficiency, building blockage, terrain restriction. 5G related coverage problems may exist in NR, E-UTRA or both.
To address the coverage problem, MDAS consumers need to know the details of the time and place at which the problem occurred, the type and cause of the problem. Thus, it is desirable for MDA to correlate and analyze multiple data (e.g., performance measurements, MDT reports, radio Link Failure (RLF) reports, RRC connection setup failure (RCEF) reports, UE location reports, and configuration data for geography, topography, and RANs) to use this detailed information to detect and describe problems.
To help MDAS consumers resolve coverage issues as soon as possible, MDAS may also provide recommended remedial actions (e.g., reconfigure or add some cells, beams, antennas, etc.) and descriptions of the issues.
The type of MDA used for coverage problem analysis is coverage analysis.
The analysis inputs for coverage problem analysis are provided in table 2.
Table 2: analysis inputs for coverage problem analysis.
In one or more embodiments, in addition to the common cells reported by the MDA (see clause 7.2), specific cells for the analysis output of the coverage problem analysis are provided in table 3.
Table 3: analysis output for coverage problem analysis
In one or more embodiments, the verification feedback and verification are associated with training reports related to ML capabilities. Verification feedback and verification of MDA report associations with MDA producers. MDA capability was used for coverage problem analysis.
In one or more embodiments, common cells reported by the MDA are used for one or more of the following information:
-an identifier uniquely identifying an MDA report between the MDAS producer and consumer;
-time of MDA report generation;
-an indication of the type of MDA capability for analyzing the corresponding problem;
-an identifier of a problem described in the MDA report;
the cause of the problem described in the MDA report;
-severity level of the problem described in the MDA report;
-the time at which the problem described in the MDA report starts;
-the time of the most recent update of the problem described in the MDA report;
-time of problem stop described in MDA report;
-MOI affected by the problem described in the MDA report;
-recommended actions for solving the problem described in the MDA report. The recommended actions may be creating, modifying, and/or deleting 3GPP MOI, and/or invoking one or more non-3GPP (e.g., ETSI ISG NFV) operations.
In one or more embodiments, analyzing the input includes at least one of:
-the following performance measurements:
-SS-RSRP distribution per SSB (beam) serving NR cells;
-SS-RSRP distribution per SSB (beam) of adjacent NR cells;
-RSRP distribution of neighboring E-UTRA cells for NR cells;
-power margin distribution for NR cells;
-wideband CQI distribution for NR cells;
-timing advance distribution for NR cells;
-number of UE context release requests (gcb-DU initiated);
-number of UE context release requests per SSB (gNB-DU initiated);
-number of UE context release requests (gcb-CU initiated);
-number of UE context release requests per SSB (gcb-CU initiated);
-average RSRP per SSB (beam) per TA bin;
-RSRP related measurements for the ng-eNB;
-UE power margin related measurements for ng-eNB;
-wideband CQI distribution for ng-eNB;
-average subband CQI for ng-eNB;
-UE Rx-Tx time difference correlation measurement for ng-eNB;
AOA-related measurements for ng-eNB;
-timing advance distribution for the ng-eNB;
-number of UE context release requests initiated by ng-eNodeB.
-MDA reports containing RSRP of serving cell and neighbor cell and UE location;
-an RLF report containing RSRP of the last serving cell and neighbor cells and UE location;
-an RLF report containing RSRP of the last serving cell and neighbor cells and UE location;
-UE location information provided by LCS that can be used to associate with MDT reports;
geographical information (longitude, latitude, altitude) of deployed RANs (NG-RAN and E-UTRAN).
-topographic data of RAN (NG-RAN and E-UTRAN);
contain NRM that affects the properties of the coverage (for NG-RAN and E-UTRAN).
In one or more embodiments, the MDA type specific cell contains at least one of the following information:
-an indication of the type of coverage problem;
-a geographical location area where coverage problems occur;
-an indication of a RAT where the coverage problem occurs.
In one or more embodiments, the NRM containing attributes that affect coverage (for NG-RAN and E-UTRAN) contains at least one of:
NRCellDU IOC, NRSectorCarrier IOC, BWP IOC, commonbeam forming function-IOC and Beam IOC in TS 28.541;
EUtranGenericCell IOC in TS 28.658;
SectorEquipmentFunction IOC, antennaFunction IOC in TS28.662 and TMA function IOC.
In one or more embodiments, the type of coverage problem is one of the following:
A weak coverage is provided and,
the coverage area of the blind spot is chosen,
-a pilot pollution and,
an over-coating of the material to be coated,
DlUl channel coverage mismatch.
In one or more embodiments, the geographic location area is represented by 1) coordinates (longitude and latitude) of location points of lines forming the boundary of the area and 2) the elevation of the area.
In one or more embodiments, the RAT in which the coverage problem occurs is NR, E-UTRA, or both.
It is to be understood that the above description is intended to be illustrative, and not restrictive.
Fig. 7 shows a flowchart of an illustrative process 700 for ML of an MnS system according to one or more example embodiments of the present disclosure.
At block 702, a facility managing a service (MnS) producer may obtain input data related to networks and services within a 5G system (5 GS) to provide MDA capabilities to MnS consumers within the 5 GS. MnS may be a Management Data Analysis Service (MDAS). The one or more common cells may include information common to a plurality of Management Data Analysis (MDA) reports. Verification feedback may be associated with verifying training reports related to ML capabilities. MnS producers may be able to act as Machine Learning (ML) capability producers to provide ML capabilities to ML capability consumers. MnS producers may be able to act as Machine Learning (ML) capability consumers to receive ML capabilities from ML capability producers.
At block 704, the device may generate one or more MDA reports, wherein the one or more MDA reports include one or more common cells, at least one MDA type associated with MDA capabilities, and one or more MDA type specific cells. The ML-capability producer may be configured to: ML for one or more mnss in 5GS is supported by being configured to: receiving training data from ML capability consumers; training an ML model; and establishing the ML capability in the ML capability producer based on the training data. The ml_ capability producer may also be configured to: sending a training report to the ML capability consumer; and identifying verification feedback received from the ML capability consumers. The ML-capability producer is further configured to: based on the verification feedback, the ML model is retrained.
At block 706, the apparatus may cause one or more MDA reports to be sent to the MnS consumer.
It is to be understood that the above description is intended to be illustrative, and not restrictive.
8-10 illustrate various systems, devices, and components that may implement aspects of the disclosed embodiments.
Fig. 8 illustrates an example network 800 in accordance with various embodiments. Network 800 may operate in a manner consistent with 3GPP technical specifications for LTE or 5G/NR systems. However, the example embodiments are not limited thereto, and the described embodiments may be applied to other networks that benefit from the principles described herein, such as future 3GPP systems, and the like.
The network 800 includes a UE 802, the UE 802 being any mobile or non-mobile computing device designed to communicate with a RAN 804 via an over-the-air connection. The UE 802 is communicatively coupled with the RAN 804 through a Uu interface, which may be applicable to both LTE and NR systems. Examples of UE 802 include, but are not limited to, smartphones, tablet computers, wearable computers, desktop computers, laptop computers, in-vehicle infotainment systems, in-vehicle entertainment systems, instrument clusters, head mounted display devices (HUDs), in-vehicle diagnostic devices, dashboard mobile devices, mobile data terminals, electronic engine management systems, electronic/engine control units, electronic/engine control modules, embedded systems, sensors, microcontrollers, control modules, engine management systems, networking appliances, machine type communication devices, machine-to-machine (M2M), device-to-device (D2D), machine Type Communication (MTC) devices, internet of things (IoT) devices, and the like. The network 800 may include a plurality of UEs 802 directly coupled to each other via D2D, proSe, PC5 and/or Side Link (SL) interfaces. These UEs 802 may be M2M/D2D/MTC/IoT devices and/or in-vehicle systems that communicate using physical side link channels (e.g., without limitation PSBCH, PSDCH, PSSCH, PSCCH, PSFCH, etc.). UE 802 may perform blind decoding attempts for the SL channel/link in accordance with various embodiments herein.
In some embodiments, the UE 802 may additionally communicate with the AP 806 via an over-the-air connection (OTA). The AP 806 manages WLAN connections that may be used to offload some/all network traffic from the RAN 804. The connection between the UE 802 and the AP 806 may conform to any IEEE 802.11 protocol. Further, the UE 802, RAN 804, and AP 806 may utilize cellular-WLAN aggregation/integration (e.g., LWA/LWIP). cellular-WLAN aggregation may involve the UE 802 being configured by the RAN 804 to utilize both cellular radio resources and WLAN resources.
RAN 804 includes one or more access network nodes (AN) 808. The AN 808 terminates the air interface for the UE 802 by providing access stratum protocols, including RRC, PDCP, RLC, MAC and PHY/L1 protocols. In this way, the AN 808 enables a data/voice connection between the CN 820 and the UE 802. AN 808 may be a macrocell base station or a low power base station for providing a femtocell, picocell, or other similar cell with a smaller coverage area, smaller user capacity, or higher bandwidth than a macrocell; or some combination thereof. In these implementations, the AN 808 may be referred to as a BS, gNB, RAN node, eNB, ng-eNB, nodeB, RSU, TRxP, or the like.
One example implementation is a "CU/DU split" architecture, wherein AN 808 is embodied as a gNB Central Unit (CU) communicatively coupled to one or more gNB Distributed Units (DUs), wherein each DU may be communicatively coupled to one or more Radio Units (RUs) (also referred to as RRHs, RRUs, etc.) (see, e.g., 3GPP TS 38.401v16.1.0 (2020-03)). In some implementations, one or more RUs may be separate RSUs. In some implementations, the CU/DU separation may include a ng-eNB-CU and one or more ng-eNB-DUs in place of or in addition to the gNB-CU and gNB-DU, respectively. AN 808 acting as a CU may be implemented in a separate device or as one or more software entities running on a server computer as part of, for example, a virtual network including a virtual baseband unit (BBU) or pool of BBUs, a Cloud RAN (CRAN), a Radio Equipment Controller (REC), a Radio Cloud Center (RCC), a centralized RAN (C-RAN), a virtualized RAN (vRAN), etc. (although these terms may refer to different implementation concepts). Any other type of architecture, arrangement, and/or configuration may be used.
The multiple ANs may be coupled to each other via AN X2 interface (if the RAN 804 is AN LTE RAN or AN evolved universal terrestrial radio access network (E-UTRAN) 810) or AN Xn interface (if the RAN 804 is a NG-RAN 814). The X2/Xn interface (which may be separated into control/user plane interfaces in some embodiments) may allow the AN to communicate information related to handoff, data/context transfer, mobility, load management, interference coordination, etc.
The ANs of the RAN 804 may each manage one or more cells, groups of cells, component carriers, etc. to provide the UE 802 with AN air interface for network access. The UE 802 may be simultaneously connected with multiple cells provided by the same or different ANs 808 of the RAN 804. For example, the UE 802 and the RAN 804 may use carrier aggregation to allow the UE 802 to connect with multiple component carriers, each component carrier corresponding to a Pcell or Scell. In a dual connectivity scenario, the first AN 808 may be a primary node providing AN MCG and the second AN 808 may be a secondary node providing AN SCG. The first/second AN 808 may be any combination of eNB, gNB, ng-enbs, etc.
RAN 804 may provide the air interface on licensed spectrum or unlicensed spectrum. To operate in unlicensed spectrum, a node may use LAA, eLAA, and/or feLAA mechanisms based on CA technology with PCell/Scell. Prior to accessing the unlicensed spectrum, the node may perform medium/carrier sense operations based on, for example, a Listen Before Talk (LBT) protocol.
In a V2X scenario, the UE 802 or AN 808 may be or act as a roadside unit (RSU), which may refer to any traffic infrastructure entity for V2X communications. The RSU may be implemented in or by a suitable AN or a fixed (or relatively fixed) UE. An RSU implemented in or by: for a UE, it may be referred to as a "UE-type RSU"; for enbs, it may be referred to as "eNB-type RSUs"; for gNB, it may be referred to as "gNB-type RSU"; etc. In one example, the RSU is a computing device coupled with radio frequency circuitry located at the roadside that provides connection support to the passing vehicle UE. The RSU may also include internal data storage circuitry for storing intersection map geometry, traffic statistics, media, and applications/software for listening to and controlling the traffic of traveling vehicles and pedestrians. The RSU may provide very low latency communications required for high speed events (e.g., collision avoidance, traffic alerts, etc.). Additionally or alternatively, the RSU may provide other cellular/WLAN communication services. The components of the RSU may be enclosed in a weather-proof enclosure suitable for outdoor installation, and may include a network interface controller for providing a wired connection (e.g., ethernet) to a traffic signal controller or backhaul network.
In some embodiments, the RAN 804 may be an E-UTRAN 810 with one or more enbs 812. The E-UTRAN 810 provides an LTE air interface (Uu) with the following characteristics: SCS of 15 kHz; a CP-OFDM waveform for DL and an SC-FDMA waveform for UL; turbo codes for data and TBCCs for control; etc. The LTE air interface may rely on: CSI-RS for CSI acquisition and beam management; PDSCH/PDCCH DMRS for PDSCH/PDCCH demodulation; and CRS for cell search and initial acquisition, channel quality measurements, and channel estimation for coherent demodulation/detection at the UE. The LTE air interface may operate on the sub-6GHz band.
In some embodiments, RAN 804 may be a Next Generation (NG) -RAN 814 with one or more gnbs 816 or one or more NG-enbs 818. The gNB 816 connects with the 5G enabled UE 802 using a 5G NR interface. The gNB 816 is connected to the 5GC 840 through an NG interface, which includes an N2 interface or an N3 interface. The NG-eNB 818 is also connected to the 5gc 840 over the NG interface, but may be connected to the UE 802 via the Uu interface. The gNB 816 and the ng-eNB 818 may be connected to each other via an Xn interface.
In some embodiments, the NG interface may be split into two parts: a NG user plane (NG-U) interface that carries traffic data (e.g., an N3 interface) between nodes of NG-RAN 814 and UPF 848; and a NG control plane (NG-C) interface, which is a signaling interface (e.g., an N2 interface) between the node of NG-RAN 814 and AMF 844.
NG-RAN 814 may provide a 5G-NR air interface (which may also be referred to as a Uu interface) with the following characteristics: a variable SCS; CP-OFDM for DL, CP-OFDM for UL, and DFT-s-OFDM; polarization codes for control, repetition codes, simplex codes, and Reed-Muller codes, and LDPC codes for data. Similar to the LTE air interface, the 5G-NR air interface may rely on CSI-RS, PDSCH/PDCCH DMRS. The 5G-NR air interface may not use CRS but may use PBCH DMRS for PBCH demodulation; PTRS for phase tracking for PDSCH; and tracking reference signals for time tracking. The 5G-NR air interface may operate on an FR1 band including a sub-6GHz band or an FR2 band including a frequency band from 24.25GHz to 52.6 GHz. The 5G-NR air interface may comprise an SSB, which is an area of the downlink resource grid comprising PSS/SSS/PBCH.
The 5G-NR air interface may utilize BWP for various purposes. For example, BWP may be used for dynamic adaptation of SCS. For example, the UE 802 may be configured with multiple BWP, where each BWP configuration has a different SCS. When a BWP change is indicated to the UE 802, the SCS of the transmission also changes. Another example of use of BWP relates to power saving. In particular, the UE 802 may be configured with multiple BWPs having different amounts of frequency resources (e.g., PRBs) to support data transmission in different traffic load scenarios. BWP containing a smaller number of PRBs may be used for data transmission with small traffic load while allowing power saving at the UE 802 and in some cases at the gNB 816. BWP containing a larger number of PRBs may be used for scenarios with higher traffic load.
The RAN 804 is communicatively coupled to a CN 820, the CN 820 including network elements and/or Network Functions (NF) for providing various functions to support data and telecommunications services for clients/subscribers (e.g., UE 802). The components of the CN 820 may be implemented in one physical node or in a separate physical node. In some embodiments, NFV may be used to virtualize any or all of the functionality provided by the network elements of CN 820 onto physical computing/storage resources in servers, switches, etc. The logical instantiation of the CN 820 may be referred to as a network slice, while the logical instantiation of a portion of the CN 820 may be referred to as a network sub-slice.
CN 820 may be an LTE CN 822 (also referred to as Evolved Packet Core (EPC) 822). EPC 822 may include MME 824, SGW 826, SGSN 828, HSS 830, PGW 832, and PCRF 834, which are coupled to each other as shown by interfaces (or "reference points"). NF in EPC 822 is briefly described as follows.
The MME 824 implements mobility management functions to track the current location of the UE 802 to facilitate paging, bearer activation/deactivation, handover, gateway selection, authentication, and the like.
SGW 826 terminates the S1 interface towards RAN 810 and routes data packets between RAN 810 and EPC 822. SGW 826 may be a local mobility anchor for inter-RAN node handover and may also provide an anchor for inter-3 GPP mobility. Other responsibilities may include lawful interception, billing and some policy enforcement.
SGSN828 tracks the location of UE 802 and performs security functions and access control. SGSN828 also performs EPC inter-node signaling for mobility between different RAT networks; MME 824 specified PDN and S-GW selection; MME 824 selection for handover; etc. The S3 reference point between MME 824 and SGSN828 may enable user and bearer information exchange for inter-3 GPP network mobility in the idle/active state.
HSS 830 includes a database for network users (including subscription related information) to support the handling of communication sessions by network entities. HSS 830 may provide support for routing/roaming, authentication, authorization, naming/addressing resolution, location dependencies, and so on. The S6a reference point between HSS 830 and MME 824 may enable the transfer of subscription and authentication data for authenticating/authorizing a user to access EPC 820.
PGW 832 may terminate the SGi interface towards a Data Network (DN) 836, which may include an application (app)/content server 838. PGW 832 routes data packets between EPC 822 and data network 836. PGW 832 is coupled to SGW 826 by S5 reference point to facilitate user plane tunneling and tunnel management. PGW 832 may also include nodes (e.g., PCEFs) for policy enforcement and charging data collection. Further, the SGi reference point may communicatively couple the PGW 832 with the same or different data network 836. PGW 832 may be communicatively coupled with PCRF 834 via a Gx reference point.
PCRF 834 is a policy and charging control element of EPC 822. PCRF 834 is communicatively coupled to app/content server 838 to determine appropriate QoS and charging parameters for the service flows. PCRF 832 also assigns the associated rules to the PCEF with the appropriate TFTs and QCIs (via Gx reference points).
CN 820 may be 5gc 840,5gc 840 including AUSF 842, AMF 844, SMF 846, UPF 848, NSSF 850, NEF 852, NRF 854, PCF 856, UDM 858, and AF 860, coupled to each other as shown by various interfaces (or "reference points"). NF in 5gc 840 is briefly described as follows.
The AUSF 842 stores data for authentication of the UE 802 and processes authentication related functions. The AUSF 842 may facilitate a common authentication framework for various access types.
AMF 844 allows other functions of 5GC 840 to communicate with UE 802 and RAN 804 and subscribe to notifications about mobility events for UE 802. The AMF 844 is responsible for registration management (e.g., for registering the UE 802), connection management, reachability management, mobility management, lawful interception of AMF related events, and access authentication and authorization. The AMF 844 provides transport for SM messages between the UE 802 and the SMF 846 and acts as a transparent proxy for routing SM messages. AMF 844 also provides transmission for SMS messages between UE 802 and SMSF. The AMF 844 interacts with the AUSF 842 and the UE 802 to perform various security anchoring and context management functions. Furthermore, the AMF 844 is an end point of the RAN-CP interface, which includes an N2 reference point between the RAN 804 and the AMF 844. AMF 844 is also the termination point for NAS (N1) signaling and performs NAS ciphering and integrity protection.
AMF 844 also supports NAS signaling with UE 802 over the N3IWF interface. The N3IWF provides access to untrusted entities. The N3IWF may be AN endpoint (for the control plane) for the N2 interface between the (R) AN 804 and the AMF 844, and may be AN endpoint (for the user plane) for the N3 reference point between the (R) AN 814 and the UPF 848. Thus, AMF 844 handles N2 signaling from SMF 846 and AMF 844 for PDU sessions and QoS, encapsulates/decapsulates packets for IPSec and N3 tunnels, marks N3 user plane packets in the uplink, and enforces QoS corresponding to N3 packet marks taking into account QoS requirements associated with such marks received over N2. The N3IWF may also relay UL and DL control plane NAS signaling between the UE 802 and the AMF 844 and uplink and downlink user plane packets between the UE 802 and the UPF 848 via the N1 reference point between the UE 802 and the AMF 844. The N3IWF also provides a mechanism for establishing an IPsec tunnel with the UE 802. AMF 844 may present an interface based on Namf services, and may be an end point for an N14 reference point between two AMFs 844 and an N17 reference point between AMFs 844 and 5G-EIR (not shown in FIG. 8).
SMF 846 is responsible for SM (e.g., session establishment, tunnel management between UPF 848 and AN 808); UE IP address allocation and management (including optional authorization); selection and control of the UP function; configuring traffic steering at UPF 848 to route traffic to the correct destination; terminating the interface towards the policy control function; control policy enforcement, charging, and a portion of QoS; lawful interception (for SM events and interfaces to LI systems); terminating the SM portion of the NAS message; downlink data notification; AN specific SM information sent to AN 808 via AN AMF 844 over N2 is initiated; and determining the SSC mode of the session. SM refers to the management of PDU sessions, and PDU session or "session" refers to a PDU connection service that provides or enables the exchange of PDUs between UE 802 and DN 836.
UPF 848 serves as an anchor point for intra-RAT and inter-RAT mobility, an external PDU session point for interconnection to data network 836, and a branching point to support multi-homing PDU sessions. The UPF 848 also performs packet routing and forwarding, packet inspection, user plane part of policy rules enforcement, lawful interception of packets (UP collection), traffic usage reporting, qoS processing of the user plane (e.g., packet filtering, gating, UL/DL rate enforcement), uplink traffic authentication (e.g., SDF to QoS flow mapping), transport layer packet tagging in the uplink and downlink, and downlink packet buffering and downlink data notification triggering. The UPF 848 may include an uplink classifier to support routing of traffic flows to the data network.
NSSF 850 selects a set of network slice instances to serve UE 802. NSSF 850 also determines the allowed NSSAI and the mapping to subscribed S-NSSAI (if needed). NSSF 850 also determines a set of AMFs or list of candidate AMFs 844 to use for serving UE 802 based on the appropriate configuration and possibly by querying NRF 854. The selection of a set of network slice instances for the UE 802 may be triggered by the AMF 844 registered by the UE 802 through interaction with the NSSF 850, which may result in a change in the AMF 844. NSSF 850 may interact with AMF 844 via the N22 reference point; and may communicate with another NSSF in the visited network via an N31 reference point (not shown).
The NEF 852 securely opens services and capabilities provided by the 3GPP NF for third parties, internal openness/reopening, AF 860, edge computing or fog computing systems (e.g., edge computing nodes), etc. In such embodiments, NEF 852 may authenticate, authorize or restrict AF. NEF 852 can also translate information exchanged with AF 860 as well as with internal network functions. For example, the NEF 852 may translate between an AF service identifier and internal 5GC information. The NEF 852 can also receive information from other NF based on the ability of the other NF to open. This information may be stored as structured data at NEF 852 or at data store NF using a standardized interface. The stored information may then be re-opened by the NEF 852 to other NF and AF, or used for other purposes (e.g., analysis).
NRF 854 supports service discovery functionality, receives NF discovery requests from NF instances, and provides information of discovered NF instances to requesting NF instances. NRF 854 also maintains information of available NF instances and services supported by it. NRF 854 also supports a service discovery function, where NRF 854 receives NF discovery requests from NF instances or SCPs (not shown) and provides information of the discovered NF instances to NF instances or SCPs.
PCF 856 provides policy rules to control plane functions to implement them and may also support a unified policy framework to manage network behavior. PCF 856 may also implement a front end to access subscription information related to policy decisions in the UDR of UDM 858. In addition to communicating with functions through reference points as shown, PCF 856 also presents an interface based on the Npcf service.
The UDM 858 processes subscription related information to support the processing of communication sessions by network entities and stores subscription data for the UE 802. For example, subscription data may be communicated via an N8 reference point between UDM 858 and AMF 844. UDM 858 may include two parts: application front-end and UDR. The UDR may store subscription data and policy data for UDM 858 and PCF 856, and/or structured data for open and application data of NEF 852 (including PFD for application detection, application request information for multiple UEs 802). The Nudr service-based interface may be exposed by UDR 221 to allow UDM 858, PCF 856, and NEF 852 to access a particular set of stored data, as well as to read, update (e.g., add, modify), delete, and subscribe to notifications of related data changes in the UDR. The UDM may include a UDM-FE that is responsible for handling credentials, location management, subscription management, etc. Several different front ends may serve the same user in different transactions. The UDM-FE accesses subscription information stored in the UDR and performs authentication credential processing, user identification processing, access authorization, registration/mobility management, and subscription management. In addition to communicating with other NFs through reference points as shown, the UDM 858 may also expose a Nudm service-based interface.
AF 860 may provide application impact on traffic routing, provide access to NEF 852, and interact with policy framework for policy control. AF 860 may affect UPF 848 (re) selection and traffic routing. Based on the operator deployment, the network operator may allow the AF 860 to interact directly with the associated NF when the AF 860 is considered a trusted entity. In addition, AF 860 may be used for edge calculation implementations.
The 5gc 840 may enable edge computation by selecting an operator/third party service to be geographically close to the point where the UE 802 attaches to the network. This may reduce latency and load on the network. In an edge computing implementation, the 5gc 840 may select a UPF 848 near the UE 802 and perform traffic steering from the UPF 848 to the DN 836 via the N6 interface. This may be based on UE subscription data, UE location and information provided by AF 860, which allows AF 860 to influence UPF (re) selection and traffic routing.
The Data Network (DN) 836 can represent various network operator services, internet access, or third party services that can be provided by one or more servers including, for example, applications (apps)/content servers 838. DN 836 can be an operator external public network, a private PDN network, or an operator internal packet data network (e.g., for providing IMS services). In this embodiment, the app server 838 may be coupled to the IMS via an S-CSCF or an I-CSCF. In some implementations, DN 836 can represent one or more Local Area DNs (LADNs), which are DN 836 (or DN names (DNNs)) that can be accessed by UEs 802 in one or more particular areas. Outside these particular areas, the UE 802 cannot access the LADN/DN 836.
Additionally or alternatively, DN 836 can be an edge DN 836, which is a (local) data network supporting architecture for implementing edge applications. In these embodiments, app server 838 may represent a physical hardware system/device that provides app server functionality, and/or application software residing in a cloud that performs server functionality or at an edge computing node. In some embodiments, the app/content server 838 provides an edge hosting environment that provides the support required for the execution of the edge application server.
In some embodiments, the 5GS may use one or more edge computing nodes to provide interfacing and offloading processing of wireless communication traffic. In these embodiments, the edge computing nodes may be included in, or co-sited with, one or more RANs 810, 814. For example, the edge compute node may provide a connection between RAN 814 and UPF 848 in 5gc 840. The edge computing node may use one or more NFV instances instantiated on the virtualization infrastructure within the edge computing node to handle wireless connections to and from RAN 814 and UPF 848.
The interface of the 5gc 840 includes a reference point and a service-based interface. The reference points include: n1 (between UE 802 and AMF 844), N2 (between RAN 814 and AMF 844), N3 (between RAN 814 and UPF 848), N4 (between SMF 846 and UPF 848), N5 (between PCF 856 and AF 860), N6 (between UPF 848 and DN 836), N7 (between SMF 846 and PCF 856), N8 (between UDM 858 and AMF 844), N9 (between two UPF 848), N10 (between UDM 858 and SMF 846), N11 (between AMF 844 and SMF 846), N12 (between AUSF 842 and AMF 844), N13 (between AUSF 842 and UDM 858), N14 (between two AMFs 844; not shown), N15 (between PCF 856 and AMF 844 in the case of a non-roaming scenario, or between PCF 856 and AMF 844 in the visited network in the case of a roaming scenario), N16 (between two SMFs 846; 846), and N22 (not shown) and nsf 844. Other reference point representations not shown in fig. 8 may also be used. The service-based representation of fig. 8 represents NFs within the control plane that enable other authorized NFs to access their services. The service-based interface (SBI) includes: namf (SBI shown by AMF 844), nsmf (SBI shown by SMF 846), nnef (SBI shown by NEF 852), npcf (SBI shown by PCF 856), nudm (SBI shown by UDM 858), naf (SBI shown by AF 860), nnrf (SBI shown by NRF 854), nnssf (SBI shown by NSSF 850), nausf (SBI shown by AUSF 842). Other service-based interfaces not shown in fig. 8 (e.g., nudr, N5g-eir, and Nudsf) may also be used. In some embodiments, NEF 852 may provide an interface to edge computing node 836x that may be used to handle wireless connections with RAN 814.
In some implementations, the system 800 may include an SMSF that is responsible for SMS subscription checking and authentication, and relaying SM messages from the UE 802 to/from other entities (e.g., SMS-GMSC/IWMSC/SMS router). SMS may also interact with AMF 842 and UDM 858 for notification procedures that UE 802 is available for SMS transmission (e.g., setting a UE unreachable flag, and notifying UDM 858 when UE 802 is available for SMS).
The 5GS may also include an SCP (or individual instances of an SCP) that supports: indirect communication (see e.g. 3gpp ts23.501 section 7.1.1); delegated discovery (see e.g. 3gpp TS23.501 section 7.1.1); message forwarding and routing to destination NF/NF services, communication security (e.g., authorizing NF service consumers to access NF service producer APIs) (see, e.g., 3gpp TS 33.501), load balancing, monitoring, overload control, etc.; and a discovery and selection function for UDM, AUSF, UDR, PCF, wherein subscription data stored in the UDR is accessed based on the SUPI, sui or GPSI of the UE (see e.g. 3gpp ts23.501 section 6.3). The load balancing, monitoring, overload control functions provided by the SCP may be implementation specific. The SCP may be deployed in a distributed manner. There may be more than one SCP in the communication path between the various NF services. SCPs, while not NF instances, may also be distributed, redundant, and scalable for deployment.
Fig. 9 schematically illustrates a wireless network 900 according to various embodiments. The wireless network 900 may include a UE 902 in wireless communication with AN 904. The UE 902 and the AN 904 may be similar to, and substantially interchangeable with, similar naming components described with respect to fig. 8.
The UE 902 may be communicatively coupled with the AN 904 via a connection 906. Connection 906 is shown as implementing a communicatively coupled air interface and may conform to a cellular communication protocol, such as the LTE protocol or the 5G NR protocol operating at mmWave or sub-6GHz frequencies.
The UE 902 may include a host platform 908 coupled to a modem platform 910. Host platform 908 may include application processing circuitry 912, and application processing circuitry 912 may be coupled with protocol processing circuitry 914 of modem platform 910. The application processing circuitry 912 may run various applications for outgoing/incoming application data for the UE 902. The application processing circuitry 912 may also implement one or more layer operations to send and receive application data to and from the data network. These layer operations may include transport (e.g., UDP) and internet (e.g., IP) operations.
Protocol processing circuit 914 may implement one or more layers of operations to facilitate sending or receiving data over connection 906. Layer operations implemented by the protocol processing circuit 914 may include, for example, MAC, RLC, PDCP, RRC and NAS operations.
Modem platform 910 may also include digital baseband circuitry 916, and digital baseband circuitry 916 may implement one or more layer operations, which are "lower" layer operations in the network protocol stack performed by protocol processing circuitry 914. These operations may include, for example, PHY operations, including one or more of the following: HARQ-Acknowledgement (ACK) functions, scrambling/descrambling, encoding/decoding, layer mapping/demapping, modulation symbol mapping, received symbol/bit metric determination, multi-antenna port precoding/decoding (which may include one or more of space-time, space-frequency, or space coding), reference signal generation/detection, preamble sequence generation and/or decoding, synchronization sequence generation/detection, control channel signal blind decoding, and other related functions.
Modem platform 910 may also include transmit circuitry 918, receive circuitry 920, RF circuitry 922, and an RF front end (RFFE) 924, which may include or be connected to one or more antenna panels 926. Briefly, transmit circuit 918 may include a digital-to-analog converter, a mixer, an Intermediate Frequency (IF) component, and the like; the receive circuitry 920 may include analog-to-digital converters, mixers, IF components, etc.; RF circuitry 922 may include low noise amplifiers, power tracking components, and the like; RFFE 924 may include filters (e.g., surface/bulk acoustic wave filters), switches, antenna tuners, beam forming components (e.g., phased array antenna components), and so forth. The selection and arrangement of the components of the transmit circuitry 918, receive circuitry 920, RF circuitry 922, RFFE 924, and antenna panel 926 (commonly referred to as "transmit/receive components") may be specific to the specifics of the particular implementation, such as whether the communication is TDM or FDM, at mmWave or sub-6GHz frequencies, etc. In some embodiments, the transmit/receive components may be arranged in multiple parallel transmit/receive chains, may be provided in the same or different chips/modules, etc.
In some embodiments, the protocol processing circuit 914 may include one or more instances of control circuitry (not shown) for providing control functions for the transmit/receive components.
UE 902 reception may be established by and through antenna panel 926, RFFE 924, RF circuitry 922, receive circuitry 920, digital baseband circuitry 916, and protocol processing circuitry 914. In some embodiments, the antenna panel 926 may receive transmissions from the AN 904 through receive beamformed signals received by multiple antennas/antenna elements of one or more antenna panels 926.
UE 902 transmission may be established by and through protocol processing circuitry 914, digital baseband circuitry 916, transmit circuitry 918, RF circuitry 922, RFFE 924, and antenna panel 926. In some embodiments, the transmit component of the UE 904 may apply spatial filtering to the data to be transmitted to form transmit beams that are transmitted by the antenna elements of the antenna panel 926.
Similar to the UE 902, the an 904 may include a host platform 928 coupled to a modem platform 930. Host platform 928 may include application processing circuitry 932 coupled to protocol processing circuitry 934 of modem platform 930. The modem platform may also include digital baseband circuitry 936, transmit circuitry 938, receive circuitry 940, RF circuitry 942, RFFE circuitry 944, and an antenna panel 946. The components of the AN 904 may be similar to, and substantially interchangeable with, similarly named components of the UE 902. In addition to performing data transmission/reception as described above, the components of the AN 908 may perform various logic functions including, for example, RNC functions (e.g., radio bearer management, uplink and downlink dynamic radio resource management, and data packet scheduling).
Fig. 10 illustrates components of a computing device 1000 according to some example embodiments, the computing device 1000 being capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any one or more of the methods discussed herein. In particular, FIG. 10 shows a diagrammatic representation of a hardware resource 1000, the hardware resource 1000 including one or more processors (or processor cores) 1010, one or more memory/storage devices 1020, and one or more communication resources 1030, each of which may be communicatively coupled via a bus 1040 or other interface circuitry. For embodiments that utilize node virtualization (e.g., NFV), the hypervisor 1002 may be executed to provide an execution environment for one or more network slices/sub-slices to utilize the hardware resources 1000.
The processor 1010 includes, for example, a processor 1012 and a processor 1014. The processor 1010 includes the following circuitry, such as, but not limited to: one or more processor cores and one or more of cache memory, low dropout voltage regulator (LDO), interrupt controller, serial interface (e.g., SPI, I2C, or universal programmable serial interface circuit), real Time Clock (RTC), timer counter (including interval timer and watchdog timer), universal I/O, memory card controller (e.g., secure digital/multimedia card (SD/MMC) or similar interface), mobile Industry Processor Interface (MIPI) interface, and Joint Test Access Group (JTAG) test access port. The processor 1010 may be, for example, a Central Processing Unit (CPU), a Reduced Instruction Set Computing (RISC) processor, an Acorn RISC Machine (ARM) processor, a Complex Instruction Set Computing (CISC) processor, a Graphics Processing Unit (GPU), one or more Digital Signal Processors (DSPs) (e.g., baseband processors), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), a Radio Frequency Integrated Circuit (RFIC), one or more microprocessors or controllers, another processor (including those discussed herein), or any suitable combination thereof. In some implementations, the processor circuit 1010 may include one or more hardware accelerators, which may be microprocessors, programmable processing devices (e.g., FPGAs, complex Programmable Logic Devices (CPLDs), etc.), or the like.
Memory/storage 1020 may include main memory, disk memory, or any suitable combination thereof. Memory/storage 1020 may include, but is not limited to, any type of volatile, nonvolatile, or semi-volatile memory such as Random Access Memory (RAM), dynamic RAM (DRAM), static RAM (SRAM), synchronous DRAM (SDRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, solid state memory, phase change RAMPRAM), resistive memory (e.g., magnetoresistive Random Access Memory) (MRAM), etc., and may include data fromAndthree-dimensional (3D) cross-point (XPOINT) memory. Memory/storage 1020 may also include a persistent storage device, which may be any type of temporary and/or permanent storage, including, but not limited to, non-volatile memory, optical, magnetic, and/or solid-state mass storage, and the like.
The communication resources 1030 may include interconnection or network interface controllers, components, or other suitable devices to communicate with one or more peripheral devices 1004 or one or more databases 1006 or other network elements via the network 1008. The communication resources 1030 may include, for example, wired communication components (e.g., for Ethernet via USB, ethernet, GRE tunnel multiprotocol label switching Ethernet (MPLS), USB Ethernet Controller Area Network (CAN), local Interconnect Network (LIN), deviceNet, controlNet, data Highway+, PROFIBUS or PROFINET, etc.), cellular communication component, NFC component, (or->Low power consumption) component->Components and other communication components. A network connection may be provided to/from computing device 1000 via communications resources 1030 using a physical connection (which may be electrical (e.g., a "copper interconnect") or optical). Physical connections also include suitable input connectors (e.g., ports, sockets, receptacles, etc.) and output connectors (e.g., plugs, pins, etc.). The communication resources 1030 may include one or more special purpose processors and/or FPGAs to use one or more of the aforementioned network interfacesThe protocol communicates.
The instructions 1050 may include software, programs, applications, applets, apps, or other executable code for causing at least any one of the processors 1010 to perform any one or more of the methods discussed herein. The instructions 1050 may reside, completely or partially, within at least one of the processor 1010 (e.g., within a cache memory of the processor), the memory/storage 1020, or any suitable combination thereof. Further, any portion of instructions 1050 may be transferred from any combination of peripherals 1004 or databases 1006 to hardware resource 1000. Accordingly, the memory of the processor 1010, the memory/storage device 1020, the peripherals 1004, and the database 1006 are examples of computer readable and machine readable media.
For one or more embodiments, at least one component set forth in one or more of the preceding figures may be configured to perform one or more operations, techniques, procedures, and/or methods set forth in the following examples section. For example, the baseband circuitry described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more examples set forth below. As another example, circuitry associated with a UE, base station, network element, etc., described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth in the examples section below.
Additional examples of the presently described embodiments include the following non-limiting implementations. Each of the following non-limiting examples may exist independently or may be combined in any permutation or combination with any one or more of the other examples provided below or throughout this disclosure.
For one or more embodiments, at least one component set forth in one or more of the preceding figures may be configured to perform one or more operations, techniques, procedures, and/or methods set forth in the following examples section. For example, the baseband circuitry described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more examples set forth below. As another example, circuitry associated with a UE, base station, network element, etc., described above in connection with one or more of the preceding figures, may be configured to operate in accordance with one or more examples set forth below.
The following examples pertain to further embodiments.
Example 1 may include an apparatus for managing a service (MnS) producer, comprising: obtaining input data related to networks and services within a 5G system (5 GS) to provide MDA capabilities to MnS consumers within the 5 GS; generating one or more MDA reports, wherein the one or more MDA reports include one or more common cells, at least one MDA type associated with the MDA capability, and one or more MDA type specific cells; and causing the one or more MDA reports to be sent to the MnS consumer.
Example 2 may include the apparatus of example 1 and/or some other examples herein, wherein the MnS producer may be capable of acting as a Machine Learning (ML) capability producer to provide ML capabilities to ML capability consumers.
Example 3 may include the apparatus of example 1 and/or some other examples herein, wherein the MnS producer may be capable of acting as a Machine Learning (ML) capability consumer to receive ML capabilities from the ML capability producer.
Example 4 may include the apparatus of example 3 and/or some other examples herein, wherein the ML capability producer may be configured to: ML for one or more mnss in the 5GS is supported by being configured to: receiving training data from the ML capability consumers; training an ML model; and establishing ML capabilities in the ML-capability producer based on the training data.
Example 5 may include the apparatus of example 4 and/or some other examples herein, wherein the ml_ capability producer may be further configured to: sending a training report to the ML capability consumer; and identifying verification feedback received from the ML-capable consumer.
Example 6 may include the apparatus of example 5 and/or some other examples herein, wherein the ml_ capability producer may be further configured to: retraining the ML model based on the verification feedback.
Example 7 may include the apparatus of example 1 and/or some other examples herein, wherein the MnS may be a Management Data Analysis Service (MDAS).
Example 8 may include the apparatus of example 1 and/or some other examples herein, wherein the one or more common cells include information that may be common to a plurality of Management Data Analysis (MDA) reports.
Example 9 may include the apparatus of example 5 and/or some other examples herein, wherein the verification feedback may be associated with verifying training reports related to ML capabilities.
Example 10 may include the apparatus of example 8 and/or some other examples herein, wherein the one or more common cells are for at least one or more of: an identifier of an MDA report uniquely identifying between an MDA producer and an MDA consumer, a time of generating the MDA report, an indication type of MDA capability for analyzing a corresponding problem, an identifier of a problem described in the MDA report, a cause of the problem described in the MDA report, a severity level of the problem described in the MDA report, a time of starting the problem described in the MDA report, a time of latest update of the problem described in the MDA report, a time of stopping the problem described in the MDA report, a Management Object Instance (MOI) affected by the problem described in the MDA report, or a recommended action for solving the problem described in the MDA report.
Example 11 may include a computer-readable storage medium comprising instructions that, when executed by a processing circuit, cause the processing circuit to: obtaining, by a management service (MnS) producer, input data related to networks and services within a 5G system (5 GS) to provide MDA capabilities to MnS consumers within the 5 GS; generating one or more MDA reports, wherein the one or more MDA reports include one or more common cells, at least one MDA type associated with the MDA capability, and one or more MDA type specific cells; and causing the one or more MDA reports to be sent to the MnS consumer.
Example 12 may include the computer-readable storage medium of example 11 and/or some other examples herein, wherein the MnS producer may be capable of acting as a Machine Learning (ML) capability producer to provide ML capabilities to ML capability consumers.
Example 13 may include the computer-readable storage medium of example 11 and/or some other examples herein, wherein the MnS producer may be capable of acting as a Machine Learning (ML) capability consumer to receive ML capabilities from the ML capability producer.
Example 14 may include the computer-readable storage medium of example 13 and/or some other examples herein, wherein the ml_ capability producer may be configured to: ML for one or more mnss in the 5GS is supported by being configured to: receiving training data from the ML capability consumers; training an ML model; and establishing ML capabilities in the ML-capability producer based on the training data.
Example 15 may include the computer-readable storage medium of example 14 and/or some other examples herein, wherein the ml_ capability producer may be further configured to: sending a training report to the ML capability consumer; and identifying verification feedback received from the ML-capable consumer.
Example 16 may include the computer-readable storage medium of example 15 and/or some other examples herein, wherein the ml_ capability producer may be further configured to: retraining the ML model based on the verification feedback.
Example 17 may include the computer-readable storage medium of example 11 and/or some other examples herein, wherein the MnS is a Management Data Analysis Service (MDAS).
Example 18 may include the computer-readable storage medium of example 11 and/or some other examples herein, wherein the one or more common cells include information that may be common to a plurality of Management Data Analysis (MDA) reports.
Example 19 may include the computer-readable storage medium of example 15 and/or some other examples herein, wherein the verification feedback may be associated with verifying training reports related to ML capabilities.
Example 20 may include the computer-readable storage medium of example 18 and/or some other examples herein, wherein the one or more common cells are for at least one or more of: an identifier of an MDA report uniquely identifying between an MDA producer and an MDA consumer, a time of generating the MDA report, an indication type of MDA capability for analyzing a corresponding problem, an identifier of a problem described in the MDA report, a cause of the problem described in the MDA report, a severity level of the problem described in the MDA report, a time of starting the problem described in the MDA report, a time of latest update of the problem described in the MDA report, a time of stopping the problem described in the MDA report, a Management Object Instance (MOI) affected by the problem described in the MDA report, or a recommended action for solving the problem described in the MDA report.
Example 21 may include the computer-readable storage medium of example 20 and/or some other examples herein, wherein the recommended action may be to create, modify, and/or delete a 3GPP MOI, and/or invoke one or more non-3GPP operations.
Example 22 may include a method comprising: obtaining, by one or more processors of a management service (MnS) producer, input data related to networks and services within a 5G system (5 GS) to provide MDA capabilities to MnS consumers within the 5 GS; generating one or more MDA reports, wherein the one or more MDA reports include one or more common cells, at least one MDA type associated with the MDA capability, and one or more MDA type specific cells; and causing the one or more MDA reports to be sent to the MnS consumer.
Example 23 may include the method of example 22 and/or some other examples herein, wherein the MnS producer may be capable of acting as a Machine Learning (ML) capability producer to provide ML capabilities to ML capability consumers.
Example 24 may include the method of example 22 and/or some other examples herein, wherein the MnS producer may be capable of acting as a Machine Learning (ML) capability consumer to receive ML capabilities from the ML capability producer.
Example 25 may include the method of example 24 and/or some other examples herein, wherein the ml_ capability producer may be configured to: ML for one or more mnss in the 5GS is supported by being configured to: receiving training data from the ML capability consumers; training an ML model; and establishing ML capabilities in the ML-capability producer based on the training data.
Example 26 may include the method of example 25 and/or some other examples herein, wherein the ml_ capability producer may be further configured to: sending a training report to the ML capability consumer; and identifying verification feedback received from the ML-capable consumer.
Example 27 may include the method of example 26 and/or some other examples herein, wherein the ml_ capability producer may be further configured to: retraining the ML model based on the verification feedback.
Example 28 may include the method of example 22 and/or some other example herein, wherein the MnS is a Management Data Analysis Service (MDAS).
Example 29 may include the method of example 22 and/or some other examples herein, wherein the one or more common cells include information that may be common to a plurality of Management Data Analysis (MDA) reports.
Example 30 may include the method of example 26 and/or some other examples herein, wherein the verification feedback may be associated with verifying training reports related to ML capabilities.
Example 31 may include the method of example 29 and/or some other examples herein, wherein the one or more common cells are for at least one or more of: an identifier of an MDA report uniquely identifying between an MDA producer and an MDA consumer, a time of generating the MDA report, an indication type of MDA capability for analyzing a corresponding problem, an identifier of a problem described in the MDA report, a cause of the problem described in the MDA report, a severity level of the problem described in the MDA report, a time of starting the problem described in the MDA report, a time of latest update of the problem described in the MDA report, a time of stopping the problem described in the MDA report, a Management Object Instance (MOI) affected by the problem described in the MDA report, or a recommended action for solving the problem described in the MDA report.
Example 32 may include the method of example 31 and/or some other examples herein, wherein the recommended action may be to create, modify, and/or delete a 3GPP MOI, and/or invoke one or more non-3GPP operations.
Example 33 may include an apparatus comprising means for performing any of the methods of examples 1-32.
Example 34 may include a network node, comprising: a communication interface; and processing circuitry coupled thereto configured to perform the methods of examples 1-32.
Example 35 may include an apparatus comprising means for performing one or more elements of the methods described in or associated with any of examples 1-32, or any other method or process described herein.
Example 36 may include one or more non-transitory computer-readable media comprising instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform one or more elements of the methods described in or associated with any of examples 1-32, or any other method or process described herein.
Example 37 may include an apparatus comprising logic, modules, or circuitry to perform one or more elements of the methods described in or associated with any of examples 1-32, or any other method or process described herein.
Example 38 may include a method, technique, or process as described in or associated with any of examples 1-32, or portions thereof.
Example 39 may include an apparatus comprising: one or more processors; and one or more computer-readable media comprising instructions that, when executed by one or more processors, cause the one or more processors to perform the methods, techniques, or processes described in or related to any one of examples 1-32 or portions thereof.
Example 40 may include signals as described in or associated with any of examples 1-32 or portions thereof.
Example 41 may include a datagram, packet, frame, segment, protocol Data Unit (PDU), or message as described in or associated with any one of examples 1-32, or portions thereof, or otherwise described in this disclosure.
Example 42 may include a signal encoded with data as described in or associated with any of examples 1-32, or portions thereof, or otherwise described in this disclosure.
Example 43 may include a signal encoded with a datagram, packet, frame, segment, protocol Data Unit (PDU), or message as described in or associated with any one of examples 1-32, or portions thereof, or otherwise described in this disclosure.
Example 44 may include an electromagnetic signal carrying computer-readable instructions, wherein execution of the computer-readable instructions by one or more processors causes the one or more processors to perform the method, technique, or process as described in or related to any one of examples 1-32, or portions thereof.
Example 48 may include a computer program comprising instructions, wherein execution of the program by a processing element causes the processing element to perform a method, technique, or process as described in or related to any one of examples 1-32 or portions thereof.
Example 45 may include a signal in a wireless network as shown and described herein.
Example 46 may include a method of communicating in a wireless network as shown and described herein.
Example 47 may include a system for providing wireless communications as shown and described herein.
Example 48 may include a device to provide wireless communication as shown and described herein.
An example implementation is an edge computing system including respective edge processing devices and nodes to invoke or perform operations of the above examples or other subject matter described herein. Another example implementation is a client endpoint node operable to invoke or perform the operations of the above examples or other subject matter described herein. Another example implementation is an aggregation node, network hub node, gateway node, or core data processing node within or coupled to an edge computing system, operable to invoke or perform the operations of the above examples or other subject matter described herein. Another example implementation is an access point, base station, roadside unit, street unit, or premise unit within or coupled to an edge computing system operable to invoke or perform the operations of the above examples or other subject matter described herein. Another example implementation is an edge provisioning node, a service orchestration node, an application orchestration node, or a multi-tenant management node within or coupled to an edge computing system, operable to invoke or perform the operations of the above examples or other subject matter described herein. Another example implementation is an edge node within or coupled to an edge computing system that operates an edge provisioning service, an application or service orchestration service, a virtual machine deployment, a container deployment, a function deployment, and a computing management, the edge node being operable to invoke or perform operations of the above examples or other subject matter described herein. Another example implementation is an edge computing system operable as an edge grid, as an edge grid with side car loading, or in grid-to-grid communication operation, operable to invoke or perform the operations of the above examples or other subject matter described herein. Another example implementation is an edge computing system including aspects of network functionality, acceleration hardware, storage hardware, or computing hardware resources, operable to invoke or execute the use cases discussed herein using the above examples or other subject matter described herein. Another example implementation is an edge computing system adapted to support client mobility, vehicle-to-vehicle (V2V), vehicle-to-everything (V2X), or vehicle-to-infrastructure (V2I) scenarios, and optionally operating in accordance with the ETSIMEC specification, operable to invoke or execute the use cases discussed herein using the above examples or other subject matter described herein. Another example implementation is an edge computing system adapted for mobile wireless communications (including being configured according to 3gpp 4G/LTE or 5G network capabilities) that is operable to invoke or perform the use cases discussed herein using the above examples or other subject matter described herein. Another example implementation is a computing system adapted for network communications (including configuration according to O-RAN capabilities) that is operable to invoke or perform the use cases discussed herein using the above examples or other subject matter described herein.
Any of the above examples may be combined with any other example (or combination of examples) unless explicitly stated otherwise. The foregoing description of one or more implementations provides illustration and description, but is not intended to be exhaustive or to limit the scope of the embodiments to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of various embodiments.
Unless used differently herein, terms, definitions and abbreviations may be consistent with terms, definitions and abbreviations defined in 3GPP TR 21.905v16.0.0 (2019-06). For purposes of this document, the following abbreviations may apply to the examples and embodiments discussed herein.
Table 4 abbreviations:
/>
/>
/>
/>
/>
/>
/>
the foregoing description provides illustration and description of various example embodiments, but is not intended to be exhaustive or to limit the scope of the embodiments to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of various embodiments. Where specific details are set forth in order to describe example embodiments of the disclosure, it should be apparent to one skilled in the art that the disclosure can be practiced without, or with variation of, these specific details. It should be understood, however, that there is no intention to limit the concepts of the present disclosure to the specific forms disclosed, but on the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the disclosure and the appended claims.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
For the purposes of this disclosure, the phrase "a and/or B" refers to (a), (B), or (a and B). For the purposes of this disclosure, the phrase "A, B and/or C" refers to (a), (B), (C), (a and B), (a and C), (B and C), or (A, B and C). The description may use the phrases "in an embodiment" or "in some embodiments," which may each refer to one or more of the same or different embodiments. Furthermore, the terms "comprising," "including," "having," and the like, as used with respect to embodiments of the present disclosure, are synonymous.
The terms "coupled," "communicatively coupled," and their derivatives are used herein. The term "coupled" may mean that two or more elements are in direct physical or electrical contact with each other, may mean that two or more elements are in indirect contact with each other but still cooperate or interact with each other, and/or may mean that one or more other elements are coupled or connected between elements referred to as being coupled to each other. The term "directly coupled" may mean that two or more elements are in direct contact with each other. The term "communicatively coupled" may mean that two or more elements may be in contact with each other through communication means (including through wired or other interconnection connections, through wireless communication channels or links, etc.).
The term "circuitry" as used herein refers to, is part of, or includes, the following hardware components configured to provide the described functionality: such as electronic circuitry, logic circuitry, 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 (hcld), a structured ASIC, or a programmable SoC), a Digital Signal Processor (DSP), etc. 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 one or more hardware elements in combination with program code (or a combination of circuitry and program code used in an electrical or electronic system) for performing the functions of the program code. In these embodiments, a combination of hardware elements and program code may be referred to as a particular type of circuit.
The term "processor circuit" as used herein refers to a circuit, part of or comprising, capable of sequentially and automatically performing a series of arithmetic or logical operations, or recording, storing and/or transmitting digital data. The processing circuitry may include one or more processing cores for executing instructions and one or more memory structures for storing program and data information. The term "processor circuitry" may refer to one or more application processors, one or more baseband processors, a physical Central Processing Unit (CPU), a single core processor, a dual core processor, a tri-core processor, a quad-core processor, and/or any other device capable of executing or otherwise operating computer-executable instructions (e.g., program code, software modules, and/or functional processes). The processing circuitry may include further hardware accelerators, which may be microprocessors, programmable processing devices, or the like. The one or more hardware accelerators may include, for example, computer Vision (CV) and/or Deep Learning (DL) accelerators. The terms "application circuitry" and/or "baseband circuitry" may be considered synonymous with "processor circuitry" and may be referred to as "processor circuitry".
The terms "memory" and/or "memory circuitry" as used herein refer to one or more hardware devices for storing data, including RAM, MRAM, PRAM, DRAM and/or SDRAM, core memory, ROM, magnetic disk storage media, optical storage media, flash memory devices, or other machine-readable media for storing data. The term "computer-readable medium" can include, but is not limited to, memory, portable or fixed storage devices, optical storage devices and various other mediums capable of storing, containing or carrying instruction(s) or data.
The term "interface circuit" as used herein refers to, is part of, or includes circuitry that enables the exchange of information between two or more components or devices. The term "interface circuit" may refer to one or more hardware interfaces, such as a bus, an I/O interface, a peripheral component interface, a network interface card, and the like.
The term "user equipment" or "UE" as used herein refers to a device having radio communication capabilities and may describe a remote user of network resources in a communication network. The term "user equipment" or "UE" may be considered as synonyms for the following terms and may be referred to as they: a client, mobile station, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, radio, reconfigurable mobile device, etc. Furthermore, the term "user equipment" or "UE" may include any type of wireless/wired device or any computing device that contains a wireless communication interface.
The term "network element" as used herein refers to a physical or virtualized device and/or infrastructure for providing wired or wireless communication network services. The term "network element" may be considered as synonym for and/or referred to as the following terms: a networked computer, networking hardware, network device, network node, router, switch, hub, bridge, radio network controller, RAN device, RAN node, gateway, server, virtualized VNF, NFVI, etc.
The term "computer system" as used herein refers to any type of interconnected electronic device, computer device, or component thereof. Furthermore, the terms "computer system" and/or "system" may refer to various components of a computer that are communicatively coupled to each other. Furthermore, the terms "computer system" and/or "system" may refer to a plurality of computer devices and/or a plurality of computing systems communicatively coupled to each other and configured to share computing and/or networking resources.
The terms "appliance," "computer appliance," and the like as used herein refer to a computer device or computer system having program code (e.g., software or firmware) specifically designed to provide a particular computing resource. A "virtual appliance" is a virtual machine image to be implemented by a hypervisor-equipped device that virtualizes or emulates a computer appliance or is otherwise dedicated to providing specific computing resources. The term "element" refers to a unit that is indivisible at a given level of abstraction and has well-defined boundaries, wherein the element may be any type of entity including, for example, one or more devices, systems, controllers, network elements, modules, etc., or a combination thereof. The term "device" refers to a physical entity embedded within or attached to another physical entity in its vicinity, having the ability to transfer digital information from or to that physical entity. The term "entity" refers to a unique component of an architecture or device, or information transmitted as a payload. The term "controller" refers to an element or entity that has the ability to affect a physical entity (e.g., by changing its state or moving the physical entity).
The term "cloud computing" or "cloud" refers to a paradigm for enabling network access to a pool of scalable and resilient shareable computing resources with on-demand self-service provisioning and administration and without active management by users. Cloud computing provides cloud computing services (or cloud services), which are one or more capabilities that are invoked via an interface (e.g., API, etc.) of a usage definition provided by the cloud computing. The term "computing resource" or simply "resource" refers to any physical or virtual component or use of such components within a computer system or network of limited availability. Examples of computing resources include use/access to servers, processors, storage devices, memory areas, networks, power, input/output (peripheral) devices, mechanical devices, network connections (e.g., channels/links, ports, network sockets, etc.), operating systems, virtual Machines (VMs), software/applications, computer files, etc., for a period of time. "hardware resources" may refer to computing, storage, and/or network resources provided by physical hardware elements. "virtualized resources" may refer to computing, storage, and/or network resources provided by the virtualization infrastructure to applications, devices, systems, etc. The term "network resource" or "communication resource" may refer to a resource that is accessible to a computer device/system via a communication network. The term "system resource" may refer to any kind of shared entity for providing a service and may include computing resources and/or network resources. System resources may be viewed as a set of contiguous functions, network data objects, or services that are accessible through a server, where the system resources reside on a single host or multiple hosts and are clearly identifiable. As used herein, the term "cloud service provider" (or CSP) indicates an organization that typically operates large-scale "cloud" resources (e.g., used in the context of public clouds) consisting of centralized, regional, and edge data centers. In other examples, CSP may also be referred to as a Cloud Service Operator (CSO). References to "cloud computing" generally refer to computing resources and services provided by CSP or CSO at remote locations with at least some added latency, distance, or constraint relative to edge computing.
As used herein, the term "data center" refers to a specially designed structure intended to accommodate multiple high performance computing and data storage nodes such that there are a large number of computing, data storage and network resources at a single location. This often requires a dedicated rack and enclosure system, suitable heating, cooling, ventilation, safety, fire suppression and power delivery systems. In some contexts, the term may also refer to compute and data storage nodes. The data centers may vary in size between a centralized or cloud data center (e.g., max), an area data center, and an edge data center (e.g., min).
As used herein, the term "edge computation" refers to the implementation, coordination, and use of computing resources at locations closer to the "edge" or "set of edges" of the network. Deploying computing resources at the edge of the network can reduce application and network latency, reduce network backhaul traffic and associated energy consumption, promote service capabilities, promote compliance with security or data privacy requirements (especially compared to traditional cloud computing), and improve total ownership costs. As used herein, the term "edge computing node" refers to a real-world, logical, or virtualized implementation of computing capable elements in the form of devices, gateways, bridges, systems or subsystems, components, whether operating in server, client, endpoint, or peer-to-peer mode, and whether located at the "edge" of a network or at a more distant connection location within a network. References to "nodes" as used herein are generally interchangeable with "devices," "components," and "subsystems"; however, references to an "edge computing system" or "edge computing network" generally refer to a distributed architecture, organization, or collection of multiple nodes and devices, and are organized to accomplish or provide some aspect of a service or resource in an edge computing setting.
Additionally or alternatively, the term "edge computation" refers to the concept of having operators and third party services hosted near the attachment access point of the UE to enable efficient service delivery with reduced end-to-end latency and load on the transport network, as described in [6 ]. As used herein, the term "edge computing service provider" refers to a mobile network operator or a third party service provider that provides edge computing services. As used herein, the term "edge data network" refers to a local Data Network (DN) that supports an architecture for implementing edge applications. As used herein, the term "edge hosting environment" refers to an environment that provides the support required for the execution of edge application servers. As used herein, the term "application server" refers to application software residing in the cloud that performs server functions.
The term "internet of things" or "IoT" refers to systems of interrelated computing devices, machines, and digital machines that are capable of transmitting data with little or no human interaction, and may involve technologies such as real-time analysis, machine learning and/or AI, embedded systems, wireless sensor networks, control systems, automation (e.g., smart home, smart building, and/or smart city technologies), and the like. IoT devices are typically low power devices that do not have heavy computing or storage capabilities. An "edge IoT device" may be any kind of IoT device deployed at the edge of a network.
As used herein, the term "cluster" refers to a set or set of entities in the form of physical entities (e.g., different computing systems, networks, or groups of networks), logical entities (e.g., applications, functions, security constructs, containers), etc., that are part of an edge computing system(s). In some locations, a "cluster" is also referred to as a "group" or "domain. The membership of a cluster may be modified or affected based on conditions or functions, including according to dynamic or attribute-based membership, according to a network or system management scenario, or according to various example techniques discussed below that may add, modify, or delete entities in the cluster. The clusters may also include or be associated with multiple layers, levels, or attributes (including variations in security features and results based on these layers, levels, or attributes).
The term "application" may refer to a complete and deployable package, environment for implementing specific functions in an operating environment. The term "AI/ML application" or the like may be an application that contains some AI/ML model and application-level descriptions. The term "machine learning" or "ML" refers to the use of computer systems implementing algorithms and/or statistical models that do not use explicit instructions, but instead rely on patterns and reasoning to perform particular tasks. The ML algorithm builds or estimates a mathematical model (called "ML model" or the like) based on sample data (called "training data", "model training information", or the like) in order to make predictions or decisions without explicit programming to perform these tasks. Generally, the ML algorithm is a computer program that learns from experience with some tasks and some performance metrics, while the ML model may be any object or data structure created after training the ML algorithm with one or more training data sets. After training, the ML model can be used to predict the new dataset. Although the term "ML algorithm" refers to a different concept than the term "ML model", for purposes of this disclosure, these terms discussed herein may be used interchangeably.
The terms "machine learning model", "ML model", and the like may also refer to ML methods and concepts used by ML-assisted solutions. An "ML-assisted solution" is a solution that uses an ML algorithm to solve a particular use case during operation. The ML model includes supervised learning (e.g., linear regression, K-nearest neighbor (KNN), decision tree algorithms, support machine vectors, bayesian algorithms, integration algorithms, etc.), unsupervised learning (e.g., K-means clustering, principal Component Analysis (PCA), etc.), reinforcement learning (e.g., Q-learning, deep RL, etc.), neural networks, etc. Depending on the implementation, a particular ML model may have many sub-models as components, and the ML model may train all sub-models together. During reasoning, separately trained ML models can also be linked together in the ML pipeline. An "ML pipe" is a set of functionalities, functions, or functional entities that are specific to an ML auxiliary solution; the ML pipeline may include one or several data sources among a data pipeline, a model training pipeline, a model evaluation pipeline, and a participant. "participants" are entities that host ML auxiliary solutions using the output of ML model reasoning. The term "ML training host" refers to an entity (e.g., network function) hosting the training of the model. The term "ML inference host" refers to an entity (e.g., a network function) that hosts a model during an inference mode (which includes both model execution and any online learning, if applicable). The ML host informs the participants of the output of the ML algorithm and the participants make decisions about the actions (as a result of the ML assistance solution output, the "actions" are performed by the participants). The term "model reasoning information" refers to information that refers to input to the ML model for determining reasoning; the data used to train the ML model and the data used to determine the reasoning may overlap, however, "training data" and "reasoning data" refer to different concepts.
The terms "instantiation", "instantiation" and the like as used herein refer to the creation of an instance. An "instance" also refers to a specific occurrence of an object that may occur, for example, during execution of program code. The term "cell" refers to a structural element that contains one or more fields. The term "field" refers to the individual content of a cell or a data element containing content. As used herein, "database object," "data structure," and the like may refer to any representation of information in the form of objects, attribute-value pairs (AVPs), key-value pairs (KVP), tuples, and the like, and may include variables, data structures, functions, methods, classes, database records, database fields, database entities, associations (also referred to as "relationships") between data and/or database entities, blocks in a blockchain implementation, links between blocks, and the like.
An "information object" as used herein refers to any representation of a collection of structured data and/or information, and may include, for example, an electronic document (or "document"), a database object, a data structure, a file, audio data, video data, raw data, an archive file, an application package, and/or any other similar representation of information. The term "electronic document" or "document" may refer to A data structure, computer file, or resource for recording data, and includes various file types and/or data formats (e.g., word processing documents, spreadsheets, slide presentations, multimedia items, web pages, and/or source code documents, etc.). By way of example, the information object may include a markup and/or source code document (e.g., HTML, XML, JSON,CSS、JSP、MessagePack TM 、/>Thrift TM 、ASN.1、/>Protocol buffers (protobuf) or some other document/format (e.g., the document/format discussed herein)). The information object may have both logical and physical structures. Physically, an information object comprises one or more units called entities. An entity is a unit of storage that contains content and is identified by a name. An entity may refer to other entities that make it included in an information object. The information object starts in a document entity, also called a root element (or "root"). Logically, an information object includes one or more declarations, elements, annotations, character references, and processing instructions, all of which are indicated in the information object (e.g., using tags).
The term "data item" as used herein refers to an atomic state of a particular object having at least one particular property at a point in time. Such objects are typically identified by object names or object identifiers, and the properties of such objects are typically defined as database objects (e.g., fields, records, etc.), object instances, or data elements (e.g., markup language elements/tags, etc.). Additionally or alternatively, the term "data item" as used herein may refer to data elements and/or content items, although these terms may refer to different concepts. The term "data element" or "element" as used herein refers to a unit that is indivisible at a given level of abstraction and has well-defined boundaries. A data element is a logical component of an information object (e.g., an electronic document) that may start with a start tag (e.g., "< element >") and end with a matching end tag (e.g., "</element >") or have only a null element tag (e.g., "< element/>). Any character (if any) between the start tag and the end tag is the content of the element (referred to herein as a "content item" or the like).
The content of the entity may include one or more content items, each having an associated data type representation. The content items may include, for example, attribute values, character values, URIs, qualified names (qnames), parameters, and the like. qname is a fully qualified name of an element, attribute, or identifier in an information object. The qname associates the URI of the namespace with the local name of the element, attribute, or identifier in the namespace. To make this association, the qname assigns a prefix to the local name that corresponds to its namespace. qname includes the URI of the namespace, the prefix, and the local name. Namespaces are used to provide uniquely named elements and attributes in an information object. The content items may include text content (e.g., "< element > content item </element >"), attributes (e.g., "< element attribute =" attributeValue ">") and other elements referred to as "sub-elements" (e.g., "< element1> < element2> content item </element2> </element1 >"). An "attribute" may refer to a tag construct that includes name-value pairs that exist within a start tag or a null element tag. Attributes contain data related to their elements and/or control the behavior of the elements.
The term "channel" as used herein refers to any tangible or intangible transmission medium to communicate data or data streams. The term "channel" may be synonymous and/or equivalent to "communication channel," "data communication channel," "transmission channel," "data transmission channel," "access channel," "data access channel," "link," "data link," "carrier," "radio frequency carrier," and/or any other similar term that refers to a path or medium through which data is communicated. Furthermore, the term "link" as used herein refers to a connection between two devices through a RAT for the purpose of transmitting and receiving information. As used herein, the term "radio technology" refers to technology for wirelessly transmitting and/or receiving electromagnetic radiation for information transfer. The term "radio access technology" or "RAT" refers to a technology for an underlying physical connection to a radio-based communication network. As used herein, the term "communication protocol" (wired or wireless) refers to a set of standardized rules or instructions implemented by a communication device and/or system to communicate with other devices and/or systems, including instructions for encapsulating/decapsulating data, modulating/demodulating signals, implementing a protocol stack, etc.
As used herein, the term "radio technology" refers to technology for wirelessly transmitting and/or receiving electromagnetic radiation for information transfer. The term "radio access technology" or "RAT" refers to a technology for an underlying physical connection to a radio-based communication network. As used herein, the term "communication protocol" (wired or wireless) refers to a set of standardized rules or instructions implemented by a communication device and/or system to communicate with other devices and/or systems, including instructions for encapsulating/decapsulating data, modulating/demodulating signals, implementing a protocol stack, etc. Examples of wireless communication protocols that may be used in various embodiments include global system for mobile communications (GSM) radio communication technology, general Packet Radio Service (GPRS) radio communication technology, enhanced data rates for GSM evolution (EDGE) radio communication technology, and/or third generation partnership project (3 GPP) radio communication technology (including, for example, 3GPP fifth generation (5G) or new air interface (NR), universal Mobile Telecommunications System (UMTS), multimedia access Free (FOMA), long Term Evolution (LTE), LTE advanced (LTE-a), LTE Extra, LTE-a Pro, cdmaOne (2G), code division multiple access 2000 (CDMA 2000), cellular Digital Packet Data (CDPD), mobitex, circuit Switched Data (CSD), high speed CSD (hscssd), universal Mobile Telecommunications System (UMTS), wideband code division multiple access (W-CDM), high speed packet access (HSPA Plus (hspa+), time division-CDMA), time division-synchronous code division multiple access (HSPA), LTE (HSPA), muLTEfire, UMTS, LTE-a, CDMA (UTRA), and UTRA (UTRA) Data on evolution (EV-DO), advanced Mobile Phone System (AMPS), digital AMPS (D-AMPS), full access communication system/extended full access communication system (TACS/ETACS), push-to-talk (PTT), mobile phone system (MTS), modified mobile phone system (IMTS), advanced mobile phone system (AMTS), cellular Digital Packet Data (CDPD), dataTAC, integrated Digital Enhanced Network (iDEN), personal Digital Cellular (PDC), personal Handyphone System (PHS), broadband integrated digital enhanced network (WiDEN), iBurst, unlicensed Mobile Access (UMA) (also known as 3GPP generic access network or GAN standard))Bluetooth Low Energy (BLE), IEEE 802.15.4-based protocols (e.g., IPv6 (6 LoWPAN), wireless HART, miWi, thread, 802.11a, etc. on a low power wireless personal area network), wiFi direct connection, ANT/ANT+, zigBee, Z-Wave, 3GPP device-to-device (D2D) or proximity services (ProSe), universal plug and Play (UPnP), low Power Wide Area Network (LPWAN), long distance Wide area network (LoRA) or LoRaWAN developed by Semtech and LoRa alliance TM Sigfox, wireless gigabit alliance (WiGig) standards, worldwide Interoperability for Microwave Access (WiMAX), universal mmWave standards (e.g., wireless systems operating at 10GHz-300GHz and above (e.g., wiGig, IEEE 802.11ad, IEEE 802.11ay, etc.), V2X communication techniques (including 3GPP C-V2X), dedicated short-range communication (DSRC) communication systems (e.g., intelligent Transportation Systems (ITS) including European ITS-G5, ITS-G5B, ITS-G5C, etc.). In addition to the standards listed above, any number of satellite uplink techniques may be used for purposes of this disclosure, including, for example, radios conforming to standards promulgated by the International Telecommunications Union (ITU), or the European Telecommunications Standards Institute (ETSI), or the like. Accordingly, the examples provided herein are understood to be applicable to a variety of other communication technologies, both existing and yet to be established.
The term "access network" refers to any network using any combination of radio technologies, RATs, and/or communication protocols to connect user equipment and service providers. In the context of a WLAN, an "access network" is an IEEE 802 Local Area Network (LAN) or Metropolitan Area Network (MAN) connected between terminals and access routers served by a provider. The term "access router" refers to a router that terminates a Medium Access Control (MAC) service from a terminal and forwards user traffic to an information server according to an Internet Protocol (IP) address.
The term "SMTC" refers to an SSB-based measurement timing configuration configured by SSB-measurementtiming configuration. The term "SSB" refers to a synchronization signal/physical broadcast channel (SS/PBCH) block that includes a Primary Synchronization Signal (PSS), a Secondary Synchronization Signal (SSs), and a PBCH. The term "primary cell" refers to an MCG cell operating on a primary frequency in which a UE performs an initial connection establishment procedure or initiates a connection re-establishment procedure. The term "primary SCG cell" refers to an SCG cell for DC operation in which the UE performs random access when performing a reconfiguration & synchronization procedure. The term "secondary cell" refers to a cell providing additional radio resources on top of a special cell for a UE configured with CA. The term "secondary cell group" refers to a subset of serving cells including PSCell and zero or more secondary cells for a UE configured with DC. The term "serving cell" refers to a primary cell for a UE under rrc_connected that is not configured with CA/DC, and there is only one serving cell including the primary cell. The term "serving cell" or "plurality of serving cells" refers to a cell set including a special cell and all secondary cells for a UE under rrc_connected configured with CA. The term "special cell" refers to the PCell of an MCG or the PSCell of an SCG for DC operation; otherwise, the term "special cell" refers to a Pcell.
The term "A1 policy" refers to the type of declarative policies expressed using formal declarations that enable non-RT RIC functions in SMO to direct near-RT RIC functions and thus direct the RAN toward better fulfilling RAN intent.
The term "A1 enrichment information" refers to information utilized by the near-RT RIC, which information is collected or derived at the SMO/non-RT RIC from non-network data sources or from the network function itself.
The term "A1 policy based traffic guidance handling mode" refers to an operation mode in which the Near-RT RIC is configured by the A1 policy to use traffic guidance actions to ensure a more specific network performance concept (e.g., applied to a smaller group of E2 nodes and UEs in the RAN) than it ensures in background traffic guidance.
The term "background traffic steering processing mode" refers to an operation mode in which near-RT RIC is configured by O1 to use traffic steering actions to ensure universal background network performance for E2 nodes and UEs widely used in the RAN.
The term "baseline RAN behavior" refers to default RAN behavior that SMO configures at the E2 node.
The term "E2" refers to an interface connecting a Near-RT RIC and one or more O-CU-CPs, one or more O-CU-UPs, one or more O-DUs, and one or more O-eNBs.
The term "E2 node" refers to a logical node that terminates an E2 interface. In this version of the specification, the ora node terminating the E2 interface is: for NR access: O-CU-CP, O-CU-UP, O-DU or any combination thereof; for E-UTRA access: O-eNB.
In the context of an O-RAN system/implementation, the term "intent" refers to a declarative policy that directs or directs the behavior of RAN functions, allowing the RAN functions to calculate optimal results to achieve a given goal.
The term "O-RAN non-real time RAN intelligent controller" or "non-RT RIC" refers to a logic function that enables non-real time control and optimization of RAN elements and resources, AI/ML workflows (including model training and updating), and policy-based guidance of applications/features in the Near-RT RIC.
The term "Near-RT RIC" or "O-RAN Near-real-time RAN intelligent controller" refers to a logic function that enables Near-real-time control and optimization of RAN elements and resources over E2 interfaces via fine-granularity (e.g., UE basis, cell basis).
The term "O-RAN central unit" or "O-CU" refers to a logical node that hosts RRC, SDAP, and PDCP protocols.
The term "O-RAN central unit-control plane" or "O-CU-CP" refers to a logical node that hosts the control plane portion of the RRC and PDCP protocols.
The term "O-RAN central unit-user plane" or "O-CU-UP" refers to the logical node hosting the user plane part of the PDCP protocol and the SDAP protocol.
The term "O-RAN distributed unit" or "O-DU" refers to a logical node hosting the RLC/MAC/High-PHY layer based on lower layer functional partitioning.
The term "O-RAN eNB" or "O-eNB" refers to an eNB or a ng-eNB that supports an E2 interface.
The term "O-RAN radio unit" or "O-RU" refers to a logical node that hosts the Low-PHY layer and RF processing based on underlying functional partitions. This is similar to the "TRP" or "RRH" of 3GPP, but more specifically includes the Low-PHY layer (FFT/iFFT, PRACH extraction).
The term "O1" refers to the interface between an Orchestration & management entity (NMS) and O-RAN management elements for operation and management, through which FCAPS management, software management, file management, and other similar functions should be implemented.
The term "RAN UE group" refers to the aggregation of UEs that set up packets in the E2 node through the E2 procedure also based on the scope of the A1 policy. These groups may then be the targets of E2 CONTROL or POLICY messages.
The term "traffic steering action" refers to using a mechanism to change RAN behavior. Such actions include E2 processes such as CONTROL and POLICY.
The term "traffic guidance inner loop" refers to the part of the traffic guidance process triggered by the arrival of periodic TS-related KPMs (key performance measures) from the E2 node, which includes UE grouping, additional data collection set from the RAN, and selection and execution of one or more optimization actions to implement the traffic guidance policy.
The term "traffic guidance outer loop" refers to the part of the traffic guidance process triggered by the Near-RT RIC setting or updating the traffic guidance aware resource optimization procedure based on the information from the A1 policy setting or updating, the A1 Enrichment Information (EI) and/or the results of the Near-RT RIC evaluation, including initial configuration (preconditions) and injection of the relevant A1 policies, trigger conditions for TS changes.
The term "traffic guidance handling mode" refers to an operation mode in which the RAN or Near-RT RIC is configured to ensure certain network performance. The performance includes aspects such as cell load and throughput, and may be applied differently to different E2 nodes and UEs. Throughout this process, the business-directed actions are used to fulfill the requirements of the configuration.
The term "traffic guidance objective" refers to the expected performance result expected by the network, which is configured to the Near-RT RIC by O1.
Furthermore, any of the disclosed embodiments and example implementations may be embodied in various types of hardware, software, firmware, middleware, or a combination thereof (including in the form of control logic), and such hardware or software is employed in a modular or integrated manner. Furthermore, any software components or functions described herein may be implemented as software, program code, scripts, instructions, etc. that are operable to be executed by processor circuitry. The components, functions, programs, etc. may be developed using any suitable computer language, such as Python, pyTorch, numPy, ruby, ruby on Rails, scala, smalltalk, java TM C++, C#, "C", kotlin, swift, rust, go (or "Golang"), EMCAScript, javaScript, typeScript, jscript, actionScript, server-side JavaScript (SSJS), PHP, pearl, lua, torch/Lua and Just-In Time compiler (LuaJIT), accelerated Mobile Page script (AMPscript), VBScript, javaServer Pages (JSP), active Server Pages (ASP), node. Js, ASP. NET, JAMscript, hyperText markup language (HTML), extensible HTML (XHTML), extensible markup language (XML), XML user interface language (XUL), scalable Vector Graphics (SVG), RESTful API Modeling Language (RAML), wikid markup or Wikiet xt, wireless Markup Language (WML), java script object concept (ON), MessagePack TM Cascading Style Sheets (CSS), extensible style sheet language (XSL), hu sub template language, handle bar template language, guide Template Language (GTL), and +.>Thread, abstract syntax symbol one (ASN.1), for example>Protocol buffering (protobuf), bitcoin script, +.>Byte code, resolution TM Vyper (Python derivative), bamroo, lisp class language (LLL), from Blockstream TM Simplicity, rholang, michelson, counterfactual, plasma, plutus, sophia provided,And/or any other programming language or development tool (including proprietary programming languages and/or development tools). The software codes may be stored as computer or processor executable instructions or commands on a physically non-transitory computer readable medium. Examples of suitable media include RAM, ROM, magnetic media (e.g., hard or floppy disk drive), or optical media (e.g., compact Disk (CD) or DVD (digital versatile disk), flash memory, etc.), or any combination of such storage or transmission devices. />

Claims (25)

1. An apparatus for managing a service (MnS) producer, the apparatus comprising processing circuitry coupled to storage, the processing circuitry configured to:
obtaining input data related to networks and services within a 5G system (5 GS) to provide MDA capabilities to MnS consumers within the 5 GS;
Generating one or more MDA reports, wherein the one or more MDA reports include one or more common cells, at least one MDA type associated with the MDA capability, and one or more MDA type specific cells; and
such that the one or more MDA reports are sent to the MnS consumer.
2. The apparatus of claim 1, wherein the MnS producer is capable of acting as a Machine Learning (ML) capability producer to provide ML capabilities to ML capability consumers.
3. The apparatus of claim 1, wherein the MnS producer is capable of acting as a Machine Learning (ML) capability consumer to receive ML capabilities from the ML capability producer.
4. The apparatus of claim 3, wherein the ML-capability producer is configured to: ML for one or more mnss in the 5GS is supported by being configured to:
receiving training data from the ML capability consumers;
training an ML model; and
based on the training data, ML capabilities are established in the ML capabilities producer.
5. The apparatus of claim 4, wherein the ml_ capability producer is further configured to:
sending a training report to the ML capability consumer; and
Authentication feedback received from the ml_ capability consumer is identified.
6. The apparatus of claim 5, wherein the ml_ capability producer is further configured to:
retraining the ML model based on the verification feedback.
7. The apparatus of claim 1, wherein the MnS is a Management Data Analysis Service (MDAS).
8. The apparatus of claim 1, wherein the one or more common cells comprise information common to a plurality of Management Data Analysis (MDA) reports.
9. The apparatus of claim 5, wherein the verification feedback is associated with verifying training reports related to ML capabilities.
10. The apparatus of claim 8, wherein the one or more common cells are used for at least one or more of:
an identifier that uniquely identifies the MDA report between the MDAS producer and the MDAS consumer,
the time at which the MDA report is generated,
the type of indication of MDA capability used to analyze the corresponding problem,
the identifiers of the questions described in the MDA report,
the cause of the problem described in the MDA report,
the severity level of the problem described in the MDA report,
the time at which the problem described in the MDA report starts,
The time of the most recent update of the problem described in the MDA report,
the time at which the problem described in the MDA report stopped,
managed Object Instance (MOI) affected by the problem described in MDA report, or
Recommended actions to solve the problem described in MDA reports.
11. A computer-readable storage medium comprising instructions that, when executed by a processing circuit, cause the processing circuit to:
obtaining, by a management service (MnS) producer, input data related to networks and services within a 5G system (5 GS) to provide MDA capabilities to MnS consumers within the 5 GS;
generating one or more MDA reports, wherein the one or more MDA reports include one or more common cells, at least one MDA type associated with the MDA capability, and one or more MDA type specific cells; and
such that the one or more MDA reports are sent to the MnS consumer.
12. The computer-readable storage medium of claim 11, wherein the MnS producer is capable of acting as a Machine Learning (ML) capability producer to provide ML capabilities to ML capability consumers.
13. The computer-readable storage medium of claim 11, wherein the MnS producer is capable of acting as a Machine Learning (ML) capability consumer to receive ML capabilities from an ML capability producer.
14. The computer-readable storage medium of claim 13, wherein the ML-capability producer is configured to: ML for one or more mnss in the 5GS is supported by being configured to:
receiving training data from the ML capability consumers;
training an ML model; and
based on the training data, ML capabilities are established in the ML capabilities producer.
15. The computer-readable storage medium of claim 14, wherein the ML-capability producer is further configured to:
sending a training report to the ML capability consumer; and
authentication feedback received from the ml_ capability consumer is identified.
16. The computer-readable storage medium of claim 15, wherein the ML-capability producer is further configured to:
retraining the ML model based on the verification feedback.
17. The computer-readable storage medium of claim 11, wherein the MnS is a Management Data Analysis Service (MDAS).
18. The computer-readable storage medium of claim 11, wherein the one or more common cells comprise information common to a plurality of Management Data Analysis (MDA) reports.
19. The computer-readable storage medium of claim 15, wherein the verification feedback is associated with verifying training reports related to ML capabilities.
20. The computer-readable storage medium of claim 18, wherein the one or more common cells are used for at least one or more of:
an identifier that uniquely identifies the MDA report between the MDAS producer and the MDAS consumer,
the time at which the MDA report is generated,
the type of indication of MDA capability used to analyze the corresponding problem,
the identifiers of the questions described in the MDA report,
the cause of the problem described in the MDA report,
the severity level of the problem described in the MDA report,
the time at which the problem described in the MDA report starts,
the time of the most recent update of the problem described in the MDA report,
the time at which the problem described in the MDA report stopped,
managed Object Instance (MOI) affected by the problem described in MDA report, or
Recommended actions to solve the problem described in MDA reports.
21. The computer-readable storage medium of any of claims 20, wherein the recommended action may be to create, modify, and/or delete a 3GPP MOI, and/or invoke one or more non-3GPP operations.
22. A method, comprising:
obtaining, by one or more processors of a management service (MnS) producer, input data related to networks and services within a 5G system (5 GS) to provide MDA capabilities to MnS consumers within the 5 GS;
Generating one or more MDA reports, wherein the one or more MDA reports include one or more common cells, at least one MDA type associated with the MDA capability, and one or more MDA type specific cells; and
such that the one or more MDA reports are sent to the MnS consumer.
23. The method of claim 22, wherein the MnS producer is capable of acting as a Machine Learning (ML) capability producer to provide ML capabilities to ML capability consumers.
24. An apparatus comprising means for performing any of the methods of claims 22-23.
25. A network node, comprising: a communication interface; and processing circuitry coupled to the communication interface and configured to perform the methods of claims 22-23.
CN202280021201.2A 2021-04-15 2022-04-14 Machine learning support for management services and management data analysis services Pending CN116998137A (en)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US63/175,482 2021-04-15
US202163177757P 2021-04-21 2021-04-21
US63/177,757 2021-04-21
PCT/US2022/024758 WO2022221495A1 (en) 2021-04-15 2022-04-14 Machine learning support for management services and management data analytics services

Publications (1)

Publication Number Publication Date
CN116998137A true CN116998137A (en) 2023-11-03

Family

ID=88523649

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202280021201.2A Pending CN116998137A (en) 2021-04-15 2022-04-14 Machine learning support for management services and management data analysis services

Country Status (1)

Country Link
CN (1) CN116998137A (en)

Similar Documents

Publication Publication Date Title
WO2022221260A1 (en) O-cloud lifecycle management service support
WO2022087482A1 (en) Resource allocation for new radio multicast-broadcast service
CN116134941A (en) In-user equipment prioritization for handling overlapping of uplink control channels and uplink data channels
WO2022031553A1 (en) Data plane for big data and data as a service in next generation cellular networks
US20240196178A1 (en) Data functions and procedures in the non-real time radio access network intelligent controller
WO2022221495A1 (en) Machine learning support for management services and management data analytics services
CN116868556A (en) Mechanism for implementing in-network computing services
WO2022087489A1 (en) Downlink control information (dci) based beam indication for new radio (nr)
CN116998137A (en) Machine learning support for management services and management data analysis services
US20240155393A1 (en) Measurement reporting efficiency enhancement
CN117480804A (en) Measurement and location data supporting Management Data Analysis (MDA) for coverage problem analysis
CN117136531A (en) Performance measurement for unified data repository (UDR)
CN117546456A (en) Performance measurement for network open functionality
CN117378182A (en) Load balancing optimization for 5G systems
US20240187071A1 (en) Time domain restriction for channel state information reference signal configuration
CN117546450A (en) Performance measurement for location management versus location management functions
CN117397219A (en) Policy authorization and event exposure performance measurement for network exposure functions
US20240154761A1 (en) Phase tracking reference signal (pt-rs) pattern determination
WO2024026515A1 (en) Artificial intelligence and machine learning entity testing
WO2023069750A1 (en) Good cell quality criteria
WO2024076852A1 (en) Data collection coordination function and network data analytics function framework for sensing services in next generation cellular networks
WO2024015747A1 (en) Session management function selection in cellular networks supporting distributed non-access stratum between a device and network functions
WO2024031028A1 (en) Activation and deactivation of semi-persistent scheduling using multi-cell techniques
WO2024091970A1 (en) Performance evaluation for artificial intelligence/machine learning inference
WO2024020519A1 (en) Systems and methods for sharing unstructured data storage function services

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination