KR20210126561A - Methods for specifying a type of MAC address with dynamic allocation mechanisms - Google Patents

Abstract

A method performed by a WTRU may include receiving context information from an infrastructure equipment and selecting a SLAP quadrant for MAC address assignment. The selecting may be based on context information received from the infrastructure equipment, which may be a bootstrapping server for the WTRU. The method may further include sending, to the DHCP server, a DHCP message indicating the selected SLAP quadrant. In response to the transmitted DHCP message, a MAC address may be received and configured in the WTRU. Context information includes, but is not limited to, number of nodes in the network, type of network deployment, type of network, mobility configuration, type of device management, battery life, location or privacy configuration.

Description

How to use a dynamic allocation mechanism to specify a MAC address type

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to U.S. Provisional Application No. 62/794,148, filed on January 18, 2019, the contents of which are incorporated herein by reference.

A method performed by a wireless transmit/receive unit (WTRU) comprises receiving context information from infrastructure equipment and assigning a media access control (MAC) address. selecting a structured local address plan (SLAP) quadrant for the The selecting may be based on context information received from the infrastructure equipment, which may be a bootstrapping server for the WTRU. The method may further include sending, to a dynamic host control protocol (DHCP) server, a DHCP message indicating the selected SLAP quadrant. In response to the transmitted DHCP message, a MAC address may be received and configured in the WTRU. Context information includes, but is not limited to, number of nodes in the network, type of network deployment, type of network, mobility configuration, type of device management, battery life, location or privacy configuration.

A more detailed understanding may be provided from the following description, given by way of example in conjunction with the accompanying drawings, in which like reference numbers indicate like elements.
1A is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented.
1B is a system diagram illustrating an exemplary wireless transmit/receive unit (WTRU) that may be used within the communication system shown in FIG. 1A, in accordance with an embodiment.
1C is a system illustrating an exemplary radio access network (RAN) and an exemplary core network (CN) that may be used within the communication system shown in FIG. 1A , according to an embodiment; It is also
1D is a system diagram illustrating additional exemplary RANs and additional exemplary CNs that may be utilized within the communication system shown in FIG. 1A , in accordance with an embodiment.
2A is an exemplary structure illustrating the four least significant bits of a 48-bit-MAC address.
2B is a table schematically showing characteristics of the four SLAP quadrants identified using Y-bits and Z-bits.
3A is a diagram of several Internet of Things (IoT) networks interfacing with a Dynamic Host Configuration Protocol (DHCP) architecture.
3B is a diagram of a large data center interfacing with a DHCP architecture.
4 is a diagram illustrating signaling for IoT quadrant selection in both standalone decision and infrastructure-assisted decision modes.
5 is a flowchart of a decision for quadrant selection in an IoT terminal embodiment.
6 is a DHCPv6 signaling flow diagram with client-server extensions.
7 is a DHCPv6 signaling flow diagram with client-repeater-server extensions.
8 is a diagram of a Quad (IA-LL) option format.
9 is a diagram of the Additional CIDs (IA-LL) option format.

1A is a diagram illustrating an example communication system 100 in which one or more disclosed embodiments may be implemented. Communication system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. Communication system 100 may allow multiple wireless users to access such content through sharing of system resources, including wireless bandwidth. For example, communication systems 100 may include code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), ), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), ZT-UW-DFT-S-OFDM (zero-tail unique-word discrete Fourier transform Spread OFDM), UW- One or more channel access methods such as unique word OFDM (OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like may be used.

As shown in FIG. 1A , a communication system 100 includes wireless transmit/receive units (WTRUs) 102a , 102b , 102c , 102d , a radio access network (RAN) 104 , and a core network (CN) 106 . ), a public switched telephone network (PSTN) 108 , the Internet 110 , and other networks 112 , although the disclosed embodiments may include any number of WTRUs, base stations and , networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. As an example, any of the WTRUs 102a , 102b , 102c , 102d may be referred to as a station (STA), configured to transmit and/or receive wireless signals, and may be configured as a user equipment (UE). ), mobile station, fixed or mobile subscriber unit, subscription-based unit, pager, cellular telephone, personal digital assistant (PDA), smartphone, laptop , netbooks, personal computers, wireless sensors, hotspot or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical applications device and applications (eg, telesurgery), industrial device and applications (eg, robots and/or other wireless devices operating in an industrial and/or automated processing chain context), consumer electronic device, commercial and/or a device operating in industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

Also, communication systems 100 may include a base station 114a and/or a base station 114b. Base stations 114a , 114b each have WTRUs 102a , 102b , 102c to facilitate access to one or more communication networks, such as CN 106 , Internet 110 , and/or other networks 112 . , 102d) may be any type of device configured to wirelessly interface with at least one of. As an example, the base stations 114a and 114b are a base transceiver station (BTS), a next generation NodeB, such as a NodeB, eNode B (eNB), Home Node B, Home eNode B, gNode B (gNB), NR ( It may be a new radio) NodeB, a site controller, an access point (AP), a wireless router, or the like. While base stations 114a, 114b are each depicted as a single element, it will be understood that base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

Base station 114a can be configured with other base stations and/or network elements (shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. not part of the RAN 104 ). Base station 114a and/or base station 114b may be configured to transmit and/or receive wireless signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in the licensed spectrum, the unlicensed spectrum, or a combination of the licensed and unlicensed spectrum. A cell may provide coverage for wireless services in a specific geographic area that may be relatively fixed or may 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, one for each sector of the cell. In an embodiment, base station 114a may utilize multiple input multiple output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and/or receive signals in desired spatial directions.

Base stations 114a, 114b may be any suitable wireless communication link (eg, radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV) light, visible light, etc.) It may communicate with one or more of the WTRUs 102a , 102b , 102c , 102d via the air interface 116 . The air interface 116 may be established using any suitable radio access technology (RAT).

