Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
  • H04L69/22—Parsing or analysis of headers
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L12/00—Data switching networks
  • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
  • H04L12/46—Interconnection of networks
  • H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
  • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
  • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
  • H04L69/321—Interlayer communication protocols or service data unit [SDU] definitions; Interfaces between layers
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W84/00—Network topologies
  • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
  • H04W84/10—Small scale networks; Flat hierarchical networks
  • H04W84/12—WLAN [Wireless Local Area Networks]

Definitions

• the example embodiments relate generally to wireless networks, and specifically packet discrimination in Wi-Fi networks.
• a Wi-Fi network may be formed by one or more access points (APs) that provide a wireless communication channel or link with a number of client devices or stations (STAs).
• APs access points
• STAs client devices or stations
• Each AP which may correspond to a Basic Service Set (BSS)
• BSS Basic Service Set
• beacon frames to enable any STAs within wireless range of the AP to establish and/or maintain a communication link with the Wi-Fi network.
• BSS Basic Service Set
• the AP and the STA may exchange data frames.
• Data frames transmitted over a Wi-Fi network may carry higher-level protocol data such as, for example, Internet Protocol (IP) data packets.
• IP Internet Protocol
• a data frame that encapsulates higher-level protocol data may include a Media Access Control (MAC) header, a Logical Link Control (LLC) header, a Subnetwork Access Protocol (SNAP) header, and a frame body.
• the frame body may contain an encapsulated data packet of a given Ethertype.
• the LLC header and the SNAP header which may be collectively referred to as the LLC/SNAP header, may indicate the Ethertype of the
• LLC Packet Discrimination is the default format of MAC service data units (MSDUs), a number of which may be contained in a MAC protocol data unit (MPDU).
• MSDUs MAC service data units
• MPDU MAC protocol data unit
• PHY physical layer protocol data unit
• PPDU physical layer protocol data unit
• Apparatuses and methods may allow a wireless device to process an Ethertype data packet encapsulated in a frame based on whether the frame contains an Ethertype Packet Discrimination (EPD) indicator.
• a method for processing an Ethertype data packet encapsulated in a frame is disclosed. The method may include receiving the frame from a second wireless device over a wireless network; detecting a presence of an Ethertype Packet Discrimination (EPD) indicator in the received frame; and based on the presence of the EPD indicator in the received frame, identifying a protocol type of the Ethertype data packet according to an EPD operation.
• EPD Ethertype Packet Discrimination
• a first wireless device for processing an Ethertype data packet encapsulated in a frame may include one or more processors and a memory configured to store instructions. Execution of the instructions by the one or more processors may cause the first wireless device to receive the frame from a second wireless device over a wireless network; detect a presence of an Ethertype Packet Discrimination (EPD) indicator in the received frame; and based on the presence of the EPD indicator in the received frame, identify a protocol type of the Ethertype data packet according to an EPD operation.
• EPD Ethertype Packet Discrimination
• a non-transitory computer-readable storage medium may store instructions that, when executed by one or more processors of a first wireless device, may cause the first wireless device to process an Ethertype data packet encapsulated in a frame by performing operations including receiving the frame from a second wireless device over a wireless network; detecting a presence of an Ethertype Packet Discrimination (EPD) indicator in the received frame; and based on the presence of the EPD indicator in the received frame, identifying a protocol type of the Ethertype data packet according to an EPD operation.
• EPD Ethertype Packet Discrimination
• a first wireless device for processing an Ethertype data packet encapsulated in a frame may include means for receiving the frame from a second wireless device over a wireless network; means for detecting a presence of an Ethertype Packet Discrimination (EPD) indicator in the received frame; and means for identifying a protocol type of the Ethertype data packet according to an EPD operation based on the presence of the EPD indicator in the received frame.
• EPD Ethertype Packet Discrimination
• FIG. 1 shows a block diagram of a wireless system within which the example embodiments may be implemented.
• FIG. 2 shows a block diagram of a wireless station (STA) in accordance with example embodiments.
• FIG. 3 shows a block diagram of an access point (AP) in accordance with example embodiments.
• FIG. 4 shows an example data frame that contains an encapsulated data packet of Ethertype xx-xx formatted using LLC Packet Discrimination (LPD).
• LPD LLC Packet Discrimination
• FIG. 5 shows an example data frame that contains an encapsulated data packet of Ethertype xx-xx formatted using Ethertype Packet Discrimination (EPD), in accordance with example embodiments.
• EPD Ethertype Packet Discrimination
• FIG. 6A shows one example MAC header within which the example
• FIG. 6B shows another example MAC header within which the example embodiments may be implemented.
• FIG. 6C shows another example MAC header within which the example embodiments may be implemented.
• FIG. 7 shows a table depicting frame type and sub-type values that may be included in the MAC headers of FIGS. 6A and 6B.
• FIG. 8A shows an example data frame that contains an encapsulated data packet of Ethertype xx-xx formatted using LPD, in accordance with example embodiments.
• FIG. 8B shows an example data frame that contains an encapsulated data packet of Ethertype xx-xx formatted using EPD, in accordance with example embodiments.
• FIG. 9 shows an illustrative flow chart depicting an example operation for processing an Ethertype data packet encapsulated within a data frame in accordance with example embodiments.
• FIG. 10 shows another block diagram of several sample aspects of apparatuses configured to transmit a data frame to another wireless device as taught herein.
• Wi-Fi wireless local area network
• Wi-Fi can include communications governed by the IEEE 802.1 1 family of standards, Bluetooth, HiperLAN (a set of wireless standards, comparable to the IEEE 802.1 1 standards, used primarily in Europe), and other technologies having relatively short radio propagation range.
• Wi-Fi wireless local area network
• the example embodiments are equally applicable to other WLAN systems including, for example, multiple WLANs, peer-to-peer (or Independent Basic Service Set) systems, Wi-Fi Direct systems, and/or Hotspots.
• the example embodiments may be applied to the exchange of any data unit, packet, and/or frame between wireless devices.
• the term "frame” may include any frame, packet, or data unit such as, for example, protocol data units (PDUs), MAC protocol data units (MPDUs), and physical layer convergence procedure protocol data units (PPDUs).
• PDUs protocol data units
• MPDUs MAC protocol data units
• PPDUs physical layer convergence procedure protocol data units
• A-MPDU may refer to aggregated MPDUs.
• circuit elements or software blocks may be shown as buses or as single signal lines.
• Each of the buses may alternatively be a single signal line, and each of the single signal lines may alternatively be buses, and a single line or bus might represent any one or more of a myriad of physical or logical mechanisms for communication between components.
• the example embodiments are not to be construed as limited to specific examples described herein but rather to include within their scopes all embodiments defined by the appended claims.
• Wi-Fi standards allow wireless devices to exchange data frames that encapsulate data packets of higher-level protocols (e.g., network-layer protocols such as IP packets and Ethernet packets) over a shared wireless medium associated with a Wi-Fi network.
• An access point may serve as a bridge between the shared wireless medium and a wired medium (e.g., corresponding to a backhaul connection or network).
• a data frame bound for the wired medium is received on a wireless interface of an AP, the AP "bridges" the frame from the wireless medium to the wired medium.
• data frames containing encapsulated data packets typically include a Media Access Control (MAC) header, a Logical Link Control (LLC) header, a
• MAC Media Access Control
• LLC Logical Link Control
• Subnetwork Access Protocol SNAP
• frame body that includes the
• the Ethernet type code (e.g., the "Ethertype") of the encapsulated data packets may be indicated by the SNAP header.
• Ethertype xx-xx where each "x" may represent a hexadecimal number
• the data frame's LLC header may contain the value "AA-AA-03" to indicate the presence of a SNAP header
• the SNAP header may contain the value "00-00-00-xx-xx" to indicate that the data packet is of Ethertype xx-xx.
• 6 bytes of the data frame's LLC/SNAP header do not change, regardless of the Ethertype.
• data frames transmitted in the wireless network may include information indicating whether the data frames include Ethertype data packets formatted using EPD, for example, so that the various wireless devices within the wireless network may readily discern whether received data frames contain encapsulated Ethertype data packets formatted using EPD or LPD.
• the wireless device when a wireless device transmits a data frame encapsulating an Ethertype data packet, the wireless device may replace at least a portion of the LLC/SNAP header with an Ethertype field.
• the Ethertype field may contain fewer bytes than the replaced portion of the LLC/SNAP header, thereby reducing transmission overhead of the data frame.
• the Ethertype field which may follow the MAC header of the data frame, may indicate whether EPD or LPD is used to format the
• the Ethertype field of the data frame may be set to a selected value to indicate the use of LPD to format the encapsulated Ethertype data packets.
• the selected Ethertype value may also indicate that the replaced portion of LLC/SNAP header follows the Ethertype field in the data frame.
• a data frame for which the Ethertype field stores a value other than the selected value may indicate the use of EPD to format the encapsulated Ethertype data packets.
• an EPD indicator may be included in the MAC header of a data frame.
• the presence of the EPD indicator in the MAC header may indicate the use of EPD, while the absence of the EPD indicator in the MAC header may indicate the use of LPD.
• a wireless device may indicate the use of EPD on a packet-by- packet basis by including an EPD indicator in each of the transmitted data frames.
• Indicating the use of EPD on a packet-by-packet basis may be important for a receiving device to identify the protocol type (e.g., the Ethertype) of the encapsulated data packet, for example, so that the receiving device may parse the packet in accordance with classification rules and/or policies that define the protocol.
• the protocol type e.g., the Ethertype
• LPD LPD
• the receiving device may use a suitable EPD technique or operation to identify the protocol type of the data packet; conversely, if the encapsulated data packet is formatted using LPD, then the receiving device may use a suitable LPD technique or operation to identify the protocol type of the data packet.
• FIG. 1 is a block diagram of a wireless system 100 within which the example embodiments may be implemented.
• the wireless system 100 is shown to include four wireless stations STA1 -STA4, a wireless access point (AP) 1 10, and a wireless local area network (WLAN) 120.
• the WLAN 120 may be formed by a plurality of Wi-Fi access points (APs) that may operate according to the IEEE 802.1 1 family of standards (or according to other suitable wireless protocols).
• APs Wi-Fi access points
• the AP 1 10 is assigned a unique MAC address that is programmed therein by, for example, the manufacturer of the access point.
• each of STA1 -STA4 is also assigned a unique MAC address.
• the wireless system 100 may correspond to a multiple- input multiple-output (MIMO) wireless network.
• MIMO multiple- input multiple-output
• WLAN 120 is depicted in FIG. 1 as an infrastructure BSS, for other example embodiments, WLAN 120 may be an IBSS, an ad-hoc network, or a peer-to-peer (P2P) network (e.g., operating according to the Wi-Fi Direct protocols).
• P2P peer-to-peer
• Each of stations STA1 -STA4 may be any suitable Wi-Fi enabled wireless device including, for example, a cell phone, personal digital assistant (PDA), tablet device, laptop computer, or the like.
• Each station STA may also be referred to as a user equipment (UE), a subscriber station, a mobile unit, a subscriber unit, a wireless unit, a remote unit, a mobile device, a wireless device, a wireless communications device, a remote device, a mobile subscriber station, an access terminal, a mobile terminal, a wireless terminal, a remote terminal, a handset, a user agent, a mobile client, a client, or some other suitable terminology.
• UE user equipment
• each station STA may include one or more transceivers, one or more processing resources (e.g., processors and/or ASICs), one or more memory resources, and a power source (e.g., a battery).
• the memory resources may include a non- transitory computer-readable medium (e.g., one or more nonvolatile memory elements, such as EPROM, EEPROM, Flash memory, a hard drive, etc.) that stores instructions for performing operations described below with respect to FIG. 9.
• the AP 1 10 may be any suitable device that allows one or more wireless devices to connect to a network (e.g., a local area network (LAN), wide area network (WAN), metropolitan area network (MAN), and/or the Internet) via AP 1 10 using Wi-Fi, Bluetooth, or any other suitable wireless communication standards.
• a network e.g., a local area network (LAN), wide area network (WAN), metropolitan area network (MAN), and/or the Internet
• AP 1 10 may include one or more transceivers, one or more processing resources (e.g., processors and/or ASICs), one or more memory resources, and a power source.
• the memory resources may include a non-transitory computer-readable medium (e.g., one or more nonvolatile memory elements, such as EPROM, EEPROM, Flash memory, a hard drive, etc.) that stores instructions for performing operations described below with respect to FIG. 9.
• a non-transitory computer-readable medium e.g., one or more nonvolatile memory elements, such as EPROM, EEPROM, Flash memory, a hard drive, etc.
• the one or more transceivers may include Wi-Fi transceivers, Bluetooth transceivers, cellular transceivers, and/or other suitable radio frequency (RF) transceivers (not shown for simplicity) to transmit and receive wireless communication signals.
• Each transceiver may communicate with other wireless devices in distinct operating frequency bands and/or using distinct communication protocols.
• the Wi-Fi transceiver may communicate within a 2.4 GHz frequency band and/or within a 5 GHz frequency band in accordance with the IEEE 802.1 1 specification.
• the cellular transceiver may communicate within various RF frequency bands in accordance with a 4G Long Term Evolution (LTE) protocol described by the 3rd Generation Partnership Project (3GPP) (e.g., between approximately 700 MHz and approximately 3.9 GHz) and/or in accordance with other cellular protocols (e.g., a Global System for Mobile (GSM)
• LTE Long Term Evolution
• 3GPP 3rd Generation Partnership Project
• GSM Global System for Mobile
• the transceivers included within the STA may be any technically feasible transceiver such as a ZigBee transceiver described by a specification from the ZigBee specification, a WiGig transceiver, and/or a HomePlug transceiver described a specification from the HomePlug Alliance.
• AP 1 10 which may correspond to a Basic Service Set (BSS), may periodically broadcast beacon frames to enable any STAs within wireless range of the AP 1 10 to establish and/or maintain a communication link with the Wi-Fi network.
• the bacon frames which may include a traffic indication map (TIM) indicating whether the AP 1 10 has queued downlink data for the stations STA1 -STA4, are typically broadcast according to a target beacon transmission time (TBTT) schedule.
• the broadcasted beacon frames may also include the AP's timing synchronization function (TSF) value.
• the stations STA1 -STA4 may synchronize their own local TSF values with the broadcasted TSF value, for example, so that all the stations STA1 - STA4 are synchronized with each other and the AP 1 10.
• FIG. 2 shows an example STA 200 that may be one embodiment of one or more of the stations STA1 -STA4 of FIG. 1 .
• the STA 200 may include a PHY device 210 including at least a number of transceivers 21 1 and a baseband processor 212, may include a MAC 220 including at least a number of contention engines 221 and frame formatting circuitry 222, may include a processor 230, may include a memory 240, and may include a number of antennas 250(1 )-250(n).
• the transceivers 21 1 may be coupled to antennas 250(1 )-250(n), either directly or through an antenna selection circuit (not shown for simplicity).
• the transceivers 21 1 may be used to transmit signals to and receive signals from AP 1 10 and/or other STAs (see also FIG. 1 ), and may be used to scan the surrounding environment to detect and identify nearby access points and/or other STAs (e.g., within wireless range of STA 200).
• the transceivers 21 1 may include any number of transmit chains to process and transmit signals to other wireless devices via antennas 250(1 )-250(n), and may include any number of receive chains to process signals received from antennas 250(1 )- 250(n).
• the STA 200 may be configured for MIMO
• the MIMO operations may include single-user M IMO (SU-MIMO) operations and multi-user MIMO (MU-MIMO) operations.
• the baseband processor 212 may be used to process signals received from processor 230 and/or memory 240 and to forward the processed signals to transceivers 21 1 for transmission via one or more of antennas 250(1 )-250(n), and may be used to process signals received from one or more of antennas 250(1 )-250(n) via transceivers 21 1 and to forward the processed signals to processor 230 and/or memory 240.
• MAC 220 is shown in FIG. 2 as being coupled between PHY device 210 and processor 230.
• PHY device 210, MAC 220, processor 230, and/or memory 240 may be connected together using one or more buses (not shown for simplicity).
• the contention engines 221 may contend for access to one more shared wireless mediums, and may also store packets for transmission over one more shared wireless mediums.
• the STA 200 may include one or more contention engines 221 for each of a plurality of different access categories.
• the contention engines 221 may be separate from MAC 220.
• the contention engines 221 may be implemented as one or more software modules (e.g., stored in memory 240 or stored in memory provided within MAC 220) containing instructions that, when executed by processor 230, perform the functions of contention engines 221 .
• the frame formatting circuitry 222 may be used to create and/or format frames received from processor 230 and/or memory 240 (e.g., by adding MAC headers to PDUs provided by processor 230), and may be used to re-format frames received from PHY device 210 (e.g., by stripping MAC headers from frames received from PHY device 210).
• Memory 240 may include an AP profile data store 241 that stores profile information for a plurality of APs.
• the profile information for a particular AP may include information including, for example, the AP's service set identifier (SSID), MAC address, channel information, whether EPD is supported, RSSI values, goodput values, channel state information (CSI), supported data rates, connection history with the AP, a trustworthiness value of the AP (e.g., indicating a level of confidence about the AP's location, etc.), and any other suitable information pertaining to or describing the operation of the AP.
• SSID AP's service set identifier
• MAC address channel information
• channel information whether EPD is supported
• RSSI values RSSI values
• goodput values channel state information
• CSI channel state information
• supported data rates connection history with the AP
• connection history with the AP e.g., a trustworthiness value of the AP (e.g., indicating a level of confidence about the
• Memory 240 may also include a non-transitory computer-readable medium (e.g., one or more nonvolatile memory elements, such as EPROM, EEPROM, Flash memory, a hard drive, and so on) that may store at least the following software (SW) modules:
• SW software
• a frame formatting and exchange software module 242 to facilitate the creation and exchange of any suitable frames (e.g., data frames, control frame, and management frames) between STA 200 and other wireless devices (e.g., as described for one or more operations of FIG. 9);
• an EPD indicator detection software module 243 to facilitate the detection of an EPD indicator in an incoming frame (e.g., as described for one or more operations of FIG. 9);
• a frame processing software module 244 to process one or more packets encapsulated in the incoming frame based, at least in part, on detection of the EPD indicator in the incoming frame (e.g., as described for one or more operations of FIG. 9).
• Each software module includes instructions that, when executed by processor 230, cause STA 200 to perform the corresponding functions.
• the non-transitory computer-readable medium of memory 240 thus includes instructions for performing all or a portion of the operations depicted in FIG. 9.
• Processor 230 may be any suitable one or more processors capable of executing scripts or instructions of one or more software programs stored in STA 200 (e.g., within memory 240).
• processor 230 may execute the frame formatting and exchange software module 242 to facilitate the creation and exchange of any suitable frames (e.g., data frames, control frame, and management frames) between STA 200 and other wireless devices.
• Processor 230 may execute the EPD indicator detection software module 243 to facilitate the detection of an EPD indicator in an incoming frame.
• Processor 230 may execute the frame processing software module 244 to process one or more packets encapsulated in the incoming frame based, at least in part, on detection of the EPD indicator in the incoming frame.
• execution of the EPD indicator detection software module 243 may cause the STA 200 to use a suitable EPD technique or operation to identify the protocol type of the encapsulated data packet.
• execution of the EPD indicator detection software module 243 may cause the STA 200 to use a suitable LPD technique or operation to identify the protocol type of the encapsulated data packet.
• FIG. 3 shows an example AP 300 that may be one embodiment of the AP 1 10 of
• AP 300 may include a PHY device 310 including at least a number of transceivers 31 1 and a baseband processor 312, may include a MAC 320 including at least a number of contention engines 321 and frame formatting circuitry 322, may include a processor 330, may include a memory 340, may include a network interface 350, and may include a number of antennas 360(1 )-360(n).
• the transceivers 31 1 may be coupled to antennas 360(1 )-360(n), either directly or through an antenna selection circuit (not shown for simplicity).
• the transceivers 31 1 may be used to communicate wirelessly with one or more STAs, with one or more other APs, and/or with other suitable devices.
• the transceivers 31 1 may include any number of transmit chains to process and transmit signals to other wireless devices via antennas 360(1 )-360(n), and may include any number of receive chains to process signals received from antennas 360(1 )-360(n).
• the AP 300 may be configured for M IMO operations including, for example, SU-MIMO operations and MU-M IMO operations.
• the baseband processor 312 may be used to process signals received from processor 330 and/or memory 340 and to forward the processed signals to transceivers 31 1 for transmission via one or more of antennas 360(1 )-360(n), and may be used to process signals received from one or more of antennas 360(1 )-360(n) via transceivers 31 1 and to forward the processed signals to processor 330 and/or memory 340.
• the network interface 350 may be used to communicate with a WLAN server (not shown for simplicity) either directly or via one or more intervening networks and to transmit signals.
• Processor 330 which is coupled to PHY device 310, to MAC 320, to memory
• MAC 320 is shown in FIG. 3 as being coupled between PHY device 310 and processor 330.
• PHY device 310, MAC 320, processor 330, memory 340, and/or network interface 350 may be connected together using one or more buses (not shown for simplicity).
• the contention engines 321 may contend for access to the shared wireless medium, and may also store packets for transmission over the shared wireless medium.
• AP 300 may include one or more contention engines 321 for each of a plurality of different access categories.
• the contention engines 321 may be separate from MAC 320.
• the contention engines 321 may be implemented as one or more software modules (e.g., stored in memory 340 or within memory provided within MAC 320) containing instructions that, when executed by processor 330, perform the functions of contention engines 321 .
• the frame formatting circuitry 322 may be used to create and/or format frames received from processor 330 and/or memory 340 (e.g., by adding MAC headers to PDUs provided by processor 330), and may be used to re-format frames received from PHY device 310 (e.g., by stripping MAC headers from frames received from PHY device 310).
• Memory 340 may include a STA profile data store 341 that stores profile information for a plurality of STAs.
• the profile information for a particular STA may include information including, for example, its MAC address, whether EPD is supported, supported data rates, connection history with AP 300, and any other suitable information pertaining to or describing the operation of the STA.
• Memory 340 may also include a non-transitory computer-readable medium (e.g., one or more nonvolatile memory elements, such as EPROM, EEPROM, Flash memory, a hard drive, and so on) that may store at least the following software (SW) modules:
• SW software
• a frame formatting and exchange software module 342 to facilitate the creation and exchange of any suitable frames (e.g., data frames, control frames, and management frames) between AP 300 and other wireless devices (e.g., as described for one or more operations of FIG. 9);
• an EPD indicator detection software module 343 to facilitate the detection of an EPD indicator in an incoming frame (e.g., as described for one or more operations of FIG. 9);
• a frame processing software module 344 to process one or more packets encapsulated in the incoming frame based, at least in part, on detection of the EPD indicator in the incoming frame (e.g., as described for one or more operations of FIG. 9).
• Each software module includes instructions that, when executed by processor 330, cause AP 300 to perform the corresponding functions.
• the non-transitory computer-readable medium of memory 340 thus includes instructions for performing all or a portion of the AP-side operations depicted in FIG. 9.
• Processor 330 may execute the frame formatting and exchange software module
• Processor 330 may execute the EPD indicator detection software module 343 to facilitate the detection of an EPD indicator in an incoming frame.
• Processor 330 may execute the frame processing software module 344 to process one or more packets encapsulated in the incoming frame based, at least in part, on detection of the EPD indicator in the incoming frame.
• execution of the frame processing software module 344 may cause the AP 300 to use a suitable EPD technique or operation to identify the protocol type of the encapsulated data packet.
• execution of the frame processing software module 344 may cause the AP 300 to use a suitable LPD technique or operation to identify the protocol type of the encapsulated data packet.
• FIG. 4 depicts a legacy IEEE 802.1 1 -compliant data frame 400 containing an encapsulated data packet of Ethertype xx-xx formatted using LPD.
• the data frame 400 is depicted in FIG. 4 as including a MAC header 401 , an LLC header 402, a SNAP header 403, and a frame body 404.
• the MAC header 401 of data frame 400 depicted in FIG. 4 does not contain an EPD indicator.
• the absence of an EPD indicator in the MAC header 401 may indicate that LPD is used to format the encapsulated Ethertype data packet.
• the LLC header 402 is shown to include a value of "AA-AA-03,” which may indicate the presence of a SNAP header (e.g., SNAP header 403) immediately following the LLC header 402.
• the SNAP header 403 is shown to include a value of "00-00-00-xx-xx,” which may indicate that frame body 404 contains an encapsulated data packet of Ethertype xx-xx.
• the LLC header 402 and the SNAP header 403 may together include 8 bytes of information.
• FIG. 5 depicts an example data frame 500 containing an encapsulated data packet of Ethertype xx-xx formatted using EPD, in accordance with example embodiments.
• the data frame 500 is depicted in FIG. 5 as including a MAC header 501 , an Ethertype field 502, and a frame body 503.
• the MAC header 501 is depicted in FIG. 5 as including an EPD indicator 550.
• the presence of the EPD indicator 550 in the MAC header 501 may indicate that an Ethertype data packet encapsulated in frame body 503 is formatted using EPD (e.g., rather than LPD).
• the Ethertype field 502 is depicted in FIG.
• an Ethertype value 08- 00 indicates that the data packet encapsulated in frame body 503 is an Internet Protocol version 4 (IPv4) data packet.
• IPv4 Internet Protocol version 4
• an Ethertype value 08-DD indicates that the data packet encapsulated in frame body 503 is an IPv6 data packet.
• an Ethertype value 08-42 indicates that the data packet encapsulated in frame body 503 is a Wake-on LAN packet.
• the data frame 500 of FIG. 5 may be created by replacing the 8-byte LLC/SNAP header 402/403 of data frame 400 of FIG. 4 with the 2-byte Ethertype field 502 of FIG. 5, thereby resulting in the overhead (e.g., header size) of data frame 500 being 6 bytes less than the overhead of data frame 400 of FIG. 4. Because the overhead of data frame 500 of FIG. 5 is less than the overhead of data frame 400 of FIG. 4, exchanging encapsulated Ethertype data packets between wireless devices using data frames 500 may result in a more efficient utilization of a shared wireless medium, for example, as compared with exchanging encapsulated Ethertype data packets using data frames 400.
• the Ethertype field 502 of data frame 500 may be another suitable length.
• FIG. 6A depicts one example MAC header 61 OA within which the example embodiments may be implemented.
• MAC header 61 OA may be used as the MAC header 501 of data frame 500 of FIG. 5.
• MAC header 61 OA may be used as the MAC header of another suitable data frame.
• MAC header 61 OA may be used as the MAC header of any suitable control frame and/or management frame.
• MAC header 61 OA may include an EPD indicator to indicate (e.g., to a receiving device) that the corresponding frame includes an encapsulated Ethertype data packet formatted using EPD (rather than LPD).
• MAC header 61 OA is depicted in FIG. 6A as including a frame control field 61 1 , a duration/ID field 612, an address 1 field 613, an address 2 field 614, an address 3 field 615, a sequence control field 616, an address 4 field 617, a Quality of Service (QoS) control field 618, and a high-throughput (HT) field 619.
• a frame control field 61 1 a duration/ID field 612
• an address 1 field 613 an address 2 field 614
• an address 3 field 615 a sequence control field 616
• an address 4 field 617 an address 4 field 617
• QoS Quality of Service
• HT high-throughput
• the frame control field 61 1 is 2 bytes
• the duration/ID field 612 is 2 bytes
• the address 1 field 613 is 6 bytes
• the address 2 field 614 is 6 bytes
• the address 3 field 615 is 6 bytes
• the sequence control field 616 is 2 bytes
• the address 4 field 617 is 0 or 6 bytes
• the QoS control field 618 is 0 or 2 bytes
• the HT field 619 is 0 or 4 bytes.
• the fields of the MAC header 61 OA of FIG. 6A may be of other suitable lengths.
• the address 4 field 617 may be omitted from MAC header 61 OA (e.g., when the corresponding frame is transmitted within a given BSS), the QoS control field 618 may be omitted (e.g., when the corresponding frame is not a QoS data frame), and/or the HT field 619 may be omitted (e.g., when the corresponding frame does not support HT capabilities).
• the address 1 field 613 may be used to store a receiver address (RA) for the corresponding frame
• the address 2 field 614 may be used to store a transmitter address (TA) for the corresponding frame
• the address 3 field 614 and the address 4 field 617 may be used to store a source address (SA) and a destination address (DA), for example, when the corresponding frame contains an A-MSDU.
• the sequence control field 616 may be used to assign sequence numbers to MSDUs, A-MSDUs, and/or MMPDUs, and may be used to assign fragment numbers to each fragment of an MSDU or MMPDU.
• the EPD indicator 550 may be provided within the frame control field 61 1 of the MAC header 61 OA.
• the frame control field 61 1 is shown to include at least a 2-bit frame Type field 61 1 A and a 4-bit Subtype field 61 1 B (other fields of the frame control field 61 1 are not shown for simplicity).
• the Subtype field 61 1 B may be populated with currently unused or reserved bit patterns to indicate that the corresponding frame uses EPD.
• FIG. 7 shows a table 700 listing valid type and subtype values for the 2-bit frame
• Type field 61 1 A and the 4-bit Subtype field 61 1 B of FIG. 6A For example, while a bit pattern of "0100" stored in the Subtype field 61 1 B of MAC header 61 OA indicates a null data packet (NDP), a selected one of the unused or reserved bit patterns stored in the Subtype field 61 1 B of MAC header 61 OA may indicate that the corresponding data frame uses EPD.
• NDP null data packet
• the reserved bit pattern of "1 101 " may be stored in the Subtype field 61 1 B of MAC header 61 OA to indicate that the corresponding data frame uses EPD to format an encapsulated Ethertype data packet. More specifically, a frame type value of "10" and a subtype value of "1 101 " stored in the frame control field 61 1 of MAC header 61 OA may serve as the EPD indicator 550 for the corresponding data frame.
• extraction of the reserved bit pattern "1 101 " from the Subtype field 61 1 B may indicate that the corresponding data frame contains an encapsulated Ethertype data packet formatted using EPD.
• an unused or reserved bit pattern may be stored in the frame type field 61 1 A and a selected one of a number of corresponding unused or reserved bit patterns may be stored in the Subtype field 61 1 B to indicate that the
• the unused bit pattern of "1 1 " may be stored in the frame Type field 61 1 A of MAC header 61 OB to reference an extension Subtype, and any of the unused or reserved bit patterns (e.g., any of the values between "0001 " and "1 1 1 1 ,” inclusive) associated with the extension subtype may be stored in the Subtype field 61 1 B of MAC header 610B to indicate that the corresponding data frame uses EPD.
• the extension subtype value "1000" may be stored in the
• Subtype field 61 1 B to indicate a QoS Data + EPD subtype, which means that a QoS control header is present and that EPD is used (rather than LPD).
• the extension subtype value "1001 " may be stored in the Subtype field 61 1 B to indicate a QoS data + CF- ACK + EPD subtype, which means that a QoS control header is present in the contention-free (CF) ACK frame and that EPD is used (rather than LPD).
• the extension subtype value "1010" may be stored in the Subtype field 61 1 B to indicate a QoS data + CF- Poll + EPD subtype, which means that a QoS control header is present in the CF-Poll frame and that EPD is used (rather than LPD).
• the extension subtype value "101 1 " may be stored in the Subtype field 61 1 B to indicate a QoS data + CF-ACK + CF-Poll + EPD subtype, which means that a QoS control header is present in the CF-ACK/CF-Poll frame and that EPD is used (rather than LPD).
• Other extension subtypes may be used to indicate, for example, other types of frames that use EPD (rather than LPD).
• a frame type value of "1 1 " stored in the frame type field 61 1 A, together with a subtype value other than "0000" (which indicates a DMG beacon) stored in the subtype field 61 1 B, may serve as the EPD indicator 550.
• extraction of the reserved bit pattern "1 1 " from the frame type field 61 1A, along with extraction of any of the reserved bits patterns "0001 " to "1 1 1 1 " from the subtype field 61 1 B may indicate that the corresponding frame uses EPD.
• the EPD indicator 550 may be provided within the address 1 field of a MAC header.
• FIG. 6C depicts another example MAC header 610C within which the example embodiments may be implemented.
• the MAC header 610C is similar to the MAC headers 61 OA and 610B of FIGS. 6A and 6B, respectively, except that the EPD indicator 550 may be stored within the address 1 field 613 (rather than in the frame control field 61 1 ).
• the address 1 field 613 stores the receiver address (RA) of the corresponding frame.
• the RA may be the MAC address of the wireless device to which the corresponding frame is to be delivered.
• the RA may be a group address indicating a group of wireless devices to which the corresponding frame is to be delivered.
• the RA may be set to all "1 's" so that the corresponding frame is received by all wireless devices associated with the wireless network.
• the address 1 field 613 may store a MAC address (e.g., of a receiving device).
• the MAC address which may be commonly referred to as the
• organizationally unique identifier typically includes 6 bytes of address information.
• the first 3 bytes of the MAC address may identify which organization manufactured the device, and is commonly referred to as the "organization identifier.”
• the organization identifier may be assigned by the Institute of Electrical and Electronic Engineers (IEEE).
• the second 3 bytes of the MAC address (denoted by sub-field 613B) may be used to uniquely identify the individual device, and is commonly referred to as the network interface controller (NIC) specific bytes,.
• NIC network interface controller
• the first byte 620 of the OUI is shown to include bits b0-b7.
• the least significant bit (LSB) of the first byte 620, bit bO, is typically used as the individual/group (l/G) bit of the MAC address.
• the LSB of the first byte 620 of the OUI may be referred to herein as the l/G bit.
• the l/G bit of the OUI may be used as the EPD indicator 550.
• FIG. 8A depicts an example data frame 800 containing an encapsulated data packet of Ethertype xx-xx formatted using LPD, in accordance with example embodiments.
• the data frame 800 is shown in FIG. 8A to include a MAC header 801 , an Ethertype 802, an LLC end field 803, a SNAP header 804, and a frame body 805 containing an encapsulated data packet of Ethertype xx-xx.
• the Ethertype 802, which immediately follows the MAC header 801 is shown to store an example reserved Ethertype value "AA-AA" signaling the use of LPD and indicating that a remainder of the LLC/SNAP value follows the Ethertype 802, for example, in the LLC end field 803.
• Ethertype 802 which immediately follows the MAC header 801 , is shown to store an example reserved Ethertype value "AA-AA" signaling the use of LPD and indicating that a remainder of the LLC/SNAP value follows the Ethertype 802, for example, in the LLC end field 803.
• the LLC end field 803 may store a value "03" that forms a remainder of the LLC/SNAP value.
• the Ethertype value of "AA-AA” is combined with the LLC value "03,” the resulting value "AA-AA-03" may form an LLC header similar to the LLC header of data frame 400 of FIG. 4.
• the header portion of data frame 800 is similar to the header portion of data frame 400, data frame 400 and data frame 800 may signal the use of EPD in different manners.
• data frame 400 may indicate the use of LPD (rather than EPD) by not including an EPD indicator in data frame 400
• data frame 800 may indicate the use of LPD by setting the Ethertype to the reserved value of "AA-AA.” If the Ethertype of data frame 800 is not set to any reserved value that indicates the use of LPD, then the use of EPD may be presumed.
• FIG. 8B depicts an example data frame 810 containing an encapsulated data packet of Ethertype xx-xx formatted using EPD, in accordance with example embodiments.
• the data frame 810 is shown in FIG. 8B to include a MAC header 81 1 , an Ethertype 812, and a frame body 813 containing an encapsulated data packet of Ethertype xx-xx.
• an Ethertype value of "xx-xx" immediately following MAC header 81 1 may signal the use of EPD, and may indicate that the data frame 810 contains an encapsulated data packet of Ethertype xx-xx, where the Ethertype value of "xx-xx" is not an Ethertype value reserved to indicate the use of LPD (e.g., as described above with respect to FIG. 8A).
• data frame 810 of FIG. 8B may appear similar to the data frame 500 of FIG. 5, data frame 810 and data frame 500 may signal the use of EPD in different manners. For example, while data frame 500 of FIG.
• EPD 5 may indicate the use of EPD by the presence of EPD indicator 550 in its MAC header 501 , data frame 810 may be presumed to indicate the use of EPD unless the reserved Ethertype value (e.g., AA-AA) is stored in the Ethertype 812.
• Ethertype value e.g., AA-AA
• FIG. 9 shows an illustrative flowchart depicting an example operation 900 for processing an Ethertype data packet encapsulated in a frame.
• the example operation 900 may be performed by a first wireless device.
• the first wireless device receives a frame from a second wireless device over a wireless network, the frame including an encapsulated
• the encapsulated Ethertype data packet may be formatted, for example, according to an LPD technique or according to an EPD technique.
• the first wireless device may detect a presence of an EPD indicator in the received frame (904).
• the EPD indicator may be embedded within the frame control field of the received frame's MAC header (e.g., as described above with respect to FIGS. 6A and 6B).
• the EPD indicator may be a reserved or unused bit pattern stored in the subtype field of the frame control field.
• the EPD indicator may be embedded within a MAC address stored in an address field of the received frame's MAC header (e.g., as described above with respect to FIG. 6C).
• the first wireless device may identify a protocol type of the Ethertype data packet according to an EPD operation based on the presence of the EPD indicator in the received frame (906).
• the presence of the EPD indicator in the received frame may indicate that an Ethertype value of the Ethertype data packet immediately follows the received frame's MAC header.
• the first wireless device may identify the protocol type of the Ethertype data packet according to an LPD operation based on an absence of the EPD indicator in the received frame (908).
• the absence of the EPD indicator in the received frame may indicate that the Ethertype value of the Ethertype data packet is contained in the SNAP header of the received frame.
• the first and second wireless devices may be any suitable wireless devices.
• each of the first and second wireless devices may an AP (e.g., AP 1 10 of FIG. 1 or AP 300 of FIG. 3) or a station (e.g., one of stations STA1 -STA4 of FIG. 1 or STA 200 of FIG. 2).
• AP e.g., AP 1 10 of FIG. 1 or AP 300 of FIG. 3
• station e.g., one of stations STA1 -STA4 of FIG. 1 or STA 200 of FIG. 2.
• FIG. 10 shows an example wireless device or apparatus 1000 represented as a series of interrelated functional modules.
• a module 1001 for receiving, from another wireless device over a wireless network, a frame including an encapsulated Ethertype data packet may correspond at least in some aspects to, for example, a processor as discussed herein (e.g., processor 230 of FIG. 2 and/or processor 330 of FIG. 3).
• a module 1002 for detecting a presence of an Ethertype Packet Discrimination (EPD) indicator in the received frame may correspond at least in some aspects to, for example, a processor as discussed herein (e.g., processor 230 of FIG. 2 and/or processor 330 of FIG. 3).
• EPD Ethertype Packet Discrimination
• a module 1003 for identifying a protocol type of the Ethertype data packet according to an EPD operation based on the presence of the EPD indicator in the received frame may correspond at least in some aspects to, for example, a processor as discussed herein (e.g., processor 230 of FIG. 2 and/or processor 330 of FIG. 3).
• a module 1004 for identifying the protocol type of the Ethertype data packet according to a Logical Link Control Packet Discrimination (LPD) operation based on an absence of the EPD indicator in the received frame may correspond at least in some aspects to, for example, a processor as discussed herein (e.g., processor 230 of FIG. 2 and/or processor 330 of FIG. 3).
• LPD Logical Link Control Packet Discrimination
• the functionality of the modules of FIG. 10 may be implemented in various ways consistent with the teachings herein.
• the functionality of these modules may be implemented as one or more electrical components.
• the functionality of these blocks may be implemented as a processing system including one or more processor components.
• the functionality of these modules may be implemented using, for example, at least a portion of one or more integrated circuits (e.g., an ASIC).
• an integrated circuit may include a processor, software, other related components, or some combination thereof.
• the functionality of different modules may be implemented, for example, as different subsets of an integrated circuit, as different subsets of a set of software modules, or a combination thereof.
• a given subset (e.g., of an integrated circuit and/or of a set of software modules) may provide at least a portion of the functionality for more than one module.
• the components and functions represented by FIG. 10, as well as other components and functions described herein may be implemented using any suitable means. Such means also may be implemented, at least in part, using corresponding structure as taught herein.
• the components described above in conjunction with the "module for" components of FIG. 10 also may correspond to similarly designated “means for” functionality.
• one or more of such means may be implemented using one or more of processor components, integrated circuits, or other suitable structure as taught herein.
• a software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.
• An exemplary storage medium is coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor.
• one aspect of the disclosure can include a non-transitory computer readable media embodying a method for time and frequency synchronization in non- geosynchronous satellite communication systems.
• the term "non-transitory” does not exclude any physical storage medium or memory and particularly does not exclude dynamic memory (e.g., conventional random access memory (RAM)) but rather excludes only the interpretation that the medium can be construed as a transitory propagating signal.
• RAM random access memory

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Computer Security & Cryptography (AREA)
• Mobile Radio Communication Systems (AREA)
• Communication Control (AREA)

Priority Applications (6)

Applications Claiming Priority (6)

Publications (1)

Family

ID=56011441

Family Applications (1)

Country Status (9)

Cited By (1)

Families Citing this family (5)

Citations (3)

Family Cites Families (22)

• 2015
  • 2015-11-24 US US14/950,102 patent/US9961170B2/en active Active
  • 2015-11-25 KR KR1020177013515A patent/KR101929903B1/ko active Active
  • 2015-11-25 WO PCT/US2015/062719 patent/WO2016086156A1/en not_active Ceased
  • 2015-11-25 CN CN201580063410.3A patent/CN107005551B/zh active Active
  • 2015-11-25 JP JP2017525976A patent/JP6403886B2/ja active Active
  • 2015-11-25 TW TW104139218A patent/TWI644552B/zh active
  • 2015-11-25 BR BR112017010949-2A patent/BR112017010949A2/pt not_active Application Discontinuation
  • 2015-11-25 AU AU2015353460A patent/AU2015353460B2/en not_active Expired - Fee Related
  • 2015-11-25 EP EP15813963.4A patent/EP3225013B1/en active Active

Patent Citations (3)

Also Published As

Similar Documents

Legal Events