(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2005/0174962 A1
`(43) Pub. Date:
`Aug. 11, 2005
`Gurevich
`
`US 2005O174962A1
`
`(54) GENERIC CLIENT FOR COMMUNICATION
`DEVICES
`
`(76) Inventor: David Gurevich, San Mateo, CA (US)
`Correspondence Address:
`MARGER JOHNSON & MCCOLLOM, P.C.
`1030 SW MORRISON STREET
`PORTLAND, OR 97205 (US)
`(21) Appl. No.:
`11/015,096
`(22) Filed:
`Dec. 16, 2004
`Related U.S. Application Data
`(60) Provisional application No. 60/542,644, filed on Feb.
`5, 2004.
`
`Publication Classification
`
`(51) Int. Cl." ....................................................... H04B 7/00
`(52) U.S. Cl. .............................................................. 370/328
`
`(57)
`
`ABSTRACT
`
`A Generic Client (GC) operates multiple virtual network
`interfaces that communicate Simultaneously to different net
`WorkS. Each virtual interface is capable of independent
`communication over an associated network through the
`Same physical interface. In one implementation, the GC
`provides Simultaneous communication with both infrastruc
`ture and ad-hoc networks in compliance with the IEEE
`802.11 protocol. The GC provides these dual modes of
`operation by instantiating different infrastructure and ad-hoc
`Virtual interfaces.
`
`
`
`DELL
`EXHIBIT 1010 - PAGE 1
`
`

`

`Patent Application Publication Aug. 11, 2005 Sheet 1 of 13
`
`US 2005/0174962 A1
`
`
`
`Figure 1
`
`DELL
`EXHIBIT 1010 - PAGE 2
`
`

`

`Patent Application Publication Aug. 11, 2005 Sheet 2 of 13
`
`US 2005/0174962 A1
`
`
`
`2O
`M
`
`Q7
`
`Point-to
`multipoint
`
`Point-to-point
`
`FIG. 2
`
`DELL
`EXHIBIT 1010 - PAGE 3
`
`

`

`Patent Application Publication Aug. 11, 2005 Sheet 3 of 13
`
`N
`
`2, ( |!
`
`
`
`
`
`DELL
`EXHIBIT 1010 - PAGE 4
`
`

`

`Patent Application Publication Aug. 11, 2005 Sheet 4 of 13
`
`US 2005/0174962 A1
`
`
`
`Slo
`
`FIG 4
`
`DELL
`EXHIBIT 1010 - PAGE 5
`
`

`

`Patent Application Publication Aug. 11, 2005 Sheet 5 of 13
`
`US 2005/0174962 A1
`
`
`
`FIG. 5
`
`DELL
`EXHIBIT 1010 - PAGE 6
`
`

`

`Patent Application Publication Aug. 11, 2005 Sheet 6 of 13
`
`US 2005/0174962 A1
`
`To standard
`infrastructureAP's
`
`
`
`32
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`To standard
`infrastructure
`clients (STA's)
`
`Infrastructure
`STA interface
`physical
`Nee ACS
`Infrastructure AP
`interface
`
`is. -- - - - - -u
`
`:
`
`F \ C, 6
`
`DELL
`EXHIBIT 1010 - PAGE 7
`
`

`

`Patent Application Publication Aug. 11, 2005 Sheet 7 of 13
`
`US 2005/0174962 A1
`
`SC
`
`
`
`G. 7 (3.
`
`DELL
`EXHIBIT 1010 - PAGE 8
`
`

`

`Patent Application Publication Aug. 11, 2005 Sheet 8 of 13
`
`US 2005/0174962 A1
`
`Se
`
`TBRPF router
`
`
`
`FIG. 8
`
`DELL
`EXHIBIT 1010 - PAGE 9
`
`

`

`Patent Application Publication Aug. 11, 2005 Sheet 9 of 13
`
`US 2005/0174962 A1
`
`? ? ? ? ? ? ? ? ? ? • • • • • • • • • • • • • • • • • • • • • • • • • • •
`
`<!----············---···············:
`
`
`
`
`
`43] [10}{ dIl
`
`
`
`
`
`
`
`·- * • • • • • • • • • • • • • • • • • + • • • • ** • • • • • • • • + ••
`
`DELL
`EXHIBIT 1010 - PAGE 10
`
`

`

`Patent Application Publication Aug. 11, 2005 Sheet 10 of 13
`
`US 2005/0174962 A1
`
`
`
`
`
`
`
`
`
`se
`
`is see ease oases as as won steers an
`
`Applications
`
`Lee J 273
`
`3 2.
`
`so a as we woo w w we or a
`
`a
`
`a
`
`v Doo saw asso, so soon was saw sow-a sa
`
`as a ss
`
`infrastructure" i Aaho." intrastructure T
`STA interface
`STA interface
`AP interface
`
`33
`
`Infrastructure
`STAS
`
`Figure 10
`
`DELL
`EXHIBIT 1010 - PAGE 11
`
`

`

`Patent Application Publication Aug. 11, 2005 Sheet 11 of 13
`
`US 2005/0174962 A1
`
`- 32.
`
`2
`
`38
`
`
`
`Infrastructure
`STA interface
`(I-STA)
`
`Infrastructure
`AP interface
`- (I-AP)
`
`- O
`
`Ad-hoc
`STA interface
`(A-STA)
`
`
`
`
`
`
`
`
`
`xx xxx A () - Oc
`
`Mapping Table (header to interface)
`from AP -> (l-STA)
`from infrastructure STA-> (I-AP)
`from ad-hoc STA-> (A-STA)
`
`Network
`Interface
`
`C. V.
`
`DELL
`EXHIBIT 1010 - PAGE 12
`
`

`

`Patent Application Publication Aug. 11, 2005 Sheet 12 of 13
`
`US 2005/0174962 A1
`
`
`
`Acce SS PO in
`
`Y ( 2
`
`DELL
`EXHIBIT 1010 - PAGE 13
`
`

`

`Patent Application Publication Aug. 11, 2005 Sheet 13 of 13
`
`US 2005/0174962 A1
`
`Cl
`
`
`
`STA
`
`YG 13
`
`DELL
`EXHIBIT 1010 - PAGE 14
`
`

`

`US 2005/0174962 A1
`
`Aug. 11, 2005
`
`GENERC CLIENT FOR COMMUNICATION
`DEVICES
`
`BACKGROUND
`0001. This application claims priority from U.S. Provi
`sional Application Ser. No. 60/542,644, filed Feb. 5, 2004.
`0002 The Institute of Electrical and Electronic Engineers
`(IEEE) 802.11 wireless communication standard defines two
`main modes of operation: Infrastructure and ad-hoc. The
`infrastructure mode assumes that there is an AcceSS Point
`(AP) which enables clients, also called stations (STA), to
`connect to a wired network. The ad-hoc mode, on the other
`hand, mainly concerns itself with wireleSS peer-to-peer
`connections among clients. In the infrastructure mode all
`clients connect to the AP and Send their messages through it.
`In the ad-hoc mode the clients Send messages directly to
`each other. There is a third Wireless Distribution System
`(WDS) communication scheme that enables APs to send
`wireleSS messages to each other.
`0003. According to the 802.11 standard, a client that
`needs to Send data to an access point in the infrastructure
`mode first goes through authentication and association. A
`client that needs to Send data to another client in the ad-hoc
`mode may go through authentication, but authentication is
`not required. The 802.11 standard does not specify the
`precise mechanism for establishing WDS connections. Once
`the infrastructure, ad-hoc or WDS connections are estab
`lished, data messages, Such as 802.11 frames, may be sent.
`0004 Table 1.0 and FIG. 1 show how the header in a
`802.11 protocol frame 25 identifies the direction of frames
`25. The mechanism consists of two bits: a “From DS bit”
`and a “To DS bit”. A Distribution System (DS) 23 can be any
`communication network used for transporting information
`to or from a client. For example, a Wide Area Network
`(WAN), Local Area Network (LAN), packet switched, cir
`cuit Switched or any other type of wired or wireleSS network.
`0005. In FIG. 1, an access point 20 is connected to a
`wired LAN 21 that provides access to the DS 23. When the
`protocol frame 25 is sent from a client 18 to the AP 20 in the
`infrastructure mode 14, the To DS bit is set to 0 and the From
`DS bit is set to 1. When the AP 20 sends a frame 25 back to
`the client 18, the From DS bit is set to 0 and the To DS bit
`is set to 1. In the ad-hoc mode 12, when clients 18 send
`frames to each other, the From DS bit is set to 0 and the To
`DS bit is set to 0. In the WDS mode, the From DS bit is set
`to 1 and the To DS bit is set to 1.
`0006. This is documented in the IEEE 802.11 spec and
`shown in table 1.0 below.
`
`TABLE 1.0
`
`0007. The setting of the To DS and From DS bits also
`determine how addresses are used. The 802.11 frames sent
`between the client 18 and the AP 20 in the infrastructure
`mode use A3 (3 address) frames. The 802.11 frames sent
`between the client 18 and another client 18 in the ad-hoc
`mode are also A3 frames. The frames sent between one AP
`20 and another AP 20 in the WDS are A4 (4 address) frames.
`0008. The contents of the address fields are determined
`by the direction of the sent frame 25. The DA is the
`destination address and the SA is the Sender address. The
`BSSID is the Basic Service Set ID in the infrastructure
`mode. The BSSID is the Independent Basic Service Set ID
`(or IBSSID) in the ad-hoc mode. The RA is the receiver
`address and TA is the transmitter address.
`0009. In the A3 frame, the DA is equivalent to the RA and
`the SA is equivalent to the TA. This is because A3 frames are
`Sent over a single hop link. The A4 frames are Sent over
`multiple hops and the RA and TA change hop by hop where
`the DA and SA do not. Thus, the WDS connections support
`layer 2 forwarding.
`0010 The protocol message formats (headers and
`addressing) are important to the operation of the System as
`a whole because they are used by Media Access Control
`(MAC) firmware and software for filtering received mes
`sages. With broadcast media, the MAC layer determines
`which messages are processed and which are discarded.
`Thus, the header Settings have to be set correctly in order to
`implement a meshing System architecture with existing
`hardware and firmware.
`0011. The infrastructure mode 14 and the ad-hoc mode 12
`are mutually exclusive. A client 18 cannot operate in the
`infrastructure mode 14 and the ad-hoc mode 11 at the same
`time. Thus, client 18A operating in the infrastructure mode
`14 cannot communicate with the client 18B or 18C operat
`ing in the ad-hoc mode 12. Similarly, clients 18B and 18C
`operating in the ad-hoc mode 12 cannot communicate to
`client 18A operating in the infrastructure mode 14 or the DS
`23 via the AP 20.
`0012. This presents a problem for networks where mes
`Sages need to be sent to any type of AP or client any time
`they are within range. The present invention addresses this
`and other problems associated with the prior art.
`
`SUMMARY OF THE INVENTION
`0013 A Generic Client (GC) operates multiple virtual
`network interfaces that communicate Simultaneously to dif
`ferent networks. Each virtual interface is capable of inde
`pendent communication over an associated network through
`the same physical interface. In one implementation, the GC
`provides Simultaneous communication with both infrastruc
`ture and ad-hoc networks in compliance with the IEEE
`802.11 protocol. The GC provides these dual modes of
`operation by instantiating different infrastructure and ad-hoc
`Virtual interfaces.
`0014. The foregoing and other objects, features and
`advantages of the invention will become more readily appar
`ent from the following detailed description of a preferred
`embodiment of the invention which proceeds with reference
`to the accompanying drawings.
`
`To From
`DS DS Address 1 Address 2 Address 3 Address 4 Meaning
`O
`O DA
`SA
`BSSD
`N/A
`STA to STA
`data frame
`Data frame
`to DS
`Data frame
`from DS
`AP to AP
`WDS data
`
`N/A
`
`N/A
`
`SA
`
`DA
`
`DA
`
`O
`
`1 DA
`
`BSSID
`
`SA
`
`1.
`
`1.
`
`O BSSID
`
`SA
`
`1 RA
`
`TA
`
`DELL
`EXHIBIT 1010 - PAGE 15
`
`

`

`US 2005/0174962 A1
`
`Aug. 11, 2005
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`0.015
`FIG. 1 is a diagram showing a prior art wireless
`communication System with mutually exclusive operation to
`infrastructure and ad-hoc networks.
`0016 FIG. 2 is a block diagram showing how a Generic
`Client (GC) can communicate using both point-to-point and
`point-to-multipoint communication modes at the same time.
`0017 FIG. 3 is a block diagram showing how the GC
`instantiates multiple virtual interfaces.
`0.018
`FIG. 4 is a diagram showing the GC communicat
`ing with both a infrastructure network and an ad-hoc net
`work at the same time.
`0019 FIG. 5 shows how the GC can extend a wireless
`network by operating as a virtual Access Point (AP).
`0020 FIG. 6 shows an infrastructure STA and infrastruc
`ture AP interface in the G.C.
`0021 FIGS. 7A and 7B show how the GC operates as a
`bridge between two APs.
`0022 FIG. 8 shows how the virtual interfaces in the GC
`can be used for neighbor discovery.
`0023 FIG. 9 is an abstraction showing functionally how
`the GC operates.
`0024 FIG. 10 is a diagram showing the different opera
`tional layers in the platform operating the G.C.
`0025 FIG. 11 shows how the GC identifies which virtual
`interfaces are used for processing data.
`0.026
`FIG. 12 is a block diagram showing the hardware
`inside the device that runs the G.C.
`0.027
`FIG. 13 is a diagram showing devices that may
`operate the G.C.
`
`DETAILED DESCRIPTION
`0028. The system described below is applicable to any
`communication System that needs to operate with more than
`one network or operate in more than one communication
`mode at the same time. The particular set of examples
`described below use 802.11 local area networks. However,
`this should only be considered as an example of the wide
`variety of different networks that may use the communica
`tion System. For example, the communication System can be
`used for any wired or wireless network where multiple
`Virtual interfaces can be instantiated and operated at the
`Same time.
`0029 Generic Client
`0030) Referring to FIG. 2, a wireless communications
`system 30 may define specific functionality and roles above
`the physical transceiver level (also known as layer 1, or
`PHY). These roles define the behavior of the link layer
`protocol (layer 2, or MAC).
`0031. In a centralized configuration, a typical cellular
`architecture, an infrastructure wireleSS Local Area Network
`(LAN), or point-to-multipoint Local Multipoint Distribution
`Services (LMDS), or an 802.16 access network, one side of
`the link implements a base station controller 34 and the other
`a subscriber or a client 31. In an 802.11 ad-hoc configura
`tion, or a point-to-point wireleSS bridge, or a push-to-talk
`
`LMR System, the link endpoints constitute peers at the
`physical and link layers. Frequently the equipment used to
`implement the System in a particular mode depends on the
`configuration.
`0032. A generic client 32 is incorporated into one or more
`SubscriberS 31 and Supports multiple modes of Simultaneous
`operation. This enables the subscriber nodes 31 to act in a
`more flexible and dynamic way. The Subscriber nodes 31 can
`take advantage of new network topologies (Such as mesh),
`increased capacity, frequency reuse, and range extension as
`conditions allow without Switching mode of operation or
`reconfiguration. This can be accomplished with a Software
`or hardware implementation and is not limited to any
`particular radio technology or Spectrum.
`0033. The generic client 32 allows the subscriber nodes
`31 in wireless network 30 to communicate with other
`Subscriber nodes 31 in a point-to-point communication
`Scheme 29. The Subscriber nodes 31 can also communicate
`with other subscribers 31 through the base station 34 using
`a point-to-multipoint communication Scheme 27.
`0034) In FIG.3, a single physical layer (L1) interface 34,
`Such as a wireleSS radio, is used to gain access to a wireleSS
`media. A software driver implements Media Access Control
`(MAC) functionality at layer-2 (L2) of the Open System
`Interconnect (OSI) standard to instantiate multiple simulta
`neous virtual network interfaces 36, 38, 40 and 42. The
`Generic Client (GC) 32 simultaneously operates the multiple
`active logical interfaces 36-42 and in one example uses a
`803.11 transceiver in radio 34 for communicating using the
`802.11 protocol.
`0035) A Station (STA) infrastructure virtual interface 36
`is configured to operate like a STA (client) for communi
`cating with an AP 20 in an 802.11 wireless infrastructure
`network 41. An Access Point (AP) infrastructure virtual
`interface 38 is configured to operate like an AP for commu
`nicating in an 802.11 infrastructure communication network
`43 with clients or STAS 18A. ASTA ad-hoc virtual interface
`40 is configured to operate as a STA for communicating in
`an 802.11 ad-hoc communication network 45 directly with
`other clients or STAS 18B.
`0036) This enables the GC 32 to interoperate with an
`infrastructure AP 20, ad-hoc STA's 18B, and provide an AP
`Service to infrastructure STA's 18A at the same time. The
`GC 32 can also support a virtual Wireless Distribution
`System (WDS) interface 42 that provides communication
`between virtual AP 38 and other APs 44.
`0037. In one embodiment, the multi-mode (multiple per
`sonality) interfaces 36-42 are not bridged at layer 2. Alter
`natively, message forwarding and routing is implemented by
`layer 3 routing 46 of the Open System Interconnect (OSI)
`standard. This allows all of the L2 interfaces 36-42 to
`operate simultaneously using the same PHY interface 34.
`0038. The GC 32 determines which one of the virtual
`interfaces 36, 38, or 40 to use for communicating with the
`APs 20 and STAS 18A and 18B according to the “From DS
`bit and the “To DS bit in frame headers. The Basic Service
`Set IDs (BSSIDs) in the frames then uniquely identify
`different wireleSS Sessions.
`
`DELL
`EXHIBIT 1010 - PAGE 16
`
`

`

`US 2005/0174962 A1
`
`Aug. 11, 2005
`
`0039. Ad-Hoc Network 45
`0040. In one implementation, A3 frames as described in
`table 1.0 are used to communicate in the ad-hoc network 45.
`The virtual interface 40 sets the From DS and To DS bits to
`0 in the frame header. The STAS 18B then operate on the
`same IBSS in ad-hoc network 45. The association is not
`required between STAS before Sending data. An authentica
`tion Step is optional. Broadcast destination addresses are
`allowed and used for discovery. This is compliant with the
`802.11 standard. This therefore supports standard STAS 18B
`operating in the 802.11 ad-hoc mode. Because there is a
`common network interface there are no implications for the
`upper layer protocols like IP and IP routing.
`0041)
`Infrastructure Networks 41 and 43
`0042. In infrastructure networks 41 and 43, the A3 frames
`shown in table 1.0 are used to communicate. The From DS
`and To DS bits are set according to the destination/Source of
`the frame. All of the STAS or clients 18A operate on the same
`BSS network. Normally association is required for this
`mode. If the association is used, this implies that one side of
`the link functions as an AP and the other side as a STA.
`However, it is possible that no association is used.
`0043. The To DS bit, From DS bit, and addresses are set
`accordingly on every frame. Broadcast destination addresses
`are used for discovery. Aside from the frame header format,
`the infrastructure virtual interfaces 36 and 38 may be similar
`to the ad-hoc virtual interface 40. Because there is a com
`mon network interface there are no implications for the
`upper layer protocols like IP and IP routing.
`0044) WDS Network 42
`0045. In the WDS network, the A4 frames shown in table
`1.0 might be used to communicate. The From DS and To DS
`bits and the addresses are set according to table 1.0. In AP
`to AP WDS, all 4 address fields in table 1.0 are used.
`Because forwarding is not being performed at layer 2, the
`Address 3 and Address 4 fields are redundant. Broadcast
`addresses are also redundant because the WDS links can
`only be set up with the knowledge of the addresses on both
`Sides of the link. This is arguably a Standard compliant
`mode. Even though the 802.11 standard does not specify the
`use of the WDS in a STA, it does not preclude it either. The
`STAS in the WDS mode have the capability of setting up
`WDS links to other access points 44.
`0046) The WDS mode 42 has significant implications on
`the upper layer protocols, particularly IP routing. The WDS
`link abstraction is a network interface. Unlike the ad-hoc or
`infrastructure networks, a Separate Sub-network interface is
`created for every link.
`0047. This is accomplished either manually or statically
`or dynamically. The manual configuration is done with prior
`knowledge of the hardware address of the remote client. The
`dynamic configuration works by listening for 802.11 beacon
`frames from the remote client. The beacon frame contains
`the hardware address. Upon receiving the frame, a WDS link
`can be set up and a network interface instantiated.
`0.048. In another embodiment, the GC 32 can also support
`other proprietary virtual network interfaces 47. A proprietary
`network 51 can communicate over the same physical inter
`face 34 used for the 802.11 networks 41, 43 and 45.
`However, the proprietary network 51 may not follow, or
`
`only partially follow, the 802.11 protocol. For example,
`proprietary network 51 may include additional Security or
`encryption operations that are not Supported in 802.11. The
`CG 32 can communicate with a client 49 over the propri
`etary network 51 using the same physical interface 34 used
`for the 802.11 infrastructure and ad-hoc networks 41, 43 and
`45.
`0049 FIG. 4 shows how the GC 32 can communicate
`with an AP 20 over an infrastructure network 50 and at the
`Same time communicate with one or more GCS 32 and/or
`non-generic Standard clients (STAS) over an ad-hoc network
`52. The GC 32 instantiates a STAMAC service interface 36
`(FIG. 3) that communicates with the infrastructure AP 20.
`At the same time the GC 32 can instantiate an ad-hoc STA
`interface 40 (FIG. 3) for communicating directly with other
`ad-hoc clients. One or more of the GCs 32 may also
`instantiate an AP infrastructure interface 38. This allows the
`GCS 32 to act as a layer 3 gateway to the infrastructure AP
`20 or to other clients.
`0050. The infrastructure AP 20 may be connected to a
`wide variety of external networks 54 including wired or
`wireless networks, Wide Area Network (WANs), Local Area
`Networks (LANs), packet switched networks, circuit
`Switched networks or any other type of wired or wireless
`communication System used for transporting information.
`0051 Transparent Range Extension
`0.052 FIG. 5 shows how the GC 32 can expand client
`functionality and range by operating as a bridge. The GC 32
`can act as a virtual AP that communicates with another GCS
`32, STAS 18, and APs 20. For example, the GC 32A can
`instantiate an infrastructure STA virtual interface 36 (FIG.
`3) and an infrastructure AP virtual interface 38 (FIG. 3).
`0053) The AP interface 38 in GC32A sets its BSSID the
`same way as the upstream AP 20. Any infrastructure STA,
`Such as STA 18A in FIG. 5, then communicates with the
`virtual AP interface 38 in the GC 32A. The GC 32A
`implements layer 3 forwarding 46 (FIG. 3) using conven
`tional routing protocols to forward the data from STA 18A
`to the virtual STA interface 36 that communicates with
`upstream AP 20. Thus, the wireless network in FIG. 5 is
`extended by allowing STA 18A to communicate with AP20
`through GC 32A.
`0054.
`In yet another example, STA 18A may be out of
`communication range for ad-hoc communication with STA
`18B or infrastructure communication with AP 20. The STA
`18A can still communicate with STA 18B in an infrastruc
`ture mode through an AP virtual interface 38 located in GC
`32A and/or GC32B. Thus, the overall range of the wireless
`network in FIG. 5 is extended over convention 802.11
`networks.
`0055. In FIG. 6, the infrastructure STA interface 36
`allows the GC 32 to appear as a standard infrastructure STA
`to “upstream” APs 20. Therefore, GC 32 does not impact the
`configuration or basic capabilities, and can work with,
`standard 802.11 APs 20. Similarly, the infrastructure AP
`interface 38 allows the GC 32 to appear as a standard
`infrastructure AP to “downstream” clients 18. Therefore, the
`GC 32 also does not impact the configuration or basic
`capabilities of conventional 802.11 clients or STAS 18. It
`should also be noted that the STA interface 36 and the AP
`interface 38 can operate Simultaneously using the same
`hardware interface 34.
`
`DELL
`EXHIBIT 1010 - PAGE 17
`
`

