A method for specifying the MAC address type using a dynamic assignment mechanism.

Abstract

To provide a method for setting a MAC address to a WTRU based on context information.SOLUTION: A method includes receiving context information from infrastructure equipment and selecting a SLAP quadrant for MAC address allocation. The selecting may be based on the context information received from the infrastructure equipment, which may be a bootstrapping server for a WTRU. The method may further comprise transmitting, to a DHCP server, a DHCP message indicating the selected SLAP quadrant, and receiving, in response to the transmitted DHCP message, a MAC address to be configured to the WTRU. The context information includes the number of nodes in a network, a type of network deployment, a type of network, a mobility configuration, a type of device management, a battery lifetime, a location or privacy configuration.SELECTED DRAWING: Figure 3A

Description

Technical Field

[0001] Cross - Reference to Related Applications This application claims the benefit of U.S. Provisional Patent Application No. 62 / 794,148, filed on January 18, 2019, the content of which is incorporated herein by reference.

Summary of the Invention

[0002] A method performed by a wireless transmit / receive unit (WTRU) can include receiving context information from an infrastructure device and selecting a structured local address plan (SLAP) quadrant for media access control (MAC) address assignment. The selection can be based on context information received from an infrastructure device that can be a bootstrap server of the WTRU. The method can further include transmitting a Dynamic Host Configuration Protocol (DHCP) message indicating the selected SLAP quadrant to a DHCP server. In response to the transmitted DHCP message, a MAC address can be received and set in the WTRU. The context information can include, but is not limited to, the number of nodes in the network, the type of network deployment, the type of network, the mobility configuration, the type of device management, battery life, location, or privacy configuration.

[0003] A more detailed understanding can be obtained from the following description given by way of example in conjunction with the accompanying drawings, in which like reference numerals indicate like elements.

Brief Description of the Drawings

[0004] [Figure 1A] FIG. 1A is a system diagram showing an exemplary communication system in which one or more of the disclosed embodiments can be implemented. [Figure 1B] FIG. 1B is a system diagram showing an exemplary wireless transmit / receive unit (WTRU) that can be used within the communication system shown in FIG. 1A according to an embodiment. [Figure 1C] Figure 1C is a system diagram showing an exemplary radio access network (RAN) and an exemplary core network (CN) that can be used in the communication system shown in Figure 1A according to an embodiment. [Figure 1D] Figure 1D is a system diagram showing further exemplary RAN and further exemplary CN that can be used in the communication system shown in Figure 1A according to an embodiment. [Figure 2A] Figure 2A is an exemplary structure showing the four least significant bits of a 48-bit MAC address. [Figure 2B] Figure 2B is a table outlining the features of the four SLAP quadrants identified using the Y and Z bits. [Figure 3A] Figure 3A depicts several Internet of Things (IoT) networks interfacing with the Dynamic Host Configuration Protocol (DHCP) architecture. [Figure 3B] Figure 3B depicts a large-scale data center interfaced with a DHCP architecture. [Figure 4] Figure 4 shows the signaling for IoT quadrant selection in both standalone decision mode and infrastructure-assisted decision mode. [Figure 5] Figure 5 is a flowchart showing the quadrant selection decision in an embodiment of an IoT terminal. [Figure 6] Figure 6 is a DHCPv6 signaling flow diagram with client-server extensions. [Figure 7] Figure 7 is a DHCPv6 signaling flow diagram with client-relay-server extension. [Figure 8] Figure 8 shows a depiction of the quadrant (IA-LL) option format. [Figure 9] Figure 9 shows the additional CID (IA-LL) option format. [Modes for carrying out the invention]

[0005] Figure 1A shows an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 can be a multi-access system that provides content such as voice, data, video, messaging, and broadcast to multiple wireless users. The communication system 100 can enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communication system 100 can employ one or more channel access schemes 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 discrete Fourier transform spread OFDM (ZT-UW-DFT-S-OFDM), unique-word OFDM (UW-OFDM), resource block filtering OFDM, and filter bank multi-carrier (FBMC).

[0006] As shown in Figure 1A, the communication system 100 may include radio transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the internet 110, and other networks 112, but it will be understood that the disclosed embodiments assume any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d can 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 stations (STAs)) may be configured to transmit and / or receive radio signals and may include user equipment (UEs), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, mobile phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical equipment and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in the context of industrial and / or automated processing chains), consumer electronics devices, and device networks operating on commercial and / or industrial radios. Any of WTRU102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0007] The communication system 100 may also include base stations 114a and / or base stations 114b. Each of the base stations 114a and 114b can be any type of device configured to radio 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, the Internet 110, and / or other networks 112. For example, base stations 114a and 114b may be a base transceiver station (BTS), Node B, eNode B (eNB), home Node B, home eNode B, gNode B (gNB), next-generation Node B such as New Radio (NR) Node B, site controller, access point (AP), radio 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.

[0008] Base station 114a may be part of RAN 104, 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 called cells (not shown). These frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. Cells can provide coverage of radio services to a particular geographic area that is relatively fixed or may change over time. Cells 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 for each sector of the cell. In embodiments, base station 114a may employ multiple-input multiple-output (MIMO) technology, allowing for the use of multiple transceivers for each sector of the cell. For example, beamforming can be used to transmit and / or receive signals in a desired spatial direction.

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

[0010] More specifically, as described above, the communication system 100 may be a multiple access system and may employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, base stations 114a and WTRU 102a, 102b, 102c of RAN 104 may implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can establish an air interface 116 using broadband CDMA (WCDMA). WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Advanced HSPA (HSPA+). HSPA may include High Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High Speed ​​Uplink (UL) Packet Access (HSUPA).

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

[0012] 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 NR.

