WO2021016472A1 - Methods and apparatus for http-over-icn based service discovery and for service discovery using end-user initiated service function chaining - Google Patents

Abstract

Methods, apparatus, systems, architectures and interfaces for service discovery using a service function chain (SFC) are provided. A method may include any of: obtaining information associated with a service discovery pattern; selecting a service discovery pattern according to information associated with the service discovery pattern; generating a network service header (NSH) according to the selected service discovery pattern; transmitting a service discovery request to a first hop of an SFC using the NSH; receiving more than one results of the service discovery request from more than one hops of the SFC according to the NSH; and transmitting, to an initiator of the service discovery, a result of the service discovery including information associated with any of the received more than one results of the service discovery request.

Description

METHODS AND APPARATUS FOR HTTP-OVER-ICN BASED SERVICE DISCOVERY AND FOR SERVICE DISCOVERY USING END-USER INITIATED

SERVICE FUNCTION CHAINING

BACKGROUND

[0001] The invention relates to the field of computing and communications and, more particularly, to methods, apparatus, systems, architectures and interfaces for computing and communications in an advanced or next generation wireless communication system, including communications carried out using a new radio and/or new radio (NR) access technology and communication systems. Such NR access and technology may provide ubiquitous computing, which may also be referred to as distributed computing, and may provide continuous computing on networked devices that are distributed at all scales and that are disposed at any location at any time. Such NR access and technology may use service function chains (SFCs), for example, to perform operations and/or services associated with the network or an end-user. Furthermore, the invention relates to service discovery in Information Centric Networks (ICN).

SUMMARY

In accordance with an embodiment, a wireless transmit/receive unit (WTRU) performs service discovery, and such a WTRU obtains information associated with a service discovery pattern and selects a service discovery pattern according to information associated with the service discovery pattern. The WTRU generates a network service header (NSFI) according to the selected service discovery pattern, transmits a service discovery request to a first hop of an SFC using the NSFI, and receives more than one results of the service discovery request from more than one hops of the SFC according to the NSFI. The WTRU transmits, to an initiator of the service discovery, a result of the service discovery including information associated with any of the received more than one results of the service discovery request.

[0002] In accordance with an exemplary method, a client initiates a service discovery request, which, in turn, is sent to one or more service repositories via a publication to the repository name where the publication is matched against all registered service repositories, and, as a result, the initiating client receives back a single consolidated discovery reply disclosing one or more responses to the initial service discovery request. l [0003] In accordance with another exemplary embodiment, a Network Attachment Point (NAP) receives an initiating service discovery request, publishes an ICN message against the repository name provided in said request along with an instruction to match the discovery request against all registered repositories in order to send the

encapsulated HTTP request to all those found repositories in an ICN multicast manner. The requests are received at the individual repositories, each of which publishes a response on the return path to the initiating NAP, which, in turn, consolidates all received responses from the one or more registered repositories and forwards a single consolidated response to the initiating discovery request toward the client.

[0004] In accordance with another exemplary embodiment, a system comprises one or more NAPs, one or more service function endpoints, and at least one client. In an exemplary embodiment, the client issues a discovery request to the nearest NAP, which, in turn, publishes the request to the ICN network in a one-to-many publication. That published request is received by one or more registered service function endpoints under the name provided in the publication, each of which endpoints generates a response, the responses being sent on a unicast path calculated based on provided information in the originating publication. The NAP receives the response(s) and consolidates the one or more responses into a single response that is transmits toward the initiating client.

[0005] In certain embodiments, the new functionality discussed herein may be implemented in the application layer or other layers in a dedicated (edge) network infrastructure node and/or integrated into a wireless transmit/receive unit (WTRU).

BRIEF DESCRIPTION OF THE DRAWINGS

[0006] A more detailed understanding may be had from the Detailed Description below, given by way of example in conjunction with drawings appended hereto. Figures in such drawings, like the detailed description, are examples. As such, the Figures and the detailed description are not to be considered limiting, and other equally effective examples are possible and likely. Furthermore, like reference numerals in the Figures indicate like elements, and wherein:

[0007] FIG. 1A is a system diagram illustrating an example communications system in which one or more disclosed embodiments may be implemented; [0008] FIG. 1 B is a system diagram illustrating an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A according to an embodiment;

[0009] FIG. 1 C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communications system illustrated in FIG. 1A according to an embodiment;

[0010] FIG. 1 D is a system diagram illustrating a further example RAN and a further example CN that may be used within the communications system illustrated in FIG. 1A according to an embodiment;

[0011] FIG. 2 is a block diagram of a network in accordance with an embodiment;

[0012] FIG. 3 is a diagram illustrating signal flow between various nodes of the network in accordance with an embodiment;

[0013] FIG. 4 is a diagram illustrating an architecture for (e.g., using) SFCs as a discovery protocol, according to embodiments;

[0014] FIG. 5 is a diagram illustrating discovery patterns as named SFCs, according to embodiments; and

[0015] FIG. 6 is a diagram illustrating a message sequence for execution of service discovery through SFCs according to embodiments.

DETAILED DESCRIPTION

Example Networks for Implementation of the Embodiments

[0016] FIG. 1A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The

communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 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), and the like. [0017] As shown in FIG. 1A, the communications system 100 may include wireless transmit/receive units (WTRlls) 102a, 102b, 102c, 102d, a RAN 104/113, a CN

106/115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments

contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may 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, any of which may be referred to as a“station” and/or a “STA”, may be configured to transmit and/or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription- 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 (loT) device, a watch or other wearable, a head- mounted display (FIMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and/or other wireless devices operating in an industrial and/or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and/or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c and 102d may be interchangeably referred to as a UE.

[0018] The communications system 100 may also include a base station 114a and/or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c,

102d to facilitate access to one or more communication networks, such as the CN 106/115, the Internet 110, and/or the other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Flome Node B, a Flome eNode B, a gNB, a NR NodeB, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

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

[0020] The base stations 114a, 114b may communicate with one or more of the

WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0021] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104/113 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115/116/117 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as Fligh-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink (DL) Packet Access (HSDPA) and/or High-Speed UL Packet Access (HSUPA).

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

[0023] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR Radio Access, which may establish the air interface 116 using New Radio (NR).

[0024] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for instance using dual connectivity (DC) principles. Thus, the air interface utilized by WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and/or transmissions sent to/from multiple types of base stations (e.g., an eNB and a gNB).

[0025] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e. , Wireless Fidelity (WiFi), IEEE 802.16 (i.e., 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), and the like.

[0026] The base station 114b in FIG. 1 A may be a wireless router, Flome Node B,

Flome eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio 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 may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE -A Pro, NR etc.) to establish a picocell or femtocell. As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the CN 106/115.

[0027] The RAN 104/113 may be in communication with the CN 106/115, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106/115 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication. Although not shown in FIG. 1 A, it will be appreciated that the RAN 104/113 and/or the CN 106/115 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104/113 or a different RAT. For example, in addition to being connected to the RAN 104/113, which may be utilizing a NR radio technology, the CN 106/115 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E- UTRA, or WiFi radio technology.

[0028] The CN 106/115 may also serve as a gateway for the WTRUs 102a, 102b,

102c, 102d to access the PSTN 108, the Internet 110, and/or the other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of

interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and/or the internet protocol (IP) in the TCP/IP internet protocol suite. The networks 112 may include wired and/or wireless communications networks owned and/or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104/113 or a different RAT.

[0029] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links). For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0030] FIG. 1 B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1 B, the WTRU 102 may include a processor 118, a transceiver 120, a

transmit/receive element 122, a speaker/microphone 124, a keypad 126, a

display/touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and/or other peripherals 138, among others. It will be appreciated that the WTRU 102 may include any sub combination of the foregoing elements while remaining consistent with an embodiment.

[0031] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (1C), a state machine, and the like. The processor 118 may 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 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. 1 B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0032] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over 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 an embodiment, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and/or receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

[0033] Although the transmit/receive element 122 is depicted in FIG. 1 B 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 over the air interface 116.

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

[0035] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the

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

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

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

[0038] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs 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, and the like. The peripherals 138 may include one or more sensors, the sensors 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.

[0039] The WTRU 102 may include a full duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for both the UL (e.g., for transmission) and downlink (e.g., for reception) may be concurrent and/or simultaneous. The full duplex radio may include an interference management unit to reduce and or substantially eliminate self-interference via either hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via processor 118). In an embodiment, the WRTU 102 may include a half-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for either the UL (e.g., for transmission) or the downlink (e.g., for reception)).