`

`US 2005/0174962 A1
`
`Aug. 11, 2005
`
`0056 FIG.7 describes in more detail how a WDS link 52
`is used as a meshing backbone. A layer 2 bridge network 42
`is created on one or more GCs 32 that allow a client to use
`the WDS link 52 as defined in the 802.11 standard for
`communication between infrastructure APS (acting as a
`virtualAP) and coordinate with a layer 3 routing protocol for
`routing across the layer-2 bridge.
`0057 The WDS link 52 is typically used as a layer 2
`forwarding architecture between AP's. It can also be used as
`a backbone for an IP routable mesh. However, in the generic
`client Scenario, the configured point-to-point links between
`two clients can be used for sending WDS frames. Forward
`ing of the frames to another AP can then be done at layer 2
`or layer 3. When layer 2 forwarding is used, static or
`dynamic bridging functionality 42 is used. Alternatively,
`layer 2 bridging may also be combined with layer 3 routing.
`0.058
`For example, the GC 32A may include a first
`virtual AP infrastructure interface 38A that communicates
`with the GC 32B over the wireless WDS link 52. Layer-2
`bridge or layer 3 router software 53 then routes the frames
`to another virtual AP interface 42 that communicates with
`the AP 20.
`0059 FIG. 8 shows how wireless neighbor discovery 55
`can be performed in the virtual network interfaces 54.
`Individual layer-2 logical interfaces 54 provide additional
`neighbor discovery 55 to a network layer (layer-3) router 56.
`Most ad hoc network protocols use a network layer (layer-3)
`neighbor discovery protocol. Layer-2 neighbor discovery 55
`is more efficient in a wireleSS network.
`0060. The 802.11 specification provides for link layer
`neighbor discovery 55. This is done via beacon frame
`broadcasts. The beacon frame contains the hardware (MAC)
`address of the sending network node that GCO uses to
`instantiate a network interface 54 for every neighbor node
`(GC1-GC3). This has the advantage of leveraging the under
`lying wireless link layer (layer-2) efficiencies. A Topology
`Broadcast based on Reverse-Path Forwarding (TBRPF)
`router 56 therefore only needs to be aware of the virtual
`point-to-point links 54.
`0061. Both the initial discovery and the on-going link
`maintenance (status) can be Supported with no layer 3
`overhead (additional messaging). AS any of neighbor GCS
`1, 2 or 3 come into range of GC 0 and move out of range,
`the link Status information is immediately translated into
`instantiation and removal of corresponding virtual interfaces
`54.
`FIG. 9 shows one way of envisioning the generic
`0.062
`client 32. Imagine two distinct clients 60 and 62 connected
`together via wired Ethernet interfaces 64. The infrastructure
`client 62 communicates with access points and the ad-hoc
`client 60 communicates point-to-point with other clients.
`Wireless interfaces 66 and 68 are not connected at layer 2
`and the messages (802.11 frames) are not forwarded directly
`from one interface to the other. There is no linkage between
`the two interfaces 66 and 68 at all. This is functionally
`equivalent to connecting the clients 60 and 62 via Ethernet
`through an IP router 70.
`0063 FIG. 10 shows one example of how the generic
`client 32 treats the infrastructure APS 20, the meshed ad-hoc
`clients 18B, and the standard infrastructure clients 18A as
`logically Separate Sub-networks accessible via distinct Vir
`
`tual interfaces 36, 38, and 40, respectively. This has the
`advantage of being able to use Standard upper layer tools for
`routing and forwarding decisions. For example, a conven
`tional IPlayer 2 and layer 3 forwarding and routing 74 can
`be used in addition to conventional neighbor discovery
`protocols such as TBRPF 76 and conventional TCP/UDP
`protocols 78. Any other conventional applications 80 cal
`also be implemented in the generic client 32.
`0064 Virtual Interface Mapping
`0065 FIG. 11 shows the functional operations in a
`generic client 32 that enable a wireleSS communication
`device to utilize a single physical interface card 80, Such as
`an 802.11 wireleSS transceiver, to Simultaneously commu
`nicate with peers in ad-hoc, infrastructure, WDS, and any
`other networkS.
`0.066 A single Network Interface Card (NIC) 80 has
`trouble communicating with distinct wireleSS networks,
`even if the networks operate on the same channel. This is
`because the infrastructure client, such (as a STA to AP),
`ad-hoc (as a STA to STA) and infrastructure AP (as an AP to
`STA) networks require distinct frame headers. In order to
`overcome this problem, the different wireless networks are
`represented as virtual network interfaces 36, 38, and 40,
`which are operating System abstractions.
`0067. A table 82 is used to keep track of the different
`wireleSS networks and to create a logical mapping between
`the wireless networks and the virtual interfaces 36, 38, and
`40. The table 82 contains the peer's network address 83 (the
`layer 2, or MAC address), the wireless network type 85 and
`peer type 87 (infrastructure client, infrastructure server
`(AP), ad-hoc client).
`0068. The NIC 80 receives a frame 84 from the air that
`includes a header 86 and a payload 88. The header 86 is
`examined by a table lookup operation 90 to determine the
`wireless network type 85 and peer type 87. The table lookup
`90 determines what type of virtual interface 36,38, or 40 to
`use for processing the frame 84 according to the information
`in the frame header 86. A frame from an infrastructure AP is
`sent to the infrastructure STA interface (I-STA) 36. A frame
`received from an infrastructure STA is sent to the infrastruc
`ture AP interface (I-AP) 38. A frame from an ad-hoc STA is
`sent to the ad-hoc STA interface (A-STA) 40.
`0069. In the 802.11 example, the table lookup determines
`what type of frame is received according to the To-DS and
`From-DS bits as described above in Table 1.0. For example,
`if the To-DS and the From-DS bits are both set to 0, then the
`table lookup 90 selects the ad-hoc STA interface 40. When
`the frame 84 is received with the To DS bit is set to 1 and
`the From DS bit set to 0, the table lookup uses the I-AP
`interface. When a frame 84 is received that has the To DS bit
`set to 0 and the From DS bit set to 1, the table lookup uses
`the I-STA interface 36. The frame header may then be
`Stripped off and the payload is forwarded via the appropriate
`interface 36, 38 or 40 via an upper layer routing operation.
`0070 The network address 83 associated with the frame
`is used to distinguish between different virtual interfaces 36,
`38, and 40 that may be operating at the same time. For
`example, there may be two I-AP interfaces 38 operating at
`the same time communicating with two different infrastruc
`ture STA's. The address in the frame is stored in network
`
`DELL
`EXHIBIT 1010 - PAGE 18
`
`