[0013] In the embodiment, base stations 114a and WTRUs 102a, 102b, and 102c can implement multiple radio access technologies. For example, base stations 114a and WTRUs 102a, 102b, and 102c can implement LTE radio access and NR radio access together, for example, using the dual connection (DC) principle. Thus, the air interface utilized by WTRUs 102a, 102b, and 102c can be characterized by multiple types of radio access technologies and / or transmissions to and from multiple types of base stations (e.g., eNBs and gNBs).

[0014] In other embodiments, base stations 114a and WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi)), IEEE 802.16 (i.e., Global Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Extended Data Rate (EDGE) of GSM Evolution, and GSM EDGE (GERAN).

[0015] 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, for example), and roads. 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 another 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, the base station 114b and WTRU 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or femtocell. As shown in Figure 1A, base station 114b can connect directly to the internet 110. Therefore, base station 114b may not need to access the internet 110 via CN 106.

[0016] RAN104 can communicate with CN106, 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 WTRU102a, 102b, 102c, and 102d. The data may have various Quality of Service (QoS) requirements, including different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, and mobility requirements. CN106 can provide call control, billing services, mobile location-based services, prepaid calls, internet connectivity, video distribution, and / or perform high-level security functions such as user authentication. Although not shown in Figure 1A, it will be understood that RAN104 and / or CN106 can communicate directly or indirectly with other RANs using the same RAT or different RATs as RAN104. For example, in addition to being connected to RAN104 which may utilize NR radio technology, CN106 may also communicate with another RAN (not shown) using GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0017] CN106 can also function as a gateway for the WTRU102a, 102b, 102c, 102d to access the PSTN108, the Internet 110, and / or other networks 112. The PSTN108 can include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 can include a global system of interconnected computer networks and devices that use common communication protocols such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and / or the Internet Protocol (IP) of the TCP / IP Internet protocol suite. The network 112 can include wired and / or wireless communication networks that are owned and / or operated by other service providers. For example, the network 112 may include another CN connected to one or more RANs, which may use the same or a different RAT as the RAN 104.

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

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

[0020] The processor 118 can be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), a plurality of 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), other types of integrated circuits (ICs), a state machine, etc. The processor 118 can perform signal encoding, data processing, power control, input / output processing, and / or any other function that enables the WTRU 102 to operate in a wireless environment. The processor 118 can be coupled to the transceiver 120, and the transceiver 120 can be coupled to the transmit / receive element 122. Although FIG. 1B shows the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 can be integrated together in an electronic package or chip.

[0021] The transmit / receive element 122 can 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 another 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 can be configured to transmit and / or receive any combination of radio signals.

[0022] 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 employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for sending and receiving radio signals via the air interface 116.

[0023] The transceiver 120 can 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 can have multimode capabilities. 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.

[0024] 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 data from them. 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 suitable type of memory, such as non-removable memory 130 and / or removable memory 132, and store data. 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. Removable memory 132 may include a subscriber identification module (SIM) card, a memory stick, a secure digital (SD) memory card, etc. In other embodiments, the processor 118 may access information from memory not physically located on the WTRU 102, such as a server or home computer (not shown), and store the data in memory.

[0025] The processor 118 can receive power from the power supply 134 and may be configured to distribute and / or control power to other components within the WTRU 102. The power supply 134 can 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.), a solar cell, a fuel cell, etc.

[0026] The processor 118 can also be coupled to a GPS chipset 136, which can 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 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 can acquire location information by any suitable location determination method while maintaining consistency with the embodiment.

[0027] The processor 118 can 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, e-compass, satellite transceiver, digital camera (for photos and / or video), Universal Serial Bus (USB) port, vibration device, TV transceiver, hands-free headset, Bluetooth® module, frequency modulation (FM) radio unit, digital music player, media player, video game player module, internet browser, virtual reality and / or augmented reality (VR / AR) device, activity tracker, etc. Peripherals 138 may include one or more sensors. The sensors may be one or more of the following: gyroscope, accelerometer, Hall effect sensor, magnetometer, orientation sensor, proximity sensor, temperature sensor, time sensor, geolocation sensor, altimeter, light sensor, touch sensor, magnetometer, barometer, gesture sensor, biometric sensor, humidity sensor, etc.

[0028] WTRU102 may include a full-duplex radio in which the transmission and reception of some or all of the UL (e.g., for transmission) and DL (e.g., for reception) signals (e.g., associated with a particular subframe) may occur in parallel and / or simultaneously. The full-duplex radio may include an interference management unit to reduce and / or substantially eliminate self-interference via either hardware (e.g., chokes) or a processor (e.g., a separate processor (not shown) or signal processing via processor 118). In embodiments, WTRU102 may include a half-duplex radio for the transmission and reception of some or all of the signals (e.g., associated with a particular subframe of either UL (e.g., for transmission) or DL ​​(e.g., for reception)).

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

[0030] 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 the 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 can implement MIMO technology. Thus, eNode-B160a can, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU102a.

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

[0032] 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 (PGW) 166. Although these elements are shown as part of CN106, it should be understood that any of these elements may be owned and / or operated by entities other than the CN operator.

[0033] MME162 may be connected to each of the eNode-B162a, 162b, and 162c within RAN104 via the S1 interface and may function as a control node. For example, MME162 could be responsible for user authentication of WTRU102a, 102b, and 102c, activation / deactivation of bearers, and selecting a specific serving gateway during the initial connection of WTRU102a, 102b, and 102c. MME162 can provide control plane functionality for switching between RAN104 and other RANs (not shown) using other radio technologies such as GSM and / or WCDMA.

[0034] The SGW164 can be connected to each of the eNode-B160a, 160b, and 160c within 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 also perform other functions, such as fixing 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.

[0035] SGW164 can be connected to PGW166, which can provide WTRU102a, 102b, and 102c with access to packet-switched networks such as the Internet 110, facilitating communication between WTRU102a, 102b, and 102c and IP-enabled devices.

[0036] 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 fixed telephone 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.

[0037] While the WTRU is shown as a wireless terminal in Figures 1A to 1D, in certain representative embodiments, it is assumed that such a terminal may be able to use a wired communication interface with a communication network (for example, temporarily or permanently).

