[go: up one dir, main page]

WO2025014819A1 - Procédés et agencements pour un cadre d'applications de système - Google Patents

Procédés et agencements pour un cadre d'applications de système Download PDF

Info

Publication number
WO2025014819A1
WO2025014819A1 PCT/US2024/036927 US2024036927W WO2025014819A1 WO 2025014819 A1 WO2025014819 A1 WO 2025014819A1 US 2024036927 W US2024036927 W US 2024036927W WO 2025014819 A1 WO2025014819 A1 WO 2025014819A1
Authority
WO
WIPO (PCT)
Prior art keywords
network
data
services
service
communications network
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
PCT/US2024/036927
Other languages
English (en)
Inventor
Yizhi Yao
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
Publication of WO2025014819A1 publication Critical patent/WO2025014819A1/fr
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/04Network management architectures or arrangements
    • H04L41/044Network management architectures or arrangements comprising hierarchical management structures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • H04L41/0803Configuration setting
    • H04L41/0806Configuration setting for initial configuration or provisioning, e.g. plug-and-play
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14Network analysis or design
    • H04L41/145Network analysis or design involving simulating, designing, planning or modelling of a network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/40Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities

Definitions

  • the cellular industry has been striving to incorporate intelligence into cellular networks.
  • the intelligence may include, c.g., artificial intelligence (Al) and machine learning (ML) based intelligence.
  • Al artificial intelligence
  • ML machine learning
  • KPI key performance indicator
  • FIG. 1A depicts an embodiment of a system including framework logic circuitry for next- generation system management and orchestration of a communications system;
  • FIG. IB depicts an embodiment of a communications system
  • FIG. 1C illustrates another embodiment of a communications system
  • FIGs. 2A-2B illustrates other embodiments of a communications system
  • FIGs. 3A-3D illustrates alternative embodiments for implementation of management services
  • FIGs. 3E-3G illustrates embodiments for management scope, workflow, and categories for managing autonomy in communications systems
  • FIGs. 3H-3I illustrates embodiments for machine learning models for intelligence and autonomy management in communications systems
  • FIG. 4 illustrates an embodiment of artificial (Al)-assisted communication between a user equipment (UE) and a radio access node (RAN) for intelligence and autonomy management in communications systems;
  • UE user equipment
  • RAN radio access node
  • FIG. 5 depicts an embodiment of a block diagram of a base station and a user equipment for intelligence and autonomy management in communications systems
  • FIGs. 6-7 depicts flowcharts of different embodiments for intelligence and autonomy management in communications systems
  • FIG. 8 depicts an embodiment of protocol entities for wireless communication devices
  • FIG. 9 illustrates embodiments of the formats of PHY data units
  • FIGs. 10A-B depicts embodiments of communication circuitry for devices in a communications system
  • FIG. 11 depicts an embodiment of a storage medium
  • FIG. 12 illustrates an embodiment of an architecture of a communications system
  • FIG. 13 illustrates an embodiment of components of a device in a communications system
  • FIG. 14 illustrates an embodiment of interfaces of baseband circuitry in a communications system
  • FIG. 15 depicts an embodiment of a block diagram of components to perform functionality described.
  • the next-generation system (e.g., sixth generation (6G) and beyond) is expected to be an intelligent and autonomous system.
  • the intelligence may empower the system to achieve higher performance and support extended capabilities.
  • the autonomy may enable the operations to be more efficient, systematic, and automated. Furthermore, the autonomy may advantageously reduce the operating expenditures (OpEx).
  • the system- wide intelligence and autonomy has two aspects - 1) the intelligence and autonomy embedded into the managed system/network, and 2) the intelligence and autonomy enabled by the management system.
  • Embodiments herein focus on the framework of the management system to enable intelligence and autonomy in the next-generation system.
  • Embodiments may provide a framework of architectural principles and requirements for next-generation intelligence and autonomous systems, including capabilities, enablers, and services associated with network automation and autonomous systems.
  • the autonomous systems discussed herein provide end-to- end (e2e) network automation beyond conventional/simple automation where human intervention is required for system and service configuration and operation.
  • the journey from simple automation to an autonomous system e.g., “zero-touch automation”
  • is based on a continuously emerging service paradigm which is enabled through a service-based framework of virtualization, cognitive awareness, and flexible levels of distribution.
  • framework logic circuitry to enable intelligence and autonomy in next-generation systems.
  • the framework logic circuitry enables intelligence and autonomy for the next-generation system, which may provide various benefits/advantages such as, for example, improved resilience, improved communication speeds, network resource efficiencies/optimizations (e.g., in terms of power, energy consumption, and/or the like), among many other benefits/advantages.
  • a network function is a processing function in a network that has defined functional behavior and interfaces.
  • a network function can be implemented either as a network element on dedicated hardware, as a software instance running on dedicated hardware, or as a virtualized function instantiated on an appropriate platform.
  • Dedicated hardware may include, e.g., user equipment (UE), base station or radio access network (RAN), a packet data network gateway (PGW), a serving gateway (SGW), mobility management entity (MME), home subscriber server (HSS), user plane function (UPF), unified data repository (UDM), other communications network hardware element, and/or the like.
  • An appropriate platform may include, e.g., a server, a laptop, a workstation, a tablet, other processing device, and/or the like, with hardware to virtualize one or more network functions.
  • Various embodiments may be designed to address different technical problems associated lack of autonomy for issue resolution or problem-solving, level of autonomy in planning for network and service management, level of autonomy in simulation for network and service management, level of autonomy in establishment and reconfiguration of network functions, lack of emulation capabilities, lack of access to tools for training ML models, lack of access to realtime or historical data for training ML models, lack of autonomy in optimization and healing, lack of emulation capabilities for communications network, lack of knowledge preservation for issues and resolutions, and/or the like.
  • Embodiments may address one or more of these problems associated with lack of intelligence and autonomy in communications network. For instance, some embodiments that address problems associated with lack of intelligence and autonomy in communications network may do so by one or more different technical means, such as, providing components with tools for software as a service, providing component for intelligence and autonomy, providing components for training ML models, providing components for emulation of ML models with real-time data and/or historical data; providing components for cloud system orchestration; providing components for knowledge creation and sharing; providing components for emulating the communications network; and/or the like.
  • Several embodiments comprise systems with multiple processor cores such as central servers, access points, and/or stations (STAs) such as modems, routers, switches, servers, workstations, netbooks, mobile devices (Laptop, Smart Phone, Tablet, and the like), sensors, meters, controls, instruments, monitors, home or office appliances, Internet of Things (loT) gear (watches, glasses, headphones, cameras, and the like), and the like.
  • STAs stations
  • Some embodiments may provide, e.g., indoor and/or outdoor “smart” grid and sensor services.
  • these devices relate to specific applications such as healthcare, home, commercial office and retail, security, and industrial automation and monitoring applications, as well as vehicle applications (automobiles, self-driving vehicles, airplanes, drones, vehicle-to-vehicle (V2V), vehicle-to- everything (V2X), and the like), and the like), and the like.
  • vehicle applications autonomouss, self-driving vehicles, airplanes, drones, vehicle-to-vehicle (V2V), vehicle-to- everything (V2X), and the like
  • the techniques disclosed herein may involve transmission of data over one or more wireless connections using one or more wireless mobile broadband technologies.
  • various embodiments may involve transmissions over one or more wireless connections according to one or more 3rd Generation Partnership Project (3GPP), 3GPP Long Term Evolution (LTE), 3GPP LTE-Advanced (LTE-A), 4G LTE, 5G New Radio (NR) and/or 6G, technologies and/or standards, including their revisions, progeny and variants.
  • 3GPP 3rd Generation Partnership Project
  • LTE Long Term Evolution
  • LTE-A 3GPP LTE-Advanced
  • 4G LTE Long Term Evolution
  • NR 5G New Radio
  • 6G technologies and/or standards, including their revisions, progeny and variants.
  • GSM Global System for Mobile Communications
  • EDGE Universal Mobile Telecommunications System
  • UMTS Universal Mobile Telecommunications System
  • HSPA High Speed Packet Access
  • GSM/GPRS GSM with General Packet Radio Service
  • wireless mobile broadband technologies and/or standards may also include, without limitation, any of the Institute of Electrical and Electronics Engineers (IEEE) 802.16 wireless broadband standards such as IEEE 802.16m and/or 802.16p, International Mobile Telecommunications Advanced (IMT-ADV), Worldwide Interoperability for Microwave Access (WiMAX) and/or WiMAX II, Code Division Multiple Access (CDMA) 2000 (e.g., CDMA2000 IxRTT, CDMA2000 EV-DO, CDMA EV-DV, and so forth), High Performance Radio Metropolitan Area Network (HIPERMAN), Wireless Broadband (WiBro), High Speed Downlink Packet Access (HSDPA), High Speed Orthogonal Frequency-Division Multiplexing (OFDM) Packet Access (HSOPA), High-Speed Uplink Packet Access (HSUPA) technologies and/or standards, including their revisions, progeny and variants.
  • IEEE 802.16 wireless broadband standards such as IEEE 802.16m and/or 802.16p, International Mobile Telecommunications Advanced (I
  • Some embodiments may additionally perform wireless communications according to other wireless communications technologies and/or standards.
  • Examples of other wireless communications technologies and/or standards that may be used in various embodiments may include, without limitation, other IEEE wireless communication standards such as the IEEE 802.11-5220, IEEE 802.1 lax-5221, IEEE 802.1 lay-5221, IEEE 802.1 lba-5221, and/or other specifications and standards, such as specifications developed by the Wi-Fi Alliance (WFA) Neighbor Awareness Networking (NAN) Task Group, machine-type communications (MTC) standards such as those embodied in 3GPP Technical Report (TR) 23.887, 3GPP Technical Specification (TS) 22.368, 3GPP TS 23.682, 3GPP TS 36.133, 3GPP TS 36.306, 3GPP TS 36.321, 3GPP TS.331, 3GPP TS 38.133, 3GPP TS 38.306, 3GPP TS 38.321, 38.214, and/or 3GPP TS 38.331 ,
  • FIG. 1A illustrates a next-generation management and orchestration system including framework logic circuitry 100 to provide intelligence and autonomy to a communications system such as a sixth generation (6G) network 180A including services and infrastructure thereof via an interface 182A such as a SGi interface, a N6 interface, a N6’ interface, and/or the like.
  • a communications system such as a sixth generation (6G) network 180A including services and infrastructure thereof via an interface 182A such as a SGi interface, a N6 interface, a N6’ interface, and/or the like.
  • 6G sixth generation
  • the framework logic circuitry 100 comprises at least one component (also referred to as sub-systems, parts, planes, domains, elements, entities, functions, network functions (NFs), engines, nodes, and/or the like) for one or more of the following management and orchestration capabilities via a network and service management and orchestration 110A component; AI/ML operations 130A component; data management 140A component; cloud system orchestration 150A component; knowledge management 160A component, and digital twin 170A component.
  • the cloud system orchestration 150A component may include an edge network/system orchestration component to support edge computing technologies, such as any of those discussed herein.
  • the network and service management and orchestration 110A component may manage and orchestrate any one or more stages of development (planning 111A, simulation 112A, and emulation 113A), deployment (establishment 114A and configuration 115A), optimization 116A, and maintenance (healing 117A and protection 118A) of network and service management.
  • the network and service management and orchestration 110A component may implement a workflow for intelligence and autonomy 120A for the 6G network 180A including observation 122A, analytics 124A, decision 126A, and execution 128A.
  • the workflow for intelligence and autonomy 120A may be applied to any one or more of stages or sub- stages of development, deployment, optimization, and maintenance of network and service management.
  • intelligence and autonomy may be achieved by one or more iterations of the workflow of observation 122A, analytics 124A, decision 126A, and execution 128A.
  • Each element in the workflow may consume the capabilities or services provided by another component such as the AI/ML operations 130A component; data management 140A component; cloud system orchestration 150A component; knowledge management 160A component, and digital twin 170A component.
  • the workflow for the intelligence and autonomy 120 A component may be an open loop with minimal human intervention (not or minimal autonomy) or a closed loop without human intervention (full autonomy), or levels of autonomy between the open loop and the closed loop, depending on the goal or target of the network or service management.
  • a management function may involve usage of communications system resources for data collection and data analytics in a subsystem of the communications system.
  • the subsystem may be, e.g., a geographical area having a network of one or more base stations or radio access nodes, access points, and UEs.
  • the framework logic circuitry 100 may determine whether the resources available in the subsystem can perform the MnF in conjunction with existing services, resources can become available through adjustment of current resource allocations within the subsystem, or resources can become available by shifting, e.g., computing resources via the cloud system 150A. If the resources are or can become available, the framework logic circuitry 100 may establish and manage the MnF autonomously.
  • the framework logic circuitry 100 may determine additional radio access nodes, access points, and UEs to locate within the subsystem for deployment of the MnF. In such embodiments, the framework logic circuitry 100 may generate a report for and communicate the report to an operator or consumer 184A with specification as to the additional network elements or platforms to locate within the subsystem. In some embodiments, the framework logic circuitry 100 may include, with a level of specificity, where to locate the additional network elements or platforms.
  • the observation (awareness) 122A element may comprise a group of tasks that include network and service data (e.g., configuration data, performance data, alarm data, etc.) collection and necessary data pre-processing (e.g., data cleaning, filtering, statistics, etc.) with the purpose of monitoring network and service information (including network and service performance, network and service anomaly, network and service event, etc.).
  • network and service data e.g., configuration data, performance data, alarm data, etc.
  • necessary data pre-processing e.g., data cleaning, filtering, statistics, etc.
  • the analytics 124A element may comprise a group of tasks that analyze the obtained network and service information (e.g., network and service status, network and service issues, and so on) or based on the historical network and service information to further predict the future change trend of the above network and service status, and make recommendation for decision.
  • the decision 126A element may comprise a group of tasks that evaluate and decide the necessary operation for execution (c.g., network configuration or adjustment).
  • the execution 128A element may comprise a group of tasks which execute the operations and/or determine network and service information to monitor performance of the network and service during execution.
  • the planning 111A stage may be a first phase or first stage for autonomous generation of a management service.
  • the framework logic circuitry 100 may define the data to be observed via observation 122A, the data analytics to perform with the data via analytics 124A, the supporting factors for making a decision and capture the decision via decision 126A, and how to monitor the results of the decision via execution 128A.
  • an issue with or service for a subsystem of the communications system may be identified by an existing model such as a mathematical model or an AI/MI. model based on processing data from the communications system.
  • the issue or service may be presented to the framework logic circuitry 100 by an operator or consumer 184A from within the communications network via interface 182A or from a network external to the communications network via an interface 185A, e.g., an application program interface.
  • the observation 122A of the framework logic circuity 100 may access the knowledge management 160A component to query a knowledge data structure to determine if the knowledge data structure includes a solution related to the issue or service.
  • the issue or service may relate to, e.g., locating a new business or residential development within a geographical area.
  • the knowledge management 160A may comprise data collection and data analytics related to a previous process for locating a business in another area of the communications system.
  • the knowledge data structure may comprise information such as definitions for observation 122A, analytics 124A, decision 126A, and execution 128A for various phases or stages such as planning 111A, simulation 112A, emulation 113A, establishment, 114A, configuration 115A, optimization 116A, healing 117A, protection 118A, and/or any other stages or phases of development of management and orchestration of the communications network and service management.
  • the framework logic circuitry 100 may comprise service-based components, which means each component provides services (e.g., management services) which can be consumed by another component internally or by a consumer or operator via an interface 185 A, e.g., an application program interface (API).
  • the components may include the network and service management and orchestration 110A component, the AI/ML operations 130A component, the data management 140A component the cloud system orchestration 150A component, the knowledge management 160 A component, the digital twin 170 A component, and/ or other components.
  • the framework logic circuity 100 may determine the population in the geographical area of the subsystem and a characterization of the traffic in the geographical area of the subsystem (e.g., residential traffic and/or business traffic). For instance, the planning 111A stage may involve locating a new bus station within the geographical area.
  • the observation 122A stage may interact with the data management 140A to collect data, clean the data, classify the data, filter the data, and aggregate the data related to the population and the services provided for residential service and business service, for the planning 111A stage of the network and service management and orchestration 110A component.
  • the data management 140A component provides the capabilities for managing data related to communication systems such as next generation systems including, for example, data collection, data classification, data cleaning, data storing, data sharing, data analytics, data correlation, data aggregation, and/or data exposure.
  • the data exposure may involve exposing data to a consumer or operator.
  • the data sharing may involve sharing data such as processed data such ML models or components of the framework logic circuitry 100 can access the data without repeating the same actions to process the data.
  • the data can be current data and/or historical data.
  • the data can be raw data and/or processed data.
  • Examples of the types of data to be managed can include network resource models, performance measurements, key performance indicators (KPIs), QoS data, QoE data, minimization drive test (MDT) data, trace data, telemetry data, alarms, event notifications or reports, UE measurements, analytics reports, user subscription data, service level specification (SLS) data, service level agreement (SLA) data, external service parameters, configuration data, resource information, environmental information, and/or any other type of data, such as any of those discussed herein.
  • the data may be relevant to infrastructure, virtual resources, platforms, system functions, network functions, management functions, and/or applications.
  • the data may be processed and/or stored in a centralized or distributed way in one or more data storage devices 142A such as data servers in one or more types of data structures.
  • System functions may include the entire architecture and functionality of the communications system.
  • Network functions may include specific processing functions within the network with well-defined behavior and interfaces.
  • Management functions may include functions to manage the operation, configuration, and maintenance of the network including management of network functions. Management functions may ensure efficient resource utilization and optimal performance.
  • the planning 111A stage may access the analytics 124 A to determine a number of base stations, access points, UEs, and/or other resources for the geographical that can provide coverage and be deployed for servicing the new bus station.
  • the UEs may include both mobile devices such as cell phones and also fixed or stationary UEs such as UEs that customers may use for subscribing to communications network services such as Internet services, cloud computing services, edge services, and/or the like.
  • the framework logic circuitry 100 may manage cell resources, base station resources, and/or access point resources associated with the UEs, access points, and base stations. For example, if the devices geographically reside, temporarily or permanently, within service area of more than one access points, base stations, and/or cells of the communications network, the resources may be load-balanced to improve performance.
  • the analytics 124A element may access the data management 140A component to perform data analysis to determine the existing resource usage and the potential resource usage for the new bus station including a determination of computing resources, based on the potential resource usage, the resource capacity and frequency bands needed to deploy for servicing the bus station.
  • the analytics 124A element may access the knowledge management 160A component to query the knowledge data structure for and obtain, if applicable, models such as mathematical models and/or AI/ML models related to deploying services for a new business or more specifically, for a new bus station.
  • the analytics 124A element may interact with the cloud system orchestration 150A component to determine workload distribution of system functions, network functions, management functions, and/or applications for servicing the new bus station, based on the potential resource usage, and the resource capacity needed to deploy for servicing the bus station.
  • the analytics 124A element may access the data management 140A component to perform data analytics, data correlation, and data aggregation.
  • the analytics 124A element may access the AI/ML operations 130A component to perform ML training, ML testing, ML emulation, ML model deployment, and/or AI/ML inference to generate and/or deploy a ML model such as a new model or a model shared from the knowledge management 160A component.
  • the cloud system orchestration 150A component provides the capabilities for managing the cloud system, which offers cloud services to system functions and/or user applications. For instance, the cloud system orchestration 150A component may determine the hardware resources or computing resources with which to deploy a user application.
  • the cloud system may be based on virtual machines and/or containers.
  • the cloud system includes one or more cloud compute nodes (e.g., various servers in one or more datacenters and/or the like) and/or one or more edge compute nodes.
  • the cloud system orchestration 150A component includes compute and storage resource registration and discovery, system function or application deployment in the cloud, monitoring of the performance of and/or healthiness of the cloud system (e.g., infrastructure, resources, platforms, system functions, applications), analytics of observed data for the cloud system, healing of system functions/applications, scaling, workload distribution of the system functions/applications, snapshot management of the system functions/applications, backup of the system functions/applications, restoration of the system functions/applications, replication of the system functions and/or applications, software as a service to consumers or operators to offer access to tools of one or more or all components of the framework logic circuitry 100, and security and privacy protection for data accessed and processed by computing resources in the cloud system of the cloud system orchestration 150A component.
  • the cloud system orchestration 150A component may also provide some specific software as service (SaaS), for example, the tool for ML training, and ML emulation.
  • SaaS software as service
  • the cloud system orchestration 150A component may provide access to a consumer or operator 184A, via an interface 185 A, one or more predefined tools for ML training 132A, testing 133 A, emulation 134A, deployment 135 A, and inference 136A via the AI/ML operations 130A component.
  • the AI/ML operations 130A component may receive and use consumer or operator 184A defined training data or may access the data management 140A component to obtain data for the user to train the ML model such as real-time data or historical data from the communications system or from an emulation of the communications system by a digital twin copy via the digital twin 170A component.
  • the cloud system orchestration 150A component may also support security and privacy protection when providing the orchestration capabilities.
  • the management and orchestration capabilities include an edge network/system orchestration component to support edge computing technologies
  • the edge network/system orchestration component may include similar functionality as the cloud system orchestration 150A component.
  • the planning 111A stage may access the decision 126A element to determine which base stations having coverage for the geographical area to deploy for the new bus station as well as the resource capacity for each cell, access point, and UE and resource capacity for computing services to deploy for servicing the new bus station.
  • the decision 126A element may access the knowledge management 160A component to query the knowledge data structure for and obtain, if applicable, models such as mathematical models and/or AI/ML models related to deploying services for a new business or more specifically, for a new bus station.
  • the knowledge management 160A component may provide the capabilities to manage knowledge in. e.g., one or more knowledge data structures.
  • the knowledge may be generated by the framework logic circuitry 100 from the operating experience, and data analysis/inference.
  • the knowledge may support a specific kind of use case and may be consumed by a consumer and reapplied to another system (or sub-system of the communications network or another communications network) for a similar use case.
  • the knowledge may include which types of data is used for solving a particular problem or which model provides better solutions for a particular usage.
  • the knowledge may be generated, created, accessed, retrieved, updated, and/or shared using various mechanisms, interfaces, and/or techniques with other components of the framework logic circuitry 100 and, in some embodiments, with components of other networks.
  • the decision 126A element may also determine the parameters and configurations for system functions, management functions, and network functions of the base stations, access points, and UEs to allocate to ULs and DLs for servicing the traffic that will be generated by the new bus station.
  • the geographical area of the bus station may reside within the geographical coverage area of two or more base stations and have multiple access points within the geographical area.
  • the decision 126A clement may determine allocations of computing resources to allocate for the new service and how to interconnect the computing resources.
  • the decision 126A element may determine allocations of computing resources based on interaction with the AI/ML operations 130A component to create, train, and infer with a new model or infer with an existing model shared from the knowledge management 160A component.
  • the decision 126 A element may access data management 140A component and/or cloud system orchestration 150A component to determine resource allocations based on an existing mathematical model deployed in the data management component 140A component or within the cloud system orchestrations 150A component. Furthermore, the decision 126A element may access data management 140A component and/or cloud system orchestration 150A component to deploy an existing model shared from the knowledge management 160A component for determination of resource allocations for a new business or a new bus station.
  • the decision 126A element may determine allocations of resources between the access points and the base stations to UL and DL data between business and/or residential UEs existing in the geographical area as well as new UEs that may be installed within the bus station.
  • the allocations of the resources may accommodate new traffic created by the installation of the new bus station as well as existing traffic in the geographical area.
  • the execution 128A element may determine data to collect, data analytics, and decision criterion to monitor the performance of the planned resource allocations.
  • the decision 126 A element may access the knowledge management I60A component to query a knowledge data structure for a mathematical model, an AI/ML model, or for one or more policies or rules related to execute for determining the deployment of the resources from one or more of the base stations, access points, UEs, and computing resources.
  • the decision 126A element may access the cloud system orchestration 150A component to access an existing model for determining the deployment of the computing resources for one or more of the base stations, access points, and/or UEs.
  • the simulation 112A stage may be a second phase or stage of development of a service.
  • the simulation 112A stage may simulate aspects of the service of the new bus station to test and possibly refine aspects of the planning.
  • the observation 122A element may collect the data from the simulation determined by the planning 111A stage to monitor the performance of the planned resource allocations via a simulation of the resources available and possibly existing resource allocations.
  • the analytics 124A element may analyze the performance data through inference by an AI/ML model via AI/ML operations 130A component, by data analysis via the data management 140A component, by a model deployed in a cloud system via the cloud system orchestration 150A component, and/or by a model shared from the knowledge management 160A component.
  • the decision 126 A element may determine, via access to services offered by AI/ML operations 130A component, data management 140A component, cloud system orchestration 150A component, knowledge management 160A component, and/or digital twin 170A component, adjustments or changes to the allocation of resources determined during the planning 111A stage to improve the allocation of resources.
  • the execution 128A element may determine via access to services offered by AI/ML operations 130A component, data management 140A component, cloud system orchestration 150A component, knowledge management 160A component, and/or digital twin 170A component, adjustments to parameters, configurations, and other for system functions, management functions, network functions, and applications based on performance during the simulation, of resource allocations for establishing services for the new bus station.
  • any project from deployment of a new network device such as a UE, an access point, or a base station for government, business, or residential use or deployment of a new service for government, business, or residential use may be planned, simulated, emulated, established, configured, optimized, healed, and protected via the intelligence and autonomy 120A workflow.
  • Each stage may involve interaction with one or more of the services offered by AI/ML operations 130A component, data management 140A component, cloud system orchestration 150A component, knowledge management 160A component, and/or digital twin 170 A component, and may operate at one or more levels of autonomy from an open loop (no or minimal autonomy) to a closed loop (full autonomy) with the exception of physical deployment of new devices.
  • the emulation 113A stage may perform an emulation of the resource allocations determined from the planning 111A stage or the simulation 112A stage.
  • the emulation 113A stage may differ from the simulation 112A stage based on use of a digital twin 170A component to emulate each network device (system function, management function, network function, and/or application), and service of the communications network based on real-time and/or historical data.
  • the data management 140A component may store real-time and/or historical data related to resource allocations, communications, and traffic in the communications system in one or more storage devices 142 A of the data management 140A component.
  • the emulation 113A stage may access models of each of the devices (system function, management function, network function, and/or application) of the communications network via the digital twin 170A component and monitor the impact of the resource allocations for the new services based on resources available to each of the devices in the communications network in accordance with real-time and/or historical data.
  • the digital twin 170 A component of the framework logic circuitry 100 may provide capabilities for providing the digital twin copy or representation of the communications system such as the 6G network 180A.
  • the digital twin 170A component may monitor and manage the communication system via a digital twin copy or representation.
  • the digital twin copy or representation is represented by the extended or enhanced network resource models (NRMs) of the communications system, together with the data for monitoring the status and events based on the NRMs.
  • the digital twin copy or representation provides a more complete view of the system than a simulation, including the environment and the resources, with the capabilities for monitoring the real-time status of the digital twin of the communications system.
  • the digital twin 170A component may include a representation of a real system that provides real network or services, and/or an emulation system that may be partitioned from the real system but does not impact the real services. In many embodiments, the digital twin 170A component also provides the capability that does not impact the real network or services during emulation of new functionalities, features, and services.
  • the digital twin 170A component may offer services including, e.g., representing the system or part of the system via a digital twin copy and running the services such as MnSs, system functions, management functions, network functions, applications, ML models, mathematical models, or the like on the digital twin.
  • the establishment 114A stage may deploy configurations, parameters, and the like for services, system functions, management functions, network functions, applications, ML models, and/or mathematical models from the planning 111A stage, the simulation 112A stage, or the emulation 113A stage to the services, system functions, management functions, network functions, applications, ML models, and/or mathematical models of devices of the communications network to deploy the service for the new bus station.
  • the configuration 115A stage may involve a situation in which a request is made to increase the capacity or capabilities of the communications network available in the geographical area about the new bus station accompanied by some data as an indication of the need for the increase in capacity or capabilities.
  • the planning 111A stage may have planned the resources for the new bus station with an assumption or determination that the likely number of users is 2000 users.
  • a consumer may request that the framework logic circuitry 100 increase the resources to accommodate 3000 users.
  • the configuration 115A stage may perform one or more iterations of the intelligence and autonomy 120A workflow to observe data related to the existing use of resources for 2000 users via access to real-time or historical data from the data management 140A component and perform data analytics to determine to determine a number of base stations, access points, UEs, and/or other resources for the geographical that can provide coverage and be deployed for servicing. Based on the increase to 3000 users and the traffic data, the configuration 115A stage may also determine a number of base stations, access points, UEs, and/or other resources for the geographical that can provide coverage and be deployed for servicing the bus station.
  • the analytics 124A element may access the data management 140A component to perform data analysis to determine the existing resource usage and the potential resource usage for the new bus station including a determination of computing resources, based on the potential resource usage, the resource capacity and frequency bands needed to deploy for servicing the bus station.
  • the decision 126 A element may determine, via access to services offered by AT/ML operations 130A component, data management 140 A component, cloud system orchestration 150A component, knowledge management 160A component, and/or digital twin 170A component, adjustments or changes to the allocation of resources to increase the allocation of resources for the increased number of users.
  • the execution 128 A element may determine via access to services offered by AI/ML operations 130A component, data management 140A component, cloud system orchestration 150A component, knowledge management 160A component, and/or digital twin 170A component, adjustments to parameters, configurations, and other for services, system functions, management functions, network functions, applications, ML models, and/or mathematical models to increase the resource allocations.
  • the optimization 116A stage may be initiated when the communications system or the digital twin 170A component detects issues such as an excessive number of bit errors, handover failures, or coverage issues.
  • the communications system or the digital twin 170A component may communicate the issue to the framework logic circuitry 100 along with data related to the excessive number of bit errors, handover failures, or coverage issues.
  • the framework logic circuitry 100 may perform one or more iterations of the intelligence and autonomy 120A workflow of observation 122A, analytics 124A, decision 126A, and execution 128A to determine adjustments or changes to configurations, parameters, resource allocations, and/or the like for services, system functions, management functions, network functions, applications, ML models, and/or mathematical models to address the issue.
  • the optimization 116A stage may access the historical data and/or real-time data, determine changes to the parameters, configurations, resource allocations, and/or the like. Further, the optimization 116A stage may interact with the digital twin 170A to deploy the changes to the configurations, parameters, resource allocations, and/or the like to services, system functions, management functions, network functions, applications, ML models, and/or mathematical models of models of the devices of the communications network to emulate the communications system in the digital twin 170A component and monitor the effects of the changes.
  • the framework logic circuitry 100 may determine that that issue is resolved. In some embodiments, the framework logic circuitry 100 may share the knowledge related to the issue and the resolution with the knowledge management 170A component to store the issue and resolution for subsequent access.
  • the optimization 116A stage may determine to adjust, e.g., increase, the handover time frame, increase the number of allowable hand-over attempts, increase the hand-over guard timer, and/or the like to reduce the number of hand-over failures.
  • the optimization 116A stage may determine to adjust the configuration for the antennas to compensate for the bad coverage.
  • the framework logic circuitry 100 may share the issue and resolution with the knowledge management 160A component.
  • the optimization 116A stage may determine that the prior resolution was not sufficient, perform the intelligence and autonomy 120 A workflow, and determine an updated solution. In such embodiments, the optimization 116A stage may share the updated solution for the handover failure issue with the knowledge management 160A component to update the solution in the knowledge data structure.
  • the framework logic circuitry 100 may determine that the solution to an issue cannot be resolved through software-based solutions and may send an indication or message to an operator or consumer 184A to indicate that, e.g., installation of a new device such as a base station, access point, or UE may be the correct solution to the resolve the issue.
  • the indication may also include a location for the new device.
  • the healing 117A stage may be initiated as a result of a fault in software of one or more devices that prevents the device from operating normally or the hardware has failed.
  • the communications system may send a report to the framework logic circuitry 100 to describe the issue.
  • the healing 117A stage may switch operation by the device to a backup software install a backup of the software on the device.
  • the healing 117 A stage may initiate the intelligence and autonomy 120A workflow to determine new parameters, configurations, resource allocations, and the like, to shift the workload of the device (e.g., network element) with the failed hardware to one or more other devices (e.g., other network elements) available to handle the workload as a temporary solution until the failed device is repaired or replaced.
  • the protection 118 A stage may be initiated to limit access to communications within communications to some users. In such embodiments, the protection 118A stage may limit access to communications to specified radio resources and to specified computing resources.
  • AI/ML operations 130A component may provide the capabilities of AI/ML operations and management to enable AI/ML in communication systems such as next-generation systems, including the system/network functions, management functions, and applications.
  • the capabilities for AI/ML operations 130A component are provided for some or all phases of the AI/ML operational workflow, including ML training, ML testing, ML emulation, ML model deployment, and AI/ML inference.
  • the AI/ML operations 130A component may provide generic and specific capabilities to operate and manage various kinds of learning methods and/or AI/ML techniques, such as supervised learning, unsupervised learning, deep learning, reinforcement learning, federated learning, and/or the like. Examples of the learning methods and/or AI/ML techniques are discussed in conjunction with FIGs. 3H and 31 and/or discussed elsewhere herein.
  • the AI/ML operations 130A component may enable flexible deployment scenarios, such as centralized training, distributed training, online training, and facilitates the AI/ML to be used on complex and simple tasks.
  • the framework logic circuitry 100 may include functionality for labeling data autonomously. In other embodiments, the data labeling may occur with some human input.
  • ML algorithms perform a training process on a training dataset to estimate an underlying ML model.
  • An ML algorithm is a computer program that learns from experience with respect to some task(s) and some performance measure(s)/metric(s), and an ML model is an object or data structure created after an ML algorithm is trained with training data.
  • the term “ML model” or “model” may describe the output of an ML algorithm that is trained with training data.
  • the model may be tested (such as testing 133 A) with a second set of data that is typically distinct from the training data, referred to herein as testing data.
  • testing data may be collected and maintained by the data management system such as data management 140A.
  • a set of data from the communications system may be split into training data to train the ML model with supervision and then may be tested with the testing data to determine the precision and accuracy of predictions made by the ML model. In some embodiments, this is an iterative process performed until the ML model makes predictions with a threshold of precision and accuracy.
  • the ML model may be tested further through emulation such as emulation 134A.
  • emulation 134A the AI/ML operations 130A component may interact with the digital twin 170A and the data management 140A component to emulate operation or performance of the ML model in one or more devices with real-time data and/or historical data from the communications system or a digital twin copy of the communications system.
  • the ML model may be deployed (such as deployment 135 A) via interaction with the network and service management and orchestration 110A component of the framework logic circuitry 100. After deployment, the ML model may be used to make predictions on new datasets. Additionally, separately trained AI/ML models can be chained together in an AI/ML pipeline during inference or prediction generation.
  • ML algorithm refers to different concepts than the term “ML model,” these terms may be used interchangeably for the purposes of the present disclosure. Any of the ML techniques discussed herein may be utilized, in whole or in part, and variants and/or combinations thereof, for any of the example embodiments discussed herein.
  • ML may require, among other things, obtaining and cleaning a dataset via interaction with the data management 140A component, performing feature selection, selecting an ML algorithm, dividing the dataset into training data and testing data, training a model (e.g., using the selected ML algorithm), testing the model, optimizing or tuning the model, and determining metrics for the model. Some of these tasks may be optional or omitted depending on the use case and/or the implementation used.
  • Model parameters are parameters, values, characteristics, configuration variables, and/or properties that are learnt during training. Model parameters are usually required by a model when making predictions, and their values define the skill of the model on a particular problem.
  • Hyperparameters are characteristics, properties, and/or parameters for an ML process that cannot be learnt during a training process. Hypcrparamctcr arc usually set before training takes place and may be used in processes to help estimate model parameters.
  • ML techniques generally fall into the following main types of learning problem categories: supervised learning, unsupervised learning, and reinforcement learning.
  • Supervised learning involves building models from a set of data that contains both the inputs and the desired outputs.
  • Unsupervised learning is an ML task that aims to learn a function to describe a hidden structure from unlabeled data.
  • Unsupervised learning involves building models from a set of data that contains only inputs and no desired output labels.
  • Reinforcement learning (RL) is a goal-oriented learning technique where an RL agent aims to optimize a long-term objective by interacting with an environment.
  • FIG. IB illustrates a communications network 190 such as the 6G network 180A shown in FIG. 1A.
  • the communication network 190 is an Orthogonal Frequency Division Multiplex (OFDM) network comprising a primary base station 191, a secondary base station 192, a cloudbased service 193, a first user equipment UE-1, a second user equipment UE-2, and a third user equipment UE-3.
  • OFDM Orthogonal Frequency Division Multiplex
  • the radio resource is partitioned into subframes in time domain and each subframe comprises of two slots.
  • Each OFDMA symbol further consists of a count of OFDMA subcarriers in frequency domain depending on the system (or carrier) bandwidth.
  • Resource Element which spans an OFDMA subcarrier over one OFDMA symbol.
  • Resource blocks comprise a group of REs, where each RB may comprise, e.g., 12 consecutive subcarriers in one slot.
  • the Physical Downlink Shared Channel (PDSCH) is the main data-bearing downlink channel, while the Physical Downlink Control Channel (PDCCH) may carry downlink control information (DCI).
  • the control information may include scheduling decision, information related to reference signal information, rules forming the corresponding transport block (TB) to be earned by PDSCH, and power control command.
  • UEs may use cell-specific reference signals (CRS) for the demodulation of control/data channels in non-precoded or codebook-based precoded transmission modes, radio link monitoring and measurements of channel state information (CSI) feedback.
  • CSI channel state information
  • UEs may use UE-specific reference signals (DM-RS) for the demodulation of control/data channels in non-codcbook-bascd preceded transmission modes.
  • the communication network 190 may comprise a cell such as a micro-cell or a macro-cell and the base station 191 may provide wireless service to UEs within the cell.
  • the base station 192 may provide wireless service to UEs within another cell located adjacent to or overlapping the cell.
  • the communication network 190 may comprise a macro-cell and the base station 192 may operate a smaller cell within the macro-cell such as a micro-cell or a picocell.
  • Other examples of a small cell may include, without limitation, a micro-cell, a femtocell, or another type of smaller- sized cell.
  • the base station 191 and the base station 192 may communicate over a backhaul.
  • the backhaul may comprise a wired backhaul.
  • backhaul may comprise a wireless backhaul.
  • the backhaul may comprise an Xn interface or a Fl interface, which are interfaces defined between two RAN nodes or base stations such as the backhaul between the base station 191 and the base station 192.
  • the Xn interface is an interface for gNBs
  • the Fl interface is an interface for gNB- Distributed units (DUs) if the architecture of the communication network 190 is a central unit / distributed unit (CU/DU) architecture.
  • the base station 191 may comprise a CU and the base station 192 may comprise a DU in some embodiments.
  • both the base stations 191 and 192 may comprise eNBs or gNBs.
  • the base stations 191 and 192 may communicate protocol data units (PDUs) via the backhaul.
  • PDUs protocol data units
  • the base station 191 may transmit or share control plane PDUs via an Xn-C interface and may transmit or share data PDUs via a Xn-U interface.
  • the base station 191 may transmit or share control plane PDUs via an Fl-C interface and may transmit or share data PDUs via a Fl-U interface.
  • signaling, sharing, receiving, or transmitting via a Xn interface may refer to signaling, sharing, receiving, or transmitting via the Xn-C interface, the Xn-U interface, or a combination thereof.
  • all communications, signaling, sharing, receiving, and transmitting involves resources that may be configured via the framework logic circuitry such as the framework logic circuitry 100 shown in FIG. 1A.
  • the base stations 191 and 192 and UEs may comprise framework logic circuitry to install configurations, parameters, models such as ML models through interaction with system management and orchestration such as the framework logic circuitry 100 shown in FIG. 1A.
  • the framework logic circuitry 100 may communicate the configurations, parameters, models such as ML models to the base stations 191 and 192 and UEs through one or more devices and network functions of the communication network 190 (or communications system such as the 6G network 180 A shown in FIG 1A).
  • FIG. 1C illustrates an embodiment of a network 190C in accordance with various embodiments such as the network 190 in FIG. IB.
  • the network 190C may operate in a manner consistent with 3GPP technical specifications for LTE or 5G/NR systems.
  • 3GPP technical specifications for LTE or 5G/NR systems 3GPP technical specifications for LTE or 5G/NR systems.
  • the example embodiments are not limited in this regard and the described embodiments may apply to other networks that benefit from the principles described herein, such as future 3GPP systems, or the like.
  • the network 190C includes a UE 192C, which is any mobile or non-mobile computing device designed to communicate with a RAN 104 via an over-the-air connection.
  • the UE 192C is communicatively coupled with the RAN 104 by a Uu interface, which may be applicable to both LTE and NR systems.
  • Examples of the UE 192C include, but are not limited to, a smartphone, tablet computer, wearable device (e.g., smart watch, fitness tracker, smart glasses, small clothing/fabrics, head-mounted displays, smart shows, and/or the like), desktop computer, workstation, laptop computer, in-vehicle infotainment system, in-car entertainment system, instrument cluster, head-up display (HUD) device, onboard diagnostic device, dashtop mobile equipment, mobile data terminal, electronic engine management system, electronic/engine control unit, electronic/engine control module, embedded system, sensor, microcontroller, control module, engine management system, networked appliance, machine-type communication device, machine-to-machine (M2M), device-to-device (D2D), machine-type communication (MTC) device, Internet of Things (loT) device, smart appliance, flying drone or unmanned aerial vehicle (UAV), terrestrial drone or autonomous vehicle, robot, electronic signage, single-board computer (SBC) (e.g., Raspbeny Pi, iOS, Intel
  • network 190C may include a set of UEs 192C coupled directly with one another via a D2D, ProSe, PC5, and/or sidelink (SL) interface, and/or any other suitable interface such as any of those discussed herein.
  • SL communication involves communication between two or more UEs 192C using 3GPP technology without traversing a network node.
  • These UEs 192C may be M2M/D2D/MTC/IoT devices and/or vehicular systems that communicate using an SL interface, which includes, for example, one or more SL logical channels (e.g., Sidelink Broadcast Control Channel (SBCCH), Sidelink Control Channel (SCCH), and Sidelink Traffic Channel (STCH)); one or more SL transport channels (e.g., Sidelink Shared Channel (SL-SCH) and Sidelink Broadcast Channel (SL-BCH)); and one or more SL physical channels (e.g., Physical Sidelink Shared Channel (PSSCH), Physical Sidelink Control Channel (PSCCH), Physical Sidelink Feedback Channel (PSFCH), Physical Sidelink Broadcast Channel (PSBCH), and/or the like).
  • the UE 192C may perform blind decoding attempts of SL channels/links according to the various examples herein.
  • the UE 192C may additionally communicate with an AP 106 via an over-the-air connection.
  • the AP 106 may manage a WLAN connection, which may serve to offload some/all network traffic from the RAN 104.
  • the connection between the UE 192C and the AP 106 may be consistent with any IEEE 802.11 protocol, wherein the AP 106 could be a wireless fidelity (Wi-Fi®) router.
  • the UE 192C, RAN 104, and AP 106 may utilize cellular- WLAN aggregation (for example, LWA/LWIP).
  • Cellular- WLAN aggregation may involve the UE 192C being configured by the RAN 104 to utilize both cellular radio resources and WLAN resources.
  • the RAN 104 may include one or more access nodes, for example, AN 108.
  • AN 108 may terminate air-interface protocols for the UE 192C by providing access stratum protocols including RRC, PDCP, RLC, MAC, and PHY/L1 protocols. In this manner, the AN 108 may enable a service for data/voice connectivity between CN 120 and the UE 192C.
  • the AN 108 may be implemented in a discrete device or as one or more software entities running on server computers as pail of, for example, a virtual network, which may be referred to as a CRAN or virtual baseband unit pool.
  • the AN 108 be referred to as a BS, gNB, RAN node, eNB, ng-eNB, NodeB, RSU, TRxP, TRP, etc.
  • the AN 108 may be a macrocell base station or a low power base station for providing femtocells, picocells or other like cells having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells.
  • Some embodiments comprise a “CU/DU split” architecture where the ANs 108 are embodied as a gNB -Central Unit (CU) that is communicatively coupled with one or more gNB -Distributed Units (DUs), where each DU may he communicatively coupled with one or more Radio Units (RUs) (also referred to as RRHs, RRUs, or the like).
  • RUs Radio Units
  • the one or more RUs may be individual RSUs.
  • the CU/DU split may include an ng- eNB-CU and one or more ng-eNB-DUs instead of, or in addition to, the gNB-CU and gNB-DUs, respectively.
  • the ANs 108 employed as the CU may be implemented in a discrete device or as one or more software entities running on server computers as part of, for example, a virtual network including a virtual Base Band Unit (BBU) or BBU pool, cloud RAN (CRAN), Radio Equipment Controller (REC), Radio Cloud Center (RCC), centralized RAN (C-RAN), virtualized RAN (vRAN), and/or the like (although these terms may refer to different implementation concepts).
  • BBU Base Band Unit
  • CRAN cloud RAN
  • REC Radio Equipment Controller
  • RRCC Radio Cloud Center
  • C-RAN centralized RAN
  • vRAN virtualized RAN
  • Any other type of architectures, arrangements, and/or configurations can be used.
  • the RAN 104 may be coupled with one another via an X2 interface (if the RAN 104 is an LTE RAN) or an Xn interface (if the RAN 104 is a 5G RAN).
  • the X2/Xn interfaces which may be separated into control/user plane interfaces in some embodiments, may allow the ANs to communicate information related to handovers, data/context transfers, mobility, load management, interference coordination, etc.
  • the ANs of the RAN 104 may each manage one or more cells, cell groups, component carriers, etc. to provide the UE 192C with an air interface for network access.
  • the UE 192C may be simultaneously connected with a plurality of cells provided by the same or different ANs of the RAN 104.
  • the UE 192C and RAN 104 may use carrier aggregation to allow the UE 192C to connect with a plurality of component carriers, each corresponding to a Pcell or Scell.
  • a first AN may be a master node that provides an MCG and a second AN may be secondary node that provides an SCG.
  • the first/second ANs may be any combination of eNB, gNB, ng-eNB, etc.
  • the RAN 104 may provide the air interface over a licensed spectrum or an unlicensed spectrum.
  • the nodes may use LAA, eLAA, and/or feLAA mechanisms based on CA technology with PCells/Scells.
  • the nodes Prior to accessing the unlicensed spectrum, the nodes may perform medium/carrier- sensing operations based on, for example, a listen-before-talk (LBT) protocol.
  • LBT listen-before-talk
  • individual UEs 192C provide radio information to one or more ANs 108 and/or one or more edge compute nodes (e.g., edge servers/hosts, and the like).
  • the radio information may be data in the form of one or more measurement reports, and/or may include, for example, signal strength measurements, signal quality measurements, and/or the like.
  • Each measurement report is tagged with a timestamp and the location of the measurement (e.g., the UEs 192C current location).
  • the measurements collected by the UEs 192C and/or included in the measurement reports may include one or more of the following: bandwidth (BW), network or cell load, latency, jitter, round trip time (RTT), number of interrupts, out-of-order delivery of data packets, transmission power, bit error rate, bit error ratio (BER), Block Error Rate (BLER), packet error ratio (PER), packet loss rate, packet reception rate (PRR), data rate, peak data rate, end-to-end (e2e) delay, signal-to-noise ratio (SNR), signal- to-noise and interference ratio (SINR), signal-plus-noise-plus-distortion to noise-plus-distortion (SINAD) ratio, carrier-to-interference plus noise ratio (CINR), Additive White Gaussian Noise (AWGN), energy per bit to noise power density ratio (Eb/NO), energy per chip to interference power density ratio (Ec/IO), energy per chip to noise power density ratio (Ec/NO), peak-
  • the RSRP, RSSI, and/or RSRQ measurements may include RSRP, RSSI, and/or RSRQ measurements of cellspecific reference signals, channel state information reference signals (CSI-RS), and/or synchronization signals (SS) or SS blocks for 3GPP networks (e.g., LTE or 5G/NR), and RSRP, RSSI, RSRQ, RCPI, RSNI, and/or ANPI measurements of various beacon, Fast Initial Link Setup (FILS) discovery frames, or probe response frames for WLAN/WiFi networks. Other measurements may be additionally or alternatively used. Additionally, or alternatively, any of the aforementioned measurements (or combination of measurements) may be collected by one or more ANs 108 and provided to the edge compute nodc(s).
  • CSI-RS channel state information reference signals
  • SS synchronization signals
  • SS SS blocks for 3GPP networks
  • the measurements can include one or more of the following measurements: measurements related to Data Radio Bearer (DRB) (e.g., number of DRBs attempted to setup, number of DRBs successfully setup, number of released active DRBs, insession activity time for DRB, number of DRBs attempted to be resumed, number of DRBs successfully resumed, and the like); measurements related to Radio Resource Control (RRC) (e.g., mean number of RRC connections, maximum number of RRC connections, mean number of stored inactive RRC connections, maximum number of stored inactive RRC connections, number of attempted, successful, and/or failed RRC connection establishments, and the like); measurements related to UE Context (UECNTX); measurements related to Radio Resource Utilization (RRU) (e.g., DL total PRB usage, UL total PRB usage, distribution of DL total PRB usage, distribution of UL total PRB usage, DL PRB used for data traffic, UL PRB used for data traffic, DL total available PRBs, UL total available PRB
  • RRC
  • the radio information (data) may be reported in response to a trigger event and/or on a periodic basis. Additionally, or alternatively, individual UEs 192C report radio information either at a low periodicity or a high periodicity depending on a data transfer that is to take place, and/or other information about the data transfer. Additionally, or alternatively, the edge compute node(s) may request the measurements from the ANs 108 at low or high periodicity, or the ANs 108 may provide the measurements to the edge compute node(s) at low or high periodicity.
  • the edge compute node(s) may obtain other relevant data from other edge compute node(s), core network functions (NFs), application functions (AFs), and/or other UEs 192C such as Key Performance Indicators (KPIs), with the measurement reports or separately from the measurement reports.
  • NFs core network functions
  • AFs application functions
  • KPIs Key Performance Indicators
  • one or more RAN nodes, and/or core network NFs may be performed to supplement the obtained observation data such as, for example, substituting values from previous reports and/or historical data, apply an extrapolation filter, and/or the like.
  • acceptable bounds for the observation data may be predetermined or configured. For example, CQI and MCS measurements may be configured to only be within ranges defined by suitable 3GPP standards.
  • a reported data value may not make sense (e.g., the value exceeds an acceptable range/bounds, or the like)
  • such values may be dropped for the current learning/training episode or epoch.
  • packet delivery delay bounds may be defined or configured, and packets determined to have been received after the packet delivery delay bound may be dropped.
  • the UE 192C can also perform reference signal (RS) measurement and reporting procedures to provide the network with information about the quality of one or more wireless channels and/or the communication media in general, and this information can be used to optimize various aspects of the communication system.
  • the physical signals and/or reference signals can include demodulation reference signals (DM-RS), phase-tracking reference signals (PT-RS), positioning reference signal (PRS), channel-state information reference signal (CSI-RS), synchronization signal block (SSB), primary synchronization signal (PSS), secondary synchronization signal (SSS), sounding reference signal (SRS), and/or the like.
  • any suitable data collection and/or measurement mechanism(s) may be used to collect the observation data.
  • data marking e.g., sequence numbering, and the like
  • packet tracing e.g., signal measurement, data sampling, and/or timestamping techniques
  • the collection of data may be based on occurrence of events that trigger collection of the data. Additionally, or alternatively, data collection may take place at the initiation or termination of an event.
  • the data collection can be continuous, discontinuous, and/or have start and stop times.
  • the data collection techniques/mechanisms may be specific to a HW configuration/implementation or non-HW-specific, or may be based on various software parameters (e.g., OS type and version, and the like). Various configurations may be used to define any of the aforementioned data collection parameters.
  • Such configurations may be defined by suitable specifications/standards, such as 3GPP (e.g., [SA6Edge]), ETSI (e.g., [MEC]), O- RAN (e.g., [O-RAN]), Intel® Smart Edge Open (formerly OpenNESS) (e.g., [ISEO]), IETF (e.g., MAMS [RFC8743]), lEEE/WiFi (e.g., [IEEE80211], [WiMAX], [IEEE16090], and the like), and/or any other like standards such as those discussed herein.
  • 3GPP e.g., [SA6Edge]
  • ETSI e.g., [MEC]
  • O- RAN e.g., [O-RAN]
  • Intel® Smart Edge Open e.g., [ISEO]
  • IETF e.g., MAMS [RFC8743]
  • lEEE/WiFi e.g.,
  • the UE 192C or AN 108 may be or act as a roadside unit (RSU), which may refer to any transportation infrastructure entity used for V2X communications.
  • RSU may be implemented in or by a suitable AN or a stationary (or relatively stationary) UE.
  • An RSU implemented in or by: a UE may be referred to as a “UE-type RSU”; an eNB may be referred to as an “eNB-type RSU”; a gNB may be referred to as a “gNB-type RSU”; and the like.
  • an RSU is a computing device coupled with radio frequency circuitry located on a roadside that provides connectivity support to passing vehicle UEs.
  • the RSU may also include internal data storage circuitry to store intersection map geometry, traffic statistics, media, as well as applications/software to sense and control ongoing vehicular and pedestrian traffic.
  • the RSU may provide very low latency communications required for high-speed events, such as crash avoidance, traffic warnings, and the like. Additionally, or alternatively, the RSU may provide other cellular/WLAN communications services.
  • the components of the RSU may be packaged in a weatherproof enclosure suitable for outdoor installation and may include a network interface controller to provide a wired connection (e.g., Ethernet) to a traffic signal controller or a backhaul network.
  • V2X RATs may be employed, which allow V2X nodes to communicate directly with one another, with infrastructure equipment (e.g., AN 108), and/or other devices/nodes.
  • at least two distinct V2X RATs may be used including WLAN V2X (W-V2X) RATs based on IEEE V2X technologies (e.g., DSRC for the U.S. and ITS-G5 for Europe) and cellular V2X (C-V2X) RATs based on 3GPP V2X technologies (e.g., LTE V2X, 5G/NR V2X, and beyond).
  • the C-V2X RAT may utilize a C-V2X air interface and the WEAN V2X RAT may utilize a W-V2X air interface.
  • the W-V2X RATs include, for example, IEEE Guide for Wireless Access in Vehicular Environments (WAVE) Architecture, IEEE STANDARDS ASSOCIATION, IEEE 1609.0-2019 (10 Apr. 2019) (“[IEEE16090]”), V2X Communications Message Set Dictionary, SAE INT’L (23 Jul. 2020) (“[J2735_202007]”), Intelligent Transport Systems in the 5 GHz frequency band (ITS-G5), the [IEEE80211p] (which is the layer 1 (LI) and layer 2 (L2) part of WAVE, DSRC, and ITS-G5), and/or IEEE Standard for Air Interface for Broadband Wireless Access Systems, IEEE Std 802.16-2017, pp.1-2726 (02 Mar. 2018) (“[WiMAX]”).
  • DSRC refers to vehicular communications in the 5.9 GHz frequency band that is generally used in the United States
  • ITS-G5 refers to vehicular communications in the 5.9 GHz frequency band in Europe. Since any number of different RATs are applicable (including [IEEE80211p] RATs) that may be used in any geographic or political region, the terms “DSRC” (used, among other regions, in the U.S) and “ITS-G5” (used, among other regions, in Europe) may be used interchangeably throughout this disclosure.
  • the access layer for the ITS-G5 interface is outlined in ETSI EN 302 663 VI.3.1 (2020-01) (hereinafter “[EN302663]”) and describes the access layer of the ITS-S reference architecture.
  • the ITS-G5 access layer comprises [IEEE80211] (which now incorporates [IEEE8021 Ip]), as well as features for Decentralized Congestion Control (DCC) methods discussed in ETSI TS 192C 687 VE2.1 (2018-04) (“[TS192C687]”).
  • DCC Decentralized Congestion Control
  • the access layer for 3GPP LTE-V2X based interface(s) is outlined in, inter alia, ETSI EN 303 613 VI.1.1 (2020-01), 3GPP TS 23.285 vl6.2.0 (2019-12); and 3GPP 5G/NR-V2X is outlined in, inter alia, 3GPP TR 23.786 vl6.1.0 (2019-06) and 3GPP TS 23.287 vl8.0.0 (2023-03-31) (“[TS23287]”).
  • the RAN 104 may be an LTE RAN 110 with eNBs, for example, eNB 112.
  • the LTE RAN 110 may provide an LTE air interface (Uu) with the following characteristics: SCS of 15 kHz; CP-OFDM waveform for DL and SC-FDMA waveform for UL; turbo codes for data and TBCC for control; etc.
  • the LTE air interface may rely on CSLRS 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 sub-6 GHz bands.
  • the RAN 104 may be an NG-RAN 114 with gNBs, for example, gNB 116, or ng-eNBs, for example, ng-eNB 118.
  • the gNB 116 may connect with 5G-enabled UEs using a 5G NR interface.
  • the gNB 116 may connect with a 5G core through an NG interface, which may include an N2 interface or an N3 interface.
  • the ng-eNB 118 may also connect with the 5G core through an NG interface, but may connect with a UE via an LTE air interface.
  • the gNB 116 and the ng-eNB 118 may connect with each other over an Xn interface.
  • the NG interface may be split into two parts, an NG user plane (NG- U) interface, which carries traffic data between the nodes of the NG-RAN 114 and a UPF 148 (e.g., N3 interface), and an NG control plane (NG-C) interface, which is a signaling interface between the nodes of the NG-RAN114 and an AMF 144 (e.g., N2 interface).
  • NG- U NG user plane
  • N3 interface e.g., N3 interface
  • N-C NG control plane
  • the NG-RAN 114 may provide a 5G-NR air interface with the following characteristics: variable SCS; CP-OFDM for DL, CP-OFDM and DFT-s-OFDM for UL; polar, repetition, simplex, and Reed-Muller codes for control and LDPC for data.
  • the 5G-NR air interface may rely on CSLRS, PDSCH/PDCCH DMRS similar to the LTE air interface.
  • the 5G-NR air interface may not use a CRS, but may use PBCH DMRS for PBCH demodulation; PTRS for phase tracking for PDSCH; and tracking reference signal for time tracking.
  • the 5G-NR air interface may operate on FR1 bands that include sub-6 GHz bands or FR2 bands that include bands from 24.25 GHz to 52.6 GHz.
  • the 5G-NR air interface may include an SSB that is an area of a downlink resource grid that includes PSS/SSS/PBCH.
  • the 5G-NR air interface may utilize BWPs for various purposes.
  • BWP can be used for dynamic adaptation of the SCS.
  • the UE 192C can be configured with multiple BWPs where each BWP configuration has a different SCS. When a BWP change is indicated to the UE 192C, the SCS of the transmission is changed as well.
  • Another use case example of BWP is related to power saving.
  • multiple BWPs can be configured for the UE 192C with different amount of frequency resources (for example, PRBs) to support data transmission under different traffic loading scenarios.
  • a BWP containing a smaller number of PRBs can be used for data transmission with small traffic load while allowing power saving at the UE 192C and in some cases at the gNB 116.
  • a BWP containing a larger number of PRBs can be used for scenarios with higher traffic load.
  • individual gNBs 116 can include a gNB-CU and a set of gNB- DUs. Additionally, or alternatively, gNBs 116 can include one or more RUs. In these implementations, the gNB-CU may be connected to each gNB-DU via respective Fl interfaces. In case of network sharing with multiple cell ID broadcast(s), each cell identity associated with a subset of PLMNs corresponds to a gNB-DU and the gNB-CU it is connected to share the same physical layer cell resources. For resiliency, a gNB-DU may be connected to multiple gNB-CUs by appropriate implementation.
  • a gNB-CU can be separated into gNB-CU control plane (gNB-CU-CP) and gNB-CU user plane (gNB-CU-UP) functions.
  • the gNB-CU-CP is connected to a gNB-DU through an Fl control plane interface (Fl-C)
  • the gNB-CU-UP is connected to the gNB-DU through an Fl user plane interface (Fl-U)
  • the gNB-CU-UP is connected to the gNB-CU-CP through an El interface.
  • one gNB-DU is connected to only one gNB-CU-CP
  • one gNB-CU-UP is connected to only one gNB-CU- CP.
  • a gNB-DU and/or a gNB-CU-UP may be connected to multiple gNB-CU-CPs by appropriate implementation.
  • One gNB-DU can be connected to multiple gNB-CU-UPs under the control of the same gNB-CU-CP, and one gNB-CU-UP can be connected to multiple DUs under the control of the same gNB-CU-CP.
  • Data forwarding between gNB-CU-UPs during intra- gNB-CU-CP handover within a gNB may be supported by Xn-U.
  • individual ng-eNBs 118 can include an ng-eNB-CU and a set of ng-eNB-DUs.
  • the ng-eNB-CU and each ng-eNB-DU are connected to one another via respective W1 interface.
  • An ng-eNB can include an ng-eNB-CU-CP, one or more ng-eNB-CU- UP(s), and one or more ng-cNB-DU(s).
  • An ng-cNB-CU-CP and an ng-cNB-CU-UP is connected via the El interface.
  • An ng-eNB-DU is connected to an ng-eNB-CU-CP via the Wl-C interface, and to an ng-eNB-CU-UP via the Wl-U interface.
  • the general principle described herein w.r.t gNB aspects also applies to ng-eNB aspects and corresponding El and W1 interfaces, if not explicitly specified otherwise.
  • the node hosting user plane part of the PDCP protocol layer (e.g., gNB-CU, gNB-CU-UP, and for EN-DC, MeNB or SgNB depending on the bearer split) performs user inactivity monitoring and further informs its inactivity or (re)activation to the node having control plane connection towards the core network (e.g., over El, X2, or the like).
  • the node hosting the RLC protocol layer (e.g., gNB-DU) may perform user inactivity monitoring and further inform its inactivity or (re)activation to the node hosting the control plane (e.g., gNB-CU or gNB-CU-CP).
  • the NG-RAN 114 is layered into a Radio Network Layer (RNL) and a Transport Network Layer (TNL).
  • RNL Radio Network Layer
  • TNL Transport Network Layer
  • the NG-RAN 114 architecture e.g., the NG-RAN logical nodes and interfaces between them
  • the NG-RAN 114 architecture is part of the RNL.
  • the NG-RAN interface e.g., NG, Xn, Fl, and the like
  • the TNL provides services for user plane transport and/or signaling transport.
  • each NG-RAN node is connected to all AMFs 144 of AMF sets within an AMF region supporting at least one slice also supported by the NG-RAN node.
  • the RAN 104 is communicatively coupled to CN 120 that includes network elements to provide various functions to support data and telecommunications services to customers/subscribers (for example, users of UE 192C).
  • the components of the CN 120 may be implemented in one physical node or separate physical nodes.
  • NFV may be utilized to virtualize any or all of the functions provided by the network elements of the CN 120 onto physical compute/storage resources in servers, switches, etc.
  • a logical instantiation of the CN 120 may be referred to as a network slice, and a logical instantiation of a portion of the CN 120 may be referred to as a network sub-slice.
  • the CN 120 may be an LTE CN 122, which may also be referred to as an EPC.
  • the LTE CN 122 may include MME 124, SGW 126, SGSN 128, HSS 130, PGW 132, and PCRF 134 coupled with one another over interfaces (or “reference points”) as shown.
  • Functions of the elements of the LTE CN 122 may be briefly introduced as follows.
  • the MME 124 may implement mobility management functions to track a current location of the UE 192C to facilitate paging, bearer activation/dcactivation, handovers, gateway selection, authentication, etc.
  • the SGW 126 may terminate an SI interface toward the RAN and route data packets between the RAN and the LTE CN 122.
  • the SGW 126 may be a local mobility anchor point for inter-RAN node handovers and also may provide an anchor for inter-3GPP mobility. Other responsibilities may include lawful intercept, charging, and some policy enforcement.
  • the SGSN 128 may track a location of the UE 192C and perform security functions and access control. In addition, the SGSN 128 may perform inter-EPC node signaling for mobility between different RAT networks; PDN and S-GW selection as specified by MME 124; MME selection for handovers; etc.
  • the S3 reference point between the MME 124 and the SGSN 128 may enable user and bearer information exchange for inter-3GPP access network mobility in idle/active states.
  • the HSS 130 may include a database for network users, including subscription-related information to support the network entities’ handling of communication sessions.
  • the HSS 130 can provide support for routing/roaming, authentication, authorization, naming/addressing resolution, location dependencies, etc.
  • An S6a reference point between the HSS 130 and the MME 124 may enable transfer of subscription and authentication data for authenticating/authorizing user access to the LTE CN 120.
  • the PGW 132 may terminate an SGi interface (interface 182A) toward a data network (DN) 136 that may include one or more application/content servers 138 such as the framework logic circuitry 100 shown in FIG. 1A and/or other application content servers 138.
  • the PGW 132 may route data packets between the LTE CN 122 and the data network 136.
  • the PGW 132 may be coupled with the SGW 126 by an S5 reference point to facilitate user plane tunneling and tunnel management.
  • the PGW 132 may further include a node for policy enforcement and charging data collection (for example, PCEF).
  • the SGi reference point between the PGW 132 and the data network 136 may be an operator external public, a private PDN, or an intraoperator packet data network, for example, for provision of IMS services.
  • the PGW 132 may be coupled with a PCRF 134 via a Gx reference point.
  • the PCRF 134 is the policy and charging control element of the LTE CN 122.
  • the PCRF 134 may be communicatively coupled to the app/content server 138 to determine appropriate QoS and charging parameters for service flows.
  • the PCRF 132 may provision associated rules into a PCEF (via Gx reference point) with appropriate TFT and QCI.
  • the CN 120 may be a 5GC 140.
  • the 5GC 140 may include an AUSF 142, AMF 144, SMF 146, UPF 148, NSSF 150, NEF 152, NRF 154, PCF 156, UDM 158, AF 160, and Network Data Analytics Function (NWDAF) 162 coupled with one another over interfaces (or “reference points”) as shown.
  • Functions of the elements of the 5GC 140 may be briefly introduced as follows.
  • the CN 120 may be a 5GC 140 including an Authentication Server Function (AUSF) 142, Access and Mobility Management Function (AMF) 144, Session Management Function (SMF) 146, User Plane Function (UPF) 148, Network Slice Selection Function (NSSF) 150, Network Exposure Function (NEF) 152, Network Repository Function (NRF) 154, Policy Control Function (PCF) 156, Unified Data Management (UDM) 158, Unified Data Repository (UDR), Application Function (AF) 160, Edge Application Server Discovery Function (EASDF) 161, and Network Data Analytics Function (NWDAF) 162 coupled with one another over various interfaces as shown.
  • AUSF Authentication Server Function
  • AMF Access and Mobility Management Function
  • SMF Session Management Function
  • UPF User Plane Function
  • NEF Network Exposure Function
  • NRF Network Repository Function
  • PCF Policy Control Function
  • UDM Unified Data Management
  • UDR Unified Data Repository
  • AF Application Function
  • EASDF Edge Application Server
  • the NWDAF 162 includes one or more of the following functionalities: support data collection from NFs and AFs 160; support data collection from 0AM; NWDAF service registration and metadata exposure to NFs and AFs 160; support analytics information provisioning to NFs and AFs 160; support machine learning (ML) model training and provisioning to NWDAF(s) 162 (e.g., those containing analytics logical function). Some or all of the NWDAF functionalities can be supported in a single instance of an NWDAF 162.
  • the NWDAF 162 also includes an analytics reporting capability, which comprises means that allow discovery of the type of analytics that can be consumed by an external party and/or the request for consumption of analytics information generated by the NWDAF 162.
  • the NWDAF 162 interacts with different entities for different purposes, such as one or more of the following: data collection based on subscription to events provided by AMF 144, SMF 146, PCF 156, UDM 158, NSACF, AF 160 (directly or via NEF 152) and 0AM (not shown); analytics and data collection using the Data Collection Coordination Function (DCCF); retrieval of information from data repositories (e.g. UDR via UDM 158 for subscriber-related information); data collection of location information from LCS system; storage and retrieval of information from an Analytics Data Repository Function (ADRF); analytics and data collection from a Messaging Framework Adaptor Function (MFAF); retrieval of information about NFs (c.g. from NRF 154 for NF-rclatcd information); on-demand provision of analytics to consumers,; and/or provision of bulked data related to analytics ID(s).
  • DCCF Data Collection Coordination Function
  • ADRF Analytics Data Repository Function
  • MFAF Messaging Framework Adaptor Function
  • a single instance or multiple instances of NWDAF 162 may be deployed in a PLMN. If multiple NWDAF 162 instances are deployed, the architecture supports deploying the NWDAF 162 as a central NF, as a collection of distributed NFs, or as a combination of both. If multiple NWDAF 162 instances are deployed, an NWDAF 162 can act as an aggregate point (e.g., aggregator NWDAF 162) and collect analytics information from other NWDAFs 162, which may have different serving areas, to produce the aggregated analytics (e.g., per analytics ID), possibly with analytics generated by itself. When multiple NWDAFs 162 exist, not all of them need to be able to provide the same type of analytics results.
  • NWDAFs 162 can be specialized in providing certain types of analytics.
  • An analytics ID information element is used to identify the type of supported analytics that NWDAF 162 can generate.
  • NWDAF 162 instance(s) can be collocated with a 5GS NF.
  • NWDAF 162 instances may be present in the 5GC 140, with possible specializations per type of analytics.
  • the capabilities of an NWDAF 162 instance are described in the NWDAF profile stored in the NRF 154.
  • the NWDAF architecture allows for arranging multiple NWDAF 162 instances in a hierarchy /tree with a flexible number of layers/branches. The number and organization of the hierarchy layers, as well as the capabilities of each NWDAF 162 instance remain deployment choices and may vary depending on implementation and/or use case.
  • NWDAFs 162 may provide data collection exposure capability for generating analytics based on the data collected by other NWDAFs 162, when DCCFs 163 and/or MFAFs 165 are not present in the network.
  • the AUSF 142 may store data for authentication of UE 192C and handle authentication- related functionality.
  • the AUSF 142 may facilitate a common authentication framework for various access types.
  • the AUSF 142 may exhibit an Nausf service-based interface.
  • the AMF 144 may allow other functions of the 5GC 140 to communicate with the UE 192C and the RAN 104 and to subscribe to notifications about mobility events with respect to the UE 192C.
  • the AMF 144 may be responsible for registration management (for example, for registering UE 192C), connection management, reachability management, mobility management, lawful interception of AMF-related events, and access authentication and authorization.
  • the AMF 144 may provide transport for SM messages between the UE 192C and the SMF 146, and act as a transparent proxy for routing SM messages.
  • AMF 144 may also provide transport for SMS messages between UE 192C and an SMSF.
  • AMF 144 may interact with the AUSF 142 and the UE 192C to perform various security anchor and context management functions.
  • AMF 144 may be a termination point of a RAN CP interface, which may include or be an N2 reference point between the RAN 104 and the AMF 144; and the AMF 144 may be a termination point of NAS (Nl) signaling, and perform NAS ciphering and integrity protection.
  • AMF 144 may also support NAS signaling with the UE 192C over an N3 IWF interface.
  • the AMF 144 also supports NAS signaling with the UE 192C over an N3IWF interface.
  • the N3IWF provides access to untrusted entities.
  • N3IWF may be a termination point for the N2 interface between the (R)AN 104 and the AMF 144 for the control plane, and may be a termination point for the N3 reference point between the (R)AN 104 and the 148 for the user plane.
  • the AMF 144 handles N2 signaling from the SMF 146 and the AMF 144 for PDU sessions and QoS, encapsulate/de-encapsulate packets for IPSec and N3 tunneling, marks N3 user-plane packets in the UL, and enforces QoS corresponding to N3 packet marking taking into account QoS requirements associated with such marking received over N2.
  • N3IWF may also relay UL and DL control-plane NAS signaling between the UE 192C and AMF 144 via an Nl reference point between the UE 192C and the AMF 144, and relay UL and DL user-plane packets between the UE 192C and UPF 148.
  • the N3IWF also provides mechanisms for IPsec tunnel establishment with the UE 192C.
  • the AMF 144 may exhibit an Namf service-based interface, and may be a termination point for an N14 reference point between two AMFs 144 and an N17 reference point between the AMF 144 and a 5G-EIR (not shown by Figure 1).
  • the AMF 144 may provide support for Network Slice restriction and Network Slice instance restriction based on NWDAF analytics.
  • the SMF 146 may be responsible for SM (for example, session establishment, tunnel management between UPF 148 and AN 108); UE IP address allocation and management (including optional authorization); selection and control of UP function; configuring traffic steering at UPF 148 to route traffic to proper destination; termination of interfaces toward policy control functions; controlling part of policy enforcement, charging, and QoS; lawful intercept (for SM events and interface to LI system); termination of SM parts of NAS messages; downlink data notification; initiating AN specific SM information, sent via AMF 144 over N2 to AN 108; and determining SSC mode of a session.
  • SM may refer to management of a PDU session, and a PDU session or “session” may refer to a PDU connectivity service that provides or enables the exchange of PDUs between the UE 192C and the data network 136.
  • the SMF 146 may also include the following functionalities to support edge computing enhancements: selection of EASDF 161 and provision of its address to the UE as the DNS server for the PDU session; usage of EASDF 161 services; and for supporting the application layer architecture, provision and updates of ECS address configuration information to the UE.
  • the UPF 148 may act as an anchor point for intra-RAT and inter-RAT mobility, an external PDU session point of interconnect to data network 136, and a branching point to support multihomed PDU session.
  • the UPF 148 may also perform packet routing and forwarding, perform packet inspection, enforce the user plane part of policy rules, lawfully intercept packets (UP collection), perform traffic usage reporting, perform QoS handling for a user plane (e.g., packet filtering, gating, UL/DL rate enforcement), perform uplink traffic verification (e.g., SDF-to-QoS flow mapping), transport level packet marking in the uplink and downlink, and perform downlink packet buffering and downlink data notification triggering.
  • UPF 148 may include an uplink classifier to support routing traffic flows to a data network.
  • the NSSF 150 may select a set of network slice instances serving the UE 192C.
  • the NSSF 150 may also determine allowed NSSAI and the mapping to the subscribed S-NSSAIs, if needed.
  • the NSSF 150 may also determine the AMF set to be used to serve the UE 192C, or a list of candidate AMFs based on a suitable configuration and possibly by querying the NRF 154.
  • the selection of a set of network slice instances for the UE 192C may be triggered by the AMF 144 with which the UE 192C is registered by interacting with the NSSF 150, which may lead to a change of AMF.
  • the NSSF 150 may interact with the AMF 144 via an N22 reference point; and may communicate with another NSSF in a visited network via an N31 reference point (not shown). Additionally, the NSSF 150 may exhibit an Nnssf service-based interface.
  • the NEF 152 may securely expose services and capabilities provided by 3GPP network functions for third party, internal exposure/re-exposure, AFs (e.g., AF 160), edge computing or fog computing systems, etc.
  • the NEF 152 may authenticate, authorize, or throttle the AFs.
  • NEF 152 may also translate information exchanged with the AF 160 and information exchanged with internal network functions. For example, the NEF 152 may translate between an AF-Service-Tdentifier and an internal 5GC information.
  • NEF 152 may also receive information from other NFs based on exposed capabilities of other NFs. In particular, the NEF 152 handles masking of network and user sensitive information to external AF's 160 according to the network policy.
  • the NEF 152 also receives information from other NFs based on exposed capabilities of other NFs. This information may be stored at the NEF 152 as structured data, or at a data storage NF using standardized interfaces. The stored information can then be re-exposed by the NEF 152 to other NFs and AFs, or used for other purposes such as analytics. For example, NWDAF analytics may be securely exposed by the NEF 152 for external party. Furthermore, data provided by an external party may be collected by the NWDAF 162 via the NEF 152 for analytics generation purpose. The NEF 152 handles and forwards requests and notifications between the NWDAF 162 and AF(s) 160. Additionally, the NEF 152 may exhibit an Nnef service-based interface.
  • the NRF 154 may support service discovery functions, receive NF discovery requests from NF instances, and provide the information of the discovered NF instances to the NF instances. NRF 154 also maintains information of available NF instances and their supported services.
  • the terms “instantiate,” “instantiation,” and the like may refer to the creation of an instance, and an “instance” may refer to a concrete occurrence of an object, which may occur, for example, during execution of program code.
  • the NRF 154 supports service discovery functions, receives NF discovery requests from NF instances, and provides information of the discovered NF instances to the requesting NF instances.
  • the NRF 154 also maintains NF profiles of available NF instances and their supported services.
  • the terms “instantiate,” “instantiation,” and the like may refer to the creation of an instance, and an “instance” may refer to a concrete occurrence of an object, which may occur, for example, during execution of program code.
  • the NF profile of NF instance maintained in the NRF 154 includes the following information: NF instance ID; NF type; PLMN ID in the case of PLMN, PLMN ID + NID in the case of SNPN; Network Slice related Identifier(s) (e.g., S-NSSAI, NSI ID); an NF’s network address(es) (e.g., FQDN, IP address, and/or the like), NF capacity information, NF priority information (e.g., for AMF selection), NF set ID, NF service set ID of the NF service instance; NF specific service authorization information; names of supported services, if applicable; endpoint address(es) of instance(s) of each supported service; identification of stored data/information (e.g., for UDR profile and/or other NF profiles); other service parameter(s) (c.g., DNN or DNN list, LADN DNN or LADN DNN list, notification endpoint for each type of notification that the NF service is interested in receiving,
  • the NF profile includes: supported analytics ID(s), possibly per service, NWDAF serving area information (e.g., a list of TAIs for which the NWDAF can provide services and/or data), Supported Analytics Delay per Analytics ID (if available), NF types of the NF data sources, NF Set IDs of the NF data sources, if available, analytics aggregation capability (if available), analytics metadata provisioning capability (if available), ML model filter information parameters S-NSSAI(s) and area(s) of interest for the trained ML model(s) per analytics ID(s) (if available), federated learning (FL) capability type (e.g., FL server or FL client, if available), Time interval supporting FL (if available).
  • NWDAF serving area information e.g., a list of TAIs for which the NWDAF can provide services and/or data
  • Supported Analytics Delay per Analytics ID if available
  • NF types of the NF data sources NF Set IDs of the NF data sources, if available
  • the NWDAF's 162 Serving Area information is common to all its supported analytics IDs.
  • the analytics IDs supported by the NWDAF 162 may be associated with a supported analytics delay, for example, the analytics report can be generated with a time (including data collection delay and inference delay) in less than or equal to the supported analytics delay.
  • the determination of supported analytics delay, and how the NWDAF 162 avoid updating its Supported Analytics Delay in NRF frequently may be NWDAF-implementation specific.
  • the PCF 156 may provide policy rules to control plane functions to enforce them, and may also support unified policy framework to govern network behavior.
  • the PCF 156 may also implement a front end to access subscription information relevant for policy decisions in a UDR of the UDM 158.
  • the PCF 156 exhibit an Npcf service-based interface.
  • the UDM 158 may handle subscription-related information to support the network entities’ handling of communication sessions, and may store subscription data of UE 192C. For example, subscription data may be communicated via an N8 reference point between the UDM 158 and the AMF 144.
  • the UDM 158 may include two parts, an application front end and a UDR.
  • the UDR may store subscription data and policy data for the UDM 158 and the PCF 156, and/or structured data for exposure and application data (including PFDs for application detection, application request information for multiple UEs 192C) for the NEF 152.
  • the Nudr servicebased interface may be exhibited by the UDR 546 to allow the UDM 158, PCF 156, and NEF 152 to access a particular set of the stored data, as well as to read, update (e.g., add, modify), delete, and subscribe to notification of relevant data changes in the UDR.
  • the UDM may include a UDM-FE, which is in charge of processing credentials, location management, subscription management and so on. 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 handling, access authorization, registration/mobility management, and subscription management.
  • the UDM 158 may exhibit the Nudm servicebased interface.
  • An Edge Application Server Discovery Function (EASDF) 161 exhibits an Neasdf servicebased interface, and is connected to the SMF 146 via an N88 interface.
  • EASDF instances may be deployed within a PLMN, and interactions between 5GC NF(s) and the EASDF 161 take place within a PLMN.
  • the EASDF 161 includes one or more of the following functionalities: registering to NRF 154 for EASDF 161 discovery and selection; handling the DNS messages according to the instruction from the SMF 146; and/or terminating DNS security, if used.
  • Handling the DNS messages according to the instruction from the SMF 146 includes one or more of the following functionalities: receiving DNS message handling rules and/or BaselineDNSPattem from the SMF 146; exchanging DNS messages from/with the UE 192C; forwarding DNS messages to C-DNS or L-DNS for DNS query; adding EDNS client subnet (ECS) option into DNS query for an FQDN; reporting to the SMF 146 the information related to the received DNS messages; and/or buffering/discarding DNS messages from the UE 192C or DNS Server.
  • the EASDF has direct user plane connectivity (e.g., without any NAT) with the PSA UPF over N6 (interface 182A) for the transmission of DNS signaling exchanged with the UE.
  • the deployment of a NAT between EASDF 161 and PSA UPF 148 may or may not be supported.
  • the AF 160 may provide application influence on traffic routing, provide access to NEF, and interact with the policy framework for policy control.
  • the AF 160 may influence UPF 148 (re)selection and traffic routing. Based on operator deployment, when AF 160 is considered to be a trusted entity, the network operator may permit AF 160 to interact directly with relevant NFs. In some implementations, the AF 160 is used for edge computing implementations.
  • An NF that needs to collect data from an AF 160 may subscribe/unsubscribe to notifications regarding data collected from an AF 160, either directly from the AF 160 or via NEF 152.
  • the data collected from an AF 160 is used as input for analytics by the NWDAF 162.
  • the 5GC 140 may enable edge computing by selecting operator/3rd party services to be geographically close to a point that the UE 192C is attached to the network 190C. This may reduce latency and load on the network 190C.
  • the 5GC 140 may select a UPF 148 close to the UE 192C and execute traffic steering from the UPF 148 to data network (DN) 136 via the N6 interface (interface 182A). This may be based on the UE subscription data, UE location, and information provided by the AF 160. In this way, the AF 160 may influence UPF (re)selection and traffic routing.
  • the network operator may permit AF 160 to interact directly with relevant NFs. Additionally, the AF 160 may exhibit a Naf service-based interface.
  • the DN 136 may represent various network operator services, Internet access, or third-party services that may be provided by one or more servers including, for example, an application/content server 138 such as the framework logic circuitry 100 and/or other application/content servers 138.
  • the DN 136 may be an operator external public, a private PDN, or an intra-operator packet data network, for example, for provision of IMS services.
  • the app server 138 can be coupled to an IMS via an S-CSCF or the I-CSCF.
  • the DN 136 may represent one or more local area DNs (EADNs), which are DNs 136 (or DN names (DNNs)) that is/are accessible by a UE 192C in one or more specific areas. Outside of these specific areas, the UE 192C is not able to access the EADN/DN 136. Additionally, or alternatively, the DN 136 may be an edge DN 136, which is a (local) DN that supports the architecture for enabling edge applications.
  • the app server 138 may represent the physical hardware systems/devices providing app server functionality and/or the application software resident in the cloud or at an edge compute node that performs server function(s). In some examples, the app/content server 138 provides an edge hosting environment that provides support required for Edge Application Server's execution.
  • the 5GS can use one or more edge compute nodes to provide an interface and offload processing of wireless communication traffic.
  • the edge compute nodes may be included in, or co-located with one or more RANs 104 or RAN nodes 114.
  • the edge compute nodes can provide a connection between the RAN 104 and UPF 148 in the 5GC 140.
  • the edge compute nodes can use one or more NFV instances instantiated on virtualization infrastructure within the edge compute nodes to process wireless connections to and from the RAN 114 and UPF 148.
  • the edge compute nodes provide a distributed computing environment for application and service hosting, and also provide storage and processing resources so that data and/or content can be processed in close proximity to subscribers (e.g., users of UEs 192C) for faster response times.
  • the edge compute nodes also support multitenancy run-time and hosting environment(s) for applications, including virtual appliance applications that may be delivered as packaged virtual machine (VM) images, middleware application and infrastructure services, content delivery services including content caching, mobile big data analytics, and computational offloading, among others.
  • VM virtual machine
  • Computational offloading involves offloading computational tasks, workloads, applications, and/or services to the edge compute nodes from the UEs 192C, CN 140, DN 136, and/or server(s) 138, or vice versa.
  • a device application or client application operating in a UE 192C may offload application tasks or workloads to one or more edge compute nodes.
  • an edge compute node may offload application tasks or workloads to a set of UEs 192C (e.g., for distributed machine learning computation and/or the like).
  • the edge compute nodes may include or be part of an edge system that employs one or more edge computing technologies (ECTs) (also referred to as an “edge computing framework” or the like).
  • the edge compute nodes may also be referred to as “edge hosts” or “edge servers.”
  • the edge system includes a collection of edge servers and edge management systems (not shown) necessary to run edge computing applications within an operator network or a subset of an operator network.
  • the edge servers arc physical computer systems that may include an edge platform and/or virtualization infrastructure, and provide compute, storage, and network resources to edge computing applications.
  • Each of the edge servers are disposed at an edge of a corresponding access network, and are arranged to provide computing resources and/or various services (e.g., computational task and/or workload offloading, cloud-computing capabilities, IT services, and other like resources and/or services as discussed herein) in relatively close proximity to UEs 192C.
  • the VI of the edge compute nodes provide virtualized environments and virtualized resources for the edge hosts, and the edge computing applications may run as VMs and/or application containers on top of the VI.
  • the ECT is and/or operates according to the MEC framework, this example implementation (and/or in any other example implementation discussed herein) may also include NFV and/or other like virtualization technologies. Other virtualization technologies and/or service orchestration and automation platforms may be used.
  • the ECT is and/or operates according to the O RAN framework.
  • O-RAN Open RAN alliance
  • the ECT is and/or operates according to the 3rd Generation Partnership Project (3GPP) System Aspects Working Group 6 (SA6) Architecture for enabling Edge Applications (referred to as “3GPP edge computing”).
  • 3GPP 3rd Generation Partnership Project
  • SA6 System Aspects Working Group 6
  • the ECT is and/or operates according to the Intel® Smart Edge Open framework (formerly known as OpenNESS).
  • the ECT operates according to the Multi-Access Management Services (MAMS) framework.
  • MAMS Multi-Access Management Services
  • the aforementioned edge computing frameworks/ECTs and services deployment examples arc only illustrative examples of ECTs, and that the present disclosure may be applicable to many other or additional edge computing/networking technologies in various combinations and layouts of devices located at the edge of a network including the various edge computing networks/sy stems described herein.
  • the techniques disclosed herein may relate to other loT edge network systems and configurations, and other intermediate processing entities and architectures may also be applicable to the present disclosure.
  • edge computing/networking technologies include [MEC]; [O- RAN]; [ISEO]; [SA6Edge]; Content Delivery Networks (CDNs) (also referred to as “Content Distribution Networks” or the like); Mobility Service Provider (MSP) edge computing and/or Mobility as a Service (MaaS) provider systems (e.g., used in AECC architectures); Nebula edgecloud systems; Fog computing systems; Cloudlet edge-cloud systems; Mobile Cloud Computing (MCC) systems; Central Office Re- architected as a Datacenter (CORD), mobile CORD (M- CORD) and/or Converged Multi-Access and Core (COMAC) systems; and/or the like.
  • MEC Mobility Service Provider
  • MaaS Mobility as a Service
  • Nebula edgecloud systems Fog computing systems
  • Cloudlet edge-cloud systems Cloudlet edge-cloud systems
  • MCC Mobile Cloud Computing
  • CORD Central Office Re- architected as a Datacenter
  • M- CORD mobile CORD
  • the interfaces of the 5GC 140 include reference points and service-based interfaces.
  • the reference points include: N1 (between the UE 192C and the AMF 144), N2 (between RAN 114 and AMF 144), N3 (between RAN 114 and UPF 148), N4 (between the SMF 146 and UPF 148), N5 (between PCF 156 and AF 160), N6 (between UPF 148 and DN 136 such as interface 182A), N7 (between SMF 146 and PCF 156), N8 (between UDM 158 and AMF 144), N9 (between two UPFs 148), N10 (between the UDM 158 and the SMF 146), Ni l (between the AMF 144 and the SMF 146), N12 (between AUSF 142 and AMF 144), N13 (between AUSF 142 and UDM 158), N14 (between two AMFs 144; not shown), N15 (between PCF 156 and AMF 144 in case of a non-
  • the service-based representation of FIG. 1C represents NFs within the control plane that enable other authorized NFs to access their services.
  • the service-based interfaces include: Namf (SBI exhibited by AMF 144), Nsmf (SBI exhibited by SMF 146), Nnef (SBI exhibited by NEF 152), Npcf (SBI exhibited by PCF 156), Nudm (SBI exhibited by the UDM 158), Naf (SBI exhibited by AF 160), Nnrf (SBI exhibited by NRF 154), Nnssf (SBI exhibited by NSSF 150), Nausf (SBI exhibited by AUSF 142).
  • NEF 152 can provide an interface to edge compute nodes 136x, which can be used to process wireless connections with the RAN 114.
  • the system 190C may also include NFs that are not shown such as, for example, UDR, Unstructured Data Storage Function (UDSF), Network Slice Admission Control Function (NSACF), Network Slice-specific and Stand-alone Non-Public Network (SNPN) Authentication and Authorization Function (NSSAAF), UE radio Capability Management Function (UCMF), 5G-Equipment Identity Register (5G-EIR), CHarging Function (CHF), Time Sensitive Networking (TSN) AF 160, Time Sensitive Communication and Time Synchronization Function (TSCTSF), Data Collection Coordination Function (DCCF), Analytics Data Repository Function (ADRF), Messaging Framework Adaptor Function (MFAF), Binding Support Function (BSF), Non-Seamless WLAN Offload Function (NSWOF), Service Communication Proxy (SCP), Security Edge Protection Proxy (SEPP), Non-3GPP InterWorking Function (N3IWF), Trusted Non-3GPP Gateway Function (TNGF), Wireline Access Gateway Function (W-AG), NFs that are not shown
  • the DN 136 may include the Next-generation system management and orchestration such as the framework logic circuitry 100 shown in FIG. 1A.
  • FIG. 2A illustrates an embodiment of a network 2000 in accordance with various embodiments.
  • the network 2000 may operate in a matter consistent with 3GPP technical specifications or technical reports for 6G systems.
  • the network 2000 may operate concurrently with network 190C.
  • the network 2000 may share one or more frequency or bandwidth resources with network 190C.
  • a UE e.g., UE 2002
  • UE 2002 may be configured to operate in both network 2000 and network 190C.
  • Such configuration may be based on a UE including circuitry configured for communication with frequency and bandwidth resources of both networks 190C and 2000.
  • several elements of network 2000 may share one or more characteristics with elements of network 190C.
  • the network 2000 may include a UE 2002, which may include any mobile or non-mobile computing device designed to communicate with a RAN 2008 via an ovcr-thc-air connection.
  • the UE 2002 may be similar to, for example, UE 192C.
  • the UE 2002 may be, but is not limited to, a smartphone, tablet computer, wearable computer device, desktop computer, laptop computer, in-vehicle infotainment, in-car entertainment device, instrument cluster, head-up display device, onboard diagnostic device, dashtop mobile equipment, mobile data terminal, electronic engine management system, electronic/engine control unit, electronic/engine control module, embedded system, sensor, microcontroller, control module, engine management system, networked appliance, machine-type communication device, M2M or D2D device, loT device, etc.
  • the network 2000 may include a plurality of UEs coupled directly with one another via a sidelink interface.
  • the UEs may be M2M/D2D devices that communicate using physical sidelink channels such as, but not limited to, PSBCH, PSDCH, PSSCH, PSCCH, PSFCH, etc.
  • the UE 2002 may be communicatively coupled with an AP such as AP 106 as described with respect to FIG. IB.
  • the RAN 2008 may include one or more ANs such as AN 108 as described with respect to FIG. 1C.
  • the RAN 2008 and/or the AN of the RAN 2008 may be referred to as a base station (BS), a RAN node, or using some other term or name.
  • the UE 2002 and the RAN 2008 may be configured to communicate via an air interface that may be referred to as a sixth generation (6G) air interface.
  • the 6G air interface may include one or more features such as communication in a terahertz (THz) or sub-THz bandwidth, or joint communication and sensing.
  • THz terahertz
  • sub-THz bandwidth may refer to a system that allows for wireless communication as well as radar-based sensing via various types of multiplexing.
  • THz or sub-THz bandwidths may refer to communication in the 80 GHz and above frequency ranges. Such frequency ranges may additionally or alternatively be referred to as “millimeter wave” or “mmWave” frequency ranges.
  • the RAN 2008 may allow for communication between the UE 2002 and a 6G core network (CN) 2010. Specifically, the RAN 2008 may facilitate the transmission and reception of data between the UE 2002 and the 6G CN 2010.
  • the 6G CN 2010 may include various functions such as NSSF 150, NEF 152, NRF 154, PCF 156, UDM 158, AF 160, SMF 146, and AUSF 142.
  • the 6G CN 2010 may additionally include UPF 148 and DN 136 as shown in FIG. 2A.
  • the DN 136 may include application/content servers such as the framework logic circuitry 100 shown in FIG. 1A and/or the application/content servers 138 shown in FIG. IB.
  • a Comm SF 2038 may connect with other Comm SFs 2038 via N9’interfaces, may the UPF 148 via a N19’ interface, and the DN 136 via a N6’ interface.
  • the UPF 148 may connect with other UPFs 148 via a N9 interface and may connect with the DN 136 (such as the framework logic circuitry 100 and/or other application/content servers 138) via a N6 interface (182A).
  • the RAN 2008 may include various additional functions that are in addition to, or alternative to, functions of a legacy cellular network such as a 4G or 5G network.
  • Two such functions may include a Compute Control Function (Comp CF) 2024 and a Compute Service Function (Comp SF) 2036.
  • the Comp CF 2024 and the Comp SF 2036 may be parts or functions of the Computing Service Plane.
  • Comp CF 2024 may be a control plane function that provides functionalities such as management of the Comp SF 2036, computing task context generation and management (e.g., create, read, modify, delete), interaction with the underlaying computing infrastructure for computing resource management, etc.
  • Comp SF 2036 may be a user plane function that serves as the gateway to interface computing service users (such as UE 2002) and computing nodes behind a Comp SF instance. Some functionalities of the Comp SF 2036 may include: parse computing service data received from users to compute tasks executable by computing nodes; hold service mesh ingress gateway or service API gateway; service and charging policies enforcement; performance monitoring and telemetry collection, etc. In some embodiments, a Comp SF 2036 instance may serve as the user plane gateway for a cluster of computing nodes. A Comp CF 2024 instance may control one or more Comp SF 2036 instances.
  • Two other such functions may include a Communication Control Function (Comm CF) 2028 and a Communication Service Function (Comm SF) 2038, which may be parts of the Communication Service Plane.
  • the Comm CF 2028 may be the control plane function for managing the Comm SF 2038, communication sessions creation/configuration/releasing, and managing communication session context.
  • the Comm SF 2038 may be a user plane function for data transport.
  • Comm CF 2028 and Comm SF 2038 may be considered as upgrades of SMF 146 and UPF 148, which were described with respect to a 5G system in FIG. IB.
  • the upgrades provided by the Comm CF 2028 and the Comm SF 2038 may enable service-aware transport. For legacy (c.g., 4G or 5G) data transport, SMF 146 and UPF 148 may still be used.
  • Data CF 2022 may be a control plane function and provides functionalities such as Data SF 2032 management, Data service creation/configuration/releasing, Data service context management, etc.
  • Data SF 2032 may be a user plane function and serve as the gateway between data service users (such as UE 2002 and the various functions of the 6G CN 2010) and data service endpoints behind the gateway. Specific functionalities may include parse data service user data and forward to corresponding data service endpoints, generate charging data, and report data service status.
  • SOCF 2020 may discover, orchestrate and chain up communication/computing/data services provided by functions in the network.
  • SOCF 2020 may interact with one or more of Comp CF 2024, Comm CF 2028, and Data CF 2022 to identify Comp SF 2036, Comm SF 2038, and Data SF 2032 instances, configure service resources, and generate the service chain, which could contain multiple Comp SF 2036, Comm SF 2038, and Data SF 2032 instances and their associated computing endpoints. Workload processing and data movement may then be conducted within the generated service chain.
  • the SOCF 2020 may also be responsible for maintaining, updating, and releasing a created service chain.
  • SRF service registration function
  • NRF 154 may act as the registry for network functions.
  • eSCP evolved service communication proxy
  • SCP service infrastructure control function
  • SICF service infrastructure control function
  • the AMF 2044 may be similar to 144, but with additional functionality. Specifically, the AMF 2044 may include potential functional repartition, such as move the message forwarding functionality from the AMF 2044 to the RAN 2008.
  • SOEF service orchestration exposure function
  • the UE 2002 may include an additional function that is referred to as a computing client service function (comp CSF) 2004.
  • the comp CSF 2004 may have both the control plane functionalities and user plane functionalities, and may interact with corresponding network side functions such as SOCF 2020, Comp CF 2024, Comp SF 2036, Data CF 2022, and/or Data SF 2032 for service discovery, request/response, compute task workload exchange, etc.
  • the Comp CSF 2004 may also work with network side functions to decide on whether a computing task should be run on the UE 2002, the RAN 2008, and/or an element of the 6G CN 2010.
  • the UE 2002 and/or the Comp CSF 2004 may include a service mesh proxy 2006.
  • the service mesh proxy 2006 may act as a proxy for service-to- service communication in the user plane. Capabilities of the service mesh proxy 2006 may include one or more of addressing, security, load balancing, etc.
  • FIG. 2B illustrates an embodiment of network deployments including an example next generation fronthaul (NGF) deployment 2100a
  • a user equipment (UE) 2102 is connected to an RU 2130 (also referred to as a “remote radio unit 2130”, “a remote radio head 2130”, or “RRH 2130”) via an air interface
  • the RU 2130 is connected to a Digital Unit (DU) 2131 via a NGF interface (NGFI)-I
  • the DU 2131 is connected to a Central Unit (CU) 2132 via an NGFI-II
  • the CU 2132 is connected to a core network (CN) 2142 via a backhaul interface.
  • CN core network
  • the DU 2131 may be a distributed unit (for purposes of the present disclosure, the term “DU” may refer to a digital unit and/or a distributed unit unless the context dictates otherwise).
  • the UEs 2102 may be the same or similar to, and/or share one or more features with UE 192C, UE 2002, UE 4005, UE 560, UE 1201, UE 1202, hardware resources 1500, and/or any other UE described herein.
  • the NGF deployment 2100a may be arranged in a distributed RAN (D-RAN) architecture where the CU 2132, DU 2131, and RU 2130 reside at a cell site and the CN 2142 is located at a centralized site.
  • D-RAN distributed RAN
  • the NGF deployment 2100a may be arranged in a centralized RAN (C-RAN) architecture with centralized processing of one or more baseband units (BBUs) at the centralized site.
  • C-RAN architectures the radio components are split into discrete components, which can be located in different locations.
  • the RU 2130 is disposed at the cell site, and the DU 2131, the CU 2132, and the CN 2142 are centralized or disposed at a central location.
  • the RU 2130 and the DU 2131 are located at the cell site, and the CU 2132 and the CN 2142 are at the centralized site.
  • only the RU 2130 is disposed at the cell site, the DU 2131 and the CU 2132 are located a RAN hub site, and the CN 2142 is at the centralized site.
  • the CU 2132 is a central controller that can serve or otherwise connect to one or multiple DUs 2131 and/or multiple RUs 2130.
  • the CU 2132 is network (logical) nodes hosting higher/upper layers of a network protocol functional split.
  • a CU 2132 hosts the radio resource control (RRC), Service Data Adaptation Protocol (SDAP), and/or Packet Data Convergence Protocol (PDCP) layers of a next generation NodeB (gNB), or hosts the RRC and PDCP protocol layers when included in or operating as an E-UTRA-NR gNB (en-gNB).
  • RRC radio resource control
  • SDAP Service Data Adaptation Protocol
  • PDCP Packet Data Convergence Protocol
  • gNB next generation NodeB
  • en-gNB E-UTRA-NR gNB
  • the SDAP sublayer performs mapping between QoS flows and a data radio bearers (DRBs) and marking QoS flow IDs (QFI) in both DL and UL packets.
  • the PDCP sublayer performs transfers user plane or control plane data; maintains PDCP sequence numbers (SNs); header compression and decompression using the Robust Header Compression (ROHC) and/or Ethernet Header Compression (EHC) protocols; ciphering and deciphering; integrity protection and integrity verification; provides timer based SDU discard; routing for split bearers; duplication and duplicate discarding; reordering and in-order delivery; and/or out-of-order delivery.
  • a CU 2132 terminates respective Fl interfaces connected with corresponding DUs 2131.
  • a CU 2132 may include a CU-control plane (CP) entity (referred to herein as “CU-CP 2132”) and a CU-user plane (UP) entity (referred to herein as “CU-UP 2132”).
  • the CU-CP 2132 is a logical node hosting the RRC layer and the control plane part of the PDCP protocol layer of the CU 2132 (e.g., a gNB-CU for an en-gNB or a gNB).
  • the CU-CP terminates an El interface connected with the CU-UP and the Fl -C interface connected with a DU 2131 .
  • the CU-UP 2132 is a logical node hosting the user plane part of the PDCP protocol layer (c.g., for a gNB-CU 2132 of an en-gNB), and the user plane part of the PDCP protocol layer and the SDAP protocol layer (e.g., for the gNB-CU 2132 of a gNB).
  • the CU-UP 2132 terminates the El interface connected with the CU-CP 2132 and the Fl-U interface connected with a DU 2131.
  • the DU 2131 controls radio resources, such as time and frequency bands, locally in real time, and allocates resources to one or more UEs.
  • the DUs 2131 are network (logical) nodes hosting middle and/or lower layers of the network protocol functional split.
  • a DU 2131 hosts the radio link control (RLC), medium access control (MAC), and high-physical (PHY) layers of the gNB or en-gNB, and its operation is at least partly controlled by the CU 2132.
  • the RLC sublayer operates in one or more of a Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM).
  • TM Transparent Mode
  • UM Unacknowledged Mode
  • AM Acknowledged Mode
  • the RLC sublayer performs transfer of upper layer PDUs; sequence numbering independent of the one in PDCP (UM and AM); error Correction through ARQ (AM only); segmentation (AM and UM) and re- segmentation (AM only) of RLC SDUs; reassembly of SDU (AM and UM); duplicate detection (AM only); RLC SDU discard (AM and UM); RLC re-establishment; and/or protocol error detection (AM only).
  • the MAC sublayer performs mapping between logical channels and transport channels; multiplexing/demultiplexing of MAC SDUs belonging to one or different logical channels into/from transport blocks (TB) delivered to/from the physical layer on transport channels; scheduling information reporting; error correction through HARQ (one HARQ entity per cell in case of CA); priority handling between UEs by means of dynamic scheduling; priority handling between logical channels of one UE by means of logical channel prioritization; priority handling between overlapping resources of one UE; and/or padding.
  • HARQ one HARQ entity per cell in case of CA
  • a DU 2131 can host a Backhaul Adaptation Protocol (BAP) layer and/or a Fl application protocol (F1AP), such as when the DU 2131 is operating as an Integrated Access and Backhaul (IAB) node.
  • BAP Backhaul Adaptation Protocol
  • F1AP Fl application protocol
  • One DU 2131 supports one or multiple cells, and one cell is supported by only one DU 2131.
  • a DU 2131 terminates the Fl interface connected with a CU 2132. Additionally, or alternatively, the DU 2131 may be connected to one or more RRHs/RUs 2130.
  • the RU 2130 is a transmission/reception point (TRP) or other physical node that handles radiofrequency (RF) processing functions.
  • the RU 2130 is a network (logical) node hosting lower layers based on a lower layer functional split.
  • the RU 2130 hosts low-PHY layer functions and RF processing of the radio interface based on a lower layer functional split.
  • the RU 2130 may be similar to 3GPP’s transmission/reception point (TRP) or RRH, but specifically includes the Low-PHY layer. Examples of the low-PHY functions include fast Fourier transform (FFT), inverse FFT (iFFT), physical random-access channel (PRACH) extraction, and the like.
  • FFT fast Fourier transform
  • iFFT inverse FFT
  • PRACH physical random-access channel
  • Each of the CUs 2132, DUs 2131, and RUs 2130 are connected through respective links, which may be any suitable wireless and/or wired (e.g., fiber, copper, and the like) links.
  • various combinations of the CU 2132, DU 2131, and RU 2130 may correspond to one or more of the RAN 104, AN 108, AP 106, and/or any other NAN, such as any of those discussed herein.
  • a fronthaul gateway function may be disposed between the DU 2131 and the RU/RRU 2130 (not shown by FIG. 2B), where the interface between the DU 2131 and the FHGW is an Open Fronthaul (e.g., Option 7-2x) interface, the interface between FHGW function and the RU/RRU 2130 is an Open Fronthaul (e.g., Option 7-2x) interface or any other suitable interface (e.g., option 7, option 8, or the like) including those that do not support Open Fronthaul (e.g., Option 7-2x).
  • the FHGW may be packaged with one or more other functions (e.g., Ethernet switching and/or the like) in a physical device or appliance.
  • a RAN controller may be communicatively coupled with the CU 2132 and/or the DU 2131.
  • the NGFI (also referred to as “xHaul” or the like) is a two-level fronthaul architecture that separates the traditional RRU 2130 to BBU connectivity in the C-RAN architecture into two levels, namely levels I and II.
  • Level I connects the RU 2130 via the NGFLI to the DU 2131
  • level II connects the DU 2131 via the NGFI-II to the CU 2132 as shown by deployment 2100a in FIG. 2B.
  • the NGFI-I and NGFI-II connections may be wired connections or wireless connections, which may utilize any suitable RAT such as any of those discussed herein.
  • the purpose of the two-level architecture is to distribute (split) the RAN node protocol functions between CU 2132 and DU 2131 such that latencies are relaxed, giving more deployment flexibilities.
  • the NGFLI interfaces with the lower layers of the function split which have stringent delay and data rate requirements, whereas NGFI-II interfaces with higher layers of the function split relative to the layers of the NGFI-I, relaxing the requirements for the fronthaul link.
  • Examples of the NGFI fronthaul interfaces and functional split architectures include O- RAN 7.2x fronthaul, Enhanced Common Radio Interface (CPRI) based C-RAN fronthaul Common Public Radio Interface: Requirements for the eCPRI Transport Network, eCPRI Transport Network vl.2, Radio over Ethernet (RoE) based C-RAN fronthaul, and/or the like.
  • CPRI Common Radio Interface
  • RoE Radio over Ethernet
  • the deployment 2100a may implement a low-level split (LLS) (also referred to as a “Lower Layer Functional Split 7-2x” or “Split Option 7-2x”) that runs between the RU 2130 (e.g., an O-RU in O-RAN architectures) and the DU 2131 (e.g., an O-DU in O-RAN architectures).
  • LLS low-level split
  • Other LLS options may be used.
  • the CUs 2132, DUs 2131, and/or RUs 2130 may be IAB nodes.
  • IAB enables wireless relaying in an NG-RAN where a relaying node (referred to as an “lAB-node”) supports access and backhauling via 3GPP 5G/new radio (NR) links/interfaces.
  • the terminating node of NR backhauling on the network side is referred to as an “lAB-donor”, which represents a RAN node (e.g., a gNB) with additional functionality to support IAB.
  • Backhauling can occur via a single or via multiple hops.
  • All lAB-nodes that are connected to an lAB-donor via one or multiple hops form a directed acyclic graph (DAG) topology with the lAB-donor as its root.
  • DAG directed acyclic graph
  • the lAB-donor performs centralized resource, topology and route management for the IAB topology.
  • the NGF deployment 2100a shows the CU 2132, DU 2131, RRH 2130, and CN 2142 as separate entities, in other implementations some or all of these network nodes can be bundled, combined, or otherwise integrated with one another into a single device or element, including collapsing some internal interfaces (e.g., Fl-C, Fl-U, El, E2, and the like).
  • some internal interfaces e.g., Fl-C, Fl-U, El, E2, and the like.
  • integrating the CU 2132 and the DU 2131 e.g., a CU-DU
  • the DU 2131 and the RRH 2130 integrated e.g., CU-DU
  • integrating the network controller or intelligent controller
  • FIG. 2B also shows an example RAN disaggregation deployment 2100b (also referred to as “disaggregated RAN 2100b”) where the UE 2102 is connected to the RRH 2130, and the RRH 2130 is communicatively coupled with one or more of the RAN functions (RANFs) 1-N (where N is a number).
  • the RANFs 1-N arc disaggregated and distributed geographically across several component segments and network nodes.
  • each RANF 1-N is a software (SW) element operated by a physical compute node and the RRH 2130 includes radiofrequency (RF) circuitry (e.g., an RF propagation module for a particular RAT and/or the like).
  • SW software
  • RF radiofrequency
  • the RANF 1 is operated on a physical compute node that is co-located with the RRH 2130 and the other RANFs are disposed at locations further away from the RRH 2130.
  • the CN 2142 is also disaggregated into CN NFs 1-x (where x is a number) in a same or similar manner as the RANFs 1-N, although in other implementations the CN 2142 is not disaggregated.
  • Network disaggregation involves the separation of networking equipment into functional components and allowing each component to be individually deployed. This may encompass separation of SW elements (e.g., NFs) from specific HW elements and/or using APIs to enable software defined network (SDN) and/or and NF virtualization (NFV).
  • SW elements e.g., NFs
  • SDN software defined network
  • NFV NF virtualization
  • RAN disaggregation involves network disaggregation and virtualization of various RANFs (e.g., RANFs 1-N in FIG. 2B).
  • the RANFs 1-N can be placed in different physical sites in various topologies in a RAN deployment based on the use case.
  • Disaggregation offers a common or uniform RAN platform capable of assuming a distinct profile depending on where it is deployed. This allows fewer fixed-function devices, and a lower total cost of ownership, in comparison with existing RAN architectures.
  • Example RAN disaggregation frameworks are provided by Telecom Infra Project (TIP) OpenRANTM, Cisco® Open vRANTM, [O-RAN], Open Optical & Packet Transport (OOPT), Reconfigurable Optical Add Drop Multiplexer (ROADM), and/or the like.
  • TIP Telecom Infra Project
  • IP Telecom Infra Project
  • OOPT Open Optical & Packet Transport
  • ROADM Reconfigurable Optical Add Drop Multiplexer
  • the RANFs 1-N disaggregate RAN HW and SW with commercial off-the-shelf (COTS) HW and open interfaces (e.g., NGFI-I and NGFI-II, and the like).
  • COTS commercial off-the-shelf
  • each RANF 1-N may be a virtual BBU or vRAN controller operating on COTS compute infrastructure with HW acceleration for BBU/vRANFs.
  • the RANFs 1-N disaggregate layers of one or more RAT protocol stacks.
  • RANF 1 is a DU 2131 operating on first COTS compute infrastructure with HW acceleration for BBU/vRANFs
  • RANF 2 is a virtual CU 2132 operating on second COTS compute infrastructure.
  • the RANFs 1-N disaggregate control plane and user plane functions.
  • the RANF 1 is a DU 2131 operating on COTS compute infrastructure with HW acceleration for BBU/vRANFs
  • RANF 2 is a virtual CU-CP 2132 operating on COTS compute infrastructure
  • a third RANF e.g., RANF 3 (not shown by FIG. 2B)
  • RANF 3 is a virtual CU-UP 2132 operating on the same or different COTS compute infrastructure as the virtual CU-CP 2132.
  • one or more CN NFs 1-x may be CN-UP functions and one or more other CN NFs 1-x may be CN-CP functions.
  • the RANFs 1-N disaggregate layers of an [IEEE802] RAT.
  • the RRH 2130 implements a WiFi PHY layer
  • RANF 1 implements a WiFi MAC sublayer
  • RANF 1 implements a WiFi logical link control (LLC) sublayer
  • RANF 2 implements one or more WiFi upper layer protocols (e.g., network layer, transport layer, session layer, presentation layer, and/or application layer), and so forth.
  • WiFi upper layer protocols e.g., network layer, transport layer, session layer, presentation layer, and/or application layer
  • the RANFs 1-N disaggregate different O-RAN RANFs including E2SMs.
  • RANF 1 implements the near-RT RIC
  • RANF 2 implements the E2SM-KPM
  • RANF 3 implements the E2SM-CCC
  • RANF 4 implements the E2SM RAN control
  • RANF 5 implements the E2SM-NI
  • RANF 6 implements functions for providing Al services, and so forth.
  • the lower layers of the RAN protocol stack can be characterized by real-time (RT) functions and relatively complex signal processing algorithms, and the higher layers of the RAN protocol stack can be characterized by non-RT functions.
  • the RT functions and signal processing algorithms can be implemented in DUs 2131 and/or RRHs 2130 either using purpose-built network elements or in COTS hardware augmented with purpose-built HW accelerators.
  • FIG. 2B also shows various functional split options 2100c, for both DL and UL directions.
  • the traditional RAN is an integrated network architecture based on a distributed RAN (D-RAN) model, where D-RAN integrates all RANFs into a few network elements.
  • D-RAN distributed RAN
  • the disaggregated RAN architecture provides flexible function split options to overcome various drawbacks of the D-RAN model.
  • the disaggregated RAN breaks up the integrated network system into several function components that can then be individually relocated as needed without hindering their ability to work together to provide a holistic network services.
  • the split options 2100c are mostly split between the CU 2132 and the DU 2131, but can include a split between the CU 2132, DU 2131, and RU 2130.
  • the Option 2 function split includes splitting non-RT processing (e.g., RRC and PDCP layers) from RT processing (e.g., RLC, MAC, and PHY layers), where the RANF implementing the CU 2132 performs network functions of the RRC and PDCP layers, and the RANF implementing the DU 2131 performs the baseband processing functions of the RLC (including high-RLC and low-RLC), MAC (including high-MAC and low MAC), and PHY layers.
  • non-RT processing e.g., RRC and PDCP layers
  • RT processing e.g., RLC, MAC, and PHY layers
  • the RANF implementing the CU 2132 performs network functions of the RRC and PDCP layers
  • the RANF implementing the DU 2131 performs the baseband processing functions of the RLC (including high-RLC and low-RLC), MAC (including high-MAC and low MAC), and PHY layers.
  • the PHY layer is further split between the DU 2131 and the RU 2130, where the RANF implementing the DU 2131 performs the high-PHY layer functions and the RU 2130 handles the low-PHY layer functions.
  • the Low-PHY entity may be operated by the RU 2130 regardless of the selected functional split option.
  • the RANF implementing the CU 2132 can connect to multiple DU 2131 (e.g., the CU 2132 is centralized), which allows RRC and PDCP anchor change to be eliminated during a handover across DUs 2131 and allows the centralized CU 2132 to pool resources across several DUs 2131. In these ways, the option 2 function split can improve resource efficiencies.
  • each protocol stack entity is operated by a respective RANF (e.g., a first RANF operates the RRC layer, a second RANF operates the PDCP layer, a third RANF operates the high-RLC layer, and so forth until an eighth RANF operates the low-PHY layer).
  • a respective RANF e.g., a first RANF operates the RRC layer, a second RANF operates the PDCP layer, a third RANF operates the high-RLC layer, and so forth until an eighth RANF operates the low-PHY layer.
  • FIG. 3A provides an embodiment of Service Based Management Architecture (SBMA) 3000.
  • SBMA Service Based Management Architecture
  • MnS Management Service
  • An MnS is a set of offered capabilities for management and orchestration (MANO) of network and services.
  • the entity producing an MnS is referred to as an "‘MnS producer” and the entity consuming an MnS is referred to as an “MnS consumer”.
  • An MnS provided by an MnS producer can be consumed by any entity with appropriate authorization and authentication.
  • an MnS may be established and configured for a device of the communications network via framework logic circuitry such as the framework logic circuitry 100 shown in FIG. 1A.
  • an MnS producer offers its services via a standardized service interface composed of individually specified MnS components.
  • a MnS is specified using different independent components.
  • a concrete MnS includes at least two of these components.
  • Three different component types are defined, including MnS component type A, MnS component type B, and MnS component type C.
  • the MnS component type A is a group of management operations and/or notifications that is agnostic with regard to the entities managed.
  • the operations and notifications as such are hence not involving any information related to the managed network.
  • These operations and notifications are called generic or network agnostic. For example, operations for creating, reading, updating and deleting managed object instances, where the managed object instance to be manipulated is specified only in the signature of the operation, are generic.
  • the MnS component type B refers to management information represented by information models representing the managed entities.
  • a MnS component type B is also called Network Resource Model (NRM).
  • MnS component type B include network resource models (see e.g., 3GPP TS 28.622 v 18.2.0 (2023-03-30) (“[TS28622]”)) and network resource models (see e.g., 3GPP TS 28.541 vl8.3.1 (2023-04-05) (“[TS28541]”)).
  • the MnS component type C is performance information of the managed entity and fault information of the managed entity.
  • management service component type C include alarm information (see e.g., 3GPP TS 28.532 vl7.3.0 (2023-01-06) (“[TS28532]”) and TS 28.545 V17.0.0 (2021-06-24)) and performance data (see e.g., [TS28552], 3GPP TS 28.554 vl8.0.0 (2023-01-06) (“[TS28554]”), and [TS32425]).
  • MnS producer profile A MnS producer is described by a set of meta data called MnS producer profile.
  • the profile holds information about the supported MnS components and their version numbers. This may include also information about support of optional features. For example, a read operation on a complete subtree of managed object instances may support applying filters on the scoped set of objects as optional feature. In this case, the MnS profile should include the information if filtering is supported.
  • FIG. 3B shows an embodiment, of a management function (MnF) 3005.
  • MnF Management Function
  • a Management Function (MnF) is a logical entity playing the roles of MnS consumer and/or MnS producer.
  • a Management Service produced by MnF may have multiple consumers.
  • the MnF may consume multiple MnS from one or multiple MnS producers.
  • the MnF 3005 is an embodiment of an MnF playing both roles (e.g., MnS producer and MnS consumer). Note that an MnF 3005 may be established and configured for a device of the communications network via framework logic circuitry such as the framework logic circuitry 100 shown in FIG. 1A.
  • FIG. 3C shows embodiments 3010 and 3015 of MnFs deployed as separate entities and embedded in a network function (NF).
  • the Management Function can be deployed as a separate entity or embedded in Network Function to provide MnS(s).
  • FIG. 3C shows an example (a) which MnF deployed as a separate entity to provide MnS(s) and another example (b) which MnF is embedded in Network Function to provide MnS(s):
  • the 3GPP management system is also capable to consume NFV MANO interface (e.g., Os- Ma-nfvo, Ve-Vnfm-em, and Ve-Vnfm-vnf reference points).
  • NFV MANO interface e.g., Os- Ma-nfvo, Ve-Vnfm-em, and Ve-Vnfm-vnf reference points.
  • a producer of management services can consume management interfaces provided by NFV MANO for following purposes: network service LCM; and VNF LCM, PM, FM, CM on resources supporting VNF.
  • FIG. 3D shows an embodiment of a framework 3020 of provisioning a management service (MnS) where an MnS producer interfaces to ETSI NFV MANO to support lifecycle management of VNFs.
  • MnS management service
  • FIG. 3E shows an embodiment of an autonomous network (AON) 3025.
  • AON autonomous network
  • Many networks have become complex due to a large number of devices and diversity of services. Different autonomy mechanisms are introduced in the industry to reduce the complexity of network management and control.
  • the ultimate goal for an AON is to enable telecommunication systems (including a management system such as the framework logic circuitry 100 shown in FIG. 1A and a communications network such as the 6G network 180A shown in FIG. 1A) and/or other networks/systems to be governed by itself with minimal to no human intervention by utilizing the autonomy mechanisms (e.g., including intelligence mechanisms (e.g., AI/ML), automation mechanisms (e.g., rule-based automatic control, heuristics, and/or the like), and other mechanisms to enable the autonomous networks).
  • Autonomous networks can reduce the OpEx associated with the autonomous management and control of the complexity network and improve the service experience to enable various vertical industries (e.g., autonomous vehicle, smart city).
  • an AON is a communication system such as a telecommunication system and/or any other network/system (including a management system such as the framework logic circuitry 100 shown in FIG. 1 A and a communications network such as the 6G network 180A shown in FIG. 1A), or collection of various nctworks/systcms, with autonomy capabilities, which is able to be governed by itself with minimal to no human intervention.
  • an autonomous network level is a level of autonomy capabilities in the AON. Examples of enablers for AONs include self-organization networks (SONs) and/or SON functions, management data analytics (MDA), intent driven management (IDM), and closed loop Service Level Specification (SLS) assurance.
  • ANL is used to describe the levels of autonomy capabilities in the AON to improve the efficiency for network management and control. Participation of the human and telecommunication system and/or other network(s) in the network management and control workflow are different for each level and are important factors to evaluate the ANLs. For each ANL, some tasks can be performed by communications system and/or other network(s), some performed by human, and some performed by cooperation of human and communications system and/or other network(s). For example, in the highest ANL, all tasks are performed by communications system and/or other network(s).
  • Example dimensions for evaluating ANLs include scenarios, management scope, and workflow.
  • the AON can be implemented for different scenarios, the complexity of AON depends on the detailed scenarios where it is applied. Also, it will be more challenging for the telecommunication system and/or other network(s) to achieve the AON for full scenarios than for certain scenarios. The autonomy capabilities of the scenarios will impact the ANL for the whole AON.
  • Example scenario types categorized by network and service management process for AONs can include; network and service planning such as planning 111A, simulation 112A, and emulation 113A shown in FIG. 1 A; network and service deployment such as establishment 114A and configuration 115A shown in FIG. 1A; network and service maintenance such as healing 117A and protection 118A shown in FIG. 1A; network and service optimization such as optimization 116A shown in FIG. 1 A.
  • the autonomy can be implemented in different scopes, the complexity of AON depends on its applicable scope. For example, it will be more challenging for the telecommunication system and/or other network(s) to achieve the AON on cross domain network layer than domain network layer, because more autonomy mechanisms need to be introduced for the coordination between different domains. The autonomy capabilities of the management scope will impact the ANL for the whole AON.
  • Example applicable scopes for AONs can include: autonomy in network element/network function (NE/NF) layer, which means the autonomy mechanisms are executed in the NE/NF; autonomy in domain network layer, which means the autonomy mechanisms are executed in the MnF(s) in domain; autonomy in cross domain network layer, which means the autonomy mechanisms are executed in the MnF(s) in cross domain; and/or autonomy in communication service layer, which means the autonomy mechanisms are executed in MnF(s) for communication service.
  • NE/NF network element/network function
  • FIG. 3F shows an embodiment of a workflow 3030 such as the intelligence and autonomy 120A workflow shown in FIG. 1A.
  • the workflow 3030 is used to describe the actions to achieve certain management and control purposes.
  • a workflow is composed of one or more management and control tasks. Each workflow task may be accomplished by human (no or minimal autonomy), or accomplished by telecommunication system and/or other network(s) with human assistance (partial autonomy), or accomplished by telecommunication system and/or other network(s) without human intervention (autonomously).
  • the autonomy capabilities of the tasks in the workflow may impact the ANL.
  • Examples of categorization of the tasks in a workflow can include one or more of the following:
  • Intent handling The group of tasks which translate network or service intent from operator or customer into detailed operations and/or control information which may affect one or more of the following groups of tasks (e.g., observation/awareness, analysis, decision, execution), also evaluate and feedback intent fulfilment information (e.g., the intent is satisfied or not) based on the detailed communications network and service information.
  • groups of tasks e.g., observation/awareness, analysis, decision, execution
  • feedback intent fulfilment information e.g., the intent is satisfied or not
  • Observation The group of tasks which include network and service data (e.g., configuration data, performance data, alarm data, etc.) collection and necessary data preprocessing (e.g., data cleaning, filtering, statistics, etc.) with the purpose of monitoring network and service information (including network and service performance, network and service anomaly, network and service event, etc.).
  • network and service data e.g., configuration data, performance data, alarm data, etc.
  • necessary data preprocessing e.g., data cleaning, filtering, statistics, etc.
  • the group of tasks which analyze the obtained network and service information e.g., network and service status, network and service issues, and so on
  • the obtained network and service information e.g., network and service status, network and service issues, and so on
  • the historical network and service information e.g., network and service information, network and service issues, and so on
  • Execution The group of tasks which execute the operations.
  • FIG. 3G shows an embodiment of a table 3035 describing levels of autonomy.
  • a framework approach for evaluating ANLs may be as follows, which may be used for evaluating the autonomy capability of a communications system such as the 6G network 180A shown in FIG. 1A.
  • the term "Human” represents corresponding tasks are accomplished by human or human utilizing the tools for network and service management and orchestration such as network and service management and orchestration 120A shown in FIG.
  • the term “Human & System” represents corresponding tasks are accomplished by collaboration of human and the communications system and/or other network(s)/system(s), the detailed collaboration pattern depends on the scenario, which is not addressed in the framework approach for evaluating ANLs; and the term “System” represents corresponding tasks are fully accomplished by the communications system and/or other network(s)/system(s).
  • framework logic circuitry such as the framework logic circuitry 100 shown in FIG. 1A may achieve one or more or all the following levels of autonomy for one or more or all network services.
  • configuration of a network service involves installation of additional hardware such as base stations (RANs) or other equipment, a degree of human activity may be required.
  • RANs base stations
  • Level 0 manual operating network No categorization of the tasks is accomplished by communications system itself.
  • Level 1 assisted operating network A part of the execution and awareness tasks are accomplished automatically by communications system itself based on human defined control information. At this level, communications system can assist human to improve the execution and awareness efficiency.
  • Level 2 preliminary AON All the execution tasks are accomplished automatically by communications system itself. A part of the obscrvation/awarcncss and analysis tasks arc accomplished automatically by communications system itself based on human defined control information. At this level, communications system can assist human to achieve the closed loop based on human defined control information.
  • Level 3 intermediate AON All the execution and observation/awareness tasks are accomplished automatically by communications system itself. A part of the analysis and decision tasks are accomplished automatically by communications system itself based on human defined control information. At this level, the communications system can achieve the closed loop automation based on the human defined closed loop automation control information.
  • Level 4 advanced AON All the execution, obscrvation/awarcncss, analysis and decision tasks are accomplished automatically by communications system itself. And intent handling tasks can be partly accomplished automatically by communications system itself based on human defined intent handling control information.
  • communications system can achieve the intent driven closed loop automation based on human defined intent handling control information, which means the communications system can translate the intent to the detailed closed loop automation control information and translate the detailed network and service information to intent fulfilment information (e.g., the intent is satisfied or not) based on human defined intent handling control information.
  • Level 5 fully AON: The entire network autonomy workflow is accomplished automatically by communications system without human intervention. At this level, communications system can achieve the whole network autonomy.
  • the above framework approach for evaluating ANLs may be applicable for evaluating the ANLs from both management scope and scenario perspective.
  • the overall ANL of the whole network/system is a comprehensive reflection of ANL of the individual management scope and scenarios, which means in fully ANL, the communications system can achieve the whole network autonomy for all management scopes and scenarios.
  • the control information in the present document represents the information which can be formatted as rules or policies to assist/control the framework logic circuitry to perform corresponding tasks in an autonomous manner, and/or configurations and/or data structures including various conditions, parameters, attributes, and/or the like.
  • FIG. 3H shows an embodiment of a neural network 3040 (an example of an AI/ML model).
  • Machine learning involves programming computing systems to optimize a performance criterion using example (training) data and/or past experience such as training 132A shown in FIG. 1A.
  • ML refers to the use and development of computer systems that are able to learn and adapt without following explicit instructions, by using algorithms and/or statistical models to analyze and draw inferences from patterns in data.
  • ML involves using algorithms to perform specific task(s) without using explicit instructions to perform the specific task(s), but instead relying on learnt patterns and/or inferences.
  • ML uses statistics to build mathematical model(s) such as ML model 131 A shown in FIG. 1A (also referred to as “ML models” or simply “models”) in order to make predictions or decisions based on sample data (e.g., training data).
  • the model is defined to have a set of parameters, and learning is the execution of a computer program to optimize the parameters of the model using the training data or past experience.
  • the trained model may be a predictive model that makes predictions based on an input dataset, a descriptive model that gains knowledge from an input dataset, or both predictive and descriptive. Once the model is learned (trained), it can be used to make inferences (e.g., predictions).
  • NNs data and neural networks
  • the NN 3040 which may be suitable for use by one or more of the computing systems (or subsystems) of the various implementations discussed herein, implemented in part by a HW accelerator, and/or the like.
  • the NN 3040 may be deep neural network (DNN) used as an artificial brain of a compute node or network of compute nodes to handle very large and complicated observation spaces.
  • DNN deep neural network
  • the NN 3040 can be some other type of topology (or combination of topologies), such as a convolution NN (CNN), deep CNN (DCN), recurrent NN (RNN), Long Short Term Memory (LSTM) network, a Deconvolutional NN (DNN), gated recurrent unit (GRU), deep belief NN, a feed forward NN (FFN), a deep FNN (DFF), deep stacking network, Markov chain, perception NN, stochastic NN, Bayesian Network (BN) or Bayesian NN (BNN), Dynamic BN (DBN), Linear Dynamical System (LDS), Switching LDS (SLDS), Optical NNs (ONNs), an NN for reinforcement learning (RL) and/or deep RL (DRL), and/or the like.
  • NNs are usually used for supervised learning, but can be used for unsupervised learning and/or RL.
  • the NN 3040 may encompass a variety of ML techniques where a collection of connected artificial neurons 3041, 3044, 3047, 3050 and 3054 that (loosely) model neurons in a biological brain that transmit signals to other neurons/nodes 3041 , 3044, 3047, 3050 and 3054.
  • the neurons 3041, 3044, 3047, 3050 and 3054 may also be referred to as nodes, processing elements (PEs), or the like.
  • PEs processing elements
  • the connections 3042, 3046, 3048, and 3052 (or edges) between the neurons 3041, 3044, 3047, 3050 and 3054 are (loosely) modeled on synapses of a biological brain and convey the signals between no neurons 3041, 3044, 3047, 3050 and 3054. Note that not all neurons 3041, 3044, 3047, 3050 and 3054 and connections 3042, 3046, 3048 are labeled for the sake of clarity.
  • Each connection 3042, 3046, and 3048 has one or more inputs and produces an output, which can be sent to one or more other connections 3042, 3046, and 3048 (the inputs and outputs may be referred to as “signals”).
  • Inputs to the neurons 3041 of the input layer L_x can be feature values of a sample of external data (e.g., input variables x_i).
  • the input variables x_i can be set as a vector containing relevant data (e.g., observations, ML features, and the like).
  • the inputs to hidden units, neurons 3044, 3047, and 3050, of the hidden layers L_a, L_b, and L_c, respectively, may be based on the outputs of other neurons.
  • the outputs of the final output neurons 3054 of the output layer L_y include predictions, inferences, and/or accomplish a desired/configured task.
  • the output variables yj may be in the form of determinations, inferences, predictions, and/or assessments. Additionally, or alternatively, the output variables yj can be set as a vector containing the relevant data (e.g., determinations, inferences, predictions, assessments, and/or the like).
  • an “ML feature” (or simply “feature”) is an individual measurable property or characteristic of a phenomenon being observed.
  • Features are usually represented using numbers/numerals (e.g., integers), strings, variables, ordinals, real-values, categories, and/or the like.
  • ML features are individual variables, which may be independent variables, based on observable phenomenon that can be quantified and recorded.
  • ML models use one or more features to make predictions or inferences. In some implementations, new features can be derived from old features.
  • Neurons 3041, 3044, 3047, 3050 and 3054 may have a threshold such that a signal is sent only if the aggregate signal crosses that threshold.
  • a neuron 3041, 3044, 3047, 3050 and 3054 may include an activation function (a), which defines the output of that neuron 3041, 3044, 3047, 3050 and 3054 given an input or set of inputs.
  • a neuron 3041, 3044, 3047, 3050 and 3054 may include a propagation function that computes the input to a neuron 3041 , 3044, 3047, 3050 and 3054 from the outputs of its predecessor neurons 3041 , 3044, 3047, 3050 and 3054 and their connections 3042, 3046, and 3048 as a weighted sum.
  • a bias term can also be added to the result of the propagation function.
  • the NN 3040 also includes connections 3042, 3046, and 3048, some of which provide the output of at least one neuron 3041, 3044, 3047, 3050 and 3054 as an input to at least another neuron 3041, 3044, 3047, 3050 and 3054.
  • Each connection 3042, 3046, and 3048 may be assigned a weight that represents its relative importance. The weights may also be adjusted as learning proceeds. The weight increases or decreases the strength of the signal at a connection 3042, 3046, and 3048.
  • the neurons 3041, 3044, 3047, 3050 and 3054 can be aggregated or grouped into one or more layers L where different layers L may perform different transformations on their inputs.
  • the NN 3040 comprises an input layer L_x, one or more hidden layers L_a, L_b, and L_c, and an output layer L_y (where a, b, c, x, and y may be numbers), where each layer L comprises one or more neurons 3041, 3044, 3047, 3050 and 3054.
  • Signals travel from the first layer (e.g., the input layer L_l), to the last layer (e.g., the output layer L_y), possibly after traversing the hidden layers L_a, L_b, and L_c multiple times.
  • the NN 3040 may include many more (or fewer) hidden layers L_a, L_b, and L_c than are shown.
  • FIG. 31 illustrates an embodiment of a reinforcement learning (RL) architecture 3060 comprising an agent 3062 and an environment 3064.
  • the agent 3062 e.g., software agent or Al agent
  • the environment 3064 comprises everything outside the agent 3062 with which the agent 3062 interacts.
  • the environment 3064 is typically stated in the form of a Markov decision process (MDP), which may be described using dynamic programming techniques.
  • MDP Markov decision process
  • An MDP is a discrete-time stochastic control process that provides a mathematical framework for modeling decision making in situations where outcomes are partly random and partly under the control of a decision maker.
  • RL is a goal-oriented learning based on interaction with environment.
  • RL is an ML paradigm concerned with how software agents (or Al agents) ought to take actions in an environment to maximize a numerical reward signal.
  • RL involves an agent taking actions in an environment that is/are interpreted into a reward and a representation of a state, which is then fed back into the agent.
  • an agent aims to optimize a long-term objective by interacting with the environment based on a trial-and-error process.
  • the agent receives a reward in the next time step (or epoch) to evaluate its previous action. Examples of RL algorithms include Markov decision process (MDP) and Markov chains, associative RL, inverse RL, safe RL, Q-learning, multi-armed bandit learning, and deep RL.
  • MDP Markov decision process
  • RL Markov chains
  • the agent 3062 and environment 3064 continually interact with one another, wherein the agent 3062 selects actions At to be performed and the environment 3064 responds to these Actions and presents new situations (or states S) to the agent 3062.
  • the action At comprises all possible actions, tasks, moves, and/or the like., that the agent 3062 can take for a particular context.
  • the state S is a current situation such as a complete description of a communications system or subset thereof, a unique configuration of information in a program or machine, a snapshot of a measure of various conditions in a communications system, and/or the like.
  • the agent 3062 selects an action At to take based on a policy n.
  • the environment 3064 also gives rise to rewards R, which are numerical values that the agent 3062 seeks to maximize over time through its choice of actions.
  • the state S may include one or more metrics related to the communications network such as one or more performance metrics (data throughput, bit error rate, durations of time for UL or DL communications, a combination thereof, other performance metrics, or the like) between one or more devices of the communications network such as UEs and RANs.
  • the reward R may reflect a change in one or more performance metrics.
  • the objective of the agent 3062 may comprise a function to maximize performance metrics and/or to raise the one or more performance metrics above minimum threshold values for the performance metrics.
  • the policy n may comprise a complex or simple algorithm to train the agent 3062 on the effects of each action At such as to train the agent 3062 which actions tend to change the one or more performance metrics in a direction towards the objective.
  • the environment 3064 starts by sending a state St to the agent 3062.
  • the environment 3064 also sends an initial a reward Rt to the agent 3062 with the state St.
  • the agent 3062 based on its knowledge, takes an action At in response to that state St, (and reward Rt, if any).
  • the action At is fed back to the environment 3064, and the environment 3064 sends a state-reward pair including a next state St+1 and reward Rt+1 to the agent 3062 based on the action At.
  • the agent 3062 may update its knowledge with the reward Rt+1 returned by the environment 3064 to evaluate its previous action(s). The process repeats until the environment 3064 sends a terminal state S, which ends the process or episode. Additionally, or alternatively, the agent 3062 may take a particular action A to optimize a value V.
  • the value V an expected long-term return with discount, as opposed to the short-term reward R.
  • V7t(S) is defined as the expected long-term return of the current state S under policy .
  • Q-learning is a model-free RL algorithm that learns the value of an action in a particular state.
  • Q-learning does not require a model of an environment 3064 and can handle problems with stochastic transitions and rewards without requiring adaptations.
  • the "Q" in Q-leaming refers to the function that the algorithm computes, which is the expected reward(s) for an action A taken in a given state S.
  • a Q-value is computed using the state St and the action At at time t using the function Q/rtSt , At).
  • QzrfSt , At) is the long-term return of a current state S taking action A under policy it.
  • DQN Deep Q-Nctwork
  • Double DQN Double DQN
  • Dueling DQN DQN is formed by substituting the Q-function of the Q-learning by an artificial neural network (ANN) such as a convolutional neural network (CNN).
  • ANN artificial neural network
  • CNN convolutional neural network
  • FIG. 4 illustrates an embodiment of a simplified block diagram of artificial (Al)-assisted communication between a UE 4005 and a RAN 4010, such as UE 190C and RAN 104 shown in FIG. 1C, in accordance with various embodiments. More specifically, as described in further detail below, Al/machinc learning (ML) models may be used or leveraged to facilitate over-the- air communication between UE 4005 and RAN 4010.
  • Al/machinc learning (ML) models may be used or leveraged to facilitate over-the- air communication between UE 4005 and RAN 4010.
  • One or both of the UE 4005 and the RAN 4010 may operate in a matter consistent with 3GPP technical specifications or technical reports for 6G systems.
  • the wireless cellular communication between the UE 4005 and the RAN 4010 may be part of, or operate concurrently with, networks 2000, 190C, and/or some other network described herein.
  • the UE 4005 may be similar to, and share one or more features with, UE 2002, UE 192C, and/or some other UE described herein.
  • the UE 4005 may be, but is not limited to, a smartphone, tablet computer, wearable computer device, desktop computer, laptop computer, in- vehicle infotainment, in-car entertainment device, instrument cluster, head-up display device, onboard diagnostic device, dashtop mobile equipment, mobile data terminal, electronic engine management system, electronic/engine control unit, electronic/engine control module, embedded system, sensor, microcontroller, control module, engine management system, networked appliance, machine-type communication device, M2M or D2D device, loT device, etc.
  • the RAN 4010 may be similar to, and share one or more features with, RAN 114, RAN 2008, and/or some other RAN described herein.
  • the Al-related elements of UE 4005 may be similar to the AI- related elements of RAN 4010.
  • description of the various elements will be provided from the point of view of the UE 4005, however it will be understood that such discussion or description will apply to equally named/numbered elements of RAN 4010, unless explicitly stated otherwise.
  • the UE 4005 may include various elements or functions that are related to AI/ML. Such elements may be implemented as hardware, software, firmware, and/or some combination thereof. In embodiments, one or more of the elements may be implemented as part of the same hardware (e.g., chip or multi-processor chip), software (e.g., a computing program), or firmware as another element.
  • the data repository 4015 may be responsible for data collection and storage. Specifically, the data repository 4015 may collect and store RAN configuration parameters, measurement data, performance key performance indicators (KPIs), model performance metrics, etc., for model training, update, and inference. More generally, collected data is stored into the repository. Stored data can be discovered and extracted by other elements from the data repository 4015. For example, as may be seen, the inference data selection/filter element 4050 may retrieve data from the data repository 4015.
  • the UE 4005 may be configured to discover and request data from the data repository 4010 in the RAN, and vice versa. More generally, the data repository 4015 of the UE 4005 may be communicatively coupled with the data repository 4015 of the RAN 4010 such that the respective data repositories of the UE and the RAN may share collected data with one another.
  • the training data selection/filter functional block 4020 may be configured to generate training, validation, and testing datasets for model training. Training data may be extracted from the data repository 4015. Data may be selected/filtered based on the specific AI/ML model to be trained. Data may optionally be transformed/augmented/pre-processed (e.g., normalized) before being loaded into datasets. The training data selection/filter functional block 4020 may label data in datasets for supervised learning. The produced datasets may then be fed into model training the model training functional block 4025.
  • model training functional block 4025 may be responsible for training and updating(re-training) AI/ML models.
  • the selected model may be trained using the fed-in datasets (including training, validation, testing) from the training data selection/filtering functional block.
  • the model training functional block 4025 may produce trained and tested AI/ML models which are ready for deployment.
  • the produced trained and tested models can be stored in a model repository 4035.
  • the model repository 4035 may be responsible for AI/ML models’ (both trained and untrained) storage and exposure. Trained/updated model(s) may be stored into the model repository 4035. Model and model parameters may be discovered and requested by other functional blocks (e.g., the training data selection/filter functional block 4020 and/or the model training functional block 4025).
  • the UE 4005 may discover and request AI/ML models from the model repository 4035 of the RAN 4010.
  • the RAN 4010 may be able to discover and/or request AI/ML models from the model repository 4035 of the UE 4005.
  • the RAN 4010 may configure models and/or model parameters in the model repository 4035 of the UE 4005.
  • framework logic circuitry such as framework logic circuitry 100 shown in FIG. 1A may create models, configure models, configure model parameters, configure training data selection/filtering functional block 4020, configure data repository 4015 for data collection, and/or the like for the UE 4005 and/or the RAN 4010.
  • the model management functional block 4040 may be responsible for management of the AI/ML model produced by the model training functional block 4025. Such management functions may include deployment of a trained model, monitoring model performance, etc. In model deployment, the model management functional block 4040 may allocate and schedule hardware and/or software resources for inference, based on received trained and tested models. As used herein, “inference” refers to the process of using trained Al/ML model(s) to generate data analytics, actions, policies, etc. based on input inference data. In performance monitoring, based on wireless performance KPIs and model performance metrics, the model management functional block 4040 may decide to terminate the running model, start model re-training, select another model, etc. In embodiments, the model management functional block 4040 of the RAN 4010 may be able to configure model management policies in the UE 4005 as shown. Furthermore, framework logic circuitry such as framework logic circuitry 100 shown in FIG. 1A may configure model management functional block 4040.
  • the inference data selection/filter functional block 4050 may be responsible for generating datasets for model inference at the inference functional block 4045, as described below. Specifically, inference data may be extracted from the data repository 4015. The inference data selection/filter functional block 4050 may select and/or filter the data based on the deployed AI/ML model. Data may be transformed/augmented/pre-processed following the same transformation/augmentation/pre-processing as those in training data selection/filtering as described with respect to functional block 4020. The produced inference dataset may be fed into the inference functional block 4045. Furthermore, framework logic circuitry such as framework logic circuitry 100 shown in FIG. 1A may configure the inference data selection/filtering functional block 4050.
  • the inference functional block 4045 may be responsible for executing inference as described above. Specifically, the inference functional block 4045 may consume the inference dataset provided by the inference data selection/filtering functional block 4050 and generate one or more outcomes. Such outcomes may be or include data analytics, actions, policies, etc. The outcome(s) may be provided to the performance measurement functional block 4030. Furthermore, framework logic circuitry such as framework logic circuitry 100 shown in FIG. 1A may configure the inference functional block 4045.
  • the performance measurement functional block 4030 may be configured to measure model performance metrics (c.g., accuracy, model bias, run-time latency, etc.) of deployed and executing models based on the inference outcome(s) for monitoring purpose. Model performance data may be stored in the data repository 4015. Furthermore, framework logic circuitry such as framework logic circuitry 100 shown in FIG. 1A may configure the performance measurement functional block 4030.
  • FIG. 5 is an embodiment of a simplified block diagram 500 of a base station 501 and a user equipment (UE) 511 that may carry out certain embodiments in a communication network such as the base stations or RANs, the UEs, and communication networks shown in FIGs. 1-4.
  • the antenna 546 transmits and receives radio signals.
  • the RF circuitry 544 coupled with the antenna 546 which is the physical layer of the base station 510, receives RF signals from the antenna 546 and performs operations on the signals such as amplifying signals, and splitting the signals into quadrature phase and in-phase signals.
  • the receiver circuitry 590 may convert the signals to digital baseband signals, or uplink data, and pass the digital in-phase and quadrature phase signals to the processor 520 of the baseband circuitry 514, also referred to as the processing circuitry or baseband processing circuitry, via an interface 525 (e.g., RF interface 1416 shown in FIG. 14) of the baseband circuitry 514 for communications such as an interface for network communications with UEs, an interface for network communications with a core cellular network such as a 5G core, an interface for network communications with other base stations, or an interface for other related network communications.
  • analog to digital converters of the processor 520 may convert the in-phase and quadrature phase signals to digital baseband signals.
  • the transmitter circuitry 592 may convert received, digital baseband signals, or downlink data, from the processor 520 to analog signals.
  • the RF circuitry 544 processes and amplifies the analog signals and converts the analog signals to RF signals and passes the amplified, analog RF signals out to antenna 546.
  • the processor 520 decodes and processes the digital baseband signals, or uplink data, and invokes different functional modules to perform features in the base station 510.
  • the memory 522 stores program instructions or code and data 524 to control the operations of the base station 510.
  • the host circuitry 512 may execute code such as RRC layer code from the code and data 524 to implement RRC layer functionality and code. Note that code executed above the medium access control (MAC) layer and physical layer (PHY) is often referred to as higher layer code.
  • MAC medium access control
  • PHY physical layer
  • the RF circuitry 594 coupled with the antenna 596, receives RF signals from the antenna 596, amplifies the RF signals, and processes the signals to generate analog in-phase and quadrature phase signals.
  • the receiver circuitry 590 processes and converts the analog in-phase and quadrature phase signals to digital baseband signals via an analog to digital converter, or downlink data, and passes the in-phase and quadrature phase signals to processor 570 of the baseband circuitry 564 via an interface 575 (e.g., RF interface 1416 shown in FIG.
  • the processor 570 may comprise analog to digital converters to convert the analog in-phase and quadrature phase signals to digital in-phase and quadrature phase signals.
  • the transmitter circuitry 592 may convert received, digital baseband signals, or downlink data, from the processor 570 to analog signals.
  • the RF circuitry 594 processes and amplifies the analog signals and converts the analog signals to RF signals and passes the amplified, analog RF signals out to antenna 596.
  • the RF circuitry 594 illustrates multiple RF chains. While the RF circuitry 594 illustrates four RF chains, each UE may have a different number of RF chains such as 8 RF chains and each of the RF chains in the illustration may represent multiple, time domain, receive (RX) chains and transmit (TX) chains.
  • the RX chains and TX chains include circuitry that may operate on or modify the time domain signals transmitted through the time domain chains such as circuitry to insert guard intervals in the TX chains and circuitry to remove guard intervals in the RX chains.
  • the RF circuitry 594 may include transmitter circuitry and receiver circuitry, which is often called transceiver circuitry. The transmitter circuitry may prepare digital data from the processor 570 for transmission through the antenna 596.
  • the transmitter may encode the data, and modulate the encoded data, and form the modulated, encoded data into Orthogonal Frequency Division Multiplex (OFDM) and/or Orthogonal Frequency Division Multiple Access (OFDM A) symbols. Thereafter, the transmitter may convert the symbols from the frequency domain into the time domain for input into the TX chains.
  • the TX chains may include a chain per subcarrier of the bandwidth of the RF chain and may operate on the time domain signals in the TX chains to prepare them for transmission on the component subcarrier of the RF chain. For wide bandwidth communications, more than one of the RF chains may process the symbols representing the data from the baseband processor(s) simultaneously.
  • the processor 570 decodes and processes the digital baseband signals, or downlink data, and invokes different functional modules to perform features in the UE 560.
  • the memory 572 stores program instructions or code and data 574 to control the operations of the UE 560.
  • the processor 570 may also execute medium access control (MAC) layer code of the code and data 574 for the UE 560.
  • MAC medium access control
  • the MAC layer code may execute on the processor 570 to cause UL communications to transmit to the base station 510 via one or more of the RF chains of the physical layer (PHY).
  • the PHY is the RF circuitry 594 and associated logic such as some or all the functional modules.
  • the host circuitry 562 may execute code such as RRC layer code to implement RRC layer functionality and code.
  • the RRC layer code may be the higher layer code that provides configuration information to the precoder logic circuitry 535 and 580 of the base station 510 and the UE 560, respectively.
  • the configuration information provided by the higher layer may comprise parameters such as the transmission mode (txConfig), PUSCH configuration (puschconfig), dmrs-Type, maxLength, and the number of codewords.
  • the number of codewords is provided by the precoder logic circuitry 535 of the base station 510 in a DCI preceding transmission of the DM-RS.
  • the base station 510 and the UE 560 may include several functional modules and circuits to carry out some embodiments.
  • the different functional modules may include circuits or circuitry that code, hardware, or any combination thereof, can configure and implement.
  • Each functional module that can implement functionality as code and processing circuitry or as circuitry configured to perform functionality may also be referred to as a functional block.
  • the processor 520 e.g., via executing program code 524) is a functional block to configure and implement the circuitry of the functional modules to allow the base station 510 to schedule (via scheduler 526), encode or decode (via codec 528), modulate or demodulate (via modulator 530), and transmit data to or receive data from the UE 560 via the RF circuitry 544 and the antenna 546.
  • the processor 570 may be a functional block to configure and implement the circuitry of the functional modules to allow the UE 560 to receive or transmit, de-modulate or modulate (via de-modulator 578), and decode or encode (via codec 576) data accordingly via the RF circuitry 594 and the antenna 596.
  • the UE 560 may also include a functional module, framework logic circuitry 580.
  • the framework logic circuitry 580 of the UE 560 may cause the processor 570 and/or the host circuitry 562 to perform actions based on configurations, parameters, models, and/or the like received from a base station such as the base station 510.
  • the configurations may include, e.g., parameters, models, algorithms, and code determined by framework logic circuitry 100 shown in FIG. 1A for a network function such as a MnS, an AON function, or the like.
  • the configurations, parameters, models, and/or the like may cause the processor 570 and/or the host circuitry 562 to, e.g., perform measurements, send signals such as sounding signals, generate and send reports, adjust allocations of resources for communications, perform data analytics, a combination thereof, to support models, services, system functions, network functions, management functions, and/or the like deployed by the framework logic circuitry 100 shown in FIG. 1A.
  • the base station 510 may also include a functional module, framework logic circuitry 535.
  • the framework logic circuitry 535 of the base station 510 may cause the processor 520 and/or the host circuitry 512 to perform actions based on configurations, parameters, models, and/or the like received from the communications network such as the 6G network 180A shown in FIG. 1A, communications network 190 shown in FIG. IB, communications network 2000 shown in FIG. 2A, or other communications network.
  • the configurations may include, e.g., parameters, models, algorithms, and code determined by framework logic circuitry 100 shown in FIG. 1A for a network function such as a MnS, an AON function, or the like.
  • the configurations, parameters, models, and/or the like may cause the processor 520 and/or the host circuitry 512 to, e.g., perform measurements, send signals such as sounding signals, generate and send reports, adjust allocations of resources for communications, perform data analytics, a combination thereof, to support models, services, system functions, network functions, management functions, and/or the like deployed by the framework logic circuitry 100 shown in FIG. 1A.
  • FIG. 6 depicts a flowchart 6000 of an embodiment for a framework logic circuitry such as the framework logic circuitry 100 shown in FIG. 1A and the embodiments described in conjunction with FIGs. 1-5.
  • the flowchart 6000 begins with framework logic circuitry of an access node of a cellular network to receive a request via the first interface for managing and orchestrating one or more services or the network function(s) (element 6005). After receiving the request, the logic circuitry may generate the configurations to the network function(s) of the communications network (element 6010).
  • the logic circuitry may further manage and orchestrate the communications network, the one or more services, and the existing services through stages of network planning, simulation, emulation, establishment, configuration, healing, optimization, protection, or a combination thereof via one or more iterations of observation, analytics, decision, and execution.
  • the logic circuitry to may emulate, via a digital twin, the communications network and the one or more services with existing services prior to deployment of the one or more services in the communications network to analyze performance of the one or more services and capabilities of the communications network in conjunction with existing services, and to optimize the one or more services and the configuration of devices of the communications network to perform the one or more services.
  • the logic circuitry may deploy configurations to the network functions of the communications network via the second interface (element 6015). In further embodiments, the logic circuitry may deploy configurations, parameters, models, applications, and/or the like for services, system functions, management functions, network functions, and/or models via the second interface to the communications network. In many embodiments, deployment may occur autonomously or with a level of autonomy. In some embodiments, the logic circuitry may further gather and store data from the communications network, the data related to the communications network, the existing services, and the one or more services. In further embodiments, the logic circuitry may further train, test, emulate, deploy, or a combination thereof, machine learning models to infer data analytics for management of the communications network and the one or more services.
  • the logic circuitry may further manage and orchestrate a cloud computing system of the communications network, the cloud computing system to provide services to system functions, applications, or a combination thereof.
  • logic circuitry may further offer tools related to network and service management and orchestration to consumers or operators via the first interface.
  • the logic circuitry may further generate and update a knowledge data structure to relate issues with solutions for the communications network and the one or more services based on operating experience via data collection of data related to operating experience via simulation in the digital twin, deployment in communications system, or a combination thereof, and analysis of the data related to the operating experience.
  • the logic circuitry may further: update the problems and the solutions for problems in the knowledge data structure to refine the problems, to optimize the solutions for the problems, or a combination thereof; and share the solutions for the problems for problems arising in existing services, for problems arising in development of new services, for problems arising in the one or more services, for problems arising in the existing services, or a combination thereof.
  • FIG. 7 depicts a flowchart 7000 of an embodiment for a framework logic circuitry such as the framework logic circuitry 100 shown in FIG. 1A and the embodiments described in conjunction with FIGs. 1-5.
  • the framework logic circuitry may include multiple stages of operation that may be performed in order or any one or more of the stages may be performed as needed.
  • the flowchart 7000 begins with framework logic circuitry planning for one or more services (element 7005). Planning, such as the planning 111A stage shown in FIG. 1A may operate autonomously or in cooperation with an operator or consumer via an interface such as an API.
  • Planning may refer to a process by which parameters, configurations, models, and/or the like may be identified for establishing a service through a process referred to as an intelligence and autonomy workflow such as the intelligence and autonomy workflow 120A shown in FIG. 1A.
  • Planning may be initiated based on an intent of a consumer or operator, an issue raised by a communications system such as the communications networks described herein.
  • the service may comprise a service to perform a function within the communications system such as a management function.
  • the planning stage may determine data to collect to determine the scope of the function and the impact on existing services. For instance, the service may be localized to a particular’ geographical area, may be focused on a management function for the communications network, may be a system-wide function, or the like.
  • the function may involve utilization of communication resources, local device (e.g., RAN, UE, or the like), and/or computing resources in a cloud system.
  • the planning may determine an estimated number of users in the area, devices of the communications system having coverage in the area, and computing resources that may be required to support the function for the estimated number of users.
  • the planning stage may communicate with other components of the framework logic circuitry such as a knowledge management component (e.g., knowledge management 160A component shown in FIG. 1A).
  • the knowledge management component may offer services to query knowledge, create knowledge, update knowledge, and share knowledge.
  • the knowledge may include issues with resolutions that may comprise a resolution for a particular issue.
  • the knowledge management component may identify the types of data to observe (element 7050) via a about the geographical area, data analytics (element 7055), rules or policies to making a decision (element 7060) and/or performance metrics to monitor via execution (element 7065) for a plan for the one or more services. If the issue is not resolved for the purposes of planning resources based on monitoring the performance metrics (element 7070), the workflow of observation, analytics, decision, and execution may repeat until the planning identifies the resources in the form of configurations, parameters, models, applications and/or the like for the one or more services. If the issue is resolved for the purposes of planning element (element 7070), the solution may be reported to the knowledge management component to create knowledge or update the existing knowledge based on revisions made to the workflow to perform the planning.
  • the flowchart includes simulating the one or more services (element 7010) such as the simulation 112A stage shown in FIG. 1A. Simulating may involve evaluation of the plan for the one or more services (communication resources for the service and existing services on one or more devices of the communications network) to possibly update the performance of the plan based on the evaluation.
  • the process may include the workflow of observation, analytics, decision, and execution, which may repeat until the simulation validates or updates the plan to communications network to meet or exceed performance metrics.
  • the flowchart includes emulating the one or more services (element 7015), which may operate through communication with a digital twin component and a data management component such as the digital twin 170A component and the data management component 140A shown in FIG. 1 A.
  • Emulating may involve evaluation of the plan for the one or more services to possibly update the performance of the plan based on the evaluation.
  • the process may include the workflow of observation, analytics, decision, and execution, which may repeat until the emulation validates or updates the plan to communications network to meet or exceed performance metrics.
  • the flowchart includes establishing the one or more services (element 7020), which may deploy the one or more services by communication of the parameters, configurations, models, and/or the like to the devices in the geographical area to establish resources to perform the service.
  • the flowchart includes configuring the one or more services (element 7025).
  • Configuring may comprise reconfiguring the plan for the one or more services based on a change to a parameter that was the basis of the plan. For instance, the geographical area of the plane may be expanded to include a larger geographical area or the number of expected users may increase.
  • the process may include the workflow of observation, analytics, decision, and execution, which may repeat until the framework logic circuitry creates a new plan or a revised plan verified to meet or exceed performance metrics.
  • the flowchart includes optimizing the one or more services (element 7030), may include revision of the allocations of resources, parameters, configurations, models, and/or the like to overcome issues such as an excessive number of bit errors.
  • the process may involve the workflow of observation, analytics, decision, and execution, which may repeat until the optimizing validates or updates the plan to meet or exceed performance metrics.
  • an optimization stage such as the optimization stage 116A shown in FIG. 1A may query the knowledge management component to determine whether a solution exists for a similar issue.
  • the knowledge management component may share one or more known solution for an issue relating to excessive bit errors that involves changing a precoding model for precoding the communications between a UE and a base station.
  • the framework logic circuitry may communicate the revised or new precoding model for precoding the communications to the base station and the base station may communicate the precoding model to the UE.
  • Framework logic circuitry of the base station and the UE may implement the new or revised precoding model to resolve the issue.
  • the flowchart includes healing the one or more services (element 7035), which may be responsive to fault in the software of a device such as a base station. In some embodiments, healing may reinstall backup software in the overcome a software fault.
  • the flowchart includes protecting the one or more services (element 7040), to protect or limit access to resources such as communication resources and/or computing resources.
  • resources such as communication resources and/or computing resources.
  • the process may involve the workflow of observation, analytics, decision, and execution, which may repeat until the optimizing validates or updates the plan to meet or exceed performance metrics and the communication resources to be protected are routed through specific devices in the geographical area to limit potential access to a particular group of users.
  • processing of data may be limited to a specific group of computing resources such as a specific set of computing nodes.
  • FIG. 8 depicts an embodiment of protocol entities 8000 that may be implemented in wireless communication devices, including one or more of a user equipment (UE) 8060 such as UEs described in conjunction with FIGs. 1-7, an evolved node B (eNB), or a new radio, next generation node B (gNB) 8080 such as base stations or RANs described in conjunction with FIGs. 1-7, and a network function (e.g., MnF), which may be a MnS, a mobility management entity (MME), or an access and mobility management function (AMF) 8094, according to some aspects.
  • the NodeB may comprise an xNodeB for a 6 th generation or later NodeB.
  • gNB 8080 may be implemented as one or more of a dedicated physical device such as a macro-cell, a femto-cell or other suitable device, or in an alternative aspect, may be implemented as one or more software entities running on server computers as part of a virtual network termed a cloud radio access network (CRAN).
  • CRAN cloud radio access network
  • one or more protocol entities that may be implemented in one or more of UE 8060, gNB 8080 and AMF 8094 may be described as implementing all or pail of a protocol stack in which the layers are considered to be ordered from lowest to highest in the order physical layer (PHY), medium access control (MAC), radio link control (RLC), packet data convergence protocol (PDCP), radio resource control (RRC) and non-access stratum (NAS).
  • PHY physical layer
  • MAC medium access control
  • RLC radio link control
  • PDCP packet data convergence protocol
  • RRC radio resource control
  • NAS non-access stratum
  • one or more protocol entities that may be implemented in one or more of UE 8060, gNB 8080 and AMF 8094 may communicate with a respective peer protocol entity that may be implemented on another device, using the services of respective lower layer protocol entities to perform such communication.
  • UE PHY layer 8072 and peer entity gNB PHY layer 8090 may communicate using signals transmitted and received via a wireless medium.
  • UE MAC layer 8070 and peer entity gNB MAC layer 8088 may communicate using the services provided respectively by UE PHY layer 872 and gNB PHY layer 8090.
  • UE RLC layer 8068 and peer entity gNB RLC layer 8086 may communicate using the services provided respectively by UE MAC layer 8070 and gNB MAC layer 8088.
  • UE PDCP layer 8066 and peer entity gNB PDCP layer 8084 may communicate using the services provided respectively by UE RLC layer 8068 and 5GNB RLC layer 8086.
  • UE RRC layer 8064 and gNB RRC layer 8082 may communicate using the services provided respectively by UE PDCP layer 8066 and gNB PDCP layer 8084.
  • UE NAS 8062 and AMF NAS 8092 may communicate using the services provided respectively by UE RRC layer 8064 and gNB RRC layer 8082.
  • the PHY layer 8072 and 8090 may transmit or receive information used by the MAC layer 8070 and 8088 over one or more air interfaces.
  • the PHY layer 8072 and 8090 may further perform link adaptation or adaptive modulation and coding (AMC), power control, cell search (e.g., for initial synchronization and handover purposes), and other measurements used by higher layers, such as the RRC layer 8064 and 8082.
  • AMC link adaptation or adaptive modulation and coding
  • the PHY layer 8072 and 8090 may still further perform error detection on the transport channels, forward error correction (FEC) coding/decoding of the transport channels, modulation/demodulation of physical channels, interleaving, rate matching, mapping onto physical channels, and Multiple Input Multiple Output (MIMO) antenna processing.
  • FEC forward error correction
  • MIMO Multiple Input Multiple Output
  • the MAC layer 8070 and 8088 may perform mapping between logical channels and transport channels, multiplexing of MAC service data units (SDUs) from one or more logical channels onto transport blocks (TB) to be delivered to PHY via transport channels, demultiplexing MAC SDUs to one or more logical channels from transport blocks (TB) delivered from the PHY via transport channels, multiplexing MAC SDUs onto TBs, scheduling information reporting, error correction through hybrid automatic repeat request (HARQ), and logical channel prioritization.
  • the RLC layer 8068 and 8086 may operate in a plurality of modes of operation, including: Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM).
  • the RLC layer 8068 and 8086 may execute transfer of upper layer protocol data units (PDUs), error correction through automatic repeat request (ARQ) for AM data transfers, and concatenation, segmentation and reassembly of RLC SDUs for UM and AM data transfers.
  • the RLC layer 8068 and 8086 may also execute re-segmentation of RLC data PDUs for AM data transfers, reorder RLC data PDUs for UM and AM data transfers, detect duplicate data for UM and AM data transfers, discard RLC SDUs for UM and AM data transfers, detect protocol errors for AM data transfers, and perform RLC re-establishment.
  • the PDCP layer 8066 and 8084 may execute header compression and decompression of Internet Protocol (IP) data, maintain PDCP Sequence Numbers (SNs), perform in-sequence delivery of upper layer PDUs at re-establishment of lower layers, eliminate duplicates of lower layer SDUs at re-establishment of lower layers for radio bearers mapped on RLC AM, cipher and decipher control plane data, perform integrity protection and integrity verification of control plane data, control timer-based discard of data, and perform security operations (e.g., ciphering, deciphering, integrity protection, integrity verification, etc.).
  • IP Internet Protocol
  • SNs PDCP Sequence Numbers
  • the main services and functions of the RRC layer 8064 and 8082 may include broadcast of system information (e.g., included in Master Information Blocks (MIBs) or System Information Blocks (SIBs) related to the non-access stratum (NAS)), broadcast of system information related to the access stratum (AS), paging, establishment, maintenance and release of an RRC connection between the UE and E-UTRAN (e.g., RRC connection paging, RRC connection establishment, RRC connection modification, and RRC connection release), establishment, configuration, maintenance and release of point to point Radio Bearers, security functions including key management, inter radio access technology (RAT) mobility, and measurement configuration for UE measurement reporting.
  • SIBs may comprise one or more information elements (IES), which may each comprise individual data fields or data structures.
  • the UE 8060 and the RAN node, gNB 8080 may utilize a Uu interface (e.g., an LTE-Uu interface) to exchange control plane data via a protocol stack comprising the PHY layer 8072 and 8090, the MAC layer 8070 and 8088, the RLC layer 8068 and 8086, the PDCP layer 8066 and 8084, and the RRC layer 8064 and 8082.
  • the non-access stratum (NAS) protocols 8092 form the highest stratum of the control plane between the UE 8060 and the AMF 8005.
  • the NAS protocols 8092 support the mobility of the UE 8060 and the session management procedures to establish and maintain IP connectivity between the UE 8060 and the Packet Data Network (PDN) Gateway (P-GW).
  • PDN Packet Data Network
  • P-GW Packet Data Network Gateway
  • FIG. 9 illustrates embodiments of the formats of PHY data units (PDUs) that may be transmitted by the PHY device via one or more antennas and be encoded and decoded by a MAC entity such as the processors 520 and 570 in FIG. 5, the baseband circuitry 1304 in FIGs. 13 and 14 according to some aspects.
  • a MAC entity such as the processors 520 and 570 in FIG. 5, the baseband circuitry 1304 in FIGs. 13 and 14 according to some aspects.
  • higher layer frames such as a frame comprising an RRC layer information element may transmit from the base station to the UE or vice versa as one or more MAC Service Data Units (MSDUs) in a payload of one or more PDUs in one or more subframes of a radio frame.
  • MSDUs MAC Service Data Units
  • a MAC PDU 9100 may consist of a MAC header 9105 and a MAC pay load 9110, the MAC pay load consisting of zero or more MAC control elements 9130, zero or more MAC service data unit (SDU) portions 9135 and zero or one padding portion 9140.
  • MAC header 8105 may consist of one or more MAC sub-headers, each of which may correspond to a MAC payload portion and appear in corresponding order.
  • each of the zero or more MAC control elements 9130 contained in MAC pay load 9110 may correspond to a fixed length sub-header 9115 contained in MAC header 9105.
  • each of the zero or more MAC SDU portions 9135 contained in MAC payload 9110 may correspond to a variable length sub-header 9120 contained in MAC header 8105.
  • padding portion 9140 contained in MAC pay load 9110 may correspond to a padding sub-header 9125 contained in MAC header 9105.
  • FIG. 10A illustrates an embodiment of communication circuitry 1000 such as the circuitry in the base station 510 and the user equipment 560 shown in FIG. 5.
  • the communication circuitry 1000 is alternatively grouped according to functions. Components as shown in the communication circuitry 1000 are shown here for illustrative purposes and may include other components not shown here in Fig. 10A.
  • the communication circuitry 1000 may include protocol processing circuitry 1005, which may implement one or more of medium access control (MAC), radio link control (RLC), packet data convergence protocol (PDCP), radio resource control (RRC) and non-access stratum (NAS) functions.
  • the protocol processing circuitry 1005 may include one or more processing cores (not shown) to execute instructions and one or more memory structures (not shown) to store program (code) and data information.
  • the communication circuitry 1000 may further include digital baseband circuitry 1010, which may implement physical layer (PHY) functions including one or more of hybrid automatic repeat request (HARQ) functions, scrambling and/or descrambling, coding and/or decoding, layer mapping and/or de-mapping, modulation symbol mapping, received symbol and/or bit metric determination, multi-antenna port pre-coding and/or decoding which may include one or more of space-time, space-frequency or spatial coding, reference signal generation and/or detection, preamble sequence generation and/or decoding, synchronization sequence generation and/or detection, control channel signal blind decoding, and other related functions.
  • PHY physical layer
  • HARQ hybrid automatic repeat request
  • the communication circuitry 1000 may further include transmit circuitry 1015, receive circuitry 1020 and/or antenna array 1030 circuitry.
  • the communication circuitry 1000 may further include radio frequency (RF) circuitry 1025 such as the RF circuitry 544 and 594 in FIG. 2.
  • RF circuitry 1025 may include multiple parallel RF chains for one or more of transmit or receive functions, each connected to one or more antennas of the antenna array 1030.
  • the protocol processing circuitry 1005 may include one or more instances of control circuitry (not shown) to provide control functions for one or more of digital baseband circuitry 1010, transmit circuitry 1015, receive circuitry 1020, and/or radio frequency circuitry 1025.
  • FIG. 10B illustrates an embodiment of radio frequency circuitry 1025 in FIG. 10A according to some aspects such as a RF circuitry 544 and 594 illustrated in FIG. 5.
  • the radio frequency circuitry 1025 may include one or more instances of radio chain circuitry 1072, which in some aspects may include one or more filters, power amplifiers, low noise amplifiers, programmable phase shifters and power supplies (not shown).
  • the radio frequency circuitry 1025 may include power combining and dividing circuitry 1074.
  • power combining and dividing circuitry 1074 may operate bidirectionally, such that the same physical circuitry may be configured to operate as a power divider when the device is transmitting, and as a power combiner when the device is receiving.
  • power combining and dividing circuitry 1074 may one or more include wholly or partially separate circuitries to perform power dividing when the device is transmitting and power combining when the device is receiving.
  • power combining and dividing circuitry 1074 may include passive circuitry comprising one or more two-way power divider/combiners arranged in a tree.
  • power combining and dividing circuitry 1074 may include active circuitry comprising amplifier circuits.
  • the radio frequency circuitry 1025 may connect to transmit circuitry 1015 and receive circuitry 1020 in FIG. 10A via one or more radio chain interfaces 1076 or a combined radio chain interface 1078.
  • the combined radio chain interface 1078 may form a wide or very wide bandwidth.
  • one or more radio chain interfaces 1076 may provide one or more interfaces to one or more receive or transmit signals, each associated with a single antenna structure which may comprise one or more antennas.
  • the combined radio chain interface 1078 may provide a single interface to one or more receive or transmit signals, each associated with a group of antenna structures comprising one or more antennas.
  • FIG. 11 illustrates an example of a storage medium 1100 to store code and data for execution by any one or more of the processors and/or processing circuitry to perform the functionality of the logic circuitry described herein.
  • Storage medium 1100 may comprise an article of manufacture.
  • storage medium 1100 may include any non-transitory computer readable medium or machine-readable medium, such as an optical, magnetic or semiconductor storage.
  • Storage medium 1100 may store diverse types of computer executable instructions, such as instructions to implement logic flows and/or techniques described herein.
  • Examples of a computer readable or machine-readable storage medium may include any tangible media capable of storing electronic data, including volatile memory or non-volatile memory, removable or nonremovable memory, erasable or non-erasable memory, writeable or re-writeable memory, and so forth.
  • Examples of computer executable instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, object-oriented code, visual code, and the like.
  • FIG. 12 illustrates an architecture of a system 1200 of a network in accordance with some embodiments.
  • the system 1200 is shown to include a user equipment (UE) 1510 and a UE 1522 such as the UEs shown in FIGs. 1-11.
  • the UEs 1510 and 1522 are illustrated as smartphones (e.g., handheld touch screen mobile computing devices connectable to one or more cellular networks) but may also comprise any mobile or non-mobile computing device, such as Personal Data Assistants (PDAs), pagers, laptop computers, desktop computers, wireless handsets, or any computing device including a wireless communications interface.
  • PDAs Personal Data Assistants
  • pagers pagers
  • laptop computers desktop computers
  • wireless handsets or any computing device including a wireless communications interface.
  • any of the UEs 1510 and 1522 can comprise an Internet of Things (loT) UE, which can comprise a network access layer designed for low-power loT applications utilizing short-lived UE connections.
  • An loT UE can utilize technologies such as machine-to- machine (M2M) or machine-type communications (MTC) for exchanging data with an MTC server or device via a public land mobile network (PLMN), Proximity-Based Service (ProSe) or device-to-device (D2D) communication, sensor networks, or loT networks.
  • M2M or MTC exchange of data may be a machine-initiated exchange of data.
  • loT network describes interconnecting loT UEs, which may include uniquely identifiable embedded computing devices (within the Internet infrastructure), with short-lived connections.
  • the loT UEs may execute background applications (e.g., keep-alive messages, status updates, etc.) to facilitate the connections of the loT network.
  • the UEs 1510 and 1522 may to connect, e.g., communicatively couple, with a radio access network (RAN) - in this embodiment, an Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN) 1210 such as the base stations shown in FIGs. 1-11.
  • RAN radio access network
  • E-UTRAN Evolved Universal Mobile Telecommunications System
  • the UEs 1510 and 1522 utilize connections 1520 and 1204, respectively, each of which comprises a physical communications interface or layer (discussed in further detail below); in this example, the connections 1520 and 1204 are illustrated as an air interface to enable communicative coupling, and can be consistent with cellular communications protocols, such as a Global System for Mobile Communications (GSM) protocol, a code-division multiple access (CDMA) network protocol, a Push-to-Talk (PTT) protocol, a PTT over Cellular (POC) protocol, a Universal Mobile Telecommunications System (UMTS) protocol, a 3GPP Long Term Evolution (LTE) protocol, a fifth generation (5G) protocol, a New Radio (NR) protocol, and the like.
  • GSM Global System for Mobile Communications
  • CDMA code-division multiple access
  • PTT Push-to-Talk
  • POC PTT over Cellular
  • UMTS Universal Mobile Telecommunications System
  • LTE Long Term Evolution
  • 5G fifth generation
  • NR New Radio
  • the UEs 1510 and 1522 may further directly exchange communication data via a ProSe interface 1205.
  • the ProSe interface 1205 may alternatively be referred to as a sidelink interface comprising one or more logical channels, including but not limited to a Physical Sidelink Control Channel (PSCCH), a Physical Sidelink Shared Channel (PSSCH), a Physical Sidelink Discovery Channel (PSDCH), and a Physical Sidelink Broadcast Channel (PSBCH).
  • PSCCH Physical Sidelink Control Channel
  • PSSCH Physical Sidelink Shared Channel
  • PSDCH Physical Sidelink Discovery Channel
  • PSBCH Physical Sidelink Broadcast Channel
  • the UE 1522 is shown to be configured to access an access point (AP) 1206 via connection 1207.
  • the connection 1207 can comprise a local wireless connection, such as a connection consistent with any IEEE 802.11 protocol, wherein the AP 1206 would comprise a wireless fidelity (WiFi®) router.
  • WiFi® wireless fidelity
  • the AP 1206 is shown to be connected to the Internet without connecting to the core network of the wireless system (described in further detail below).
  • the E-UTRAN 1210 can include one or more access nodes that enable the connections 1520 and 1204.
  • ANs access nodes
  • BSs base stations
  • NodeBs evolved NodeBs
  • gNB next Generation NodeBs
  • RAN nodes and so forth, and can comprise ground stations (e.g., terrestrial access points) or satellite stations providing coverage within a geographic area (e.g., a cell).
  • ground stations e.g., terrestrial access points
  • satellite stations providing coverage within a geographic area (e.g., a cell).
  • the E-UTRAN 1210 may include one or more RAN nodes for providing macro-cells, e.g., macro RAN node 1560, and one or more RAN nodes for providing femto-cells or picocells (e.g., cells having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macro-cells), e.g., low power (LP) RAN node 1572.
  • macro RAN node 1560 e.g., macro RAN node 1560
  • femto-cells or picocells e.g., cells having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macro-cells
  • LP low power
  • any of the RAN nodes 1560 and 1572 can terminate the air interface protocol and can be the first point of contact for the UEs 1510 and 1522.
  • any of the RAN nodes 1560 and 1572 can fulfill various logical functions for the E-UTRAN 1210 including, but not limited to, radio network controller (RNC) functions such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management.
  • RNC radio network controller
  • the UEs 1510 and 1522 can be configured to communicate using Orthogonal Frequency-Division Multiplexing (OFDM) communication signals with each other or with any of the RAN nodes 1560 and 1572 over a multicarrier communication channel in accordance various communication techniques, such as, but not limited to, an Orthogonal Frequency-Division Multiple Access (OFDMA) communication technique (e.g., for downlink communications) or a Single Carrier Frequency Division Multiple Access (SC-FDMA) communication technique (e.g., for uplink and ProSe or sidelink communications), although the scope of the embodiments is not limited in this respect.
  • OFDM signals can comprise a plurality of orthogonal subcarriers.
  • a downlink resource grid can be used for downlink transmissions from any of the RAN nodes 1560 and 1572 to the UEs 1510 and 1522, while uplink transmissions can utilize similar techniques.
  • the grid can be a time-frequency grid, called a resource grid or time-frequency resource grid, which is the physical resource in the downlink in each slot.
  • a time-frequency plane representation is a common practice for OFDM systems, which makes it intuitive for radio resource allocation.
  • Each column and each row of the resource grid corresponds to one OFDM symbol and one OFDM subcarrier, respectively.
  • the duration of the resource grid in the time domain corresponds to one slot in a radio frame.
  • the smallest timefrequency unit in a resource grid is denoted as a resource element.
  • Each resource grid comprises a number of resource blocks, which describe the mapping of certain physical channels to resource elements.
  • Each resource block comprises a collection of resource elements; in the frequency domain, this may represent the smallest quantity of resources that currently can be allocated.
  • DL physical downlink
  • the physical downlink shared channel may carry user data and higher-layer signaling to the UEs 1510 and 1522.
  • the physical downlink control channel (PDCCH) may carry information about the transport format and resource allocations related to the PDSCH channel, among other things. It may also inform the UEs 1510 and 1522 about the transport format, resource allocation, and HARQ (Hybrid Automatic Repeat Request) information related to the uplink shared channel.
  • downlink scheduling (assigning control and shared channel resource blocks to the UE 192 within a cell) may be performed at any of the RAN nodes 1560 and 1572 based on channel quality information fed back from any of the UEs 1510 and 1522.
  • the downlink resource assignment information may be sent on the PDCCH used for (e.g., assigned to) each of the UEs 1510 and 1522.
  • the PDCCH may use control channel elements (CCEs) to convey the control information.
  • CCEs control channel elements
  • the PDCCH complex-valued symbols may first be organized into quadruplets, which may then be permuted using a sub-block interleaver for rate matching.
  • Each PDCCH may be transmitted using one or more of these CCEs, where each CCE may correspond to nine sets of four physical resource elements known as resource element groups (REGs).
  • RAGs resource element groups
  • QPSK Quadrature Phase Shift Keying
  • the PDCCH can be transmitted using one or more CCEs, depending on the size of the downlink control information (DCI) and the channel condition.
  • DCI downlink control information
  • There can he four or more different PDCCH formats defined in LTE with different numbers of CCEs (c.g., aggregation level, L l, 2, 4, or 8).
  • Some embodiments may use concepts for resource allocation for control channel information that are an extension of the above-described concepts.
  • some embodiments may utilize an enhanced physical downlink control channel (EPDCCH) that uses PDSCH resources for control information transmission.
  • the EPDCCH may be transmitted using one or more enhanced the control channel elements (ECCEs). Similar’ to above, each ECCE may correspond to nine sets of four physical resource elements known as an enhanced resource element groups (EREGs). An ECCE may have other numbers of EREGs in some situations.
  • EPCCH enhanced physical downlink control channel
  • ECCEs enhanced the control channel elements
  • each ECCE may correspond to nine sets of four physical resource elements known as an enhanced resource element groups (EREGs).
  • EREGs enhanced resource element groups
  • An ECCE may have other numbers of EREGs in some situations.
  • the RAN nodes 1560 and 1572 may communicate with one another and/or with other access nodes in the E-UTRAN 1210 and/or in another RAN via an X2 interface, which is a signaling interface for communicating data packets between ANs. Some other suitable interface for communicating data packets directly between ANs may be used.
  • the E-UTRAN 1210 is shown to be communicatively coupled to a core network - in this embodiment, an Evolved Packet Core (EPC) network 1220 via an SI interface 1570.
  • EPC Evolved Packet Core
  • the SI interface 1570 is split into two parts: the SI-U interface 1214, which carries traffic data between the RAN nodes 1560 and 1572 and the serving gateway (S-GW) 1222, and the SI- mobility management entity (MME) interface 1215, which is a signaling interface between the RAN nodes 1560 and 1572 and MMEs 1546.
  • SI-U interface 1214 which carries traffic data between the RAN nodes 1560 and 1572 and the serving gateway (S-GW) 1222
  • MME SI- mobility management entity
  • the EPC network 1220 comprises the MMEs 1546, the S-GW 1222, the Packet Data Network (PDN) Gateway (P-GW) 1223, and a home subscriber server (HSS) 1224.
  • the MMEs 1546 may be similar in function to the control plane of legacy Serving General Packet Radio Service (GPRS) Support Nodes (SGSN).
  • GPRS General Packet Radio Service
  • the MMEs 1546 may manage mobility aspects in access such as gateway selection and tracking area list management.
  • the HSS 1224 may comprise a database for network users, including subscription-related information to support the network entities' handling of communication sessions.
  • the EPC network 1220 may comprise one or several HSSs 1224, depending on the number of mobile subscribers, on the capacity of the equipment, on the organization of the network, etc.
  • the HSS 1224 can provide support for routing/roaming, authentication, authorization, naming/addressing resolution, location dependencies, etc.
  • the S-GW 1222 may terminate the SI interface 1570 towards the E-UTRAN 1210, and routes data packets between the E-UTRAN 1210 and the EPC network 1220.
  • the S- GW 1222 may be a local mobility anchor point for inter-RAN node handovers and also may provide an anchor for inter-3GPP mobility. Other responsibilities may include lawful intercept, charging, and some policy enforcement.
  • the P-GW 1223 may terminate an SGi interface (such as interface 182A) toward a PDN.
  • the P-GW 1223 may route data packets between the EPC network 1220 and external networks such as a network including the application server 1230 (alternatively referred to as application function (AF)) via an Internet Protocol (IP) interface 1225.
  • the application server 1230 may be an element offering applications that use IP bearer resources with the core network (e.g., UMTS Packet Services (PS) domain, LTE PS data services, etc.).
  • PS UMTS Packet Services
  • LTE PS data services etc.
  • the P-GW 1223 is shown to be communicatively coupled to an application server 1230 via an IP interface 1225.
  • the application server 1230 can also be configured to support one or more communication services (e.g., Voice-over-Internet Protocol (VoIP) sessions, PTT sessions, group communication sessions, social networking services, etc.) for the UEs 1510 and 1522 via the EPC network 1220.
  • VoIP Voice-over-Internet Protocol
  • PTT sessions PTT sessions
  • group communication sessions social networking services, etc.
  • the P-GW 1223 may further be a node for policy enforcement and charging data collection.
  • Policy and Charging Enforcement Function (PCRF) 1226 is the policy and charging control element of the EPC network 1220.
  • PCRF Policy and Charging Enforcement Function
  • HPLMN Home Public Land Mobile Network
  • IP-CAN Internet Protocol Connectivity Access Network
  • HPLMN Home Public Land Mobile Network
  • V-PCRF Visited PCRF
  • VPLMN Visited Public Land Mobile Network
  • the PCRF 1226 may be communicatively coupled to the application server 1230 via the P-GW 1223.
  • the application server 1230 may signal the PCRF 1226 to indicate a new service flow and select the appropriate Quality of Service (QoS) and charging parameters.
  • the PCRF 1226 may provision this rule into a Policy and Charging Enforcement Function (PCEF) (not shown) with the appropriate traffic flow template (TFT) and QoS class of identifier (QCI), which commences the QoS and charging as specified by the application server 1230.
  • PCEF Policy and Charging Enforcement Function
  • TFT traffic flow template
  • QCI QoS class of identifier
  • FIG. 13 illustrates example components of a device 1300 in accordance with some embodiments such as the base stations and UEs shown in FIGs. 1- 12.
  • the device 1300 may include application circuitry 1302, baseband circuitry 1304, Radio Frequency (RF) circuitry 1306, front-end module (FEM) circuitry 1308, one or more antennas 1310, and power management circuitry (PMC) 1312 coupled together at least as shown.
  • the components of the illustrated device 1300 may be included in a UE or a RAN node such as a base station or gNB.
  • the device 1300 may include less elements (e.g., a RAN node may not utilize application circuitry 1302, and instead include a processor/controller to process IP data received from an EPC).
  • the device 1300 may include additional elements such as, for example, memory/storage, display, camera, sensor, or input/output (R0) interface.
  • the components described below may be included in more than one device (e.g., said circuitries may be separately included in more than one device for Cloud- RAN (C-RAN) implementations).
  • the application circuitry 1302 may include one or more application processors.
  • the application circuitry 1302 may include circuitry such as, but not limited to, one or more single-core or multi-core processors.
  • the processor(s) may include any combination of general- purpose processors and dedicated processors (e.g., graphics processors, application processors, etc.).
  • the processors may be coupled with or may include memory/storage and may be configured to execute instructions stored in the memory/storage to enable various applications or operating systems to run on the device 1300.
  • processors of application circuitry 1302 may process IP data packets received from an EPC.
  • the baseband circuitry 1304 may include circuitry such as, but not limited to, one or more single-core or multi-core processors.
  • the baseband circuitry 1304 may include one or more baseband processors or control logic to process baseband signals received from a receive signal path of the RF circuitry 1306 and to generate baseband signals for a transmit signal path of the RF circuitry 1306.
  • the baseband circuity 1304 may interface with the application circuitry 1302 for generation and processing of the baseband signals and for controlling operations of the RF circuitry 1306.
  • the baseband circuitry 1304 may include a third generation (3G) baseband processor 1304A, a fourth generation (4G) baseband processor 1304B, a fifth generation (5G) baseband processor 1304C, or other baseband processor(s) 1304D for other existing generations, generations in development or to be developed in the future (e.g., second generation (2G), sixth generation (6G), etc.).
  • the fourth generation (4G) baseband processor 1304B may include capabilities for generation and processing of the baseband signals for LTE radios and the fifth generation (5G) baseband processor 1304C may capabilities for generation and processing of the baseband signals for NRs.
  • the baseband circuitry 1304 may handle various radio control functions that enable communication with one or more radio networks via the RF circuitry 1306. In other embodiments, some of or all the functionality of baseband processors 1304A-D may be included in modules stored in the memory 1304G and executed via a Central Processing Unit (CPU) 1304E.
  • the radio control functions may include, but are not limited to, signal modulation/demodulation, encoding/decoding, radio frequency shifting, etc.
  • modulation/demodulation circuitry of the baseband circuitry 1304 may include Fast-Fourier Transform (FFT), precoding, or constellation mapping/demapping functionality.
  • FFT Fast-Fourier Transform
  • encoding/decoding circuitry of the baseband circuitry 1304 may include convolution, tail-biting convolution, turbo, Viterbi, or Low-Density Parity Check (LDPC) encoder/decoder functionality.
  • LDPC Low-Density Parity Check
  • the baseband circuitry 1304 may include one or more audio digital signal processor(s) (DSP) 1304F.
  • the audio DSP(s) 1304F may be include elements for compression/decompression and echo cancellation and may include other suitable processing elements in other embodiments.
  • Components of the baseband circuitry may be suitably combined in a single chip, a single chipset, or disposed on a same circuit board in some embodiments.
  • some of or all the constituent components of the baseband circuitry 1304 and the application circuitry 1302 may be implemented together such as, for example, on a system on a chip (SOC).
  • the baseband circuitry 1304 may provide for communication compatible with one or more radio technologies.
  • the baseband circuitry 1304 may support communication with an evolved universal terrestrial radio access network (E-UTRAN) or other wireless metropolitan area networks (WMAN), a wireless local area network (WLAN), a wireless personal area network (WPAN).
  • E-UTRAN evolved universal terrestrial radio access network
  • WMAN wireless metropolitan area networks
  • WLAN wireless local area network
  • WPAN wireless personal area network
  • Embodiments in which the baseband circuitry 1304 is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry.
  • the RF circuitry 1306 may enable communication with wireless networks using modulated electromagnetic radiation through a non- solid medium.
  • the RF circuitry 1306 may include switches, filters, amplifiers, etc. to facilitate the communication with the wireless network.
  • the RF circuitry 1306 may include a receive signal path which may include circuitry to down-convert RF signals received from the FEM circuitry 1308 and provide baseband signals to the baseband circuitry 1304.
  • the RF circuitry 1306 may also include a transmit signal path which may include circuitry to up-convert baseband signals provided by the baseband circuitry 1304 and provide RF output signals to the FEM circuitry 1308 for transmission.
  • the receive signal path of the RF circuitry 1306 may include mixer circuitry 1306a, amplifier circuitry 1306b and filter circuitry 1306c.
  • the transmit signal path of the RF circuitry 1306 may include filter circuitry 1306c and mixer circuitry 1306a.
  • the RF circuitry 1306 may also include synthesizer circuitry 1306d for synthesizing a frequency, or component carrier, for use by the mixer circuitry 1306a of the receive signal path and the transmit signal path.
  • the mixer circuitry 1306a of the receive signal path may to down-convert RF signals received from the FEM circuitry 1308 based on the synthesized frequency provided by synthesizer circuitry 1306d.
  • the amplifier circuitry 1306b may amplify the down-converted signals and the filter circuitry 1306c may be a low-pass filter (LPF) or band-pass filter (BPF) to remove unwanted signals from the down- converted signals to generate output baseband signals.
  • Output baseband signals may be provided to the baseband circuitry 1304 for further processing.
  • LPF low-pass filter
  • BPF band-pass filter
  • the output baseband signals may be zero-frequency baseband signals, although this is not a requirement.
  • mixer circuitry 1306a of the receive signal path may comprise passive mixers, although the scope of the embodiments is not limited in this respect.
  • the mixer circuitry 1306a of the transmit signal path may be configured to up-convert input baseband signals based on the synthesized frequency provided by the synthesizer circuitry 1306d to generate RF output signals for the FEM circuitry 1308.
  • the baseband signals may be provided by the baseband circuitry 1304 and may be filtered by filter circuitry 1306c.
  • the mixer circuitry 1306a of the receive signal path and the mixer circuitry 1306a of the transmit signal path may include two or more mixers and may be arranged for quadrature downconversion and upconversion, respectively.
  • the mixer circuitry 1306a of the receive signal path and the mixer circuitry 1306a of the transmit signal path may include two or more mixers and may be arranged for image rejection (e.g., Hartley image rejection). In some embodiments, the mixer circuitry 1306a of the receive signal path and the mixer circuitry 1306a may be arranged for direct downconversion and direct upconversion, respectively. In some embodiments, the mixer circuitry 1306a of the receive signal path and the mixer circuitry 1306a of the transmit signal path may be configured for super-heterodyne operation.
  • the output baseband signals and the input baseband signals may be analog baseband signals, although the scope of the embodiments is not limited in this respect.
  • the output baseband signals and the input baseband signals may be digital baseband signals.
  • the RF circuitry 1306 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry and the baseband circuitry 1304 may include a digital baseband interface to communicate with the RF circuitry 1306.
  • ADC analog-to-digital converter
  • DAC digital-to-analog converter
  • a separate radio IC circuitry may be provided for processing signals for each spectrum, although the scope of the embodiments is not limited in this respect.
  • the synthesizer circuitry 1306d may be a fractional-N synthesizer or a fractional NIN+ I synthesizer, although the scope of the embodiments is not limited in this respect as other types of frequency synthesizers may be suitable.
  • synthesizer circuitry 1306d may be a delta- sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase-locked loop with a frequency divider.
  • the synthesizer circuitry 1306d may synthesize an output frequency for use by the mixer circuitry 1306a of the RF circuitry 1306 based on a frequency input and a divider control input.
  • the synthesizer circuitry 1306d may be a fractional NIN+ I synthesizer.
  • frequency input may be an output of a voltage-controlled oscillator (VCO), although that is not a requirement.
  • VCO voltage-controlled oscillator
  • Divider control input may be an output of either the baseband circuitry 1304 or an application processor of the applications circuitry 1302 depending on the desired output frequency.
  • Some embodiments may determine a divider control input (e.g., N) from a look-up table based on a channel indicated by the applications circuitry 1302.
  • the synthesizer circuitry 1306d of the RF circuitry 1306 may include a divider, a delay- locked loop (DLL), a multiplexer and a phase accumulator.
  • the divider may be a dual modulus divider (DMD) and the phase accumulator may be a digital phase accumulator (DPA).
  • the DMD may be configured to divide the input signal by either N or N+l (e.g., based on a carry out) to provide a fractional division ratio.
  • the DLL may include a set of cascaded, tunable, delay elements, a phase detector, a charge pump and a D-type flip-flop.
  • the delay elements may break a VCO period up into Nd equal packets of phase, where Nd is the number of delay elements in the delay line.
  • Nd is the number of delay elements in the delay line.
  • the synthesizer circuitry 1306d may generate a carrier frequency (or component carrier) as the output frequency, while in other embodiments, the output frequency may be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and used in conjunction with quadrature generator and divider circuitry to generate multiple signals at the carrier frequency with multiple different phases with respect to each other.
  • the output frequency may be a local oscillator (LO) frequency (fLO).
  • the RF circuitry 1306 may include an IQ/polar converter.
  • the FEM circuitry 1308 may include a receive signal path which may include circuitry to operate on RF signals received from one or more antennas 1310, amplify the received signals and provide the amplified versions of the received signals to the RF circuitry 1306 for further processing.
  • FEM circuitry 1308 may also include a transmit signal path which may include circuitry configured to amplify signals for transmission provided by the RF circuitry 1306 for transmission by one or more of the one or more antennas 1310.
  • the amplification through the transmit or receive signal paths may be done solely in the RF circuitry 1306, solely in the FEM circuitry 1308, or in both the RF circuitry 1306 and the FEM circuitry 1308.
  • the FEM circuitry 1308 may include a TX/RX switch to switch between transmit mode and receive mode operation.
  • the FEM circuitry may include a receive signal path and a transmit signal path.
  • the receive signal path of the FEM circuitry may include a low-noise amplifier (LNA) to amplify received RF signals and provide the amplified received RF signals as an output (c.g., to the RF circuitry 1306).
  • the transmit signal path of the FEM circuitry 1308 may include a power amplifier (PA) to amplify input RF signals (e.g., provided by RF circuitry 1306), and one or more filters to generate RF signals for subsequent transmission (e.g., by one or more of the one or more antennas 1310).
  • PA power amplifier
  • the radio refers to a combination of the RF circuitry 130 and the FEM circuitry 1308.
  • the radio refers to the portion of the circuitry that generates and transmits or receives and processes the radio signals.
  • the RF circuitry 1306 includes a transmitter to generate the time domain radio signals with the data from the baseband signals and apply the radio signals to subcarriers of the carrier frequency that form the bandwidth of the channel.
  • the PA in the FEM circuitry 1308 amplifies the tones for transmission and amplifies tones received from the one or more antennas 1310 via the LNA to increase the signal-to-noise ratio (SNR) for interpretation.
  • the FEM circuitry 1308 may also search for a detectable pattern that appears to be a wireless communication.
  • a receiver in the RF circuitry 1306 converts the time domain radio signals to baseband signals via one or more functional modules such as the functional modules shown in the base station 510 and the user equipment 560 illustrated in FIG. 2.
  • the PMC 1312 may manage power provided to the baseband circuitry 1304.
  • the PMC 1312 may control power-source selection, voltage scaling, battery charging, or DC-to-DC conversion.
  • the PMC 1312 may often be included when the device 1300 is capable of being powered by a battery, for example, when the device is included in a UE.
  • the PMC 1312 may increase the power conversion efficiency while providing desirable implementation size and heat dissipation characteristics.
  • FIG. 13 shows the PMC 1312 coupled only with the baseband circuitry 1304.
  • the PMC 1312 may be additionally or alternatively coupled with, and perform similar power management operations for, other components such as, but not limited to, application circuitry 1302, RF circuitry 1306, or FEM circuitry 1308.
  • the PMC 1312 may control, or otherwise be part of, various power saving mechanisms of the device 1300. For example, if the device 1300 is in an RRC > Connected state, where it is still connected to the RAN node as it expects to receive traffic shortly, then it may enter a state known as Discontinuous Reception Mode (DRX) after a period of inactivity. During this state, the device 1300 may power down for brief intervals of time and thus save power.
  • DRX Discontinuous Reception Mode
  • the device 1300 may transition off to an RRC Idle state, where it disconnects from the network and does not perform operations such as channel quality feedback, handover, etc.
  • the device 1300 goes into a very low power state and it performs paging where again it periodically wakes up to listen to the network and then powers down again.
  • the device 1300 may not receive data in this state, in order to receive data, it must transition back to RRC Connected state.
  • An additional power saving mode may allow a device to be unavailable to the network for periods longer than a paging interval (ranging from seconds to a few hours). During this time, the device is totally unreachable to the network and may power down completely. Any data sent during this time incurs a large delay and it is assumed the delay is acceptable.
  • the processors of the application circuitry 1302 and the processors of the baseband circuitry 1304 may be used to execute elements of one or more instances of a protocol stack.
  • processors of the baseband circuitry 1304 may be used execute Layer 3, Layer 2, or Layer 1 functionality, while processors of the application circuitry 1302 may utilize data (e.g., packet data) received from these layers and further execute Layer 4 functionality (e.g., transmission communication protocol (TCP) and user datagram protocol (UDP) layers).
  • Layer 3 may comprise a radio resource control (RRC) layer, described in further detail below.
  • RRC radio resource control
  • Layer 2 may comprise a medium access control (MAC) layer, a radio link control (RLC) layer, and a packet data convergence protocol (PDCP) layer, described in further detail below.
  • Layer 1 may comprise a physical (PHY) layer of a UE/RAN node, described in further detail below.
  • FIG. 14 illustrates example interfaces of baseband circuitry in accordance with some embodiments such as the baseband circuitry shown and/or discussed in conjunction with FIGs. 1- 13.
  • the baseband circuitry 1304 of FIG. 13 may comprise processors 1304A-1304E and a memory 1304G utilized by said processors.
  • Each of the processors 1304A- 1304E may include a memory interface, 1404A-1404E, respectively, to send/receive data to/from the memory 1304G.
  • the baseband circuitry 1304 may further include one or more interfaces to communicatively couple to other circuitries/devices, such as a memory interface 1412 (e.g., an interface to send/receive data to/from memory external to the baseband circuitry 1304), an application circuitry interface 1414 (c.g., an interface to scnd/rcccivc data to/from the application circuitry 1302 of FIG. 13), an RF circuitry interface 1416 (e.g., an interface to send/receive data to/from RF circuitry 1306 of FIG.
  • a memory interface 1412 e.g., an interface to send/receive data to/from memory external to the baseband circuitry 1304
  • an application circuitry interface 1414 c.g., an interface to scnd/rcccivc data to/from the application circuitry 1302 of FIG. 13
  • an RF circuitry interface 1416 e.g., an interface to send/receive data to/from RF circuitry 13
  • a wireless hardware connectivity interface 1418 e.g., an interface to send/receive data to/from Near Field Communication (NFC) components, Bluetooth® components (e.g., Bluetooth® Low Energy), Wi-Fi® components, and other communication components
  • a power management interface 1420 e.g., an interface to send/receive power or control signals to/from the PMC 1312.
  • FIG. 15 is a block diagram illustrating components, according to some example embodiments, able to read instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and perform any one or more of the methodologies discussed herein.
  • FIG. 15 shows a diagrammatic representation of hardware resources 1500 including one or more processors (or processor cores) 1510, one or more memory/storage devices 1520, and one or more communication resources 1530, each of which may be communicatively coupled via a bus 1540.
  • node virtualization e.g., NFV
  • a hypervisor 1502 may be executed to provide an execution environment for one or more network slices/sub-slices to utilize the hardware resources 1500.
  • the processors 1510 may include, for example, a processor 1512 and a processor 1514.
  • CPU central processing unit
  • RISC reduced instruction set computing
  • CISC complex instruction set computing
  • GPU graphics processing unit
  • DSP digital signal processor
  • ASIC application specific integrated circuit
  • RFIC radio-frequency integrated circuit
  • the memory/storage devices 1520 may include main memory, disk storage, or any suitable combination thereof.
  • the memory/storage devices 1520 may include, but are not limited to any type of volatile or non-volatile memory such as dynamic random-access memory (DRAM), static random-access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), Flash memory, solid-state storage, etc.
  • DRAM dynamic random-access memory
  • SRAM static random-access memory
  • EPROM erasable programmable read-only memory
  • EEPROM electrically erasable programmable read-only memory
  • Flash memory solid-state storage, etc.
  • the communication resources 1530 may include interconnection or network interface components or other suitable devices to communicate with one or more peripheral devices 1504 or one or more databases 1506 via a network 1508.
  • the communication resources 1530 may include wired communication components (c.g., for coupling via a Universal Serial Bus (USB)), cellular communication components, NFC components, Bluetooth® components (e.g., Bluetooth® Low Energy), Wi-Fi® components, and other communication components.
  • Instructions 1550 may comprise software, a program, an application, an applet, an app, or other executable code for causing at least any of the processors 1510 to perform any one or more of the methodologies discussed herein.
  • the instructions 1550 may reside, completely or partially, within at least one of the processors 1510 (e.g., within the processor's cache memory), the memory/storage devices 1520, or any suitable combination thereof.
  • any portion of the instructions 1550 may be transferred to the hardware resources 1500 from any combination of the peripheral devices 1504 or the databases 1506. Accordingly, the memory of processors 1510, the memory/storage devices 1520, the peripheral devices 1504, and the databases 1506 are examples of computer-readable and machine-readable media.
  • one or more elements of FIGs. 12, 13, 14, and/or 15 may be configured to perform one or more processes, techniques, or methods as described herein, or portions thereof. In embodiments, one or more elements of FIGs. 12, 13, 14, and/or 15 may be configured to perform one or more processes, techniques, or methods, or portions thereof, as described in the following examples.
  • circuitry may refer to, be pail of, or include an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group), and/or memory (shared, dedicated, or group) that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable hardware components that provide the described functionality.
  • ASIC Application Specific Integrated Circuit
  • processor shared, dedicated, or group
  • memory shared, dedicated, or group
  • hardware elements may include devices, components, processors, microprocessors, circuits, circuit elements (e.g., transistors, resistors, capacitors, inductors, and so forth), integrated circuits, application specific integrated circuits (ASIC), programmable logic devices (PLD), digital signal processors (DSP), field programmable gate array (FPGA), memory units, logic gates, registers, semiconductor device, chips, microchips, chip sets, and so forth.
  • ASIC application specific integrated circuits
  • PLD programmable logic devices
  • DSP digital signal processors
  • FPGA field programmable gate array
  • software elements may include software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, procedures, software interfaces, application program interfaces (API), instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. Determining whether an example is implemented using hardware elements and/or software elements may vary in accordance with any number of factors, such as desired computational rate, power levels, heat tolerances, processing cycle budget, input data rates, output data rates, memory resources, data bus speeds and other design or performance constraints, as desired for a given implementation.
  • Coupled and “connected” along with their derivatives. These terms are not necessarily intended as synonyms for each other. For example, descriptions using the terms “connected” and/or “coupled” may indicate that two or more elements are in direct physical or electrical contact with each other. The term “coupled,” however, may also mean that two or more elements are not in direct contact with each other, but yet still co-operate or interact with each other.
  • a data processing system suitable for storing and/or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus.
  • the memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code to reduce the number of times code must be retrieved from bulk storage during execution.
  • code covers a broad range of software components and constructs, including applications, drivers, processes, routines, methods, modules, firmware, microcode, and subprograms. Thus, the term “code” may be used to refer to any collection of instructions which, when executed by a processing system, perform a desired operation or operations.
  • Processing circuitry, logic circuitry, devices, and interfaces herein described may perform functions implemented in hardware and also implemented with code executed on one or more processors.
  • Processing circuitry, or logic circuitry refers to the hardware or the hardware and code that implements one or more logical functions.
  • Circuitry is hardware and may refer to one or more circuits. Each circuit may perform a particular function.
  • a circuit of the circuitry may comprise discrete electrical components interconnected with one or more conductors, an integrated circuit, a chip package, a chip set, memory, or the like.
  • Integrated circuits include circuits created on a substrate such as a silicon wafer and may comprise components. And integrated circuits, processor packages, chip packages, and chipsets may comprise one or more processors.
  • Processors may receive signals such as instructions and/or data at the input(s) and process the signals to generate the at least one output. While executing code, the code changes the physical states and characteristics of transistors that make up a processor pipeline. The physical states of the transistors translate into logical bits of ones and zeros stored in registers within the processor. The processor can transfer the physical states of the transistors into registers and transfer the physical states of the transistors to another storage medium.
  • a processor may comprise circuits or circuitry to perform one or more sub-functions implemented to perform the overall function of “a processor”.
  • a processor may comprise one or more processors and each processor may comprise one or more processor cores that independently or interdependently process code and/or data.
  • Each of the processor cores are also “processors” and arc only distinguishable from processors for the purpose of describing a physical arrangement or architecture of a processor with multiple processor cores on one or more dies and/or within one or more chip packages.
  • Processor cores may comprise general processing cores or may comprise processor cores configured to perform specific tasks, depending on the design of the processor.
  • Processor cores may be processors with one or more processor cores.
  • processors may comprise one or more processors, each processor having one or more processor cores, and any one or more of the processors and/or processor cores may reside on one or more dies, within one or more chip packages, and may perform part of or all the processing required to perform the functionality.
  • a processor is a state machine or an application-specific integrated circuit (ASIC) that includes at least one input and at least one output.
  • a state machine may manipulate the at least one input to generate the at least one output by performing a predetermined series of serial and/or parallel manipulations or transformations on the at least one input.
  • the enhancements advantageously enable a framework to manage and orchestrate one or more services or network functions with a level of autonomy for a communications system or network; emulate, via a digital twin, the communications network with services or network functions; deploy configurations to the network functions of devices of the communications network to establish the one or more services; manage and orchestrate the communications network, through stages of network planning, simulation, emulation, establishment, configuration, healing, optimization, protection, or a combination thereof via observation, analytics, decision, and execution; gather and store data from the communications network; train, test, emulate, deploy, or a combination thereof, machine learning models to infer data analytics for management of the communications network and services or network functions; and manage and orchestrate a cloud computing system of the communications network and offer software as a service for services of components of the framework.
  • Example 1 is an apparatus with a framework to manage and orchestrate a network function of a service with a level of autonomy for a communications network, comprising a first interface for communication with the consumer of the management services; a second interface for communication with the communications network; logic circuitry coupled with the interfaces to perform operations to receive a request via the first interface for managing and orchestrating the service or the network function; generate a configuration for the network function of the communications network; and deploy the configuration to the network function of the communications network via the second interface.
  • Example 2 the apparatus of Example 1, wherein the logic circuitry comprises one or more processors coupled with the first interface and the second interface, and a memory coupled with the one or more processor, wherein the memory comprises code for the framework to execute on at least one of the one or more processors.
  • Example 3 the apparatus of Example 1, the logic circuitry to further manage and orchestrate the communications network, the service or the network function, and the existing services through stages of network planning, simulation, emulation, establishment, configuration, healing, optimization, protection, or a combination thereof via one or more iterations of observation, analytics, decision, and execution.
  • Example 4 the apparatus of Example 1, the logic circuitry to further manage and orchestrate the communications network, the service or the network function, and the existing services by emulation, via a digital twin, the communications network and the service or the network function with existing services prior to deployment of the network function in the communications network to analyze performance of the service or the network function and capabilities of the communications network in conjunction with existing services, and to optimize the service or the network function and the configuration of the network function of a device of the communications network to perform the services.
  • Example 5 the apparatus of Example 1, the logic circuitry to further gather and store data from the communications network, the data related to the communications network, the existing services, and the service or the network function.
  • Example 6 the apparatus of Example 1, the logic circuitry to further train, test, emulate, deploy, or a combination thereof, machine learning models to infer data analytics for management of the communications network and the service or the network function.
  • Example 7 the apparatus of Example 1, the logic circuitry to further manage and orchestrate a cloud computing system of the communications network, the cloud computing system to provide the service to a system function, a management function, the network function, a model, an application, or a combination thereof.
  • Example 8 the apparatus of any one or more of Examples 1-6, the logic circuitry to further generate and update a knowledge data structure to relate an issue with a solution for the communications network and the service based on operating experience via data collection of data related to operating experience via simulation in the digital twin, deployment in the communications system, or a combination thereof, and analysis of the data related to the operating experience.
  • the logic circuitry to further update the issue and the solution in the knowledge data structure to refine the issue, to optimize the solution for the issue, or a combination thereof; and share the solution for the issue arising in existing services, for the issue arising in development of new services, for the issue arising in the service, for the issue arising in the existing network functions, for the issue arising in the network function, or a combination thereof.
  • Example 10 is a method for a framework to manage and orchestrate one or more network functions with a level of autonomy for a communications network, comprising receiving a request from a consumer of the management services via a first interface for managing and orchestrating one or more network functions; generating one or more configurations for the one or more network functions of the communications network; and deploying the one or more configurations to the communications network to the one or more network functions of the communications network via the second interface.
  • the method of Example 10 further comprising managing and orchestrating the communications network, the one or more network functions, and the existing services through stages of network planning, simulation, emulation, establishment, configuration, healing, optimization, protection, or a combination thereof via one or more iterations of observation, analytics, decision, and execution.
  • Example 12 the method of Example 9, further comprising training, testing, emulating, deploying, or a combination thereof, machine learning models to infer data analytics for management of the communications network and the one or more network functions.
  • Example 13 the method of Example 9, further comprising managing and orchestrating a cloud computing system of the communications network, the cloud computing system to provide a service to a system function, a management function, the one or more network functions, a model, an application, or a combination thereof.
  • Example 14 the method of any Example 9-13, further comprising generating and updating a knowledge data structure to relate issues with solutions for the communications network and the one or more network functions based on operating experience via data collection of data related to operating experience via simulation in the digital twin, deployment in communications system, or a combination thereof, and analysis of the data related to the operating experience.
  • Example 15 is a machine-readable medium containing instructions for a framework to manage and orchestrate services or network functions with a level of autonomy for a communications network, which when executed by a processor, cause the processor to perform operations, the operations to receive a request via the first interface for managing and orchestrating the services or the network functions; generate the configurations for the network functions of the communications network; and deploy the configurations to the network functions of the communications network via the second interface.
  • the machine- readable medium of Example 15 the operations to further manage and orchestrate the communications network, the services or the network functions, and the existing services through stages of network planning, simulation, emulation, establishment, configuration, healing, optimization, protection, or a combination thereof via one or more iterations of observation, analytics, decision, and execution.
  • Example 17 the machine-readable medium of Example 15, the operations to further gather and store data from the communications network, the data related to the communications network, the existing services, and the services or the network functions.
  • Example 18 the machine-readable medium of Example 15, the operations to further train, test, emulate, deploy, or a combination thereof, machine learning models to infer data analytics for management of the communications network and the services or the network functions.
  • Example 19 the machine-readable medium of Example 15, the operations to further manage and orchestrate a cloud computing system of the communications network, the cloud computing system to provide the services to system functions, management functions, the network functions, models, applications, or a combination thereof.
  • Example 20 the machine- readable medium of any Example 15-19, the operations to further emulate, via a digital twin, the communications network and the services or the network functions with existing services prior to deployment of the services or the network functions in the communications network to analyze performance of the services or the network functions and capabilities of the communications network in conjunction with existing services, and to optimize the services and the configurations of the network functions of devices of the communications network to perform the services.
  • Example 21 is an apparatus comprising a means for any action in Examples 1-20.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Une logique peut fournir un cadre d'applications pour gérer et orchestrer des services ou des fonctions de réseau présentant un niveau d'autonomie pour un réseau de communication. La logique peut émuler, par l'intermédiaire d'un jumeau numérique, le réseau de communication avec les services ou les fonctions de réseau. La logique peut déployer des configurations destinées aux fonctions de réseau afin d'établir les services ou les fonctions de réseau. Une logique peut gérer et orchestrer le réseau de communication, par l'intermédiaire d'étapes de planification de réseau, de simulation, d'émulation, d'établissement, de configuration, de restauration, d'optimisation, de protection ou d'une combinaison de celles-ci au moyen d'actions d'observation, d'analyse, de décision et d'exécution. La logique peut rassembler et stocker des données provenant du réseau de communication. La logique peut entraîner, tester, émuler, déployer, ou une combinaison de ces actions, des modèles d'apprentissage automatique pour inférer des analyses de données pour la gestion du réseau de communication. Et la logique peut gérer et orchestrer un système informatique en nuage du réseau de communication et fournir un logiciel en tant que service pour des services de composants du cadre d'applications.
