Method, apparatus, and system for discovering edge network management servers

Abstract

To provide a method, an apparatus, a system, an architecture, and an interface for a wireless transmit / receive unit (WTRU) to discover available edge network (EN) management (ENM) servers associated with either an edge network (EN) service and an EN application.SOLUTION: A method may include sending a first message to a core network entity including information indicating a request for discovery of an ENM server, receiving a second message from the core network entity responding to the request for discovery of an ENM server, the second message includes ENM server information indicating (1) any number of available ENM servers and (2) respective available ENM server endpoint information, and performs communication with one or more of the available ENM servers.SELECTED DRAWING: Figure 2

Description

[Background technology]

[0001] The present invention relates to the field of computing and communications, and more specifically to methods, apparatus, systems, architectures, and interfaces for computing and communications in advanced or next-generation wireless communication systems, including communications performed using new wireless and / or new wireless (NR) access technologies and communication systems. Such NR access and technologies, sometimes called 5G, can provide and may require edge computing, sometimes called fog networking and / or ubiquitous computing. Use cases such as vehicle automation, including cars and drones, real-time augmented reality (AR), and immersive games represent just a few technically advanced use cases that may require edge computing, for example, for low latency support. While implementations of such use cases have been attempted using conventional network capabilities and technologies, such implementations remain insufficient and limited in their features, such as being in controlled environments and / or using specialized hardware.

[0002] Edge computing may be similar to (e.g., conventional) cloud computing, but edge computing has its own set of unique challenges. For example, in the case of (e.g., conventional) cloud computing networks, existing discovery and / or routing mechanisms operate assuming that the services are centrally located, and such services provide equivalent performance and / or functionality. However, both assumptions are inaccurate in the case of edge computing because the services are deployed in a decentralized manner and / or are located near the consumption points. In such cases, depending on the selected service instance, such services may not provide the same latency to the end user. The European Telecommunications Standards Institute (ETSI) - Multi-Access Edge Computing (MEC) and the 3rd Generation Partnership Project (3GPP) 5G Edge Computing Group are focused on characterizing and solving such edge computing problems.

[0003] Solving such edge computing problems may involve dealing with Domain Name System / Service / Server (DNS) technology. DNS provides a worldwide distributed directory service and is an essential component of the Internet as it is used in both public and private networks. DNS translates a fully qualified domain name (FQDN) that identifies an application or service to the IP address required to locate and identify computer resources within the IP address space where the application and service are available.

[0004] In distributed (e.g., traditional) cloud services, the function of DNS is to optimize user delivery by providing different IP addresses for the same FQDN, for example, directing users to nearby servers for low latency. Such DNS functionality is provided using DNS communication, which has a message structure of five sections: (1) header, (2) query (e.g., a query for DNS), (3) answer (e.g., a resource record (RR) that answers the query), (4) authorization (e.g., an RR pointing to authorization), and (5) append (e.g., an RR holding additional information). The header is always present and specifies which of the remaining sections is present. The header includes a 16-bit identifier (ID) used in both requests and responses, a set of bits describing the message, and four counters indicating the number of records in the other sections. The query includes fields describing the question / query sent to the name server and consists of the query type (QTYPE), query class (QCLASS), and query domain name (QNAME) fields. The response, authorization, and additional sections shall have the same format, each being a list of RRs, and each may be empty. Furthermore, the DNS message format discussed herein may be similar to that described and / or defined by the Internet Engineering Task Force (IETF).

[0005] For example, edge computing, as described by 3GPP, can be considered a network architecture concept that enables the deployment of cloud computing capabilities and service environments at the edge networks of, for example, 3GPP cellular networks. Edge computing can enable lower latency, higher bandwidth, reduced backhaul traffic, and new services. Furthermore, edge computing can be considered part of the evolution of mobile networks and the convergence of IT and telecommunications / wireless networking, as described by, for example, the Multi-Access Edge Computing (MEC) Industry Specification Group (ISG) of the European Telecommunications Standards Institute (ETSI). Multi-access edge computing delivers vertical business segments and services to consumer and enterprise customers, enabling software applications to access / use real-time information about local content and local access network conditions. Furthermore, the mobile core network is further congested (for example, to serve local purposes efficiently) when services and caching content are deployed at the network edge. Moreover, edge computing can be seen as needed (e.g., essential) to enable various technologically advanced use cases such as vehicle / drone automation, real-time AR / VR, and immersive gaming. [Brief explanation of the drawing]

[0006] A more detailed understanding can be obtained from the following description, which is given as an example in conjunction with the attached drawings, where similar reference numbers in the drawings indicate similar elements. [Figure 1A] This is a system diagram showing an exemplary communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] This is a system diagram showing an exemplary wireless transmit / receive unit (WTRU) that may be used in the communication system shown in Figure 1A, according to one embodiment. [Figure 1C] This is a system diagram showing an exemplary radio access network (RAN) and an exemplary core network (CN) that may be used in the communication system shown in Figure 1A according to one embodiment. [Figure 1D] This is a system diagram showing further exemplary RAN and further exemplary CN that may be used in the communication system shown in Figure 1A according to one embodiment. [Figure 2] This diagram shows the 3GPP architecture for enabling edge applications. [Figure 3] This figure shows the ETSI-MEC reference architecture (e.g., framework). [Figure 4] This figure shows the client discovery of an ENM server with address assignment according to an embodiment. [Figure 5] This figure shows the client discovery process for an ENM server that does not have IP address assignment, according to an embodiment. [Figure 6] This figure shows a DHCP server that filters ENM servers based on requirements, according to an embodiment. [Figure 7] This figure shows a client that selects an ENM server according to an embodiment. [Figure 8] This figure shows a client rediscovering the ENM server according to an embodiment. [Figure 9] This figure shows the EXS discovery process according to the embodiment. [Figure 10] This figure shows the EXS discovery process according to the embodiment. [Figure 11] This figure shows the EXS discovery process according to the embodiment. [Figure 12] This figure shows the association between EEC and AC based on cardinality according to the embodiment. [Figure 13] This figure shows ECS provisioning according to an embodiment. [Modes for carrying out the invention]

[0007] Exemplary network for implementing the embodiment Figure 1A shows an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, message transmission, and broadcast to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique-word DFT-Spread OFDM (ZT UW DTS-s OFDM), unique-word OFDM (UW-OFDM), resource block filtering OFDM, and filter bank multicarrier (FBMC).

[0008] As shown in Figure 1A, the communication system 100 may include radio transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, but it will be understood that the disclosed embodiments intend 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 radio environment. For example, WTRU102a, 102b, 102c, and 102d, any of which may be referred to as “station” and / or “STA”, may be configured to transmit and / or receive radio signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscriber-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, radio sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other radio devices operating in an industrial and / or automated processing chain context), consumer electronics devices, and devices operating in commercial and / or industrial radio networks. Any of WTRU102a, 102b, 102c, and 102d may interchangeably be referred to as UE.

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

[0010] Base station 114a may be part of 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), and relay nodes. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage of radio services to a specific geographic area that may be relatively fixed or change over time. A cell may be further divided into cell sectors. For example, a cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver per sector of the cell. In one embodiment, the base station 114a may use 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 a desired spatial direction.

[0011] Base stations 114a and 114b may communicate with one or more WTRUs 102a, 102b, 102c, and 102d via an air interface 116, which may be any suitable radio 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).

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

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

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

[0015] In one 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 example, using the dual connectivity (DC) principle. Accordingly, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by transmissions to / from multiple types of radio access technologies and / or multiple types of base stations (e.g., eNBs and gNBs).

[0016] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement wireless 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), etc.

[0017] The base station 114b in Figure 1A may be, for example, a wireless router, home node B, home eNode B, or access point, and may utilize any suitable RAT to facilitate wireless connectivity in local areas such as offices, homes, vehicles, campuses, industrial facilities, aerial corridors (for use by drones), roads, etc. In one embodiment, the base station 114b and WTRU 102c, 102d may implement wireless technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and WTRU 102c, 102d may implement wireless technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base stations 114b and WTRUs 102c, 102d may establish picocells or femtocells using cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.). As shown in Figure 1A, base station 114b may have a direct connection to the internet 110. Therefore, base station 114b may not need to access the internet 110 via CN 106 / 115.

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

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

[0020] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 may include multimode capability (for example, WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers for communicating with different radio networks via different radio links). For example, WTRU 102c shown in Figure 1A may be configured to communicate with base station 114a, which may use cellular-based radio technology, and base station 114b, which may use IEEE 802 radio technology.

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

[0022] The processor 118 may be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 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 a transceiver 120 which may be coupled to a transmit / receive element 122. Figure 1B shows the processor 118 and transceiver 120 as separate components, but it will be understood that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

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

[0024] Although the transmit / receive element 122 is shown as a single element in Figure 1B, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may utilize 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 radio signals via the air interface 116.