[0038] In a typical embodiment, the other network 112 can be a WLAN.

[0039] A WLAN in Infrastructure Basic Service Set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access to or interfaces with a distribution system (DS) or another type of wired / wireless network that transmits traffic into and / or out of the BSS. Traffic originating from outside the BSS to an STA may arrive via the AP and be delivered to the STA. Traffic originating from an STA to a destination outside the BSS may be sent to the AP and delivered to its respective destination. Traffic between STAs within the BSS can be transmitted via the AP. For example, 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 can be transmitted (e.g., directly) between a source STA and a destination STA using a Direct Link Setup (DLS). In certain representative embodiments, the DLS may be 802.11e DLS or 802.11z Tunnel 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 communication mode may be referred to herein as the “ad hoc” communication mode.

[0040] When using 802.11ac infrastructure mode or a similar operating mode, an AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of a fixed width (e.g., a wide bandwidth of 20 MHz) or a dynamically set width. The primary channel may also be the operating channel of the BSS and may be used by the STA to establish a connection with the AP. In certain typical embodiments, collision avoidance carrier sense multiple access (CSMA / CA) may be implemented, for example, in an 802.11 system. In the case of CSMA / CA, the STA, including the AP (e.g., all STAs), can sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, that STA may backoff. One STA (e.g., only one station) can transmit on a particular BSS at any time.

[0041] High-throughput (HT) STAs can use a 40MHz wide channel for communication, for example, by combining a primary 20MHz channel with adjacent or non-adjacent 20MHz channels to form a 40MHz wide channel.

[0042] Very high throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining consecutive 20 MHz channels. 160 MHz channels can be formed by combining eight consecutive 20 MHz channels or two discontinuous 80 MHz channels, which may be referred to as an 80+80 configuration. In the 80+80 configuration, after channel encoding, the data can pass through a segment parser that can split the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing can be performed separately on each stream. The streams may be mapped to two 80 MHz channels, and the data may be transmitted by a transmitting STA. At the receiver of the receiving STA, the above operation for the 80+80 configuration can be reversed, and the combined data can be transmitted to a media access control (MAC).

[0043] Sub-1 GHz operating modes are supported in 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 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV white space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using the non-TVWS spectrum. According to a typical embodiment, 802.11ah can support meter-type control / machine communications (MTC), such as MTC devices in a macro coverage area. MTC devices may have limited functionality, including support for specific bandwidths and / or limited bandwidths (e.g., support only). MTC devices may include batteries with a battery life exceeding a threshold (e.g., to maintain a very long battery life).

[0044] WLAN systems that can support multiple channels, and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that can be designated as the primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by an STA from among all STAs operating in a BSS that support the minimum bandwidth operating mode. In the 802.11ah example, even if the AP and other STAs in the BSS support operating modes of 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidths, the primary channel of an STA that supports (e.g., only supports) 1MHz mode (such as an MTC type device) may be 1MHz wide. Carrier discovery and / or network allocation vector (NAV) settings may depend on the status of the primary channel. For example, if the primary channel is busy because an STA (which only supports 1MHz operating mode) is transmitting to the AP, the entire available frequency band may be considered busy, even if the majority of the available frequency band remains idle.

[0045] In the United States, the available frequency band for 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 available bandwidth for 802.11ah is 6MHz to 26MHz, depending on the country code.

[0046] Figure 1D is a system diagram showing RAN104 and CN106 according to an embodiment. As described above, RAN104 can communicate with WTRU102a, 102b, and 102c via the air interface 116 using NR radio technology. RAN104 can also communicate with CN106.

[0047] RAN104 may include gNB180a, 180b, and 180c, but it will be understood that RAN104 may include any number of gNBs while maintaining consistency with the 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 can implement MIMO technology. For example, gNB180a and 180b can utilize beamforming to transmit signals to and / or receive signals from gNB180a, 180b, and 180c. Thus, gNB180a can, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU102a. In embodiments, gNB180a, 180b, and 180c can implement carrier aggregation technology. For example, gNB180a can transmit carriers of multiple components to WTRU102a (not shown). A subset of these component carriers may be on the unlicensed spectrum, and the remaining component carriers may be on the licensed spectrum. In embodiments, gNB180a, 180b, and 180c can implement cooperative multipoint (CoMP) technology. For example, WTRU102a can receive cooperative transmissions from gNB180a and gNB180b (and / or gNB180c).

[0048] WTRU102a, 102b, and 102c can 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 parts of the radio transmission spectrum. WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using subframes or transmit time intervals (TTIs) of varying or scalable lengths (e.g., varying numbers of OFDM symbols and / or varying lengths of absolute time that persist).

[0049] The 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, the WTRU102a, 102b, and 102c can communicate with the gNB180a, 180b, and 180c without accessing other RANs (e.g., eNode-B160a, 160b, and 160c). In a standalone configuration, the WTRU102a, 102b, and 102c can utilize one or more gNB180a, 180b, and 180c as mobility anchor points. In a standalone configuration, the WTRU102a, 102b, and 102c can communicate with the gNB180a, 180b, and 180c using unlicensed bandwidth signals. In a non-standalone configuration, WTRU102a, 102b, and 102c can communicate with / connect to gNB180a, 180b, and 180c while communicating with / connecting to another RAN 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 may also function as mobility anchors for WTRU102a, 102b, and 102c, and gNB180a, 180b, and 180c may provide additional coverage and / or throughput to service WTRU102a, 102b, and 102c.

[0050] 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, interworking between DC, NR and E-UTRA, routing of user plane data to user plane functions (UPF) 184a and 184b, access to control plane information and routing to mobility management functions (AMF) 182a and 182b, etc. As shown in Figure 1D, the gNB180a, 180b, and 180c can communicate with each other via the Xn interface.

[0051] The CN106 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 the aforementioned elements are shown as part of CN106, it will be understood that any of these elements may be owned and / or operated by entities other than the CN operator.

[0052] AMF182a, 182b may be connected to one or more gNB180a, 180b, 180c within RAN104 via the N2 interface and may function as a control node. For example, AMF182a, 182b may be responsible for user authentication of WTRU102a, 102b, 102c, support for network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selection of specific SMF183a, 183b, registration areas, termination of non-accessible layer (NAS) signaling, mobility management, etc. Network slicing can be used by AMF182a, 182b to customize CN support for WTRU102a, 102b, 102c based on the types of services utilized by WTRU102a, 102b, 102c. For example, various network slices can be established for various use cases, such as services that rely on ultra-high reliability low latency (URLLC) access, services that rely on extended large-scale mobile broadband (eMBB) access, and MTC access services. The AMF182a and 182b can provide control plane functionality for switching between RAN104 and other RANs (not shown) that use other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0053] SMF183a and 183b can be connected to AMF182a and 182b in CN106 via the N11 interface. SMF183a and 183b can also be connected to UPF184a and 184b in CN106 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 DL data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

[0054] UPF184a and 184b can be connected to one or more gNB180a, 180b, and 180c within RAN104 via the N3 interface, which can provide WTRU102a, 102b, and 102c with access to packet-switched networks such as the Internet 110, facilitating communication between WTRU102a, 102b, and 102c and IP-enabled devices. UPF184 and 184b can perform other functions such as packet routing and forwarding, enforcement of user plane policies, support for multi-homed PDU sessions, processing of user plane QoS, buffering of DL packets, and providing mobility anchors.

[0055] CN106 can facilitate communication with other networks. For example, CN106 may include, or communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that functions as an interface between CN106 and PSTN108. Furthermore, CN106 can 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 can be connected to local DN185a, 185b via UPF184a, 184b through an N3 interface to UPF184a, 184b and an N6 interface between UPF184a, 184b and DN185a, 185b.

[0056] With regard to Figures 1A-1D and the corresponding descriptions therein, with respect to one or more of the WTRU102a-d, base stations 114a-b, eNode-B160a-c, MME162, SGW164, PGW166, gNB180a-c, AMF182a-b, UPF184a-b, SMF183a-b, DN185a-b, and / or any other device(s) described herein, one or more, or all, of the functions described herein can be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, emulation devices may be used to test other devices and / or to simulate network and / or WTRU functions.

[0057] Emulation devices can be designed to implement one or more tests of other devices in a lab environment and / or operator network environment. For example, one or more emulation devices can 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 can perform one or more or all functions while temporarily implemented / deployed as part of a wired and / or wireless network. Emulation devices can be directly coupled to another device for the purpose of performing tests and / or tests using over-the-air wireless communication.

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

[0059] The IEEE initially configured the 48-bit MAC address space so that half of the address space was reserved for local use. Local use is configured when the Universal / Local (U / L) bit is set to 1. According to an optional Structured Local Access Plan (SLAP), different allocation approaches can be used within four designated areas of this local MAC address space. These four areas, called the SLAP quadrants, include the Extended Local Identifier (ELI) quadrant, the Standard Allocation Identifier (SAI) quadrant, the Administrative Allocation Identifier (AAI) quadrant, and the quadrant reserved for future use.

[0060] Quadrant ELI MAC addresses can be assigned based on a Company ID (CID) using 24 bits, with the remaining 24 bits reserved for addresses locally assigned to each CID for unicast (M bit=0) and multicast (M bit=1). CIDs are assigned by IEEE Registered Accreditation Authorities (RAs).

[0061] Quadrant SAI MAC addresses are assigned based on protocols specified in the IEEE 802 standard. For a 48-bit MAC address, 44 bits are available. Multiple protocols for assigning SAI can be specified in the IEEE standard. The coexistence of multiple protocols can be supported by limiting the subspace available for assignment by each protocol.

[0062] Quadrant AAI MAC addresses are assigned locally by the administrator. Multicast IPv6 packets use destination addresses starting with 33:33, and since this is within this space, conflicting addresses should not be used to avoid conflicts with IPv6 multicast addresses. For 48-bit MAC addresses, 44 bits are available.

[0063] Quadrants reserved for future use define areas that can be allocated using new methods where MAC addresses have not yet been defined, or by administrators, similar to the allocations made in the AAI quadrant, for example.

[0064] Figure 2A shows an exemplary structure of the IEEE 48-bit MAC address structure. In this example, four least significant bits (LSBs) are identified. LSB M 202 refers to the individual / group (I / G) indicator of the M bit, indicating whether the MAC address is a unicast WTRU or a group of WTRUs. LSB X bit 204 indicates whether the MAC address is locally assigned. LSB Y 206 refers to the SLAP Y bit, and LSB Z 208 refers to the SLAP Z bit. The SLAP Y and X bits are described in detail in Table 220 shown in Figure 2B.

[0065] Figure 2B is Table 220, which outlines the characteristics of the four SLAP quadrants. Table 220 is organized with respect to quadrant 222, Y bit 224, Z bit 226, local identifier type 228, and local identifier 230. For quadrant 01 232, if the Y bit is set to 0 240 and the Z bit is set to 1 248, the local identifier type is extended to local 256 and the local identifier is ELI264. For quadrant 11 234, if the Y bit is set to 1 242 and the Z bit is set to 1 250, the local identifier type is standard assignment 258 and the local identifier is SAI266. For quadrant 00 236, if the Y bit is set to 0 244 and the Z bit is set to 0 252, the local identifier type is administrative assignment 260 and the local identifier is AAI268. In quadrant 10 238, if the Y bit is set to 1 246 and the Z bit is set to 0 254, the local identifier type is reserved 262, and the local identifier is also reserved 270.

[0066] The IEEE is working on a mechanism for assigning addresses to the Standard Assigned Identifier (SAI) quadrant, and in conjunction with this, the Internet Engineering Task Force (IETF) is working on specifying a new mechanism to extend the operation of Dynamic Host Control Protocol version 6 (DHCPv6) to handle local MAC address assignment. In this way, MAC assignment can be handled dynamically. However, these standardization efforts do not provide a mechanism to support a method for selecting the SLAP quadrant to use for assigning MAC addresses to requesting WTRUs, which may be terminals or client units. In embodiments, the DHCPv6 protocol is extended so that a DHCPv6 client or DHCPv6 relay can indicate a preferred SLAP quadrant to a server, and as a result the server can assign MAC addresses to a particular client or relay accordingly. Two exemplary applications where it becomes necessary to assign local MAC addresses according to the preferred SLAP quadrant are described: (1) individual WTRUs, and (2) large-scale virtualization environments such as data centers where many virtual machines are managed by a hypervisor or other virtualization technology.

[0067] Regarding the first application, most WTRUs deployed today have pre-installed interfaces with MAC addresses "burned in" using 24-bit organizationally unique identifiers (OUIs) assigned to IEEE 802 interface vendors and allocated from the universal address space. However, the need to assign local (rather than universal) MAC addresses to WTRUs has recently become apparent, particularly in Internet of Things (IoT) systems and privacy.

[0068] IoT systems can incorporate numerous inexpensive, sometimes short-lived, and disposable devices. For these devices, MAC address reuse is ideal to avoid unnecessarily expanding the MAC address space. Examples of these devices include: sensors and actuators for health or home automation applications. In these systems, it is common for IoT devices to use a temporary MAC address to send an initial DHCP packet to an available DHCP server upon initial startup. IoT devices typically request a single MAC address for each available network interface, e.g., wired and wireless interfaces. Once the server assigns a MAC address, the device discards the temporary MAC address used to send the initial DHCP packet. This type of device is usually not a mobile or highly mobile device. Generally, any type of SLAP quadrant is suitable for address assignment, but in some scenarios, such as when the assigned address needs to belong to a company ID (CID) assigned to the IoT communication device vendor, the ELI / SAI quadrant may be more appropriate.

[0069] Regarding WTRU privacy concerns, exposing MAC addresses makes it possible to expose a user's location, thus making it relatively easy to track a user's movements. One mechanism being considered to mitigate this problem is the use of a local random MAC address that changes each time the user connects to a different network. In this scenario, the device is typically mobile. Here, the AAI quadrant is ideal for address randomization, and the SLAP quadrant can be the ideal one for assigning addresses because the address does not need to persist when changing networks.

[0070] Figure 3A is a depiction of several Internet of Things (IoT) networks 302–306 that interface with a Dynamic Host Configuration Protocol (DHCP) architecture. Each of the IoT networks 302–306 may have one or more IoT devices, including WTRUs, home appliances, door locks, bicycles, fitness sensors, etc. IoT networks 302–304 include DHCP relays 308, 310 for coupling to a DHCP server 312. IoT network 306 does not have to include a DHCP relay, and IoT devices in IoT network 306 can reach the DHCP server 312 directly. In this example, a single ELI 314, SAI 316, and AAI 318 may be used.

[0071] Regarding the second application, virtualization can facilitate the assignment of local MAC addresses. For example, in a large-scale virtualization environment, thousands of virtual machines (VMs) are active. These VMs are typically managed by a hypervisor, which is responsible for creating and stopping VMs as needed. The hypervisor is also typically responsible for assigning new MAC addresses to the VMs. If a DHCP solution is in place for this purpose, the hypervisor acts as a DHCP client, requesting that an available DHCP server assign one or more MAC addresses from an address block. The hypervisor uses those addresses not for itself, but to create new VMs with appropriate MAC addresses. Each VM can have a new MAC address when instantiated. In very large data center environments, it is common to partition into different network regions. Each of these different network regions is configured to manage its own local address space. In this scenario, shown in Figure 3B, there are two elements, including migratable and non-migrative capabilities.

[0072] Figure 3B is a depiction 330 of a large-scale data center 332 interfaced with a DHCP architecture. The large-scale data center 332 can consist of multiple regions 334-340. Each region may contain migratable and non-migratable VMs. Each region 334-340 may include DHCP relays 342-348 for relaying DHCP messages to and from a DHCP server 350. A single ELI quadrant 352 and SAI quadrant 354 may be used. Alternatively, each region may be assigned addresses from AAI quadrants 356-362.

[0073] When a VM providing specific functionality needs to potentially be migrated to a different area of ​​the data center for reasons such as maintenance, resilience, or end-user mobility, it may be required that this VM retain its network context in the new area, including the retention of its MAC address. Therefore, to meet this need, it may be appropriate to assign addresses from the ELI / SAI SLAP quadrant, which can be centrally assigned by a DHCP server.

[0074] On the other hand, if it is known that a VM is unlikely to be migrated to another region of the data center, there may be no requirements associated with its MAC address. In this scenario, it is more efficient to assign MAC addresses from the AAI SLAP quadrant, which does not need to be the same for all data centers. In embodiments, each region can manage its own MAC addresses without having to check for duplicates globally.

[0075] A mechanism for SLAP quadrant selection from a terminal to determine which MAC address to use and when to change the assigned MAC address can be determined based on contextual information and / or preferences indicated by the terminal, such as a WTRU, or by infrastructure such as a base station or cellular core network server. As described herein, these mechanisms can be implemented within each of the aforementioned applications, such as IoT applications, privacy-conscious implementation applications, and data center applications.

[0076] In an IoT architecture, IoT devices can attach to a WLAN network using a pre-set temporary MAC address. This allows the device to acquire a connection and bootstrap properly. During this phase, the device can acquire information and / or preferences to help determine which SLAP quadrant to use to set a persistent local MAC address rather than a temporary pre-set address. As shown in Figure 4, IoT devices can make standalone or infrastructure-assisted decisions regarding which SLAP quadrant to use to obtain a local MAC address.