PCT/US2024/036927 2023-07-07 2024-07-05 Procédés et agencements pour un cadre d'applications de système Pending WO2025014819A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202363512513P 2023-07-07 2023-07-07
US63/512,513 2023-07-07

Publications (1)

Publication Number Publication Date
WO2025014819A1 true WO2025014819A1 (fr) 2025-01-16

Family

ID=94216068

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2024/036927 Pending WO2025014819A1 (fr) 2023-07-07 2024-07-05 Procédés et agencements pour un cadre d'applications de système

Country Status (1)

Country Link
WO (1) WO2025014819A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN119759585A (zh) * 2025-03-05 2025-04-04 东北大学秦皇岛分校 面向依赖子任务的移动边缘计算任务调度系统及方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110213688A1 (en) * 2008-08-29 2011-09-01 Nec Europe Ltd. Process for providing network access for a user via a network provider to a service provider
US20200228602A1 (en) * 2020-03-25 2020-07-16 Marcin Spoczynski Computer-readable storage medium, an apparatus and a method to select access layer devices to deliver services to clients in an edge computing system
US20210152430A1 (en) * 2017-05-03 2021-05-20 NEC Laboratories Europe GmbH Mla based distributed management and orchestration (mano) system and method
WO2022125296A1 (fr) * 2020-12-08 2022-06-16 Intel Corporation Mécanismes pour permettre des services informatiques en réseau
WO2023044721A1 (fr) * 2021-09-24 2023-03-30 Intel Corporation Gestion de stationnement et d'emplacement automatisée collaborative basée sur une infrastructure

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110213688A1 (en) * 2008-08-29 2011-09-01 Nec Europe Ltd. Process for providing network access for a user via a network provider to a service provider
US20210152430A1 (en) * 2017-05-03 2021-05-20 NEC Laboratories Europe GmbH Mla based distributed management and orchestration (mano) system and method
US20200228602A1 (en) * 2020-03-25 2020-07-16 Marcin Spoczynski Computer-readable storage medium, an apparatus and a method to select access layer devices to deliver services to clients in an edge computing system
WO2022125296A1 (fr) * 2020-12-08 2022-06-16 Intel Corporation Mécanismes pour permettre des services informatiques en réseau
WO2023044721A1 (fr) * 2021-09-24 2023-03-30 Intel Corporation Gestion de stationnement et d'emplacement automatisée collaborative basée sur une infrastructure

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN119759585A (zh) * 2025-03-05 2025-04-04 东北大学秦皇岛分校 面向依赖子任务的移动边缘计算任务调度系统及方法