`

`US 2005/0174962 A1
`
`Aug. 11, 2005
`
`address 83 in table 82 to identify the particular virtual
`interface 38 associated with the wireless session.
`0071) The TX (transmit) logic works a differently. The
`Virtual network interface by itself provides the appropriate
`wireleSS network context So no table lookup is required.
`Because the operations conducted in the Virtual interfaces
`36, 38, and 40 are already known, they are not described in
`further detail.
`0072 Hardware Considerations
`0.073
`FIG. 12 shows the general architecture of a device
`100 providing the generic client 32 operations. An analog
`radio 34 is coupled to an antenna 96. A Digital Signal
`Processor (DSP) 92 is coupled to the radio 34 and a Central
`Processing Unit (CPU) 94. A media access controller
`(MAC) 98 may be a separate chip or may be integrated into
`the CPU 94.
`0074 The CPU 94 may operate the AP 20 in software.
`The generic client 32 may be operated by the CPU 94 and
`may be part of a Personal Computer (PC), Personal Digital
`Assistant (PDA), or laptop. With the generic client 32, the
`CPU 94 may also run the driver Software. The software
`which runs on the DSP 92 and the MAC chip is often called
`firmware. The firmware is usually written into non-volatile
`memory 102.
`0075 FIG. 13 shows on example of mobile devices that
`may serve as a platform for the generic client 32. Typically
`for 802.11 applications, the GC 32 is operating in Some sort
`of computing device 108, such as a PC, PDA, or laptop.
`However, for 802.11 or other types of wireless communi
`cation protocols, may operate the generic client 32 from
`other platforms such as a vehicle 110. The access point 20
`typically includes routing Software or a gateway for trans
`ferring data over a network, such as an Internet Protocol (IP)
`network 112.
`0.076 The GC can be incorporated into any current or
`emerging wireleSS technology including all current and
`future versions of IEEE 802.11 (also known as WiFi),
`Bluetooth, and other proprietary wireleSS protocols. The
`IEEE 802.11 WiFi specification is located at http://stan
`dards.ieee.org/getieee802/802.11.html and is herein incor
`porated by reference.
`0077. The system described above can use dedicated
`processor Systems, micro controllers, programmable logic
`devices, or microprocessors that perform Some or all of the
`operations. Some of the operations described above may be
`implemented in Software and other operations may be imple
`mented in hardware.
`0078 For the sake of convenience, the operations are
`described as various interconnected functional blocks or
`distinct Software modules. This is not necessary, however,
`and there may be cases where these functional blockS or
`modules are equivalently aggregated into a Single logic
`device, program or operation with unclear boundaries. In
`any event, the functional blocks and Software modules or
`features of the flexible interface can be implemented by
`themselves, or in combination with other operations in either