[0077] Figure 4 shows the signaling for IoT quadrant selection in both standalone decision 400 and infrastructure-assisted decision 420 modes. When making a standalone decision 400, the IoT device 402 may rely on contextual information, including, but is not limited to, the type of IoT deployment such as industrial, national, or local, mobility, whether the device is managed or unmanaged, and / or operation / battery life. In the case of small-scale deployments such as national deployments, the IoT device 402 itself may decide to use the AAI quadrant. This decision may, in embodiments, not involve the use of DHCP by the terminal, which constitutes a random address calculated by the terminal itself. Otherwise, DHCP signaling 406 may be used. In the case of large-scale deployments such as industrial or local deployments where thousands of terminals may coexist, the IoT device 402 may decide to use the ELI or SAI quadrant. If the IoT device 402 can or may move, it may be preferable to select the SAI or AAI quadrant to minimize address collisions when moving to a different network. If it is known that IoT device 402 will remain stationary, the ELI quadrant may be the most suitable for use. The chosen quadrant may differ depending on whether IoT device 402 is managed or cannot be reconfigured during its lifetime. For example, if it can be managed, this means that changes in the network topology may occur during its lifetime, for example, due to changes in deployment such as expansions involving additional terminals, which may influence the preferred quadrant to avoid future potential collisions. Depending on the expected lifetime of the terminal, different quadrants may be preferred to minimize future potential address collisions. These are examples of parameters that an IoT terminal can use to select a particular SLAP quadrant. Other parameters may also be dependent. Because IoT terminals are typically resource-constrained, they can make simple decisions based on, for example, pre-configured preferences or settings.

[0078] In IoT scenarios, it is more likely that the selected quadrant will be ELI in most cases. In this case, the MAC address provided to the terminal is based on a Company ID (CID), which is typically pre-configured in the terminal as a burned temporary address. However, in large-scale IoT deployments, such as local or industrial ones, the address space from a single CID may be exhausted. In this case, the terminal can provide a list of preferred CIDs that the DHCP server 404 will use to provide MAC addresses. Additional CIDs may belong to other vendors with whom the IoT terminal manufacturer has business relationships or contracts (e.g., subsidiaries of the IoT terminal vendor). If the quadrant selected by the terminal is ELI, the DHCP server 404 can assign addresses from the primary CID, from any of the additionally provided CIDs, or even from different CIDs. In all cases, the DHCP server 404 can or may check which CIDs are available to assign a local MAC address to the terminal. This can be done, for example, by a DHCP server 404 that has a list of permitted CIDs for each IoT terminal. Figure 5 shows an illustrative procedure illustrating how an IoT device can select a quadrant and perform local MAC address configuration.

[0079] When making an infrastructure-assisted decision 420, the IoT terminal 422 receives a hint / preference / request 426 from the infrastructure regarding the SLAP quadrant to use to obtain its local MAC address. In IoT scenarios, this hint may be signaled 426 from a bootstrap / configuration server 424 that the IoT terminal 422 uses to complete its configuration. The server 424 may also perform quadrant selections, including (1) the type of IoT deployment, (2) mobility, and / or (3) operation / battery life, using parameters correlated with the IoT terminal's deployment environment / context.

[0080] The right side of Figure 4 shows the general operation of the infrastructure support decision 420. The IoT terminal 422 connects to a bootstrap / configuration server 424, which can run on the cloud or locally where the IoT terminal 422 is deployed, and receives the selected SLAP quadrant to be used in DHCP signaling 430 by the DHCP server 428 as part of bootstrap / configuration signaling 426.

[0081] Figure 5 is a flowchart 500 for determining quadrant selection in an embodiment of an IoT terminal. In this embodiment, a bootstrap IoT device 502 can determine whether it is a component of a large-scale deployment 504. If it is determined that it is not a component of a large-scale deployment 506, the IoT terminal can select the AAI quadrant 508. The IoT device can be configured to select a random address locally from the AAI quadrant 510. If configured to select a random address locally 512, the IoT can select a random address 514 from the AAI quadrant. Conversely 516, the IoT device can perform DHCP signaling 518 indicating the AAI quadrant using a DHCP server or other server.

[0082] If the IoT device is part of a large-scale deployment, the IoT device may consider mobility as a factor when performing quadrant selection. If the device is likely to be mobile, the IoT device may use the SAI quadrant and may perform DHCP, indicating SAI.

[0083] If the IoT device is expected to be stationary and not mobile 530, the IoT device may select ELI quadrant 532 and determine whether to include CID 534. If the IoT device has a CID including 536, the IoT device may perform DHCP signaling indicating ELI 538 and include preferred CID. The IoT device may include additional CIDs as needed. If the IoT device determines that the CID is not used 550 534, the IoT device may perform DHCP signaling indicating AAI quadrant 552.

[0084] Assuming the IoT device performs DHCP signaling 538 with at least one CID indicated, the DHCP server can determine if the address is available from primary CID 540. If the address is available from primary CID 542, the DHCP server can provide the local MAC address from primary CID 544. If no address is available 546, the DHCP server can provide the local MAC address from additional CID 548.

[0085] Privacy-enhanced solutions for assigning local MAC addresses to WTRUs can define additional steps. In these scenarios, WTRUs, such as laptops and smartphones, connect to the network using their built-in MAC address. Due to privacy / security concerns, a device may want to configure its local MAC address. The device can use different parameters and contextual information to determine when to perform an address change, as well as the SLAP quadrant used for local MAC address configuration. In some embodiments, an address change may be performed several times over the device's lifespan. Contextual information may include, but is not limited to, the type of network the device is connected to (e.g., public, work, home), whether the network is trusted, whether it is the device's first time accessing the network, the network's geographical location, whether the device is mobile, an operating system (OS) network profile including security / trust-related parameters, and / or triggers provided by applications running on the device regarding location privacy. Regarding OS network profiles, most modern operating systems maintain metadata associated with networks that can or may connect to, such as the level of trust that a user or administrator assigns to the network. This information can be used to configure how a device behaves regarding network advertising itself, firewall settings, etc. However, this information can or may be used to determine whether to configure a local MAC address, from which SLAP quadrant it should be configured, and how often it should be configured. Regarding application triggers, an application, for example, depending on the nature of the application, can request the OS to maximize location privacy, which could mean the OS forcing the use or modification of a local MAC address.