More specifically, as noted 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, and the like. For example, the base station 114a and the WTRUs 102a, 102b, 102c in the RAN 104 may establish the air interface 116 using wideband CDMA (WCDMA), Universal A radio technology such as Mobile Telecommunications System (UMTS) Terrestrial Radio Access) may be implemented. WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink (DL) Packet Access (HSDPA) and/or High-Speed Uplink (UL) Packet Access (HSUPA).

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

In an embodiment, the base station 114a and the WTRUs 102a , 102b , 102c may implement a radio technology such as NR radio access that may establish the air interface 116 using NR.

In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, using, for example, dual connectivity (DC) principles. . Accordingly, the air interface used by the WTRUs 102a , 102b , 102c is a transmission transmitted to/from multiple types of radio access technologies and/or multiple types of base stations (eg, eNB and gNB). can be characterized by

In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c are IEEE 802.11 (ie, Wireless Fidelity (WiFi)), IEEE 802.16 (ie, Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, IS-2000 (Interim Standard 2000), IS-95 (Interim Standard 95), IS-856 (Interim Standard 856), GSM (Global System for Mobile communications), EDGE (Enhanced Data rates for Radio technologies such as GSM Evolution) and GSM EDGE (GERAN) may be implemented.

The base station 114b in FIG. 1A may be, for example, a wireless router, Home Node B, Home eNode B, or access point, and may be a business, home, vehicle, campus, industrial facility, (eg, to a drone). Any suitable RAT may be used to facilitate wireless access in a localized area, such as a location such as an air corridor, road, etc.). In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d use a cellular-based RAT (eg, WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) A picocell or a femtocell may be established. As shown in FIG. 1A , the base station 114b may have a direct connection to the Internet 110 . Accordingly, the base station 114b may not need to access the Internet 110 via the CN 106 .

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

The CN 106 may also serve as a gateway for the WTRUs 102a , 102b , 102c , 102d to access the PSTN 108 , the Internet 110 , and/or other networks 112 . The PSTN 108 may include circuit switched telephone networks that provide plain old telephone service (POTS). Internet 110 is an interconnect using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and/or Internet Protocol (IP) in the TCP/IP Internet protocol suite. a global system of computer networks and devices. Networks 112 may include wired and/or wireless communication networks owned and/or operated by other service providers. For example, networks 112 may include another CN connected to one or more RANs, which may use the same RAT as RAN 104 or a different RAT.

Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities (eg, the WTRUs 102a, 102b, 102c, 102d may have different radios may include multiple transceivers for communicating with different wireless networks via links). For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with a base station 114a that may utilize a cellular-based radio technology, and a base station 114b that may utilize an IEEE 802 radio technology.

1B is a system diagram illustrating an example WTRU 102 . As shown in FIG. 1B , the WTRU 102 includes, among other things, a processor 118 , a transceiver 120 , a transmit/receive element 122 , a speaker/microphone 124 , a keypad 126 , a display/ may include a touchpad 128 , non-removable memory 130 , removable memory 132 , a power source 134 , a global positioning system (GPS) chipset 136 , and/or other peripherals 138 . It will be appreciated that the WTRU 102 may include any subcombination of the foregoing elements while remaining consistent with an embodiment.

Processor 118 may be a general purpose processor, special purpose processor, conventional processor, 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). , field programmable gate arrays (FPGAs), any other type of integrated circuit (IC), state machine, or the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functions that enable 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 . 1B shows the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together within an electronic package or chip.

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

Although the transmit/receive element 122 is shown in FIG. 1B as a single element, the WTRU 102 may include any number of transmit/receive elements 122 . More specifically, the WTRU 102 may utilize MIMO technology. Accordingly, in one embodiment, the WTRU 102 includes two or more transmit/receive elements 122 (eg, multiple antennas) for transmitting and receiving wireless signals over an air interface 116 . can do.

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

The processor 118 of the WTRU 102 may include a speaker/microphone 124 , a keypad 126 , and/or a display/touchpad 128 (eg, a liquid crystal display (LCD) display unit or organic light (OLED) display unit). -emitting diode) display unit) and receive user input data therefrom. Processor 118 may also output user data to speaker/microphone 124 , keypad 126 , and/or display/touchpad 128 . In addition, processor 118 may access information from, and store data in, any type of suitable memory, such as non-removable memory 130 and/or removable memory 132 . 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 identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 accesses information from, and stores data in, memory that is not physically located on the WTRU 102 , such as on a server or home computer (not shown). can be saved.

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

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

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, functionality, and/or wired or wireless connectivity. For example, peripherals 138 may include an accelerometer, electronic compass (e-compass), satellite transceiver, digital camera (for photos and/or video), universal serial bus (USB) port, vibration device, television transceiver, hands-free (hands free) headsets, Bluetooth® modules, frequency modulated (FM) radio units, digital music players, media players, video game player modules, internet browsers, virtual and/or augmented reality (VR/AR) devices, activity trackers ( activity tracker) and the like. Peripherals 138 may include one or more sensors. Sensors include 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 It may be one or more of, etc.

The WTRU 102 transmits and receives some or all of the signals (eg, associated with specific subframes for both UL (eg, for transmission) and DL (eg, for reception)). This may include a full duplex radio that may be concurrent and/or concurrent. A full-duplex radio reduces magnetic interference or substantially reduces magnetic interference through hardware (eg, a choke) or signal processing through a processor (eg, through a separate processor (not shown) or processor 118 ). and an interference management unit that removes the . In an embodiment, the WTRU 102 may configure some of the signals (eg, associated with specific subframes for either UL (eg, for transmission) or DL (eg, for reception)) or a half-duplex radio for all transmission and reception.

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

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