[0040] FIG. 1 C is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0041] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and/or receive wireless signals from, the WTRU 102a.

[0042] Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and/or DL, and the like. As shown in FIG. 1 C, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

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

[0044] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and/or WCDMA.

[0045] The SGW 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the S1 interface. The SGW 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

[0046] The SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the

Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0047] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and/or wireless networks that are owned and/or operated by other service providers.

[0048] Although the WTRU is described in FIGS. 1 A-1 D as a wireless terminal, it is contemplated in certain representative embodiments that such a terminal may use (e.g., temporarily or permanently) wired communication interfaces with the communication network.

[0049] In representative embodiments, the other network 112 may be a WLAN. [0050] A WLAN in Infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have an access or an interface to a Distribution System (DS) or another type of wired/wireless network that carries traffic in to and/or out of the BSS. Traffic to STAs that originates from outside the BSS may arrive through the AP and may be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS may be sent to the AP to be delivered to respective destinations. Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA. The traffic between STAs within a BSS may be considered and/or referred to as peer-to-peer traffic. The peer-to- peer traffic may be sent between (e.g., directly between) the source and destination STAs with a direct link setup (DLS). In certain representative embodiments, the DLS may use an 802.11 e DLS or an 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other. The IBSS mode of communication may sometimes be referred to herein as an“ad-hoc” mode of communication.

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

[0052] High Throughput (HT) STAs may use a 40 MHz wide channel for communication, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.

[0053] Very High Throughput (VHT) STAs may support 20MHz, 40 MHz, 80 MHz, and/or 160 MHz wide channels. The 40 MHz, and/or 80 MHz, channels may be formed by combining contiguous 20 MHz channels. A 160 MHz channel may be formed by combining 8 contiguous 20 MHz channels, or by combining two non-contiguous 80 MHz channels, which may be referred to as an 80+80 configuration. For the 80+80 configuration, the data, after channel encoding, may be passed through a segment parser that may divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing, and time domain processing, may be done on each stream separately. The streams may be mapped on to the two 80 MHz channels, and the data may be transmitted by a transmitting STA. At the receiver of the receiving STA, the above described operation for the 80+80 configuration may be reversed, and the combined data may be sent to the Medium Access Control (MAC).

[0054] Sub 1 GHz modes of operation are supported by 802.1 1 af and 802.1 1 ah. The channel operating bandwidths, and carriers, are reduced in 802.1 1 af and 802.1 1 ah relative to those used in 802.1 1 n, and 802.1 1 ac. 802.1 1 af supports 5 MHz, 10 MHz and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.1 1 ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.1 1 ah may support Meter Type

Control/Machine-Type Communications, such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, for example, limited capabilities including support for (e.g., only support for) certain and/or limited bandwidths. The MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0055] WLAN systems, which may support multiple channels, and channel bandwidths, such as 802.1 1 n, 802.1 1 ac, 802.1 1 af, and 802.1 1 ah, include a channel which may be designated as the primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and/or limited by a STA, from among all STAs in operating in a BSS, which supports the smallest bandwidth operating mode. In the example of 802.1 1 ah, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only support) a 1 MHz mode, even if the AP, and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and/or other channel bandwidth operating modes. Carrier sensing and/or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which supports only a 1 MHz operating mode), transmitting to the AP, the entire available frequency bands may be considered busy even though a majority of the frequency bands remains idle and may be available. [0056] In the United States, the available frequency bands, which may be used by 802.11 ah, are from 902 MHz to 928 MHz. In Korea, the available frequency bands are from 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11 ah is 6 MHz to 26 MHz depending on the country.

[0057] FIG. 1 D is a system diagram illustrating the RAN 113 and the CN 115 according to an embodiment. As noted above, the RAN 113 may employ an NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also be in communication with the CN 115.

[0058] The RAN 113 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, gNBs 180a, 180b may utilize beamforming to transmit signals to and/or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a, for example, may use multiple antennas to transmit wireless signals to, and/or receive wireless signals from, the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum while the remaining component carriers may be on licensed spectrum. In an embodiment, the gNBs 180a, 180b, 180c may implement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and/or gNB 180c).

[0059] The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using transmissions associated with a scalable numerology. For example, the OFDM symbol spacing and/or OFDM subcarrier spacing may vary for different transmissions, different cells, and/or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using subframe or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing varying number of OFDM symbols and/or lasting varying lengths of absolute time). [0060] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and/or a non-standalone configuration.

In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as eNode-Bs 160a, 160b, 160c). In the standalone configuration, WTRUs 102a, 102b, 102c may utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b,

180c using signals in an unlicensed band. In a non-standalone configuration WTRUs 102a, 102b, 102c may communicate with/connect to gNBs 180a, 180b, 180c while also communicating with/connecting to another RAN such as eNode-Bs 160a, 160b, 160c. For example, WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In the non-standalone configuration, eNode-Bs 160a,

160b, 160c may serve as a mobility anchor for WTRUs 102a, 102b, 102c and gNBs 180a, 180b, 180c may provide additional coverage and/or throughput for servicing WTRUs 102a, 102b, 102c.

[0061] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and/or DL, support of network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and Mobility Management Function (AMF) 182a, 182b and the like. As shown in FIG. 1 D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.

[0062] The CN 115 shown in FIG. 1 D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While each of the foregoing elements are depicted as part of the CN 115, it will be appreciated that any of these elements may be owned and/or operated by an entity other than the CN operator.

[0063] The AMF 182a, 182b may be connected to one or more of the gNBs 180a,

180b, 180c in the RAN 113 via an N2 interface and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different PDU sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of NAS signaling, mobility management, and the like. Network slicing may be used by the AMF 182a, 182b in order to customize CN support for WTRUs 102a, 102b, 102c based on the types of services being utilized. For example, different network slices may be established for different use cases such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for machine type communication (MTC) access, and/or the like. The AMF 182 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and/or non-3GPP access technologies such as WiFi.

[0064] The SMF 183a, 183b may be connected to an AMF 182a, 182b in the CN 115 via an N11 interface. The SMF 183a, 183b may also be connected to a UPF 184a,

184b in the CN 115 via an N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b.

The SMF 183a, 183b may perform other functions, such as managing and allocating UE IP address, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, and the like. A PDU session type may be IP-based, non-IP based, Ethernet-based, and the like.

[0065] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184a, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, and the like.

[0066] The CN 115 may facilitate communications with other networks. For example, the CN 115 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 115 and the PSTN 108. In addition, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and/or wireless networks that are owned and/or operated by other service providers. In one

embodiment, the WTRUs 102a, 102b, 102c may be connected to a local Data Network (DN) 185a, 185b through the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b. [0067] In view of Figures 1 A-1 D, and the corresponding description of Figures 1 A-1 D, one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and/or any other device(s) described herein, may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, the emulation devices may be used to test other devices and/or to simulate network and/or WTRU functions.

[0068] The emulation devices may be designed to implement one or more tests of other devices in a lab environment and/or in an operator network environment. For example, the one or more emulation devices may perform the one or more, or all, functions while being fully or partially implemented and/or deployed as part of a wired and/or wireless communication network in order to test other devices within the communication network. The one or more emulation devices may perform the one or more, or all, functions while being temporarily implemented/deployed as part of a wired and/or wireless communication network. The emulation device may be directly coupled to another device for purposes of testing and/or may performing testing using over-the-air wireless communications.

[0069] The one or more emulation devices may perform the one or more, including all, functions while not being implemented/deployed as part of a wired and/or wireless communication network. For example, the emulation devices may be utilized in a testing scenario in a testing laboratory and/or a non-deployed (e.g., testing) wired and/or wireless communication network in order to implement testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and/or wireless communications via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation devices to transmit and/or receive data.

Exemplary Architecture Including an Information Centric Network (ICN)

[0070] FIG. 2 is a block diagram of the components in accordance with an exemplary embodiment. The network 200 is an Information Centric Network (ICN) which may include components such as one or more Network Attachment Points (NAPs) 201. The NAPS may comprise, for example, base stations, eNodeBs, gNodeBs, and other infrastructure nodes of a wireless network. One or more client devices 203 attach to and communicate with and with the network through the NAPs. The client devices 203 may, for example, comprise WTRUs and other user devices. In certain embodiments, some or all of the client devices 203 may implement the NAP functionality discussed herein. The network may further include at least one Path Computation Element (PCE) 205 for matching names (of services expressed, e.g., as fully qualified domain names, in the network) with forwarding paths as discussed in more detail below.