[0086] This information can be used to select the SLAP quadrant for a device. For example, if a device is moving (e.g., connected to a public network at an airport), it is best to use the SAI or AAI quadrant to minimize the possibility of address collisions, as the access point may change several times. If the device is not moving and not connected to a trusted network (e.g., a workplace), it is probably best to select the ELI quadrant. These are just a few examples of how this information can be used to select a quadrant. Furthermore, this information can also be used to trigger subsequent changes in the MAC address, enhancing location privacy. Additionally, changing the SLAP quadrant used can also be used as an additional extension to make it harder to track a user's location.

[0087] In data center applications, the hypervisor may require a local MAC address to be assigned to a virtual machine. As in other embodiments, the hypervisor may use information provided by the Cloud Management System (CMS) or Virtualization Infrastructure Manager (VIM) running on the hypervisor to select a preferred SLAP quadrant. This information may include, but is not limited to, whether the VM is migratable or non-migrationable, and / or VM connectivity characteristics such as standalone, part of a pool, or part of a service graph / chain. Whether a VM is migratable influences the SLAP quadrant preference, as some quadrants (e.g., ELI / SAI) are better suited to supporting migrations in large data centers. VM connectivity characteristics, if known, can be used by the hypervisor to select the optimal SLAP quadrant.

[0088] In relation to either the WTRU or data center application described above, various DHCPv6 extensions can be defined that outline the steps necessary to select the SLAP quadrant of the local MAC address according to the configuration of the requesting DHCPv6 client. Such steps may differ depending on whether the SLAP quadrant is indicated by a DHCP client, such as a terminal / IoT device, or by a DHCP relay.

[0089] Figure 6 illustrates the steps defined in an exemplary extension for allowing address assignment when a preferred SLAP quadrant is indicated by a DHCP client. In Step 1, link-layer addresses (i.e., MAC addresses) are assigned in blocks. The smallest block is a single address. To request an assignment, the client sends a request message 606 containing an IA_LL option in the message. The IA_LL option must contain an LLADDR option. To indicate a preferred SLAP quadrant, the IA_LL option contains a new quadrant IA-LL option that includes the preferred quadrant. In Step 2, when the server receives the IA_LL option, it inspects its contents and may provide addresses for each LLADDR option according to the policy. The server returns an advertise message 608 containing an IA_LL option that includes an LLADDR option specifying the addresses being provided. If the server supports a new quadrant IA-LL option and manages blocks of addresses belonging to the requested quadrant, the addresses being provided must belong to the requested quadrant. If the server does not have an address from the requested quadrant, the server must return an IA_LL option that includes a status code option with the status set to NoQuadAvail. In step 3, the client waits for available servers to send advertised responses and extracts one server. The client then sends a request message 610 that includes an IA_LL container option with an LLADDR option copied from the advertised message sent by the selected server. It includes a preferred SLAP quadrant in the new quadrant IA-LL option. In step 4, upon receiving the request message 610 with the IA_LL container option, the server assigns the requested address. The server may change the assignment at this point. It then generates a response message 612 and sends it back to the client. Upon receiving the response message 612, the client can parse the IA_LL container option 614 and begin using all the provided addresses.It should be noted that a client that includes the quick commit option in its request may receive a response in response to the request and skip the above advertise and request steps (following the standard DHCPv6 procedure). In step 5, when the assigned address is about to expire, 616 the client sends an update message 618. In step 6, the server responds with a response message 620 that includes the LLADDR option, which has an extended lifetime.

[0090] Figure 7 illustrates the steps defined in an exemplary extension to enable address assignment when the preferred SLAP quadrant is indicated by the DHCP relay. This is useful when the DHCP server is operating on a large infrastructure divided into different network regions, each region potentially having different requirements. This example is a deployment where IoT and regular WiFi-enabled end-user devices coexist, but are divided into two different WiFi networks, each managed by a different DHCPv6 relay. In Step 1, link-layer addresses (i.e., MAC addresses) are assigned in blocks. The smallest block is a single address. To request an assignment, the client sends a solicitation message 708 that includes the IA_LL option in the message. The IA_LL option must include the LLADDR option. In Step 2, the DHCP relay receives the solicitation message and encapsulates it in a relay-forwarding message 710. Local knowledge and policy-based relays include the preferred quadrant in the relay agent remote ID option. The relay may be able to determine the requested quadrant based on its local configuration (for example, ELI / SAI is required because the network being provided only contains IoT devices) or other means, such as based on analysis of the request message from the client. In step 3, when the server receives the forwarded request message containing the IA_LL option, it may inspect its contents and provide addresses for each LLADDR option according to its policy. The server sends back an advertised message containing the IA_LL option, which includes the LLADDR option specifying the address being provided. This message is sent to the relay in relay-response message 712. If the server supports the semantics of preferred quadrants included in the relay agent remote ID option and manages a block of addresses belonging to the requested quadrant, the provided address must belong to the requested quadrant. In step 4, the relay sends the received advertised message 714 to the client.In step 5, the client waits for available servers to send advertised responses and selects one server. The client then sends a request message 716 containing the IA_LL container option with the LLADDR option copied from the advertised message sent by the selected server. In step 6, the relay forwards the received request in relay-forward message 718, adding the relay agent remote ID option to the preferred quadrant. In step 7, upon receiving the forwarded request message with the IA_LL container option, the server assigns the requested address. The server may change the assignment at this point. It then generates a response message and sends it back to the relay in relay-response 720. In step 8, upon receiving the response message 722, the client can parse the IA_LL container option and begin using all the provided addresses. In step 9, when the assigned address 724 is about to expire 726, the client sends an update message 728. In step 10, this message is forwarded by the relay in relay-forward message 730. In step 11, the server responds with a response message that includes the LLADDR option with an extended lifespan. This message is sent in relay response message 732. In step 12, the relay sends response message 734 back to the client.