[0025] The transceiver 120 may be configured to modulate the signal transmitted by the transmit / receive element 122 and demodulate the signal received by the transmit / receive element 122. As described above, the WTRU 102 may have multimode capability. Therefore, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

[0026] The processor 118 of the WTRU102 may be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light-emitting diode (OLED) display unit) and may receive user input from these. The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. Furthermore, the processor 118 may access information from any type of suitable memory, such as non-removable memory 130 and / or removable memory 132, and store data in memory. 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 in memory that is not physically located on the WTRU 102, such as on a server or home computer (not shown), and store data in the memory.

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

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

[0029] The processor 118 may be further coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functions, and / or wired or wireless connectivity. For example, peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), 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 peripheral device 138 may include one or more sensors, which may be one or more of the following: gyroscope, accelerometer, Hall effect sensor, magnetometer, compass sensor, proximity sensor, temperature sensor, time sensor, geolocation sensor, altimeter, light sensor, touch sensor, magnetometer, barometer, gesture sensor, biometric sensor, and / or humidity sensor.

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

[0031] Figure 1C is a system diagram illustrating RAN104 and CN106 according to one embodiment. As described above, RAN104 can communicate with WTRU102a, 102b, and 102c via the air interface 116 using E-UTRA wireless technology. RAN104 can also communicate with CN106.

[0032] RAN104 may include eNode-B160a, 160b, and 160c, but it will be understood that RAN104 may include any number of eNode-B while maintaining consistency with one embodiment. Each of eNode-B160a, 160b, and 160c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, eNode-B160a, 160b, and 160c may implement MIMO technology. Thus, eNode-B160a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU102a.

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

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

[0035] The MME162 can be connected to each of the eNode-B160a, 160b, and 160c within RAN104 via the S1 interface and can function as a control node. For example, the MME162 may perform roles such as authenticating users of WTRU102a, 102b, and 102c, activating / deactivating bearers, and selecting gateways for specific services during the initial attachment of WTRU102a, 102b, and 102c. The MME162 may provide control plane functionality for switching between RAN104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0036] The SGW164 can be connected to each of the eNode-B160a, 160b, and 160c in RAN104 via the S1 interface. The SGW164 can generally route and forward user data packets to and from WTRU102a, 102b, and 102c. The SGW164 can perform other functions, such as anchoring the user plane during eNode-B handovers, triggering paging when DL data is available to WTRU102a, 102b, and 102c, and managing and remembering the context of WTRU102a, 102b, and 102c.

[0037] SGW164 may be connected to PGW166, which may provide WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices.

[0038] CN106 can facilitate communication with other networks. For example, CN106 can provide WTRU102a, 102b, and 102c with access to a circuit-switched network such as PSTN108 to facilitate communication between WTRU102a, 102b, and 102c and conventional terrestrial line communication devices. For example, CN106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN106 and PSTN108. Furthermore, CN106 can provide WTRU102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0039] Although the WTRU is shown as a wireless terminal in Figures 1A to 1D, in certain representative embodiments, such a terminal is intended to be able to use a wired communication interface (e.g., temporary or permanent) with a communication network.

[0040] In a typical embodiment, the other network 112 may be a WLAN.

[0041] A WLAN in Basic Service Set (BSS) mode may have access points (APs) of the BSS and one or more stations (STAs) associated with the APs. APs may have access to or interfaces with another type of wired / wireless network carrying traffic into and / or out of the Distribution System (DS) or BSS. Traffic originating outside the BSS and destined for the STAs may reach and be delivered to the STAs via the APs. Traffic originating from the STAs and destined for destinations outside the BSS may be sent to the APs and then delivered to their respective destinations. Traffic between STAs within the BSS may be transmitted, for example, via APs; a source STA may send traffic to the AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be transmitted between a source STA and a destination STA (for example, directly between them) via a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using Independent BSS (IBSS) mode may not have APs, and STAs within or using IBSS (e.g., all STAs) may communicate directly with each other. The IBSS mode of communication may be referred to herein as the “ad hoc” communication mode.

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

[0043] High-throughput (HT) STAs may use a 40 MHz wide channel for communication, which may be formed, for example, through a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels.

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

[0045] Sub-1GHz operating modes are supported by 802.11af and 802.11ah. Channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the TV White Space (TVWS) spectrum, while 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using the non-TVWS spectrum. According to a typical embodiment, 802.11ah may support meter-type control / machine-type communications, such as MTC devices in a macro coverage area. MTC devices may have limited capabilities, including, for example, support for specific and / or limited bandwidths (e.g., support only for those bandwidths). MTC devices may include batteries with battery life exceeding a threshold (for example, to maintain a very long battery life).

[0046] A WLAN system capable of supporting multiple channels and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah includes a channel that can be designated as the primary channel. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by an STA from among all STAs operating in a BSS that supports the minimum bandwidth operating mode. In the 802.11ah example, the primary channel may be 1 MHz wide for an STA (e.g., an MTC type device) that supports (e.g., only) the 1 MHz mode, even if other STAs in the AP and 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 state of the primary channel. For example, if the primary channel is busy due to an STA (supporting only the 1 MHz operating mode) transmitting to the AP, the entire available frequency band may be considered busy, even if a large portion of the frequency band remains idle and could be available.

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

[0048] Figure 1D is a system diagram showing RAN113 and CN115 according to one embodiment. As described above, RAN113 can communicate with WTRU102a, 102b, and 102c via air interface 116 using NR radio technology. RAN113 can also communicate with CN115.

[0049] RAN113 may include gNB180a, 180b, and 180c, but it will be understood that RAN113 may include any number of gNBs while maintaining consistency with one embodiment. Each of gNB180a, 180b, and 180c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, gNB180a, 180b, and 180c may implement MIMO technology. For example, gNB180a and 108b may use beamforming to transmit and / or receive signals to gNB180a, 180b, and 180c. Thus, gNB180a may, for example, use multiple antennas to transmit and / or receive radio signals from WTRU102a. In one embodiment, gNB180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB180a may transmit multiple component carriers to WTRU102a (not shown). A subset of these component carriers may be on the unauthorized spectrum, and the remaining component carriers may be on the authorized spectrum. In one embodiment, gNB180a, 180b, and 180c may implement coordinated multi-point (CoMP) technology. For example, WTRU102a may receive coordinated transmissions from gNB180a and gNB180b (and / or gNB180c).

[0050] WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using transmissions associated with scalable numerology. For example, OFDM symbol intervals and / or OFDM subcarrier intervals may vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of varying or scalable lengths (e.g., containing varying numbers of OFDM symbols and / or having varying absolute time durations).

[0051] gNB180a, 180b, and 180c can be configured to communicate with WTRU102a, 102b, and 102c in standalone and / or non-standalone configurations. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c without accessing other RANs (e.g., eNode-B160a, 160b, and 160c). In a standalone configuration, WTRU102a, 102b, and 102c can utilize one or more of gNB180a, 180b, and 180c as mobility anchor points. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using signals in unlicensed bands. In a non-standalone configuration, WTRU102a, 102b, and 102c can communicate with and connect to gNB180a, 180b, and 180c, while also communicating with and connecting to other RANs such as eNode-B160a, 160b, and 160c. For example, WTRU102a, 102b, and 102c can implement DC principles for substantially simultaneous communication with one or more gNB180a, 180b, and 180c and one or more eNode-B160a, 160b, and 160c. In a non-standalone configuration, eNode-B160a, 160b, and 160c can function as mobility anchors for WTRU102a, 102b, and 102c, while gNB180a, 180b, and 180c can provide additional coverage and / or throughput to service WTRU102a, 102b, and 102c.

[0052] Each of the gNB180a, 180b, and 180c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, support for network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data to User Plane Functions (UPFs) 184a and 184b, routing of control plane information to Access and Mobility Management Functions (AMFs) 182a and 182b, and so on. As shown in Figure 1D, the gNB180a, 180b, and 180c may communicate with each other via the Xn interface.

[0053] The CN115 shown in Figure 1D may include at least one AMF182a, 182b, at least one UPF184a, 184b, at least one Session Management Function (SMF)183a, 183b, and optionally a Data Network (DN)185a, 185b. Although each of the aforementioned elements is shown as part of the CN115, it will be understood that any of these elements may be owned and / or operated by entities other than the CN operator.

[0054] AMF182a and 182b can be connected to one or more gNB180a, 180b, and 180c in RAN113 via the N2 interface and can function as control nodes. For example, AMF182a and 182b can perform roles such as user authentication for WTRU102a, 102b, and 102c, support network slicing (e.g., handling different PDU sessions with different requirements), selection of specific SMF183a and 183b, management of registration areas, termination of NAS signaling, and mobility management. Network slicing can be used by AMF182a and 182b to customize CN support for WTRU102a, 102b, and 102c based on the type of service utilizing WTRU102a, 102b, and 102c. 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 similar. The AMF162 may provide control plane functionality for switching between RAN113 and other RANs (not shown) employing other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

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

[0056] UPF184a and 184b may be connected via the N3 interface to one or more of gNB180a, 180b, and 180c in RAN113, which may provide WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices. UPF184 and 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, and providing mobility anchoring.

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

[0058] As can be seen from Figures 1A to 1D and their corresponding descriptions, one or more of the functions described herein relating to one or more of the WTRU102a to d, base stations 114a to b, eNode-B160a to c, MME162, SGW164, PGW166, gNB180a to c, AMF182a to b, UPF184a to b, SMF183a to b, DN185a to b, and / or any other devices described herein may be implemented by one or more emulation devices (not shown). An emulation device may be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0059] Emulation devices may be designed to implement testing of one or more other devices in a laboratory and / or operator network environment. For example, one or more emulation devices may perform one or more or all functions while fully or partially implemented and / or deployed as part of a wired and / or wireless network to test other devices in a communications network. One or more emulation devices may perform one or more or all functions while temporarily implemented / deployed as part of a wired and / or wireless network. Emulation devices may be directly coupled to another device for testing purposes and / or may perform testing using terrestrial radio communication.

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

[0061] (Detailed explanation) Introduction - DNS Considering DNS communication, which has a message structure including sections for headers, queries, answers, authorizations, and additional RRs, the DNS protocol can be thought of as consisting of two (e.g., main) parts: (1) a query / response protocol for querying a specific name, and (2) a protocol for name servers to exchange database records.

[0062] Applications on / at the edge of wireless networks, such as 3GPP networks, can be deployed (e.g., should be deployed and must be deployed) on WTRUs that are not edge-aware, and on WTRUs that are edge-aware, without affecting other applications (e.g., edge-unaware applications), and with minimal impact on other applications.

[0063] Figure 2 shows the 3GPP architecture for enabling edge applications.

[0064] Referring to Figure 2 and the following disclosures herein, an architecture for enabling edge applications may be as described by 3GPP. The architecture for enabling edge applications 200 may include a WTRU 201, which includes either an application client 202 or an edge enabler client 203. Furthermore, the architecture 200 may include a 3GPP network 204, an edge data network 205, which includes either an edge application server 206 or an edge enabler server 207, and an edge data network configuration server 208. The edge enabler server 207 provides the functionality necessary for the edge application server 206 to run within the edge data network 205. Such functionality includes providing any configuration information necessary to communicate with the server 206, as well as providing information about the edge application server 206 to the edge enabler client 203. The edge enabler client 203 utilizes the edge application server 206 by providing the functionality of the application client 202 running on the WTRU. In other words, the edge enabler client 203 communicates with the edge enabler server 207 to discover and retrieve information about the edge application server 206.

[0065] The EDGE-1 reference point between the edge enabler client 203 and the edge enabler server 207 is the entry point for devices (e.g., WTRUs, BSs, nodes, servers, etc.) to the edge network management system. For example, as proposed by 3GPP, the (e.g., conventional) mechanism for finding edge enabler servers such as server 207 uses a combination of preconfiguration and DNS. That is, 3GPP proposes that service providers deploy global / regional edge data network configuration servers such as server 208, and that edge enabler clients such as client 203 request information to establish a connection with the edge enabler servers. The edge enabler client (e.g., client 203) is configured (e.g., must be configured) with the address / URI of the edge data network configuration server (e.g., server 208). Such an address / URI is either preconfigured within the WTRU or a predefined value derived from the serving network domain name.

[0066] Figure 3 shows the ETSI-MEC reference architecture (e.g., framework).

[0067] Referring to Figure 3, the ETSI MEC framework, such as the Multi-Access Edge System 300, enables the implementation of MEC applications 301 as software-only entities running on a virtualized infrastructure located within or near the network edge. ETSI MEC defines a reference architecture that identifies the functional elements of the MEC system and the reference points between those functional elements. The Multi-Access Edge System 300 includes MEC hosts and MEC management (e.g., mandatory) for running MEC applications within the operator network or a subset of the operator network. MEC management includes MEC system-level management and MEC host-level management. MEC system-level management includes the Multi-Access Edge Orchestrator (MEO) 302 as a (e.g., core) component that has an overview of the (e.g., complete) MEC system. Such an overview may include, for example, the network topology, deployed MEC hosts, and available resources and services. The MEO 302 is responsible for application onboarding, deployment, instantiation, termination, and redeployment.

[0068] The Operation Support System (OSS) 303 is the operator's OSS (for example, ). OSS 303 receives requests for application operations (e.g., instantiation, termination, and relocation) and decides whether to approve the request. Approved requests are forwarded to MEO 302 for further processing. User applications 301 are MEC applications that are instantiated within the MEC system 300 in response to user requests via device applications. The User Application Lifecycle Management Proxy (UALCMP) allows device applications to request onboarding, instantiation, termination, and relocation of user applications and allows device applications to be notified about the status of user applications. UALCMP authorizes requests from device applications within devices (e.g., WTRUs, laptops with internet connectivity, tablets, etc.) and interacts with OSS and MEO for further processing of these requests. The Mx2 reference point between device applications and UALCMP is the device's entry point to the edge network management system. Furthermore, ETSI MEC does not explicitly state how to find UALCMP. However, it is assumed (for example, generally) that UALCMP exists in well-known FQDNs (similar to 3GPP), which corresponds to a combination of pre-configuration and DNS.

[0069] For example, in IPv4 networking, DHCP enables devices to join a network and initiate communication within and across the network. DHCPv6 is the equivalent protocol for IPv6. Both DHCP and DHCPv6 use the use of options to carry additional parameters in protocol messages. Such options are used bidirectionally, from client to server and from server to client. A client may use such options to provide information about itself and suggestions or hints of desired configuration parameters from the server (e.g., by the client). A server (e.g., DHCP, DHCPv6) may use options to provide information about the network and configuration values ​​for the client. DHCP notification messages enable the exchange of DHCP options without assigning a client IP address, thus extending the DHCP options mechanism to clients whose addresses are configured through other means. Such features are continued in DHCPv6, which can operate either in place of or in addition to Stateless Address Auto-Configuration (SLAAC).

[0070] In the case of a 3GPP network with / using DHCP, an IP address is assigned, and network configuration parameters (e.g., DNS server address) are provided to the WTRU, for example, during the establishment of a Protocol Data Unit (PDU) session. In such cases, the WTRU may obtain an IP address via NAS signaling or DHCP, for example, after the PDU session is established (e.g., it may have the option to obtain one). Furthermore, the WTRU may obtain network parameters via NAS signaling or DHCP, for example, in the case of IPv4 and IPv6 (e.g., it may have the option to obtain them, or it may be independently decided to obtain them). For example, in the case of a 3GPP network (i.e., and / or any similar wireless network), to support DHCP-based IP address configuration, the Session Management Function (SMF) acts as a DHCP server (e.g., for that purpose) toward the WTRU.

[0071] Furthermore, in such cases, an external data network may be used to obtain IP addresses and network parameters, in which case the SMF acts as a DHCP client to an external DHCP server. In such cases, NAS signaling may be used, and there may be "extended protocol configuration options" defined for PDU session messages, where such option definitions may refer to "protocol configuration options" (PCOs) defined for PDP context messages (see, for example). In such cases, local server discovery may also be present, an example of which is included in the IP Multimedia Subsystem (IMS) interworking model as described in accordance with the 3GPP documentation. In such cases, the address of the Proxy Call Session Control Function (P-CSCF) server is provided to the WTRU via either DHCP options or PDU session PCOs. Furthermore, in such cases for 3GPP networks, the P-CSCF IP address may be configured locally within the SMF or discovered using the Network Repository Function (NRF).

[0072] Discovery of edge network management servers In an edge computing environment, edge-aware applications (e.g., devices) that participate in the edge network and attempt to discover and utilize edge network services must be able to discover the edge network management server (e.g., must discover it first). That is, in an edge computing environment, for example, in the architectures shown in Figures 2 and 3, and / or the 3GPP architecture, the edge enabler client must find the addresses of the edge enabler server and / or the edge data network configuration server. In the ETSI MEC architecture, the device application must find the UALCMP address.

[0073] Edge networks are localized (by definition, for example) and unique in terms of topology, functionality, and configuration. However, edge computing can (and is expected to be) deployed globally across many mobile network service providers, cable providers, tower companies, neutral hosts, and infrastructure vendor platforms. In such cases, conventional (and current state-of-the-art) mechanisms for discovering edge network management servers require (and demand) (1) some degree of pre-configuration, and (2) DNS that cannot be reliably used in the edge network. That is, DNS cannot be reliably used for any of the following reasons: (i) DNS caching prevents clients from consistently using edge network DNS servers; (ii) flushing the cache to force a full DNS resolution is highly inefficient and slow; and (iii) the network does not support the use of TTL-zero for DNS entries.

[0074] According to the embodiment, that is, considering the above (e.g., conventional) mechanisms for discovering edge network management servers, it is necessary to determine how an edge-aware application / device discovers and locates an edge network management server, for example, in the absence of preconfiguration and / or prior association with an edge network. According to the embodiment, for example, for universal applicability, a discovery mechanism (e.g., procedure, feature, operation, method, etc.) (for example, an edge network management server) can perform and / or satisfy (e.g., should, must, must) any of the following: (1) requires neither preconfiguration nor pre-association with an (e.g., specific) edge network provider within the application / device; (2) has minimal impact on edge-aware devices and no impact on edge-non-edge-aware devices; (3) is suitable for networks of various sizes and complexities; and (4) provides multiple addresses to support multiple edge network management servers and / or multiple edge network management systems.

[0075] ECS provisioning for WTRUs with multiple EECs In addition to the above-mentioned issues, for example, in the case of architectures and / or features specified by 3GPP (see, for example, 3GPP documentation on edge applications), such may address the provision of ECS configuration information (e.g., via the 5GC procedure). However, in such cases (e.g., as specified by 3GPP), the method of addressing this is unclear when two or more EECs are supported within a WTRU (e.g., by means of), and in such cases these EECs may be connected to one or more application clients (ACs). In such cases, it may be necessary to determine how the SMF can / can provide ECS information to the correct EEC when two or more EECs and two or more ACs are supported within / by means of a WTRU.

[0076] In some embodiments, DHCP may be used to discover entry points to an edge network management server (e.g., access to it, paths to it, interfaces for it, access, etc.). In some embodiments, a DHCP option for an edge network management (ENM) server may satisfy (e.g., all) the requirements of the discovery mechanism described above and may further provide any of the advantages described below. In some embodiments, the advantage may be that, regardless of the size of the network, the DHCP server may prioritize and / or filter ENM server candidates based, for example, on the location of a client (e.g., an attachment point). For example, (a) the DHCP server is located at an attachment point, or (b) the DHCP server is centralized and a DHCP relay agent is used that can provide the necessary information.

[0077] According to the embodiment, information associated with either the requirements and / or availability of edge network services (for example, the advantages may be as follows) can be communicated (e.g., signaling, sending, etc.) between the DHCP client and the server. According to the embodiment, such communicated requirements can be used by either the client or the server to further prioritize / filter ENM server candidates, for example. According to the embodiment, rediscovery can be triggered if there are changes in the requirements and / or availability of edge network services. According to the embodiment, another advantage may be that the solutions (e.g., resolved FQDNs) can be kept locally and managed (e.g., easily) at the edge network level. According to the embodiment, a global and / or region configuration server having (e.g., including, containing, storing, etc.) information associated (e.g., spanning) many edge networks may not be necessary.

[0078] Discovering ENM server clients Figure 4 shows a client discovery process for an ENM server with address assignment, according to an embodiment.

[0079] According to the embodiment, client discovery of an ENM server having address assignment may be performed as described below with reference to Figure 4. According to the embodiment, a parameter request list, which is (e.g., an existing) DHCP option, may be used by the client to request values ​​for specified configuration parameters, and the list may be specified as n octets, each octet being a valid DHCP option code. According to the embodiment, a client that uses DHCP for IP address assignment and wishes to discover an ENM server may add a code for a new ENM server DHCP option to the parameter request list, for example, in either a DISCOVER message and (e.g., a subsequent) REQUEST message. According to the embodiment, (e.g., in response to the parameter request list) the DHCP server may include the actual ENM server DHCP option (e.g., including ENM server information) in either an OFFER message and an ACK message.

[0080] According to one embodiment, the integration of a DHCP client and server, in which a new ENM server option is appended to an existing DHCP message, can be shown in Figure 4. According to one embodiment, such a rule for appending information to an existing DHCP message may be used throughout this document. According to one embodiment, new parameters may be enumerated in the message flow, while existing parameters may be omitted. According to one embodiment, the format of the ENM server DHCP option may be similar to conventional (e.g., standardized) formats used for DNS, NTP, and SMTP servers, and may be as follows: This option specifies a list of IP addresses indicating available ENM servers for the client. The servers should be listed in order of priority. The code for this option is X. The minimum length is 4, and the length must be a multiple of 4.

[0081] [Table 1]

[0082] According to one embodiment, the DHCPv6 format may be as follows, similar to the DHCP format: The ENM server option provides the client with a list of one or more IPv6 addresses of available ENM servers. The ENM servers are listed in order of preference for the client's use.

[0083] [Table 2]

[0084] Figure 5 shows a client discovery process for an ENM server that does not have IP address assignment, according to an embodiment.

[0085] According to embodiments, if a DHCP server does not understand the ENM server option code (for example, similar DHCP options), the DHCP server does not have to return the ENM server option (for example, it should not return it). According to embodiments, if a DHCP server understands the ENM server option code but is not an edge network (for example, not functioning as an edge network), the DHCP server may return an empty list of ENM servers. It should be noted that conventional (e.g., standard, modern, prior art, etc.) DHCP servers are configured manually by an administrator, either directly or indirectly, via a management platform. According to embodiments, the configuration of a DHCP server with an ENM server address, and any related information discussed herein, may (e.g., is expected) be done using the latest technology as they evolve.

[0086] According to one embodiment, referring to Figure 5, a client having an IP address configured by other means but wishing to discover an ENM server may add a code for the ENM server DHCP option to a parameter request list, for example, in an INFORM message. According to another embodiment, a DHCP server may include the ENM server DHCP option (for example, in response) in an ACK message.

[0087] DHCP server prioritizing ENM servers According to the embodiment, the DHCP server may (e.g., freely) apply prioritization to the ENM server list if it deems it appropriate based on, for example, performance metrics, operator priority, load balancing, etc. According to the embodiment, as described above, the DHCP server may communicate the prioritization to the client, for example, using the list order of the ENM server DHCP options. According to the embodiment, in the case of a DHCP relay agent (e.g., one is used), the DHCP relay agent may be configured with an IP address on the subnet on which it provides service. According to the embodiment, the DHCP relay agent may add this IP address to the message it relays to the DHCP server. According to the embodiment, the DHCP server may use this field (e.g., in the message being relayed) to determine, for example, whether to broadcast its response or unicast it back to the relay agent.

[0088] According to the embodiment, the DHCP server may customize the configuration sent to clients using (for example, further) DHCP relay agent addresses. For example, if there are multiple ENM servers, the DHCP server may prioritize (for example, customize the configuration) based on proximity to clients. According to the embodiment, for example, there may be a campus network serviced by (for example, a single) DHCP server. In such a case, the network may have two (for example, one or more main) connection zones (for example, areas), and each connection zone has a separate DHCP relay agent. In such a case, there may be edge network providers (for example, contracted) that enable services (for example, edge, fog, etc.) within the campus network. For example, in such a case, edge network providers P1 and P2 may be able to provide services (for example, enable) throughout the entire campus network, but, for example, due to deployment constraints, most of P1's resources are in the east zone and most of P2's resources are in the west zone.

[0089] According to the embodiments, in such cases, the DHCP server may prioritize the P1 ENM server for clients attaching to the East Zone and the P2 ENM server for clients in the West Zone. However, the disclosure is not limited thereto, and DHCP may prioritize ENM servers for any of the following reasons, factors, characteristics, requirements, etc., in adding and / or replacing ENM server locations. For example, in a campus network, there may be further cases where P1 provides (e.g., certain) services in the West Zone that have a higher QoS than such services provided by P2, and the DHCP server may prioritize the ENM server accordingly.

[0090] DHCP server filtering ENM server According to the embodiment, if a client device can utilize edge computing (e.g., desire, need, wish, decide, etc.), the client device may do so (e.g., would do so) for (e.g., specific) reasons such as desired applications and services spanning both the device and the edge network. In such cases, the client device may assist the DHCP server in filtering available ENM servers. According to the embodiment, the DHCP client may add an (e.g., new) ENM server requirements DHCP option to its message. According to the embodiment, the ENM server requirements DHCP option may be, for example, a list of identifiers for any of the services and / or (e.g., associated) applications that the client expects the edge network environment to provide. According to the embodiment, for example, in ETSI MEC terminology, this may be feature-dependent, and in 3GPP, this may be a publicly exposed network feature or service capability exposed feature (NEF / SCEF) category. According to the embodiment, (for example, in addition to such categories) a WTRU (e.g., a client, DHCP client) may use information associated with traffic descriptor rules (e.g., from there) as provided (e.g., from there) by a UE (e.g., WTRU) Route Selection Policy (URSP) provided by the network. According to the embodiment, such traffic descriptor-related information may be associated with an application, such as information indicating an application descriptor that identifies an application (e.g., an application ID), and / or with either IP information or non-IP information, for example, included in the ENM server requirement DHCP option.

[0091] According to the embodiment, there may be various use cases in which a client device assists a DHCP server by using any of the above-described client device features, such as providing ENM server requirements DHCP options in messages sent by the client device (e.g., add, send, send, etc.; new). According to the embodiment, such use cases may include any of the following: application computation offloading; augmented reality; and active device location tracking.

[0092] According to the embodiment, in the case of application computation offloading, the network may perform specific (e.g., computationally intensive) operations, processes, functions, etc. For example, instead of the user's mobile device, the network may perform either graphical rendering or data processing according to a DHCP server that receives an ENM server requirement DHCP option in a message sent by the client device. According to the embodiment, in such a case, the feature dependency may be the "user application" or any other appropriate signal, field, information, or indicator of a client device (e.g., prefer, request, etc.) having the network, which performs specific operations, processes, functions, etc. For example, if the client device is a smartphone used as a VR headset / screen, the ENM server requirement DHCP option may indicate a preference / request for image / motion rendering to be offloaded over the network to, for example, a home device or another device.

[0093] In some embodiments, in the case of augmented reality, a client device (e.g., which can send a discovery message to a DHCP server) may be provided with an interactive experience (e.g., which it can engage with), where real-world objects (e.g., which exist) are enhanced by computer-generated perceptual information. In such cases, connectivity must be maintained as the user (e.g., the client device) moves around, and the server instance (e.g., selected by a DHCP server) may be relocated (e.g., reconfigured, rediscovered, reselected, filtered, etc.) to meet performance requirements (e.g., as instructed / requested by the client device). Such changes to the ENM server instance may be referred to as smart relocation. In some embodiments, in such cases of augmented reality, feature dependencies may be the “user application” and “smart relocation,” or any other appropriate signals, fields, information, or indicators of a client device (e.g., prefer, request, etc.) that has a network-moving / relocating ENM server instance performing a particular action, process, function, etc.

[0094] According to the embodiments, active device location tracking may enable tracking of active devices (e.g., in real time, network measurement-based). According to the embodiments, active device location tracking may enable location-based services in any of the following: locations, retail locations, and areas where GPS coverage is unavailable. For example, such services may include mobile advertising, cloud management, and smart cities. According to the embodiment, in such cases of active device location tracking, the feature dependency may be “User Application” and “Location,” or any other appropriate signal, field, information, or indicator of the client device (e.g., prefer, request, etc.) that has a network providing services depending on the client device’s location (e.g., via an EMN server instance). For example, a client device may use an EMN server instance associated with one of several locations in a parking lot to indicate to a DHCP server (e.g., by sending a message containing either the feature dependency “User Application” and “Location”) that an application / service indicating the availability of a parking space should be run.

[0095] According to the embodiment, the format of the ENM server requirement DHCP option may be as follows: This option specifies a list of edge application / service identifiers required by the client. Each identifier is represented as a 32-bit integer. Up to 32 identifiers can be listed. The code for this option is Y. The minimum length is 4, the maximum length is 128, and the length must be a multiple of 4.

[0096] [Table 3]

[0097] Figure 6 shows a DHCP server that filters ENM servers based on requirements, according to an embodiment.

[0098] According to one embodiment, if the DHCP server cannot satisfy the client's requirements with available ENM servers, the DHCP server may return a list of ENM servers that may be empty. According to another embodiment, (for example, on the one hand) if the client message is a DISCOVER message, the DHCP server does not have to respond (for example, to decide, select, choose, etc.).

[0099] Clients that select an ENM server Figure 7 shows a client selecting an ENM server according to an embodiment. According to the embodiment, (see, for example, Figure 7) the client may select any of the ENM servers (for example, among them) (for example, freely) regardless of the enumerated order. According to the embodiment, if the client receives two or more OFFER messages in response to a DISCOVER message, the client may select any of the ENM servers or among those OFFERs (for example, freely) based on any other criterion. According to the embodiment, less stringent filters may be applied to the DHCP server, for example, this may enable the client to make a better informed decision among the ENM servers (for example, it may be suitable for this). According to the embodiment, the client may require some services, while others may be optional (for example, preferred, good to have, etc.). In such cases, the client may start discovery using its minimum set of services and then gradually increase it.

[0100] According to embodiments, for example, for more efficient exchange, the DHCP server may add requirement compliance information to each ENM server, for example, in a new ENM server having a requirement compliance DHCP option. According to embodiments, such a function of the DHCP server to add requirement compliance information, or any other function of the DHCP server described herein, may be performed with respect to any of the use cases (1) application computation offload, (2) active device location tracking, and (3) augmented reality. According to embodiments, for example, in the case of application computation offload, the WTRU (e.g., DHCP client device) may (e.g., be able to) perform the computation tasks of the application (e.g., all of them), but may (e.g., should use, would use, etc.) use offloading if available. According to embodiments, in such cases, the feature dependency "user application" may be considered optional by either the DHCP client or the DHCP server (e.g., not required, may be useful, may be provided variably / conditionally, etc.). For example, in such a case, the battery / power of the WTRU may deplete while the WTRU is performing application computing, and offloading may become more critical, for example, changing feature dependencies to requirements, not necessarily arbitrarily. That is, according to the embodiment, feature dependencies may change for a variety of reasons, such as requirements, capabilities, parameters, characteristics, measurements, configurations, resources, triggers, signals, and indicators associated with, for example, but not limited to, client devices (e.g., WTRU), applications, services, network slices, ENM server instances, networks, fog networks, edge networks, radio frequency networks, core networks, wired networks, etc.

[0101] In some embodiments, for example, in the case of active device location tracking and augmented reality, tourists may be walking around an area (e.g., new to them), and their primary concern is not getting lost (e.g., being navigated to a desired location) and knowing about landmarks along their walking route. That is, tourists may want an enhanced experience using AR (e.g., to have fun). In such cases, according to some embodiments, feature dependencies may be such that "user application" and "location" are requirements (e.g., essential), and "smart relocation" is an option (e.g., desirable) for the execution of an application (e.g., a service performed by the tourist WTRU) for guidance (e.g., navigation) and historical information (e.g., AR information) within the area (e.g., a new venue) (e.g., sending associated discovery requests). In such cases, the tourist's inherent interest in learning and not getting lost can be satisfied.

[0102] According to the embodiment, the format of a (e.g., new) ENM server having a requirements compliance DHCP option may be as follows: This option specifies a list of IP addresses indicating available ENM servers for the client. The servers should be listed in order of priority. For each ENM server, the bitmask indicates the availability of each ENM server requirement in the order specified by the client in the ENM server requirement options. The code for this option is Z. The minimum length is 8, and the length must be a multiple of 8.

[0103] [Table 4]

[0104] Client to rediscover ENM server Figure 8 shows a client rediscovering the ENM server according to an embodiment.

[0105] According to one embodiment, if a client's ENM server requirements change, for example, while associated with an edge network, i.e., while in the DHCP "Bound" state, the client may issue a DHCP REQUEST containing the new requirements, as shown, for example, in Figure 8. According to one embodiment, the DHCP server may send (e.g., in response to) an ACK containing, for example, a list of ENM servers that satisfy the requirements or a list of ENM servers that have compliance with the relevant requirements. According to one embodiment, if the DHCP server determines (e.g., decides) that there are no available (e.g., satisfactory) ENM servers, the DHCP server may send (e.g., instead) a NAK to trigger, for example, the client back to the "Init" state and send a new DISCOVER message. According to one embodiment, if a client's ENM server requirements change while not using DHCP for IP address assignment, the client may issue a DHCP INFORM message containing, for example, the client's new requirements. According to one embodiment, the DHCP server may send (e.g., in response to) an ACK containing, for example, a list of ENM servers that satisfy the requirements or a list of ENM servers that have compliance with the relevant requirements. According to one embodiment, if a DHCP server determines (e.g., decides) that there are no available (e.g., satisfactory) ENM servers, the DHCP server may (e.g., further) send an ACK using, for example, an empty ENM server list.

[0106] DHCP applicability to 3GPP As mentioned above, there may be cases where a 3GPP SA6 architecture has an Edge Enabler Server (EES) that functions as an ENM server (e.g., operates as a , performing the actions of ). In such cases, for example, an Edge Data Network Configuration Server (ECS) (in the 3GPP SA6 architecture) may be used to facilitate the discovery of the EES. However, in such cases, the use of an ECS may add complexity to / for discovery (e.g., simply, simply, etc.), in other words, it may add another layer to the problem of performing discovery. That is, in such cases of an ECS in a 3GPP SA6 architecture, it is necessary to determine how the ECS can be found. According to embodiments, if the ECS (e.g., also functions as an ENM server), there are methods, actions, characteristics, etc. for determining and / or discovering the ECS, as described below. As mentioned below, the acronym EXS may be used interchangeably to refer to either the EES or the ECS.

[0107] According to the embodiment, for example, DHCP may be supported for a local area data network (LADN) (e.g., supported option). For example, the DHCP option and / or PDU session PCO may be used (e.g., as a means / for) to discover the address of a local server (e.g., its LADN) in a similar subsystem (e.g., P-CSCF for IMS) (e.g., as specified by 3GPP). According to the embodiment, for example, in the case of DHCP in 3GPP, the EXS address may be added to the PCO (e.g., included in, provided by, indicated by, etc.). That is, according to the embodiment, in order to support WTRU discovery of the EXS (e.g., determination of the EXS address), the EXS address may be added to the PCO (e.g., should be added) regardless of the method used for WTRU address assignment and network configuration (e.g., neutral).

[0108] According to embodiments, the SMF may obtain and / or provide (e.g., can provide, is configured to provide, etc.) (e.g., is required) information used for and / or associated with the discovery of the EXS (e.g., the EXS address). According to embodiments, for example, in the case of an operator-owned edge network, the EXS address may be obtained in the same manner as the P-CSCF address (e.g., using the same, similar, etc., operation / procedure / features / etc.). That is, according to embodiments, the EXS address may be obtained either by being configured locally within the SMF or by being discovered using the NRF. According to embodiments, in such cases where the EXS address is obtained, the WTRU may include (e.g., a new) indicator within, for example, the S1 SM container, to trigger the SMF to determine the address of the EXS. According to embodiments, in the case of a third-party edge network, the EXS address may be obtained using (e.g., via) a DHCP request to a local DHCP server. In some embodiments, the third-party edge network may be independent of the 3GPP system (e.g., remain independent) or may seamlessly support 3GPP and non-3GPP WTRUs (e.g., similarly, similarly, etc.).

[0109] Figures 9, 10, and 11 illustrate EXS discovery according to embodiments. According to embodiments, for example, referring to Figures 9, 10, and 11, there may be variations in the procedure for EXS discovery. According to embodiments, referring to Figure 9, the (e.g., 3GPP) EXS address may be configured (e.g., stored locally) in the SMF. According to embodiments, for example, in the case of Figure 9, the WTRU may obtain the EXS address using either a DHCP message or a PDU session establishment message. According to embodiments, referring to Figure 10, the EXS may be registered with the NRF, and the SMF may query the NRF. According to embodiments, referring to Figure 11, the EXS may be configured (e.g., stored) in a (e.g., local) DHCP server.

[0110] According to the embodiment, in the case of EXS discovery, for example, referring to any of Figures 9, 10, and 11, either the WTRU or the SMF may be affected. According to the embodiment, either the WTRU or the SMF may request and / or provide an EXS address, for example, during PDU session establishment, for example, using a (e.g., new) PCO. According to the embodiment, in the direction of the WTRU toward the network, there may be either an EXS IPv4 address request or an EXS IPv6 address request (e.g., its transmission, information indicating it, etc.) that may be included in and / or associated with any suitable and / or yet-to-be-determined (e.g., new) container identifier. According to the embodiment, in the direction of the network toward the WTRU, there may be either an EXS IPv4 address or an EXS IPv6 address (e.g., its transmission, information indicating it, etc.) that may be included in and / or associated with any suitable and / or yet-to-be-determined (e.g., new) container identifier.

[0111] According to the embodiment, a container identifier may indicate an EXS address request (for example, it may include information indicating such a request). According to the embodiment, in such a case, the container identifier content field of a container identifier indicating an EXS address request may be empty, and the length of the container identifier content may be zero (for example, equal to zero). According to the embodiment, if the container identifier content field is not empty, it may be ignored (for example, it shall be ignored). According to the embodiment, a container identifier may indicate an EXS address (for example, it may include information indicating such a request). For example, in such a case of a container identifier indicating an EXS address, according to the embodiment, the container identifier content field may include an IP address (for example, one) corresponding to the EXS address used. According to the embodiment, if it is necessary to include multiple EXS addresses, more logical units having container identifiers indicating EXS addresses may be used.

[0112] According to the embodiment, for example, for either registration and / or discovery of an EXS, any of the EXS, NRF, and SMF may use either a (e.g., new) NF type, such as the NF type associated with the EXS, or a (e.g., new) data type, such as the data type associated with ExsInfo. According to the embodiment, any of the attribute name and / or associated data type, presence (P) or option (O) value, cardinality, and / or description may be as provided in Table 1 (e.g., shown).

[0113] [Table 5]

[0114] Support for multiple EECs during ECS ​​provisioning According to the embodiment, multiple edge enabler clients (EECs) may be associated with multiple application clients (ACs), and these EECs may be associated with multiple PLMNs (e.g., further, and so on) (e.g., as defined by 3GPP).

[0115] Figure 12 shows the relationship between EEC and AC based on cardinality according to an embodiment.

[0116] According to the embodiment, ECS address information can be provisioned by the MNO, for example, via the 5G core network procedure. According to the embodiment, for example, referring to Figure 12, there may be multiple EECs, and these EECs may serve one or more ACs. For example, EE1 may process requests from AC1 and AC2, while EEC2 may process (e.g., address) requests from AC3 and ACn. According to the embodiment, an EEC may be associated with one or more ECSs, and / or one ECS may be associated with one or more EECs.

[0117] Figure 13 shows ECS provisioning according to an embodiment.

[0118] According to the embodiment, the EEC may provide the WTRU with information indicating, for example, the available EECs and / or their IDs, and / or application IDs and / or services supported by these EECs (e.g., regardless of which). That is, for example, in the case of multiple EECs and / or multiple ACs, in addition to and / or instead of notifying the SMF whether the WTRU supports the transfer of ECS configuration information between the NAS layer and the EECs, the EEC may provide the WTRU with information regarding the available EECs and / or their IDs or application IDs / services supported by these EECs. According to the embodiment, for example, referring to Figure 13, the network, for example (e.g., in particular) the SMF, may use such information to select applicable ECS information according to the EECs supported and / or configured in the WTRU, for example.

[0119] According to the embodiment, referring to Figure 13, the ECS provisioning procedure may include any of the following actions. According to the embodiment, as a first action, an AC, e.g., AC1, which may need to contact the relevant EAS server, may request EAS discovery via edge-4, and the AC may provide either its application ID or service ID (e.g., as part of the request and / or included in the request). According to the embodiment, as a second action, an EEC associated with AC1, e.g., EEC1, may issue an AT command (e.g., send, transmit, provide, etc.) to trigger, for example, the establishment of a PDU session. According to the embodiment, the EEC (e.g., EEC1) may provide its EEC ID (e.g., EEC1), as well as the application ID and / or service ID provided by the relevant AC (e.g., also, further, etc.). According to the embodiment, such information may be provided (e.g., transmit) in the PCO portion of the +CGDCONT AT command, for example.

[0120] According to the embodiment, as a third operation, an AC, e.g., AC2, may need to contact the relevant EAS server to request EAS discovery via edge-4, for example, and such an AC (e.g., AC2) may provide its application ID or service ID to the EAS server, for example. According to the embodiment, as a fourth operation, an EEC associated with AC2, e.g., EEC2, may send an AT command (e.g., send, issue, etc.) to trigger the establishment of a PDU session, and the EEC may provide its EEC ID (e.g., EEC2) and / or either the application ID and service ID provided by the relevant AC. According to the embodiment, such a command and / or information may be sent in the PCO portion of the +CGDCONT AT command. According to the embodiment, as a fifth operation, the NAS layer (e.g., processor operation for and / or associated with the NAS layer) may be implemented to wait for two or more EEC requests before issuing a PDU session establishment message, and thus may provide information to any one or more EECs and any one or more ACs. According to one embodiment, such a request may be from an EEC associated with a service provided within the same network slice, for example, as provided by an S-NSSAI provided by an AT command.

[0121] According to one embodiment, as a sixth operation, when the SMF receives, for example, a PDU session establishment request message, it may derive ECS information related to the EEC and / or application ID provided in the PCO within the PDU session establishment request message (e.g., in). According to one embodiment, as a seventh operation, the SMF may provide the derived information in a PDU session establishment acceptance message, for example, for each EEC. According to one embodiment, as an eighth operation, the NAS layer may relay the ECS information to the relevant EEC (e.g., EEC2). According to one embodiment, as a ninth operation, the EEC may use the ECS information provided in the PCO to obtain, for example, applicable EES address information. According to one embodiment, in such a ninth operation, the EEC may use (e.g., exhaust) the EES to obtain applicable EAS information.

[0122] According to the embodiment, as a tenth operation, the EEC may provide EAS information applicable to the relevant AC (e.g., AC2) in the EAS discovery response. According to the embodiment, as an eleventh operation, the NAS layer may relay ECS information to the relevant EEC (e.g., EEC1). According to the embodiment, as a twelfth operation, the EEC may obtain applicable EES address information using ECS ​​information provided, for example, in the PCO. According to the embodiment, the EEC may use (e.g., exhaust) the EES to obtain applicable EAS information. According to the embodiment, as a thirteenth operation, the EEC may provide EAS information applicable to the relevant AC (e.g., AC1) in the EAS discovery response.

[0123] According to the embodiment, in the case of ECS provisioning, for example, referring to either Figure 12 or Figure 13, either the WTRU or the network may be affected. According to the embodiment, in the case of the WTRU, there may be an EEC within the WTRU that can (e.g., must provide) any of its client ID, application ID, and service ID from an AC connected (e.g., by using the +CGDCONT AT command, for example). According to the embodiment, when the NAS layer issues a PDU session establishment request message, it may (e.g., must provide) any of the EEC ID, application ID, and service ID within the PCO. According to the embodiment, in the case of the WTRU, the EEC (e.g., within the WTRU) may (e.g., must provide) extract the ECS information provided in the PCO. According to the embodiment, the WTRU may extract such information for all ACs, and the WTRU may determine whether one or more EESs can (e.g., must be contacted) to obtain relevant EAS information.

[0124] According to the embodiment, in the case of a network, the SMF may extract (for example, need to extract) any of the EEC ID, application ID, and service ID to use as input to derive ECS information relevant to each EEC. According to the embodiment, in the case of a network, the SMF may (for example, need to provide) ECS information for all EECs, for example, within the PCO in the PDU session establishment acceptance message. According to the embodiment, in such a case, optimization may be possible if all EECs are associated with / associated with the same ECS.

[0125] conclusion While features and elements are described above in specific combinations, those skilled in the art will understand that each feature or element can be used alone or in any combination with other features and elements. Furthermore, the methods described herein can be implemented in computer programs, software, or firmware embedded in computer-readable media for execution by a computer or processor. Examples of non-temporary computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, 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 associated with software can be used to implement a radio frequency transceiver for use in a UE, WTRU, terminal, base station, RNC, or any host computer.

[0126] Furthermore, the embodiments described above include processing platforms, computing systems, controllers, and other devices, including a rendezvous point / server with constraint servers and processors. These devices may include at least one central processing unit ("CPU") and memory. According to the convention of those skilled in the art in the field of computer programming, references to operations and symbolic representations of arithmetic or instructions may be performed by various CPUs and memories. Such operations and arithmetic or instructions may be referred to as "execution," "computer execution," or "CPU execution."

[0127] Those with ordinary art in the technical field will understand that operations and symbolically represented arithmetic or instructions involve the manipulation of electrical signals by a CPU. The electrical system represents data bits that can cause a resulting transformation or reduction of electrical signals, and maintains these data bits in memory locations in a memory system, thereby reconfiguring or otherwise modifying the CPU's operations and processing of other signals. The memory locations where the data bits are maintained are physical locations having specific electrical, magnetic, optical, or organic properties that correspond to or represent the data bits. It should be understood that exemplary embodiments are not limited to the platforms or CPUs described above, and other platforms and CPUs may support the methods provided.

[0128] Data bits may also be maintained on computer-readable media, including magnetic disks, optical disks, and any other volatile (e.g., Random Access Memory ("RAM")) or CPU-readable non-volatile (e.g., Read-Only Memory ("ROM")) mass storage systems. The computer-readable media may include cooperative or interconnected computer-readable media distributed among multiple interconnected processing systems, which may reside exclusively on a processing system or be local or remote to the processing system. Typical embodiments are not limited to the memory described above, and it is understood that other platforms and memories may support the methods described.

[0129] In exemplary embodiments, any of the operations, processes, etc., described herein may be implemented as computer-readable instructions stored on a computer-readable medium. Computer-readable instructions can be executed by processors in mobile devices, network elements, and / or any other computing devices.

[0130] There is little distinction between hardware and software implementations of a system configuration. The use of hardware or software is generally (though not always, in certain situations the choice between hardware and software can be significant) a design choice involving a cost-effectiveness trade-off. Various vehicles (e.g., hardware, software, and / or firmware) may be effective for the processes and / or systems and / or other technologies described herein, and the preferred vehicle may vary depending on the context in which the processes and / or systems and / or other technologies are deployed. For example, if the implementer determines that speed and accuracy are paramount, they may primarily choose a hardware and / or firmware vehicle. If flexibility is paramount, the implementer may primarily choose a software implementation. Alternatively, the implementer may choose any combination of hardware, software, and / or firmware.

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

[0132] While the features and elements are provided above in specific combinations, it will be understood by those with ordinary art in the field that each feature or element can be used individually or in any combination with other features and elements. This disclosure is not limited in terms of the specific embodiments described in this application, which are intended to be illustrative of various aspects. As will be apparent to those skilled in the art, many modifications and variations can be made without departing from the spirit and scope of the invention. Any element, operation, or instruction used in the description of this application should not be construed as important or essential to the invention unless expressly presented as such. In addition to those enumerated herein, functionally equivalent methods and apparatus within the scope of this disclosure will be apparent to those skilled in the art from the foregoing description. Such modifications and variations are intended to fall within the scope of the appended claims. This disclosure is limited only by the terms of the appended claims, and is limited in the same way as the full scope of the equivalents to which such claims are entitled. It should be understood that this disclosure is not limited to any particular method or system.

[0133] Furthermore, it should be understood that the terms used herein are intended solely to describe specific embodiments (e.g., only) and are not intended to limit the invention. Where used herein, the term “User Equipment” and its abbreviation “UE” may mean (1) a wireless transmit and / or receive unit (WTRU) as described below; (2) any of several embodiments of a WTRU, such as the infrastructure described; (3) a wireless and / or wired (e.g., tetherable) device configured to have some or all of the structure and functions of an exemplary WTRU (e.g., the infrastructure described); (4) a wireless and / or wired device configured to have less than all of the structure and functions of a WTRU (e.g., the infrastructure described); or (5) etc. Details of exemplary WTRUs that may represent any WTRU described herein.

[0134] In certain representative embodiments, some parts of the subject matter described herein may be implemented via application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), and / or other integrated formats. However, it will be recognized by those skilled in the art that some aspects of the embodiments disclosed herein can be equivalently implemented in an integrated circuit, in whole or in part, 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 substantially any combination thereof, and that designing circuits and / or writing software and / or firmware code is within the scope of the art of those skilled in the art in light of this disclosure. Furthermore, it will be understood by those skilled in the art that the mechanisms of the subject matter described herein can be distributed as various forms of program products, and that the exemplary embodiments of the subject matter described herein are applicable regardless of the specific type of signal-carrying medium used to actually carry out the distribution. Examples of signal-carrying mediums include, but are not limited to, recordable media such as floppy disks, hard disk drives, CDs, DVDs, digital tapes, and computer memory, and transmission media such as digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.).

[0135] The subject matter described herein may, in some cases, depict different components that are contained within or connected to other different components. Such illustrated architectures are merely examples, and it should be understood that in practice, many other architectures can be implemented to achieve the same function. Conceptually, any arrangement of components to achieve the same function is effectively “associated” in such a way that the desired function can be achieved. Thus, any two components combined herein to achieve a particular function, regardless of architecture or intermediate components, can be seen as “associated” with each other in such a way that the desired function can be achieved. Similarly, any two components thus associated can be seen as “operably connected” or “operably coupled” with each other to achieve the desired function, and any two components that can be associated in such a way can be seen as “operably coupled” with each other to achieve the desired function. Specific examples of operably coupled components include, but are not limited to, physically matable and / or physically interacting components, and / or wirelessly interactable and / or wirelessly interacting components, and / or logically interacting and / or logically interactable components.

[0136] With regard to the use of substantially any plural and / or singular terms herein, those skilled in the art can convert from plural to singular and / or singular to plural as appropriate to the context and / or use. For clarity purposes, various singular / plural rearrangements may be explicitly described herein.