[0071] In one embodiment, the NAPs (including, for instance, the NAP functionality that may be implemented in one or more WTRUs, hereinafter referred to collectively as “NAP” unless otherwise specified) may implement methods, for instance, to map HTTP- based service requests/responses to ICN message exchanges. In other embodiments, the NAP is referred to as a Service Communication Proxy (SCP) or Name-based Routing (NbR) layer. As discussed elsewhere, the NAP can be realized as such NbR layer within a single device instead of having a separate client and NAP. Both variations are shown in FIG. 2, with the separate realization shown at the bottom left and the joint (in-client) realization of client and NAP shown at the top left.

[0072] The NAP 201 utilizes the PCE 205 for matching names onto forwarding path.

The PCE 205 may be realized as a combination of a RV (rendezvous) and a TM

(topology manager), where the RZ matches names (e.g., HTTP URLs) onto network locations with the TM calculating suitable paths between those locations. Such paths may be unicast path (where there is exactly one source and destination) or multi source/destination. Practical applications of the methods discussed elsewhere may realize the functionality of the PCE in the Name Resolution Function (NRF) and the Name Resolver (NR), respectively.

[0073] The client(s) 203 in FIG. 2 may initiate the service discovery requests, sending an initial request and ultimately receiving a single response following a conventional HTTP request/response semantic.

[0074] The SFE (Service Function Endpoint) components 207, specifically SFE1 , SFE2, SFE3, in FIG. 2, denote the service repositories that could potentially receive service discovery requests. Similarly to the clients 205, the SFEs 207 may be standalone components, e.g., realized as a legacy IP device connected to a separate NAP (as shown for SFE 3), or integrated with the NAPs 201 (as shown for SFE1 and SFE2).

SFE components 207 may be exposed as named entities, registering their Fully

Qualified Domain Name (FQDN) with the PCE, e.g., following the methods outlined elsewhere. More than one SFE component may be registered under one specific FQDN. This is particularly likely when using virtualized components of the same SFE, providing the same service in different parts of the network. This type of embodiment with possible multiple registrations under one FQDN will be utilized in the use cases discussed further below.

Method of HTTP-based Service Discovery

[0075] The HTTP-based service discovery over an ICN-based network such as outlined in FIG. 2 may be implemented in accordance with the exemplary embodiments and variations thereof discussed below.

[0076] FIG. 3 is a signal flow diagram illustrating operation in accordance with one exemplary embodiment. In this embodiment, a client issues an HTTP request 301 to a FQDN that denotes the desired service repository, such as discovery.com. The specific FQDN typically will depend on the particular use case. Furthermore, in the example of FIG. 3, two SFEs, SFE1 and SFE2 are registered under that name, discovery.com.

[0077] Also, the specific semantics of the request commonly will depend on the chosen service discovery semantics. In one embodiment, for instance, these semantics may include a service profile against which the repositories match their existing services, the service profile being encoded in a language such as JSON or XML.

[0078] Further, the sending of a request to one particular name with the possibility that there are several repositories registered under that name is semantically different than asking several repositories registered under individual names (as will be addressed further in the use cases below), as suggested in [7] Particularly, the request 301 queries a single named entity, whereas [7] queries several individual entities (similarly to a web crawler searching through different search engines). Unlike [7], the following steps 303 through 313 ensure that the ICN multicast capabilities of the network are utilized to send the discovery request to all those entities registered under said request name.

[0079] A NAP receives the HTTP request 301 and issues a publication 303 toward the FQDN identified in the request, e.g., discovery.com. This publication 303 is sent to the PCE for matching with suitable repositories. In the publication 303 toward the PCE, an optional flag may be set to indicate that one-to-many matching of results should be implemented on the request. Alternately, the PCE could use port or FQDN information to derive the one-to-many matching as an extension to the one-to-one matching, for example, as discussed elsewhere. [0080] In response, the PCE determines all endpoints registered under the provided FQDN, e.g., discovery.com, and calculates a one-to-many path from the client to the one or more endpoints found for said FQDN (305). At 307, the PCE returns the calculated forwarding identifier (FID) together with a number, N, of matched repositories to the NAP of the initiating client.

[0081] Next, at 309, after receiving the (one-to-many) forwarding identifier 307 from the PCE, the NAP decides to publish the encapsulated FITTP payload from the initial service discovery request 301 along with the FID to the ICN network. The publication message 309 will also include the client endpoint identifier (a domain-unique identifier assigned to the client at attachment of the client to the network), which will be used for path calculation in connection with step 317 discussed below.

[0082] The ICN multicast delivery capabilities of the network (generally represented at 311 in FIG. 3) will lead to the publication(s) 313 being sent along the one-to-many path encoded in the provided forwarding identifier; and, if there is more than one service repository registered under the FQDN that was originally provided in 301 (and repeated in 309), it will lead to the publication being sent to all those registered SFE components, e.g., SFE1 , SFE2 in this example, along the one-to-many path.

[0083] The SFE components, SFE1 , SFE2, that had been matched by the PCE in step 305 will now receive a service discovery request 313 through their respective NAPs. As shown in FIG. 2, the NAPs associated with SFE1 and SFE 2 are included in the respective SFE nodes. However, as also illustrated in FIG. 2 in connection with SFE3, for instance, the NAP may alternately be a separate node. That variation, however, is not illustrated in FIG. 3. Furthermore, the two NAPs that are collocated with SFE1 and SFE2 are not separately called out in FIG. 3 so as not to unduly obfuscate the drawing.

[0084] The NAP of each recipient SFE now initiates the return path calculation, that is to be performed by the PCE, by publishing message 315 to the PCE, message 315 including the client endpoint identifier that was provided in the incoming publication 313 along with the SFE endpoint identifier.

[0085] The PCE calculates a path from the SFE to the client, as shown at 317, and returns a suitable forwarding identifier to the NAP of the initiating SFE, as shown at 319. As shown in FIG. 3, two different forwarding identifiers 319 are returned, one for each individual return path from each SFE to the client. [0086] Each SFE formulates a service discovery response, as shown at 321 , and sends it to its corresponding NAP (a step that is not expressly shown in FIG. 3 since these NAPs are collocated within their SFEs and are not separately shown in the figure).

[0087] Upon receipt of the service discovery response(s) by the collocated NAPs from their respective SFE components, the NAPs utilize the forwarding identifier received in step 319 to send the publication of the response to the NAP of the client (messages 323).

[0088] Note that steps 319 and 321 can be reversed in order of execution or executed in parallel. Parallel execution of step 6 before 7 would minimize response latency since the path calculation (317) could take place while the discovery response is being generated by the SFE component (321 ).

[0089] The NAP of the initiating client takes the one or more published responses 323 from the one or more repositories and associates them with the original discovery request 301 through the rCID (Return Content ID) that is included in the response publication(s) 323.

[0090] In one exemplary embodiment, the rCID may be determined using the discovery URI provided in the original discovery request 301. In an embodiment, the discovery request may be disclosed via a query extension in the URI. Note that those responses will all come from the same name, as defined by the original FQDN that was part of the discovery request 301 (e.g., discovery.com). The NAP will use the number of repositories it received in message 307 to suitably wait until all responses are received. When all responses are received, the NAP can merge all of the received responses into a single response, as shown at 325, and then send a response 327 to the client.

[0091] The implementation of the merging operation 325 depends on the semantics of the service discovery request. In one exemplary embodiment, the NAP may use a multi-form body to separate the individual responses in the FITTP body from each other yet still deliver a single response, with the multi-form syntax providing an indication to the client that more than one repository has delivered a response, albeit all under the same name. Alternately, the individual discovery responses could be delivered in a single form body, therefore hiding any information on how many (same named) repositories actually contributed to the single response.

[0092] In certain embodiments, the NAP associated with the client device may employ a timeout mechanism to finish waiting for responses from repositories that do not respond within the defined timeout period. Use Cases

[0093] Below are discussed several exemplary use cases for which the capability of sending one request to many repositories registered under the same name might be useful.

Use Case - Discovery across virtualized repositories

[0094] In one such use case, SFE1 and SFE2 in FIG. 3 may be virtualized repositories. In other words, those repositories are deployed as virtualized entities from the same software package and under the same FQDN. Local methods, such as service registration being sent to the nearest virtualized entity, may lead to individual knowledge that exists across both of those virtualized repositories. The present invention allows retrieval of suitable responses from both repositories using a single request that is sent to the common FQDN of the repository.