[0091] Further disclosed herein are a variety of novel DHCPv6 options and values ​​used to indicate one or more priority quadrants.

[0092] Figure 8 provides an example format of the Quadrant (IA-LL) option 800, along with a description of the example fields. As discussed with reference to Figure 4, the Quadrant (IA-LL) option can be used to specify preferences for selected quadrants within IA_LL. The option can be encapsulated in the IA_LL-option field of the IA_LL option. In this example, the 16-bit option_quadrant field 802 can be set to a value assigned by the Internet Assigned Numbering Authority (IANA). The 16-bit option-long field 804 can represent the number of quadrants and preferences included in the Quadrant (IA-LL) option 800. The fields Quadrant-1 806 and Preference-1 808 can refer to quadrant identifiers and preferences. A second quadrant and preference can be indicated by the Quadrant-2 810 and Preference-2 812 fields. The 32-bit 814 can be reserved for future use or used to indicate additional quadrants and / or preferences. In this embodiment, the quadrants may be listed in the order of preferences, so the preferences do not necessarily need to be explicitly shown.

[0093] Figure 9 provides an example format of the Additional CID (IA-LL) option 900, along with a description of the fields included. The Additional CID option 900 can be used to forward an Additional CID in addition to the one used as the source address of the message in IA_LL (i.e., the temporary one written). This option should be used if the ELI is included as one of the preferred SLAP quadrants of the Quadrant IA_LL option.

[0094] The Additional CID (IA-LL) option 900 includes a 16-bit option_CID field 902, which can be a value assigned by IANA. The option-length field can be used to indicate the number of CIDs included in the Additional CID (IA-LL) option 900. The example shown includes three CIDs: cid-1 906, cid-2 908a-908b, and cid-3 910.

[0095] The relay agent remote ID option can also be used to include quadrants in DHCPv6 signaling. The definition of the values ​​used in the relay agent remote ID option is vendor-specific. The vendor is indicated in the optional company number field. The remote-id field can be used to encode the preferred SLAP quadrant.

[0096] 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 computer-readable media include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of 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, optical media such as CD-ROM discs, and digital multi-purpose discs (DVDs). A processor associated with the software can be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method performed by a client device, Selecting the Structured Local Address Plan (SLAP) quadrant, Sending a first message indicating the SLAP quadrant to the server, A method comprising receiving a second message from the server, which includes a media access control (MAC) address from the SLAP quadrant, wherein the MAC address belongs to a block of MAC addresses managed by the server.

2. The method according to claim 1, wherein the SLAP quadrant is selected based on contextual information including the number of nodes in the network, the type of network deployment, the type of network, the mobility configuration, the type of device management, the battery life, the location, or the privacy configuration.

3. The method according to claim 2, wherein the context information is received by the client from the bootstrap server.

4. The method according to claim 1, wherein the SLAP quadrant is an Extended Local Identifier (ELI) quadrant.

5. The method according to claim 1, wherein the SLAP quadrant is a standard assignment identifier (SAI) quadrant.

6. The method according to claim 1, wherein the SLAP quadrant is an administratively assigned identifier (AAI) quadrant.

7. The method according to claim 1, wherein the content of the first message passes through one or more DHCP version 6 (DHCPv6) relays.

8. The method according to claim 1, wherein the content of the second message passes through one or more DHCP version 6 (DHCPv6) relays.

9. It is a client device, A circuit configured to select a Structured Local Address Plan (SLAP) quadrant, A transmitter configured to send a first message indicating the SLAP quadrant to the server, A client device comprising: a receiver configured to receive a second message from the server, the receiver including a media access control (MAC) address in the SLAP quadrant, wherein the MAC address belongs to a block of MAC addresses managed by the server.

10. The client device according to claim 9, wherein the SLAP quadrant is selected based on contextual information including the number of nodes in the network, the type of network deployment, the type of network, the mobility configuration, the type of device management, the battery life, the location, or the privacy configuration.

11. The client device according to claim 10, wherein the context information is received from the bootstrap server.

12. The client device according to claim 9, wherein the SLAP quadrant is an Extended Local Identifier (ELI) quadrant.

13. The client device according to claim 9, wherein the SLAP quadrant is the standard assigned identifier (SAI) quadrant.

14. The client device according to claim 9, wherein the SLAP quadrant is the administratively assigned identifier (AAI) quadrant.

15. The client device according to claim 9, wherein the content of the first message passes through one or more DHCP version 6 (DHCPv6) relays.

16. The client device according to claim 9, wherein the content of the second message passes through one or more DHCP version 6 (DHCPv6) relays.

17. A server, A receiver configured to receive a first message from a client device indicating a Structured Local Address Plan (SLAP) quadrant, wherein the SLAP quadrant is selected by the client device, and the receiver A circuit configured to determine whether the SLAP quadrant belongs to a block of media access control (MAC) addresses managed by the server, It is a transmitter, When the server manages a block of MAC addresses belonging to the indicated SLAP quadrant, it sends a second message indicating the MAC address of the SLAP quadrant to the client device. If the server does not manage a block of MAC addresses belonging to the indicated SLAP quadrant, it sends a third message to the client device indicating that there are no available MAC addresses. A server comprising a transmitter configured to perform the following actions.

18. The server according to claim 17, wherein the first message includes the quadrant IA_LL option which includes the SLAP quadrant indicated above.

19. The server according to claim 18, wherein the server is a Dynamic Host Control Protocol (DHCP) server and the client device is a DHCP client device.

Images