CN115720338A - Apparatus for use in a wireless communication network - Google Patents
Apparatus for use in a wireless communication network Download PDFInfo
- Publication number
- CN115720338A CN115720338A CN202210949275.4A CN202210949275A CN115720338A CN 115720338 A CN115720338 A CN 115720338A CN 202210949275 A CN202210949275 A CN 202210949275A CN 115720338 A CN115720338 A CN 115720338A
- Authority
- CN
- China
- Prior art keywords
- service
- distributed
- physical resource
- orchestrator
- resource provider
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Mobile Radio Communication Systems (AREA)
Abstract
The present application relates to an apparatus for use in a wireless communication network. An apparatus for use in a distributed Service Function (SF) orchestrator, wherein the apparatus comprises a processor circuit configured to cause the distributed SF orchestrator, upon receiving a service requirement from a service originator: sending a bid invitation associated with a service requirement to a distributed physical resource provider; receiving a bid request from a distributed physical resource provider as a response to the bid invitation; and forming an electronic contract between the distributed physical resource provider and the service originator based on the bid request when the distributed physical resource provider is selected by the service originator as a service provider associated with the service requirement.
Description
Cross Reference to Related Applications
This application is based on and claims priority from U.S. patent application No.63/236,451, filed 24/8/2021, which is hereby incorporated by reference in its entirety.
Technical Field
Embodiments of the present disclosure relate generally to wireless communications, and more particularly, to an apparatus for use in a wireless communication network.
Background
Currently, network Function Virtualization (NFV) technology is increasingly used in wireless communication networks to implement various communication network functions in general hardware resources. A network infrastructure of a wireless communication network employing NFV technology comprises a switch node and an NFV node, wherein: a Virtual Network Function (VNF) may be hosted on the NFV node; by isolation, multiple VNFs can run on the same NFV node; and due to limited resources on each NFV node, one VNF may also be distributed on different NFV nodes.
Drawings
Embodiments of the present disclosure are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements.
Fig. 1 shows a block diagram of a conventional NFV architecture.
Fig. 2 illustrates a sequence diagram of a Service Function Chaining (SFC) service provisioning related procedure for use in a distributed NFV architecture, in accordance with some embodiments of the present disclosure.
Fig. 3 illustrates a flow diagram of a Virtual Network Function (VNF) orchestration related method for use in a distributed SF orchestrator, according to some embodiments of the present disclosure.
Fig. 4 illustrates a sequence diagram of a registration and authentication related process for use in a distributed NFV architecture, in accordance with some embodiments of the present disclosure.
Fig. 5 shows a schematic diagram of a network according to various embodiments of the present disclosure.
Fig. 6 shows a schematic diagram of a wireless network in accordance with various embodiments of the present disclosure.
Fig. 7 illustrates a block diagram of components 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 methodologies discussed herein, in accordance with various embodiments of the present disclosure.
Detailed Description
Various aspects of the illustrative embodiments will be described using terms commonly employed by those skilled in the art to convey the substance of the disclosure to others skilled in the art. It will be apparent, however, to one skilled in the art that many alternative embodiments can be practiced using portions of the described aspects. For purposes of explanation, specific numbers, materials, and configurations are set forth in order to provide a thorough understanding of the illustrative embodiments. It will be apparent, however, to one skilled in the art that alternative embodiments may be practiced without these specific details. In other instances, well-known features may be omitted or simplified in order not to obscure the illustrative embodiments.
Further, various operations will be described as multiple discrete operations in turn, in a manner that is most helpful in understanding the illustrative embodiments; however, the order of description should not be construed as to imply that these operations are necessarily order dependent. In particular, these operations need not be performed in the order of presentation.
The phrases "in an embodiment," "in one embodiment," and "in some embodiments" are used repeatedly herein. Such phrases are not generally referring to the same embodiment; however, they may also refer to the same embodiment. The terms "comprising," "having," and "including" are synonymous, unless the context dictates otherwise. The phrases "A or B" and "A/B" mean "(A), (B), or (A and B)".
Fig. 1 illustrates a block diagram of a conventional NFV architecture 100. As shown in fig. 1, the conventional NFV architecture 100 includes a VNF module 102, a NFV infrastructure (NFVI) module 104, and a NFV management and orchestration (NFV-MANO) module 106, wherein the VNF module 102 is configured to implement various VNFs (for each VNF, there is a corresponding Element Management (EM) unit to manage the VNF), and the NFVI module 104 is configured to implement virtualization of underlying hardware resources to provide a runtime environment for the VNF; the NFV-MANO module 106 is configured to manage the VNF module 102 and the NFVI module 104 to enable overall management and orchestration of VNFs.
Further, as shown in fig. 1, NFV-MANO module 106 includes NFV orchestrator (NFVO) 1062, VNF manager (VNFM) 1064, and Virtualized Infrastructure Manager (VIM) 1066, where NFVO 1062 is coupled to an OSS/BSS (operations and billing support system) and configured to manage a combination of connected VNFs, VNFM 1064 is coupled to VNF module 102 to manage individual VNFs, and VIM 1066 is coupled to NFVI module 104 and configured to manage usage of NFVI resources.
In a wireless communication network employing NFV technology, the concatenation of network services is referred to as a Service Function Chain (SFC), and SFC services may be provided by a combination of VNFs. However, in the conventional NFV architecture 100, since the overall management and orchestration of VNFs is centrally implemented by the NFV-MANO module 106, various problems related to the centralized management and orchestration of software will inevitably occur.
In view of the above, a distributed NFV architecture is proposed that is capable of providing SFC services to third parties when a service originator (e.g., an OSS/BSS or a Communication Service Provider (CSP)) initiates the SFC services. In particular, the distributed NFV architecture includes VNF providers, a distributed Service Function (SF) orchestrator, and distributed physical resource providers that work together to provide SFC services initiated by a service originator.
Fig. 2 illustrates a sequence diagram of an SFC service provisioning related process 200 for use in a distributed NFV architecture, in accordance with some embodiments of the present disclosure. As shown in fig. 2, the SFC service provision related procedure 200 includes:
s201, the VNF provider creates a VNF instance and registers with the distributed SF orchestrator.
S202, the service initiating direction sends service requirements to the distributed SF orchestrator.
S203, the distributed SF orchestrator sends bid invitations associated with the service requirements to one or more distributed physical resource providers, wherein each bid invitation includes at least one of VNF package requirements, billing information, compliance statements associated with the service requirements.
S204, the one or more distributed physical resource providers send a bid request to the distributed SF orchestrator as a response to the bid invitation, wherein the VNF package requirements are matched with the network service delivery infrastructure of the one or more distributed physical resource providers.
The service originator selects one of the one or more distributed physical resource providers as the service provider associated with the service requirement S205.
S206, the distributed SF orchestrator forms an electronic contract between the service initiator and the distributed physical resource provider selected by the service initiator based on the bid request from the distributed physical resource provider selected by the service initiator, wherein the VNF associated with the service requirement is executed on the network service delivery infrastructure of the distributed physical resource provider selected by the service initiator according to the electronic contract.
Fig. 3 illustrates a flow diagram of a VNF orchestration related method 300 for use in a distributed SF orchestrator, according to some embodiments of the present disclosure, wherein the VNF orchestration related method 300 needs to be implemented in the SFC service provision related process 200. As shown in fig. 3, the VNF orchestration related method 300 includes: s302, when receiving a service demand from a service initiator, sending a bidding invitation associated with the service demand to a distributed physical resource provider; s304, receiving a bid request as a response to the bid invitation from the distributed physical resource provider; and S306, when the distributed physical resource provider is selected by the service initiator as the service provider associated with the service requirement, forming an electronic contract between the distributed physical resource provider and the service initiator based on the bid request.
In some embodiments, the electronic contract comprises a Service Level Agreement (SLA), and the VNF orchestration correlation method 300 further comprises: a bill associated with the service requirement is made based on the electronic contract. An analysis of quality of service experience and billing associated with the service demand may be made.
In some embodiments, the bid request includes at least one of VNF package requirements, billing information, and compliance statements associated with the service requirements; VNF package requirements are matched with the network service delivery infrastructure of the distributed physical resource provider; and/or the VNF instance associated with the service requirement executes on a network service delivery infrastructure of the distributed physical resource provider according to the electronic contract.
In some embodiments, the VNF package is provided by a VNF provider, wherein the VNF package is protected from modification, delivered by the VNF provider, and accessible by the OSS/BSS and/or distributed SF orchestrator.
In some embodiments, the distributed SF orchestrator acts as a commit node for the blockchain network, and the VNF provider, the distributed physical resource provider, and the service originator register with the distributed SF orchestrator as customer nodes of the blockchain network, each customer node requesting transactions only from the commit node.
Fig. 4 illustrates a sequence diagram of a registration and authentication related process 400 for use in a distributed NFV architecture, according to some embodiments of the present disclosure. As shown in fig. 4, the VNF provider, the distributed physical resource provider, and the service originator distributed SF orchestrator register their blockchain identities (S401-S403), the VNF provider and the service originator mutually authenticate each other using their blockchain identities (S404-S405), and a session key is exchanged between the VNF provider and the service originator after the mutual authentication between the VNF provider and the service originator is completed (S406).
In some embodiments, VNF instances associated with service requirements are created by VNF providers as resources or containers. For blockchains, an autonomous identity (SS ID) (e.g., a Globally Unique Identifier (GUID) and a random number) is generated at each protocol layer (e.g., each service function graph) for a VNF instance associated with a service requirement, as well as an initially configured cryptographic hash. The device identity of the VNF instance associated with the service requirement may be a physical identity, a network identity, a logical identity, etc. The SS ID generated for the VNF instance associated with the service requirement may be used as the blockchain identity for the VNF provider. In the event of resource conflicts, the distributed SF orchestrator may validate each operation and then restart.
In some embodiments, an initial configuration of a VNF instance associated with a service requirement is provided to a distributed SF orchestrator along with an SS ID associated with the VNF instance, and various service-related information associated with the VNF instance is bound to the SS ID associated with the VNF instance.
It should be appreciated that the service bid related methods used at the distributed physical resource providers also need to be implemented in the SFC service provision related process 200. Specifically, the service bid related method includes: receiving a bid invitation associated with a service requirement from a distributed SF orchestrator; and sending a bid request as a response to the bid invitation to the distributed SF orchestrator, wherein the service requirement is initiated by a service initiator, and an electronic contract between the distributed physical resource provider and the service initiator is formed based on the bid request when the distributed physical resource provider is selected by the service initiator as a service provider associated with the service requirement.
As described above, in contrast to traditional NFV architectures, which rely on a central orchestration entity to maintain customer relationships and "subcontract" workloads in the form of VNFs, the distributed NFV architecture removes the central orchestration entity and replaces it with a distributed service contract orchestrator role that any participant in the NFV ecosystem may occupy. Moreover, registering address and identity binding pairs of VNF providers, distributed physical resource providers, and service initiators onto the blockchain may provide tamper-resistant records for their transaction history and may be used to facilitate secure billing and analysis.
Fig. 5-6 illustrate various systems, devices, and components that can implement aspects of the disclosed embodiments.
Fig. 5 shows a schematic diagram of a network 500 according to various embodiments of the present disclosure. Network 500 may operate in accordance with 3GPP technical specifications for Long Term Evolution (LTE) or 5G/NR systems. However, the exemplary embodiments are not limited in this respect 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.
In some embodiments, network 500 may include multiple UEs directly coupled to each other through a sidelink interface. The UE may be an M2M/D2D device that communicates using a physical sidelink channel (e.g., without limitation, a Physical Sidelink Broadcast Channel (PSBCH), a Physical Sidelink Discovery Channel (PSDCH), a Physical Sidelink Shared Channel (PSSCH), a Physical Sidelink Control Channel (PSCCH), a Physical Sidelink Fundamental Channel (PSFCH), etc.).
In some embodiments, the UE 502 may also communicate with an Access Point (AP) 506 over an over-the-air connection. The AP 506 may manage a Wireless Local Area Network (WLAN) connection, which may be used to offload some/all network traffic from the RAN 504. The connection between the UE 502 and the AP 506 may be in accordance with any IEEE 802.11 protocol, wherein the AP 506 may be a Wireless FidelityA router. In some embodiments, the UE 502, RAN 504, and AP 506 may utilize cellular WLAN aggregation (e.g., LTE-WLAN aggregation (LWA)/lightweight IP (LWIP)). Cellular WLAN aggregation may involve configuring the UE 502 by the RAN 504 to utilize both cellular radio resources and WLAN resources.
The RAN 504 may include one or more access nodes, e.g., AN Access Node (AN) 508. The AN 508 may terminate air interface protocols of the UE 502 by providing access stratum protocols including a Radio Resource Control (RRC) protocol, a Packet Data Convergence Protocol (PDCP), a Radio Link Control (RLC) protocol, a Medium Access Control (MAC) protocol, and AN L1 protocol. In this manner, AN 508 may enable a data/voice connection between Core Network (CN) 520 and UE 502. In some embodiments, AN 508 may be implemented in a discrete device or as one or more software entities running on a server computer (as part of a virtual network, which may be referred to as a distributed RAN (CRAN) or virtual baseband unit pool, for example). The AN 508 may be referred to as a Base Station (BS), a next generation base station (gNB), a RAN node, AN evolved node B (eNB), a next generation eNB (ng-eNB), a node B (NodeB), a roadside unit (RSU), a transmit receive point (TRxP), a transmit point (TRP), and the like. The AN 508 may be a macrocell base station or a low power base station that provides a microcell, picocell, or other similar cell with smaller coverage area, smaller user capacity, or higher bandwidth than a macrocell.
In embodiments where the RAN 504 includes multiple ANs, the ANs may be coupled to each other over AN X2 interface (if the RAN 504 is AN LTE RAN) or AN Xn interface (if the RAN 504 is a 5G RAN). In some embodiments, the X2/Xn interface, which may be separated into a control/user plane interface, may allow the AN to communicate information related to handover, data/context transfer, mobility, load management, interference coordination, etc.
The ANs of the RAN 504 may each manage one or more cells, groups of cells, component carriers, etc., to provide the UE 502 with AN air interface for network access. The UE 502 may be simultaneously connected with multiple cells provided by the same or different ANs of the RAN 504. For example, UE 502 and RAN 504 may use carrier aggregation to allow UE 502 to connect with multiple component carriers, each corresponding to a primary cell (PCell) or a secondary cell (SCell). In a dual connectivity scenario, the first AN may be a master node providing a Master Cell Group (MCG) and the second AN may be a secondary node providing a Secondary Cell Group (SCG). The first/second AN can be any combination of eNB, gNB, ng-eNB, etc.
In a vehicle-to-everything (V2X) scenario, the UE 502 or AN 508 may be or act as a Road Side Unit (RSU), which may refer to any transport infrastructure entity for V2X communication. The RSU may be implemented in or by AN appropriate AN or stationary (or relatively stationary) UE. An RSU implemented in or by a UE may be referred to as a "UE-type RSU"; an RSU implemented in or by an eNB may be referred to as an "eNB-type RSU"; an RSU implemented in or by a next generation NodeB (gNB) may be referred to as a "gNB-type RSU" or the like. In one example, the RSU is a computing device coupled with radio frequency circuitry located at the curb side that provides connection support to passing vehicle UEs. The RSU may also include internal data storage circuitry for storing intersection map geometry, traffic volume 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 warnings, etc.). Additionally or alternatively, the RSU may provide other cellular/WLAN communication services. The components of the RSU may be enclosed in a weatherproof enclosure suitable for outdoor installation and may include a network interface controller to provide a wired connection (e.g., ethernet) to a traffic signal controller or backhaul network.
In some embodiments, RAN 504 may be an LTE RAN 510 including an evolved node B (eNB), e.g., eNB 512. The LTE RAN 510 may provide an LTE air interface with the following characteristics: subcarrier spacing (SCS) of 15 kHz; a single carrier frequency division multiple access (SC-FDMA) waveform for Uplink (UL) and a cyclic prefix orthogonal frequency division multiplexing (CP-OFDM) waveform for Downlink (DL); turbo codes for data and tail-biting convolutional codes (TBCC) for control, etc. The LTE air interface may rely on channel state information reference signals (CSI-RS) for CSI acquisition and beam management; performing Physical Downlink Shared Channel (PDSCH)/Physical Downlink Control Channel (PDCCH) demodulation by relying on a DMRS for PDSCH/PDCCH demodulation; and relying on Cell Reference Signals (CRS) for cell search and initial acquisition, channel quality measurements, and channel estimation, and on channel estimation for coherent demodulation/detection at the UE. The LTE air interface may operate on the 6GHz sub-band.
In some embodiments, RAN 504 may be a Next Generation (NG) -RAN 514 with a gNB (e.g., gNB 516) or gn-eNB (e.g., NG-eNB 518). The gNB 516 may connect with 5G-enabled UEs using a 5G NR interface. The gNB 516 may be connected to the 5G core through an NG interface, which may include an N2 interface or an N3 interface. The NG-eNB 518 may also be connected with the 5G core over the NG interface, but may be connected with the UE over the LTE air interface. The gNB 516 and ng-eNB 518 may be connected to each other through an Xn interface.
In some embodiments, the NG interface may be divided into two parts, a NG user plane (NG-U) interface, which carries traffic data between the UPF 548 and nodes of the NG-RAN 514 (e.g., an N3 interface), and a NG control plane (NG-C) interface, which is a signaling interface between the access and mobility management function (AMF) 544 and nodes of the NG-RAN 514 (e.g., an N2 interface).
The NG-RAN 514 may provide a 5G-NR air interface with the following characteristics: variable SCS; cyclic prefix-orthogonal frequency division multiplexing (CP-OFDM) for DL, CP-OFDM and DFT-s-OFDM for UL; polarity, repetition, simplex, and reed-muller codes for control; and low density parity check codes (LDPC) for the data. The 5G-NR air interface may rely on channel state reference signals (CSI-RS), PDSCH/PDCCH demodulation reference signals (DMRS), similar to the LTE air interface. The 5G-NR air interface may not use Cell Reference Signals (CRS), but may use Physical Broadcast Channel (PBCH) demodulation reference signals (DMRS) for PBCH demodulation; performing phase tracking of the PDSCH using a Phase Tracking Reference Signal (PTRS); and time tracking using the tracking reference signal. The 5G-NR air interface may operate over the FR1 band, which includes the 6GHz sub-band, or the FR2 band, which includes the 24.25GHz to 52.6GHz band. The 5G-NR air interface may include synchronization signals and PBCH blocks (SSBs), which are regions of a downlink resource grid including Primary Synchronization Signals (PSS)/Secondary Synchronization Signals (SSS)/PBCH.
In some embodiments, the 5G-NR air interface may use a bandwidth portion (BWP) for various purposes. For example, BWP may be used for dynamic adaptation of SCS. For example, the UE 502 may be configured with multiple BWPs, where each BWP configuration has a different SCS. When the BWP is indicated to the UE 502 to change, the SCS of the transmission also changes. Another use case for BWP is related to power saving. In particular, the UE 502 may be configured with multiple BWPs with different numbers of frequency resources (e.g., PRBs) to support data transmission in different traffic load scenarios. BWPs containing a smaller number of PRBs may be used for data transmission with smaller traffic load while allowing power savings at the UE 502 and, in some cases, the gNB 516. BWPs containing a large number of PRBs may be used in scenarios with higher traffic loads.
In some embodiments, CN 520 may be LTE CN 522, which may also be referred to as Evolved Packet Core (EPC). LTE CN 522 may include a Mobility Management Entity (MME) 524, a Serving Gateway (SGW) 526, a serving General Packet Radio Service (GPRS) support node (SGSN) 528, a Home Subscriber Server (HSS) 530, a Proxy Gateway (PGW) 532, and a policy control and charging rules function (PCRF) 534, which are coupled to each other by an interface (or "reference point") as shown. The functions of the elements of LTE CN 522 may be briefly introduced as follows.
The MME 524 may implement mobility management functions to track the current location of the UE 502 to facilitate paging, bearer activation/deactivation, handover, gateway selection, authentication, etc.
The SGSN 528 can track the location of the UE 502 and perform security functions and access control. In addition, the SGSN 528 may perform EPC inter-node signaling for mobility between different Radio Access Technology (RAT) networks; PDN and S-GW selection specified by MME 524; MME selection for handover, etc. The S3 reference point between MME 524 and SGSN 528 may enable user and bearer information exchange for inter-3 GPP access network mobility in idle/active state.
In some embodiments, CN 520 may be a 5G core network (5 GC) 540. The 5GC 540 may include an authentication server function (AUSF) 542, an access and mobility management function (AMF) 544, a Session Management Function (SMF) 546, a User Plane Function (UPF) 548, a Network Slice Selection Function (NSSF) 550, a network open function (NEF) 552, an NF storage function (NRF) 554, a Policy Control Function (PCF) 556, a Unified Data Management (UDM) 558, and an Application Function (AF) 560, which are coupled to each other by an interface (or "reference point") as shown. The function of the elements of the 5GC 540 can be briefly described as follows.
The AUSF 542 may store data for authentication of the UE 502 and handle authentication related functions. The AUSF 542 may facilitate a common authentication framework for various access types. The AUSF 542 may exhibit a Nausf service based interface in addition to communicating with other elements of the 5GC 540 through the reference points as shown.
The AMF 544 may allow other functions of the 5GC 540 to communicate with the UE 502 and the RAN 504 and subscribe to notifications regarding mobility events for the UE 502. The AMF 544 may be responsible for registration management (e.g., registering the UE 502), connection management, reachability management, mobility management, lawful interception of AMF-related events, and access authentication and authorization. AMF 544 may provide for the transmission of Session Management (SM) messages between UE 502 and SMF 546 and act as a transparent proxy for routing SM messages. The AMF 544 may also provide for the transmission of SMS messages between the UE 502 and the SMSF. AMF 544 may interact with AUSF 542 and UE 502 to perform various security anchor and context management functions. Further, AMF 544 may be a termination point for the RAN CP interface, which may include or be an N2 reference point between RAN 504 and AMF 544; the AMF 544 may serve as a termination point for NAS (N1) signaling and perform NAS ciphering and integrity protection. The AMF 544 may also support NAS signaling communications with the UE 502 over the N3 IWF interface.
The UPF 548 may serve as an anchor point for intra-RAT and inter-RAT mobility, an external PDU session point interconnected with the data network 536, and a branch point to support multi-homed PDU sessions. The UPF 548 can also perform packet routing and forwarding, perform packet inspection, perform the user plane portion of policy rules, lawful intercepted packets (UP collection), perform traffic usage reporting, perform QoS processing for the user plane (e.g., packet filtering, gating, UL/DL rate enforcement), perform uplink traffic validation (e.g., SDF to QoS flow mapping), transport level packet tagging in the uplink and downlink, and perform downlink packet buffering and downlink data notification triggering. The UPF 548 may include an uplink classifier to support routing of traffic flows to a data network.
The AF 560 can provide application impact on traffic routing, provide access to NEFs, and interact with the policy framework for policy control.
In some embodiments, the 5GC 540 may enable edge computation by selecting an operator/third party service that is geographically close to the point where the UE 502 connects to the network. This may reduce delay and load on the network. To provide an edge calculation implementation, the 5GC 540 may select the UPF 548 near the UE 502 and perform traffic steering from the UPF 548 to the data network 536 over the N6 interface. This may be based on UE subscription data, UE location, and information provided by AF 560. In this way, the AF 560 can affect UPF (re) selection and traffic routing. Based on operator deployment, the network operator may allow AF 560 to interact directly with the relevant NFs when AF 560 is considered a trusted entity. In addition, the AF 560 may expose a Naf service-based interface.
The data network 536 may represent various network operator services, internet access, or third party services that may be provided by one or more servers, including, for example, an application/content server 538.
Fig. 6 illustrates a wireless network 600 in accordance with various embodiments. The wireless network 600 may include a UE 602 in wireless communication with AN 604. The UE 602 and the AN 604 may be similar to and substantially interchangeable with like-named components described elsewhere herein.
The UE 602 may be communicatively coupled with AN 604 via a connection 606. Connection 606 is shown as an air interface to enable communication coupling and may operate at millimeter wave or below 6GHz frequencies according to a cellular communication protocol such as the LTE protocol or the 5G NR protocol.
The modem platform 610 may further include digital baseband circuitry 616, the digital baseband circuitry 616 may implement one or more layer operations "below" the layer operations performed by the protocol processing circuitry 614 in the network protocol stack. These operations may include, for example, PHY operations including one or more of HARQ-ACK functions, scrambling/descrambling, encoding/decoding, layer mapping/demapping, modulation symbol mapping, received symbol/bit metric determination, multi-antenna port precoding/decoding, wherein these functions may include one or more of space-time, space-frequency, or spatial coding, reference signal generation/detection, preamble sequence generation and/or decoding, synchronization sequence generation/detection, control channel signal blind decoding, and other related functions.
Modem platform 610 may further include transmit circuitry 618, receive circuitry 620, RF circuitry 622, and RF front end (RFFE) circuitry 624, which may include or be connected to one or more antenna panels 626. Briefly, the transmit circuit 618 may include a digital-to-analog converter, a mixer, intermediate Frequency (IF) components, and the like; the receive circuitry 620 may include analog-to-digital converters, mixers, IF components, and the like; RF circuitry 622 may include low noise amplifiers, power tracking components, and the like; the RFFE circuitry 624 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 components of transmit circuitry 618, receive circuitry 620, RF circuitry 622, RFFE circuitry 624, and antenna panel 626 (collectively, "transmit/receive components") may be specific to details of the particular implementation, e.g., whether the communication is Time Division Multiplexed (TDM) or Frequency Division Multiplexed (FDM), at mmWave or below 6GHz frequencies, etc. In some embodiments, the transmit/receive components may be arranged in multiple parallel transmit/receive chains, and may be arranged in the same or different chips/modules, etc.
In some embodiments, the protocol processing circuit 614 may include one or more instances of control circuitry (not shown) to provide control functionality for the transmit/receive components.
UE reception may be established by and via antenna panel 626, RFFE circuitry 624, RF circuitry 622, receive circuitry 620, digital baseband circuitry 616, and protocol processing circuitry 614. In some embodiments, antenna panel 626 may receive transmissions from AN 604 by receiving beamformed signals received by multiple antennas/antenna elements of one or more antenna panels 626.
UE transmissions may be established via and through protocol processing circuitry 614, digital baseband circuitry 616, transmit circuitry 618, RF circuitry 622, RFFE circuitry 624, and antenna panel 626. In some embodiments, the transmit components of UE 602 may apply spatial filtering to the data to be transmitted to form the transmit beams transmitted by the antenna elements of antenna panel 626.
Similar to UE 602, AN 604 may include a host platform 628 coupled to a modem platform 630. The host platform 628 may include an application processing circuit 632 coupled with a protocol processing circuit 634 of the modem platform 630. The modem platform may also include digital baseband circuitry 636, transmit circuitry 638, receive circuitry 640, RF circuitry 642, RFFE circuitry 644, and antenna panel 646. The components of the AN 604 may be similar to, and substantially interchangeable with, the synonymous components of the UE 602. In addition to performing data transmission/reception as described above, the components of AN 604 may perform various logical functions including, for example, radio Network Controller (RNC) functions such as radio bearer management, uplink and downlink dynamic radio resource management, and data packet scheduling.
Fig. 7 is a block diagram illustrating components 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 methodologies discussed herein, according to some example embodiments. In particular, fig. 7 shows a schematic diagram of hardware resources 700, hardware resources 700 including one or more processors (or processor cores) 710, one or more memory/storage devices 720, and one or more communication resources 730, where each of these processors, memory/storage devices, and communication resources may be communicatively coupled via a bus 740 or other interface circuitry. For embodiments utilizing node virtualization (e.g., network Function Virtualization (NFV)), hypervisor 702 may be executed to provide an execution environment for one or more network slices/subslices to utilize hardware resources 700.
Memory/storage 720 may include a main memory, a disk storage device, or any suitable combination thereof. The memory/storage 720 may include, but is not limited to, any type of volatile, non-volatile, or semi-volatile memory, such as Dynamic Random Access Memory (DRAM), static Random Access Memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, solid-state memory, and the like.
The communication resources 730 may include interconnection or network interface controllers, components, or other suitable devices to communicate with one or more peripherals 704 or one or more databases 706 or other network elements via the network 708. For example, communication resources 730 may include wired communication components (e.g., for coupling via USB, ethernet, etc.)) a cellular communication component, a Near Field Communication (NFC) component,(orLow energy) assembly,Components, and other communication components.
The instructions 750 may include software, programs, applications, applets, applications, or other executable code for causing at least any one of the processors 710 to perform any one or more of the methods discussed herein. The instructions 750 may reside, completely or partially, within at least one of the processor 710 (e.g., in a cache of the processor), the memory/storage 720, or any suitable combination thereof. Further, any portion of instructions 750 may be communicated to hardware resource 700 from any combination of peripheral device 704 or database 706. Thus, the memory of the processor 710, the memory/storage 720, the peripherals 704, and the database 706 are examples of computer-readable and machine-readable media.
The following paragraphs describe examples of various embodiments.
Example 1 includes an apparatus for use in a distributed Service Function (SF) orchestrator, wherein the apparatus comprises a processor circuit configured to cause the distributed SF orchestrator, upon receiving a service requirement from a service originator: sending a bid invitation associated with the service requirement to a distributed physical resource provider; receiving a bid request from the distributed physical resource provider as a response to the bid invitation; and forming an electronic contract between the distributed physical resource provider and the service originator based on the bid request when the distributed physical resource provider is selected by the service originator as a service provider associated with the service requirement.
Example 2 includes the apparatus of example 1, wherein the electronic contract comprises a Service Level Agreement (SLA), and the processor circuit is further configured to cause the distributed SF orchestrator to: a bill associated with the service requirement is made based on the electronic contract.
Example 3 includes the apparatus of example 1, wherein the bid request includes at least one of a Virtual Network Function (VNF) package demand, billing information, and a compliance statement associated with the service demand.
Example 4 includes the apparatus of example 3, wherein the VNF package requirements are matched with a network service delivery infrastructure of the distributed physical resource provider.
Example 5 includes the apparatus of example 4, wherein the VNF instance associated with the service requirement is executed on a network service delivery infrastructure of the distributed physical resource provider in accordance with the electronic contract.
Example 6 includes the apparatus of example 5, wherein the processor circuit is further configured to cause the distributed SF composer to act as a commit node of a blockchain network, and wherein the distributed physical resource provider and the service originator are registered with the distributed SF composer as customer nodes of the blockchain network.
Example 7 includes the apparatus of example 6, wherein a VNF provider that provides the VNF instance associated with the service requirement is also registered with the distributed SF orchestrator as a customer node of the blockchain network.
Example 8 includes the apparatus of example 7, wherein an autonomous identity (SS ID) associated with the VNF instance is used as a blockchain identity of the VNF provider.
Example 9 includes the apparatus of example 7, wherein a session key is exchanged between the VNF provider and the service initiator after the VNF provider and the service initiator mutually authenticate each other using their blockchain identities.
Example 10 includes the apparatus of example 8, wherein an initial configuration of the VNF instance is provided to the distributed SF orchestrator along with an SS ID associated with the VNF instance.
Example 11 includes the apparatus of example 8, wherein various service-related information associated with the VNF instance is bound to an SS ID associated with the VNF instance.
Example 12 includes an apparatus for use at a distributed physical resource provider, wherein the apparatus comprises a processor circuit configured to cause the distributed physical resource provider to: receiving a bid invitation associated with a service requirement from a distributed Service Function (SF) orchestrator; sending a bid request to the distributed SF orchestrator as a response to the bid invitation, wherein the service requirement is initiated by a service originator, and an electronic contract between the distributed physical resource provider and the service originator is formed based on the bid request when the distributed physical resource provider is selected by the service originator as a service provider associated with the service requirement.
Example 13 includes the apparatus of example 12, wherein the processor circuit is further configured to cause the distributed physical resource provider to: a client node as a blockchain network registers with the distributed SF orchestrator, wherein the distributed SF orchestrator serves as a commit node of the blockchain network.
Example 14 includes a computer-readable storage medium having stored thereon computer-executable instructions, wherein the computer-executable instructions, when executed by processor circuitry of a distributed Service Function (SF) orchestrator, cause the distributed SF orchestrator, upon receiving a service demand from a service originator to: sending a bid invitation associated with the service requirement to a distributed physical resource provider; receiving a bid request from the distributed physical resource provider as a response to the bid invitation; and forming an electronic contract between the distributed physical resource provider and the service originator based on the bid request when the distributed physical resource provider is selected by the service originator as a service provider associated with the service requirement.
Example 15 includes the computer-readable storage medium of example 14, wherein the electronic contract contains a Service Level Agreement (SLA), and the computer-executable instructions, when executed by the processor circuit of the distributed SF orchestrator, further cause the distributed SF orchestrator to: a bill associated with the service requirement is made based on the electronic contract.
Example 16 includes the computer-readable storage medium of example 14, wherein the bid request contains at least one of a Virtual Network Function (VNF) package demand, billing information, and a compliance statement associated with the service demand.
Example 17 includes the computer-readable storage medium of example 16, wherein the VNF package requirements are matched with a network service delivery infrastructure of the distributed physical resource provider.
Example 18 includes the computer-readable storage medium of example 17, wherein the VNF instance associated with the service requirement executes on a network service delivery infrastructure of the distributed physical resource provider in accordance with the electronic contract.
Example 19 includes the computer-readable storage medium of example 18, wherein the computer-executable instructions, when executed by the processor circuit of the distributed SF composer, further cause the distributed SF composer to act as a commit node of a blockchain network, and wherein the distributed physical resource provider and the service originator are registered with the distributed SF composer as customer nodes of the blockchain network.
Example 20 includes the computer-readable storage medium of example 19, wherein a VNF provider that provides the VNF instance associated with the service requirement is also registered with the distributed SF orchestrator as a customer node of the blockchain network.
Example 21 includes the computer-readable storage medium of example 20, wherein an autonomous identity (SS ID) associated with the VNF instance is used as the blockchain identity of the VNF provider.
Example 22 includes the computer-readable storage medium of example 20, wherein a session key is exchanged between the VNF provider and the service initiator after the VNF provider and the service initiator mutually authenticate each other using their blockchain identities.
Example 23 includes the computer-readable storage medium of example 21, wherein the initial configuration of the VNF instance is provided to the distributed SF orchestrator along with an SS ID associated with the VNF instance.
Example 24 includes the computer-readable storage medium of example 21, wherein various service-related information associated with the VNF instance is bound to an SS ID associated with the VNF instance.
Example 25 includes a computer-readable storage medium having computer-executable instructions stored thereon, wherein the computer-executable instructions, when executed by processor circuitry of a distributed physical resource provider, cause the distributed physical resource provider to: receiving a bid invitation associated with a service requirement from a distributed Service Function (SF) orchestrator; sending a bid request to the distributed SF orchestrator as a response to the bid invitation, wherein the service requirement is initiated by a service originator, and an electronic contract between the distributed physical resource provider and the service originator is formed based on the bid request when the distributed physical resource provider is selected by the service originator as a service provider associated with the service requirement.
Example 26 includes the computer-readable storage medium of example 25, wherein the computer-executable instructions, when executed by the processor circuit of the distributed physical resource provider, further cause the distributed physical resource provider to: a client node that is a blockchain network registers with the distributed SF orchestrator, wherein the distributed SF orchestrator serves as a commit node for the blockchain network.
Example 27 includes a method for use in a distributed Service Function (SF) orchestrator, the method comprising, upon receiving a service demand from a service originator: sending a bid invitation associated with the service requirement to a distributed physical resource provider; receiving a bid request from the distributed physical resource provider as a response to the bid invitation; and forming an electronic contract between the distributed physical resource provider and the service originator based on the bid request when the distributed physical resource provider is selected by the service originator as a service provider associated with the service requirement.
Example 28 includes the method of example 27, wherein the electronic contract contains a Service Level Agreement (SLA), and the processor circuit is further configured to cause the distributed SF orchestrator to: a bill associated with the service requirement is made based on the electronic contract.
Example 29 includes the method of example 27, wherein the bid request includes at least one of a Virtual Network Function (VNF) package demand, billing information, and a compliance statement associated with the service demand.
Example 30 includes the method of example 29, wherein the VNF package requirements are matched with a network service delivery infrastructure of the distributed physical resource provider.
Example 31 includes the method of example 30, wherein the VNF instance associated with the service requirement is executed on a network service delivery infrastructure of the distributed physical resource provider according to the electronic contract.
Example 32 includes the method of example 31, wherein the distributed SF orchestrator acts as a commit node for a blockchain network, and wherein the distributed physical resource provider and the service initiator are registered with the distributed SF orchestrator as customer nodes for the blockchain network.
Example 33 includes the method of example 32, wherein a VNF provider that provides the VNF instance associated with the service requirement is also registered with the distributed SF orchestrator as a customer node of the blockchain network.
Example 34 includes the method of example 33, wherein an autonomous identity (SS ID) associated with the VNF instance is used as a blockchain identity of the VNF provider.
Example 35 includes the method of example 33, wherein a session key is exchanged between the VNF provider and the service originator after the VNF provider and the service originator mutually authenticate each other using their blockchain identities.
Example 36 includes the method of example 34, wherein the initial configuration of the VNF instance is provided to the distributed SF orchestrator along with an SS ID associated with the VNF instance.
Example 37 includes the method of example 34, wherein various service-related information associated with the VNF instance is bound to an SS ID associated with the VNF instance.
Example 38 includes a method for use at a distributed physical resource provider, the method comprising: receiving a bid invitation associated with a service requirement from a distributed Service Function (SF) orchestrator; sending a bid request to the distributed SF orchestrator as a response to the bid invitation, wherein the service requirement is initiated by a service originator, and an electronic contract between the distributed physical resource provider and the service originator is formed based on the bid request when the distributed physical resource provider is selected by the service originator as a service provider associated with the service requirement.
Example 39 includes the method of example 38, further comprising: a client node as a blockchain network registers with the distributed SF orchestrator, wherein the distributed SF orchestrator serves as a commit node of the blockchain network.
Example 40 includes an apparatus for use in a distributed Service Function (SF) orchestrator, comprising means for implementing the method of any one of examples 27-37.
Example 41 includes an apparatus for use at a distributed physical resource provider, the apparatus comprising means for implementing the method of any of examples 38-39.
Although certain embodiments have been illustrated and described herein for purposes of description, a wide variety of alternate and/or equivalent embodiments or implementations calculated to achieve the same purposes may be substituted for the embodiments shown and described without departing from the scope of the present disclosure. This application is intended to cover any adaptations or variations of the embodiments discussed herein. Therefore, it is manifestly intended that the embodiments described herein be limited only by the claims and the equivalents thereof.
Claims (25)
1. An apparatus for use in a distributed Service Function (SF) orchestrator, wherein the apparatus comprises a processor circuit configured to cause the distributed SF orchestrator, upon receiving a service demand from a service originator:
sending a bid invitation associated with the service requirement to a distributed physical resource provider;
receiving a bid request from the distributed physical resource provider in response to the bid invitation; and
forming an electronic contract between the distributed physical resource provider and the service originator based on the bid request when the distributed physical resource provider is selected by the service originator as a service provider associated with the service requirement.
2. The apparatus of claim 1, wherein the electronic contract comprises a Service Level Agreement (SLA), and the processor circuit is further configured to cause the distributed SF orchestrator to:
a bill associated with the service requirement is made based on the electronic contract.
3. The apparatus of claim 1, wherein the bid request comprises at least one of a Virtual Network Function (VNF) package requirement, billing information, and a compliance statement associated with the service requirement.
4. The apparatus of claim 3, wherein the VNF package requirements are matched to a network service delivery infrastructure of the distributed physical resource provider.
5. The apparatus of claim 4, wherein the VNF instance associated with the service requirement executes on a network service delivery infrastructure of the distributed physical resource provider in accordance with the electronic contract.
6. The apparatus of claim 5, wherein the processor circuit is further configured to cause the distributed SF orchestrator to act as a commit node for a blockchain network, and wherein the distributed physical resource provider and the service originator are registered with the distributed SF orchestrator as customer nodes for the blockchain network.
7. The apparatus of claim 6, wherein a VNF provider that provides the VNF instance associated with the service requirement is also registered with the distributed SF orchestrator as a customer node of the blockchain network.
8. The apparatus of claim 7, wherein an autonomous identity (SSID) associated with the VNF instance is used as a blockchain identity for the VNF provider.
9. The apparatus of claim 7, wherein a session key is exchanged between the VNF provider and the service originator after the VNF provider and the service originator mutually authenticate each other using their blockchain identities.
10. The apparatus of claim 8, wherein an initial configuration of the VNF instance is provided to the distributed SF orchestrator along with an SSID associated with the VNF instance.
11. The apparatus of claim 8, wherein various service related information associated with the VNF instance is bound to an SSID associated with the VNF instance.
12. An apparatus for use at a distributed physical resource provider, wherein the apparatus comprises a processor circuit configured to cause the distributed physical resource provider to:
receiving a bid invitation associated with a service requirement from a distributed Service Function (SF) orchestrator;
sending a bid request as a response to the bid invitation to the distributed SF orchestrator, wherein
The service requirement is initiated by a service initiator, and an electronic contract between the distributed physical resource provider and the service initiator is formed based on the bid request when the distributed physical resource provider is selected by the service initiator as a service provider associated with the service requirement.
13. The apparatus of claim 12, wherein the processor circuit is further configured to cause the distributed physical resource provider to:
a client node as a blockchain network registers with the distributed SF orchestrator, wherein the distributed SF orchestrator serves as a commit node of the blockchain network.
14. A computer-readable storage medium having stored thereon computer-executable instructions, wherein the computer-executable instructions, when executed by processor circuitry of a distributed Service Function (SF) orchestrator, cause the distributed SF orchestrator, upon receiving a service demand from a service originator to:
sending a bid invitation associated with the service requirement to a distributed physical resource provider;
receiving a bid request from the distributed physical resource provider as a response to the bid invitation; and
when the distributed physical resource provider is selected by the service originator as a service provider associated with the service requirement, an electronic contract between the distributed physical resource provider and the service originator is formed based on the bid request.
15. The computer-readable storage medium of claim 14, wherein the electronic contract contains a Service Level Agreement (SLA), and the computer-executable instructions, when executed by the processor circuit of the distributed SF orchestrator, further cause the distributed SF orchestrator to:
a bill associated with the service requirement is made based on the electronic contract.
16. The computer-readable storage medium of claim 14, wherein the bid request includes at least one of a Virtual Network Function (VNF) package demand, billing information, and a compliance statement associated with the service demand.
17. The computer-readable storage medium of claim 16, wherein the VNF package requirements are matched to a network service delivery infrastructure of the distributed physical resource provider.
18. The computer-readable storage medium of claim 17, wherein the VNF instance associated with the service requirement executes on a network service delivery infrastructure of the distributed physical resource provider according to the electronic contract.
19. The computer-readable storage medium of claim 18, wherein the computer-executable instructions, when executed by the processor circuit of the distributed SF orchestrator, further cause the distributed SF orchestrator to act as a commit node for a blockchain network, and wherein the distributed physical resource provider and the service originator are registered with the distributed SF orchestrator as customer nodes of the blockchain network.
20. The computer-readable storage medium of claim 19, wherein a VNF provider that provides the VNF instance associated with the service requirement is also registered with the distributed SF orchestrator as a customer node of the blockchain network.
21. The computer-readable storage medium of claim 20, wherein an autonomous identity (SSID) associated with the VNF instance is used as a blockchain identity for the VNF provider.
22. The computer-readable storage medium of claim 20, wherein a session key is exchanged between the VNF provider and the service initiator after the VNF provider and the service initiator mutually authenticate each other using their blockchain identities.
23. The computer-readable storage medium of claim 21, wherein the initial configuration of the VNF instance is provided to the distributed SF orchestrator along with an SSID associated with the VNF instance.
24. A computer-readable storage medium having stored thereon computer-executable instructions, wherein the computer-executable instructions, when executed by a processor circuit of a distributed physical resource provider, cause the distributed physical resource provider to:
receiving a bid invitation associated with a service requirement from a distributed Service Function (SF) orchestrator;
sending a bid request as a response to the bid invitation to the distributed SF orchestrator, wherein
The service requirement is initiated by a service initiator, and an electronic contract between the distributed physical resource provider and the service initiator is formed based on the bid request when the distributed physical resource provider is selected by the service initiator as a service provider associated with the service requirement.
25. The computer-readable storage medium of claim 24, wherein the computer-executable instructions, when executed by the processor circuit of the distributed physical resource provider, further cause the distributed physical resource provider to:
a client node as a blockchain network registers with the distributed SF orchestrator, wherein the distributed SF orchestrator serves as a commit node of the blockchain network.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US202163236451P | 2021-08-24 | 2021-08-24 | |
US63/236,451 | 2021-08-24 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN115720338A true CN115720338A (en) | 2023-02-28 |
Family
ID=85253887
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202210949275.4A Pending CN115720338A (en) | 2021-08-24 | 2022-08-09 | Apparatus for use in a wireless communication network |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN115720338A (en) |
-
2022
- 2022-08-09 CN CN202210949275.4A patent/CN115720338A/en active Pending
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN113179551A (en) | Downlink transmission for high speed scenarios | |
CN114339688A (en) | Apparatus and method for authentication of a UE with an edge data network | |
CN114339821A (en) | Method and apparatus for machine learning model sharing between distributed NWDAFs | |
CN113766502A (en) | Apparatus for use in a UE, SMF entity, and provisioning server | |
CN113285790A (en) | Method for feeding back resource allocation | |
CN115694700A (en) | Apparatus for use in a wireless communication system | |
CN114641044A (en) | Apparatus for use in source base station, target base station and user equipment | |
CN114765485A (en) | Apparatus for use in user equipment | |
CN114765826A (en) | Arrangement in an access node | |
CN115720338A (en) | Apparatus for use in a wireless communication network | |
CN117528565A (en) | Apparatus and computer readable storage medium for mitigating EAS discovery failures | |
CN117014852A (en) | Device for policy provisioning of UE | |
CN115278637A (en) | Apparatus for use in a core network | |
CN116390118A (en) | Apparatus for use in ECSP and PLMN management systems | |
CN117251224A (en) | ML entity loading device for management service producer | |
CN116981106A (en) | Apparatus for use in a wireless communication system | |
CN115884234A (en) | Apparatus for use in a wireless communication system | |
CN117234889A (en) | ML entity testing device for management service consumer and producer | |
CN118042463A (en) | Apparatus and method for data verification | |
CN116405888A (en) | Billing-related device for use in EES and CHF | |
CN115250465A (en) | Apparatus for use in a core network | |
CN116266815A (en) | Apparatus for supporting artificial intelligence or machine learning in wireless communication system | |
CN116981056A (en) | Apparatus for artificial intelligence or machine learning assisted beam management | |
CN114584270A (en) | Apparatus for use in user equipment | |
CN116264747A (en) | Device for managing data analysis and management service consumer and producer |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication |