Method and apparatus for transparent exchange of service function identifiers

The programmable middleware solution addresses the challenge of dynamic SFC reconfiguration by transparently updating SFIDs, enhancing network flexibility and efficiency in communication networks.

JP7702967B2Active Publication Date: 2025-07-04INTERDIGITAL PATENT HOLDINGS INC
View PDF 4 Cites 0 Cited by

Patent Information

Application Number
JP2022568867
Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
Priority Date
2020-05-14
Filing Date
2021-05-13
Publication Date
2025-07-04
Estimated Expiration
2041-05-13

AI Technical Summary

Technical Problem

Existing communication networks face challenges in dynamically reconfiguring service function chains (SFCs) due to the lack of transparent and efficient exchange of service function identifiers (SFIDs), which hinders end-to-end slicing and orchestration, requiring code changes and affecting application development workflows.

Method used

Implementing programmable middleware with a service function identifier (SFID) exchange mechanism using a programmable application programming interface (API) to map and update SFIDs transparently, allowing dynamic reconfiguration without altering application code.

Benefits of technology

Enables seamless and dynamic reconfiguration of SFCs, improving network flexibility and efficiency by automating SFID updates, thereby enhancing end-to-end slicing capabilities.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 0007702967000004
    Figure 0007702967000004
  • Figure 0007702967000005
    Figure 0007702967000005
  • Figure 0007702967000006
    Figure 0007702967000006
Patent Text Reader

Abstract

In one example, a method for wireless communication includes transmitting configuration information to one or more service function endpoints (SFEs) using a programmable application programming interface (API), implementing the API as programmable middleware, and registering each of the one or more SFEs with a respective identifier according to a service description in the programmable middleware.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] Cross - reference to Related Applications This application claims the benefit and priority of U.S. Provisional Patent Application No. 63 / 024,903, filed with the United States Patent and Trademark Office on May 14, 2020, the entire content of which is hereby incorporated by reference herein in its entirety as if fully set forth below and for all applicable purposes.

Summary of the Invention

[0002] The present disclosure generally relates to wireless and / or wired communication networks. For example, one or more embodiments disclosed herein relate to methods and apparatuses for the transparent exchange of service function identifiers. For example, the transparent exchange of service function identifiers can be used for dynamic end - to - end slicing and / or re - orchestration of a service function chain (SFC).

[0003] In one embodiment, a method of using a service function identifier for wireless communication may include transmitting configuration information to one or more service function endpoints (SFEs) using a programmable application programming interface (API), implementing the API as programmable middleware, and registering each of the one or more SFEs using its respective identifier according to a service description in the programmable middleware. The method may also include, for each respective SFE, using the programmable middleware to map a destination service function (SF) name to a service function identifier (SFID). The method may further include determining that a mapping between a service function (SF) name and a first SFID has changed and updating the mapping with a second SFID to map the SF name.

Brief Description of the Drawings

[0004] A more detailed understanding can be obtained from the following detailed description given by way of example in conjunction with the drawings attached hereto. The figures of such drawings, like the detailed description, are examples. Accordingly, the figures and the detailed description should not be regarded as limiting, and other equally effective examples are possible and likely. Further, like reference numerals in the figures indicate like elements.

Figure 1A

Figure 1B

Figure 1C

Figure 1D

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

[0005] In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the embodiments and / or examples disclosed herein. However, it will be understood that such embodiments and examples may be practiced without some or all of these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to obscure the following description. Further, embodiments and examples not specifically described herein may be practiced in lieu of, or in combination with, the embodiments and other examples explicitly, implicitly, and / or inherently (collectively "provided") described, disclosed, or otherwise provided herein. In this specification, various embodiments are described and / or claimed in which an apparatus, system, device, etc. and / or any element thereof performs various operations, processes, algorithms, functions, etc. and / or any part thereof, but it should be understood that any embodiment described and / or claimed herein assumes that any apparatus, system, device, etc. and / or any element thereof is configured to perform any operation, process, algorithm, function, etc. and / or any part thereof.

[0006] One or more embodiments disclosed herein relate to methods and apparatuses for the transparent exchange of service function identifiers. In one embodiment, methods and apparatuses are provided for the transparent exchange of service function identifiers for dynamic end-to-end slicing and / or reorchestration of a service function chain (SFC).

[0007] Communication Networks and Devices The methods, apparatuses, and systems provided herein are well-suited for communications involving both wired and wireless networks. Wired networks are well-known. An overview of various types of wireless devices and infrastructure is provided with respect to FIGS. 1A-1D, and the various elements of the network can be utilized, executed, arranged, and / or adapted and / or configured for the methods, apparatuses, and systems provided herein.

[0008] FIG. 1A is a diagram illustrating an exemplary communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 can be a multiple access system that provides content such as voice, data, video, messaging, broadcast, etc. to a plurality of wireless users. The communication system 100 can enable a plurality of wireless users to access the content as described above through sharing of system resources including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique-word DFT-Spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multicarrier (FBMC), etc.

[0009] As shown in FIG. 1A, the communication system 100 can include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RANs 104 / 113, CNs 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it is understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d can be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, which may be referred to interchangeably as a “station” and / or “STA,” can be configured to transmit and / or receive wireless signals and can be a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscriber-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable head-mounted display (HMD), a vehicle, a drone, a medical device and application (e.g., remote surgery), an industrial device and application (e.g., a robot and / or other wireless device operating in an industrial and / or automated processing chain context), a home appliance device, a device operating in a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d can be referred to interchangeably as a UE.

[0010] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as CN106 / 115, Internet 110, and / or other network 112. By way of example, base stations 114a, 114b may be a base transceiver station (BTS), Node B, eNodeB, home Node B, home eNodeB, gNB, New Radio (NR) Node B, site controller, access point (AP), wireless router, etc. Although base stations 114a, 114b are each shown as a single element, it will be understood that base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0011] Base station 114a can be part of RAN 104 / 113 and can also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, etc. Base station 114a and / or base station 114b can be configured to transmit and / or receive radio signals at one or more carrier frequencies, which can be referred to as a cell (not shown). These frequencies can be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. The cell can provide wireless service coverage to a specific geographic area that can be relatively fixed or can change over time. The cell can be further divided into cell sectors. For example, the cell associated with base station 114a can be divided into three sectors. Thus, in one embodiment, base station 114a can include three transceivers, for example, one transceiver per sector of the cell. In one embodiment, base station 114a can employ multiple-input multiple output (MIMO) technology and can utilize multiple transceivers per sector of the cell. For example, beamforming can be used to transmit and / or receive signals in a desired spatial direction.

[0012] Base stations 114a, 114b can communicate with one or more of WTRUs 102a, 102b, 102c, 102d via air interface 116, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, millimeter wave, infrared (IR), ultraviolet (UV), visible light, etc.). Air interface 116 can be established using any suitable radio access technology (RAT).

[0013] More specifically, as described above, the communication system 100 can be a multiple access system and can employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base stations 114a within RAN104 / 113, and the WTRUs 102a, 102b, 102c can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can establish the air interfaces 115 / 116 / 117 using wideband CDMA (WCDMA). WCDMA can include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High-Speed Downlink Packet Access (HSDPA) and / or High-Speed UL Packet Access (HSUPA).

[0014] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement radio technologies such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which can establish the air interface 116 using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-A Pro).

[0015] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can establish the air interface 116 using New Radio (NR).

[0016] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for example, using the dual connectivity (DC) principle. Accordingly, the air interfaces utilized by WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies transmitted to / from multiple types of base stations (e.g., eNBs and gNBs) and / or transmissions.

