CN116868556A

CN116868556A - Mechanism for implementing in-network computing services

Info

Publication number: CN116868556A
Application number: CN202180075376.7A
Authority: CN
Inventors: 李倩; 丁宗睿; 吴耕
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2020-12-08
Filing date: 2021-11-22
Publication date: 2023-10-10
Also published as: WO2022125296A1

Abstract

Various embodiments herein provide techniques related to computing an intra-network service grid function of a service function (CSF). The in-network service grid function may identify devices associated with the in-network service grid function. The in-network service grid function may also identify a service request received from the device and identify a service instance for the device in a service registry of the CSF based on the service request. The in-network service grid function may also send an indication of the service instance. Other embodiments may be described or claimed.

Description

Mechanism for implementing in-network computing services

Cross Reference to Related Applications

The present application claims priority from U.S. provisional patent application No.63/122,768 filed on 8 months of 2020.

Technical Field

Various embodiments may relate generally to the field of wireless communications. For example, some embodiments may relate to an in-network computing service.

Background

In a legacy client-server computing model, a client device may need to connect to an application server for computing services. However, such a connection may require a time-consuming connection procedure, which may introduce time delays.

Drawings

Embodiments will be readily understood by the following detailed description in conjunction with the accompanying drawings. To facilitate this description, like reference numerals designate like structural elements. The embodiments are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings.

Fig. 1 illustrates an example Innovative Optical and Wireless Network (IOWN) all-photon network (APN) and computing/data infrastructure architecture, in accordance with various embodiments.

Fig. 2 illustrates an example Computing Service Function (CSF) in a device and network in accordance with various embodiments.

Fig. 3 illustrates an example technique related to the use of an in-network Domain Name System (DNS) in accordance with various embodiments.

Fig. 4 schematically illustrates an example network in accordance with various embodiments.

FIG. 5 illustrates an example technique related to the use of an in-network service grid in accordance with various embodiments.

Fig. 6 schematically illustrates components of a network in accordance with various embodiments.

Fig. 7 illustrates example techniques related to device-network service orchestration according to various embodiments.

Fig. 8 schematically illustrates an alternative example of a network in accordance with various embodiments.

Fig. 9 illustrates an example technique related to device-network resource orchestration.

Fig. 10 illustrates an example network architecture 1000 in accordance with various embodiments.

Fig. 11 schematically illustrates a wireless network 1100 in accordance with various embodiments.

Fig. 12 illustrates components of a computing device 1200 according to some example embodiments.

Detailed Description

The following detailed description refers to the accompanying drawings. The same reference numbers may be used in different drawings to identify the same or similar elements. In the following description, for purposes of explanation and not limitation, specific details are set forth such as particular structures, architectures, interfaces, techniques, etc. in order to provide a thorough understanding of the various aspects of the various embodiments. However, it will be apparent to one skilled in the art having the benefit of this disclosure that the various aspects of the various embodiments may be practiced in other examples that depart from these specific details. In certain instances, descriptions of well-known devices, circuits, and methods are omitted so as not to obscure the description of the various embodiments with unnecessary detail. For the purposes of this document, the phrases "A or B" and "A/B" mean (A), (B) or (A and B).

Typically, communication and computing systems are designed to meet workload requirements and implement new types of workloads and applications. Typical computing workloads in today's systems can be categorized mainly into two categories: client-server type workloads (e.g., online games, web services, etc.) and High Performance Computing (HPC) type workloads (e.g., weather forecast, scientific computing, etc.).

Client-server type workloads (e.g., online games, web services, etc.) are pre-partitioned between clients and servers during application development. The micro-service framework may be used to facilitate development and computational expansion. Client-server type workloads are typically less sensitive to communication and I/O latency between micro-services. HPC type workloads typically run within a data center. Parallelization is managed by the data center OS. HPC workload is sensitive to communication and I/O latency between compute nodes in the DC. The advent of the cyber-physical system (cyber-physical system) is expected to bring the following types of workloads: sensing and cognition and network physical interactive systems. The sensing and cognitive workload may utilize or include local data collection, processing and analysis. The sensing and cognitive workload is time-delay sensitive (e.g., fault detection, hazard alarms). The cyber-physical interactive system workload utilizes or includes real-time interactions between physical domains and network domains. Network physical interactive system workloads are also time delay sensitive.

Emerging new workloads require low latency ubiquitous computing across devices, networks, and clouds. Today's typical cloud computing is done in an edge/center cloud and uses orchestrators running in the application layer to manage computing workload distribution. FIG. 1 illustrates an example workload distribution scheme used by a cloud computing system.

In particular, fig. 1 illustrates an example IOWN all-photon network (APN) and computing/data infrastructure architecture, in accordance with various embodiments. Fig. 1 includes data plane functions in an IOWN APN, etc. In the example of fig. 1, the data plane functions interact with APN controllers, CSF, network transport nodes (e.g., forwarders, aggregation nodes, switching nodes, etc.), devices/terminals, and external clouds. In these interactions, the data plane functions may act as a data consumer or a data provider.

The data plane functions may have the following functions: (1) device identity, access and QoS policies, configuration; (2) Measurement and sensing data storage within the communication and computing infrastructure and sharing between NW and computing functions; (3) data processing and analysis; and (4) data opening to external users as a service.

Fig. 2 illustrates an example Computing Service Function (CSF) in a device and network in accordance with various embodiments. The functions of CSF include: (1) For in-network computing resources, CSF provides functions such as service discovery, access control, charging, etc.; and (2) cloud computing services may also be registered in CSF. The CSF may direct the device's request for cloud computing services to the appropriate computing location.

Embodiments herein relate to mechanisms for implementing intra-network computing and functions of CSF. Embodiments herein may be implemented as part of an IOWN framework (e.g., IOWN Global Forum (GF) as part of an APN system). In particular, the present disclosure relates to solving the following three problems identified in today's communication and computing systems.

As a first problem, in a legacy client-server computing model, a client device (which may also be referred to herein as a "client" or "device") may need to connect to an application server for computing services. A typical process may include the following elements:

1) The client is configured with an Internet Service Provider (ISP) Domain Name System (DNS) server Internet Protocol (IP) address

2) Client sends domain name query to ISP DNS server

3) ISP DNS server contacts Content Security Policy (CSP) authority DNS server for domain name resolution

4) CSP rights DNS server selects the appropriate application server

5) The CSP may choose to launch the new application server at a location near the client

6) CSP authority DNS server responds to ISP DNS server domain name query

7) ISP DNS server responds to client domain name queries

8) Clients connect to assigned application servers

It can be seen that the above elements may lead to long connection setup times due to the back and forth interactions between the device, DNS server and CSP controller. Long connection setup times may result in long first packet delays. For streaming type services, long connection setup times may be amortized by long service times. However, for transactional services, long connection setup times may have a significant impact on performance.

As a second problem, computing resources in legacy systems may be concentrated in data centers (including large data centers and smaller edge data centers). Computing resources and services may be centrally managed by a CSP resource orchestrator. Data center modes of operation are designed to host large applications with stable traffic (e.g.,etc.). However, as applications, services, and computing requirements become more diverse, flexible ways of ubiquitous computing and accessing computing resources may be desired. The desire to boost energy efficiency for sustainable growth also requires more dynamic computing resource usage. Computing communities have been working on server-less technology to adapt computing resources to service traffic demands. Computing and communication infrastructure can also evolve to realize the full benefits of server-less technology (e.g., infrastructure that inherently supports computing resource discovery, access control, and load balancing, rather than relying too much on top-level (top) solutions).

As a third problem, workload partitioning between clients and servers in legacy client-server applications may be fixed while the applications are programmed. A Remote Procedure Call (RPC) interface may be programmed to enable communication between a client-side application and a server-side application. The model may be acceptable for legacy client-server type applications and workloads. However, looking into the future, as more diverse workloads and devices demand more diverse computing, a fixed workload partitioning model may become undesirable or infeasible. For example, devices and network computing nodes may dynamically change workload partitioning between networks and devices based on conditions such as computing load, battery life, network connection. To allow for such dynamic workload partitioning, new functionality in the communication and computing infrastructure may be desirable.

Embodiments discussed herein address one or more of the above problems. Specifically, the embodiment includes: example 1 (involving an in-network DNS); example 2 (involving an in-network service grid); example 3 (involving device-network service orchestration); and embodiment 4 (related to device-network resource orchestration).

Example 1: intra-network DNS

Embodiment 1 can solve the above-described long connection setup time problem by implementing an in-network DNS. The CSF (e.g., the CSF of fig. 2) may be equipped with DNS functionality. The example process of embodiment 1 may operate as follows according to fig. 2 and 3:

1) At 301, a device (e.g., the device of fig. 2) sends a Dynamic Host Configuration Protocol (DHCP) broadcast, for example, to the network of fig. 2.

2) At 302, a DHCP server of the network (e.g., DHCP server of fig. 4) allocates an IP address and other system configurations (e.g., DNS server addresses). If the CSF of the network supports in-network DNS, the DHCP server may inform the device of the CSF address as a DNS server address. The DHCP server of the Internet Service Provider (ISP) may also inform the device of the CSF server configuration (whether the ISP supports CSF, CSF IP address, etc.).

3) At 303, an application running on the device (e.g., the application of fig. 2 located in the device) may request access to the domain name.

4) At 304, the domain name resolver at the device may look up a domain name record in its cache.

5) If the domain name is not in its local cache, the domain name resolver may send the domain name to a configured DNS server of the network to resolve the address.

a. If a CSF address is used as the DNS server address, the domain name resolution request may be directed to a configured CSF of the network (e.g., the CSF of fig. 4).

b. If a conventional DNS server is used, a CSF-capable network switch may filter out DNS requests and examine its locally cached domain name records to resolve domain names.

Embodiment 1 may be used to at least partially solve problem 1. However, if a domain name is used to find a server IP address, more elements may be required to find a service. Furthermore, if the domain name resolution request is sent over hypertext transfer protocol secure (HTTPS), the in-network DNS solution may not work.

Example 2: intra-net service grid

The in-network service grid may contain service orchestration functions (e.g., service discovery, load balancing, service instance assignment, service access control, etc. in the network). These functions may be performed in legacy networks via a service front-end in the CSP cloud. The in-network service grid may enable service orchestration access across different service providers, including network operators, CSPs, and application service providers.

Fig. 4 depicts an example architecture that shows interactions between devices 1-M, an in-network service grid function instance, a service registry instance, a network controller, or a DHCP server, and a service instance. Both the in-network service grid function and the service registry may be part of the depicted Computational Service Function (CSF).

An example process associated with fig. 4 and 5 may be as follows:

1) At 501, a device is associated with one of the in-network service grid function instances (e.g., device 1 is associated with in-network service grid function instance 1).

2) At 502, the device sends a service request to an associated in-network service grid function.

3) At 503, the in-network service grid function performs a query related to the service with a service registry having records related to multiple instances of different services.

4) At 504, the in-network service grid function selects a service instance for the device. The selection decision may be based on factors such as the location of the device, the location of the service instance, the load of the service instance, the estimated service response time, and so on.

5) At 505, the in-network service grid function sends a response to the device's service request. The response message may include the assigned service instance address, the assigned computing resources, the service execution results, and the like.

In some embodiments, element (1) (e.g., a device associated with one of the in-network service grid function instances) may include one or both of the following two options:

● Option 1: association managed by a network controller or DHCP server. In this option, the network controller or DHCP server will assign CSF to the device when the device first attaches to the network. The network controller or DHCP server may then configure the device with a CSF address.

● Option 2: and (5) autonomous association of devices. In this option, the device may broadcast its CSF association request message when the device first attaches to the network. CSF receiving the association request message may be responsive to the device. The response message may include information about CSF address, service capability, etc. If more than one CSF is responsive to the device, the device may select one CSF with which to associate (e.g., by sending an association request to that CSF, which then responds with a grant message).

Services (including in-network services and external services) are registered with the service registry. These services are indicated in fig. 1 as service X (with multiple instances), service Y (with multiple instances), and so on. As an example, there may be at least three options to enable service registration:

● Option 1: subscription-based methods. In this approach, a service registry may subscribe to service events. If a new event exists in the service (e.g., instantiating a new service instance, a service update, etc.), the service registry may be notified.

● Option 2: query-based methods. In this method, the service registry periodically sends a query message to each service. Each service may respond to the query with updated service status.

● Option 3: notification-based methods. In this method, each service may send a notification message to the service registry when there is a state change.

Embodiment 2 may be expected to solve the first two problems described above. In particular, embodiment 2 may address the latency associated with computing service setup time and computing resource/service discovery/access inflexibility.

Example 3: device-network service orchestration

To address the third problem described above, particularly where a fixed workload partitioning between a client (e.g., device) and a server may be a problem, a service orchestration function may be introduced. Service Orchestration Functions (SOFs) reside in both the device and the CSF. The SOF may run on top of the device and/or CSF Operating System (OS) and may be used to dynamically direct service execution between the device and the network. Fig. 6 provides an illustration of SOF in a device and network and interfaces between the two ends.

An example process related to embodiment 3 may be described as follows with respect to fig. 6 and 7:

1) At 701, a client application on a device interacts with a service orchestration function-client (SOF-C) to request a service.

2) At 702, the SOF-C interacts with a device OS and a service orchestration function-network (SOF-N) to obtain information about service availability (both locally and in the network).

3) The sof-C may then dynamically direct the service requests of the application between local execution (e.g., on the device) and network execution at 703.

a. If the execution is done locally (e.g., on the device), the SOF-C will send a service request to the local OS, e.g., via a system call.

b. If execution is done in the network, the SOF-C will send a service request to the CSF, e.g., via a remote procedure call.

The decision as to where to perform the requested service may be made by SOF-C or SOF-N. In one embodiment, when the SOF-C is making a decision, the SOF-C may collect information from the local OS and SOF-N regarding service availability, network conditions, device battery level, estimated service execution time, etc. In one embodiment, when the SOF-N is making a decision, the SOF-N may collect information from the SOF-C, the network service registry, and/or the network computing resource platform regarding one or more of service availability, network conditions, device battery level, network computing load, estimated service execution time, and the like.

Example 4: device-network resource orchestration

Embodiment 3 may operate on top of the OS and may have an impact on applications (e.g., applications that would need to interact with SOF-C). Embodiment 4 may involve using a Resource Orchestration Function (ROF) as part of the network stack. ROFs in the client side and the network side may be used to orchestrate computing resources in the devices and the network. Fig. 8 illustrates an example of such a ROF and an interface between a device and a network in accordance with various embodiments.

An example procedure for the present embodiment according to fig. 8 and 9 may be as follows:

1) At 901, a resource orchestration function-client (ROF-C) of a device may interact with a resource orchestration function-network (ROF-N) of CSF via a device-network resource orchestration interface to obtain a list of network computing resources and capabilities that the device is capable of using. This may be accomplished via one or more of the following methods.

a. Option 1: the ROF-N broadcasts a list of one or more network computing resources and capabilities as system information.

b. Option 2: the ROF-C sends a query message to the ROF-N regarding network computing resources and capabilities. ROF-N responds to the query of ROF-C.

2) At 902, the ROF-C opens a list of computing resources and capabilities (from one or both of options 1 and 2) to the OS of the device.

3) At 903, when the device's OS requests computing resources, ROF-C sends a resource request to ROF-N.

4) At 904, the ROF-N decides whether to accept the request for ROF-C and responds to the request for ROF-C.

5) At 905, if the resource request is accepted, then ROF-C and ROF-N may establish a data path between the device and the network for accessing the computing resource. The OS may then use the computing resources via the data path.

Fig. 10-12 illustrate various systems, devices, and components that may implement aspects of the disclosed embodiments.

Fig. 10 illustrates an example network architecture 1000 in accordance with various embodiments. The network 1000 may operate in a manner consistent with 3GPP technical specifications for LTE or 5G/NR systems. However, the example embodiments are not limited thereto, and the described embodiments may be applied to other networks that benefit from the principles described herein, such as future 3GPP systems, and the like.

The network 1000 includes a UE 1002, the UE 1002 being any mobile or non-mobile computing device designed to communicate with the RAN 1004 via an over-the-air connection. The UE 1002 is communicatively coupled with the RAN 1004 over a Uu interface, which may be applicable to both LTE and NR systems. Examples of UEs 1002 include, but are not limited to, smart phones, tablet computers, wearable computers, desktop computers, laptop computers, in-vehicle infotainment systems, in-vehicle entertainment systems, instrument clusters, head mounted display (HUD) devices, in-vehicle diagnostic devices, dashboard mobile devices, mobile data terminals, electronic engine management systems, electronic/engine control units, electronic/engine control modules, embedded systems, sensors, microcontrollers, control modules, engine management systems, networking appliances, machine type communication devices, machine-to-machine (M2M), device-to-device (D2D), machine Type Communication (MTC) devices, internet of things (IoT) devices, and the like. The network 1000 may include a plurality of UEs 1002 directly coupled to each other via D2D, proSe, PC5 and/or Side Link (SL) interfaces. These UEs 1002 may be M2M/D2D/MTC/IoT devices and/or vehicle systems that communicate using physical side link channels (e.g., without limitation PSBCH, PSDCH, PSSCH, PSCCH, PSFCH, etc.). UE 1002 may perform blind decoding attempts for the SL channel/link in accordance with various embodiments herein.

In some embodiments, UE 1002 may additionally communicate with AP 1006 via an over-the-air (OTA) connection. The AP 1006 manages WLAN connections that may be used to offload some/all network traffic from the RAN 1004. The connection between the UE 1002 and the AP 1006 may conform to any IEEE 802.11 protocol. Further, UE 1002, RAN 1004, and AP 1006 may utilize cellular-WLAN aggregation/integration (e.g., LWA/LWIP). cellular-WLAN aggregation may involve the UE 1002 being configured by the RAN 1004 to utilize both cellular radio resources and WLAN resources.

The RAN 1004 includes one or more access network nodes (AN) 1008.AN 1008 terminates the air interface for UE 1002 by providing access stratum protocols, including RRC, PDCP, RLC, MAC and PHY/L1 protocols. In this way, the AN 1008 enables a data/voice connection between the CN 1020 and the UE 1002. AN 1008 may be a macrocell base station, or a low power base station for providing a femtocell, picocell, or other similar cell with a smaller coverage area, smaller user capacity, or higher bandwidth than a macrocell, or some combination thereof. In these implementations, AN 1008 may be referred to as a BS, gNB, RAN node, eNB, ng-eNB, nodeB, RSU, TRxP, or the like.

One example implementation is a "CU/DU split" architecture, wherein AN 1008 is embodied as a gNB-Central Unit (CU) communicatively coupled to one or more gNB-Distributed Units (DUs), wherein each DU may be communicatively coupled to one or more Radio Units (RUs) (also referred to as RRHs, RRUs, etc.) (see, e.g., 3GPP TS 38.401v16.1.0 (2020-03)). In some implementations, one or more RUs may be separate RSUs. In some implementations, the CU/DU separation may include a ng-eNB-CU and one or more ng-eNB-DUs, in lieu of or in addition to the gNB-CU and gNB-DU, respectively. AN 1008 embodied as a CU may be implemented in a separate device or as one or more software entities running on a server computer as part of, for example, a virtual network comprising virtual baseband units (BBUs) or BBU pools, cloud RANs (CRANs), radio Equipment Controllers (RECs), radio Cloud Centers (RCCs), centralized RANs (C-RANs), virtualized RANs (vrans), etc. (although these terms may refer to different implementation concepts). Any other type of architecture, arrangement, and/or configuration may be used.

The multiple ANs may be coupled to each other via AN X2 interface (if the RAN 1004 is AN LTE RAN or AN evolved universal terrestrial radio access network (E-UTRAN) 1010) or AN Xn interface (if the RAN 1004 is a NG-RAN 1014). The X2/Xn interface (which may be separated into control/user plane interfaces in some embodiments) may allow the AN to communicate information related to handoff, data/context transfer, mobility, load management, interference coordination, etc.

The ANs of the RAN 1004 may each manage one or more cells, groups of cells, component carriers, etc. to provide AN air interface for network access to the UE 1002. The UE 1002 may be simultaneously connected with multiple cells provided by the same or different ANs 1008 of the RAN 1004. For example, the UE 1002 and the RAN 1004 may use carrier aggregation to allow the UE 1002 to connect with multiple component carriers, each component carrier corresponding to a Pcell or Scell. In a dual connectivity scenario, the first AN 1008 may be a primary node providing AN MCG and the second AN 1008 may be a secondary node providing AN SCG. The first/second AN 1008 may be any combination of eNB, gNB, ng-enbs, etc.

RAN 1004 may provide the air interface on licensed spectrum or unlicensed spectrum. To operate in unlicensed spectrum, a node may use LAA, eLAA, and/or feLAA mechanisms with PCell/Scell based on CA technology. Prior to accessing the unlicensed spectrum, the node may perform medium/carrier sense operations based on, for example, a Listen Before Talk (LBT) protocol.

In a V2X scenario, the UE 1002 or AN 1008 may be or act as a roadside unit (RSU), which may refer to any traffic infrastructure entity for V2X communications. The RSU may be implemented in or by a suitable AN or a fixed (or relatively fixed) UE. An RSU implemented in or by: for a UE, it may be referred to as a "UE-type RSU"; for enbs, it may be referred to as "eNB-type RSUs"; for gNB, it may be referred to as "gNB-type RSU"; etc. In one example, the RSU is a computing device coupled with radio frequency circuitry located at the roadside that provides connectivity support to passing vehicle UEs. The RSU may also include internal data storage circuitry for storing intersection map geometry, traffic statistics, media, and applications/software for sensing and controlling ongoing vehicle and pedestrian traffic. The RSU may provide very low latency communications required for high speed events (e.g., collision avoidance, traffic alerts, etc.). Additionally or alternatively, the RSU may provide other cellular/WLAN communication services. The components of the RSU may be enclosed in a weather-proof enclosure suitable for outdoor installation, and may include a network interface controller for providing a wired connection (e.g., ethernet) to a traffic signal controller or backhaul network.

In some embodiments, the RAN 1004 may be an E-UTRAN 1010 with one or more enbs 1012. The E-UTRAN 1010 provides an LTE air interface (Uu) with the following characteristics: SCS of 15 kHz; a CP-OFDM waveform for DL and an SC-FDMA waveform for UL; turbo codes for data and TBCCs for control; etc. The LTE air interface may rely on: CSI-RS for CSI acquisition and beam management; PDSCH/PDCCH DMRS for PDSCH/PDCCH demodulation; and CRS for cell search and initial acquisition, channel quality measurements, and channel estimation for coherent demodulation/detection at the UE. The LTE air interface may operate on the sub-6GHz band.

In some embodiments, the RAN 1004 may be a Next Generation (NG) -RAN 1014 with one or more gnbs 1016 and/or one or more NG-enbs 1018. The gNB 1016 connects with the 5G enabled UE 1002 using a 5G NR interface. The gNB 1016 is connected to the 5GC 1040 via a NG interface, which includes an N2 interface or an N3 interface. The NG-eNB 1018 is also connected to the 5gc 1040 through the NG interface, but may be connected to the UE 1002 via the Uu interface. The gNB 1016 and the ng-eNB 1018 may be connected to each other through an Xn interface.

In some embodiments, the NG interface may be split into two parts: a NG user plane (NG-U) interface that carries traffic data (e.g., an N3 interface) between the node of NG-RAN 1014 and UPF 1048; and a NG control plane (NG-C) interface, which is a signaling interface (e.g., an N2 interface) between the node of NG-RAN 1014 and AMF 1044.