[0095] In the state of the art, on the other hand, a request would need to be sent to each virtualized repository, in turn, exposing each virtualized SFE under its specific name rather than using the overall repository name. For instance, one request would be sent to SFE1.discovery.com and another to SFE2.discovery.com. However, this would pose the problem of finding out the names of the virtualized individual SFEs, while also being less efficient in terms of using individual discovery steps for each repository/SFE, rather than utilizing the more efficient ICN multicast delivery capability.

Use Case - Contextual Naming

[0096] A special case of the above virtualized repositories is that of combining several repositories under a contextual name, such as repositories sharing a common location. For instance, a location could be encoded as livingroom. bob-smith. home. Issuing a discovery request to this name would lead to the request being sent to ANY device that registered under this contextual name, therefore fulfilling the intent of discovering any service having this context (i.e. , being at this location). Other exemplary contexts include city level naming and relative locations, such as cars. What the client now receives as a single response are all services under that context (not individual responses from each repository under its own name). Use Case - Emulating mDNS

[0097] Multicast-based DNS (mDNS) is a technique that broadcasts a DNS-based service discovery to a well-known IP multicast address with all those repositories listening to said IP multicast address in order to be able to respond individually to the initiating client. The present invention can emulate this type of technique by setting the ‘name’ in the discovery request to the IP multicast address. In an example, mDNS is often used to limit DNS queries to a logical IP subnet in which the IP multicast is being propagated. It therefore can provide a simple form of the contextual naming use case mentioned before - but note that the‘propagation’ here is logical in the sense of the local IP network (e.g., a home network) and, therefore, cannot be as fine-grained as contexts such as rooms or similar.

Use Case - Discovery of SFEs for Specific SFs

[0098] The use of virtualization to provide more than one SFE for a specific FQDN was mentioned above. Certain solutions such describe methods to‘pin’ the execution of service function chains, i.e. , the sending of service requests along a specific set of (virtualized) SFEs, e.g., for reasons of resource management. For this, the discovery of which SFEs are provided under which FQDNs (i.e., representing a service function) is often needed. The certain solutions may propose the communication toward a service function host, representing a local management agent that is aware of which SFE is currently running in its set of resources (such as in a micro data center). An alternative approach in accordance with the present invention could be to‘discover’ the SFE instances by sending a discovery request to the FQDN of the overall service function, upon which each SFE instance registered under said FQDN will receive said request and reply with suitable information that allows for decision making according to the certain solutions, e.g., by instructing a specific SFE instance to register under a pinned service name.

Exemplary Architecture Including Service Function Chains (SFCs)

[0099] FIG. 4 is a diagram illustrating an architecture for (e.g., using) SFCs as a discovery protocol, according to embodiments.

[0100] According to embodiments, an architecture 400, which may be referred to as a network 200, for example, as shown in FIG. 4 may include components for realizing the methods and apparatuses for (e.g., using) SFCs for service discovery (e.g., as a discovery protocol). According to embodiments, the architecture 400 may include a service discovery manager (SDM) 401 , for example, that may be (e.g., responsible) for initiating a selected service function chain, which may be referred to as a named service discovery instance. According to embodiments, a named service discovery instance may be provided by a (e.g., any of various) service repository (SR) 402, such as SR1 , SR2, SR3, and SR4 in FIG. 4. According to embodiments, any of a (e.g., each, any) SR and a SDM may communicate via a (e.g., local) nSFF 203, for example, as shown in FIG. 4, with SR3 and SR4 being served by the same nSFF. According to embodiments, a nSFF may implement methods, for example, as described with reference to a nSFF component within a SFC framework. According to embodiments, a SDM 401 may be collocated with a client device, for example, client device 204 in FIG. 4, for use cases such as fully client-initiated discovery. According to embodiments, a SDM 401 may be collocated with any of a client 403 (e.g., a WTRU) and a Non-Access Stratum (NAS) engine (not shown), for example, in a network-assisted discovery service realization.

Capturing Service Discovery Patterns as SFCs

[0101] FIG. 5 is a diagram illustrating discovery patterns as named SFCs, according to embodiments.

[0102] According to embodiments, an architecture for using) SFCs as a discovery protocol, for example, as shown in FIG. 4, may be used for implementing (e.g., the most common) discovery patterns as a service. For example, according to embodiments, a centralized search may use (e.g., initiate, be directed against, etc.) a (e.g., only one) repository, such as one of the SRs 402 in FIG. 4. According to embodiments, a parallel search may initiate two or more (e.g., such centralized) searches, for example, in a manner similar to crawling several search engines or websites. According to

embodiments, a sequential search may be (e.g., represent, initiate, etc.) a (e.g., typical) federation-based search, for example, for which all (e.g., specified) SRs may be searched for a (e.g., overall) result. According to embodiments, (e.g., previously described) mDNS style of discovery may be emulated, for example, by a parallel search to all local known members (e.g., albeit) represented as fully qualified domain names (FQDNs), and, for example, not to members of an IP multicast address, for example, as in mDNS.

[0103] According to embodiments, discovery patterns, for example, as shown in FIG. 5, may be (e.g., further) constrained (e.g., associated, configured, etc.) with attributes, for example, such as any of exhaustive search, top ranked search, and fastest search. According to embodiments, an exhaustive search may include (e.g., all) known service repositories into a search pattern (e.g., for the parallel search), while top ranked search may select a (e.g., only one) service repository (e.g., only) based on a ranking mechanism, for example, by maintaining a ranking for each known service repository at a SDM. According to embodiments, a parallel search pattern, for example, as shown in FIG. 5, may be (e.g., then become) the same as the centralized and sequential search, for example, by (e.g., only) contacting the SR with the highest rank. According to embodiments, a fastest search may use (e.g., be realized through) a latency ranking (e.g., a latency including any of an overall search latency and a network latency) and may (e.g., then only) contact a selected (e.g., fastest) repository, for example, in a manner similar to the top ranked search attribute.

Recursively Applying Service Discovery Patterns as SFCs

[0104] According to embodiments, a service discover pattern may be applied recursively as a SFC (e.g., as a recursive SFC). For example, according to

embodiments, discovery patterns, for example, as shown in FIG. 5, may be recursively applied at a (e.g., any, each) repository by a (e.g., any, each) SR locally realizing (e.g., locally applying) any of a same or a different discovery pattern, for example, before suppling a (e.g., discovery) response to the initiating SFCs. According to embodiments, a determination of which service discovery patterns may be applied locally may be the same as (e.g., follow a similar approach as) that for a client. For example, according to embodiments, a local configuration of an SDM may be used with the same approach to discovery initiation and reconciliation as for the main, e.g., topmost discovery pattern.

[0105] According to embodiments, in the case of using a same discovery pattern as that for a client, the client may (e.g., initially) select a search (e.g., a centralized search), which may be (e.g., then) realized by a chosen SR, for example, through (e.g., using) a parallel search with several other SRs. According to embodiments, combining a sequential search with a parallel search, for example, at each sequential SR, may be (e.g., then represent an example for) a federation-based discovery. According to embodiments, a centralized federation agent (e.g., represented by a SR included in the initial sequential search) may use a parallel search in its own domain, for example, with SRs likely not known to the initiating client. Combining the Name-based Search with a Virtualized Service Instance

[0106] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in 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, a read only memory (ROM), random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU 102, UE, terminal, base station, RNC, or any host computer.

[0107] According to embodiments, service discovery patterns (e.g., and resulting SFPs that may be constructed as an SFC) may use named relationships, for example, such as FQDNs, for the service repositories. For example, according to embodiments, an IP address may serve as a named relationship, but such a case may lose a (e.g., possible) realization via virtualized instances located in more than one routing location. According to embodiments, any number of virtualized entities of any (e.g., one) of SRs, for example, as shown in FIG. 5, may exist in a network, for example, using virtualization.

[0108] According to embodiments, for example, using methods associate with a nSFF component within a SFC framework, a service request to one of the SRs, for example, under a given FQDN, may be directed to a selected (e.g., virtualized) service instance. According to embodiments, selection of a service instance may be based on any of a shortest path or similar constraint-based path computation policy. According to embodiments, methods and/or solutions that may be used include any associated with pinning a (e.g., specific, virtualized) service instance of a given FQDN (e.g., SR1 in FIG. 5) to a specific client, for example, through a context-specific naming that is being used to extend the original FQDN (e.g., SR1 ) with the specific context information. According to embodiments, (e.g., by using such) pinning methods may (e.g., then) replace an original SR1 FQDN with a context-specific one, for example, allowing for assigning specific search and/or discovery repositories to specific clients in the (e.g., overall) system. Determining a Set of SRs Being Used