[0017] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c may implement wireless technologies such as IEEE 802.11 (e.g., Wireless Fidelity (WiFi)), IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0018] The base station 114b in FIG. 1A can be, for example, a wireless router, a home Node B, a home eNodeB, or an access point, and can utilize any suitable RAT to facilitate wireless connection in a local area such as an office, a home, a vehicle, a campus, an industrial facility, an aerial corridor (for use by drones, for example), a road, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d can implement a wireless technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d can implement a wireless technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d can utilize a cellular-based RAT (such as WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a pico cell or a femto cell. As shown in FIG. 1A, the base station 114b can have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 via the CN 106 / 115.

[0019] RAN 104 / 113 may communicate with CN 106 / 115, which may be any type of network configured to provide voice, data, application, and / or voice over internet protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, 102d. The data may have various quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, internet connectivity, video delivery, etc., and / or may perform high-level security functions such as user authentication. Although not shown in Figure 1A, it will be understood that RAN 104 / 113 and / or CN 106 / 115 may communicate directly or indirectly with other RANs that employ the same or a different radio access technology (RAT) as RAN 104 / 113. For example, in addition to being connected to RAN 104 / 113, which may utilize New Radio (NR) radio technology, CN 106 / 115 may also communicate with another RAN (not shown) that employs GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0020] CN106 / 115 may also function as a gateway for WTRU102a, 102b, 102c, 102d to access the PSTN108, the Internet 110, and / or other networks 112. The PSTN108 may include a public switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices, where these networks and devices use common communication protocols such as the transmission control protocol (TCP), the user datagram protocol (UDP), and / or the internet protocol (IP) of the TCP / IP internet protocol suite. The network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the network 112 may include another CN connected to one or more RANs that may employ the same or a different RAT as the RAN104 / 113.

[0021] Some or all of the WTRU102a, 102b, 102c, 102d in the communication system 100 may include multimode capabilities (e.g., the WTRU102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). For example, the WTRU102c shown in Figure 1A may be configured to communicate with a base station 114a that may employ a cellular-based wireless technology and a base station 114b that may employ IEEE802 wireless technology.

[0022] Figure 1B is a system diagram showing an exemplary WTRU 102. As shown in Figure 1B, the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, a non-removable memory 130, a removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and / or other peripheral devices 138. It will be understood that the WTRU 102 may include any partial combination of the foregoing elements while remaining consistent with one embodiment.

[0023] The processor 118 can be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 can perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 can be coupled to a transceiver 120 that can be coupled to a transmit / receive element 122. Although Figure 1B shows the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 can be integrated together in an electronic package or chip.

[0024] The transmit / receive element 122 may be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via the air interface 116. For example, in one embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In one embodiment, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF signals and optical signals. It will be understood that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0025] Although the transmit / receive element 122 is shown in FIG. 1B as a single element, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via the air interface 116.

[0026] The transceiver 120 may be configured to modulate signals transmitted by the transmit / receive element 122 and demodulate signals received by the transmit / receive element 122. As noted above, the WTRU 102 may have multimode capabilities. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs such as, for example, NR and IEEE 802.11.

[0027] The processor 118 of the WTRU 102 may be coupled to the speaker / microphone 124, keypad 126, and / or the display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light-emitting diode (OLED) display unit), and may receive user input data therefrom. The processor 118 may also output user data to the speaker / microphone 124, keypad 126, and / or the display / touchpad 128. Further, the processor 118 may access information from and store data in any suitable type of memory, such as the non-removable memory 130 and / or the removable memory 132. The non-removable memory 130 may include a random-access memory (RAM), read-only memory (ROM), hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, memory stick, secure digital (SD) memory card, etc. In other embodiments, the processor 118 may access information from and store data in a memory that is not physically located on the WTRU 102, such as on a server or home computer (not shown).

[0028] The processor 118 may receive power from the power supply 134 and may be configured to distribute and / or control power to other components within the WTRU 102. The power supply 134 may be any suitable device for supplying power to the WTRU 102. For example, the power supply 134 may include one or more dry cells (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, etc.

[0029] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the location of the WTRU 102. In addition to or instead of information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) via the air interface 116 and / or may determine its location based on the timing of signals received from two or more nearby base stations. It will be understood that the WTRU 102 may obtain location information by any suitable location determination method while remaining consistent with one embodiment.

[0030] The processor 118 may further be coupled to other peripheral devices 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connections. For example, the peripheral devices 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, etc. The peripheral devices 138 may include one or more sensors, which may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

[0031] The WTRU 102 may include a full-duplex radio in which transmission and reception of some or all of the signals (e.g., associated with specific subframes for both UL (e.g., for transmission) and downlink (e.g., for reception)) may be parallel and / or simultaneous. The full-duplex radio may include an interference management unit 139 for reducing and / or substantially eliminating self-interference either via hardware (e.g., a choke) or via signal processing (e.g., via a separate processor (not shown) or via processor 118). In one embodiment, the WRTU 102 may include a half-duplex radio for transmission and reception of some or any of all of the signals (e.g., associated with specific subframes for either UL (e.g., for transmission) or downlink (e.g., for reception)).

[0032] Figure 1C is a system diagram showing the RAN 104 and the CN 106 according to one embodiment. As described above, the RAN 104 may employ E-UTRA radio technology and communicate with the WTRU 102a, 102b, 102c via the air interface 116. The RAN 104 may also communicate with the CN 106.

[0033] The RAN 104 may include eNode-Bs 160a, 160b, 160c, although it will be understood that the RAN 104 may include any number of eNode-Bs while remaining consistent with one embodiment. Each of the eNode-Bs 160a, 160b, 160c may include one or more transceivers for communicating with the WTRU 102a, 102b, 102c via the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a may transmit a radio signal to and / or receive a radio signal from the WTRU 102a, for example, using multiple antennas.

[0034] Each of eNode-Bs 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling, etc. in UL and / or DL. As shown in Figure 1C, eNode-Bs 160a, 160b, and 160c can communicate with each other via the X2 interface.

[0035] CN 106 shown in Figure 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. Although each of the foregoing elements is shown as part of CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0036] MME 162 can be connected to each of eNode-Bs 160a, 160b, and 160c within RAN 104 via the S1 interface and can function as a control node. For example, MME 162 can authenticate users of WTRUs 102a, 102b, and 102c, activate / deactivate bearers, and select a gateway in a specific service during the initial attach of WTRUs 102a, 102b, and 102c. MME 162 can provide control plane functions for switching between RAN 104 and other RANs (not shown) that employ other radio technologies such as GSM and / or WCDMA.

[0037] The SGW 164 can be connected to each of the eNode-Bs 160a, 160b, and 160c within the RAN 104 via the S1 interface. The SGW 164 can generally route and transfer user data packets to / from the WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions such as anchoring the user plane during an eNode B handover, triggering paging when DL data is available to the WTRUs 102a, 102b, and 102c, and managing and storing the contexts of the WTRUs 102a, 102b, and 102c.

[0038] The SGW 164 can be connected to the PGW 166, and the PGW 166 can provide the WTRUs 102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between the WTRUs 102a, 102b, and 102c and IP-compatible devices.

[0039] The CN 106 can facilitate communication with other networks. For example, the CN 106 can provide the WTRUs 102a, 102b, and 102c with access to a circuit-switched network such as the PSTN 108 to facilitate communication between the WTRUs 102a, 102b, and 102c and conventional landline communication devices. For example, the CN 106 can include or communicate with an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that functions as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 can provide the WTRUs 102a, 102b, and 102c with access to other networks 112, and the other networks 112 can include other wired and / or wireless networks owned and / or operated by other service providers.

[0040] The WTRU is described as a wireless terminal in FIGS. 1A - 1D, but in certain representative embodiments, it is contemplated that such a terminal can use a wired communication interface (e.g., temporarily or permanently) with a communication network.

[0041] In an exemplary embodiment, the other network 112 may be a WLAN.

[0042] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) of the BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to another type of wired / wireless network that carries traffic entering and / or exiting the distribution system (DS) or BSS. Traffic to an STA originating outside the BSS may reach and be delivered to the STA through the AP. Traffic originating from an STA and destined for a destination outside the BSS may be sent to the AP and delivered to each destination. Traffic between STAs within the BSS may be transmitted, for example, via the AP, where the source STA may send the traffic to the AP and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be transmitted in a direct link setup (DLS) between the source STA and the destination STA (e.g., directly between them). In certain exemplary embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (e.g., all of the STAs) may communicate directly with each other. The IBSS mode of communication may be referred to herein as the "ad hoc" communication mode.

[0043] When using the 802.11ac infrastructure operation mode or a similar operation mode, the AP may transmit beacons on a fixed channel such as the primary channel. The primary channel can be of a fixed width (e.g., a 20 MHz bandwidth) or a width dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In certain representative embodiments, for example, in an 802.11 system, Carrier Sense Multiple Access / Collision Avoidance (CSMA / CA) with collision avoidance can be implemented. In the case of CSMA / CA, STAs including the AP (e.g., all STAs) can sense the primary channel. If the primary channel is sensed / detected as busy by a particular STA and / or determined to be so, the particular STA can back off. Only one STA (e.g., only one station) can transmit at any given time in a given BSS.

[0044] A High Throughput (HT) STA can form a 40 MHz wide channel for communication, for example, via a combination of a primary 20 MHz channel and an adjacent or non - adjacent 20 MHz channel.

[0045] A Very High Throughput (VHT) STA may support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. The above-mentioned 40 MHz and / or 80 MHz wide channels may be formed by combining consecutive 20 MHz channels. A 160 MHz channel may be formed by combining eight consecutive 20 MHz channels or by combining two non-consecutive 80 MHz channels, which may be referred to as an 80+80 configuration. In the case of the 80+80 configuration, after channel coding, the data may pass through a segment parser that can split the data into two streams. The Inverse Fast Fourier Transform (IFFT) process and time domain processing may be performed separately for each stream. The streams may be mapped to two 80 MHz channels and the data may be transmitted by the transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration can be reversed, and the combined data can be transmitted to the Medium Access Control (MAC).

[0046] The sub-1 GHz operating mode is supported by 802.11af and 802.11ah. The channel operating bandwidth and carriers are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using the non-TVWS spectrum. According to an exemplary embodiment, 802.11ah may support meter type control / machine type communication, such as MTC devices within a macro coverage area. The MTC device may have limited capabilities, including certain capabilities, for example, support for a certain and / or limited bandwidth (e.g., support only therefor). The MTC device may include a battery having a battery life exceeding a threshold (e.g., to maintain a very long battery life).

[0047] WLAN systems that can support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include channels that can be designated as primary channels. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or restricted by an STA from among all STAs operating in a BSS that supports the minimum bandwidth operation mode. In the example of 802.11ah, the primary channel can be 1 MHz wide for an STA (e.g., an MTC type device) that supports the 1 MHz mode (e.g., supports only that) even when the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operation modes. Carrier sensing and / or Network Allocation Vector (NAV) setting can depend on the state of the primary channel. For example, if the primary channel is busy due to an STA transmitting to the AP (supporting only the 1 MHz operation mode), the entire available frequency band can be considered busy even though most of the frequency band remains idle and available.

[0048] In the United States, the available frequency band that can be used by 802.11ah is 902 MHz to 928 MHz. In Korea, the available frequency band is 917.5 MHz to 923.5 MHz. In Japan, the available frequency band is 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11ah is 6 MHz to 26 MHz depending on the country code.

[0049] FIG. 1D is a system diagram showing RAN 113 and CN 115 according to one embodiment. As described above, RAN 113 can communicate with WTRUs 102a, 102b, 102c via air interface 116 using NR radio technology. RAN 113 can also communicate with CN 115.

[0050] RAN 113 may include gNBs 180a, 180b, and 180c, but it will be understood that RAN 113 may include any number of gNBs while remaining consistent with one embodiment. Each of gNBs 180a, 180b, and 180c may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 108b may use beamforming to transmit and / or receive signals to / from gNBs 180a, 180b, and 180c. Thus, gNB 180a, for example, may transmit a radio signal to WTRU 102a and / or receive a radio signal from WTRU 102a using multiple antennas. In one embodiment, gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB 180a may transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum and the remaining component carriers may be on licensed spectrum. In one embodiment, gNBs 180a, 180b, and 180c may implement coordinated multi-point (CoMP) technology. For example, WTRU 102a may receive coordinated transmission from gNB 180a and gNB 180b (and / or gNB 180c).

[0051] WTRUs 102a, 102b, and 102c may communicate with gNBs 180a, 180b, and 180c using transmissions associated with scalable numerology. For example, the OFDM symbol interval and / or the OFDM subcarrier interval may vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c may communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., including various numbers of OFDM symbols and / or having absolute times of various lengths).

[0052] gNBs 180a, 180b, and 180c may be configured to communicate with WTRUs 102a, 102b, and 102c in a stand-alone configuration and / or a non-stand-alone configuration. In a stand-alone configuration, WTRUs 102a, 102b, and 102c may communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., eNode-Bs 160a, 160b, and 160c, etc.). In a stand-alone configuration, WTRUs 102a, 102b, and 102c may utilize one or more of gNBs 180a, 180b, and 180c as a mobility anchor point. In a stand-alone configuration, WTRUs 102a, 102b, and 102c may communicate with gNBs 180a, 180b, and 180c using signals in an unlicensed band. In a non-stand-alone configuration, WTRUs 102a, 102b, and 102c may communicate with and connect to gNBs 180a, 180b, and 180c while also communicating with and connecting to another RAN such as eNode-Bs 160a, 160b, and 160c. For example, WTRUs 102a, 102b, and 102c may implement a DC principle for communicating with one or more gNBs 180a, 180b, and 180c and one or more eNode-Bs 160a, 160b, and 160c substantially simultaneously. In a non-stand-alone configuration, eNode-Bs 160a, 160b, and 160c may function as a mobility anchor for WTRUs 102a, 102b, and 102c, while gNBs 180a, 180b, and 180c may provide additional coverage and / or throughput for servicing WTRUs 102a, 102b, and 102c.

[0053] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, support for network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data to user plane functions (UPFs) 184a, 184b, and routing of control plane information to access and mobility management functions (AMFs) 182a, 182b, etc. As shown in FIG. 1D, gNBs 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0054] CN 115 shown in FIG. 1D can include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and optionally data networks (DNs) 185a, 185b. Although each of the foregoing elements is shown as part of CN 115, it will be understood that any of these elements can be owned and / or operated by entities other than the CN operator.

[0055] AMF 182a and 182b can be connected to one or more of gNBs 180a, 180b, and 180c within RAN 113 via the N2 interface and can function as control nodes. For example, AMF 182a and 182b can play roles such as authentication of users of WTRUs 102a, 102b, and 102c, support for network slicing (e.g., handling of different PDU sessions with different requirements), selection of specific SMFs 183a and 183b, management of registration areas, termination of NAS signaling, and mobility management. Network slices can be used by AMF 182a and 182b to customize the CN support for WTRUs 102a, 102b, and 102c based on the type of services being utilized by WTRUs 102a, 102b, and 102c. For example, different network slices can be established for different use cases such as services that rely on ultra-reliable low latency (URLLC) access, services that rely on enhanced massive mobile broadband (eMBB) access, and services for machine type communication (MTC) access. AMF 182 can provide control plane functions for switching between RAN 113 and other RANs (not shown) that employ other radio technologies such as non-3GPP access technologies like LTE, LTE-A, LTE-A Pro, and / or WiFi.

[0056] SMF183a and 183b can be connected to AMF182a and 182b within CN115 via the N11 interface. SMF183a and 183b can also be connected to UPF184a and 184b within CN115 via the N4 interface. SMF183a and 183b can select and control UPF184a and 184b and configure the routing of traffic passing through UPF184a and 184b. SMF183a and 183b can perform other functions such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. The PDU session type can be IP-based, non-IP-based, Ethernet-based, etc.

[0057] UPF184a and 184b can be connected to one or more of gNB180a, 180b, and 180c within RAN113 via the N3 interface, which can provide access to a packet-switched network such as the Internet 110 to WTRU102a, 102b, and 102c to facilitate communication between the WTRU102a, 102b, and 102c and IP-corresponding devices. UPF184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-home PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring.

[0058] CN115 may facilitate communication with other networks. For example, CN115 may include or communicate with an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that functions as an interface between CN115 and PSTN108. Further, CN115 may provide access to other network 112 for WTRU102a, 102b, 102c, and other network 112 may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRU102a, 102b, 102c may be connected to local data network (DN) 185a, 185b through UPF184a, 184b via an N3 interface to UPF184a, 184b and an N6 interface between UPF184a, 184b and DN185a, 185b.

[0059] In view of FIGS. 1A-1D and the corresponding descriptions of FIGS. 1A-1D, one or more of the functions described herein with respect to one or more of WTRU102a-d, base stations 114a-b, eNode-Bs 160a-c, MME162, SGW164, PGW166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other devices described herein may be performed by one or more emulation devices (not shown). An emulation device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functionality.

[0060] An emulation device can be designed to implement one or more tests of other devices in a laboratory environment and / or an operator network environment. For example, one or more emulation devices can be fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices within the communication network and can execute one or more or all functions while being deployed. One or more emulation devices can execute one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. An emulation device can be directly coupled to another device for testing purposes and / or can execute tests using terrestrial wireless communication.

[0061] One or more emulation devices can execute one or more functions including all while not being implemented / deployed as part of a wired and / or wireless communication network. For example, an emulation device can be utilized in a test scenario in a test laboratory and / or in a wired and / or wireless communication network that is not deployed (e.g., for testing) to implement tests of one or more components. One or more emulation devices can be test equipment. Direct RF coupling and / or wireless communication via an RF circuit (which can include one or more antennas) can be used by an emulation device to transmit and / or receive data.

[0062] Service Function Chaining Service functions (SFs) are widely deployed and essential in many networks. SFs can provide various features such as security, wide area network (WAN) acceleration, and / or server load distribution. SFs can be instantiated at one or more different points within network infrastructures such as data centers, WANs, core networks (CNs), RANs, etc., and at mobile nodes or devices (e.g., WTRUs or UEs).

[0063] A virtualized network function (VNF), or software function (SF) as it is also referred to, is hosted on computing, storage, and networking resources. SFs are becoming more prevalent even in traditional closed environments such as cellular networks that currently incorporate cloud-native technologies. Thus, in some 5G-based systems, SFs may be referred to as network function services (or NF services), and these NF services can be accessed using mainstream Internet protocols such as the Hypertext Transfer Protocol (HTTP). The hosting environment for the functions disclosed herein is referred to as a service function provider or a Network Function Virtualization (NFV) Infrastructure Point of Presence (NFVI-PoP) (e.g., using ETSI NFV terminology). Services are typically formed as a combination of SFs (or VNFs), and each SF provides a specific function of the overall service. Services may also be referred to as network services (NS), for example, according to ETSI terminology.

[0064] A communication system designed to enable highly dynamic service orchestration and lifecycle changes needs to meet one or more of the following criteria to deliver on the promises of 5G and / or future systems.

[0065] Service-based system architecture. The migration from monolithic functions to microservices (represented as instances of services that can be requested through application programming interfaces (APIs)) is one of the important changes in the system architecture for telecommunications systems. To deliver highly scalable services, service-based system architectures, such as the 5G 3GPP enhanced Service-based Architecture (eSBA) work, have been introduced in telecommunications.

[0066] Service routing - The routing of packets between service instances must enable timely endpoint selection and reselection, and thus enable end-to-end slicing of network resources.

[0067] Cloud-native orchestration - The orchestration of microservices that is managed to optimize resource utilization independently of the underlying infrastructure or platform.

[0068] End-to-end (E2E) slicing - The slicing of the network (as well as computing resources) is one of the 5G features enabled by programmable infrastructure. The computing resources are "sliced" according to cloud-native orchestration principles, and while network resources are the focus of this effort, access to these resources does not necessarily require additional tagging of packets with additional headers / information in addition to the already "sliced" computing and storage resources, for example, using IP flows, VLANs, MPLS. When using name-based routing, there is no longer a need to further slice the switching fabric at layer 2.5 or 3 and it is no longer required. Nevertheless, it does not rule out the ability to additionally tag each name-based slice.

[0069] For consistent terminology throughout this disclosure, when considering typical client-server principles, the following conventions are used to describe services and their instances. · Client: An entity that requests a service from a server and is also described as an endpoint. · Server: An entity that processes requests sent from a client and is described as a service endpoint. For example, a Network Function Service (NFS) (e.g., in 3GPP or 5G) or an IETF Service Function (SF) can be considered a service endpoint. · Service Function Endpoint (SFE): A deployed instance of a service function, equivalent to a 5G 3GPP CP network function service instance.

[0070] When referring to 3GPP (e.g., eSBA features), legacy monolithic network elements are decomposed into functional entities called network functions (NFs). Subsequently, further refinement was achieved using the introduction of network function services (NFS) and network function service instances. As described above, a network function service (NFS) can be considered a service endpoint. In 3GPP 5G, these concepts apply only to the Control Plane (CP), leaving the User Plane (UP) for further consideration.

[0071] However, the cloud-native orchestration principle requires a more refined distinction between service endpoints / network function services and their instances for both CP and UP. For this purpose, the work in the Service Function Chaining (SFC) IETF group forms the basis of the cloud-native orchestration principle for services in telecommunications systems. This group defines a service function chain composed of service functions (SFs), where a service function (SF) has a 1:n relationship with the deployed instances of the SF defined as service function endpoints (SFEs). For example, an SF can be associated with one or more SFEs (e.g., n SFEs) in a service function chain. Since HTTP is the de facto application layer protocol for all endpoints to communicate, fully qualified domain names (FQDNs) are used to identify service functions. FQDNs are also described as service function identifiers (SFIDs). In some cases, when HTTP is not the application layer protocol, the SFID does not have to be an FQDN.

[0072] Figure 2 shows a high-level system diagram of a service-based communication system that includes service routing and orchestration and a service function chain that is orchestrated across three orchestrateable compute resources (OCRs) OCR1, OCR2, and OCR3 and two SFs, SF1 and SF2. The resulting deployed SFEs are labeled as SFE <SF_ID>,<INSTANCE_ID> where <SF_ID> is the numerical identifier of the service function (SF1 or SF2) and <INSTANCE_ID> is the numerical identifier of an instance of a particular SF. In the following example, SF1 is labeled as SFE 1,1 and deployed once on OCR1, and SF2 is deployed as two instances (SFEs) SFE on OCR2 and OCR3 respectively2,1 and SFE 2,2 is deployed as. SFE 1,1 When SFE is intended to communicate with SF2 (either of the two deployed instances), service routing can determine where to route the packets based on the capabilities that the routing platform must provide.