The NG-RAN 1014 may provide a 5G-NR air interface (which may also be referred to as Uu interface) with the following characteristics: a variable SCS; CP-OFDM for DL, CP-OFDM for UL, and DFT-s-OFDM; polarization codes for control, repetition codes, simplex codes, and Reed-Muller codes, and LDPC codes for data. Similar to the LTE air interface, the 5G-NR air interface may rely on CSI-RS, PDSCH/PDCCH DMRS. The 5G-NR air interface may not use CRS but may use PBCH DMRS for PBCH demodulation; PTRS for phase tracking for PDSCH; and tracking reference signals for time tracking. The 5G-NR air interface may operate on an FR1 band including a sub-6GHz band or an FR2 band including a frequency band from 24.25GHz to 52.6 GHz. The 5G-NR air interface may comprise an SSB, which is an area of the downlink resource grid comprising PSS/SSS/PBCH.

The 5G-NR air interface may utilize BWP for various purposes. For example, BWP may be used for dynamic adaptation of SCS. For example, UE 1002 may be configured with multiple BWP's, where each BWP configuration has a different SCS. When a BWP change is indicated to the UE 1002, the SCS of the transmission also changes. Another example of use of BWP relates to power saving. In particular, the UE 1002 may be configured with multiple BWPs having different amounts of frequency resources (e.g., PRBs) to support data transmission in different traffic load scenarios. BWP containing a smaller number of PRBs may be used for data transmission with small traffic load while allowing power saving at the UE 1002 and in some cases at the gNB 1016. BWP containing a larger number of PRBs may be used for scenarios with higher traffic load.

The RAN 1004 is communicatively coupled to a CN 1020, the CN 1020 including network elements and/or Network Functions (NF) to provide various functions to support data and telecommunications services for clients/subscribers (e.g., UE 1002). The components of the CN 1020 may be implemented in one physical node or in a separate physical node. In some embodiments, NFV may be used to virtualize any or all of the functionality provided by the network elements of CN 1020 onto physical computing/storage resources in servers, switches, and the like. The logical instantiation of the CN 1020 may be referred to as a network slice, while the logical instantiation of a portion of the CN 1020 may be referred to as a network sub-slice.

CN 1020 may be an LTE CN 1022 (also referred to as Evolved Packet Core (EPC) 1022). EPC 1022 may include MME 1024, SGW 1026, SGSN 1028, HSS1030, PGW 1032, and PCRF 1034, which are coupled to each other through interfaces (or "reference points") as shown. NF in EPC 1022 is briefly described as follows.

MME 1024 implements mobility management functions to track the current location of UE 1002 to facilitate paging, bearer activation/deactivation, handover, gateway selection, authentication, etc.

SGW 1026 terminates the S1 interface towards RAN 1010 and routes data packets between RAN 1010 and EPC 1022. SGW 1026 may be a local mobility anchor for inter-RAN node handover and may also provide anchoring for inter-3 GPP mobility. Other responsibilities may include legal interception, billing, and some policy enforcement.

SGSN 1028 keeps track of the location of UE 1002 and performs security functions and access control. SGSN 1028 also performs EPC inter-node signaling for mobility between different RAT networks; MME 1024 specified PDN and S-GW selection; MME 1024 selection for handover; etc. The S3 reference point between MME 1024 and SGSN 1028 may enable user and bearer information exchange for inter-3 GPP network mobility in the idle/active state.

HSS1030 includes a database for network users including subscription related information to support the handling of communication sessions by network entities. HSS1030 may provide support for routing/roaming, authentication, authorization, naming/addressing resolution, location dependencies, and the like. The S6a reference point between HSS1030 and MME 1024 may enable the transfer of subscription and authentication data for authenticating/authorizing a user to access EPC 1020.

PGW 1032 may terminate an SGi interface towards a Data Network (DN) 1036 that may include an application (app)/content server 1038. PGW 1032 routes data packets between EPC 1022 and data network 1036. PGW 1032 is communicatively coupled to SGW 1026 via an S5 reference point to facilitate user plane tunneling and tunnel management. PGW 1032 may also include nodes (e.g., PCEFs) for policy enforcement and charging data collection. Further, the SGi reference point may communicatively couple PGW 1032 with the same or different data network 1036. PGW 1032 may be communicatively coupled with PCRF 1034 via a Gx reference point.

PCRF 1034 is a policy and charging control element of EPC 1022. PCRF 1034 may be communicatively coupled to app/content server 1038 to determine appropriate QoS and charging parameters for the service flows. PCRF 1032 assigns the associated rules to the PCEF with the appropriate TFTs and QCIs (via Gx reference points).

CN 1020 may be 5GC 1040,5GC 1040 including AUSF 1042, AMF 1044, SMF 1046, UPF 1048, NSSF 1050, NEF 1052, NRF 1054, PCF 1056, UDM 1058, and AF 1060, coupled to each other through various interfaces as shown. NF in 5gc 1040 is briefly described as follows.

The AUSF 1042 stores data for authentication of the UE 1002 and processes authentication related functions. AUSF 1042 may facilitate a common authentication framework for various access types.

The AMF 1044 allows other functions of the 5gc 1040 to communicate with the UE 1002 and RAN 1004 and subscribe to notifications about mobility events for the UE 1002. The AMF 1044 is also responsible for registration management (e.g., for registering the UE 1002), connection management, reachability management, mobility management, quorum interception of AMF related events, and access authentication and authorization. The AMF 1044 provides transport for SM messages between the UE 1002 and the SMF 1046, and acts as a transparent proxy for routing SM messages. AMF 1044 also provides for transmission of SMS messages between UE 1002 and SMSF. The AMF 1044 interacts with the AUSF 1042 and the UE 1002 to perform various security anchoring and context management functions. Furthermore, the AMF 1044 is an end point of the RAN-CP interface, which includes an N2 reference point between the RAN 1004 and the AMF 1044. The AMF 1044 is also the termination point for NAS (N1) signaling and performs NAS ciphering and integrity protection.

The AMF 1044 also supports NAS signaling with the UE 1002 over the N3IWF interface. The N3IWF provides access to untrusted entities. The N3IWF may be AN end point for the control plane for the N2 interface between the (R) AN 1004 and the AMF 1044, and may be AN end point for the user plane for the N3 reference point between the (R) AN 1014 and the UPF 1048. Thus, the AMF 1044 processes the N2 signaling from the SMF 1046 and AMF 1044 for PDU session and QoS, encapsulates/decapsulates the packets for IPSec and N3 tunnels, marks the N3 user plane packets in the uplink, and enforces QoS corresponding to the N3 packet mark taking into account the QoS requirements associated with such marks received over N2. The N3IWF may also relay UL and DL control plane NAS signaling between the UE 1002 and the AMF 1044 via the N1 reference point between the UE 1002 and the AMF 1044, and relay uplink and downlink user plane packets between the UE 1002 and the UPF 1048. The N3IWF also provides a mechanism for establishing an IPsec tunnel with the UE 1002. The AMFs 1044 may present an interface based on Namf services and may be termination points for an N14 reference point between two AMFs 1044 and an N17 reference point between the AMFs 1044 and a 5G-EIR (not shown in FIG. 10).

The SMF 1046 is responsible for SM (e.g., session establishment, tunnel management between UPF 1048 and AN 1008); UE IP address allocation and management (including optional authorization); selection and control of the UP function; configuring traffic steering at the UPF 1048 to route traffic to the correct destination; terminating the interface towards the policy control function; control policy enforcement, charging, and a portion of QoS; legal interception (for SM events and interfaces to LI systems); terminating the SM portion of the NAS message; downlink data notification; initiate AN specific SM information sent to AN 1008 through N2 via AMF 1044; and determining the SSC mode of the session. SM refers to the management of PDU sessions, and PDU session or "session" refers to a PDU connection service that provides or enables the exchange of PDUs between UE 1002 and DN 1036.

The UPF 1048 serves as an anchor point for intra-RAT and inter-RAT mobility, an external PDU session point for interconnection to the data network 1036, and a branching point to support multi-homing PDU sessions. The UPF 1048 also performs packet routing and forwarding, packet inspection, user plane part enforcing policy rules, legal intercept packets (UP collection), performing traffic usage reporting, performing QoS processing for the user plane (e.g., packet filtering, gating, UL/DL rate enforcement), performing uplink traffic validation (e.g., SDF to QoS flow mapping), transport level packet marking in the uplink and downlink, and performing downlink packet buffering and downlink data notification triggering. The UPF 1048 may include an uplink classifier to support routing traffic flows to the data network.

NSSF 1050 selects a set of network slice instances to serve UE 1002. NSSF 1050 also determines the allowed NSSAI and mapping (if needed) to subscribed S-NSSAI. NSSF 1050 also determines a set of AMFs or a list of candidate AMFs 1044 to be used to serve UE 1002 based on the appropriate configuration and possibly by querying NRF 1054. Selecting a set of network slice instances for the UE 1002 may be triggered by the AMF 1044 registered by the UE 1002 by interacting with the NSSF 1050; this may result in a change in AMF 1044. NSSF 1050 interacts with AMF 1044 via an N22 reference point; and may communicate with another NSSF in the visited network via an N31 reference point (not shown).

The NEF 1052 securely opens services and capabilities provided by the 3GPP NF for third parties, internal openness/reopening, AF 1060, edge computing or fog computing systems (e.g., edge computing nodes), and the like. In such embodiments, NEF 1052 may authenticate, authorize, or restrict AF. The NEF 1052 may also convert information exchanged with the AF 1060 and information exchanged with internal network functions. For example, the NEF 1052 may translate between AF service identifiers and internal 5GC information. The NEF 1052 may also receive information from other NFs based on their ability to open. This information may be stored as structured data at NEF 1052 or at data store NF using a standardized interface. The stored information may then be re-opened by the NEF 1052 to other NFs and AFs, or for other purposes (e.g., analysis).

NRF 1054 supports a service discovery function, receives NF discovery requests from NF instances, and provides information of the discovered NF instances to requesting NF instances. NRF 1054 also maintains information of available NF instances and services supported by them. The NRF 1054 also supports a service discovery function, in which the NRF 1054 receives an NF discovery request from an NF instance or an SCP (not shown) and provides information of the discovered NF instance to the NF instance or the SCP.

PCF 1056 provides policy rules to control plane functions to implement them and may also support a unified policy framework to manage network behavior. PCF 1056 may also implement a front end to access subscription information related to policy decisions in the UDR of UDM 1058. In addition to communicating with functions through reference points as shown, PCF 1056 also presents an interface based on the Npcf service.

The UDM 1058 processes subscription related information to support the handling of communication sessions by network entities and stores subscription data for the UE 1002. For example, subscription data may be communicated via an N8 reference point between the UDM 1058 and the AMF 1044. UDM 1058 may include two parts: application front-end and UDR. The UDR may store subscription data and policy data for UDM 1058 and PCF 1056, and/or structured data for the opening and application data of NEF 1052 (including PFD for application detection, application request information for multiple UEs 1002). The Nudr service-based interface may be exposed by UDR 221 to allow UDM 1058, PCF 1056, and NEF 1052 to access a particular set of stored data, as well as to read, update (e.g., add, modify), delete, and subscribe to notifications of changes to data in the UDR. The UDM may include a UDM-FE that is responsible for handling credentials, location management, subscription management, etc. Several different front ends may serve the same user in different transactions. The UDM-FE accesses subscription information stored in the UDR and performs authentication credential processing, user identification processing, access authorization, registration/mobility management, and subscription management. In addition to communicating with other NFs through reference points as shown, the UDM 1058 may also expose a Nudm service-based interface.

AF 1060 provides application impact on traffic routing, provides access to NEF 1052, and interacts with the policy framework for policy control. AF 1060 can affect UPF 1048 (re) selection and traffic routing. Based on the operator deployment, the network operator may allow the AF 1060 to interact directly with the associated NF when the AF 1060 is considered a trusted entity. In addition, AF 1060 may be used for edge computing implementations.