Each of the eNode-Bs 160a , 160b , 160c may be associated with a specific cell (not shown) and may make radio resource management decisions, handover decisions, scheduling of users in the UL and/or DL, etc. may be configured to process. As shown in FIG. 1C , the eNode-Bs 160a , 160b , 160c may communicate with each other via an X2 interface.

The CN 106 shown in FIG. 1C may include a Mobility Management Entity (MME) 162 , a Serving Gateway (SGW) 164 , and a Packet Data Network (PDN) Gateway (PGW) 166 . Although the foregoing elements are shown as part of the CN 106 , it will be understood that any of these elements may be owned and/or operated by entities other than the CN operator.

The MME 162 may be connected to each of the eNode-Bs 162a , 162b , 162c in the RAN 104 via an S1 interface and may act as a control node. For example, the MME 162 authenticates users of the WTRUs 102a, 102b, 102c, activates/deactivates bearer, and serves specific during initial attach of the WTRUs 102a, 102b, 102c. It may be responsible for selecting a gateway, etc. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) using other radio technologies such as GSM and/or WCDMA.

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

The SGW 164 provides the WTRUs 102a, 102b, 102c, such as the Internet 110, to facilitate communication between the WTRUs 102a, 102b, 102c and IP-enabled devices. may be connected to a PGW 166, which may provide access to packet switched networks.

The CN 106 may facilitate communication with other networks. For example, the CN 106 may provide the PSTN 108 to the WTRUs 102a, 102b, 102c to facilitate communication between the WTRUs 102a, 102b, 102c and traditional land-line communication devices. ) can provide access to circuit switched networks such as For example, the CN 106 may include or communicate with an IP gateway (eg, an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108 . The CN 106 also provides the WTRUs 102a, 102b, 102c for other networks 112, which may include other wired and/or wireless networks owned and/or operated by other service providers. access can be provided.

Although a WTRU is described as a wireless terminal in FIGS. 1A-1D , it is contemplated that in certain representative embodiments, such a terminal may utilize (eg, temporarily or permanently) wired communication interfaces with a communication network.

In representative embodiments, the other network 112 may be a WLAN.

A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) to the BSS and one or more stations (STA) associated with the AP. The AP may have access or interface to a distribution system (DS), or other type of wired/wireless network that carries traffic into and/or out of the BSS. Traffic to STAs originating outside the BSS may arrive through the AP and may be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS may be transmitted to the AP to be delivered to the respective destinations. Traffic between STAs in the BSS may be sent via an AP, eg, a source STA may send traffic to an AP, and the AP may forward traffic to a destination STA. Traffic between STAs in a BSS may be considered and/or referred to as peer-to-peer traffic. Peer-to-peer traffic may be transmitted between (eg, directly between) source and destination STAs via 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 cannot have an AP, and STAs within or using IBSS (eg, all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an “ad hoc” communication mode.

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

High Throughput (HT) STAs may use a 40 MHz wide channel for communication, for example, by combining a primary 20 MHz channel and an adjacent or non-adjacent 20 MHz channel to form a 40 MHz wide channel.

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

Sub 1 GHz operating modes are supported by 802.11af and 802.11ah. Channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz and 16 MHz bandwidths using the non-TVWS spectrum. According to an exemplary embodiment, 802.11ah may support Meter Type Control/Machine-Type Communications (MTC), such as MTC devices in a macro coverage area. have. MTC devices may have certain capabilities, such as limited capabilities, including, for example, support for (eg, support only for) certain and/or limited bandwidths. MTC devices may include a battery whose battery life is above a threshold (eg, to keep the battery life very long).

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 a 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 main channel may be set and/or limited by the STA among all STAs operating in the BSS supporting the minimum bandwidth operation mode. In the example of 802.11ah, the primary channel supports 1 MHz mode (e.g., only that Supporting STAs (eg, MTC type devices) may be 1 MHz wide. Carrier sensing and/or network allocation vector (NAV) settings may depend on the state of the primary channel. If the main channel is busy, for example due to the STA transmitting to the AP (which supports only 1 MHz mode of operation), all available frequencies, even if most of the available frequency bands are idle. Bands may be considered to be busy.

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

1D is a system diagram illustrating a RAN 104 and a CN 106, according to an embodiment. As noted above, the RAN 104 may use NR radio technology to communicate with the WTRUs 102a , 102b , 102c over the air interface 116 . The RAN 104 may also communicate with the CN 106 .

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

The WTRUs 102a , 102b , 102c may communicate with the gNBs 180a , 180b , 180c using transmissions associated with scalable numerology. For example, the OFDM symbol spacing and/or OFDM subcarrier spacing may vary for different transmissions, different cells, and/or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may be configured in a subframe or transmission time interval of varying or scalable lengths (eg, including a variable number of OFDM symbols and/or continuously variable lengths of absolute time). interval) (TTIs) may be used to communicate with the gNBs 180a, 180b, 180c.

The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and/or in a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c communicate with the gNBs 180a, 180b, 180c without access to other RANs (eg, such as eNode-Bs 160a, 160b, 160c). can communicate. In a standalone configuration, the WTRUs 102a , 102b , 102c may use one or more of the gNBs 180a , 180b , 180c as a mobility anchor point. In a standalone configuration, the WTRUs 102a , 102b , 102c may communicate with the gNBs 180a , 180b , 180c using signals in the unlicensed band. In a non-standalone configuration, the WTRUs 102a , 102b , 102c communicate or connect with the gNBs 180a , 180b , 180c while also communicating or connecting with another RAN, such as the eNode-Bs 160a , 160b , 160c . can be For example, the WTRUs 102a, 102b, 102c may implement DC principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c. have. In a non-standalone configuration, the eNode-Bs 160a , 160b , 160c may serve as mobility anchors for the WTRUs 102a , 102b , 102c , and the gNBs 180a , 180b , 180c may serve as the WTRUs 102a , 102b, 102c) may provide additional coverage and/or throughput.

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

The CN 106 shown in FIG. 1D includes at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly data network (DN) 185a, 185b. Although the foregoing elements are shown as part of the CN 106 , it will be understood that any of these elements may be owned and/or operated by entities other than the CN operator.

The AMF 182a , 182b may connect with one or more of the gNBs 180a , 180b , 180c in the RAN 104 via an N2 interface and may function as a control node. For example, the AMF 182a , 182b may use user authentication of the WTRUs 102a , 102b , 102c , network slicing (eg, of different protocol data unit (PDU) sessions with different requirements). processing), selection of specific SMFs 183a and 183b, management of registration areas, termination of non-access stratum (NAS) signaling, mobility management, and the like. Network slicing may be used by the AMF 182a, 182b to customize CN support for the WTRUs 102a, 102b, 102c based on the types of services they use. . For example, different network slices can be used for services that rely on ultra-reliable low latency (URLLC) access, services that rely on enhanced massive mobile broadband (eMBB) access, MTC may be established for different use cases, such as services for access, and the like. The AMFs 182a and 182b are connected to the RAN 104 with other RANs (not shown) using other radio technologies, such as LTE, LTE-A, LTE-A Pro, and/or non 3GPP access technologies such as WiFi. It can provide a control plane function to switch between.

The SMFs 183a and 183b may be connected to the AMFs 182a and 182b in the CN 106 via an N11 interface. SMFs 183a, 183b may also be connected to UPFs 184a, 184b in CN 106 via an N4 interface. The SMFs 183a and 183b may select and control the UPFs 184a and 184b, and may configure routing of traffic through the UPFs 184a and 184b. The SMFs 183a and 183b may perform other functions such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing DL data notifications, and the like. The PDU session type may be IP-based, non-IP-based, Ethernet-based, or the like.

The UPF 184a, 184b provides access to packet-switched networks, such as the Internet 110, to facilitate communication between the WTRUs 102a, 102b, 102c and IP capable devices. 102c ) may be connected to one or more of the gNBs 180a , 180b , 180c in the RAN 104 via an N3 interface. UPFs 184, 184b are responsible for routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering DL packets. to perform other functions, such as providing mobility anchoring, etc.

The CN 106 may facilitate communication with other networks. For example, the CN 106 may include or communicate with an IP gateway (eg, an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108 . The CN 106 also provides access to other networks 112, which may include other wired and/or wireless networks owned and/or operated by other service providers, to the WTRUs 102a, 102b, 102c. can be provided to In one embodiment, the WTRUs 102a, 102b, 102c connect to the UPFs 184a, 184a, via the N3 interface to the UPFs 184a, 184b and the N6 interface between the UPFs 184a, 184b and the DNs 185a, 185b. 184b) to the local DNs 185a, 185b.

1A-1D and 1A-1D , WTRU 102a-d, base station 114a-b, eNode-B 160a-c, MME 162, SGW 164, in light of the corresponding description of FIGS. , PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and/or any described herein One or more or all of the functions described herein with respect to one or more of the other device(s) of may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, emulation devices may be used to test other devices and/or to simulate network and/or WTRU functions.

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

The one or more emulation devices may perform one or more functions, including all functions, without being implemented/deployed as part of a wired and/or wireless communication network. For example, the emulation devices may be used in a test scenario in a test laboratory and/or in an undeployed (eg, test) wired and/or wireless communication network to implement testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and/or wireless communication via RF circuitry (eg, which may include one or more antennas) may be utilized by the emulation devices to transmit and/or receive data.

The IEEE has constructed the 48-bit MAC address space in such a way that half of the original address space is reserved for local use. When the universal/local (U/L) bit is set to 1, local use is configured. Different allocation approaches may be used within the four designated regions of this local MAC address space according to the Selective Structured Local Access Plan (SLAP). These four regions, referred to as SLAP quadrants, are the extended local identifier (ELI) quadrant; standard assigned identifier (SAI) quadrant; the administratively assigned identifier (AAI) quadrant; and quadrants reserved for future use.

Quadrant ELI MAC addresses may be assigned based on Company ID (CID) taking 24-bits, for unicast (M-bit = 0) and also for multicast (M-bit = 1). Leave the remaining 24-bits for the locally assigned address for each CID. The CID is assigned by an IEEE Registration Authority (RA).

Quadrant SAI MAC addresses are assigned based on the protocol specified in the IEEE 802 standard. For 48-bit MAC addresses, 44 bits are available. A number of protocols for allocating SAIs may be specified in IEEE standards. The coexistence of multiple protocols can be supported by limiting the subspace available for allocation by each protocol.

Quadrant AAI MAC addresses are assigned locally by the administrator. Multicast IPv6 packets use a destination address starting at 33:33, which falls within this space, and therefore a conflicting address must not be used to avoid conflicts with IPv6 multicast addresses. For 48-bit MAC addresses, 44 bits are available.

What is reserved for the future use quadrant defines an area to which MAC addresses can be assigned, either using new methods not yet defined, or by an administrator, similar to the assignments made in the AAI quadrant, for example.

2A is an exemplary structure of an IEEE 48-bit-MAC address structure. In this example, the four least significant bits (LSBs) are identified. LSB M 202 refers to an M-bit Individual/Group (I/G) indicator that indicates whether the MAC address is for a unicast WTRU or group of WTRUs. The LSB X-bit 204 indicates whether the MAC address is assigned locally. LSB Y 206 refers to SLAP Y-bits, and LSB Z 208 refers to SLAP Z-bits. The SLAP Y-bits and X-bits are detailed in table 220 shown in FIG. 2B .

2B is a table 220 schematically illustrating 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), when the Y-bit is set to 0 (240) and the Z-bit is set to 1 (248), the local identifier type is extended local (256) and the local identifier is ELI (264). am. For quadrant 11 (234), when 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 SAI 266 . For quadrant 00 (236), when the Y-bit is set to 0 (244) and the Z-bit is set to 0 (252), the local identifier type is management assignment 260 and the local identifier is AAI (268) . For quadrant 10 (238), when 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 .

The IEEE is working on mechanisms for assigning addresses in the Standard Assigned Identifier (SAI) quadrant, and in this regard, the Internet Engineering Task Force (IETF) has established the Dynamic Host Control Protocol version 6 (DHCPv6) to handle local MAC address assignments. ) are working on specifying new mechanisms to extend the behavior. In this way, MAC assignments can be handled on a dynamic basis. However, these standardization efforts do not provide a mechanism to support methods for selecting a SLAP quadrant for use in assignment of a MAC address to a requesting WTRU, which may be a terminal or a client unit. In embodiments, DHCPv6 protocols are extended to allow a DHCPv6 client or DHCPv6 relay to indicate to the server a preferred SLAP quadrant, such that the server can correspondingly assign a MAC address to a given client or relay. Two example applications are described in which the need to allocate local MAC addresses according to the preferred SLAP quadrants arises: (1) individual WTRUs and (2) many virtual machines by hypervisors or other virtualization technologies. Large virtualized environments, eg, data centers, managed by

Regarding the first application, most WTRUs deployed today are "burned" from MAC addresses, allocated from a universal address space using a 24-bit Organizationally Unique Identifier (OUI), allocated to IEEE 802 interface vendors. )" with pre-installed interfaces. Recently, however, the need to assign local MAC addresses to WTRUs (instead of universal) has arisen, particularly in Internet of Things (IoT) systems and privacy.

An IoT system may include many inexpensive, sometimes short-lived and disposable devices. For such devices, reuse of the MAC address would be ideal so as not to expand the MAC address space more than necessary. Examples of such devices may include sensors and actuators for health or home automation applications. In such systems, upon first booting, it is common for the IoT device to use a temporary MAC address to send initial DHCP packets to available DHCP servers. IoT devices typically request a single MAC address for each available network interface, eg, wired and wireless interfaces. Once the server assigns a MAC address, the device relinquishes its temporary MAC address used to send initial DHCP packets. This type of device is typically not a mobile or highly mobile device. In general, any type of SLAP quadrant will be good for assigning addresses, but the ELI/SAI quadrant may be used in some scenarios, such as where it is necessary for assigned addresses to belong to an IoT communication device vendor's assigned Company ID (CID). may be more suitable in

With respect to the privacy issue of the WTRU, the exposure of the MAC address allows for the exposure of the user's locations, thus making it relatively easy to track the user's movements. One of the mechanisms considered to alleviate this problem is the use of local random MAC addresses, which change each time a user connects to a different network. In this scenario, the devices are typically mobile. Here, the AAI quadrant may be the best SLAP quadrant for allocating addresses, since it is best suited for randomization of addresses and the addresses do not need to survive when changing networks.

3A is a diagram 300 of several Internet of Things (IoT) networks 302-306 interfacing with a Dynamic Host Configuration Protocol (DHCP) architecture. Each of the IoT networks 302-306 may include one or more IoT devices including WTRUs, appliances, door locks, bicycles, fitness sensors, and the like. IoT networks 302-304 include DHCP relays 308 , 310 for coupling to a DHCP server 312 . The IoT network 306 may not include a DHCP relay, and IoT devices in the IoT network 306 may directly reach the DHCP server 312 . A single ELI 314 , SAI 316 and AAI 318 may be used in this example.

As for the second application, virtualization may encourage the allocation of local MAC addresses. For example, in large-scale virtualization environments, thousands of virtual machines (VMs) are active. These VMs are typically managed by the hypervisor responsible for spawning and stopping the VMs as needed. The hypervisor is also typically responsible for allocating new MAC addresses to the VMs. When a DHCP solution is ready for this, the hypervisor acts as a DHCP client and requests available DHCP servers to allocate one or more MAC addresses in the address block. The hypervisor does not use only those addresses themselves, but uses them to create new VMs with appropriate MAC addresses. Each VM may be provided with a new MAC address when instantiated. For very large data center environments, partitioning of different network areas is typical. Each of the different network areas is configured to manage its own local address space. In this scenario, as shown in FIG. 3B , there are two elements comprising migratable functions and non-migratable functions.

3B is a diagram 330 of a large data center 332 interfacing with a DHCP architecture. The large-scale data center 332 may be comprised of a plurality of areas 334-340. Each of the regions may contain migrating VMs and non-migrating VMs. Each area 334-340 may include a DHCP relay 342-348 for relaying DHCP messages to and from the DHCP server 350 . A single ELI quadrant 352 and SAI quadrant 354 may be used. Alternatively, each region may be assigned an address from the AAI quadrant 356-362.

If a VM providing a given function needs to potentially be migrated to another area of the data center due to maintenance, resiliency, end-user mobility, etc., then it is a requirement for this VM to maintain its networking context in the new area. can, and this includes maintaining its MAC address(es). Thus, to satisfy this need, it may be appropriate to allocate addresses from the ELI/SAI SLAP quadrant, which may be centrally assigned by a DHCP server.

On the other hand, if a VM is known to be unlikely to migrate to another area of the data center, there may be no requirements associated with its MAC address. In this scenario, it is more efficient to assign a MAC address from the AAI SLAP quadrant, which need not be the same for all data centers. In an embodiment, each region may manage its own MAC addresses, without globally checking for duplicates.

Mechanisms for SLAP quadrant selection to determine, from terminals, which MAC address to use and when to change the assigned MAC address, are provided by terminals, e.g., WTRUs, or infrastructure, e.g., base stations or cellular cores. It may be determined based on context information and/or preferences indicated by the network server. As described herein, these mechanisms may be implemented within each of the aforementioned applications, including, for example, IoT applications, privacy sensitive implementation applications, and data center applications.

In the IoT architecture, IoT terminals can connect to a WLAN network using a burned-in temporary MAC address. This allows the terminals to gain connectivity and proper bootstrap. During this step, the terminal may obtain information and/or preferences to assist in determining which SLAP quadrant to use to construct a more permanent local MAC address than a temporary burn-in address. As shown in FIG. 4 , an IoT device may make a standalone decision or an infrastructure-assisted decision as to which SLAP quadrant to use to obtain a local MAC address.

4 is a diagram illustrating signaling for IoT quadrant selection in both standalone decision 400 and infrastructure-assisted decision 420 modes. When making the standalone decision 400 , the IoT device 402 may be configured to include, but is not limited to, a type of IoT deployment, eg, industrial, home, rural, etc.; mobility; whether the devices are managed or unmanaged; and/or contextual information including operation/battery life. For small deployments, such as home deployments, the IoT device 402 itself may decide to use the AAI quadrant. This determination may, in an embodiment, not include the use of DHCP by the terminal constructing a random address calculated by the terminal itself. Otherwise, DHCP signaling 406 may be used. For large deployments, such as industrial or rural deployments, where thousands of terminals may coexist, the IoT device 402 may decide to use ELI or SAI quadrants. If the IoT device 402 is mobile or mobile, it may prefer to select SAI or AAI quadrants to minimize address conflicts when moving to another network. If the IoT device 402 is known to remain stationary, the ELI quadrant may be the most appropriate to use. Depending on whether the IoT device 402 is managed during its lifetime or cannot be reconfigured, the quadrant selected may be different. For example, it can be managed, which means that network topology changes can occur during its lifetime, due to changes to the deployment, such as, for example, extensions involving additional terminals, which , can affect the preferred quadrant, for example to avoid potential collisions in the future. Depending on the expected lifetime of the terminal, a different quadrant may be desirable to minimize potential address conflicts in the future. These are examples of parameters that an IoT terminal may use to select a given SLAP quadrant. It may depend on other parameters as well. Since IoT terminals are typically resource constrained, simple decisions can be taken, for example, based on pre-configured preferences or pre-configured settings.

For the IoT scenario, it is further expected that the quadrant chosen in most cases will be ELI. In this case, the MAC address to be provided to the terminal is based on a Company ID (CID), which is typically preconfigured in the terminal as a burnt temporary address. However, in large IoT deployments, such as rural or industrial deployments, the address space from a single CID can be exhausted. In this case, the terminal may provide a list of preferred CIDs to be used by the DHCP server 404 to provide MAC addresses therefrom. Additional CIDs may belong to other vendors with which the IoT terminal manufacturer has business relationships or agreements, for example, subsidiaries of the IoT terminal vendor. When the quadrant selected by the terminal is ELI, the DHCP server 404 may assign addresses from the default CID, from any of the additional provided CIDs, or even from a different one. In all cases, the DHCP server 404 is checkable or can check from which CIDs the terminal can be assigned a local MAC address. This may be done, for example, by the DHCP server 404 with a list of allowed CIDs per IoT terminal. An exemplary procedure showing how an IoT terminal can select a quadrant and perform local MAC address configuration is shown in FIG. 5 .

When making the infrastructure-assisted decision 420, the IoT terminal 422 receives a hint/preference/request 426 from the infrastructure as to which SLAP quadrant to use to obtain the local MAC address. In an IoT scenario, this hint may be signaled 426 from the bootstrapping/configuration server 424 that the IoT terminal 422 uses to complete its configuration. The server 424 may also use parameters correlated to the deployment environment/context of the IoT terminal to perform quadrant selection, including: (1) the type of IoT deployment; (2) mobility; and/or (3) operation/battery life.

On the right side of FIG. 4 , the general operation of the infrastructure support decision 420 is shown. The IoT terminal 422 is in contact with a bootstrapping/configuration server 424 , which may be running on the cloud or running locally on which the IoT terminal 422 is deployed, and as part of the bootstrapping/configuration signaling 426, a DHCP server Receive the selected SLAP quadrant to be used later in DHCP signaling 430 with 428 .

5 is a decision flow diagram 500 for quadrant selection in an IoT terminal embodiment. In an embodiment, the bootstrapping IoT device 502 may determine whether it is a component of the large deployment 504 . If it determines that it is not a component of the large deployment (506), the IoT terminal may select (508) the AAI quadrant. The IoT device may be configured to select 510 a random address locally from the AAI quadrant. If configured to select a random address locally ( 512 ), the IoT may select a random address from the AAI quadrant ( 514 ). Conversely ( 516 ), the IoT device may perform DHCP signaling ( 518 ) indicating the AAI quadrant with a DHCP server or another server.

If the IoT device is part of a large deployment 520 , the IoT device may consider mobility 522 as a factor in performing quadrant selection. If the device is likely to be mobile ( 524 ), the IoT device may use the SAI quadrant 526 and may perform DHCP indicating the SAI ( 528 ).

If the IoT device is stationary and is expected not to be mobile ( 530 ), the IoT device may select ( 532 ) the ELI quadrant and determine whether a CID ( 534 ) should be included. If the IoT device has a CID to include ( 536 ), the IoT device may perform DHCP signaling indicating the ELI ( 538 ) and include the preferred CID. The IoT device may optionally include additional CIDs. If the IoT device determines that the CID is not used (550) (534), the IoT device may perform DHCP signaling indicating the AAI quadrant (552).

Assuming that the IoT device performs (538) DHCP signaling with the at least one indicated CID, the DHCP server may determine (540) whether addresses are available from the default CID. If the address from the default CID is available ( 542 ), the DHCP server may provide the local MAC address from the default CID ( 544 ). If addresses are not available (546), the DHCP server may provide (548) a local MAC address from an additional CID.