[0073] In various embodiments, OCR can be a computing node managed by an infrastructure provider / operator or a terminal (e.g., a WTRU or UE). An example of a service function chain shown in the upper right of FIG. 2 (a service function chain with two SFs, SF1 and SF2) is used over the two examples given below.

[0074] FIG. 3 shows a scenario when SF1 reaches SF2 via FQDN sfe2.foo.com. In this example, service routing determines to use SFE 1,1 as the instance of SF2 that provides services to SFE 2,1 However, in the case of a private (non-public) network scenario, it may be desirable to enforce the use of a particular SFE or set of SFEs based on a certain context, such as regional preference, time, or privacy concerns. This action, defined as pinning, uses a (temporary) SFID that is the original SFID with a prefix prepended (e.g.,) to enforce that SFE 2,1 provides services to SFE 1,1 A method and procedure for performing name-based slicing using a new SFID (e.g., FQDN) are described. In the following example, SFID sf2.foo.com is prepended by sfe1 and sfe1.sf2.foo.com is obtained.

[0075] Figure 4 shows a scenario when the entire service function chain is reorchestrated due to a change in the number of SFs that make up the chain. Instead of SF1 and SF2, SF2 is further decomposed into SF3 and other SFs, which results in a chain relationship of SF1>SF3>SF instead of SF1>SF2. The left subfigure of Figure 4 shows the initial communication between SFE using SFID sf2.foo.com and SFE n and SFE 1,1 and SFE 2,1 and SFE 3,1 is shown in the center of Figure 4, where the new SF, SF3, is being deployed as SFE 3,1 After that, SFE 1,1 is registered with the service routing using the new SFID sf3.foo.com, and this new SFID must then be communicated to all instances of SF1 (e.g., SFE

[0076] ) for use in any future HTTP transactions going to SF2.In both scenarios shown in FIGS. 3 and 4, there remains the problem of how the SFE recognizes that one or more SFEs are no longer reachable and that it is necessary to use a new SFE with a new SFID. Even if the SFE can query the orchestrator for information about itself, such as the chain name, service function name, or parent domain, in order to construct the SFID for the next SF, any change to the SFID for reaching the next SF is not programmable at that point and, thus, a runtime update of the SFE's SFID cannot be achieved. Each component within the service function is programmed to reach the next SF in the chain using a hard-coded name such as sf1. Some network platforms may implement an interface for querying the parent domain, such as foo.com, in which the entire service chain is deployed. If the entire chain is reorchestrated at runtime, code changes are not executable. This applies to pinning an SFE to a specific instance of another SF (pinning). Further, SFID updates should be made as transparent as possible to the service itself and should not affect the application developer and their code development workflow.

[0077] Transparent Exchange of Service Function Identifiers In various embodiments, middleware and programmable APIs for service function endpoints (network service functions) are used so that an application can program the service function identifier (FQDN) to the active instance without the need to change the code or socket communication.

[0078] When an application that requires an HTTP library is written, modern libraries, when receiving a request from the application to send a request to a host, perform one or more of the following steps. In one embodiment, if the host is an FQDN, the library may perform a DNS lookup to establish the IP address of the service endpoint that provides the service to the FQDN. The IP address library may be used to establish a session using the transport layer protocol selected towards the service endpoint.

[0079] In various embodiments, since the application developer is done by library calls, the application does not include functions for performing dedicated actions for DNS lookups and TCP socket creation / processing. One or more embodiments described below do not impose special requirements on the application developer other than calling another library. As a result, programmable middleware is proposed, which becomes part of an existing widely used library or such middleware is provided to the developer as an additional cross-system simulation layer (library). As described above, a change in the SFID usually requires an update of the application itself. The proposed solution introduces a programmable interface and its procedure that enables remote programming of the SFID across the SFE without any change to the application itself. A schematic diagram of the present disclosure is given in FIG. 5, which shows an authority entity having access to a programmable API on the left side and a proposed OSI layer of a service function endpoint having new middleware between the application and the transport layer on the right side. The present disclosure removes the need for the application to resolve the FQDN and establish a transport layer session, but these steps can still be performed and are moved to the middleware itself.

[0080] Both the programmable middleware API and the middleware itself are described in more detail below.

[0081] Middleware As shown in FIG. 6, the proposed middleware is composed of an application library having name-based I / O calls and a programmable lookup table. The application uses the middleware library and its I / O call function send() to send data to another SF via a transaction. Compared with standard library calls that require an FQDN or IP address (or SFID), the proposed library only requires the name of the SF to send data. Further, the registration function reg() is available to enable the application to communicate their service function names.

[0082] The send I / O call requires a connection property argument connProp that notifies the middleware about information regarding the configuration of the lower OSI layer. A complete list of the connProp fields is given in Table 1. In some examples, by putting the connProp argument in each send call, the same application can be enabled to initiate different types of transactions, such as HTTP, HTTP / 2, or SIP.

[0083] [Table 1]

[0084] The middleware may maintain a lookup table that maps the destination SF name to an SFID (such as an FQDN or IP address). When an SFID update arrives, the middleware updates the lookup table without the application having knowledge thereof. Upon such an update, the middleware checks for active sessions still using the old SFID and either terminates their transactions or, if the application layer protocol allows such behavior, forces a transparent switch to the new SFID. In some examples, the policy of whether to wait or switch immediately is communicated via a programmable API.

[0085] When a new transaction request is issued by the application, the middleware can search for the destination SF name given in the send() call and the middleware can find the SFID to replace the value within the request packet. For example, in the case of HTTP as the application layer protocol, the middleware can replace the value of the HTTP header field Host with the SFID, which is obtained by the middleware from its lookup table. The actual packet, including the header and payload, can be constructed by the application itself.

[0086] When aiming for access control for end-to-end slices, the middleware may implement this feature using the lookup table. Since all applications must first register with their middleware, the lookup table can also be programmed to enforce that only certain service functions are permitted to call send() to other SFs. As shown in Figure 6, the field SR SRC has either a wildcard (asterisk) or the name of an SF permitted to communicate with another SF.

[0087] Programmable middleware interface In various embodiments, a new interface is introduced that enables the orchestrator to communicate such changes to each operable SFE in order to communicate changes to the SFID of an SF. The present disclosure includes aspects of programmability that enable the orchestrator to deploy changes quickly. The interface may enable any of these actions.

[0088] Addition: A new SF name and SFID are communicated to the SFE's middleware.

[0089] Update: The SF and SFID are communicated to the SFE's middleware, including policies on how to handle ongoing application transactions for the old SFID.

[0090] Deletion: A pair consisting of an SF name and its SFID is deleted from the lookup table, including any exchange policies that may have been communicated.

[0091] The interface may be implemented as a CRUD service endpoint that uses HTTP as the application protocol. The middleware listens on a predefined and globally available transport layer port. In some examples, Internet Assigned Numbers Authority (IANA) port definitions may be used or applied for the transport layer port.

[0092] [Table 2]

[0093] The API may be used to submit a single action or a concatenation of actions. The following example uses json as the payload format for an HTTP POST command to populate information, as shown in FIG. 6.

[0094]

Table 3