The 5gc 1040 may enable edge computation by selecting an operator/third party service to be geographically close to the point where the UE 1002 attaches to the network. This may reduce latency and load on the network. In an edge computing implementation, the 5gc 1040 may select a UPF 1048 near the UE 1002 and perform traffic steering from the UPF 1048 to the DN 1036 via the N6 interface. This may be based on the UE subscription data, the UE location and information provided by AF 1060, which allows AF 1460 to affect UPF (re) selection and traffic routing.

Data Network (DN) 1036 can represent various network operator services, internet access, or third party services that can be provided by one or more servers including, for example, an application (app)/content server 1038. DN 1036 may be an operator external public, private PDN or an operator internal packet data network, for example for provisioning IMS services. In this embodiment, app server 1038 may be coupled to the IMS via an S-CSCF or an I-CSCF. In some implementations, DN 1036 may represent one or more Local Area DNs (LADNs), which are DNs 1036 (or DN names (DNNs)) accessible to UE 1002 in one or more particular areas. Outside these particular areas, the UE 1002 cannot access the LADN/DN 1036.

Additionally or alternatively, DN 1036 can be an edge DN 1036, which is a (local) data network supporting an architecture for implementing edge applications. In these embodiments, app server 1038 may represent a physical hardware system/device that provides app server functionality and/or application software residing in the cloud or at an edge computing node that performs server functionality. In some embodiments, app/content server 1038 provides an edge hosting environment that provides the support required for the execution of edge application servers.

In some embodiments, the 5GS may use one or more edge computing nodes to provide interfacing and offloading processing of wireless communication traffic. In these embodiments, the edge computing nodes may be included in, or co-sited with, one or more RANs 1010, 1014. For example, the edge computing node may provide a connection between the RAN 1014 and the UPF 1048 in the 5gc 1040. The edge computing node may use one or more NFV instances instantiated on the virtualization infrastructure within the edge computing node to handle wireless connections to and from the RAN 1014 and UPF 1048.

The interfaces of the 5gc 1040 include reference points and service-based interfaces. The reference points include: n1 (between UE 1002 and AMF 1044), N2 (between RAN 1014 and AMF 1044), N3 (between RAN 1014 and UPF 1048), N4 (between SMF 1046 and UPF 1048), N5 (between PCF 1056 and AF 1060), N6 (between UPF 1048 and DN 1036), N7 (between SMF 1046 and PCF 1056), N8 (between UDM 1058 and AMF 1044), N9 (between two UPF 1048), N10 (between UDM 1058 and SMF 1046), N11 (between AMF 1044 and SMF 1046), N12 (between AUSF 1042 and AMF 1044), N13 (between AUSF 1042 and UDM 1048), N14 (between two AMFs 1044; not shown), N15 (between PCF 1056 and AMF 1044 in case of a non-roaming scenario, or between AMF 1046 and AMF 1044 in a visited network in case of a non-roaming scenario), N11 (between AMF 1044; N16 and nsf 1044) and N22 (between AMF 1044). Other reference point representations not shown in fig. 10 may also be used. The service-based representation of fig. 10 represents NFs within the control plane that enable other authorized NFs to access their services. The service-based interface (SBI) includes: namf (SBI shown by AMF 1044), nsmf (SBI shown by SMF 1046), nnef (SBI shown by NEF 1052), npcf (SBI shown by PCF 1056), nudm (SBI shown by UDM 1058), naf (SBI shown by AF 1060), nnrf (SBI shown by NRF 1054), nnssf (SBI shown by NSSF 1050), nausf (SBI shown by AUSF 1042). Other service-based interfaces not shown in fig. 10 (e.g., nudr, N5g-eir, and Nudsf) may also be used. In some embodiments, NEF 1052 may provide an interface to edge computing node 1036x, which may be used to handle wireless connections with RAN 1014.

In some implementations, the system 1000 may include an SMSF that is responsible for SMS subscription checking and authentication, and relaying SM messages from other entities (e.g., SMS-GMSC/IWMSC/SMS-router) to/from the UE 1002. SMS may also interact with AMF 1042 and UDM 1058 for notification procedures that UE 1002 is available for SMS transmission (e.g., setting a UE unreachable flag, and notifying UDM 1058 when UE 1002 is available for SMS).

The 5GS may also include an SCP (or a single instance of an SCP) that supports indirect communications (see e.g., 3gpp ts23.501 section 7.1.1); delegated discovery (see e.g., 3gpp ts23.501 section 7.1.1); message forwarding and routing to destination NF/NF services, communication security (e.g., authorization of NF service consumer to access NF service producer APIs) (see e.g., 3gpp TS 33.501), load balancing, monitoring, overload control, etc.; and a discovery and selection function for UDM, AUSF, UDR, PCF, wherein subscription data stored in the UDR is accessed based on the SUPI, sui or GPSI of the UE (see e.g. 3gpp ts23.501 section 6.3). The load balancing, monitoring, overload control functions provided by the SCP may be implementation specific. The SCP may be deployed in a distributed manner. There may be more than one SCP in the communication path between the various NF services. SCPs, while not NF instances, may also be deployed in a distributed, redundant, and scalable manner.

Fig. 11 schematically illustrates a wireless network 1100 in accordance with various embodiments. The wireless network 1100 may include a UE 1102 in wireless communication with AN 1104. The UE 1102 and AN 1104 may be similar to, and substantially interchangeable with, the similarly named components described with respect to fig. 10.

UE 1102 may be communicatively coupled with AN 1104 via a connection 1106. Connection 1106 is shown as implementing a communicatively coupled air interface and may conform to a cellular communication protocol, such as the LTE protocol or the 5G NR protocol operating at mmWave or sub-6GHz frequencies.

The UE 1102 may include a host platform 1108 coupled with a modem platform 1110. Host platform 1108 may include application processing circuitry 1112, which may be coupled with protocol processing circuitry 1114 of modem platform 1110. Application processing circuitry 1112 may run various applications for outgoing/incoming application data for UE 1102. Application processing circuitry 1112 may also implement one or more layer operations to send and receive application data to and from a data network. These layer operations may include transport (e.g., UDP) and internet (e.g., IP) operations.

Protocol processing circuitry 1114 may implement one or more layers of operations to facilitate sending or receiving data over connection 1106. Layer operations implemented by the protocol processing circuit 1114 may include, for example, MAC, RLC, PDCP, RRC and NAS operations.

Modem platform 1110 may also include digital baseband circuitry 1116, which may implement one or more layer operations, which are "lower" layer operations in the network protocol stack performed by protocol processing circuitry 1114. These operations may include, for example, PHY operations, including one or more of the following: HARQ Acknowledgement (ACK) functions, scrambling/descrambling, encoding/decoding, layer mapping/demapping, modulation symbol mapping, received symbol/bit metric determination, multi-antenna port precoding/decoding (which may include one or more of space-time, space-frequency, or space coding), reference signal generation/detection, preamble sequence generation and/or decoding, synchronization sequence generation/detection, control channel signal blind decoding, and other related functions.

The modem platform 1110 may also include transmit circuitry 1118, receive circuitry 1120, RF circuitry 1122, and an RF front end (RFFE) 1124, which may include or be connected to one or more antenna panels 1126. Briefly, the transmit circuit 1118 may include digital-to-analog converters, mixers, intermediate Frequency (IF) components, and the like; the receive circuitry 1120 may include analog-to-digital converters, mixers, IF components, etc.; the RF circuitry 1122 may include low noise amplifiers, power tracking components, and the like; RFFE 1124 may include filters (e.g., surface/bulk acoustic wave filters), switches, antenna tuners, beam forming components (e.g., phased array antenna components), and so forth. The selection and arrangement of the components of the transmit circuit 1118, receive circuit 1120, RF circuit 1122, RFFE 1124, and antenna panel 1126 (commonly referred to as "transmit/receive components") may be specific to the specifics of the particular implementation, such as whether the communication is TDM or FDM, at mmWave or sub-6GHz frequencies, and so forth. In some embodiments, the transmit/receive components may be arranged in multiple parallel transmit/receive chains, may be provided in the same or different chips/modules, etc.

In some embodiments, the protocol processing circuit 1114 may include one or more instances of control circuitry (not shown) for providing control functions for the transmit/receive components.

UE 1102 reception may be established by and through antenna panel 1126, RFFE 1124, RF circuitry 1122, receive circuitry 1120, digital baseband circuitry 1116, and protocol processing circuitry 1114. In some embodiments, the antenna panel 1126 may receive transmissions from the AN 1104 through receive beamforming signals received by multiple antennas/antenna elements of one or more antenna panels 1126.

UE 1102 transmission may be established by and through protocol processing circuitry 1114, digital baseband circuitry 1116, transmit circuitry 1118, RF circuitry 1122, RFFE 1124, and antenna panel 1126. In some embodiments, the transmit component of UE 1104 may apply spatial filtering to the data to be transmitted to form transmit beams that are transmitted by the antenna elements of antenna panel 1126.

Similar to UE 1102, an 1104 may include a host platform 1128 coupled with a modem platform 1130. Host platform 1128 may include application processing circuitry 1132 coupled with protocol processing circuitry 1134 of modem platform 1130. The modem platform may also include digital baseband circuitry 1136, transmit circuitry 1138, receive circuitry 1140, RF circuitry 1142, RFFE circuitry 1144, and antenna panel 1146. The components of AN 1104 may be similar to, and substantially interchangeable with, similarly named components of UE 1102. In addition to performing data transmission/reception as described above, components of AN 1108 may perform various logic functions including, for example, RNC functions such as radio bearer management, uplink and downlink dynamic radio resource management, and data packet scheduling.

Fig. 12 is a diagram illustrating components of a computing device 1200 capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any one or more of the methods discussed herein, according to some example embodiments. In particular, fig. 12 shows a graphical representation of a hardware resource 1200, the hardware resource 1200 comprising one or more processors (or processor cores) 1210, one or more memory/storage devices 1220, and one or more communication resources 1230, each of which may be communicatively coupled via a bus 1240 or other interface circuitry. For embodiments that utilize node virtualization (e.g., NFV), the hypervisor 1202 can be executed to provide an execution environment for one or more network slices/sub-slices to utilize the hardware resources 1200.

Processor 1210 includes, for example, a processor 1212 and a processor 1214. Processor 1210 includes circuitry such as, but not limited to, the following: one or more of a processor core or cache memory, a low dropout regulator (LDO), an interrupt controller, a serial interface (e.g., SPI, I2C, or universal programmable serial interface circuit), a Real Time Clock (RTC), a timer counter (including an interval timer and a watchdog timer), a universal I/O, a memory card controller (e.g., secure digital/multimedia card (SD/MMC) or the like), a Mobile Industrial Processor Interface (MIPI) interface, and a Joint Test Access Group (JTAG) test access port. Processor 1210 may be, for example, a Central Processing Unit (CPU), a Reduced Instruction Set Computing (RISC) processor, an Acorn RISC Machine (ARM) processor, a Complex Instruction Set Computing (CISC) processor, a Graphics Processing Unit (GPU), one or more Digital Signal Processors (DSPs) (e.g., baseband processors), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), a Radio Frequency Integrated Circuit (RFIC), one or more microprocessors or controllers, another processor (including those discussed herein), or any suitable combination thereof. In some implementations, the processor circuit 1210 may include one or more hardware accelerators, which may be microprocessors, programmable processing devices (e.g., FPGAs, complex Programmable Logic Devices (CPLDs), etc.), or the like.