[0109] According to embodiments, an (e.g., another) aspect of client-centric control features discussed herein is selection of SRs, for example, those being used in the first place (e.g., SR1 through SR4 in FIG. 4). According to embodiments, selection of a SR may depend on a use case for the discovery. For example, in the case of FIG. 4, the SRs may represent search engines and may (e.g., therefore) map to a set of known search engines with the selection of the search pattern allowing for a fast search on the fastest responsive search engine, or an exhaustive search crawling all search engines known to the SDM. According to embodiments, for example, depending on the use case, SRs may provide different information to be searched, for example, which may (e.g., then, also) be reflected in a search request sent by a client to a SDM.

Steps for Service Discovery Based on SFC

[0110] According to embodiments, any of the following steps (e.g., procedures, methods, operations, etc.) may (e.g., need to) be executed, for example, for execution of service discovery through SFCs: (1 ) a client may select a (e.g., specific, initial) discovery pattern; (2) a client may send (e.g., then issue) a (e.g., discovery) request to a SDM; (3) a SDM may determine a (e.g., best fitting) service discovery pattern, for example, upon receiving the (e.g., discovery) request from the client; (4) a SDM may send (e.g., then issue) a (e.g., first) request to a (e.g., its local) nSFF; and (5) a payload of a NSFI packet may be extracted, for example, upon the last response arriving at a SDM.

[0111] According to embodiments, a client may select a specific initial discovery pattern, for example, from among the discovery patterns shown in FIG. 5. According to embodiments, selection of a discovery pattern may be done through any of a

programmatic interface, such as an application programming interface (API), and a graphical user interface (GUI), such as in a system setting. According to embodiments, a selection may be according to (e.g., based on) any of specific SRs and a (e.g., general) service discovery pattern (which may be interchangeably referred to as a pattern). According to embodiments, in a case specific SRs, a user may specify a pattern in its exact form, for example, specified according to which central repository may be used for a centralized search.

[0112] According to embodiments, in a case where a pattern is (e.g., merely) chosen, for example, according to a general pattern, an SDM may fill in (e.g., the specific) SR information into the service discovery pattern, for example, upon determining the service discovery pattern. According to embodiments, a selection (e.g., a process of and/or method for selecting) may use a specific index associated with (e.g., into, describing, mapping to, etc.) a pattern, for example, using any of pattern 2 for (e.g., as, indicating) a parallel search, for example, of Figure 2, and attributes such as, for example, fastest, exhaustive, or highest ranked. According to embodiments, in a case of a (e.g., end) user selecting (e.g., a discovery pattern) through a GUI, (e.g., more meaning full) information may (e.g., then) be presented to the (e.g., end) user, for example, to allow the user to select an exhaustive search through a simple GUI.

According to embodiments, a client may send (e.g., transmit, command, issue, etc.) a request to a SDM, for example, (e.g., automatically) upon a selection of a service discovery pattern (e.g., by the user), as described hereinabove. According to

embodiments, such request may be an API call, for example, to any of a local service discovery module or an HTTP-based call to a (e.g., well-known) SDM URL.

[0113] According to embodiments, for example, upon receiving a discovery request, an SDM may determine a (e.g., best fitting) service discovery pattern, for example, using any of: (1 ) a provided index, for example, an index associated with (e.g., mapping to, into, etc.) a set of patterns; and (2) mapping selection criteria, such as, for example, fastest, exhaustive, etc., onto a (e.g., the most fitting, available) search pattern.

According to embodiments, an SDM may, for example, upon determining a service discovery pattern, construct a (e.g., suitable) Network Service Header (NSH), for example, to encode a (e.g., the overall) SFP for a (e.g., the chosen) service discovery pattern, for example, as shown in FIG. 5. According to embodiments, in a case where, for example, along with selecting a service discovery pattern as discussed above, a client specifies SRs, the (e.g., specific) SRs may be filled into a (e.g., the respective) service discovery pattern (e.g., that was chosen).

[0114] According to embodiments, in a case where a client does (e.g., did) not specify SRs, for example, when selecting a service discovery pattern, a SDM may use (e.g., internal) SR knowledge to fill in the respective named SR information associated with a (e.g., in the) service discovery pattern chosen by a client. According to embodiments, for (e.g., filling in, acquiring, receiving, discovering, etc.) SR knowledge, any of the following may be used: (1 ) configuration of repositories in system settings (e.g., main search engine to be used); (2) discovery of repositories through existing SD protocols, such as mDNS and others; and (3) utilizing (e.g., well-known) names for repositories, such as, for example, any of repository. local for local discovery, and rooml .local and room2. local for geo-based naming.

[0115] According to embodiments, (e.g., then, upon determining a service discovery pattern) an SDM may issue a first request to a (e.g., its local) nSFF, for example, in the form of an NSFI header with an FITTP discovery request as payload. According to embodiments, for example, upon receiving an HTTP request at a local nSFF, a (e.g., next, named) hop may be determined, for example, in the form of the outgoing nSFF in a manner such as that associated with a nSFF component within an SFC framework. According to embodiments, for example, upon receiving the HTTP request at an outgoing nSFF, an NSH header may be removed and the HTTP request may be sent to a (e.g., the respective, local) SR function. According to embodiments, for example, upon receiving a response (e.g., to the HTTP request, from the local SR function), a nSFF may determine a next named hop, and may forward the NSH and HTTP content to the next hop.

[0116] According to embodiments, the NSH and HTTP content may be forwarded, for example, according to the NSH information, for example, and therefore according to the underlying SFP that had been chosen as an outcome of (e.g., determining) the (e.g., best fitting) service discovery pattern. According to embodiments, a multi-form HTTP body may be (e.g., used) for combining a HTTP response from a (e.g., local) SR and a request being used to forward to the (e.g., local) SR at a nSFF. According to

embodiments, the above operations and procedures may be repeated, for example, with respect to the NSH header being removed and the HTTP request being sent to the respective local SR function, until there is no next hop left in the NSH. According to embodiments, SFPs, for example, as shown in FIG. 5, may be constructed with an SDM being the last hop of the SFC, and in such a case, a response (e.g., form the last hop of the SFC) may have (e.g., then) arrive (e.g., back) at the SDM, and a payload of the NSH packet may be extracted.

[0117] According to embodiments, for example, upon a (e.g., the last) response arriving at an SDM, a payload of an NSH packet may be extracted. According to embodiments, in a case of a multi-form HTTP body, responses may be taken from the multi-form HTTP body and consolidated into a single response to a client. According to

embodiments, consolidation into a single response may be according to (e.g., depend on) selection of a service discovery pattern. For example, according to embodiments, a multi-SR pattern, such as parallel or sequential search, may be used, and consolidation may take the multiple responses (e.g., delivered in a multi-form HTTP (response) body) and may merges them into in a (e.g., appropriately, structured) single response.

[0118] According to embodiments, a (e.g., appropriately) structured single response may have (e.g., be) an XML-based format, for example, where‘SR’ or similar tags are used to separate replies in a (e.g., single) XML response. According to embodiments, for example, according to (e.g., depending on) a (e.g., chosen) form (e.g., format) for issuing a request to an SDM (e.g., an API call, an HTTP-based call, etc.), a response may be delivered through any of a local API call-back call and an HTTP response from the SDM to the client. According to embodiments, a client may (e.g., then) use, for example, XML parsing techniques to determine (e.g., the overall) responses provided.

[0119] FIG. 6 is a diagram illustrating a message sequence for execution of service discovery through SFCs according to embodiments.

[0120] According to embodiments, the operations and procedures (e.g., 1 - 5) discussed above for execution of service discovery through SFCs may be performed according to a message sequence chart of FIG. 6, for example, with a sequential search (e.g., of FIG. 5) over SR1 , SR2, and SR3 (e.g., of FIG. 6). According to embodiments, messages as shown in FIG. 6 may be HTTP methods; however, the disclosure is not limited thereto, and other application protocols may be used for a message sequence for executing service discovery through SFCs.

Terminal Relevance