[0095] To demonstrate the middleware method and procedure, the pinning use case of SFE (e.g., as shown in FIG. 3) is used. FIG. 7 shows two service functions SF1 and SF2, where SF1 is deployed once as SFE 1,1 and SF2 is deployed twice as SFE 2,1 and SFE 2,2 . Both SFEs (SFE 2,1 and SFE 2,2 ) are registered for service routing using SFIDsf2.foo.com. SFE 1,1 is intended to start a new transaction with SF2, and the service routing determines which SFE 2,x to select. The application representing SF1 registers itself with its middleware, and SFIDsf2.foo.com is programmed for the destination SF name of sf2. Since the SF2 application does not start a transaction and only acts as a service endpoint, the other middleware lookup tables are empty.

[0096] When SFE 1,1 sends a request to an SF having a name sf2 mapped to SFIDsf2.foo.com as the source SF field, SF SRC includes a wildcard. When the request uses HTTP, the middleware operates on the value of the HTTP header field Host from sf2 to the SFID in the lookup table before the request exits the SFE communication stack. Next, the service routing determines to route the request to SFE 2,1 . Then, SFE 2,1 can handle the request and respond accordingly.

[0097] The next transaction is for SFE1,1 Before being initialized by 1,1 (or service routing), SFE 1,1 can be determined to pin SFE 2,2 to SFE 1,1 This is achieved by using the unique SFID sf1.sf2.foo.com programmed into the middleware of SFE

[0098] When the following request is sent to the service endpoint named sf2 by SFE 1,1 the middleware, if HTTP is used as the OSI layer 7 protocol, re - operates on the HTTP header and then finds the new FQDN in its lookup table and issues the request to this SFID. Since only SFE 2,2 is registered with this FQDN for service routing, the request is routed to the SFE 2,2 that is serving it. On SFE 1,1 only the applications initially registered with the name sf1 can have middleware that maps them to the pinned FQDN that enables access control for the end - to - end slice.

[0099] In various embodiments, methods and apparatuses are provided for the transparent exchange of service function identifiers. For example, the transparent exchange of service function identifiers can be used for dynamic end - to - end slicing and / or re - orchestration of service function chains (SFCs).

[0100] In one embodiment, a method for wireless communication may include transmitting configuration information to one or more service function endpoints (SFEs) using a programmable application programming interface (API), implementing the API as programmable middleware, and registering each of the one or more SFEs using their respective identifiers according to a service description in the programmable middleware. The method may also include, for each respective SFE, mapping a destination service function (SF) name to a service function identifier (SFID) using the programmable middleware. The method may further include determining that a mapping between a service function (SF) name and a first SFID has changed and updating the mapping with a second SFID to map the SF name.

[0101] In one embodiment, the method described herein may further include receiving one or more programmable updates from a chain operation entity. The chain operation entity may be an authority entity and / or an orchestrator. The one or more programmable updates may include a service description.

[0102] In one embodiment, the service description is a description associated with a service function chain (SFC).

[0103] In one embodiment, the method described herein may be implemented in a wireless transmit / receive unit (WTRU) that operates as an SFE among one or more SFEs and communicates with other SFEs among the one or more SFEs by name.

[0104] In one embodiment, the method described herein may also include determining that one or more SFs have been re-chained and updating the mapping from the SF name to the SFID based on the determination.

[0105] In one embodiment, any of the SFIDs, the first SFID, or the second SFID is a fully qualified domain name (FQDN) or an IP address. The identifier may be an FQDN or an IP address. The SF name may also be an FQDN or an IP address.

[0106] In one embodiment, the methods described herein may also include remotely programming a lookup table of programmable middleware using a programmable API.

[0107] Each of the following references is hereby incorporated by reference herein: rd Generation Partnership Project (3GPP), "System architecture for the 5G System (5GS), v16.0.0, TS 23.501", 2019; PCT International Publication No. WO 2019 / 222703; and InterDigital, "Next Generation Networks: Flexible Routing and Services", https: / / www.interdigital.com / solution / next-generation-networks.

[0108] The features and elements are described above in specific combinations, but one of ordinary skill in the art will understand that each feature or element can be used alone or in any combination with other features and elements. Further, the methods described herein may be implemented in a computer program, software, or firmware incorporated into a computer-readable medium for execution by a computer or processor. Examples of non-transitory computer-readable storage media include, but are not limited to, magnetic media such as read only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, internal hard disks, and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A radio frequency transceiver for use in a WTRU102, UE, terminal, base station, RNC, or any host computer may be implemented using a processor associated with software.

[0109] Furthermore, in the above embodiments, other devices including a processing platform, computing system, controller, and processor are described. These devices may include at least one central processing unit ("Central Processing Unit, CPU") and memory. According to the convention of those of ordinary skill in the art in the technical field of computer programming, references to operations, and symbolic representations of operations or instructions may be implemented by various CPUs and memories. Such operations and operations or instructions may be referred to as "executed", "executed by a computer", or "executed by a CPU".

[0110] Those skilled in the art will understand that operations and symbolically represented operations or instructions involve the manipulation of electrical signals by a CPU. An electrical system represents data bits that can cause a resultant conversion or reduction of electrical signals, maintains the data bits in memory locations of a memory system, thereby restructuring or otherwise changing the operation of the CPU and the processing of other signals. The memory locations where the data bits are maintained are physical locations having specific electrical, magnetic, optical, or organic characteristics corresponding to or representing the data bits. Representative embodiments are not limited to the above-described platforms or CPUs, and it should be understood that other platforms and CPUs may support the provided methods.

[0111] Data bits can also be maintained on a computer-readable medium, including magnetic disks, optical disks, and any other volatile (e.g., random access memory ("RAM")) or non-volatile (e.g., read-only memory ("ROM")) mass storage systems readable by a CPU. The computer-readable medium may include cooperative or interconnected computer-readable media that exist exclusively on a processing system or are distributed among multiple interconnected processing systems that may be local or remote to the processing system. Representative embodiments are not limited to the above-described memories, and it should be understood that other platforms and memories may support the described methods.

[0112] In an exemplary embodiment, any of the operations, processes, etc. described herein may be implemented as computer-readable instructions stored on a computer-readable medium. The computer-readable instructions may be executed by a processor of a mobile body, network element, and / or any other computing device.

[0113] There is little distinction between the hardware implementation and the software implementation of the aspects of the system. The use of hardware or software is generally (e.g., although not always, in certain contexts, the choice between hardware and software can be important) a design choice representing a cost - effectiveness trade - off. There can be various vehicles (e.g., hardware, software, and / or firmware) by which the processes and / or systems and / or other technologies described herein can be affected, and the preferred vehicle can vary depending on the context in which the processes and / or systems and / or other technologies are deployed. For example, if the implementer determines that speed and accuracy are of utmost importance, the implementer can choose a vehicle mainly of hardware and / or firmware. If flexibility is of utmost importance, the implementer can choose mainly a software implementation. Alternatively, the implementer may choose some combination of hardware, software, and / or firmware.

[0114] In the foregoing detailed description, various embodiments of devices and / or processes have been shown through the use of block diagrams, flowcharts, and / or examples. As long as such block diagrams, flowcharts, and / or examples include one or more functions and / or operations, those skilled in the art will understand that each function and / or each operation in such block diagrams, flowcharts, or examples can be implemented individually and / or collectively by a wide range of hardware, software, firmware, or substantially any combination thereof. Suitable processors include, by way of example, general - purpose processors, dedicated processors, conventional processors, digital signal processors (DSPs), multiple microprocessors, one or more microprocessors associated with a DSP core, controllers, microcontrollers, application - specific integrated circuits (ASICs), application - specific standard products (ASSPs), field - programmable gate array (FPGA) circuits, any other type of integrated circuit (IC), and / or state machines.