[0137] In general, it will be understood by those skilled in the art that the terms used herein, and in particular in the appended claims (e.g., in the body of the appended claims), are generally intended to be “non-limiting” terms (for example, the term “contains” should be interpreted as “contains but not limited to,” the term “has” should be interpreted as “has at least,” and the term “contains” should be interpreted as “contains but not limited to.”). Furthermore, it will be understood by those skilled in the art that if a particular number of claims introduced are intended to be described, such intent is explicitly stated in the claim, and if such statement is not present, such intent does not exist. For example, if only one item is intended, the term “single” or similar word may be used. To aid understanding, the following appended claims and / or descriptions herein may include the use of the introductory phrases “at least one” and “one or more” to introduce the description of a claim. However, the use of such phrases should not be interpreted as meaning that the introduction of a claim description by the indefinite article "a" or "an" limits any particular claim containing such introduced description to embodiments containing only one such description, even if the same claim contains the introductory phrase "one or more" or "at least one" and an indefinite article such as "a" or "an" (for example, "a" and / or "an" should be interpreted as meaning "at least one" or "one or more"). The same applies to the use of the definite article used to introduce a claim description. Furthermore, even if a particular number of descriptions in an introduced claim are explicitly stated, it will be recognized by those skilled in the art that such a statement should be interpreted as meaning at least the number stated (for example, the simple statement "two descriptions" without other modifiers means at least two descriptions or two or more descriptions).Furthermore, when a notation similar to "at least one of A, B, and C" is used, such a structure is generally intended to mean what a person skilled in the art would understand (for example, "a system having at least one of A, B, and C" includes, but is not limited to, systems having only A, only B, only C, A and B together, A and C together, B and C together, and / or A, B, and C together). When a notation similar to "at least one of A, B, or C" is used, such a structure is generally intended to mean what a person skilled in the art would understand (for example, "a system having at least one of A, B, or C" includes, but is not limited to, systems having only A, only B, only C, A and B together, A and C together, B and C together, and / or A, B, and C together). It will be further understood by those skilled in the art that any substantially separate word and / or phrase presenting two or more alternative terms in any description, claim, or drawing should be understood as construing the possibility of including one of the terms, either of the terms, or both of the terms. For example, the phrase “A or B” should be understood as including the possibility of “A” or “B” or “A and B.” Furthermore, as used herein, the term “any of ~” followed by a list of multiple items and / or a list of categories of multiple items is intended to include “any of,” “any combination of,” “any number of,” and / or “any number of combinations of,” of the items and / or categories of items, individually or in combination with other items and / or categories of other items. Furthermore, as used herein, the term “set / group” is intended to include any number of items, including zero. Furthermore, as used herein, the term “number” is intended to include any number, including zero.

[0138] Furthermore, if any feature or aspect of this disclosure is described in terms of the Markush group, a person skilled in the art will recognize that this disclosure is also described in terms of any individual member or subgroup of a member of the Markush group.

[0139] For all purposes, including providing written explanations, as will be understood by those skilled in the art, all scopes disclosed herein also encompass any possible sub-scopes and combinations of sub-scopes. Any enumerated scope can be readily recognized as sufficiently explainable and enable that the same scope can be broken down into at least equal 1 / 2, 1 / 3, 1 / 4, 1 / 5, 1 / 10, etc. As a non-limiting example, each scope described herein can readily be broken down into the lower third, the middle third, the upper third, etc. Also, as will be understood by those skilled in the art, all words such as “up to,” “at least,” “greater than,” and “less than” include the number mentioned and mean a scope that can be further broken down into sub-scopes as described above. Finally, as will be understood by those skilled in the art, a scope includes individual elements. Thus, for example, a group having 1 to 3 cells refers to a group having 1, 2, or 3 cells. Similarly, a group having 1 to 5 cells refers to a group having 1, 2, 3, 4, or 5 cells, and so on.

[0140] Furthermore, unless otherwise specifically stated, the claims should not be read as being limited to the order or elements provided. Moreover, in any claim, the use of the term “means for” is intended to appeal to Section 112, paragraph 6 of the U.S. Patent Act, or the means-plus-function claim format, and no claim without the term “means for” is intended to appeal in that way.

[0141] A software-related processor may be used to implement a radio frequency transceiver for use in a radio transceiver unit (WTRU), user equipment (UE), terminal, base station, mobility management entity (MME), or evolved packet core (EPC), or any host computer. The WTRU may be used in conjunction with hardware and / or software-implemented modules such as software-defined radio (SDR), and may also be implemented in other components such as cameras, video camera modules, video phones, speakerphones, vibration devices, speakers, microphones, television transceivers, hands-free headsets, keyboards, Bluetooth® modules, frequency modulation (FM) radio units, near-field communication (NFC) modules, LCD display units, organic light-emitting diode (OLED) display units, digital music players, media players, video game player modules, internet browsers, and / or wireless local area network (WLAN) or ultra-wideband (UWB) modules.

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

[0143] Furthermore, while the present invention is illustrated and described herein with reference to specific embodiments, it is not intended to be limited to the details shown. Rather, various modifications can be made in detail within the scope of the claims and their equivalents without departing from the present invention.

Claims

1. A method performed by a wireless transceiver unit (WTRU) for discovering available edge data network configuration servers (ECS) associated with an edge enabler server (EES), wherein the method is: Sending a Protocol Data Unit (PDU) session establishment request message to a core network entity, wherein the PDU session establishment request message includes a first protocol configuration option (PCO) and includes information relating to the first PCO receiving an ECS address, Receiving a PDU session establishment acceptance message from the core network entity in response to the PDU session establishment request message, wherein the PDU session establishment acceptance message includes a second PCO, the second PCO includes ECS information, and the ECS information included in the second PCO includes an ECS address, an identifier, and a list of tracking area identifiers (TAIs) that can be provided by the ESC associated with the ECS information. To provide at least the ECS address from the non-access stratum (NAS) layer of the WTRU to the edge enabler client (EEC) of the WTRU, A method including performing communication with one or more ECSs.

2. The method according to claim 1, wherein the core network entity is equipped with a session management function (SMF).

3. The method according to claim 1, wherein the first PCO includes one or more of the following: edge enabler client (EEC) identification information (ID) and application ID or service ID.

4. The method according to claim 1, further comprising obtaining EES address information based on the ECS information using the EEC of the WTRU.

5. The method according to claim 1, wherein the ECS address includes an Internet Protocol (IP) address.

6. The method according to claim 1, wherein an attention (AT) command is used to transmit the ECS information from the non-access stratum (NAS) layer of the WTRU to the EEC of the WTRU.

7. The method according to claim 4, further comprising obtaining edge application server (EAS) address information based on the EES address information using the EEC of the WTRU.

8. The method according to claim 1, further comprising sending an edge application server (EAS) discovery request to the EEC of the WTRU via the application client (AC) of the WTRU, wherein the EAS discovery request includes an application ID or a service ID.

9. A method performed by a Session Management Function (SMF) to enable the discovery of available Edge Data Network Configuration Servers (ECS) associated with an Edge Enabler Server (EES), wherein the method is: Receiving a protocol data unit (PDU) session establishment request message from a wireless transceiver unit (WTRU), wherein the PDU session establishment request message includes a first protocol configuration option (PCO) and includes information relating to the first PCO receiving an ECS address, Based on the aforementioned PDU session establishment request message, the ECS information is determined, A method comprising sending a PDU session establishment acceptance message to the WTRU in response to the PDU session establishment request message, wherein the PDU session establishment acceptance message includes a second PCO, the second PCO includes ECS information, and the ECS information included in the second PCO includes an ECS address, an identifier, and a list of tracking area identifiers (TAIs) that can be provided by an ESC associated with the ECS information.

10. The method according to claim 9, wherein the ECS address includes an Internet Protocol (IP) address.

11. The method according to claim 9, further comprising receiving an edge application server (EAS) discovery request from an application client (AC) of the WTRU, wherein the EAS discovery request includes an application ID or a server ID.

12. The method according to claim 9, wherein the ECS information is received from the network repository function (NRF) by the SMF.

13. A wireless transceiver unit (WTRU) comprising a processor and memory, wherein the processor and memory are A protocol data unit (PDU) session establishment request message is sent to the core network entity, and the PDU session establishment request message includes a first protocol configuration option (PCO) and includes information about support for discoveries related to the first PCO receiving an edge data network configuration server (ECS) address. In response to the PDU session establishment request message, the core network entity receives a PDU session establishment acceptance message, the PDU session establishment acceptance message includes a second PCO, the second PCO includes ECS information, and the ECS information included in the second PCO includes an ECS address, an identifier, and a list of tracking area identifiers (TAIs) that can be provided by the ESC associated with the ECS information. The non-access stratum (NAS) layer of the WTRU provides at least the ECS address to the edge enabler client (EEC) of the WTRU, A WTRU configured to communicate with one or more ECSs.

14. The WTRU according to claim 13, wherein the ECS address includes an Internet Protocol (IP) address.

15. The WTRU according to claim 13, wherein an attention (AT) command is used to transmit the ECS information from the non-access stratum (NAS) layer of the WTRU to the EEC of the WTRU.

16. The aforementioned processor and memory are The WTRU according to claim 13, configured to acquire edge application server (EAS) address information based on ECS information using the EEC of the WTRU.

17. The aforementioned processor and memory are The WTRU according to claim 13, configured to send an edge application server (EAS) discovery request to the EEC via the application client (AC) of the WTRU, wherein the EAS discovery request includes an application ID or a service ID.

18. The WTRU according to claim 13, wherein the core network entity includes a session management function (SMF).

19. The WTRU according to claim 13, wherein the first PCO includes one or more of edge enabler client (EEC) identification information (ID) and application ID or service ID.

20. The WTRU according to claim 16, wherein the processor and memory are configured to obtain EES address information based on the ECS information by the EEC of the WTRU.

Images