[0121] According to embodiments, methods implemented at an SDM may be performed by (e.g., integrated into) a WTRU, for example, for some use cases. According to embodiments, a service repository may be a WTRU, for example, to discover locally provided micro-services. According to embodiments, such use cases may be applied to fog systems, for example, having service endpoints located on small device, for example, surrounding a user’s main device, and contributing to the overall (e.g., human centric) experience, for example, by offloading tasks similar as those described in our application function offloading one. According to embodiments, service repositories as well as services themselves may be (e.g., entirely) located on (e.g., such, terminal) devices. Search Engine Crawling

[0122] According to embodiments, SRs (for example, as shown in FIG. 6) may represent search engines, such as ***.com, bing.com and others. According to embodiments, a SDM may maintain a list of search engines (e.g., preconfigured or updated regularly). According to embodiments, a client may issue search request (e.g., using any of a search interface, a location bar in available web browsers, etc.), while also specifying (e.g., being able to specify) a nature of a search associated with the search request, for example, using attributes such as exhaustive, fastest, etc. According to embodiments, (e.g., such) attributes may be defined, for example, using a settings user interface (Ul) in which the user sets an attribute for (e.g., all, future) search requests. According to embodiments, an SDM may be realized (e.g., executed, instantiated, etc.), for example, on a client device using a plug-in for a (e.g., specific) browser, for example, used by the end user.

Micro Service Discovery in Transient Devices

[0123] According to embodiments, there may be a case where (e.g., dynamic) assembly of transient devices providing (e.g., human-centric) user experiences using micro services distributed over a number of execution points (e.g., mobile devices, network- based servers, etc.). According to embodiments, in order to assemble such

experiences, context and capability information may be discovered, and, for example, may be used to select a (e.g., the‘right’) instance of micro-service in a (e.g., the‘right’) execution point. According to embodiments, there may be a case of a display micro service, for example, responsible for displaying bitmap-based image content. In such a case, the display micro-service may exist on any number of devices, for example, with suitable display capabilities, such as TVs, monitors, mobile devices, wearables, etc. According to embodiments, in such a case, choosing the (e.g.,‘right’) instance may be a task that the client may perform, for example, such that the client embodies methods of a device programming entity (DPE) in a context of dynamic assembly of transient devices. According to embodiments, in the case of choosing the (e.g., the‘right’) instance, a client may (e.g., would need to) discover capabilities, for example, to choose from the available devices.

[0124] According to embodiments, in the above described case, SRs (e.g., as shown in FIG. 6) may represent specific micro-service endpoints, represented through their name, such as display.device.org or processing.device.org or receive.device.org, which may be referred to as named micro-service functions, for example, associated with Micro Service Function Chains (MSFCs). According to embodiments, a search pattern (e.g., as shown in FIG. 5) may (e.g., now) determine how to discover service

capabilities from available SRs. According to embodiments, a sequential search may be performed across all micro-services, such as, here display, then receive, then receive, with a nSFF forwarding and/or sending requests to an instance chosen by the nSFF forwarding.

[0125] According to embodiments, a client may (e.g., also) choose the fastest search with the SDM initiating a parallel search across display, receive and processing, micro service endpoints; and the SDM may receive responses as a single response, for example, separated through XML tagging in the response. According to embodiments, a selection of a service discovery pattern may be done using (e.g., realized through) a (e.g., general) setting exposed to a (e.g., end) user, for example, with attributers such as any of exhaustive, fast, and efficient being provided as a choice. According to embodiments, (e.g., such) settings may (e.g., then) be used across (e.g., all) discovery requests, for example, for micro service discovery. According to embodiments, settings may (e.g., also) be (e.g., human-centric) experience-specific, wherein a human-centric experience may be different than a device-centric experience.

Discovery in Resource Pinning

[0126] According to embodiments, SFCs may be pinned to (e.g., context-specific) service instances. That is, according to embodiments, an execution path of a micro service request may be pinned to (e.g., along a, specific) set of micro-service instances. For example, there may be use cases, such as a transient device use case and a 5G control plane use case. According to embodiments, in such use cases (e.g., common to both is that), a discovery step may target an availability of micro-services, for example, in/at a specific execution point, such as a network function host (NFH), for example, rather than the capabilities of the specific micro-service. According to embodiments, in a case of micro-services, there may be discovery of provided micro-services in each NFH, such as an NFH representing a compute cluster such as any of a server and an (e.g., end) user terminal. According to embodiments, a list of micro-service names may be a result of a service discovery (e.g., request, from an end-user). For example, according to embodiments, a discovery result may be a list of micro-service names, for example, that may (e.g., then) pinned against execution of a (e.g., specific) SFC. [0127] According to embodiments, in a case of a transient device, for example, instead of discovering the micro-service capability, SRs may (e.g., now) represent SFHs, for example, in which the micro-services are hosted. According to embodiments, for example, any of TVs, user terminals and/or server may expose an SFH FQDN (e.g., SFFI1.service.com, SFFI12.service.com, etc.), which is any of known to the SDM or advertised (e.g., using existing mDNS solutions in a local network). According to embodiments, a client may (e.g., now) issue a discovery request, for example, to discover micro-services available on each (e.g., of those) execution point (e.g., SFFIs), for example, by selecting any of fastest search, exhaustive search, efficient search, etc.