[0115] Although the features and elements have been provided in specific combinations above, those skilled in the art will understand that each feature or each element can be used alone or in any combination with other features and elements. The present disclosure is not limited in terms of the specific embodiments described in this application, and these embodiments are intended as examples of various aspects. As will be apparent to those skilled in the art, many modifications and variations can be made without departing from the spirit and scope of the present invention. Any element, operation, or instruction used in the description of this application should not be construed as important or essential to the present invention unless explicitly presented as such. In addition to those listed in this specification, functionally equivalent methods and apparatuses within the scope of the present disclosure will be apparent to those skilled in the art from the above description. Such modifications and variations are intended to fall within the scope of the appended claims. The present disclosure is limited only by the terms of the appended claims, and is limited together with the full scope of equivalents to which such claims are entitled. It should be understood that the present disclosure is not limited to a particular method or system.

[0116] It should also be understood that the terms used in this specification are for the purpose of describing particular embodiments only and are not intended to be limiting. As used in this specification and when referred to in this specification, "local" and its abbreviation "STA", "user equipment" and its abbreviation "UE" mean (i) a wireless transmit and / or receive unit (WTRU) such as the described infrastructure, (ii) any of some embodiments of a WTRU such as the described infrastructure, (iii) a wireless-capable and / or wire-capable (e.g., tetherable) device configured to have some or all of the structure and functionality of a WTRU as illustrated (e.g., such as the described infrastructure), (iii) a wireless-capable and / or wire-capable device configured to have less structure and functionality than all of a WTRU as described (e.g., such as the described infrastructure), or (iv) otherwise. Details of exemplary WTRUs that may represent any UE listed in this specification are provided below with respect to FIGS. 1A - 1D.

[0117] In certain representative embodiments, some portions of the subject matter described herein may be implemented via application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs), and / or other integrated formats. However, some aspects of the embodiments disclosed herein may be equivalently implemented in an integrated circuit as one or more computer programs operating on one or more computers (e.g., as one or more programs operating on one or more computer systems), as one or more programs operating on one or more processors (e.g., as one or more programs operating on one or more microprocessors), as firmware, or in substantially any combination thereof, and it will be recognized by those of ordinary skill in the art that designing the circuitry and / or writing the code for the software and / or firmware is within the scope of the skill of those of ordinary skill in the art in light of this disclosure. Further, it will be understood by those of ordinary skill in the art that the mechanisms of the subject matter described herein may be distributed as various forms of program products, and that the illustrative embodiments of the subject matter described herein apply regardless of the particular type of signal carrying medium used to actually effect the distribution. Examples of signal carrying media include recordable media such as floppy disks, hard disk drives, CDs, DVDs, digital tapes, computer memories, and transmission media such as digital and / or analog communication media (e.g., optical fiber cables, waveguides, wired communication links, wireless communication links, etc.), but are not limited thereto.

[0118] The subject matter described in this specification may, in some cases, depict different components that are included within or connected to different other components. It should be understood that such illustrated architectures are merely examples, and that many other architectures may be implemented in practice to achieve the same functionality. Conceptually, any arrangement of components for achieving the same functionality is effectively "associated" so that the desired functionality can be achieved. Thus, any two components combined herein to achieve a particular function can be viewed as "associated" with each other such that the desired functionality is achieved, regardless of the architecture or intermediate components. Similarly, any two components so associated can also be considered to be "operably connected" or "operably coupled" to each other to achieve the desired functionality, and any two components that can be so associated can also be considered to be "operably couplable" to each other to achieve the desired functionality. Specific examples of operably couplable include, but are not limited to, components that are physically mating and / or physically interacting, and / or wirelessly interacting and / or wirelessly interacting, and / or logically interacting and / or logically interactable components.

[0119] Regarding the use of substantially any plural and / or singular terms herein, one of ordinary skill in the art can convert from plural to singular and / or from singular to plural as appropriate to the context and / or application. In this specification, various singular / plural permutations may be explicitly recited for clarity purposes.

[0120] Generally, the terms used in this specification, and especially in the appended claims (e.g., the body of the appended claims), will be understood by those of ordinary skill in the art to generally be intended as "open" terms (e.g., the term "comprising" should be interpreted as "comprising, but not limited to", the term "having" should be interpreted as "having at least", and the term "including" should be interpreted as "including, but not limited to"). Further, if a specific number of introductions of a claim is intended, such intent will be expressly recited in the claim, and it will be understood by those of ordinary skill in the art that if no such recitation is present, no such intent exists. For example, if only one item is intended, the term "single" or similar words may be used. To assist understanding, the following appended claims and / or the description in this specification may include the use of introductory phrases such as "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be construed to limit any particular claim that introduces a claim recitation with an indefinite article "a" or "an" to an embodiment that includes only one such recitation, even if the same claim includes both an introductory phrase such as "one or more" or "at least one" and an indefinite article such as "a" or "an" (e.g., "a" and / or "an" should be interpreted to mean "at least one" or "one or more"). The same applies to the use of definite articles used to introduce claim recitations. Further, even if a specific number of introductions of a claim is expressly recited, it will be recognized by those of ordinary skill in the art that such recitation should be interpreted to mean at least the recited number (e.g., a simple recitation of "two recitations" without other modifiers means at least two recitations, or two or more recitations).

[0121] Furthermore, when notations similar to “at least one of A, B, and C” are used, generally, such a structure is intended in the sense that those skilled in the art will understand such notations (e.g., “a system having at least one of A, B, and C” includes, but is not limited to, a system having only A, only B, only C, A and B together, A and C together, B and C together, and / or A, B, and C together). When notations similar to “at least one of A, B, or C” are used, generally, such a structure is intended in the sense that those skilled in the art will understand such notations (e.g., “a system having at least one of A, B, or C” includes, but is not limited to, a system having only A, only B, only C, A and B together, A and C together, B and C together, and / or A, B, and C together). It will be further understood by those skilled in the art that any substantially discrete words and / or phrases presenting two or more alternative terms in any of the description, claims, or drawings are to be understood as contemplating the inclusion of one of the terms, any of the terms, or both terms. For example, the phrase “A or B” is to be understood as including the possibilities of “A” or “B” or “A and B”. Furthermore, as used herein, the term “any of” following a list of items and / or a list of categories of items is intended to include “any of”, “any combination of”, “any plurality of”, and / or “any combination of any plurality of” the items and / or categories of items, individually or in combination with other items and / or other categories of items. Furthermore, as used herein, the terms “set / group” or “group” are intended to include any number of items including zero. Furthermore, as used herein, the term “number” is intended to include any number including zero.

[0122] In addition, when features or aspects of the present disclosure are described from the perspective of a Markush group, those skilled in the art will recognize that the present disclosure is thereby also described from the perspective of any individual member or subgroup of members of the Markush group.

[0123] As will be understood by those skilled in the art, for all purposes, such as from the perspective of providing a written description, all ranges disclosed herein also include any possible sub-ranges and combinations of such sub-ranges. Any recited range can be readily recognized as enabling, for example, the same range to be decomposed into at least equal halves, thirds, fourths, fifths, tenths, etc. As a non-limiting example, each range described herein can be readily decomposed into a lower third, a middle third, and an upper third, etc. Also, as will be understood by those skilled in the art, all words such as "up to", "at least", "greater than", "less than", etc. mean a range that includes the recited number and can further be decomposed into sub-ranges as described above. Finally, as will be understood by those skilled in the art, a range includes individual elements. Thus, for example, a group having 1 to 3 cells refers to a group having 1, 2, or 3 cells. Similarly, a group having 1 to 5 cells refers to a group having 1, 2, 3, 4, or 5 cells, and so on.

[0124] Furthermore, the claims should not be read as being limited to the order provided or the elements provided, unless specifically so recited. Additionally, in any claim, the use of the term "means for" is intended to invoke 35 U.S.C. § 112, ¶ 6, or the means-plus-function claim format, and no claim that does not have the term "means for" is so intended.