Privacy enhancement solutions for assigning local MAC addresses to WTRUs may define additional procedures. In these scenarios, a WTRU, such as a laptop or smartphone, uses its embedded MAC address to connect to the network. Due to privacy/security concerns, the terminal may wish to configure its local MAC address. A terminal may use different parameters and context information to determine which SLAP quadrant to use for local MAC address configuration, as well as when to perform an address change. In some embodiments, the change of address may be performed multiple times during the lifetime of the device. The context information may include, but is not limited to, the type of network to which the terminal is connected, for example, public, work, home, etc.; whether the network is trusted; whether the terminal is visiting the network for the first time; network geographic location; whether the terminal is mobile; an operating system (OS) network profile including security/trust related parameters; and/or triggers provided by applications running on the device with respect to location privacy. With respect to an OS network profile, most modern OSs maintain metadata associated with networks to which they are accessible or to which they can connect, for example, as the level of trust that a user or administrator assigns to a network. This information can be used to configure how the terminal behaves in terms of advertisements on the network itself, firewall settings, and the like. However, this information may also be available or used to determine whether to construct a local MAC address, from which SLAP quadrant, and how often to do so. With respect to application triggers, an application may provide a request to the OS to maximize location privacy, for example due to the nature of the application, which may mean that the OS forces the use or change of the local MAC address. have.

This information can be used by the terminal to select the SLAP quadrant. For example, if a terminal is moving around (e.g. while connected to a public network in an airport), it is likely to change access point multiple times, thus the chance of address conflicts using SAI or AAI quadrants. It is best to minimize them. If the terminal is not moving (eg at work) and is connected to a trusted network, it is probably best to choose the ELI quadrant. These are just some examples of how to use this information to select a quadrant. The information may also be used to trigger subsequent changes to the MAC address to improve location privacy. In addition, changing the SLAP quadrant used can also be used as an additional enhancement to make it more difficult to track a user's location.

In data center applications, the hypervisor may request that local MAC addresses be assigned to virtual machines. As in other embodiments, the hypervisor may select a preferred SLAP quadrant using information provided by a Cloud Management System (CMS) or Virtual Infrastructure Manager (VIM) running on top of the hypervisor. This information may include, but is not limited to, whether the VM is a migrating or non-migrating VM; and/or VM connection characteristics, eg, standalone, part of a pool, part of a service graph/chain. Whether a VM is migrateable affects the preference for the SLAP quadrant, as some quadrants are better suited to support migration in large data centers (eg ELI/SAI). VM connection characteristics, if known, may be used by the hypervisor to select the best SLAP quadrant.

With respect to any of the above WTRU or data center applications, various DHCPv6 extensions may be defined outlining the steps for allowing selection of a SLAP quadrant of a local MAC address according to the preference of a requesting DHCPv6 client. Such steps may be different depending on whether the SLAP quadrant is indicated by a DHCP client, eg a terminal/IoT device or by a DHCP relay.

6 shows the steps defined in the exemplary extension to permit address assignment when the preferred SLAP quadrant is indicated by a DHCP client. In step 1, link layer addresses (ie MAC addresses) are assigned to blocks. The smallest block is a single address. To request an assignment, the client sends a Solicit message 606 with the IA_LL option in the message. The IA_LL option must include the LLADDR option. To indicate the preferred SLAP quadrant, the IA_LL option includes a new quad IA-LL option containing the preferred quadrant. In step 2, the server, upon receiving the IA_LL option, may examine its content and provide an address or addresses for each LLADDR option according to its policy. The server sends back an advertisement message 608 with an IA_LL option that includes an LLADDR option specifying the addresses to be provided. If the server supports the new quad IA-LL option and manages a block of addresses belonging to the requested quadrant, the addresses provided must belong to the requested quadrant. If the server does not have addresses from the requested quadrant, the server MUST return an IA_LL option containing a status code option whose status is set to NoQuadAvail. In step 3, the client waits for available servers to send advertisement responses and selects a server. The client then sends a request message 610 containing the IA_LL container option with the LLADDR option copied from the advertisement message sent by the selected server. This includes the preferred SLAP quadrant in the new quad IA-LL-option. In step 4, upon receipt of the request message 610 with the IA_LL container option, the server assigns the requested addresses. The server may change the allocation at this time. It then generates a Reply message 612 and sends it back to the client. Upon receiving the reply message 612, the client may parse the IA_LL container option 614 and start using all provided addresses. Note that a client that includes a Rapid Commit option in its request may receive a reply in response to the request and skip the above advertisement and request steps (according to standard DHCPv6 procedures). In step 5, when the assigned addresses are about to expire (616), the client sends a Renew message (618). In step 6, the server responds with a reply message 620 containing an LLADDR option with an extended lifetime.