[0128] According to embodiments, attributes of (e.g., a) selection may be translated. For example, attributes may be translated in the discovery through a parallel search across all known SFFIs for any of a fastest search, a sequential search, and an efficient search (e.g., efficiency occurring because an originating client device only sends one request over its (e.g., constrained) wireless interface, distributing costs for discovery across all SFFIs. According to embodiments, for example, upon receiving a (e.g., service discovery) result, a client may (e.g., now) receive a list of (e.g., all available) micro services in (e.g., all queried) SFFIs. According to embodiments, a client may (e.g., now) use the result (e.g., apply as a solution) to pin an execution path for its service to specific instances in the discovered SFFIs. According to embodiments, the features described herein with respect to the transient device use case may be (e.g., similarly) applied for (e.g., a use case of) selecting 5G control plane services in SFFIs, for example, wherein a SFFI may represent compute clusters provided by operators for the realization of the various 5G control plane services.

[0129] According to embodiments, discovery for the pinning of SFCs to context-specific service instances may (e.g., also) be combined with the discovery of capabilities of specific service instances. For example, according to embodiments, in a case of (e.g., after) discovering that specific micro-services, such as for display.device.org, are being hosted at a set of (e.g., specific) SFFIs, a SDM may use this set of SFFIs as another set of SRs. In such a case, according to embodiments, an SDM may (e.g., then) perform a secondary discovery with this secondary set of SRs, for example, to discover the capabilities of each micro-service (e.g., a display micro-service), for example, in order to select an (e.g., right) instance in the pinned service execution path.

[0130] According to embodiments, a search strategy for a (e.g., the) secondary discovery may (e.g., now) be different from a (e.g., first) strategy used to discover the available micro-service in each SFH. According to embodiments, a realization of selecting a service discovery protocol may use any of a system-wide and application- specific setting, for example, that is exposed to a (e.g., end) user, for example, which be similar to that as in the above discussed use cases. According to embodiments, methods described herein may (e.g., easily) be detected through packet inspection, for example, in application protocol realizations such as via HTTP. According to

embodiments, naming to select specific service instances may be exposed to a transport network, for example, and may be visible in interactions.

Conclusion

[0131] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in 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, a read only memory (ROM), random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU 102, UE, terminal, base station, RNC, or any host computer.

[0132] Moreover, in the embodiments described above, processing platforms, computing systems, controllers, and other devices containing processors are noted. These devices may contain at least one Central Processing Unit ("CPU") and memory.

In accordance with the practices of persons skilled in the art of computer programming, reference to acts and symbolic representations of operations or instructions may be performed by the various CPUs and memories. Such acts and operations or

instructions may be referred to as being "executed", "computer executed", or "CPU executed".

[0133] One of ordinary skill in the art will appreciate that the acts and symbolically represented operations or instructions include the manipulation of electrical signals by the CPU. An electrical system represents data bits that can cause a resulting transformation or reduction of the electrical signals and the maintenance of data bits at memory locations in a memory system to thereby reconfigure or otherwise alter the CPU's operation, as well as other processing of signals. The memory locations where data bits are maintained are physical locations that have particular electrical, magnetic, optical, or organic properties corresponding to or representative of the data bits. It should be understood that the exemplary embodiments are not limited to the above- mentioned platforms or CPUs and that other platforms and CPUs may support the provided methods.

[0134] The data bits may 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 system readable by the CPU. The computer readable medium may include cooperating or interconnected computer readable medium, which exist exclusively on the processing system or are distributed among multiple interconnected processing systems that may be local or remote to the processing system. It is understood that the representative embodiments are not limited to the above-mentioned memories and that other platforms and memories may support the described methods.

[0135] In an illustrative 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 unit, a network element, and/or any other computing device.

[0136] There is little distinction left between hardware and software implementations of aspects of systems. The use of hardware or software is generally (but not always, in that in certain contexts the choice between hardware and software may become significant) a design choice representing cost vs. efficiency tradeoffs. There may be various vehicles by which processes and/or systems and/or other technologies described herein may be affected (e.g., hardware, software, and/or firmware), and the preferred vehicle may vary with the context in which the processes and/or systems and/or other technologies are deployed. For example, if an implementer determines that speed and accuracy are paramount, the implementer may opt for a mainly hardware and/or firmware vehicle. If flexibility is paramount, the implementer may opt for a mainly software implementation. Alternatively, the implementer may opt for some combination of hardware, software, and/or firmware.

[0137] The foregoing detailed description has set forth various embodiments of the devices and/or processes via the use of block diagrams, flowcharts, and/or examples. Insofar as such block diagrams, flowcharts, and/or examples contain one or more functions and/or operations, it will be understood by those within the art that each function and/or operation within such block diagrams, flowcharts, or examples may be implemented, individually and/or collectively, by a wide range of hardware, software, firmware, or virtually any combination thereof. Suitable processors include, by way of example, a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller,

Application Specific Integrated Circuits (ASICs), Application Specific Standard Products (ASSPs); Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (1C), and/or a state machine.

[0138] Although features and elements are provided above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. The present disclosure is not to be limited in terms of the particular embodiments described in this application, which are intended as illustrations of various aspects. Many modifications and variations may be made without departing from its spirit and scope, as will be apparent to those skilled in the art. No element, act, or instruction used in the description of the present application should be construed as critical or essential to the invention unless explicitly provided as such. Functionally equivalent methods and apparatuses within the scope of the disclosure, in addition to those enumerated herein, will be apparent to those skilled in the art from the foregoing descriptions. Such modifications and variations are intended to fall within the scope of the appended claims. The present disclosure is to be limited only by the terms of the appended claims, along with the full scope of equivalents to which such claims are entitled. It is to be understood that this disclosure is not limited to particular methods or systems.

[0139] It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only, and is not intended to be limiting. As used herein, when referred to herein, the terms“station” and its abbreviation“STA”, "user equipment" and its abbreviation "UE" may mean (i) a wireless transmit and/or receive unit (WTRU), such as described infra; (ii) any of a number of embodiments of a WTRU, such as described infra; (iii) a wireless-capable and/or wired-capable (e.g., tetherable) device configured with, inter alia, some or all structures and functionality of a WTRU, such as described infra; (iii) a wireless-capable and/or wired-capable device configured with less than all structures and functionality of a WTRU, such as described infra; or (iv) the like.

[0140] In certain representative embodiments, several 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. Flowever, those skilled in the art will recognize that some aspects of the embodiments disclosed herein, in whole or in part, may be equivalently implemented in integrated circuits, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or as virtually any combination thereof, and that designing the circuitry and/or writing the code for the software and or firmware would be well within the skill of one of skill in the art in light of this disclosure. In addition, those skilled in the art will appreciate that the mechanisms of the subject matter described herein may be distributed as a program product in a variety of forms, and that an illustrative embodiment of the subject matter described herein applies regardless of the particular type of signal bearing medium used to actually carry out the distribution. Examples of a signal bearing medium include, but are not limited to, the following: a recordable type medium such as a floppy disk, a hard disk drive, a CD, a DVD, a digital tape, a computer memory, etc., and a transmission type medium such as a digital and/or an analog communication medium (e.g., a fiber optic cable, a waveguide, a wired communications link, a wireless communication link, etc.).

[0141] The herein described subject matter sometimes illustrates different components contained within, or connected with, different other components. It is to be understood that such depicted architectures are merely examples, and that in fact many other architectures may be implemented which achieve the same functionality. In a conceptual sense, any arrangement of components to achieve the same functionality is effectively "associated" such that the desired functionality may be achieved. Flence, any two components herein combined to achieve a particular functionality may be seen as "associated with" each other such that the desired functionality is achieved, irrespective of architectures or intermediate components. Likewise, any two

components so associated may also be viewed as being "operably connected", or "operably coupled", to each other to achieve the desired functionality, and any two components capable of being so associated may also be viewed as being "operably couplable" to each other to achieve the desired functionality. Specific examples of operably couplable include but are not limited to physically mateable and/or physically interacting components and/or wirelessly interactable and/or wirelessly interacting components and/or logically interacting and/or logically interactable components.

[0142] With respect to the use of substantially any plural and/or singular terms herein, those having skill in the art can translate from the plural to the singular and/or from the singular to the plural as is appropriate to the context and/or application. The various singular/plural permutations may be expressly set forth herein for sake of clarity.

[0143] It will be understood by those within the art that, in general, terms used herein, and especially in the appended claims (e.g., bodies of the appended claims) are generally intended as "open" terms (e.g., the term "including" should be interpreted as "including but not limited to," the term "having" should be interpreted as "having at least," the term "includes" should be interpreted as "includes but is not limited to," etc.).

It will be further understood by those within the art that if a specific number of an introduced claim recitation is intended, such an intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example, where only one item is intended, the term "single" or similar language may be used. As an aid to understanding, the following appended claims and/or the descriptions herein may contain usage of the introductory phrases "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be construed to imply that the introduction of a claim recitation by the indefinite articles "a" or "an" limits any particular claim containing such introduced claim recitation to embodiments containing only one such recitation, even when the same claim includes the introductory phrases "one or more" or "at least one" and indefinite articles 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 holds true for the use of definite articles used to introduce claim recitations. In addition, even if a specific number of an introduced claim recitation is explicitly recited, those skilled in the art will recognize that such recitation should be interpreted to mean at least the recited number (e.g., the bare recitation of "two recitations," without other modifiers, means at least two recitations, or two or more recitations). Furthermore, in those instances where a convention analogous to "at least one of A, B, and C, etc." is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (e.g., "a system having at least one of A, B, and C" would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and/or A, B, and C together, etc.). In those instances where a convention analogous to "at least one of A, B, or C, etc." is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (e.g., "a system having at least one of A, B, or C" would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and/or A, B, and C together, etc.). It will be further understood by those within the art that virtually any disjunctive word and/or phrase presenting two or more alternative terms, whether in the description, claims, or drawings, should be understood to contemplate the possibilities of including one of the terms, either of the terms, or both terms. For example, the phrase "A or B" will be understood to include the possibilities of "A" or "B" or "A and B". Further, the terms "any of" followed by a listing of a plurality of items and/or a plurality of categories of items, as used herein, are intended to include "any of," "any combination of," "any multiple of," and/or "any combination of multiples of" the items and/or the categories of items, individually or in conjunction with other items and/or other categories of items. Moreover, as used herein, the term "set" or“group” is intended to include any number of items, including zero. Additionally, as used herein, the term "number" is intended to include any number, including zero.

[0144] In addition, where features or aspects of the disclosure are described in terms of Markush groups, those skilled in the art will recognize that the disclosure is also thereby described in terms of any individual member or subgroup of members of the Markush group.

[0145] As will be understood by one skilled in the art, for any and all purposes, such as in terms of providing a written description, all ranges disclosed herein also encompass any and all possible subranges and combinations of subranges thereof. Any listed range can be easily recognized as sufficiently describing and enabling the same range being broken down into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each range discussed herein may be readily broken down into a lower third, middle third and upper third, etc. As will also be understood by one skilled in the art all language such as "up to", "at least", "greater than", "less than", and the like includes the number recited and refers to ranges which can be subsequently broken down into subranges as discussed above. Finally, as will be understood by one skilled in the art, a range includes each individual member. Thus, for example, a group having 1 -3 cells refers to groups having 1 , 2, or 3 cells. Similarly, a group having 1-5 cells refers to groups having 1 , 2, 3, 4, or 5 cells, and so forth.

[0146] Moreover, the claims should not be read as limited to the provided order or elements unless stated to that effect. In addition, use of the terms "means for" in any claim is intended to invoke 35 U.S.C. §112(f)or means-plus-function claim format, and any claim without the terms "means for" is not so intended.

[0147] Although the invention is illustrated and described herein with reference to specific 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 and range of equivalents of the claims and without departing from the invention.

[0148] Throughout the disclosure, one of skill understands that certain representative embodiments may be used in the alternative or in combination with other representative embodiments.

[0149] Although features and elements are described above in particular

combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in 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, a read only memory (ROM), random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WRTU, UE, terminal, base station, RNC, or any host computer.

[0150] Moreover, in the embodiments described above, processing platforms, computing systems, controllers, and other devices containing processors are

noted. These devices may contain at least one Central Processing Unit ("CPU") and memory. In accordance with the practices of persons skilled in the art of computer programming, reference to acts and symbolic representations of operations or instructions may be performed by the various CPUs and memories. Such acts and operations or instructions may be referred to as being "executed”, "computer executed”, or "CPU executed”. [0151] One of ordinary skill in the art will appreciate that the acts and symbolically represented operations or instructions include the manipulation of electrical signals by the CPU. An electrical system represents data bits that can cause a resulting transformation or reduction of the electrical signals and the maintenance of data bits at memory locations in a memory system to thereby reconfigure or otherwise alter the CPU's operation, as well as other processing of signals. The memory locations where data bits are maintained are physical locations that have particular electrical, magnetic, optical, or organic properties corresponding to or representative of the data bits.

[0152] The data bits may 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 system readable by the CPU. The computer readable medium may include cooperating or interconnected computer readable medium, which exist exclusively on the processing system or are distributed among multiple interconnected processing systems that may be local or remote to the processing system. It is understood that the representative embodiments are not limited to the above-mentioned memories and that other platforms and memories may support the described methods.

[0153] No element, act, or instruction used in the description of the present application should be construed as critical or essential to the invention unless explicitly described as such. In addition, as used herein, the article "a" is intended to include one or more items. Where only one item is intended, the term "one" or similar language is used. Further, the terms "any of followed by a listing of a plurality of items and/or a plurality of categories of items, as used herein, are intended to include "any of," "any combination of," "any multiple of," and/or "any combination of multiples of the items and/or the categories of items, individually or in conjunction with other items and/or other categories of items. Further, as used herein, the term "set" is intended to include any number of items, including zero. Further, as used herein, the term "number" is intended to include any number, including zero.

[0154] Moreover, the claims should not be read as limited to the described order or elements unless stated to that effect. In addition, use of the term "means" in any claim is intended to invoke 35 U.S.C. §112(f), and any claim without the word "means" is not so intended.

[0155] Suitable processors include, by way of example, a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Application Specific Standard Products (ASSPs); Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (1C), and/or a state machine.

[0156] A processor in association with software may be used to implement a radio frequency transceiver for use in a wireless transmit receive unit (WRTU), user equipment (UE), terminal, base station, Mobility Management Entity (MME) or Evolved Packet Core (EPC), or any host computer. The WRTU may be used m conjunction with modules, implemented in hardware and/or software including a Software Defined Radio (SDR), and other components such as a camera, a video camera module, a

videophone, a speakerphone, a vibration device, a speaker, a microphone, a television transceiver, a hands free headset, a keyboard, a Bluetooth® module, a frequency modulated (FM) radio unit, a Near Field Communication (NFC) Module, a liquid crystal display (LCD) display unit, an organic light-emitting diode (OLED) display unit, a digital music player, a media player, a video game player module, an Internet browser, and/or any Wireless Local Area Network (WLAN) or Ultra Wide Band (UWB) module.

[0157] Although the invention has been described in terms of communication systems, it is contemplated that the systems may be implemented in software on

microprocessors/general purpose computers (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.

[0158] In addition, although the invention is illustrated and described herein with reference to specific 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 and range of equivalents of the claims and without departing from the invention.

Claims

CLAIMS What is claimed is:

1 . A method performed by a wireless transmit/receive unit (WTRU) executing a System Discovery Manager (SDM) for performing service discovery using a service function chain (SFC), the method comprising:

obtaining information associated with a service discovery pattern;

selecting a service discovery pattern according to information associated with the service discovery pattern;

generating a network service header (NSH) according to the selected service discovery pattern;

transmitting a service discovery request to a first hop of an SFC using the NSFI; receiving more than one results of the service discovery request from more than one hops of the SFC according to the NSFI; and

transmitting, to an initiator of the service discovery, a result of the service discovery including information associated with any of the received more than one results of the service discovery request.

2. The method of claim 1 , wherein the information associated with the service discovery pattern is received from the initiator of the service discovery.

3. The method of claim 1 , wherein the initiator of the service discovery is an end user of a wireless transmit/receive unit (WTRU).

4. The method of claim 1 , wherein the service discovery pattern is selected by the end user, and

wherein the information associated with the service discovery pattern includes attributes associated with the service discovery.

5. The method of claim 1 , wherein the service discovery request includes information indicating service repositories (SRs) selected by the end-user.

6. The method of claim 1 , wherein the first hop of the SFC is a named-service function forwarder (nSFF).

7. The method of claim 1 , wherein the NSH is transmitted with an HTTP discovery request as a payload, and

wherein a payload of NSH includes information associated with the results of the service discovery request.

8. A wireless transmit/receive unit (WTRU), including any of a transmitter, a receiver, a memory, and a processor, for ) executing a System Discovery Manager (SDM) for performing service discovery using a service function chain (SFC), the WTRU configured to:

obtain information associated with a service discovery pattern;

select a service discovery pattern according to information associated with the service discovery pattern;

generate a network service header (NSH) according to the selected service discovery pattern;

transmit a service discovery request to a first hop of an SFC using the NSH;

receive more than one results of the service discovery request from more than one hops of the SFC according to the NSH; and

transmit, to an initiator of the service discovery, a result of the service discovery including information associated with any of the received more than one results of the service discovery request.

9. The WTRU of claim 8, wherein the information associated with the service discovery pattern is received from the initiator of the service discovery.

10. The WTRU of claim 8, wherein the initiator of the service discovery is an end user of a wireless transmit/receive unit (WTRU).

1 1 . The WTRU of claim 8, wherein the service discovery pattern is selected by the end user, and

wherein the information associated with the service discovery pattern includes attributes associated with the service discovery.

12. The WTRU of claim 8, wherein the service discovery request includes information indicating service repositories (SRs) selected by the end-user.

13. The WTRU of claim 8, wherein the first hop of the SFC is a named-service function forwarder (nSFF).

14. The WTRU of claim 8, wherein the NSFI is transmitted with an FITTP discovery request as a payload, and

wherein a payload of NSFI includes information associated with the results of the service discovery request.

15. A method implemented in a wireless transmit/receive unit (WTRU), for service discovery in an Information Centric Network (ICN), the method comprising:

a client on the WTRU issuing to a Network Access Point (NAP) a HyperText Transfer Protocol (HTTP) service discovery request, the HTTP service discovery request including a domain name of a service repository; and

the client receiving a merged service discovery response including information from a plurality of responding service function entities (SFEs) in the network

corresponding to the domain name.

16. The method of claim 15, wherein the WTRU comprises the NAP, the method further comprising:

the NAP publishing to a Path Computation Element (PCE) of the network an ICN message including the domain name;

the NAP receiving from the PCE in response to the publishing, a forwarding identifier (FID) message including a FID toward the plurality of SFEs;

the NAP, in response, publishing a message to the ICN including the FID, an identity of the client, and the HTTP service discovery request;

the NAP receiving from each of the plurality of SFEs a service discovery response message; and

the NAP merging the service discovery response messages from the plurality of SFEs and sending the merged response to the client.

17. The method of claim 16, wherein the ICN message includes a flag set to indicate that one-to-many matching of results is to be implemented on the request.

18. The method of claim 16, wherein the FID message further includes a number, N, of the plurality of SFEs and wherein the NAP waits for N service discovery responses to be received before sending the merged response to the client.

19. The method of claim 16, wherein the FID message further includes a number, N, of the plurality of SFEs and wherein the NAP waits for the earlier of (1 ) N service discovery responses to be received, and (2) expiration of a timer, before sending the merged response to the client.

20. The method of claim 16, wherein each of the plurality of service discovery responses includes a Return Content ID (rCID) and wherein the NAP associates the plurality of service discovery responses with the FITTP service discovery request according to the rCIDs.