Similar Documents

Publication Publication Date Title
US11917527B2 (en) Resource allocation and activation/deactivation configuration of open radio access network (O-RAN) network slice subnets
US20240298225A1 (en) Using ai-based models for network energy savings
US20230268982A1 (en) Network controlled repeater
WO2023215720A1 (fr) Autorisation et authentification de transfert de modèle d'apprentissage automatique
EP4449689A1 (fr) Solutions basées sur un modèle de ressources de réseau pour formation de modèle ai-ml
WO2023287808A1 (fr) Formation de faisceau destinée à des modes entrée multiple sortie multiple (mimo) dans des systèmes de réseau d'accès radio ouvert (o-ran)
WO2024091862A1 (fr) Modèles d'intelligence artificielle/apprentissage automatique (ai/ml) pour déterminer la consommation d'énergie dans des instances de fonction de réseau virtuel
WO2025014819A1 (fr) Procédés et agencements pour un cadre d'applications de système
US20240397362A1 (en) Enhanced performance measurements related to one-way uplink packet delay in wireless communications
US20250274744A1 (en) User equipment (ue)-side applicable functionality reporting and management
WO2025030150A1 (fr) Procédés et agencements pour la gestion de modèles d'apprentissage automatique
WO2025076680A1 (fr) Gestion de réseau central d'intelligence artificielle au niveau d'un équipement d'utilisateur
WO2025216900A1 (fr) Amplification de puissance de liaison montante pour agrégation de porteuses de liaison montante
WO2025076688A1 (fr) Enregistrement et découverte d'entraînement de modèle pour intelligence artificielle au niveau d'un équipement utilisateur
WO2024238186A1 (fr) Commande de puissance de transmission pour gestion d'interférence de liaison croisée
US20250247744A1 (en) User equipment delegation service
WO2025235790A1 (fr) Transmission d'un signal de référence de sondage avec compensation de perte d'insertion
WO2025174443A1 (fr) Commande de puissance de liaison montante dans des systèmes en duplex intégral
WO2025174457A1 (fr) Commande de puissance de srs et avance de temporisation pour trps
WO2025212440A1 (fr) Association ptrs et dmrs pour transmissions sans fil
WO2024238356A1 (fr) Mesures de saut de fréquence pour positionnement d'ue redcap
WO2024211739A1 (fr) Configurations de positionnement de phase de porteuse
WO2025029999A1 (fr) Mesure de technologie d'accès inter-radio (rat) sans intervalle
WO2025035080A1 (fr) Différence de synchronisation de réception maximale pour réceptions à panneaux multiples
WO2025085764A1 (fr) Réseau d'accès radio (ran) basé sur un service

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 24840337

Country of ref document: EP

Kind code of ref document: A1