7 shows the steps defined in the exemplary extension to permit address assignment when the preferred SLAP quadrant is indicated by a DHCP relay. This is useful when the DHCP server is running over a large infrastructure partitioned in different network areas, where each area may have different requirements. An example of this would be a deployment where IoT and regular WiFi-capable end-user terminals coexist, but are split into two different WiFi networks, each managed by a different DHCPv6 repeater. In step 1, link layer addresses (ie MAC addresses) are assigned to blocks. The smallest block is a single address. To request an assignment, the client sends a request message 708 with the IA_LL option in the message. The IA_LL option must include the LLADDR option. In step 2, the DHCP relay receives the request message and encapsulates it in a relay-forw message 710 . The relay includes a preferred quadrant for the relay agent remote-ID option, based on local knowledge and policies. The repeater requests which quadrant based on local configuration (eg, the network being served contains only IoT devices and thus requires ELI/SAI) or other means such as based on parsing the request message from the client. know what to do In step 3, the server, upon receiving the forwarded request message containing the IA_LL option, may examine its content and provide an address or addresses for each LLADDR option according to its policy. The server sends back the advertisement message with the IA_LL option including the LLADDR option specifying the addresses to be provided. This message is sent to the repeater in a repeater-reply message 712 . If the server supports the semantics of the preferred quadrant included in the relay agent remote-ID option, and maintains a block of addresses belonging to the requested quadrant, the addresses provided must belong to the requested quadrant. In step 4, the relay sends the received advertisement message 714 to the client. In step 5, the client waits for available servers to send advertisement responses and selects a server. The client then sends a request message 716 containing the IA_LL container option with the LLADDR option copied from the advertisement message sent by the selected server. In step 6, the relay forwards the received request in a relay-forward message 718 . It adds a repeater agent remote-ID option with a preferred quadrant. In step 7, upon receipt of the forwarded request message with the IA_LL container option, the server assigns the requested address. The server may change the allocation at this time. It then generates a reply message and sends it back to the repeater in repeater-reply 720 . In step 8, upon receiving the reply message 722, the client may parse the IA_LL container option and begin using all provided addresses. In step 9, when the assigned addresses 724 are about to expire (726), the client sends an update message (728). In step 10, this message is forwarded by the repeater in a repeater-forward message 730. In step 11, the server responds with a reply message containing an LLADDR option with an extended lifetime. This message is sent in relay-reply message 732 . In step 12, the relay sends a reply message 734 back to the client.

Various new DHCPv6 options and values used to indicate one or more preferred quadrants are further disclosed herein.

8 provides an example format of a quad (IA-LL) option 800 along with a description of example fields. As discussed with reference to FIG. 4 , the quad (IA-LL) option may be used to specify preferences for selected quadrants within IA_LL. Options may be encapsulated in the IA_LL options field of the IA_LL options. In the illustrated example, the 16-bit OPTION_QUAD field 802 may be set to a value to be assigned by the Internet Assigned Numbers Authority (IANA). The 16-bit option-length field 804 may indicate the number of quadrant(s) and preference(s) included in the quad (IA-LL) option 800 . Fields Quad-1 806 and Preference-1 808 may refer to quadrant identifiers and preferences. The second quadrant and preference may be indicated by quadrant-2 (810) and preference-2 (812) fields. The 32 bits 814 may be reserved for future use, or may be used to indicate additional quadrant(s) and/or preference(s). In an embodiment, the quadrants may be listed in order of preference, and thus preference may not need to be explicitly indicated.

9 provides an exemplary format for additional CIDs (IA-LL) option 900 along with descriptions of the included fields. Additional CIDs option 900 may be used to send additional CIDs in addition to being used as the source address of the message in IA_LL (ie, burnt temporary). This option should be used when ELI is included as one of the preferred SLAP quadrants in the quad IA_LL option.

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

The relay agent remote-ID option may 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 displayed in the option's company number field. The remote-id field may be used to encode the preferred SLAP quadrant.

Although features and elements have been described above in specific combinations, one of ordinary skill in the art will recognize that each feature or element may be used alone or in any combination with other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over 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, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims (20)

A method performed by a wireless transmit/receive unit (WTRU), comprising:
receiving context information from the infrastructure equipment;
selecting a structured local address plan (SLAP) quadrant for medium access control (MAC) address assignment based on the context information; and
sending a message indicating the selected SLAP quadrant
A method comprising According to claim 1,
wherein the message is a Dynamic Host Control Protocol (DHCP) message. According to claim 1,
wherein the context information includes number of nodes in the network, type of network deployment, type of network, mobility configuration, type of device management, battery life, location or privacy configuration. According to claim 1,
wherein the infrastructure equipment is a bootstrapping server. According to claim 1,
wherein the selected SLAP quadrant is an Extended Local Identifier (ELI) quadrant, and the context information indicates limited mobility or no mobility. According to claim 1,
wherein the selected SLAP quadrant is a standard assigned identifier (SAI) quadrant, and the context information indicates mobility. According to claim 1,
wherein the selected SLAP quadrant is an Management Assigned Identifier (AAI) quadrant, and the context information indicates a large deployment. 3. The method of claim 2,
and receiving, from the DHCP server, a DHCP message comprising a MAC address, wherein the MAC address is in the selected SLAP quadrant. 3. The method of claim 2,
wherein the DHCP message passes through at least one DHCP version 6 (DHCPv6) relays. 8. The method of claim 7,
and randomly selecting a MAC address from the AAI quadrant. A wireless transmit/receive unit (WTRU) comprising:
a memory configured to store context information;
circuitry configured to select a structured local address plan (SLAP) quadrant for medium access control (MAC) address assignment based on the context information; and
A transmitter configured to send a message
wherein the message indicates the selected SLAP quadrant. 12. The method of claim 11,
wherein the message is a Dynamic Host Control Protocol (DHCP) message. 12. The method of claim 11,
wherein the context information includes number of nodes in the network, type of network deployment, type of network, mobility configuration, type of device management, battery life, location or privacy configuration. 12. The method of claim 11,
wherein the context information is received from a bootstrapping server. 12. The method of claim 11,
wherein the selected SLAP quadrant is an Extended Local Identifier (ELI) quadrant, and the context information indicates limited mobility or no mobility. 12. The method of claim 11,
wherein the selected SLAP quadrant is a standard assigned identifier (SAI) quadrant, and the context information indicates mobility. 12. The method of claim 11,
wherein the selected SLAP quadrant is an Management Assigned Identifier (AAI) quadrant, and the context information indicates a large deployment. 13. The method of claim 12,
and a receiver configured to receive, from the DHCP server, a DHCP message comprising a MAC address, wherein the MAC address is in the SLAP quadrant. 13. The method of claim 12,
wherein the DHCP message passes through at least one DHCP version 6 (DHCPv6) relay. 18. The method of claim 17,
and circuitry configured to randomly select a MAC address from the selected AAI quadrant.

Images