Multicast and unicast Medium Access Control (MAC) Address assignment protocol (MUMAAP)
阅读说明：本技术 多播和单播介质接入控制(mac)地址指派协议(mumaap) (Multicast and unicast Medium Access Control (MAC) Address assignment protocol (MUMAAP) ) 是由 安东尼奥·德拉奥利瓦 罗伯特·G·加兹达 于 2020-04-23 设计创作，主要内容包括：本文描述了用于多播和单播MAC地址指派协议(MUMAAP)的方法和装置。第一节点可以基于第二节点的单播MAC地址或与第二节点相关联的多播MAC地址向第二节点发送发现消息,该发现消息可以包括第一MAC地址或第一MAC地址范围。第一节点可以接收具有第二MAC地址范围的给予消息。如果第一节点从接收到的第二MAC地址范围中选择第二MAC地址,则第一节点可以传送指示第二MAC地址或第二MAC地址范围被分配给第一节点的请求消息。第一节点可以接收确认消息,该确认消息指示第二MAC地址或第二MAC地址范围被分配给第一节点。(Methods and apparatus for Multicast and Unicast MAC Address Assignment Protocol (MUMAAP) are described herein. The first node may send a discovery message to the second node based on a unicast MAC address of the second node or a multicast MAC address associated with the second node, the discovery message may include the first MAC address or the first range of MAC addresses. The first node may receive a grant message having a second MAC address range. If the first node selects a second MAC address from the received second range of MAC addresses, the first node may transmit a request message indicating that the second MAC address or the second range of MAC addresses is assigned to the first node. The first node may receive an acknowledgement message indicating that the second MAC address or the second MAC address range is assigned to the first node.)
1. A method for use in a first node, the method comprising:
transmitting a discovery message to a second node based on a unicast Media Access Control (MAC) address of the second node or a multicast MAC address associated with the second node, the discovery message comprising a first MAC address or a first MAC address range;
receiving a grant message from the second node, the grant message having a second range of MAC addresses assignable to the first node;
transmitting a request message to the second node indicating that the second MAC address or the second range of MAC addresses is allocated to the first node in case a second MAC address is selected from the second range of MAC addresses;
receiving an acknowledgement message from the second node indicating that the second MAC address or the second MAC address range is assigned to the first node.
2. The method of claim 1, further comprising:
determining the first MAC address or the first MAC address range based on a previous MAC address assignment.
3. The method of claim 1, wherein the second MAC address is a unicast MAC address to be assigned to the first node or a multicast MAC address to be assigned to the first node.
4. The method of claim 1, wherein the second MAC address range comprises a unicast MAC address range or a multicast MAC address range.
5. The method of claim 1, wherein the discovery message further comprises a plurality of control word bits, a status field, an identification of the first node, and a MAC address count.
6. The method of claim 1, further comprising:
upon transmitting the discovery message to the second node, starting a timer associated with the grant message and incrementing a counter indicating a number of discovery messages transmitted; and
re-transmitting the discovery message to the second node based on the unicast MAC address associated with the second node or the multicast address associated with the second node if the timer expires and the counter does not exceed a predetermined count number.
7. The method of claim 1, wherein the second range of MAC addresses is determined based on at least one of a pool of MAC addresses associated with the second node, the first MAC address, or the first range of MAC addresses.
8. The method of claim 1, wherein the grant message further comprises a plurality of control word bits, a status field, a network identification, an identification of the second node, and a lifetime.
9. The method of claim 1, wherein the second MAC address assigned to the first node is the same as the first MAC address or the second MAC address assigned to the first node is within the first MAC address range.
10. The method of claim 1, wherein a source address of the discovery message is a random MAC address or a global MAC address.
11. The method of claim 1, wherein the first node is a client with or without a preconfigured initial MAC address and the second node is a server, wherein the preconfigured initial MAC address is a local address or a global address.
12. The method of claim 1, wherein each of the discover, give, request, and confirm messages is encapsulated in a frame with an indicator indicating that a protocol type is audio/video transport protocol (AVTP) with a subtype indicating IEEE802.1 CQ.
13. A first node, the first node comprising:
a transmitter configured to transmit a discovery message to a second node based on a unicast Media Access Control (MAC) address of the second node or a multicast MAC address associated with the second node, the discovery message comprising a first MAC address or a first MAC address range;
a receiver configured to receive a grant message from the second node, the grant message having a second range of MAC addresses assignable to the first node;
the transmitter is further configured to transmit a request message to the second node indicating that the second MAC address or the second range of MAC addresses is allocated to the first node, if a second MAC address is selected from the second range of MAC addresses;
the receiver is further configured to receive an acknowledgement message from the second node indicating that the second MAC address or the second range of MAC addresses is assigned to the first node.
14. The first node of claim 13, further comprising:
a processor configured to determine the first MAC address or the first MAC address range based on a previous MAC address assignment.
15. The first node of claim 14, wherein the processor is further configured to, upon transmission of the discovery message to the second node, start a timer associated with the grant message and increment a counter indicating a number of discovery messages transmitted, and wherein the transmitter is further configured to, if the timer expires and the counter does not exceed a predetermined count number, retransmit the discovery message to the second node based on the unicast MAC address of the second node or the multicast address associated with the second node.
16. The first node of claim 13, wherein the second MAC address is a unicast MAC address to be assigned to the first node or a multicast MAC address to be assigned to the first node.
17. The first node of claim 13, wherein the second MAC address range comprises a unicast MAC address range or a multicast address range.
18. The first node of claim 13, wherein the second MAC address assigned to the first node is the same as the first MAC address or the second MAC address assigned to the first node is within the first MAC address range.
19. The first node of claim 13, wherein the first node is a client with or without a preconfigured initial MAC address and the second node is a server, wherein the preconfigured initial MAC address is a local address or a global address.
20. A first node, the first node comprising:
a transmitter configured to transmit a discovery message to a second node requesting a Media Access Control (MAC) address to be assigned to a first node based on a unicast MAC address associated with the second node or a multicast MAC address associated with the second node;
a receiver configured to receive a grant message from the second node, the grant message having a range of MAC addresses that can be assigned to the first node;
the transmitter is configured to, in the event that the MAC address is selected from the range of MAC addresses, send a request message to the second node indicating that the MAC address or the range of MAC addresses is allocated to the first node; and
the receiver is configured to receive an acknowledgement message from the second node confirming that the MAC address or the range of MAC addresses is assigned to the first node.
Background
An IEEE802.1CQ is a standard that specifies protocols, procedures, and management objects for the locally unique assignment of 48-bit and 64-bit addresses in an IEEE802 network. Specifically, IEEE802.1CQ is operating on a layer 2 protocol to assign unicast and multicast MAC addresses locally to end stations in a Structured Local Address Plan (SLAP) defined in IEEE802c over all IEEE802 access technologies (e.g., IEEE802.11, IEEE802.3, etc.). However, current layer 2 protocols, such as the IEEE1722MAC address acquisition protocol, do not support the allocation of MAC addresses to end stations regardless of any prior configuration or prior allocation of MAC addresses. Therefore, a protocol for allocation that does not require previously configured or allocated unicast and multicast MAC addresses is needed to meet the requirements of IEEE802.1 CQ.
Disclosure of Invention
Methods and apparatus for Multicast and Unicast MAC Address Assignment Protocol (MUMAAP) are described herein. For example, a first node in a wired or wireless network may transmit a discovery message to a second node based on a unicast MAC address of the second node or a multicast MAC address associated with the second node, which may or may not include the first MAC address or the first MAC address range. If the discovery message includes a first MAC address or a first MAC address range, the first MAC address or first MAC address range may be determined based on a previous MAC address or address range assigned to the first node using the MUMAAP. The first node may then receive a grant message from the second node with a second range of MAC addresses that may be assigned to the first node. The second range of MAC addresses includes a unicast range of MAC addresses or a multicast range of addresses and may be determined by the second node based on at least one of a pool of MAC addresses associated with the second node, the first MAC address, or the first range of MAC addresses. If the first node selects a second MAC address from the received second range of MAC addresses, the first node may transmit a request message to the second node indicating that the second MAC address or the second range of MAC addresses is assigned to the first node. The selected second MAC address may be a unicast MAC address or a multicast MAC address, and may be the same as or within the first MAC address range. The first node may then receive an acknowledgement message from the second node indicating that the second MAC address or the second range of MAC addresses is assigned to the first node. The first node may be a client with or without a pre-configured initial MAC address and the second node may be a server.
Drawings
The invention may be understood in more detail from the following description, given by way of example in conjunction with the accompanying drawings, in which like reference numerals identify like elements, and in which:
FIG. 1A is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented;
figure 1B is a system diagram illustrating an example wireless transmit/receive unit (WTRU) that may be used in the communication system shown in figure 1A, according to an embodiment;
fig. 1C is a system diagram illustrating an example Radio Access Network (RAN) and an example Core Network (CN) that may be used in the communication system shown in fig. 1A according to an embodiment;
fig. 1D is a system diagram illustrating another example RAN and another example CN that may be used in the communication system shown in fig. 1A, according to an embodiment;
FIG. 2 is a system diagram illustrating an example communication system in which the Multicast and Unicast MAC Address Assignment Protocol (MUMAAP) is implemented; and
fig. 3 is a diagram illustrating an example MUMAAP process.
Detailed Description
FIG. 1A is a diagram illustrating an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to a plurality of wireless users. Communication system 100 may enable multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, communication system 100 may employ one or more channel access methods such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), zero-tail unique word discrete Fourier transform spread OFDM (ZT-UW-DFT-S-OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multi-carrier (FBMC), and so forth.
As shown in fig. 1A, the communication system 100 may include wireless 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, although it is understood that any number of WTRUs, base stations, networks, and/or network elements are contemplated by the disclosed embodiments. Each WTRU102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. For example, the WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a Station (STA) or a node) may be configured to transmit and/or receive wireless signals and may include User Equipment (UE), a mobile station, a fixed or mobile subscriber unit, a network node, a client, a subscription-based unit, a pager, a cellular telephone, a Personal Digital Assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an internet of things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical devices and applications (e.g., tele-surgery), industrial devices and applications (e.g., robots and/or other wireless devices operating in an industrial and/or automated processing chain environment), Consumer electronics devices, devices operating on commercial and/or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE, node, or client.
Communication system 100 may also include base station 114a and/or base station 114 b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN106, the internet 110, and/or the other networks 112. By way of example, the base stations 114a, 114B may be Base Transceiver Stations (BTSs), nodes B, e node bs (enbs), home node bs, home enodebs, next generation node bs such as g node bs (gnbs), New Radio (NR) node bs, site controllers, Access Points (APs), network nodes, servers, wireless routers, and so forth. Although the base stations 114a, 114b are each depicted as a single element, it will be understood that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements. The base stations 114a, 114b may be interchangeably referred to as nodes or servers.
The base station 114a may be part of the RAN104 and may also include other base stations and/or network elements (not shown), such as Base Station Controllers (BSCs), Radio Network Controllers (RNCs), relay nodes, and so forth. 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 licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for wireless services to a particular geographic area, which may be relatively fixed or may change over time. The cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one transceiver per sector of the cell. In an embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of a cell. For example, beamforming may be used to transmit and/or receive signals in desired spatial directions.
The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., Radio Frequency (RF), microwave, centimeter wave, micrometer wave, Infrared (IR), Ultraviolet (UV), visible light, etc.). Air interface 116 may be established using any suitable Radio Access Technology (RAT).
More specifically, as described above, 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, and the like. For example, the base station 114a in the RAN104 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) terrestrial radio access (UTRA), which may establish the air interface 116 using wideband cdma (wcdma). WCDMA may include communication protocols such as High Speed Packet Access (HSPA) and/or evolved HSPA (HSPA +). HSPA may include high speed Downlink (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) that may establish the air interface 116 using Long Term Evolution (LTE) and/or LTE-advanced (LTE-a) and/or LTE-Pro-advanced (LTE-a Pro).
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 use NR to establish the air interface 116.
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 together implement LTE radio access and NR radio access, e.g., using Dual Connectivity (DC) principles. Thus, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and/or transmissions sent to or from multiple types of base stations (e.g., enbs and gnbs).
In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE802.11 (i.e., Wireless Fidelity (WiFi), IEEE802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA20001X, CDMA2000EV-DO, interim standard 2000(IS-2000), interim standard 95(IS-95), interim standard 856(IS-856), Global System for Mobile communications (GSM), enhanced data rates for GSM evolution (EDGE), GSM EDGE (GERAN), and so forth.
The base station 114B in fig. 1A may be, for example, a wireless router, a home nodeb, a home enodeb, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in local areas such as business establishments, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for use by drones), roads, and so forth. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE802.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 IEEE802.15 to establish a Wireless Personal Area Network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE-a Pro, NR, etc.) to establish the pico cell or the femto cell. As shown in fig. 1A, the base station 114b may have a direct connection to the internet 110. Thus, the base station 114b may not need to access the internet 110 via the CN 106.
The RAN104 may communicate with the CN106, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102 d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN106 may provide call control, billing services, mobile location-based services, prepaid calling, internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication. Although not shown in fig. 1A, it should be understood that the RAN104 and/or the CN106 may communicate directly or indirectly with other RANs that employ the same RAT as the RAN104 or a different RAT. For example, in addition to connecting to the RAN104, which may utilize NR radio technology, the CN106 may communicate with another RAN (not shown) that employs GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technologies.
The CN106 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN108, the internet 110, and/or other networks 112. The PSTN108 may include a circuit-switched telephone network that provides Plain Old Telephone Service (POTS). The internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and/or the Internet Protocol (IP) in the TCP/IP internet protocol suite. The network 112 may include wired and/or wireless communication networks owned and/or operated by other service providers. For example, the network 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN104 or a different RAT.
Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers to communicate with different wireless networks over different wireless links). For example, the WTRU102c shown in figure 1A may be configured to communicate with a base station 114a, which may employ a cellular-based radio technology, and with a base station 114b, which may employ an IEEE802 radio technology.
Figure 1B is a system diagram illustrating an example WTRU 102. As shown in fig. 1B, the WTRU102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a Global Positioning System (GPS) chipset 136, and/or other peripherals 138, among others. It will be appreciated that the WTRU102 may include any subcombination of the foregoing elements while remaining consistent with an embodiment.
The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a Digital Signal Processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), any other type of Integrated Circuit (IC), a state machine, or the like. The processor 118 may perform signal decoding, data processing, power control, input/output processing, and/or any other functions that enable the WTRU102 to operate in a wireless environment. The processor 118 may be coupled to a transceiver 120, and the transceiver 120 may be coupled to a transmit/receive element 122. Although fig. 1B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.
Transmit/receive element 122 may be configured to transmit signals to and receive signals from a base station (e.g., base station 114a) over 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, 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 and optical signals. It should be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.
Although transmit/receive element 122 is depicted in fig. 1B as a single element, WTRU102 may include any number of transmit/receive elements 122. More specifically, the WTRU102 may employ MIMO technology. Thus, in one embodiment, the WTRU102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.
Transceiver 120 may be configured to modulate signals to be transmitted by transmit/receive element 122 and demodulate signals received by transmit/receive element 122. As described above, the WTRU102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU102 to communicate via multiple RATs, such as NR and IEEE 802.11.
The processor 118 of the WTRU102 may be connected to and may receive user input data from a speaker/microphone 124, a keypad 126, and/or a display/touchpad 128, such as a Liquid Crystal Display (LCD) display unit or an Organic Light Emitting Diode (OLED) display unit. The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. Additionally, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may include Random Access Memory (RAM), Read Only Memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a Subscriber Identity Module (SIM) card, a memory stick, a Secure Digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from and store data in memory that is not physically located on the WTRU102, such as on a server or home computer (not shown).
The processor 118 may receive power from the power source 134 and may be configured to distribute and/or control power to other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel cadmium, nickel zinc, 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, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, information from the GPS chipset 136, the WTRU102 may receive location information over the air interface 116 from a base station (e.g., base stations 114a, 114b) and/or determine its location based on the timing of signals received from two or more neighboring base stations. It should be appreciated that the WTRU102 may acquire location information by any suitable location determination method while remaining consistent with an embodiment.
The processor 118 may also be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality, and/or wired or wireless connectivity. For example, peripheral device 138 may be packagedIncluding accelerometers, electronic compasses, satellite transceivers, digital cameras (for photo and/or video), Universal Serial Bus (USB) ports, vibrating devices, television transceivers, hands-free headsets,A module, a Frequency Modulation (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, a virtual reality and/or augmented reality (VR/AR) device, an activity tracker, and/or the like. Peripheral device 138 may include one or more sensors. The sensor may be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, a humidity sensor, and the like.
The WTRU102 may include a full-duplex radio for which transmission and reception of some or all signals (e.g., signals associated with particular subframes for both UL (e.g., for transmission) and DL (e.g., for reception)) may be concurrent and/or simultaneous.
Figure 1C is a system diagram illustrating the RAN104 and the CN106 according to an embodiment. As described above, the RAN104 may employ E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN104 may also communicate with the CN 106.
The RAN104 may include enodebs 160a, 160B, 160c, although it should be appreciated that the RAN104 may include any number of enodebs while remaining consistent with an embodiment. The enode bs 160a, 160B, 160c may each include one or more transceivers to communicate with the WTRUs 102a, 102B, 102c over the air interface 116. In one embodiment, the enode bs 160a, 160B, 160c may implement MIMO technology. Thus, for example, the enodeb 160a may use multiple antennas to transmit and/or receive wireless signals to and from the WTRU102 a.
each of the enode bs 160a, 160B, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and/or DL, and the like. As shown in FIG. 1C, the eNode Bs 160a, 160B, 160C may communicate with each other via an X2 interface.
The CN106 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. While the foregoing elements are depicted as part of the CN106, it will be understood that any of these elements may be owned and/or operated by an entity other than the CN operator.
The MME162 may be connected to each enodeb 162a, 162B, 162c in the RAN104 via an S1 interface and may serve as a control node. For example, the MME162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME162 may provide a control plane function for switching between the RAN104 and other RANs (not shown) that employ other radio technologies (e.g., GSM and/or WCDMA).
The SGW164 may be connected to each of the enodebs 160a, 160B, 160c in the RAN104 via an S1 interface. The SGW164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102 c. The SGW164 may perform other functions such as anchoring the user plane during inter-enodeb handovers, triggering paging when DL data is available to the WTRUs 102a, 102B, 102c, managing and storing the context of the WTRUs 102a, 102B, 102c, and the like.
The SGW164 may be connected to a PGW166, which may provide WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the internet 110, to facilitate communications between WTRUs 102a, 102b, 102c and IP-enabled devices.
The CN106 may facilitate communications with other networks. For example, the CN106 may provide access for the WTRUs 102a, 102b, 102c to circuit-switched networks (e.g., the PSTN108) to facilitate communications between the WTRUs 102a, 102b, 102c and conventional landline communication devices. For example, the CN106 may include, or may communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN106 and the PSTN 108. In addition, the CN106 may provide the WTRUs 102a, 102b, 102c access to other networks 112, which other networks 112 may include other wired and/or wireless networks owned and/or operated by other service providers.
Although the WTRU is depicted in fig. 1A-1D as a wireless terminal, it is contemplated that in some representative embodiments, such a terminal may use (e.g., temporarily or permanently) a wired communication interface with a communication network.
In a representative embodiment, the other network 112 may be a WLAN.
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 or interface to a Distribution System (DS) or another type of wired/wireless network that carries traffic to and/or from the BSS. Traffic originating from STAs outside the BSS may arrive through the AP and may be delivered to the STAs. Traffic originating from the STA to a destination outside the BSS may be sent to the AP to be delivered to the respective destination. Traffic between STAs within a BSS may be transmitted through the AP, e.g., where a source STA may transmit traffic to the AP and the AP may deliver traffic to a destination STA. Traffic between STAs within a BSS may be considered and/or referred to as point-to-point traffic. Point-to-point traffic may be transmitted between a source STA and a destination STA (e.g., directly between the source STA and the destination STA) using Direct Link Setup (DLS). In some representative embodiments, DLS may use 802.11e DLS or 802.11z tunnel DLS (tdls). A WLAN using Independent Bss (IBSS) mode may not have an AP and STAs within or using IBSS (e.g., all STAs) may 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 similar mode of operation, the AP may transmit a beacon on a fixed channel, such as the primary channel. The primary channel may be a fixed width (e.g., a20 MHz wide bandwidth) or a dynamically set width. The primary channel may be an operating channel of the BSS and may be used by the STAs to establish a connection with the AP. In some representative embodiments, carrier sense multiple access with collision avoidance (CSMA/CA) may be implemented, for example, in 802.11 systems. For CSMA/CA, STAs (e.g., each STA) including the AP may sense the primary channel. A particular STA may back off (back off) if the primary channel is sensed/detected and/or determined to be busy by the particular STA. One STA (e.g., only one station) may transmit at any given time in a given BSS.
High Throughput (HT) STAs may communicate using a 40MHz wide channel, for example, by combining a primary 20MHz channel with an adjacent or non-adjacent 20MHz channel to form a 40MHz wide channel.
Very High Throughput (VHT) STAs may support channels that are 20MHz, 40MHz, 80MHz, and/or 160MHz wide. 40MHz and/or 80MHz channels may be formed by combining adjacent 20MHz channels. The 160MHz channel may be formed by combining 8 contiguous 20MHz channels or by combining two non-contiguous 80MHz channels, which may be referred to as an 80+80 configuration. For the 80+80 configuration, after channel encoding, the data may pass through a segment parser that may divide the data into two streams. Each stream may be separately subjected to Inverse Fast Fourier Transform (IFFT) processing and time domain processing. The streams may be mapped onto two 80MHz channels and the data may be transmitted by the transmitting STAs. At the receiver of the receiving STA, the operations of the above 80+80 configuration may be reversed and the combined data may be sent to the Medium Access Control (MAC).
The mode of operation below 1GHz is supported by 802.11af and 802.11 ah. The channel operating bandwidth and carrier is reduced in 802.11af and 802.11ah relative to the channel operating bandwidth and carrier used in 802.11n and 802.11 ac. 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in TV white space (TVWS) spectrum, while 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support meter type control/Machine Type Communication (MTC), such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, for example, limited capabilities including support for certain and/or limited bandwidth (e.g., support only). MTC devices may include a battery having a battery life above a threshold (e.g., to maintain a very long battery life).
WLAN systems that can support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include channels that can be designated as primary channels. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and/or limited by STAs among all STAs operating in the BSS, which supports a minimum bandwidth mode of operation. In the 802.11ah example, for STAs (e.g., MTC-type devices) that support (e.g., only support) the 1MHz mode, the primary channel may be 1MHz wide, even though the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and/or other channel bandwidth operating modes. Carrier sensing and/or Network Allocation Vector (NAV) setting may depend on the state of the primary channel. If the primary channel is busy, for example, because STAs (which support only a 1MHz mode of operation) are transmitting to the AP, all available bands may be considered busy even if most of the available bands remain idle.
In the united states, the available frequency band available for 802.11ah is from 902MHz to 928 MHz. In korea, the available frequency band is from 917.5MHz to 923.5 MHz. In japan, the available frequency band is from 916.5MHz to 927.5 MHz. The total bandwidth available for 802.11ah is 6MHz to 26MHz, depending on the country code.
Figure 1D is a system diagram illustrating the RAN104 and the CN106 according to an embodiment. As described above, the RAN104 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN104 may also communicate with the CN 106.
RAN104 may include gnbs 180a, 180b, 180c, but it should be understood that RAN104 may include any number of gnbs while remaining consistent with an embodiment. Each of the gnbs 180a, 180b, 180c includes one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gnbs 180a, 180b, 180c may implement MIMO technology. For example, the gnbs 180a, 108b may utilize beamforming to transmit signals to and/or receive signals from the gnbs 180a, 180b, 180 c. Thus, the gNB180a may use multiple antennas to transmit and/or receive wireless signals to and from the WTRU102a, for example. In an embodiment, the gnbs 180a, 180b, 180c may implement carrier aggregation techniques. For example, the gNB180a may transmit multiple component carriers (not shown) to the WTRU102 a. A subset of the component carriers may be on the unlicensed spectrum and the remaining component carriers may be on the licensed spectrum. In an embodiment, the gnbs 180a, 180b, 180c may implement coordinated multipoint (CoMP) techniques. For example, WTRU102a may receive coordinated transmissions from gNB180a and gNB180b (and/or gNB180 c).
WTRUs 102a, 102b, 102c may communicate with gNB180a, 180b, 180c using transmissions associated with scalable parameter configuration (numerology). For example, the OFDM symbol spacing and/or OFDM subcarrier spacing may vary for different transmissions, different cells, and/or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gnbs 180a, 180b, 180c using subframes or Transmission Time Intervals (TTIs) of various or scalable lengths (e.g., absolute times including different numbers of OFDM symbols and/or varying lengths).
The gnbs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in independent configurations and/or non-independent configurations. In a standalone configuration, WTRUs 102a, 102B, 102c may communicate with a gNB180a, 180B, 180c without also accessing other RANs (e.g., enodebs 160a, 160B, 160 c). In a standalone configuration, WTRUs 102a, 102b, 102c may utilize one or more of gNB180a, 180b, 180c as mobility anchors. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNB180a, 180b, 180c using signals in an unlicensed frequency band. In a non-standalone configuration, the WTRUs 102a, 102B, 102c may communicate/connect with the gNB180a, 180B, 180c, and may also communicate/connect with another RAN, such as the enodebs 160a, 160B, 160 c. For example, the WTRUs 102a, 102B, 102c may implement the DC principles to communicate substantially simultaneously with one or more gnbs 180a, 180B, 180c and one or more enodebs 160a, 160B, 160 c. 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 provide additional coverage and/or throughput for serving the WTRUs 102a, 102B, 102 c.
Each of the gnbs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and/or DL, support of network slicing, interworking between DC, NR and E-UTRA, routing of user plane data to User Plane Functions (UPFs) 184a, 184b, routing of control plane information to access and mobility management functions (AMFs) 182a, 182b, etc. As shown in fig. 1D, gnbs 180a, 180b, 180c may communicate with each other through an Xn interface.
The CN106 shown in fig. 1D may include at least one AMF182a, 182b, at least one UPF184a, 184b, at least one Session Management Function (SMF)183a, 183b, and possibly a Data Network (DN)185a, 185 b. While the foregoing elements are depicted as part of the CN106, it will be understood that any of these elements may be owned and/or operated by an entity other than the CN operator.
The AMFs 182a, 182b may be connected to one or more of the gnbs 180a, 180b, 180c in the RAN104 via an N2 interface and may serve as control nodes. For example, the AMFs 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling different Protocol Data Unit (PDU) sessions with different requirements), selecting a particular SMF183a, 183b, management of registration areas, termination of non-access stratum (NAS) signaling, mobility management, and so forth. The AMFs 182a, 182b may use network slices to customize the CN's support for the WTRUs 102a, 102b, 102c based on the type of service used by the WTRUs 102a, 102b, 102 c. For example, different network slices may be established for different use cases, such as services that rely on ultra-reliable low latency (URLLC) access, services that rely on enhanced large-scale mobile broadband (eMBB) access, services for MTC access, and so on. The AMFs 182A, 182b may provide control plane functionality for handover between the RAN104 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-a Pro, and/or non-3 GPP access technologies (e.g., WiFi).
The SMFs 183a, 183b may be connected to the AMFs 182a, 182b in the CN106 via an N11 interface. The SMFs 183a, 183b may also be connected to UPFs 184a, 184b in the CN106 via an N4 interface. The SMFs 183a, 183b may select and control the UPFs 184a, 184b and configure the routing of traffic through the UPFs 184a, 184 b. SMFs 183a, 183b may perform other functions such as managing and assigning UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing DL data notifications, etc. The PDU session type may be IP-based, non-IP-based, ethernet-based, etc.
The UPFs 184a, 184b may be connected to one or more of the gnbs 180a, 180b, 180c in the RAN104 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPFs 184, 184b may perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering DL packets, providing mobility anchoring, and the like.
The CN106 may facilitate communications with other networks. For example, the CN106 may include, or may communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN106 and the PSTN 108. In addition, the CN106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which other networks 112 may include other wired and/or wireless networks owned and/or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may connect to the local DNs 185a, 185b through UPFs 184a, 184b via an N3 interface to UPFs 184a, 184b and an N6 interface between UPFs 184a, 184b and DNs 185a, 185 b.
In view of the respective descriptions of fig. 1A-1D and 1A-1D, one or more or all of the functions described herein with respect to one or more of the following may be performed by one or more emulation devices (not shown): 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. The emulation device can be one or more devices configured to emulate one or more or all of the functionalities described herein. For example, the emulation device may be used to test other devices and/or simulate network and/or WTRU functions.
The simulated device may be designed to implement one or more tests on other devices in a laboratory environment and/or an operator network environment. For example, one or more emulation devices can perform one or more or all functions while being implemented and/or deployed, in whole or in part, as part of a wired and/or wireless communication network in order to test other devices within the communication 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 communication network. The simulated device may be directly coupled to another device for testing purposes and/or testing may be performed using over-the-air wireless communication.
The one or more emulation devices can perform one or more functions, including all functions, rather than being implemented/deployed as part of a wired and/or wireless communication network. For example, the simulation device may be used in a test scenario in a test laboratory and/or in a non-deployed (e.g., testing) wired and/or wireless communication network to enable testing of one or more components. The one or more simulation devices may be test equipment. The emulation device can transmit and/or receive data using direct RF coupling and/or wireless communication via RF circuitry (e.g., which can include one or more antennas).
As discussed herein, the protocol defined in IEEE802.1CQ for assigning multicast and unicast addresses may be specified in two types of operations: self-assignment, wherein a declaration-based (claiming) procedure is used, triggered by the station; and/or a server-based process in which a station contacts an entity that will be assigned an address in a particular pool. Both variants can be integrated in a common protocol.
The protocol may provide a common set of messages for self-declaration (self-closing) and server-based operations. This may be done to keep the protocol concise and reduce the total number of messages. The self-declaration protocol is referred to as the MAC address self-assignment protocol (MASAP), and the server-based version is referred to as the MAC address server-based assignment protocol (MASBAP).
The MASAP protocol is based on the IEEE1722MAC Address Acquisition Protocol (MAAP). IEEE1722 defines the MAC Address Acquisition Protocol (MAAP) which is used only to self-declare the multicast MAC address assigned to the address pool of IEEE1722 to use as a stream identifier in audio/video transmissions. MAAP is used only for self-declaration (e.g., where server-based assignment may not be supported). In addition, it does not include any support from the infrastructure or allocation of multicast MAC addresses. Assume that a unicast MAC address is assigned to a station performing MAAP. As a result, MAAP in an "as-is" scenario may not meet the needs of IEEE802.1 CQ.
MASAP may include support for an authorization response from a proxy serving the network (e.g., implementing the MUMAAP protocol), which may be able to capture and subscribe to all Discovery (DISCOVER) messages in the hold network and directly notify stations of the results of the self-declaration process.
The MASBAP protocol may be related to a simplified version of DHCP in a restrictive manner, where there are four messages for the initial assignment of addresses.
As discussed herein, a station may be an end node of a client side running the mumap protocol, while a server may refer to an infrastructure side of a server side running the mumap protocol, whether a proxy or server. The server may be located in a carrier network infrastructure component and/or may be located in customer premises equipment such as a gateway, access point, router, home network controller or set-top box.
The IEEE1722MAAP protocol and DHCP are incorporated herein by reference. The IEEE1722MAAP may cover the allocation of multicast addresses from a certain range. The protocol may operate from the perspective that the client has a unicast MAC address assigned or allocated to it, which may not be the case for 802.1 CQs. Also, IEEE1722 may be limited to wired environments. Thus, control bit based messages and behavior not covered by the IEEE1722MAAP may be required. As discussed herein, the MAAP framework may be extended to override operations with a proxy that may be able to mediate in the self-assignment process. Further, the techniques/embodiments/protocols discussed herein may replace the operation of a MAAP in an IEEE1722 network, as it may be used for the same function if needed, and may include options such as station ID and network ID that may address issues in MAAP deployment (e.g., address conflicts occur when a client belongs to multiple networks running the MAAP).
The MUMAAP may consider four message exchanges (i.e., discovery, grant, request, acknowledgement) similar to DHCP. All messages and actions are specific to the mumap protocol.
A protocol needs to be defined for assigning local unicast and multicast addresses to end stations, such as IEEE802.1CQ and the protocols defined in IEEE802 c. The protocol may need to support allocation, for example, by a self-assignment (i.e., self-declaration) mechanism and/or by a server-aware approach. The protocol may also need to support the assignment of local unicast and multicast addresses in the 4 quadrants defined in IEEE802 c.
As discussed herein, there is a need to design local and multicast MAC address assignment protocols with two operational variants: i) self-assignment and ii) server-based assignment. The protocol may need to be able to operate in multiple IEEE802 technologies supporting the infrastructure or in standalone mode. Further, protocol messages and state machines defining two modes of operation may be required. Furthermore, it may be desirable to support allocation of addresses to stations without any prior configuration/allocation/assignment, or to support allocation of addresses that takes into account stations and prior allocations.
As mentioned above, there may be two different protocol variants: i) MAC address self-assignment protocol (MASAP) and ii) MAC Address Server Based Assignment Protocol (MASBAP). MASAP corresponds to a self-assignment mode of operation, while MASBAP is used for server-based assignment. The two protocols may share the same message structure and options, although the behavior is defined differently for each message structure and option.
MASAP may use Discovery (DISCOVER), defense (DEFEND) and Announcement (ANNOUNCE) mechanisms, which rely on multicast support in the network. The client may select a unicast MAC address or MAC address range by randomly selecting a local unicast MAC address from a pre-established range defined in the IEEE802.1 CQ. Once a client selects a local unicast MAC address, it can probe (via a discovery message) the availability of that MAC address or range of MAC addresses (e.g., unicast or multicast) by, for example, sending a discovery message to a pre-established multicast address, with all MASAP clients or agents listening. After sending several discovery messages without receiving any reply, the client can understand that the address can be assigned to it. Thereafter, the station may initiate a defense and announcement phase in which a listen Discovery (DISCOVER) requests its allocated (i.e., self-assigned) address range and periodically announces its allocation within the network.
This basic operation may be similar to IEEE1722 in some respects, but with other sets of parameters and messages used, may be extended to account for the fact that some IEEE802 technologies (e.g., IEEE802.11) may not support reception of discovery messages for stations that are not yet associated (i.e., stations that are not yet assigned a MAC address that are undergoing a probe phase). Therefore, there is a need for client operation by enabling an agent (e.g., IEEE802.11 AP) in the network to keep track of the different assignments that the client requests through MASAP and directly answer station Discovery (DISCOVER). This not only allows operation of the protocol in technologies such as IEEE802.11, but may also improve the speed of allocation of MAC addresses, since the client can receive the acknowledgement immediately. MASAP may use a different MAC address range than MASBAP for assignment.
If a MASBAP server is in the network, the server may reply to the MASAP discovery message and assign a server-based MAC address. In this case, MASAP clients in the network may stop the processes related to the defense and announcement messages.
As described above, MASBAP may use four message exchanges (i.e., discovery, grant, request, acknowledgement) similar to DHCP to assign addresses to stations. As in MASBAP, a client may automatically generate an address to use as its source address for messages and initiate discovery, OFFER (OFFER), REQUEST (REQUEST), and Acknowledgement (ACK) message exchanges with the server. In response to the granting, the server or proxy grants the MAC address or MAC address range to the client. The client may receive several offers from separate servers. Server operation may be stateless, so the MAC address may be assigned only after the server receives the request message. After the client can use the assigned MAC address or range of MAC addresses in the network, the server can issue an ACK to the client.
MASAP may be used to comply with self-declared unicast and multicast addresses as defined by IEEE802c SLAP. The declaration of multicast addresses within the ranges defined by IEEE1722 tables b.9 and b.10 may be beyond the scope of this disclosure and may use the rules defined in IEEE1722 MAAP.
MASAP may utilize the following rules for message addressing: a source MAC address of a discovery message, which may be randomly selected from the ranges shown in table 1; a source MAC address of a defense and announcement message, which may use a MAC address previously assigned to a station or EUI-64/48 assigned to the station; a destination MAC address of a discovery message, the discovery message corresponding to the multicast MAC address specified in table 1; and/or a destination MAC address of a defense and announcement message corresponding to a source MAC address of the discovery message. The source and/or destination addresses may be encapsulated in an MSASP packet.
Table 1: address allocation
The MASAP protocol may be similar to the IEEE1722MAC Address Acquisition Protocol (MAAP), but the state machines may be different. MASAP operations as defined in this document may use similar state machines, events, constants, and timers as specified in IEEE 1722. However, in MASAP, MAAP may be extended to support authorization replies (e.g., reply to discovery requests) from proxies serving the network that are able to capture and subscribe to maintain all discovery messages in the network and directly notify stations of the results of the self-declaration process.
Table 2 shows the state machine of the MAAP protocol with additional state transitions (grey cells). Note that the table only represents state machine transitions for the station.
Table 2: MASAP state machine
aStart! Or port operability! Events may be initialized with an assigned address range, or MASAP may select an address range using the generate _ address function. If Start! Or port operability! Events are provided with address ranges, generate _ address may not be called, and the provided address ranges may be used. If an application (application) has previously obtained an address range and has access to persistent storage, the application may record the previous address range and attempt to reuse the saved address range.
bThe rProbe!can be generated only upon receipt of a discovery, defense, and announcement PDU that conflicts with an address range associated with the state machine! rDepend! And rAnnounce! An event. All discovery, defense, and announcement PDUs that do not collide with the address range associated with the state machine may be ignored.
cReceive the publication! After an event and the state machine has returned to the initial state, the address range associated with the state machine may be considered empty and the state machine may be corrupted.
dIf the compare _ MAC function returns TRUE (TRUE), no further processing or protocol actions may be taken and the protocol state may not change.
In an embodiment, as shown in Table 2, upon receipt of the Start! On event, the state machine running on the node may execute the generate _ address function in the initial state and call the reserved address! An event. Upon receipt of the reserved address! In the event, the state machine may execute the init map probe count function and start the probe timer. A node sends a discovery message (i.e., sProbe) to a neighbor node and enters the discovery state until a defensive message is received from the neighbor node or a probe timer expires. If a defensive message is received from a neighbor node, the state machine may stop the probe timer and invoke a restart! Event to return to the initial state. Upon receipt of a reboot! On event, the state machine may execute the generate _ address function and call the reserved Address! Events, as described above. If the Probe timer expires but no defense message is received, the state machine may invoke the Probe timer! Event and execute the start _ probe _ timer function and decrease the probe count. The node also sends a discovery message (i.e., a sProbe) to another node or neighboring node in the discovery state. If the snoop count is below zero, the state machine may invoke the snoop count! Event, stop probe timer, and start announcement timer. Upon receipt of the Probe count! Event, station may also send an announce message (i.e., sAnnounce) and enter a defensive state.
In another embodiment, a station may receive a proxy reply or give message in response to a discovery message sent to another station (e.g., an AP). Upon receiving a proxy reply or a give message, the state machine may invoke the rproxylanswer event with various state indications. For example, if the status indication in the agent reply or give message is equal to one (1), the state machine may stop the probe timer and the station may enter the defensive state. A status indication equal to one (1) may indicate that the MAC address that the station is attempting to assign is available. If the proxy replies or the status indication in the grant message equals two (2) or three (3), the state machine may stop the probe timer and will invoke restart! And the station may enter an initial state. A status indication equal to two (2) or three (3) may indicate that the MAC address that the station is attempting to assign is not available. This embodiment may be applied to IEEE802.11 networks.
Like MAAP, MASAP may operate on a point-to-point (P2P) basis, where stations agree on the status of a certain MAC address range among themselves. However, in the case where a proxy is available in the network, MASAP may bring an opportunity to reduce probe time, where the proxy replies to the discovery message with a grant message. The use of proxies may also allow the protocol to work over technologies where unassociated clients may not listen for announcement or defense messages. If an OFFER (OFFER) answers to the discovery message, the station may stop the defense state and omit transmission of the announcement message, since the broker may be responsible for subscribing to maintain the address state.
IEEE802.11 has a different set of characteristics, e.g., stations associated with an AP cannot listen to frames transmitted in a pre-association state. This may be the case for a discovery message, which may be transmitted to the AP through ANQP. In this case, the MASAP protocol may operate with agents capable of replying to discovery messages. This mode of operation may also omit the use of announcement messages because probing nodes are not associated and will not receive these messages, rendering them useless. It is also possible that the current behavior implemented with the grant message (e.g., AP indicating successful allocation) may also be implemented by using an IEEE802.11 reassociation frame that contains a code such as dened _ MAC _ ADDRESS _ POLICY _ view.
MASBAP can be used to assign unicast and multicast addresses following the IEEE802c SLAP definition, where a client discovers and requests an address from a MASBAP server(s) or proxy in the network.
MASBAP may utilize the following rules for message addressing: a source MAC address of a discovery message to be randomly selected from the range shown in table 3; the grant message may carry the MAC address to be used by the MASBAP client as the source MAC address; a source MAC address of a request message that is to use a MAC address previously assigned to the station, a MAC address assigned to the station by EUI-64/48, or a MAC address provided by the give message; a destination MAC address of a discovery message, the discovery message corresponding to the multicast address specified in table 1; and/or a destination MAC address of a grant and ACK message corresponding to a source MAC address of the discovery message or to a MAC address used as a source of the request message in case of ACK.
The MASBAP protocol may be defined by the following client state machine.
The client state machine may utilize the following events (events are denoted by | at the end): start! Wherein the state machine is initialized or re-initialized; issue! Where the! An event signals that the address range associated with this instance of the state machine is no longer in use; restart! Wherein the restart! An event signals that an error has been detected and the state machine is to be restarted; request Address! Wherein the request address! Events signal the initiation of MASBAP procedures; rOffer! Wherein rOffer! An event signaling that a give message has been received; rACK! Wherein rACK! An event signaling that an ACK message has been received; eTIMER _ expect! Wherein eTIMER _ expire! An event signals that the TIMER has expired; message count! Wherein the message counts! An event signaling that the number of MESSAGE MESSAGEs sent has reached its maximum value; and/or, port operability! Wherein port operability! An event signals that a port has entered an operational state.
The client state machine may utilize the following function functions: select _ address, which determines whether the previously known MAC address of the network is known and needs to be included in Discovery (DISCOVER); start _ TIMER, which starts a TIMER for a specific lease (lease); stop _ TIMER, which stops the TIMER for that particular lease; reset _ message _ count, set to 0 is a message count counter; increment _ MESSAGE _ count, which is incremented by 1 by the MESSAGE count counter; sDISCOVER, which sends discovery messages; sREQUEST, which sends the request message; valid _ requests, where the action checks that the partial satisfaction of the requested parameters of the discovery message is sufficient for the client operation, and it returns a 1 if the state machine can continue, or a 0 if it cannot; and/or Select _ offer, where if multiple give messages are received, the action selects one of them to continue the process, and the alternative mechanism may be related to the level of compliance of the requested parameters sent in Discovery (DISCOVER).
The client state machine may be based on the four states indicated in table 3.
Status of state
Description of the invention
Initial
Startup of state machine
Discovery
Sending discovery, wait response
Request for
Receiving grant, sending request, waiting for response
Restraint (Bound)
Select an address, receive ACK
Table 3: MASBAP client state
Table 4 shows the state machine of the MASBAP client.
Table 4: MASBAP client state machine
aIf valid _ requests returns 0, the grant timer will not stop and the client will continue to wait for other grant messages to arrive.
bThis event marks that the lifetime timer has expired, before which the client may send a request message to the server containing the station ID and MAC address range that it wants to re-bind.
With regard to MASBAP servers, its operation may be completely stateless. All information provided to the client must be treated as informational (i.e., not allocated) until an ACK is sent. The server may block the MAC address or range of MAC addresses assigned to a particular station only after the ACK transmission.
In an embodiment, as shown in Table 4, upon receipt of the Start! On event, a state machine running on the node may execute a select _ address function in an initial state and call the request address! An event. Upon receiving the request address! On event, the state machine may reset the discovery count and start the offserrcv timer. The node also sends a discovery message to the agent (or server) and enters the discovery state until either a give message is received from the agent or the offserrcv timer expires. If the OfferRcv timer expires but the grant message has been notified of receipt, the state machine may call eOfferRcv _ expire! An event. Upon receiving eoOfferRcv _ expire! On event, the state machine may increment the discovery count and start the offserrcv timer. The node also sends a discovery message to the agent in the discovery state. If a give message is received from the proxy, the state machine may call rOffer! An event. Upon receiving rOffer! In the event, the state machine selects to give, verify the request, stop the OfferRcv timer, start the ACKRcv timer, and reset the request count. The node may also send a request message to the proxy and enter the request state until an ACK message is received from the proxy or the ACKRcv timer expires.
If the ACKRcv timer expires without receiving an ACK message, the state machine may call eACKRcv _ expire! An event. Upon receiving the eACKRcv _ expire! On event, the state machine may increment the request count and start the ACKRcv timer. The node may also send a request message to the proxy in the request state. If an ACK message is received from the proxy, the state machine may call rACK!with various status indications! An event. For example, if the status indicator value is equal to 3 or 9, the state machine may stop the ACKRcv timer and return to the initial state. If the value of the status indication is equal to 5, 6, 7, or 11, the state machine may stop the ACKRcv timer, calling rOffer! Event and return to the request state. If the status indication value is equal to 4, the state machine may stop the ACKRcv timer, start the lifetime timer, and enter the constrained state. In the constrained state, a MAC address has been assigned to the node, and the node may stop the lifetime timer.
In an embodiment, for the protocols discussed herein, there may be a vulnerability from an address exhaustion attack where an attacker attempts to block all possible addresses available at the server. Typically, by one definition of the count field in the option, it may need to interact with the server 2^ 34. In the case where the range of MAC addresses available at the server does not cover all 48 bits of the address space, it is desirable to reduce the maximum number of addresses that can be requested in a single iteration with the server. In case the client requests more addresses than allowed, an ACK message with status 11 (parameter problem) has to be answered to the discovery or request message.
Fig. 2 is a system diagram illustrating an example communication system 200 implementing Multicast and Unicast MAC Address Assignment Protocol (MUMAAP). As shown in fig. 2, a communication system 200 for a MUMAAP may include nodes 202a, 202b, 202c, 202d, proxies (or servers) 210, 230, and network devices connecting the proxies (or servers) 220. The nodes 202a, 202b, 202c, 202d may be referred to as clients configured to transmit and/or receive wired or wireless signals. Examples of nodes 202a, 202b, 202c, 202d may include, but are not limited to, a Station (STA), a WTRU, a User Equipment (UE), a mobile station, a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, an internet of things (IoT) device, and a wearable device. The proxy 210, 230 may be referred to as a server configured to transmit and/or receive wired or wireless signals. Examples of the agents 210, 230 may include, but are not limited to, servers, base stations, switches, site controllers, Access Points (APs), hypervisors, and routers. The network device 220 may be any type of device capable of connecting the proxies 210, 230.
In one embodiment implementing MUMAAP, the node 202a may transmit a discovery message to the proxy 210 based on a unicast Media Access Control (MAC) address of the proxy 210 or a multicast MAC address associated with the proxy 210 or a multicast MAC address to which the proxy 210 is to listen. The discovery message may or may not include a MAC address or a range of MAC addresses (i.e., the first MAC address or the first range of MAC addresses). If a MAC address or MAC address range is included in the discovery message, the MAC address or MAC address range may be determined based on previous MAC address assignment information. The previous MAC address assignment information may include a previous MAC address or address range assigned to node 202a using MUMAAP. Alternatively or additionally, the MAC address or range of MAC addresses included in the discovery message may be determined randomly. Note that node 202a may or may not be pre-configured with an initial MAC address. For example, the network card of node 202a is manufactured without a MAC address on its hardware.
After transmitting the discovery message to the proxy 210, the node 202a may initialize a timer associated with the grant message that is expected to receive and increment a counter value, e.g., by one (1). The counter value may indicate a number of transmissions of the discovery message. The timer may be reset or initialized if a grant message is received from the agent 210. If the grant message is not received, the timer has not expired, and the counter value is less than the predetermined number, node 202a may retransmit the discovery message to agent 210 using the unicast MAC address of agent 210 or the multicast MAC address associated with agent 210 or the multicast MAC address that agent 210 is listening to.
After sending the discovery message to the proxy 210, the node 202a may receive a grant message from the proxy 210. The grant message may include a MAC address range (i.e., a second MAC address range) that may be assigned to node 202 a. The MAC address range may be determined by the proxy 210 based on a pool of available MAC addresses in the proxy 210. In determining the MAC address range, the proxy 210 may also consider the MAC address or MAC address range (in the discovery message) received from the node 202 a. The MAC address range determined by the proxy 210 may be a unicast MAC address range or a multicast MAC address range.
Upon receiving the grant message, node 202a may select a MAC address (i.e., a second MAC address) from the range of MAC addresses in the grant message. The selected MAC address may be a unicast MAC address or a multicast MAC address, which is assigned to node 202 a. Node 202a may select the (second) MAC address based on the (first) MAC address or the (first) MAC address range transmitted in the discovery message. For example, the selected (second) MAC address may be the same as the transmitted (first) MAC address, or within the transmitted (first) MAC address range.
Upon selecting the (second) MAC address, node 202a may transmit a request message to proxy 210 that includes the (second) MAC address or the (second) range of MAC addresses to indicate that the (second) MAC address or the (second) range of MAC addresses has been assigned to node 202 a. Node 202a may then receive an ACK message from proxy 210 indicating that a second MAC address or a second MAC address range is assigned to the first node.
In another embodiment implementing MUMAAP, node 202b may transmit a discovery message to node 202c based on a unicast Media Access Control (MAC) address of node 202c or a multicast MAC address associated with node 202c (e.g., a multicast MAC address to which node 202c is to listen). Node 202b may also start counters and timers. The discovery message may include a MAC address or range of MAC addresses and may be transmitted to the other nodes 202a, 202c, 202d or agents 210, 230 to verify whether the MAC address or range of MAC addresses is available (i.e., may be assigned to node 202 b). The MAC address or range of MAC addresses may be determined based on the MAC address or range of MAC addresses previously assigned to node 202 b. Alternatively or additionally, the MAC address or range of MAC addresses included in the discovery message may be determined randomly. Note that node 202 may or may not be pre-configured with an initial MAC address. For example, the network card of node 202b is manufactured without a MAC address on its hardware.
If a defensive message is received from node 202c while the timer is running, node 202b may stop the timer and generate a discovery message with a new MAC address or a new range of MAC addresses. The defensive message may indicate that the transmitted MAC address or range of MAC addresses is not available for allocation to node 202b (i.e., for use by node 202 c). Once the new MAC address or new range of MAC addresses is generated, node 202b may transmit a discovery message to node 202c based on the unicast MAC address of node 202c or the multicast MAC address associated with node 202c (or the multicast MAC address that node 202c is listening to). If the defensive message is not received, the timer expires and node 202b may reset the timer and decrement the counter. Once the counter is below zero, the node 202b transmits an announce message to the other nodes 202a, 202c, 202d indicating that a MAC address or range of MAC addresses has been allocated to the node 202 b.
In another embodiment, node 202d (e.g., a station) may transmit a discovery message to agent 230 (e.g., an AP) based on a unicast Media Access Control (MAC) address of agent 230 or a multicast MAC address associated with agent 230 (or a multicast MAC address to which agent 230 is to listen). The discovery message may include a MAC address or range of MAC addresses to verify whether a MAC address or range of MAC addresses is available for assignment to node 202 d. The MAC address or range of MAC addresses may be determined based on a MAC address or range of MAC addresses previously assigned to node 202 d. Alternatively or additionally, the MAC address or range of MAC addresses contained in the discovery message may be determined randomly. Note that node 202 may or may not pre-configure the initial MAC address. In response to the discovery message, node 202d may receive a grant message with various status indications from agent 230. In the case where the status indication is equal to one (1), node 202d may understand that the MAC address or MAC address range transmitted in the discovery message may be freely allocated. In the case where the status indication is equal to two (2) or three (3), node 202d may understand that the MAC address or MAC address range transmitted in the discovery message is not freely allocatable, or that an error has occurred between agent 230 and node 202 d.
Fig. 3 is a diagram illustrating an example MUMAAP process 300, which may be used in conjunction with any of the other embodiments described herein. In step 310, a first node in a wired or wireless network may transmit a discovery message to a second node using a unicast MAC address of the second node or a multicast MAC address associated with the second node or a multicast MAC address to which the second node is to listen. The discovery message may or may not include the first MAC address or the first range of MAC addresses. If the discovery message includes the first MAC address or the first MAC address range, the first MAC address or the first MAC address range may be determined based on previous MAC address assignment information. For example, the previous MAC address assignment information may be a range of MAC addresses assigned to the first node before the first node is turned on.
At step 320, the first node may receive a grant message with a second MAC address range from the second node. Determining, by the second node, the second range of MAC addresses based on a pool of MAC addresses available to the second node. The first node may be assigned a MAC address or range of MAC addresses based on the second range of MAC addresses. The second MAC address range comprises a unicast MAC address range or a multicast address range.
At step 330, the first node selects a second MAC address from the second range of MAC addresses. The selected second MAC address may be the same as the first MAC address or within the first MAC address range. The second MAC address may be a unicast MAC address or a multicast MAC address to be assigned to the first node.
At step 340, the first node may transmit a request message to the second node indicating that the second MAC address or the second MAC address range is allocated to the first node. In response to the request message, the first node may receive an acknowledgement message from the second node indicating that the second MAC address or the second range of MAC addresses is assigned to the first node in the network at step 350. The first node may be a client with or without a pre-configured initial MAC address and the second node may be a proxy or server. Each of the discovery, give, request, and acknowledgement messages are encapsulated in a frame having a protocol type indicating an audio/video transport protocol (AVTP) having a subtype indicating an IEEE802.1 CQ.
Embodiments of example message formats are described herein. The EtherType (EtherType) of all MUMAAP frames may be the EtherType given in table 5.
MUMAAP Ether type
F16(for example)
Table 5: MUMAAP Ether type
The message formats of the protocol(s) discussed herein may use a common control header, which may be included on all messages of the protocol. An example of a control header is in table 6.
Table 6: MUMAAP base header
The different fields of the control header may be as follows: subtype (8 bits), where a 1 octet subtype field is used to identify the format carried by MUMAAP and to distinguish MASAP from MASBAP protocols, as defined in table 7; version (3 bits), where there may be three bits indicating the version of the protocol (as disclosed herein, all bits may be set to 0 may represent the first version of the protocol); a message type (5 bits), which is a field containing one of the mumap message types as defined in table 8, and if the mumap message is received together with the reserved message type, the mumap frame may be ignored; a control word (16 bits) which may include the flags shown in Table 9; a cookie (16 bits), which is a field that must be incremented from the local counter, for each new transaction in the MUMAAP variant, where a frame generated as a result of receiving another frame can replicate the cookie of the originating frame, since the frame belongs to the same conversation; state (4 bits), where the state code may indicate the result of the action, which may be selected from table 10; and/or length (12 bits) which represents the message length in octets.
Table 7: MUMAAP subtype
Table 8: message type
Table 9: control word behavior
Value of
Description of the invention
0
Unused fields
1
Unused MAC ranges
2
Range of MAC used
3
Regenerating addresses in a given prefix and using MASAP
4
ACK-accepting assignment
5
Failure-to complete assignment
6
Fault-request quadrant unavailable
7
Failure-request scope not available
8
Administration of
9
Mandatory use of MASAP
10
Mandatory use of MASBAP
11
Problem of parameters
12
Providing administration-partial satisfaction
13-15
Retention
Table 10: status value
Depending on the actual message carried, the MASAP message may include different options transmitted by the protocol. Initially, options that can be transmitted can be defined and later it can be indicated for each message and the value to be carried which options can be added to the message. For all options, the type field is shown in table 11. Length (Length), the Length of an option is expressed in octets.
Type ID
Description of the invention
0
Station ID
1
48 bit MAC address (Range)
2
64 bit MAC address (Range)
3
Network ID
4
Specific MAC ranges
5
48-bit MAC Range in Conflict
6
64-bit MAC Range in Conflict
7
MAC address counting
8
Service life
Table 11: the option code value station ID option may provide up to 255 bytes to include the station's identifier as shown in table 12.
Table 12: station ID
In all cases where a station receives a message other than discovery, announcement, or defense with a station ID that does not correspond to its own, the packet must be dropped and processing stopped.
For a 48-bit MAC address (range), this option may provide a mechanism to transmit a 48-bit plus 16-bit MAC address indicating the amount of addresses requested. If it is desired to specify a single address rather than a range, the count must be set to 1. When the count is above one, then the count may indicate that multiple MAC addresses are assigned or requested, starting with the MAC address and including the next sequential address up to the count. See, for example, table 13.
TABLE 13 48 bit MAC Address
For a 64-bit MAC address (range), this option may provide a mechanism to transmit a 64-bit plus 16-bit MAC address indicating the amount of addresses requested. If it is desired to specify a single address rather than a range, the count may need to be set to 1, e.g., see Table 14.
Table 14: 64-bit MAC address
For a network ID, this option may provide up to 255 bytes to include an identifier of the network. See, for example, table 15.
Table 15: network ID
This option may be included for a particular MAC range so that the server requests the station to perform self-declaration in a particular address space. See, for example, table 16.
Table 16: specific MAC ranges
The byte subfield of the MAC address prefix length may be a 3-bit subfield. When the MAC address prefix length subfield is set to one of values 1-6, the value may indicate a MAC address prefix length byte field (e.g., in octets). In some cases, the MAC address prefix length byte subfield is not set to 0 or 7, as these values may be reserved.
The prefix trim subfield may be a 3-bit subfield and takes one of values 0-7, where the value indicates the number of bits truncated from the end of the MAC address prefix subfield to obtain the MAC address prefix. In other words, the MAC address prefix may be represented as the value of the MAC address prefix byte field after some of the most significant bits of the last octet are truncated, where the number of truncated bits is equal to the value of the prefix trim subfield.
The MAC address prefix byte field may be a 1 to 8 octet field, the length of which is signaled in the MAC address prefix length subfield of the policy flags field, which may contain all bytes of the MAC address prefix related to address self-assignment prior to truncation per prefix trim subfield.
For a 48-bit MAC range in conflict, this option may provide a mechanism to transmit a 48-bit plus 16-bit number of MAC addresses in conflict that indicates the amount of addresses in conflict. If it is desired to specify a single address rather than a range, the count may need to be set to 1. See, for example, table 17.
Table 17: 48 bit MAC range
For a 64-bit MAC range in a collision, this option may provide a mechanism to transmit a 64-bit plus 16-bit number of MAC addresses in a collision that indicates the amount of addresses in the collision. If it is desired to specify a single address rather than a range, the count may need to be set to 1. See, for example, table 18.
Table 18: 64 bit MAC range
For MAC address counting, this option may provide a mechanism for a station to request multiple addresses without providing a range of MAC addresses. See, for example, table 19.
Table 19: MAC address counting
If the MAC address count option is not present in the REQUEST (REQUEST), it may be assumed that the REQUEST is for a single MAC address.
For lifetime, this option may enable the server to set the lifetime of a particular MAC address lease. See, for example, table 20.
Table 20: service life
With respect to MASAP protocol messages, the self-declaration protocol may use the following message definitions. For Discovery (DISCOVER), this message may be used to prove a free MAC address range. The discovery message may include the following options in table 21.
Table 21: discovery
For a control word, a bit may need to become a 1 or 0 according to the following list: bits 0 through 2 may need to be changed to 1 depending on the quadrant to which the self-asserted address belongs; bit 4 may indicate whether the self-asserted address is 64 or 48 bits; bit 5 may indicate whether the address is unicast or multicast; bit 6 may be set to 0 indicating that the message originated at the station; and/or bit 7 may need to be set to 1 indicating that the message carries a MAC address.
For status, this field may need to be set to 0 in this message.
For the station ID, this may optionally include the ID of the station that sent the message.
For either a 48-bit MAC address (range) or a 64-bit MAC address (range), these may be the first addresses of the requested continuous address range. The count field may be the number of addresses requested. This field may be set to one (1) if only a single address is requested.
With respect to defenses (DEFEND), this message may be used to DEFEND against MAC address ranges that have been acquired. See, for example, table 22.
Table 22: defense
For a control word, the bit may need to go to 1 or 0, copying the value from the discovery message that triggered this message, where: bits 0 to 2 may need to become 1 depending on the quadrant to which the self-asserted address belongs; bit 4 may indicate whether the address it asserts is 64 or 48 bits; bit 5 may indicate whether the address is unicast or multicast; bit 6 may be set to 0 indicating that the message originated at the station; and/or bit 7 may need to be set to 1 indicating that the message carries a MAC address.
For status, this field may need to be set to 0 in this message.
For station IDs, this may be copied from the originating discovery message. If the discovery message that originated the message contains a station ID, the option may need to be copied from one of the discovery messages.
For 48-bit MAC addresses (range) or 64-bit MAC addresses (range), these may be copied from the original discovery message.
These may be set to the first address to conflict from the discovery requested address range for either the 48-bit MAC range in conflict or the 64-bit MAC range in conflict. In this case, the count may be set to the number of addresses that conflict with the range.
With respect to the announcement, the message may be used to announce the MAC address ranges that have been allocated. See, for example, table 23.
Table 23: announcement
For a control word, a bit may need to become a 1 or 0 according to the following list: bits 0 to 2 may need to become 1 depending on the quadrant to which the self-asserted address belongs; bit 4 may indicate whether the self-asserted address is 64 or 48 bits; bit 5 may indicate whether the address is unicast or multicast; bit 6 may be set to 0 indicating that the message originated at the station; and/or bit 7 may need to be set to 1 indicating that the message carries a MAC address.
For status, this field may need to be set to 0 in this message.
For the station ID, this may optionally include the ID of the station that sent the message.
For 48-bit MAC addresses (range) or 64-bit MAC addresses (range), these may be the first addresses of the continuous address range assigned to the station. The count field may be the number of addresses that have been allocated, starting with the address provided in the MAC address field. This field may be set to one (1) if only a single address is requested.
With respect to giving, this message may be used by the server/proxy to shorten the time required to probe the MAC address range. The idea behind this message is that in case the proxy subscribes to an address used in the holding network, it can quickly state the address being probed. The message may also be used to request that the station repeat the probe in a different range of MAC addresses. See, for example, table 24.
Table 24: administration of
For a control word, a bit may need to become a 1 or 0 according to the following list: bits 0 to 2 may need to become 1 depending on the quadrant to which the self-asserted address belongs; bit 4 may indicate whether the self-asserted address is 64 bits or 48 bits; bit 5 may indicate whether the address is unicast or multicast; bit 6 may be set to 1 indicating that the message originated at the server; and/or if a specific MAC range is provided, bit 7 may need to be set to 1, indicating that the message carries a MAC address range.
For status, the field may need to be set to 1, 2, 3, or 12 in the message. The meaning of each code is as follows: 1, indicating an unused MAC range and an address that can be directly allocated to a station; 2, indicates the MAC range in use, and the station must immediately select a different range; indicating that the station may generate a new address or address range within the range provided in the particular MAC range option and try the self-declaration again. If the state value is 3, the option "special MAC range" may be provided; and/or a value of 10, where MASAP is not supported in the network and MASBAP is needed.
If the state value is 2, it may be required that there be a 48-bit MAC address (range) or a 64-bit MAC address (range) in the message and a 48-bit MAC range in conflict or a 64-bit MAC range in conflict, which has the same meaning as in the defensive message.
For a network ID, this may optionally provide an indication of the network that the server is serving.
There may be one or more MASBAP protocol messages, where the server-based protocol defines the following messages.
Discovery (DISCOVER) is a message that can be used to open a dialog with any proxy/server in the network. See, for example, table 25.
Table 25: discovery
For a control word, a bit may need to become a 1 or 0 according to the following list: bits 0 to 2 may need to become 1 depending on the quadrant of the address being requested; bit 4 may indicate whether the requested address is 64 or 48 bits; bit 5 may indicate whether the requested address is unicast or multicast; bit 6 may be set to 0 indicating that the message originated at the station; and/or bit 7 may need to be set to either a 1 or 0 depending on whether the message carries a particular MAC range or 48/64MAC address (range).
For status, this field may need to be set to 0 in this message.
For the station ID, this may optionally contain the ID of the station that sent the message. The station ID may be mandatory if the message contains a 48-bit MAC address (range) or a 64-bit MAC address (range).
A particular MAC range may be used to provide the server with the range of MAC addresses being requested. The server may attempt to assign MAC addresses that fall within the range provided in this option.
For a 48-bit MAC address (range) or a 64-bit MAC address (range), this may be used to provide a MAC address or range of MAC addresses that have been previously assigned to the station. The server may attempt to assign the same MAC address or range to the stations. This field may be one (1) if only a single address is requested.
The MAC address count may be used to request address ranges without defining the range to which the MAC address belongs. This option may not be added if a 48-bit MAC address (range) or a 64-bit MAC address (range) is provided. If either of the two options is not provided, the server may assume that a single MAC address is requested.
Regarding grants, upon receiving the discovery message, the server may send grants for possible MAC address assignments to the client. Note that the allocation may take into account different cues provided by the stations. For example, see
Table 26.
Table 26: administration of
For a control word, a bit may need to become a 1 or 0 according to the following list: bits 0 to 2 may need to become 1 depending on the quadrant of the address being allocated; bit 4 may indicate whether the assigned address is 64 or 48 bits; bit 5 may indicate whether the assigned address is unicast or multicast; bit 6 may be set to 1 indicating that the message originated at the server; and/or bit 7 may need to be set to 1 indicating that the message carries 48/64 a MAC address (range).
The status field may need to be set to 8, indicating an ongoing process, or to 12, indicating a partial implementation of the constraints sent in Discovery (DISCOVER).
The network ID may optionally contain an ID of the network to which the agent sending the message belongs.
The station ID may optionally duplicate the station ID from the discovery message.
The lifetime may indicate the lifetime of the lease. It may be desirable to provide a service life option.
For 48-bit MAC addresses (ranges) or 64-bit MAC addresses (ranges), these may be used to provide a station with a MAC address or MAC address range. Such an option may need to be provided in this message.
With respect to the request message, upon receipt of the grant message, the station may confirm that the address (es) are assigned to the server by the message. The server may not consider the assigned address before receiving the message. See, for example, table 27.
Table 27: request for
For a control word, these bits may need to become 1 or 0 according to the following list: bits 0 to 2 may need to become 1 depending on the quadrant of the address being allocated; bit 4 may indicate whether the assigned address is 64 or 48 bits; bit 5 may indicate whether the assigned address is unicast or multicast; bit 6 may be set to 0 indicating that the message originated at the station; and/or bit 7 may need to be set to 1 indicating that the message carries 48/64 a MAC address (range).
The status field may need to be set to 0.
The network ID may optionally be duplicated in the grant message.
The station ID may optionally include the ID of the station.
The lifetime may indicate the lifetime of a lease copied from a given message.
For 48-bit MAC addresses (range) or 64-bit MAC addresses (range), these may be copied from the grant message.
With regard to the ACK message, the message may be used for stations to acknowledge assignment of addresses. In some cases, this may be sent as a reply to a REQUEST (REQUEST) to shut down the assignment process, although it may also be used by the server to notify the station of any errors, with which to reply to the discovery message. See, for example, table 28.
Table 28: ACK
The control word bit may need to become either 1 or 0 according to the following list: bits 0 to 2 may need to become 1 depending on the quadrant of the address being allocated; bit 4 may indicate whether the assigned address is 64 or 48 bits; bit 5 may indicate whether the assigned address is unicast or multicast; bit 6 may be set to 0 indicating that the message originated at the station; and/or bit 7 may need to be set to 1 indicating that the message carries 48/64 a MAC address (range).
The status field may take on a number of values, for example: 3, which may indicate that MASBAP is not available and that the station should generate a MAC address or range within the range defined in the specific MAC range option and use MASAP; 4, which may indicate that the allocation completed successfully; 5 to 7 which may indicate a failure while assigning addresses in view of hints provided by the stations; 9, which may indicate that MASBAP is not supported and MASAP is used; and/or 11, where there may be a mismatch in parameters between packets sent by the server and packets sent by the station. In case the state value is 3, then it may be necessary to provide an option specific MAC range.
The network ID may optionally include an ID of the network served by the proxy.
The station ID may optionally include the ID of the station. This option may need to be included if the station ID is provided in the request message.
The specific MAC range may include a range for MASAP. This option may need to appear in the status code being 3.
The ACK may be used as a reply to the discovery and request. The station may not consider the allocation complete until the ACK message is received.
Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with 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 a wired or wireless connection) 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.
- 上一篇：一种医用注射器针头装配设备
- 下一篇：激光雷达的配置方法、设备及存储介质