Memory/storage 1220 may include main memory, disk storage, or any suitable combination thereof. Memory/storage 1220 may include, but is not limited to, any type of volatile, nonvolatile or semi-volatile memory, such as Random Access Memory (RAM), dynamic RAM (DRAM), static RAM (SRAM), synchronous DRAM (SDRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, solid state memory, phase change RAM (PRAM), resistiveMemory (e.g., magnetoresistive Random Access Memory (MRAM)), etc., and may be combined fromAndthree-dimensional (3D) cross-point (XPOINT) memory. Memory/storage 1220 may also include a persistent storage device, which may be any type of temporary and/or permanent storage, including, but not limited to, non-volatile memory, optical storage, magnetic storage, and/or solid-state mass storage, among others.

The communication resources 1230 may include interconnection or network interface controllers, components, or other suitable devices to communicate with one or more peripheral devices 1204 or one or more databases 1206 or other network elements via the network 1208. The communication resources 1230 may include, for example, wired communication components (e.g., for coupling via USB, ethernet over GRE tunnel, ethernet over multiprotocol Label switching (MPLS), ethernet over USB, controller Area Network (CAN), local Interconnect Network (LIN), deviceNet, controlNet, data Highway+, PROFIBUS, PROFINET, etc.), cellular communication component, NFC component, data Highway+, PROFIBUS, PROFINET, etc, (or low power consumption->) Assembly, & gtof>Components and other communication components. A network connection may be provided to/from computing device 1200 via communication resources 1230 using physical connections (which may be electrical (e.g., a "copper interconnect") or optical). Physical connections also include suitable input connectors (e.g., ports, sockets, jacks, etc.) and output connectors (e.g., plugs, pins, etc.). The communication resources 1230 may include one or more special purpose processors and/or FPGAs to use one or moreA plurality of the above-described network interface protocols communicate.

The instructions 1250 may include software, programs, applications, applets, apps, or other executable code for causing at least any processor 1210 to perform any one or more of the methods discussed herein. The instructions 1250 may reside, completely or partially, within at least one of the processor 1210 (e.g., within a cache memory of the processor), the memory/storage device 1220, or any suitable combination thereof. Further, any portion of instructions 1250 may be transferred from any combination of peripherals 1204 or databases 1206 to hardware resource 1200. Thus, the memory of processor 1210, memory/storage 1220, peripherals 1204, and database 1206 are examples of computer readable and machine readable media.

Additional examples of the presently described embodiments include the following non-limiting implementations. Each of the following non-limiting examples may exist independently or may be combined with any one or more of the other examples provided below or throughout the present disclosure, in any permutation or combination.

Example 1 includes: an in-network DNS function as part of an in-network computing service function, wherein the DHCP server may notify the device of a CSF address as a DNS server address; the ISP's DHCP server may also inform the device of CSF server configuration (whether the ISP supports CSF, CSF IP address); if a CSF address is used as a DNS server address, then the domain name resolution request will go directly to the configured CSF; and/or if a conventional DNS server is used, a CSF-capable network switch may filter out DNS requests and examine its locally cached domain name records to resolve domain names.

Example 2 includes: a service registry function for registering services and service instances includes in-network services and services provided by external providers outside the network.

Example 3 includes: the service registry function of example 2 and/or some other examples herein, wherein implementing service registration comprises a subscription-based method, wherein the service registry subscribes to service events. If there is a new event in the service (e.g., a new service instance is instantiated, a service update, etc.), the service registry will be notified.

Example 4 includes: the service registry function of examples 2-3 and/or some other examples herein, wherein implementing service registration comprises a query-based method, wherein the service registry periodically sends a query message to each service. Each service responds to the query with an updated service status.

Example 5 includes: the service registry function of examples 2-4 and/or some other examples herein, wherein implementing service registration comprises a notification-based method wherein each service will send a notification message to the service registry when there is a state change.

Example 6 includes: an in-network service grid function as part of an in-network computing service function, wherein the in-network service grid function includes service orchestration functions (e.g., service discovery, load balancing, service instance assignment, service access control in the network); the in-network service grid function has an interface with the service registry function, network controller or DHCP server, device, and there is also an interface between the in-network service grid function instances (as shown in fig. 1).

Example 7 includes: a method of operating an in-network service grid function (including the in-network service grid function of example 6 and/or some other examples herein) as part of an in-network computing service function, the method comprising: the device is associated with one of the in-network service grid function instances; the device sends a service request to the associated in-network service grid function; the in-network service grid function queries the service from the service registry; the in-network service grid function selects a service instance for the device. The selection decision may be based on factors such as the location of the device, the location of the service instance, the load of the service instance, the estimated service response time, etc.; and the in-network service grid function responds to the service request of the device. The response message may include the assigned service instance address, the assigned computing resources, the service execution results, and the like.

Example 8 includes: the method of example 7 and/or some other examples herein, wherein the network controller/DHCP server manages the association for the step of associating the device with one of the intra-network service grid function instances. In this option, the network controller or DHCP server will assign CSF to the device when the device first attaches to the network. The network controller or DHCP server configures the device with a CSF address.

Example 9 includes: the method of examples 7-8 and/or some other examples herein, wherein for the step of associating the device with one of the intra-network service grid function instances, the device autonomously associates, wherein when the device first attaches to the network, the device will broadcast its CSF association request message; CSF receiving the association request message will respond to the device; the response message may include information about CSF address, service capability, etc., and if more than one CSF responds to the device, the device may select one CSF to associate (by sending an association request to that CSF, and the CSF responds with a grant message).

Example 10 includes: an intra-network service orchestration function-network (SOF-N) and a service orchestration function-client (SOF-C) among the intra-network computing service functions, wherein the SOF-N and the SOF-C are used to dynamically direct service execution between the device and the network.

Example 11 includes: a method of operating a SOF-N (including a SOF-N as described in example 10 and/or some other examples herein), the method comprising: the client application interacts with a service orchestration function-client (SOF-C) to request a service; SOF-C interacts with a client OS and a service orchestration function-network (SOF-N) to obtain information (both locally and in the network) about service availability; and the SOF-C may then dynamically direct the service requests of the application between the native execution and the network execution.

Example 12 includes: the method of example 11 and/or some other examples herein, further comprising: if execution is done locally, SOF-C will send a service request to the native OS, e.g., via a system call.

Example 13 includes: the method of examples 11-12 and/or some other examples herein, further comprising: if execution is done in the network, SOF-C will send a service request to CSF, e.g., via a remote procedure call.

Example 14 includes: the method of examples 10-13 and/or some other examples herein, wherein the decision as to where to perform the requested service may be made by SOF-C or SOF-N.

Example 15 includes: the method of example 14 and/or some other examples herein, wherein, when the SOF-C is making a decision, the SOF-C is to collect information from the local OS and the SOF-N regarding service availability, network conditions, device battery level, estimated service execution time, etc.

Example 16 includes: the method of examples 14-15 and/or some other examples herein, wherein, when the SOF-N is making a decision, the SOF-N is to collect information about service availability, network conditions, device battery level, network computing load, estimated service execution time, etc. from the SOF-C, network service registry, and network computing resource platform.

Example 17 includes: an in-network resource orchestration function-network (SOF-N) and a resource orchestration function-client (SOF-C) in an in-network computing service function, wherein the client side and the network side resource orchestration function are used to orchestrate computing resources in devices and networks.

Example 18 includes: a method of operating a SOF-N (including a SOF-N as described in example 17 and/or some other examples herein), the method comprising: a resource orchestration function-client (ROF-C) interacts with a resource orchestration function-network (ROF-N) to obtain a list of network computing resources and capabilities that the client can use; ROF-C opens a list of computing resources and capabilities to OS; when the OS requests computing resources, the ROF-C sends a resource request to the ROF-N; ROF-N decides whether to accept the request of ROF-C and responds to the request of ROF-C; and if the resource request is accepted, the ROF-C and ROF-N will establish a data path between the device and the network for accessing the computing resource. The OS may then use the computing resources via the data path.

Example 19 includes: the method of example 18 and/or some other examples herein, wherein the ROF-C interacting with the ROF-N to obtain a list of network computing resources and capabilities that the client is capable of using comprises: ROF-N broadcasts a list of network computing resources and capabilities as system information.

Example 20 includes: the method of examples 18-19 and/or some other examples herein, wherein the ROF-C interacting with the ROF-N to obtain a list of network computing resources and capabilities that the client is capable of using comprises: the ROF-C sends a query message to the ROF-N to query network computing resources and capabilities. ROF-N responds to the query of ROF-C.

Example 21 includes: a method for operating an in-network service grid function as part of an in-network computing service function, wherein the in-network service grid function contains service orchestration functions including service discovery, load balancing, service instance assignment, service access control in a network, the in-network service grid function having interfaces with service registry functions, network controllers or DHCP servers and devices, and also interfaces between various in-network service grid function instances, wherein the method comprises: identifying, by an in-network service grid function (INSEF) instance, an association with a device; receiving, by the INSF instance, a service request from a device; querying, by the INMF instance, a service registry for service information based on the service request; selecting, by the INSEF instance, a service instance for the device based on the service information; and providing, by the INSEF instance, a service response including the selected service instance and/or related information.

Example 22 includes: the method of example 21 and/or some other examples herein, wherein selecting is based on one or more factors including: the location of the device, the location of the INSFinstance, the load of the INSFinstance, the estimated service response time, and/or some other parameter or criterion.

Example 23 includes: the method of examples 21-22 and/or some other examples herein, wherein the service response includes an assigned service instance address, an assigned computing resource, a service execution result, and/or other information related to the selected service instance.

Example 24 includes: a method for operating an intra-network service orchestration function-network (SOF-N) and a service orchestration function-client (SOF-C) in an intra-network computing service function, wherein the SOF-N and the SOF-C are used to dynamically direct service execution between a client device and the network function, the method comprising: identifying, by the SOF-C, a service request from a client application (app) of a client device; interacting by the SOF-C with the client OS and SOF-N of the client device to obtain information about service availability (e.g., locally at the client and/or in the network); and dynamically directing, by the SOF-C, the service request between the local execution and the network execution.

Example 25 includes: the method of example 24 and/or some other examples herein, wherein when the execution is done locally, the method further comprises: the service request is sent by the SOF-C to the native OS via a system call.

Example 26 includes: the method of example 24 and/or some other examples herein, wherein when the performing is done in a network, the method further comprises: a service request is sent by SOF-C to a Computational Service Function (CSF) via an API call or a remote procedure call.

Example 27 includes: a method for operating an intra-network resource orchestration function-network (ROF-N) and a resource orchestration function-client (ROF-C) in an intra-network computing service function, wherein the ROF-C and ROF-N are used to orchestrate computing resources in client devices and the network, the method comprising: requesting, by the ROF-C from the ROF-N, a list of network computing resources and capabilities that the client device is capable of using; opening, by the ROF-C, a list of network computing resources and capabilities to a client OS implemented by the client device; transmitting, by the ROF-C, a resource request to the ROF-N in response to the OS requesting computing resources from the list; receiving, by the ROF-C from the ROF-N, a response to the resource request indicating whether the resource request is accepted; and when the resource request is accepted, establishing a data path between the client device and the network by the ROF-C and the ROF-N for accessing the computing resource.

Example 28 includes: the method of example 27 and/or some other examples herein, wherein the ROF-N broadcasts the list of network computing resources and capabilities as system information in suitable system information comprising the message.

Example 29 includes: the method of example 27 and/or some other examples herein, further comprising: a query message is sent by the ROF-C to the ROF-N to query the network for computing resources and capabilities.

Example 30 includes: the method of example 29 and/or some other examples herein, further comprising: a response including network computing resources and capabilities is received by the ROF-C from the ROF-N.

Example 31 includes: the method of examples 27-30 and/or some other examples herein, wherein the OS may use the computing resources via a data path.

Example 32 may include: a method implemented by an in-network service grid function of a Computing Service Function (CSF), the method comprising: identifying, by the in-network service grid function, a device associated with the in-network service grid function; identifying, by the in-network service grid function, a service request received from the device; identifying, by the in-network service grid function, a service instance for the device in a service registry of the CSF based on the service request; and sending, by the in-network service grid function, an indication of the service instance.

Example 33 may include: the method of example 32 or some other example herein, wherein the identification of the service instance is based on sending, by the in-network service grid function, a query related to the service request to the service registry.

Example 34 may include: the method of example 32 or some other example herein, wherein the intra-network service grid function is one of a plurality of intra-network service grid functions of the CSF.

Example 35 may include: the method of example 34 or some other example herein, wherein respective ones of the plurality of intra-network service grid functions are associated with different ones of the plurality of devices.

Example 36 may include: the method of example 32 or some other example herein, wherein the in-network service grid function is to: identifying a service instance for the device based on at least one of: the location of the device, the location of the service instance, the load of the service instance, and the estimated service response time.

Example 37 may include: the method of example 32 or some other example herein, wherein the indication of the service instance includes at least one of: the assigned service instance address, the assigned computing resources, and the service execution results.

Example 38 may include: the method of example 32 or some other example herein, wherein the device is associated with an intra-network service grid function by one or more of: the association managed by the network controller, the association managed by a Dynamic Host Configuration Protocol (DHCP) server, and the association of the device autonomy.

Example 39 may include: one or more non-transitory computer-readable media comprising instructions that, when executed by one or more processors of a device, cause a service orchestration function of the device-client (SOF-C): identifying a service request from a client application of the device; identifying information related to availability of a service related to a service request based on interactions with one or more of an Operating System (OS) of the device and a service orchestration function-network (SOF-N) of a Computing Service Function (CSF) to which the device is communicatively coupled; and directing the service request for local execution or network execution based on the information related to the availability of the service.

Example 40 may include: the one or more non-transitory computer-readable media of example 39 or some other example herein, wherein the locally executing is related to executing a service by the device.

Example 41 may include: the one or more non-transitory computer-readable media of example 39 or some other example herein, wherein the network execution is related to an electronic device executing a service communicatively coupled to by the device.

Example 42 may include: the one or more non-transitory computer-readable media of example 39 or some other example herein, wherein the directing is based on a determination by the SOF-N based on information related to availability of the service.

Example 43 may include: the one or more non-transitory computer-readable media of example 42 or some other example herein, wherein the information is related to a web service registry.

Example 44 may include: the one or more non-transitory computer-readable media of example 39 or some other example herein, wherein the directing is based on a determination by the SOF-C based on information related to availability of the service.

Example 45 may include: the one or more non-transitory computer-readable media of example 39 or some other example herein, wherein the information comprises information related to one or more of: service availability, network conditions, device battery level, and estimated service execution time.

Examples 46 may include: an apparatus, comprising: one or more processors; one or more non-transitory computer-readable media comprising instructions that, when executed by one or more processors, cause a resource orchestration function-client (ROF-C): identifying a plurality of resources of a network that are usable by a device based on communication with a resource orchestration function-network (ROF-N) of the network; providing an indication of the plurality of resources to an Operating System (OS) of the device; identifying a request from the OS to access a resource of the plurality of resources; sending an indication of the request to the ROF-N; and based on the response to the request received from the ROF-N, identifying whether a data path is established between the device and the network such that the OS can access the resource.

Example 47 may include: the apparatus of example 46 or some other example herein, wherein ROF-C is to: based on the list broadcast by the ROF-N, a plurality of resources are identified.

Example 48 may include: the apparatus of example 46 or some other example herein, wherein ROF-C is to: based on a response by the ROF-N to a query sent by the ROF-C to the ROF-N, a plurality of resources are identified.

Example 49 may include: the apparatus of example 46 or some other example herein, wherein the resource is a computing resource or capability of an element of the network.

Example 50 may include: the apparatus of example 46 or some other example herein, wherein ROF-C is to: if the response to the request indicates an ROF-N acceptance, a data path is established.

Example 51 may include: the apparatus of example 46 or some other example herein, wherein ROF-C is to: if the response to the request indicates a ROF-N rejection, no data path is established.

Example 52 may include: an apparatus comprising means for performing one or more elements of the methods described in or relating to any one of examples 1-51, or any other method or process described herein.

Example 53 may include: one or more non-transitory computer-readable media comprising instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform one or more elements of the methods described in or related to any one of examples 1-51, or any other method or process described herein.

Example 54 may include: an apparatus comprising logic, modules, or circuitry to perform one or more elements of the methods described in or related to any one of examples 1-51, or any other method or process described herein.

Example 55 may include: a method, technique, or process as described in or relating to any one of examples 1-51 or a portion or section thereof.

Examples 56 may include: an apparatus, comprising: one or more processors and one or more computer-readable media comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform the method, technique, or process described in or related to any one of examples 1-51, or a portion or section thereof.

Example 57 may include: a signal as described in or related to any one of examples 1-51 or a portion or section thereof.

Example 58 may include: a datagram, packet, frame, segment, protocol Data Unit (PDU), or message as described in or relating to any one of examples 1-51 or a portion or section thereof or otherwise described in this disclosure.

Example 59 may include: a signal encoded with data as described in or relating to any one of examples 1-51 or a portion or section thereof or otherwise described in this disclosure.

Example 60 may include: a signal encoded with a datagram, packet, frame, segment, protocol Data Unit (PDU), or message as described in or relating to any one of examples 1-51 or a portion or section thereof or otherwise described in this disclosure.

Example 61 may include: an electromagnetic signal carrying computer-readable instructions, wherein execution of the computer-readable instructions by one or more processors causes the one or more processors to perform the method, technique, or process described in or related to any one of examples 1-51 or portions thereof.

Example 62 may include: a computer program comprising instructions, wherein execution of the program by a processing element causes the processing element to perform a method, technique or process described in or related to any one of examples 1-51 or portions thereof.

Example 63 may include: a signal in a wireless network as shown and described herein.

Example 64 may include: a method of communicating in a wireless network as shown and described herein.

Example 65 may include: a system for providing wireless communications as shown and described herein.

Examples 66 may include: an apparatus for providing wireless communication as shown and described herein.

Any of the above examples may be combined with any other example (or combination of examples) unless explicitly stated otherwise. The foregoing description of one or more implementations provides illustration and description, but is not intended to be exhaustive or to limit the scope of the embodiments to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of various embodiments.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

For the purposes of this disclosure, the phrase "a and/or B" means (a), (B), or (a and B). For the purposes of this disclosure, the phrase "A, B and/or C" means (a), (B), (C), (a and B), (a and C), (B and C), or (A, B and C). The description may use the phrase "in an embodiment" or "in some embodiments," which may each refer to one or more of the same or different embodiments. In addition, the terms "including", "comprising", "having" and the like are synonymous as used with respect to the embodiments of the present disclosure.

The terms "coupled," "communicatively coupled," and their derivatives are used herein. The term "coupled" may mean that two or more elements are in direct physical or electrical contact with each other, may mean that two or more elements are in indirect contact with each other but still cooperate or interact with each other, and/or may mean that one or more other elements are coupled or connected between elements referred to as being coupled to each other. The term "directly coupled" may mean that two or more elements are in direct contact with each other. The term "communicatively coupled" may mean that two or more elements may be in contact with each other through communication (including through wired or other interconnection connections, through wireless communication channels or links, etc.).

The term "circuitry" as used herein refers to, or is part of, or includes hardware components configured to provide the described functionality: for example, electronic circuitry, logic circuitry, a processor (shared, dedicated, or group) and/or memory (shared, dedicated, or group), an Application Specific Integrated Circuit (ASIC), a Field Programmable Device (FPD) (e.g., a Field Programmable Gate Array (FPGA), a Programmable Logic Device (PLD), a Complex PLD (CPLD), a high-capacity PLD (HCPLD), a structured ASIC, or a programmable SoC), a Digital Signal Processor (DSP), or the like. In some embodiments, the circuitry may execute one or more software or firmware programs to provide at least some of the described functionality. The term "circuitry" may also refer to a combination of one or more hardware elements and program code (or a combination of circuitry and program code for use in an electrical or electronic system), one or more hardware elements being arranged to perform the functions of the program code. In these embodiments, a combination of hardware elements and program code may be referred to as a particular type of circuit.

The term "processor circuit" as used herein refers to, is part of, or includes circuitry capable of sequentially and automatically performing a series of arithmetic or logical operations or recording, storing, and/or transmitting digital data. The processing circuitry may include one or more processing cores for executing instructions and one or more memory structures for storing program and data information. The term "processor circuitry" may refer to one or more application processors, one or more baseband processors, a physical Central Processing Unit (CPU), a single core processor, a dual core processor, a tri-core processor, a quad-core processor, and/or any other device capable of executing or otherwise operating computer-executable instructions (e.g., program code, software modules, and/or functional processes). The processing circuitry may include further hardware accelerators, which may be microprocessors, programmable processing devices, or the like. The one or more hardware accelerators may include, for example, computer Vision (CV) and/or Deep Learning (DL) accelerators. The terms "application circuitry" and/or "baseband circuitry" may be considered synonymous with and may be referred to as "processor circuitry".

The terms "memory" and/or "memory circuitry" as used herein refer to one or more hardware devices for storing data, including RAM, MRAM, PRAM, DRAM and/or SDRAM, kernel memory, ROM, magnetic disk storage media, optical storage media, flash memory devices, or other machine readable media for storing data. The term "computer-readable medium" can include, but is not limited to, memory, portable or fixed storage devices, optical storage devices and various other mediums capable of storing, containing or carrying instruction(s) or data.

The term "interface circuit" as used herein refers to, is part of, or includes circuitry that enables the exchange of information between two or more components or devices. The term "interface circuitry" may refer to one or more hardware interfaces (e.g., a bus, an I/O interface, a peripheral component interface, a network interface card, etc.).

The term "user equipment" or "UE" as used herein refers to a device having radio communication capabilities and may describe a remote user of network resources in a communication network. The term "user equipment" or "UE" may be considered synonymous to and may be referred to as a client, mobile station, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, radio, reconfigurable mobile, etc. Furthermore, the term "user equipment" or "UE" may include any type of wireless/wired device or any computing device that includes a wireless communication interface.

The term "network element" as used herein refers to a physical or virtualized device and/or infrastructure to provide wired or wireless communication network services. The term "network element" may be considered synonymous to and/or refer to a networked computer, networking hardware, network device, network node, router, switch, hub, bridge, radio network controller, RAN device, RAN node, gateway, server, virtualized VNF, NFVI, etc.

The term "computer system" as used herein refers to any type of interconnected electronic device, computer device, or component thereof. Furthermore, the terms "computer system" and/or "system" may refer to various components of a computer that are communicatively coupled to each other. Furthermore, the terms "computer system" and/or "system" may refer to a plurality of computer devices and/or a plurality of computing systems communicatively coupled to each other and configured to share computing resources and/or networking resources.

The terms "appliance," "computer appliance," and the like as used herein refer to a computer device or computer system having program code (e.g., software or firmware) specifically designed to provide a particular computing resource. A "virtual appliance" is a virtual machine image to be implemented by a hypervisor-equipped device that virtualizes or emulates a computer appliance or is otherwise dedicated to providing specific computing resources. The term "element" refers to a unit that is indivisible at a given level of abstraction and has well-defined boundaries, wherein the element may be any type of entity including, for example, one or more devices, systems, controllers, network elements, modules, etc., or a combination thereof. The term "device" refers to a physical entity embedded within or attached to another physical entity in its vicinity, having the ability to transfer digital information from or to that physical entity. The term "entity" refers to different components of an architecture or device or information transmitted as a payload. The term "controller" refers to an element or entity that has the ability to affect a physical entity, for example, by changing its state or moving the physical entity.

The term "cloud computing" or "cloud" refers to a paradigm for enabling network access to a pool of scalable and resilient shareable computing resources with on-demand self-service provisioning and administration and without active management by users. Cloud computing provides cloud computing services (or cloud services), which are one or more capabilities that are invoked via an interface (e.g., API, etc.) of a usage definition provided by the cloud computing. The term "computing resource" or simply "resource" refers to any physical or virtual component or use of such components within a computer system or network of limited availability. Examples of computing resources include use/access to servers, processors, storage devices, memory areas, networks, power, input/output (peripheral) devices, mechanical devices, network connections (e.g., channels/links, ports, network sockets, etc.), operating systems, virtual Machines (VMs), software/applications, computer files, etc., for a period of time. "hardware resources" may refer to computing, storage, and/or network resources provided by physical hardware elements. "virtualized resources" may refer to computing, storage, and/or network resources provided by the virtualization infrastructure to applications, devices, systems, etc. The term "network resource" or "communication resource" may refer to a resource that is accessible to a computer device/system via a communication network. The term "system resource" may refer to any kind of shared entity for providing a service and may include computing resources and/or network resources. System resources may be viewed as a set of contiguous functions, network data objects, or services that are accessible through a server, where the system resources reside on a single host or multiple hosts and are clearly identifiable. As used herein, the term "cloud service provider" (or CSP) indicates an organization that typically operates large-scale "cloud" resources (e.g., used in the context of public clouds) consisting of centralized, regional, and edge data centers. In other examples, CSP may also be referred to as a Cloud Service Operator (CSO). References to "cloud computing" generally refer to computing resources and services provided by CSP or CSO at remote locations with at least some added latency, distance, or constraint relative to edge computing.

As used herein, the term "data center" refers to a specially designed structure intended to accommodate multiple high performance computing and data storage nodes such that there are a large number of computing, data storage and network resources at a single location. This often requires a dedicated rack and enclosure system, suitable heating, cooling, ventilation, safety, fire suppression and power delivery systems. In some contexts, the term may also refer to compute and data storage nodes. The data centers may vary in size between a centralized or cloud data center (e.g., max), an area data center, and an edge data center (e.g., min).

As used herein, the term "edge computation" refers to the implementation, coordination, and use of computing resources at locations closer to the "edge" or "set of edges" of the network. Deploying computing resources at the edge of the network can reduce application and network latency, reduce network backhaul traffic and associated energy consumption, promote service capabilities, promote compliance with security or data privacy requirements (especially compared to traditional cloud computing), and improve total ownership costs. As used herein, the term "edge computing node" refers to a real-world, logical, or virtualized implementation of computing capable elements in the form of devices, gateways, bridges, systems or subsystems, components, whether operating in server, client, endpoint, or peer-to-peer mode, and whether located at the "edge" of a network or at a more distant connection location within a network. References to "nodes" as used herein are generally interchangeable with "devices," "components," and "subsystems"; however, references to an "edge computing system" or "edge computing network" generally refer to a distributed architecture, organization, or collection of multiple nodes and devices, and are organized to accomplish or provide some aspect of a service or resource in an edge computing setting.

Additionally or alternatively, the term "edge computation" refers to the concept of having operators and third party services hosted near the attachment access point of the UE to enable efficient service delivery with reduced end-to-end latency and load on the transport network. As used herein, the term "edge computing service provider" refers to a mobile network operator or a third party service provider that provides edge computing services. As used herein, the term "edge data network" refers to a local Data Network (DN) that supports an architecture for implementing edge applications. As used herein, the term "edge hosting environment" refers to an environment that provides the support required for the execution of edge application servers. As used herein, the term "application server" refers to application software residing in the cloud that performs server functions.

The term "internet of things" or "IoT" refers to systems of interrelated computing devices, machines, and digital machines that are capable of transmitting data with little or no human interaction, and may involve technologies such as real-time analysis, machine learning and/or AI, embedded systems, wireless sensor networks, control systems, automation (e.g., smart home, smart building, and/or smart city technologies), and the like. IoT devices are typically low power devices that do not have heavy computing or storage capabilities. An "edge IoT device" may be any kind of IoT device deployed at the edge of a network.

As used herein, the term "cluster" refers to a set or set of entities in the form of physical entities (e.g., different computing systems, networks, or groups of networks), logical entities (e.g., applications, functions, security constructs, containers), etc., that are part of an edge computing system(s). In some locations, a "cluster" is also referred to as a "group" or "domain. The membership of a cluster may be modified or affected based on conditions or functions, including according to dynamic or attribute-based membership, according to a network or system management scenario, or according to various example techniques discussed below that may add, modify, or delete entities in the cluster. The clusters may also include or be associated with multiple layers, levels, or attributes (including variations in security features and results based on these layers, levels, or attributes).

The term "application" may refer to a complete and deployable package, environment for implementing specific functions in an operating environment. The term "AI/ML application" or the like may be an application that contains some AI/ML model and application-level descriptions. The term "machine learning" or "ML" refers to the use of computer systems implementing algorithms and/or statistical models that do not use explicit instructions, but instead rely on patterns and reasoning to perform particular tasks. The ML algorithm builds or estimates a mathematical model (called "ML model" or the like) based on sample data (called "training data", "model training information", or the like) in order to make predictions or decisions without explicit programming to perform these tasks. Generally, the ML algorithm is a computer program that learns from experience with some tasks and some performance metrics, while the ML model may be any object or data structure created after training the ML algorithm with one or more training data sets. After training, the ML model can be used to predict the new dataset. Although the term "ML algorithm" refers to a different concept than the term "ML model", for purposes of this disclosure, these terms discussed herein may be used interchangeably.

The terms "machine learning model", "ML model", and the like may also refer to ML methods and concepts used by ML-assisted solutions. An "ML-assisted solution" is a solution that uses an ML algorithm to solve a particular use case during operation. The ML model includes supervised learning (e.g., linear regression, K-nearest neighbor (KNN), decision tree algorithms, support machine vectors, bayesian algorithms, integration algorithms, etc.), unsupervised learning (e.g., K-means clustering, principal Component Analysis (PCA), etc.), reinforcement learning (e.g., Q-learning, deep RL, etc.), neural networks, etc. Depending on the implementation, a particular ML model may have many sub-models as components, and the ML model may train all sub-models together. During reasoning, separately trained ML models can also be linked together in the ML pipeline. An "ML pipe" is a set of functionalities, functions, or functional entities that are specific to an ML auxiliary solution; the ML pipeline may include one or several data sources among a data pipeline, a model training pipeline, a model evaluation pipeline, and a participant. "participants" are entities that host ML auxiliary solutions using the output of ML model reasoning. The term "ML training host" refers to an entity (e.g., network function) hosting the training of the model. The term "ML inference host" refers to an entity (e.g., a network function) that hosts a model during an inference mode (which includes both model execution and any online learning, if applicable). The ML host informs the participants of the output of the ML algorithm and the participants make decisions about the actions (as a result of the ML assistance solution output, the "actions" are performed by the participants). The term "model reasoning information" refers to information that refers to input to the ML model for determining reasoning; the data used to train the ML model and the data used to determine the reasoning may overlap, however, "training data" and "reasoning data" refer to different concepts.

The terms "instantiation", "instantiation" and the like as used herein refer to the creation of an instance. An "instance" also refers to a specific occurrence of an object that may occur, for example, during execution of program code. The term "cell" refers to a structural element that contains one or more fields. The term "field" refers to the individual content of a cell or a data element containing content. As used herein, "database object," "data structure," and the like may refer to any representation of information in the form of objects, attribute-value pairs (AVPs), key-value pairs (KVP), tuples, and the like, and may include variables, data structures, functions, methods, classes, database records, database fields, database entities, associations (also referred to as "relationships") between data and/or database entities, blocks in a blockchain implementation, links between blocks, and the like.

An "information object" as used herein refers to any representation of a collection of structured data and/or information, and may include, for example, an electronic document (or "document"), a database object, a data structure, a file, audio data, video data, raw data, an archive file, an application package, and/or any other similar representation of information. The term "electronic document" or "document" may refer to a data structure, computer file, or resource to record data, and includes various file types and/or data formats (e.g., word processing documents, spreadsheets, slide presentations, multimedia items, web pages and/or source code documents, etc.). By way of example, the information object may include a markup and/or source code document (e.g., HTML, XML, JSON, CSS、JSP、MessagePack ^TM 、/>Thrift ^TM 、ASN.1、/>Protocol buffers (protobuf) or some other document/format (e.g., the document/format discussed herein)). The information object may have both logical and physical structures. Physically, an information object comprises one or more units called entities. An entity is a unit of storage that contains content and is identified by a name. An entity may refer to other entities that make it included in an information object. The information object starts in a document entity, also called a root element (or "root"). Logically, an information object includes one or more declarations, elements, annotations, character references, and processing instructions, all of which are indicated in the information object (e.g., using tags).

The term "data item" as used herein refers to an atomic state of a particular object having at least one particular property at a point in time. Such objects are typically identified by object names or object identifiers, and the properties of such objects are typically defined as database objects (e.g., fields, records, etc.), object instances, or data elements (e.g., markup language elements/tags, etc.). Additionally or alternatively, the term "data item" as used herein may refer to data elements and/or content items, although these terms may refer to different concepts. The term "data element" or "element" as used herein refers to a unit that is indivisible at a given level of abstraction and has well-defined boundaries. A data element is a logical component of an information object (e.g., an electronic document) that may start with a start tag (e.g., "< element >") and end with a matching end tag (e.g., "</element >") or have only a null element tag (e.g., "< element/>). Any character (if any) between the start tag and the end tag is the content of the element (referred to herein as a "content item" or the like).

The content of the entity may include one or more content items, each having an associated data type representation. The content items may include, for example, attribute values, character values, URIs, qualified names (qnames), parameters, and the like. qname is a fully qualified name of an element, attribute, or identifier in an information object. The qname associates the URI of the namespace with the local name of the element, attribute, or identifier in the namespace. To make this association, the qname assigns a prefix to the local name that corresponds to its namespace. qname includes the URI of the namespace, the prefix, and the local name. Namespaces are used to provide uniquely named elements and attributes in an information object. The content items may include text content (e.g., "< element > content item </element >"), attributes (e.g., "< element attribute =" attributeValue ">") and other elements referred to as "sub-elements" (e.g., "< element1> < element2> content item </element2> </element1 >"). An "attribute" may refer to a tag construct that includes name-value pairs that exist within a start tag or a null element tag. Attributes contain data related to their elements and/or control the behavior of the elements.

The term "channel" as used herein refers to any tangible or intangible transmission medium to communicate data or data streams. The term "channel" may be synonymous and/or equivalent to "communication channel," "data communication channel," "transmission channel," "data transmission channel," "access channel," "data access channel," "link," "data link," "carrier," "radio frequency carrier," and/or any other similar term that refers to a path or medium through which data is communicated. Furthermore, the term "link" as used herein refers to a connection between two devices through a RAT for the purpose of transmitting and receiving information. As used herein, the term "radio technology" refers to technology for wirelessly transmitting and/or receiving electromagnetic radiation for information transfer. The term "radio access technology" or "RAT" refers to a technology for an underlying physical connection to a radio-based communication network. As used herein, the term "communication protocol" (wired or wireless) refers to a set of standardized rules or instructions implemented by a communication device and/or system to communicate with other devices and/or systems, including instructions for encapsulating/decapsulating data, modulating/demodulating signals, implementing a protocol stack, etc.

As used herein, the term "radio technology" refers to technology for wirelessly transmitting and/or receiving electromagnetic radiation for information transfer. The term "radio access technology" or "RAT" refers to a technology for an underlying physical connection to a radio-based communication network. As used herein, the term "communication protocol" (wired or wireless) refers to a set of standardized rules or instructions implemented by a communication device and/or system to communicate with other devices and/or systems, including instructions for encapsulating/decapsulating data, modulating/demodulating signals, implementing a protocol stack, etc. Examples of wireless communication protocols that may be used in various embodiments include Global System for Mobile communications (GSM) radio communication technology, general Packet Radio Service (GPRS) radio communication technology, enhanced data rates for GSM evolution (EDGE) radio communication technology, and/or third generation partnership project (3 GPP) radioCommunication technologies including, for example, 3GPP fifth generation (5G) or New air interface (NR), universal Mobile Telecommunications System (UMTS), multimedia Access Free (FOMA), long Term Evolution (LTE), LTE advanced (LTE-A), LTE Extra, LTE-A Pro, cdmaOne (2G), code division multiple Access 2000 (CDMA 2000), cellular Digital Packet Data (CDPD), mobitex, circuit Switched Data (CSD), high Speed CSD (HSCSSD), universal Mobile Telecommunications System (UMTS), wideband code division multiple Access (W-CDM), high Speed Packet Access (HSPA), HSPA Plus (HSPA+), time division-code division multiple Access (TD-CDMA), time division-synchronous code division multiple Access (TD-SCDMA) LTE LAA, muLTEfire, UMTS Terrestrial Radio Access (UTRA), evolved UTRA (E-UTRA), optimized evolved data or evolution-only data (EV-DO), advanced Mobile Phone System (AMPS), digital AMPS (D-AMPS), full access communication system/extended full access communication system (TACS/ETACS), push-to-talk (PTT), mobile phone system (MTS), improved mobile phone system (IMTS), advanced mobile phone system (AMTS), cellular Digital Packet Data (CDPD), dataTAC, integrated Digital Enhanced Network (iDEN), personal Digital Cellular (PDC), personal Handyphone System (PHS), broadband integrated digital enhanced network (WiDEN), iBurst, unlicensed Mobile Access (UMA) (also known as 3GPP generic access network or GAN standard)), and, Bluetooth Low Energy (BLE), IEEE 802.15.4-based protocols (e.g., IPv6 (6 LoWPAN), wireless HART, miWi, thread, 802.11a, etc. on a low power wireless personal area network), wiFi direct connection, ANT/ANT+, zigBee, Z-Wave, 3GPP device-to-device (D2D) or proximity services (ProSe), universal plug and Play (UPnP), low Power Wide Area Network (LPWAN), long distance Wide area network (LoRA) or LoRaWAN developed by Semtech and LoRa alliance ^TM Sigfox, wireless gigabit alliance (WiGig) standards, worldwide Interoperability for Microwave Access (WiMAX), universal mmWave standards (e.g., wireless systems operating at 10GHz-300GHz and above (e.g., wiGig, IEEE 802.11ad, IEEE 802.11ay, etc.), V2X communication techniques (including 3GPP C-V2X), dedicated short-range communication (DSRC) communication systems (e.g., intelligent Transportation Systems (ITS) including European ITS-G5, ITS-G5B, ITS-G5C, etc.). In addition to the criteria listed above, for purposes of this disclosure, one mayTo use any number of satellite uplink technologies including, for example, radios conforming to standards promulgated by the International Telecommunications Union (ITU), or the European Telecommunications Standards Institute (ETSI), or the like. Accordingly, the examples provided herein are understood to be applicable to a variety of other communication technologies, both existing and yet to be established.

The term "access network" refers to any network using any combination of radio technologies, RATs, and/or communication protocols to connect user equipment and service providers. In the context of a WLAN, an "access network" is an IEEE 802 Local Area Network (LAN) or Metropolitan Area Network (MAN) connected between terminals and access routers served by a provider. The term "access router" refers to a router that terminates a Medium Access Control (MAC) service from a terminal and forwards user traffic to an information server according to an Internet Protocol (IP) address.

The term "SMTC" refers to an SSB-based measurement timing configuration configured by SSB-measurementtiming configuration. The term "SSB" refers to a synchronization signal/physical broadcast channel (SS/PBCH) block that includes a Primary Synchronization Signal (PSS), a Secondary Synchronization Signal (SSs), and a PBCH. The term "primary cell" refers to an MCG cell operating on a primary frequency in which a UE performs an initial connection establishment procedure or initiates a connection re-establishment procedure. The term "primary SCG cell" refers to an SCG cell for DC operation in which the UE performs random access when performing a reconfiguration & synchronization procedure. The term "secondary cell" refers to a cell providing additional radio resources on top of a special cell for a UE configured with CA. The term "secondary cell group" refers to a subset of serving cells including PSCell and zero or more secondary cells for a UE configured with DC. The term "serving cell" refers to a primary cell for a UE under rrc_connected that is not configured with CA/DC, and there is only one serving cell including the primary cell. The term "serving cell" or "plurality of serving cells" refers to a cell set including a special cell and all secondary cells for a UE under rrc_connected configured with CA. The term "special cell" refers to the PCell of an MCG or the PSCell of an SCG for DC operation; otherwise, the term "special cell" refers to a Pcell.

The term "all-photon network" or "APN" refers to future communication infrastructure including high quality all-optical networks that responds to increasingly diverse and complex demands by using photonics-based technologies in all areas from the network to the terminal. This approach achieves various benefits including power savings on the order of 100 times improvement over traditional networks, larger capacity networks, and ultra low latency.

The term "digital twinning" refers to the virtual digital copy of actual or potential physical devices, processes, personnel, sites, and systems that can be used to run a simulation. The use of IOWN's digital twinning computation would be a significant advancement in achieving new, large-scale, high-precision real-world reproductions that were previously impossible by performing a large number of operations to freely combine various digital twinning.

The term "interconnect" refers to a link of an optical network at least in the context of IOWN so that a user of one all-optical network can communicate with a user of another all-optical network.

The term "framework" refers to a collection of documents defining specifications and underlying implementation details.

The term "large scale simulation" refers to a simulation that is an approximate imitation of the operation of a process or system that represents its operation over time.

The term "ultra wideband" or "UWB" refers to a wireless technology (or RAT) for transmitting large amounts of digital data over a wide frequency spectrum and frequency band with very low power for short distances.

The term "user interface" or "UI" refers to a graphical layout of an application that may include buttons clicked by a user, text they read, images, slides, text input fields, and all remaining items of user interaction. "UX" stands for "user experience". The term "user experience" or "UX" refers to determining the ease of interaction with user interface elements.

In addition to the foregoing, any of the disclosed embodiments and example implementations may also be embodied in various types of hardware, software, firmware, middleware, or combinations thereof (including in the form of control logic), and such hardware or software is employed in a modular or integrated manner. Furthermore, any of the software components or functions described herein may be implemented asSoftware, program code, scripts, instructions, etc. operable to be executed by the processor circuitry. These components, functions, programs, etc. may be developed using any suitable computer language, such as Python, pyTorch, numPy, ruby, ruby on Rails, scala, smalltalk, javaTM, C ++, C#, "C", kotlin, swift, rust, go (or "Golang"), EMCAScript, javaScript, typeScript, jscript, actionScript, server Side JavaScript (SSJS), PHP, pearl, lua, torch/Lua and Just-In Time compiler (LuaJIT), accelerated Mobile Page script (AMPscript), VBScript, javaServerPages (JSP), active Server Pages (ASP), node. Js, ASP. NET, JAMscript, hypertext markup language (HTML), extensible HTML (XHTML), extensible markup language (XML), XML user interface language (XUL), scalable Vector Graphics (SVG), RESTful API Modeling Language (RAML), wiki markup or Wikite, wireless Markup Language (WML), java Script Object (JSON), RESTful API modeling language (WixtML), MessagePack ^TM Cascading Style Sheets (CSS), extensible style sheet language (XSL), hu sub template language, handle bar template language, guide Template Language (GTL), and +.>Thread, abstract syntax symbol one (ASN.1), for example>Protocol buffering (protobuf), bitcoin script, +.>Byte code, resolution ^TM Vyper (Python derivative), bamroo, lisp class language (LLL), from Blockstream ^TM Simplicity, rholang, michelson, counterfactual, plasma, plutus, sophia, & gt, provided>And/or any other programming language or development tool(including proprietary programming languages and/or development tools). The software codes may be stored as computer or processor executable instructions or commands on a physically non-transitory computer readable medium. Examples of suitable media include RAM, ROM, magnetic media (e.g., hard or floppy disk drive), or optical media (e.g., compact Disk (CD) or DVD (digital versatile disk), flash memory, etc.), or any combination of such storage or transmission devices.

The embodiments described herein are not intended to be exhaustive or to limit the scope of the disclosure to the precise forms disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of various embodiments. Where specific details are set forth in order to describe example embodiments of the disclosure, it should be apparent to one skilled in the art that the disclosure can be practiced without, or with variation of, these specific details. It should be understood, however, that there is no intention to limit the concepts of the present disclosure to the specific forms disclosed, but on the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the disclosure and the appended claims.

Claims

1. A method implemented by an in-network service grid function of a Computing Service Function (CSF), the method comprising:

identifying, by the in-network service grid function, a device associated with the in-network service grid function;

identifying, by the in-network service grid function, a service request received from the device;

identifying, by the in-network service grid function, a service instance for the device in a service registry of the CSF based on the service request; and

an indication of the service instance is sent by the in-network service grid function.

2. The method of claim 1, wherein the identification of the service instance is based on sending, by the in-network service grid function, a query related to the service request to the service registry.

3. The method of claim 1, wherein the intra-network service grid function is one of a plurality of intra-network service grid functions of the CSF.

4. The method of claim 3, wherein respective ones of the plurality of intra-network service grid functions are associated with different ones of a plurality of devices.

5. The method of any of claims 1-4, wherein the in-network service grid function is to:

Identifying a service instance for the device based on at least one of: the location of the device, the location of the service instance, the load of the service instance, and the estimated service response time.

6. The method of any of claims 1-4, wherein the indication of the service instance comprises at least one of: the assigned service instance address, the assigned computing resources, and the service execution results.

7. The method of any of claims 1-4, wherein the device is associated with the in-network service grid function by one or more of: the association managed by the network controller, the association managed by a Dynamic Host Configuration Protocol (DHCP) server, and the association of the device autonomy.

8. One or more non-transitory computer-readable media comprising instructions that, when executed by one or more processors of a device, cause a service orchestration function-client (SOF-C) of the device to:

identifying a service request from a client application of the device;

identifying information related to availability of a service related to the service request based on interactions with one or more of an Operating System (OS) of the device and a service orchestration function-network (SOF-N) of a Computing Service Function (CSF) to which the device is communicatively coupled; and

The service request is directed to be executed locally or network based on information related to the availability of the service.

9. The one or more non-transitory computer-readable media of claim 8, wherein locally executing is related to executing the service by the device.

10. The one or more non-transitory computer-readable media of claim 8, wherein network execution is related to execution of the service by an electronic device to which the device is communicatively coupled.

11. The one or more non-transitory computer-readable media of claim 8, wherein the directing is based on a determination by the SOF-N based on information related to availability of the service.

12. The one or more non-transitory computer-readable media of claim 11, wherein the information relates to a network service registry.

13. The one or more non-transitory computer-readable media of any of claims 8-12, wherein the directing is based on a determination by the SOF-C based on information related to availability of the service.

14. The one or more non-transitory computer-readable media of any one of claims 8-12, wherein the information includes information related to one or more of: service availability, network conditions, device battery level, and estimated service execution time.

15. An apparatus, comprising:

one or more processors;

one or more non-transitory computer-readable media comprising instructions that, when executed by the one or more processors, cause a resource orchestration function-client (ROF-C):

identifying a plurality of resources of a network usable by the device based on communication with a resource orchestration function of the network (ROF-N);

providing an indication of the plurality of resources to an Operating System (OS) of the device;

identifying a request from the OS to access a resource of the plurality of resources;

transmitting an indication of the request to the ROF-N; and

based on a response received from the ROF-N to the request, it is identified whether a data path is established between the device and the network such that the OS can access the resource.

16. The apparatus of claim 15, wherein the ROF-C is to:

the plurality of resources is identified based on a list broadcast by the ROF-N.

17. The apparatus of claim 15, wherein the ROF-C is to:

the plurality of resources is identified based on a response made by the ROF-N to a query sent by the ROF-C to the ROF-N.

18. The apparatus of any of claims 15-17, wherein the resource is a computing resource or capability of an element of the network.

19. The apparatus of any one of claims 15-17, wherein the ROF-C is to:

if a response to the request indicates acceptance of the ROF-N, the data path is established.

20. The apparatus of any one of claims 15-17, wherein the ROF-C is to:

if the response to the request indicates that the ROF-N refuses, the data path is not established.