[0125] A radio frequency transceiver can be implemented for use in a wireless transmit / receive unit (WTRU), user equipment (UE), terminal, base station, mobility management entity (MME) or evolved packet core (EPC), or any host computer, using a processor associated with software. The WTRU may be used in conjunction with hardware and / or software implemented modules such as, for example, software defined radio (SDR), and may also be implemented in other components such as a camera, video camera module, videophone, speakerphone, vibrating device, speaker, microphone, television transceiver, hands-free headset, keyboard, Bluetooth® module, frequency modulation (FM) radio unit, near field communication (NFC) module, liquid crystal display (LCD) display unit, organic light emitting diode (OLED) display unit, digital music player, media player, video game player module, Internet browser, and / or a wireless local area network (WLAN) or ultra wide band (UWB) module.

[0126] Although the invention has been described in the context of a communication system, it is contemplated that the system may be implemented in software on a microprocessor / general purpose computer (not shown). In certain embodiments, one or more of the functions of the various components may be implemented in software that controls a general purpose computer.

[0127] In addition, although the invention has been illustrated and described herein with reference to particular embodiments, the invention is not intended to be limited to the details shown. Rather, various modifications may be made in the details within the scope of the claims and their equivalents and without departing from the invention.

[0128] Throughout this disclosure, those skilled in the art will understand that certain representative embodiments may be used alternatively or in combination with other representative embodiments.

[0129] Features and elements have been described above in specific combinations, but those skilled in the art will understand that each feature or element can be used alone or in any combination with other features and elements. Further, the methods described herein may be implemented in a computer program, software, or firmware incorporated into a computer-readable medium for execution by a computer or processor. Examples of non-transitory computer-readable storage media include, but are not limited to, magnetic media such as read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, internal hard disks, and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A radio frequency transceiver for use in a WRTU, UE, terminal, base station, RNC, or any host computer can be implemented using a processor associated with software.

[0130] Furthermore, in the above embodiments, other devices including a processing platform, a computing system, a controller, and a processor are described. These devices may include at least one central processing unit ("CPU") and memory. According to the convention of those skilled in the art in the technical field of computer programming, references to operations, and symbolic representations of operations or instructions may be implemented by various CPUs and memories. Such operations and operations or instructions may be referred to as "executed," "executed by a computer," or "executed by a CPU."

[0131] Those skilled in the art will understand that operations and symbolically represented operations or instructions involve the manipulation of electrical signals by a CPU. An electrical system represents data bits that can cause a resultant conversion or reduction of electrical signals, maintains the data bits at memory locations in a memory system, thereby restructuring or otherwise changing the operation of the CPU and the processing of other signals. The memory location where the data bits are maintained is a physical location having specific electrical, magnetic, optical, or organic characteristics corresponding to or representing the data bits.

[0132] Data bits can also be maintained on a computer-readable medium, including magnetic disks, optical disks, and any other volatile (e.g., random access memory ("RAM")) or non-volatile (e.g., read-only memory ("ROM")) mass storage systems readable by a CPU. The computer-readable medium can include cooperative or interconnected computer-readable media that exist exclusively on a processing system or are distributed among multiple interconnected processing systems that can be local or remote to the processing system. Representative embodiments are not limited to the memory described above, and it is understood that other platforms and memories can support the described methods.

[0133] Suitable processors include, by way of example, general-purpose processors, dedicated processors, conventional processors, digital signal processors (DSPs), multiple microprocessors, one or more microprocessors associated with a DSP core, controllers, microcontrollers, application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), field-programmable gate array (FPGA) circuits, any other type of integrated circuit (IC), and / or state machines.

[0134] Although the present invention has been described with respect to a communication system, it is contemplated that the system may be implemented in software on a microprocessor / general purpose computer (not shown). In certain embodiments, one or more of the functions of the various components may be implemented in software that controls a general purpose computer.

[0135] In addition, although the present invention has been illustrated and described herein with reference to particular embodiments, the present invention is not intended to be limited to the details shown. Rather, various modifications may be made in the details within the scope of the claims and their equivalents and without departing from the spirit of the invention.

Claims

1. A method for wireless communication, comprising: transmitting configuration information to one or more service function endpoints (SFEs) using a programmable application programming interface (API); implementing the API as programmable middleware; registering each of the one or more SFEs with a respective service function identifier (SFID) according to a service description in the programmable middleware; for each of the one or more SFEs, determining a destination service function (SF) name associated with the respective SFID using the programmable middleware, and communicating with the respective SFE using the destination SF name.

2. For each respective SFE, mapping the destination SF name to the respective SFID using the programmable middleware. The method according to claim 1, further comprising:

3. determining that the association between the destination SF name and the respective SFID has changed, and updating the association with a second SFID to associate with the destination SF name. The method according to claim 1, further comprising:

4. The method according to claim 1, further comprising receiving one or more programmable updates from a chain operation entity.

5. The method according to claim 4, wherein the chain operation entity is an authority entity, a service chain controller, or an orchestrator.

6. The method according to claim 4, wherein the one or more programmable updates include the service description.

7. The method according to claim 1, wherein the service description is a description associated with a service chain (SC).

8. The method according to claim 1, implemented in a wireless transmit / receive unit (WTRU) operating as one of the one or more SFEs and communicating with other ones of the one or more SFEs using the destination SF name.

9. determining that one or more SFs have been re-chained, and updating the association from the SF name to the SFID based on the determination. The method according to claim 1, further comprising:

10. The method according to claim 3, wherein any one of the SFID, each of the respective SFIDs, or the second SFID is a fully qualified domain name (FQDN) or an IP address.

11. The method according to claim 1, wherein the SFID is a fully qualified domain name (FQDN) or an IP address.

12. The method according to claim 1, wherein the destination SF name is a fully qualified domain name (FQDN) or an IP address.

13. Implementing the API as the programmable middleware includes remotely programming a lookup table of the programmable middleware using the programmable API, according to the method of claim 1.

14. A wireless transmit / receive unit (WTRU) for wireless communication, comprising a processor, a transmitter, a receiver, and a memory, wherein the WTRU transmits configuration information to one or more service function endpoints (SFEs) using a programmable application programming interface (API), implements the API as programmable middleware, registers each of the one or more SFEs according to a service description in the programmable middleware, using respective service function identifiers (SFIDs), for each of the one or more SFEs, determines a destination service function (SF) name associated with each SFID using the programmable middleware, and is configured to communicate with each of the SFEs using the destination SF name.

15. The processor is configured to map the destination SF name to each respective SFID using the programmable middleware for each respective SFE, according to the WTRU of claim 14.

16. The processor is configured to determine that the association between the destination SF name and each respective SFID has changed, and update the association with a second SFID to associate with the destination SF name, according to the WTRU of claim 14.

17. The receiver of the WTRU according to claim 14 is configured to receive one or more programmable updates from a chain operation entity.

18. The WTRU according to claim 17, wherein the chain operation entity is an authority entity, a service chain controller, or an orchestrator. **Claim 19** The WTRU according to claim 14, wherein the one or more programmable updates include the service description, and the service description is a description associated with a service chain (SC). **Claim 20** The WTRU according to claim 14, wherein either each SFID or the destination SF name is a fully qualified domain name (FQDN) or an IP address.

Citation Information

Patent Citations

  • Distributed control system and its constituting element

    JP2000268016A

  • Method of resolving virtual network name

    JP2003163678A

  • Communication system and communication method

    JP2020174259A

  • Method and apparatus for encapsulating / decapsulating data packets at a radio access node

    US20180097722A1