Patent Grant
7639656
This invention relates to wireless local area networks such as those following the protocols of IEEE Standard 802.11. In particular this invention relates to networks arranged to use wireless switches and access ports, such as the networks described in copending application Ser. No. 09/528,697, filed Mar. 17, 2000, the specification of which is incorporated herein by reference. It should be understood that the term “access port” as used in this application is the commercial name for the device referred to as an “RF Port” in the referenced copending application and the term “wireless switch” as used in this application is the commercial name for the device referred to as “Cell Controller” in the referenced copending application. The wireless switches of the present invention may also correspond to the cell controllers described in copending provisional application Ser. No. 60/473,755, filed May 28, 2003, the specification of which is incorporated herein by reference.
New technologies are currently evolving that make it desirable to support different communications protocols and different media using the wireless switches, to interface additional devices to the wired network containing the wireless switch by radio, fiber optics or serial data paths using other media, including wires.
It is an object of the present invention to provide a new and improved communications format that can accommodate multiple technologies in connection with communications between a wireless switch and an access port.
In accordance with the invention there is provided an improved method for configuring access ports in a wireless local area network, wherein a wireless switch controls the operation of one or more access ports and manages data communications with the one or more access ports, and wherein the access ports include one or more portals for communicating data to other devices. Software for operation of the access port is downloaded from the wireless switch. The access port sends data representing the identification of the one or more portals of the access port to the wireless switch. Data to configure the one or more portals of the access port is downloaded from the wireless switch to the access port.
In accordance with the invention there is provided an access port configured using the foregoing method.
In accordance with the invention there is provided an improved method for communicating in a wireless local area network, wherein a wireless switch controls the operation of one or more access ports and manages data communications with the access ports, and wherein at least one of the access ports includes an access port processor and a plurality of portals for communicating data to other devices. Separate network addresses corresponding to the access port processor and the portals are provided. Messages between the access port processor and the wireless switch are sent using a network address corresponding to the access port processor; and messages between the portals and the wireless switch are sent using network addresses assigned to the portals.
In a preferred embodiment sequence numbers are assigned to data messages between the access port and the wireless switch, wherein separate series of sequence numbers are assigned to each of the access port processor and the plurality of portals. The data messages may have an ethernet format, including a first ethernet header and a second header, wherein the ethernet header includes the network address and wherein the second header includes the sequence number. The second header may also include a message length field and/or a command field identifying message direction and message type. The second header may optionally include a code field indicating a command code for processing data in the message.
In accordance with the invention there is provided a wireless local area network arranged to operate using the method of the invention.
For a better understanding of the present invention, together with other and further objects, reference is made to the following description, taken in conjunction with the accompanying drawings, and its scope will be pointed out in the appended claims.
Throughout the figures, unless otherwise stated, the same reference numerals and characters are used to denote like features, elements, components, or portions of the illustrated embodiments.
As used in this specification the following terms have the following meanings:
Referring to
The present invention provides a protocol for communication between access ports 16, 18 and 20 and wireless switches 12, 13. The protocol includes two versions of some formats, a first version for communicating between a wireless switch 12, 13 and an access port 16 having a single portal. The second version of the protocol is for communicating between wireless switches 12, 13 and access ports 18, 20 having multiple portals. The two versions of the protocol format are compatibly used in the same system, and many of the formats for the two versions are identical.
The present invention further provides an arrangement for downloading runtime code from the wireless switches to the access ports. In the case of access ports having multiple portals, the present invention further provides an arrangement for configuring the portals of an access port.
In the case of multi-portal access ports, there are preferably multiple MAC addresses assigned to the access port. The first is the MAC address for the NIC card and the processor thereon. The remaining MAC addresses are preferably assigned to the portals of the access port. Generally, an operational access port will preferably have at least two MAC addresses, regardless of the number of portals.
All communication between the Wireless Switch and the Access Port processor or Portal within the Access Port uses WISP messages (WISP is an acronym for Wireless Switch Protocol). All fields are in big endian (network order) format. Within each field the highest order bit is shown to the left and the lowest order bit is shown to the right. The WISP message format is shown in Table 1.
The Ethernet Header portion of the message is the standard IEEE 802.3 header, consisting of the destination MAC address, the source MAC address, and the Ethertype. The Ethertype field may contain the proprietary Symbol Ethertype value of 0x8783 or other value. The Ethernet header is shown in Table 2. The WISP Header is shown in Table 3.
The command field is divided into sub-fields as shown in Table 4 below.
For messages that are sent to or from an Access Port, the direction sub-field is set to 0 if the message is sent from the Access Port and set to 1 if the message is sent to the Access Port. Type 3 messages are used for hardware diagnostics and may be specified by the device manufacturer.
The type sub-field values and meanings are listed in Table 5.
The initial set of command codes for the management messages is set forth in Table 6. The initial set of command codes for the wireless data messages is set forth in Table 7. The initial set of command codes for the flow control messages is set forth in Table 8. The initial set of command codes for the diagnostic messages is set forth in Table 9.
The sequence field is used for multiple purposes. There are also multiple sequence number streams for use in different types of WISP messages. Each stream starts with a value of 0 and increments by one for each successive message.
The Wireless Switch assigns sequence numbers as follows: for a given Access Port, there is one 16-bit sequence number stream used for all Management messages sent by the Wireless Switch (the same stream is used regardless of whether the Management messages are addressed to the Access Port or one of the portals within the Access Port). In addition, there are different 16-bit sequence number streams used to send immediate Wireless Data messages to each portal within an Access Port. Immediate Wireless Data messages are those that are sent by the Wireless Switch to the portal without delay (this includes all directed data as well as those multicast data frames that match the multicast mask). Another sequence number “stream” is used by the Wireless Switch to send bulk-delayed Wireless Data messages to a portal. Bulk-delayed messages are those non-directed Data frames that are stored in the Wireless Switch until the portal requests them via a DTIM Poll message (i.e. all broadcasts plus those multicasts that don't match the multicast mask). Each time the Wireless Switch sends bulk-delayed messages, they start with sequence number 0 and increment by one until all queued messages are transmitted to the portal that requested them. In response to the next DTIM Poll, whether it comes from the same portal or a different one, the sequence numbers in the bulk-delayed Wireless Data messages start at 0 again.
The Access Port assigns sequence numbers as follows: the boot code utilizes a single 16-bit sequence number stream for all messages it transmits. After a successful download, the Access Port processor uses a different 16-bit sequence number stream for all messages it transmits (this currently only includes DeviceInfo messages). Each portal within the Access Port uses its own 16-bit sequence number stream for every message it transmits, regardless of whether they are Management, Wireless Data, or Flow Control messages.
An Access Port with two portals would deal with the following sequence number streams:
During executable image downloading the sequence numbers provide a means of identifying each segment of the downloaded file by incrementing this value for each segment. This ensures that no frames are received out of sequence.
Sequence numbers are included in non-download management messages mainly to assist packet flow analysis and debug. Neither Wireless Switches nor portals are required to detect and/or reject non-download management messages that are received out of sequence.
During runtime the sequence numbers in immediate Wireless Data messages provide a means of flow control for 802.11 data frames sent from the Wireless Switch to a portal. The Wireless Switch and the portals use the Sequence field to reassemble any fragmented packets, as the sequence number will remain constant for each fragment of a Wireless Data message.
The following provides the details of Management message contents. Many of the messages follow a format that provides for the possibility of variable length fields. The general form of this format is:
During Access Port initialization, the Hello message is transmitted once per second until a Parent reply is received or upon the expiration of a predetermined period of time (e.g., 60 seconds). The Hello message format is shown in Table 10, and is used with the Parent message to provide a way for Wireless Switches to declare their intention to adopt an Access Port. The Hello message has no body.
The Parent message is sent from a Wireless Switch to an Access Port in response to a Hello message. The Parent message is used with the Hello message to provide a way for Wireless Switches to declare their intention to adopt an Access Port.
A Wireless Switch sends a Parent message in response to a Hello message if the Wireless Switch is configured to do so. The format for the Parent message is shown in Tables 11 and 12, the message body consists of the Wireless Switch MAC address.
In response to the Parent message, the Access Port sends a LoadMe message. The message content and format depends on the configuration of the Access Port. A first version of the LoadMe message, shown in Table 13 is utilized by the DSP-based Access Ports of the type described in co-pending application Ser. No. 09/528,697 and shown in
The LoadMe message is sent by an Access Port to request that an executable image be downloaded into the Access Port. When an Access Port powers on, it sends LoadMe messages at 1-second intervals for 10 seconds, if there is no response the Access port must reset.
Information in the LoadMe message body is used by the Wireless Switch to determine whether or not to adopt the Access Port. Information in the LoadMe message may also be presented to the user at the Wireless Switch user interface, depending on the design of the Wireless Switch.
The LoadMe frame body is made up of a series of Items. Each Item consists of a 1-byte ID field, a 1-byte length field, and a variable length data field. The length field is the total length in bytes of the data field. The length field is always an even number. If the true length of a variable length data field is an odd number, then a one byte pad (zero) is added to the end of the data to make the length an even number.
Item IDs 1 through 5, described in Table 14 below, must always be present in the LoadMe frame. This message may be extended when appropriate and other Items may be included as needed. The receiver of the LoadMe message must ignore all Items that it does not understand.
A second version of the LoadMe message, for use by advanced Access Ports, such as the multiple portal access ports shown in
The Wireless Switch responds to the LoadMe message with a LoadImage message, which downloads the operating code for the network interface card (NIC) of the access port. For the first version of the LoadMe message the LoadImage message is described in Table 17 and 18.
The Wireless Switch sends the first LoadImage in response to a LoadMe (if the Wireless Switch determines that it will adopt this Access Port).
When the Access Port responds to the LoadImage with a Ack that indicates the next sequence number, the Wireless Switch sends the next LoadImage message. When the Access Port responds to the LoadImage with a Nak, the Wireless Switch resends the last LoadImage message.
This continues until the entire image has been downloaded.
The last portion of the file is sent in the body of a LoadDone message. This indicates to the Access Port that it has received its entire runtime image.
In response to the second version of the Load Me message the Wireless switch sends the LoadImage message in the format specified in Tables 19 and 20. As with the first version, the image code may be sent in a number of fragments with the last fragment indicated to be a LoadDone message in the command code.
Acknowledgement messages are sent by the access port in response to each LoadImage or LoadDone message from the wireless switch to the access port that is successfully received. The first version Ack message is responsive to the first versions of the LoadImage and LoadDone messages and is set forth in Tables 21 and 22. The second version responsive to the second version of the LoadImage and LoadDone messages is set forth in Tables 23 and 24. The sequence number in the Ack is taken from the sequence field of the LoadImage or LoadDone packet header.
A Wireless Switch using the second version sends an Ack when a DeviceInfo packet is successfully processed. The sequence number in the Ack is taken from the sequence field of the DeviceInfo packet header. The format for the Ack message from the Wireless Switch to the Access Port is set forth in Tables 25 and 26.
Nak messages are sent under the same conditions as Ack messages when a prior message is not successfully received. The first version Nak message format is set forth in Tables 27 and 28. The second version Nak messages from the Access Port to the Wireless Switch are set forth in Tables 29 and 30. The Nak messages from the Wireless switch to the Access Port are set forth in Tables 31 and 32. In connection with Nak messages the sequence number is taken as the last successful sequence field incremented by one.
A LoadDone message is sent by the Wireless Switch to the Access Port with the last fragment of code of the LoadImage message. In connection with Access Ports using the first version the LoadDone message is defined by Tables 33 and 34. The second version of the LoadDone message is shown in Tables 35 and 36. The LoadDone message contains the last segment of image code followed by a 16-bit checksum.
An Access Port using the second version sends a DeviceInfo packet to report the combined capabilities of all its portals to the Wireless Switch. The DeviceInfo message is sent when the Access Port's runtime image is loaded and is executing correctly, but before its radios have been configured. The DeviceInfo message is broadcast so that all Wireless Switches may be aware of the Access Port's radio configuration.
If the Access Port received a Parent response from its Hello message, the Access Port expects an Ack of the DeviceInfo message from its Parent Wireless switch (i.e. from the MAC address indicated by the first Parent to reply to the Access Port's Hello message). If the Access Port does not see such an ACK within 10 seconds, it will reset and begin sending Hello messages.
If the Access Port did not receive a Parent response from its Hello message, the Access Port will send five DeviceInfo messages (once per second). It will then reset and begin sending Hello messages.
The Body of the DeviceInfo message is made up of a series of items. These items are not guaranteed to be in any particular order, although it is suggested that they be placed in numerical order according to the value of their ID fields.
The format for the DeviceInfo message is set forth in Tables 37 through 40.
Items Oxa, Oxb, Oxc, Oxd, and Oxe above may preferably be repeated (in order) for each portal on the device.
It is notable that the bits of Table 40 may have meaning only if the Access Port has the capability to detect the presence of the antenna. Thus, the Wireless Switch must preferably be aware of the Access Port's capability to detect antennas.
When the Access Port's runtime image is loaded following the second version of the protocol and the Access Port has successfully sent a DeviceInfo to the Wireless Switch, but the radio has not been configured, each portal of the Access Port sends the ConfigMe packet to report its capabilities to the Wireless Switch and to request its configuration. Until a radio has been configured, it sends a ConfigMe packet every 3 seconds for 9 seconds. After which it sends out a ConfigMe every 60 seconds until a response if received. When the Configuration Packet has been successfully received and processed by the radio, the ConfigMe is no longer sent. The radio then begins normal operation. The format of the ConfigMe message is set forth in Tables 41 and 42.
It is noted that the FH portal will preferably send out certain parameters already stored in FLASH configuration memory. Exemplary values are set forth in Table 42 and are Hop Set (values may be 1-3), Hop sequence (values may be 1-max number of channels/3), and hop dwell time (range 20-1000 in K-usec units).
The Wireless Switch may send a Configuration packet in response to the ConfigMe packet or whenever a change in configuration is required.
The Configuration message includes a header shown in Table 43 and is made up of a variable number of Items. The format of the possible Configuration Items is described in Tables 44 to 51. A Portal must ignore any configuration item that it does not recognize.
Configuration messages will generate a Status message if they are processed correctly. If the Access Port determines that the Configuration is erroneous, the Access Port shall reply to the Configuration with a Status message that indicates the error in the Configuration Error Type field.
The configuration sequence number is incremented by the Radio when all configuration processing is complete. The radio sends this value to the Wireless Switch in a Status packet to indicate that all changes specified have been successfully made. If the radio receives a Configuration packet with the previously seen sequence number the radio will ignore that packet.
The initial Configuration packet sent to a radio must contain all of the configuration information that is required for radio operation. If a field is absent, the radio will use a default value. Subsequent Configuration packets must contain Items that are to be changed, but may contain Items that have not changed.
Every 5 seconds, a configured Radio sends a Status message to the Wireless Switch to announce that it is still operational. Additional Status packets can be sent at any time as needed so that the Wireless Switch may recognize significant changes. Examples of significant changes are the auto channel scan feature completes, an 802.11a portal detects radar on its current channel, or an erroneous Configuration message is received as indicated by the Configuration Error Type field. When this occurs, the Configuration message that contained the error, is not effective.
The Status packet is also used to send statistical and status information to the Wireless Switch. These Items can be defined in the future.
The body of this message consists of a series of Items. Each Item consists of a 1-byte Item ID, a 1-byte length, and a variable length data field. The length field is the total length in bytes of the data field. The Status message format is shown in Tables 52, 53 and 54.
During normal operation, the selected channel item is the channel currently in use by the radio. The value 0xffff indicates that Auto Channel Scan is in progress. The value 0xfffe indicates that Auto Channel Scan has completed and the radio is waiting for a new configuration.
The Wireless Switch sends a Heartbeat message to each Radio each second to indicate to the Radio that the Wireless Switch is still operational, to keep the network time synchronized and to update load balance data
This load balance data becomes part of the Load Balance Element in the beacon and probe response RF packet. The requirement for the 1-second update time is to keep the network time synchronized. The Heartbeat message format is shown in Tables 55 and 56.
The purpose of UpdateTIM packet is to update the Partial Virtual Bitmap field of the beacon for a Radio and to update the bitmap offset of the bitmap control field. The rest of the fields in TIM element are filled in by the Radio.
The TIM map is compiled by the Wireless Switch based on the traffic currently stored for each PSP MU that is associated through this radio (if any). The length field of the fragment control header indicates the total length of the element.
Format for the UpdateTIM message is shown in Tables 57 and 58. The first byte of the body in the packet will indicate the bitmap offset for bitmap control. The rest is the Partial Virtual Bitmap to be part of each beacon.
The purpose of Reset packet is to reset the Access Port. It may be directed to either the Access Port NIC MAC address or to a Portal MAC address. When directed to the Access Port NIC MAC address, the Reset packet has the same effect as toggling power at the Access Port—the Access Port will revert back to its initialization procedure.
When directed to a Portal MAC address, the Portal will revert to the ConfigMe stage, sending ConfigMe messages until a Configuration is received from the Portal's Parent Wireless Switch. Portals other the destination portal shall not change their operating state. The header for the Reset message is shown in Table 59. This message has no body.
In the following discussion the term “radio” is used to refer to a Portal (radio or other entity) that resides within an Access Port, even in the case where the Access Port only consists of one radio and the same MAC address is used for both Access Port and radio.
Each message to be sent to a radio by a Wireless Switch is sent encapsulated in one or more Wireless Data Packets. Each time the Wireless Switch creates a Wireless Data Packet—without fragments—in which to encapsulate a message, it increments the value of the sequence field in that Wireless Data Packet by 1. If the message must be fragmented, the sequence number is the same value for each fragment of the message. The radio remembers the value of the sequence field in the last of the Wireless Data Packets that contained each frame to be transmitted. The sequence numbering is independent for each radio within an Access Port. As soon as possible after the radio forwards a frame that it received from a Wireless Switch, it reports the value of the sequence field that was in the Wireless Data Packet that originally contained that frame back to the Wireless Switch in the Results1 or Results2 fields as described below.
There are two methods that a radio can use to report to the Wireless Switch the sequence fields of frames most recently forwarded. Both methods involve filling in the Tx Results fields of a message that is sent to the Wireless Switch. The first method is to fill in the Tx Results1 and Tx Results2 fields in a Wireless Data Packet that contains a message received by the radio and destined for the Wireless Switch. The second method is to create an UpdateResults message, fill in one or more Tx Results fields as necessary, and send it to the Wireless Switch. The only purpose of this message is to report the results fields to the Wireless Switch. Each radio must implement a mechanism to report the results of forwarded messages to the Wireless Switch as quickly as possible.
When a fragmented message received by the Access Port from the Wireless Switch has been successfully transmitted by the Access Port, the successful result is indicated as described above. In this case, just one Results indication is sent from the Access Port to the Wireless switch—even though the Access Port received two frames (two fragments) for the message.
The format for a wireless data message from the access port to the wireless switch is set forth in Table 60 and 61. When the access port is configured using the first version of the protocol and having only one access port, the Radio MAC address is the address of the Access Port NIC.
The format for the TxResults 1 and TxResults 2 fields is set forth in Table 62.
When the radio has received a message that is to be forwarded to the Wireless Switch, it fills in the TxResults1 and TxResults2 fields of the frames that contain the encapsulated message as follows, depending on what has or has not already been reported to the Wireless Switch:
If all data sent by the Wireless Switch to the radio to be forwarded has been forwarded and the results have been reported to the Wireless Switch, both fields are set to zero.
If only 1 message sent from the Wireless Switch has been forwarded and not reported, the TxResults1 field is filled in with information regarding the last (or only) fragment of that message and TxResults2 is set to 0.
If more than 1 message sent from the Wireless Switch has been forwarded and not reported, the TxResults1 is filled in with information regarding of the oldest unreported message and the TxResults2 field is filled in with information regarding of the next oldest unreported message.
A portal can report lost frames by setting the “ok” subfield equal to 3, the “seq” subfield to the sequence number that was lost, and setting the rest of the subfields to 0.
If the Access Port has forwarding results ready to report, but there are no received frames waiting to be sent to the Wireless Switch, the radio will create and send UpdateResults messages to the Wireless Switch soon after the transmit results are known to the Access Port. The TxResults1 and TxResults2 fields are filled in as described above. How long a portal hangs on to unreported results before creating and sending an UpdateResults message is implementation dependent, but in general this time should be minimized.
The results reported to the Wireless Switch may not be in sequence. Each radio is free to transmit Data frames in whatever order it deems most efficient, but transmit results must be sent back to the Wireless Switch in the same order as the results become known to the radio.
The Rx Data field is filled in the body of the Wireless Data Packet that contains the last fragment of that message using the format of Table 63. The RSSI sub-field contains the relative signal strength with which the message was received (if the Portal is a radio), as reported by the supporting hardware. The rate sub-field contains the encoded data rate of the received message (if the Portal is a radio). Encoding of the data rate is shown in Table 64 below. The format for the channel field is shown in Table 65.
The format for the header field and body of a data message from the wireless switch to a radio is shown in Table 66 and 67.
The bit map values for any transmit rate, including the Allowed Rates field in Table 67, is shown below in Table 68. The top row is the bit number. The bottom row is the data rate in megabits per second.
The Transmit Control field is set forth in Table 69. The priority field is intended to allow flexibility in support of Quality of Service mechanisms. Where such mechanisms are not in place the field is set to zero.
The group field specifies the priority group to which this message belongs.
The relationship between Priority Group and Priority is as follows: Each priority group may be sub-divided into up to 16 priorities. Any message in one priority group has priority over any message in a lower-numbered priority group, regardless of the value of their respective priority fields.
The profile field specifies a retry algorithm. More specifically, the RF Port uses this value to determine the following information for each transmission:
The retry algorithm to be used is not specified by the protocol. Instead, it is up to the implementation to define the appropriate transmit profile for each of the five profile types.
Flow control allows for the efficient movement of data from a Wireless Switch to a portal. It also ensures that data will not be sent to a portal that doesn't have room for it. There are two distinct types of data that flow control applies to: immediate and bulk-delayed. Each type is handled with a different method of flow control.
Immediate Wireless Data messages are flow-controlled via the Sequence fields in their headers, and the Flow Control Window field in the bodies of upstream (i.e. from portal to Wireless Switch) Wireless Data, UpdateResults, and DTIMPoll messages. The Flow Control Window field allows a portal to advertise to the Wireless Switch how much room it has left to accept additional Wireless Data messages. This room is expressed in terms of a “window” of sequence numbers, where the Flow Control Window value is the last sequence number that can be accepted. As a portal transmits data via RF, it frees up additional buffer space and subsequently advertises a new window in the next Wireless Data, UpdateResults, or DTIMPoll message it transmits. The advertised window will always be either equal to or larger than the last advertised window (excluding the 16-bit wraparound case).
Bulk-delayed Wireless Data messages are flow-controlled via the DTIMPoll message. This message is sent prior to an imminent DTIM time, and signals the Wireless Switch to send all buffered non-directed data to the portal that requested it, up to the limit specified within the DTIMPoll message. The sequence numbering for bulk-delayed Wireless Data messages is separate from immediate Wireless Data messages, and each portal must maintain a separate memory area for each data type. Receipt of (and subsequent RF transmission of) bulk-delayed Wireless Data messages have NO impact on the value of the Flow Control Window field.
The UpdateResults message is sent to the Wireless Switch by a Radio when information is available regarding the status of one or more completed data forward (transmit) operation(s) and no data that has been received is pending to be sent to the Wireless Switch. The Tx Results fields are filled in as described above. The TxResults 1 and TxResults 2 fields are always included in this message, even if there is only one result to report (in that case, the Tx Results2 field would be invalid). Additional TxResults can be appended to this message as necessary.
This message also serves to update the Wireless Switch with the latest flow control information. The format for the UpdateResults message is set forth in Tables 70 and 71.
The radio sends theDTIM_Poll message to the Wireless Switch to request that any stored (buffered) broadcast or multicast messages be sent. The amount of time between the DTIM_Poll and DTIM time is implementation dependant. When the DTIM time occurs, the radio will transmit any broadcast or multicast messages that it has received since the last DTIM.
This message also serves to update the Wireless Switch with the number of currently available transmit buffers (non-DSP) for this radio.
This message can be used to send any previously unreported TxResults to the Wireless Switch. Zero, one, or two valid TxResults may be included, but the TxResults 1 and TxResults 2 field are always present even if they don't contain valid data. The format for the DTIM_POLL message is set forth in Tables 72 and 73.
The process by which an Access Port becomes associated with (or adopted by) a Wireless Switch is called the Access Port Adoption Process (APAP). Some WISP messages are used only during this Adoption Process.
The following illustrates the possible normal initialization message sequences between a Wireless Switch and an Access Port.
The first section describes a normal successful download between the Wireless Switch and a multi-portal access port. The second section describes the message exchanges between a multi-portal access port and the Wireless Switch when no Wireless Switches are configured to adopt the port. The third section describes the message exchanges between a DSP based Access Port, as shown in
The following table summarizes message exchanges when the Access Port begins the sequence with a Hello message and at least one Wireless Switch is configured to adopt the Access Port.
The following summarizes message exchanges when NO Wireless Switches are configured to adopt the Access Port.
The following summarizes message exchanges when an Access Port begins the initialization sequence with a LoadMe message rather than a Hello message.
After each portal is configured, it begins normal operation. During normal operation with no traffic, the Wireless Switch sends a “Heartbeat” message to each portal once per second. The portal sends a “status” message to the Wireless Switch every 5 s.
If any portal misses the Heartbeat for 10 s, the Access Port resets and starts again at phase 1.
During normal operation, if an 802.11a radio detects radar, transmission on the current channel will cease. The 802.11a portal will send a Status message with a “radar detect” indication. At this point, normal forwarding operations will cease. The Access Port will remain in this state (as if no Active ESS's are defined) until another Configuration message is received from the Wireless Switch. The next Configuration message will determine the next action taken by the Access Port. The next Configuration message may indicate that the Access Port shall perform ACS (described below). The Configuration message may simply indicate which channel to use. In this case, the Access Port shall continue normal operation on the channel indicated in the Configuration message.
The Switch may direct the Access Port to perform ACS at any time. The following steps are involved in the ACS process:
The Switch sends a Configuration message to Access Port with the Automatic Channel Scan bit set. The ACS bit is in the Option Mask field (Element ID 0x2E) of the Configuration message. When this message is received by the Access Port, all normal forwarding operations will cease. This will be operationally identical to having no Active ESS. The Heartbeat and Status message exchanges will continue during ACS.
In the same Configuration message, the Allowed Channels Field (0x2F) will define the list of channels (one or more) to use in the process.
When the Access Port begins the process, the Access Port will send a Status message to the Wireless Switch with the Auto Channel scan field (0×50) set to 0xffff.
The Access Port will start with the first channel indicated in the Allowed Channels Field (0x2F), and sequentially process each channel as follows:
Several messages sent by the Access Port have timeouts, repeat intervals, and differing behaviors depending on whether they timeout or receive the expected response. The following is a summary. A Reset returns the Access Port to the Access port Adoption Process.
The sequence number field in the Wireless Data Packet is used to detect packets that have gotten out of order due to possible differing paths through the switch fabric between a Wireless Switch and a Radio. Each entity (Wireless Switch and Radio) must keep track of the sequence number of the last Wireless Data Packet that it received. If it receives a Wireless Data Packet with a sequence number that is lower than the last it received, it must discard that packet. Care must be taken to ensure that this mechanism works through wrap-around of the sequence number back to zero.
While there have been described what are believed to be the preferred embodiments of the present invention, those skilled in the art will recognize that other and further changes and modifications may be made thereto without departing from the spirit of the invention, and it is intended to claim all such changes and modifications as falls in the scope of the invention.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5546397 | Mahany | Aug 1996 | A |
| 6741853 | Jiang et al. | May 2004 | B1 |
| 6873611 | Rios | Mar 2005 | B2 |
| 7010300 | Jones et al. | Mar 2006 | B1 |
| 7027425 | Fullerton et al. | Apr 2006 | B1 |
| 7142099 | Ross et al. | Nov 2006 | B2 |
| 7155518 | Forslow | Dec 2006 | B2 |
| 7321578 | Rios | Jan 2008 | B2 |
| 7414995 | Melkote et al. | Aug 2008 | B1 |
| 20010012296 | Burgess et al. | Aug 2001 | A1 |
| 20030007464 | Balani | Jan 2003 | A1 |
| 20030031160 | Gibson Ang et al. | Feb 2003 | A1 |
| 20030177267 | Orava et al. | Sep 2003 | A1 |
| 20030212821 | Gillies et al. | Nov 2003 | A1 |
| 20040029525 | Vertelney | Feb 2004 | A1 |
| 20040044454 | Ross et al. | Mar 2004 | A1 |
| 20040047320 | Eglin | Mar 2004 | A1 |
| 20040235468 | Luebke et al. | Nov 2004 | A1 |
| 20050030160 | Goren et al. | Feb 2005 | A1 |
| 20050058111 | Hung et al. | Mar 2005 | A1 |
| 20050059396 | Chuah et al. | Mar 2005 | A1 |
| 20050102529 | Buddhikot et al. | May 2005 | A1 |
| 20050124359 | Willins et al. | Jun 2005 | A1 |
| 20050223111 | Bhandaru et al. | Oct 2005 | A1 |
| 20050243737 | Dooley et al. | Nov 2005 | A1 |
| 20060155803 | Muramatsu et al. | Jul 2006 | A1 |
| 20070118389 | Shipon | May 2007 | A1 |
| Number | Date | Country | |
|---|---|---|---|
| 20050243737 A1 | Nov 2005 | US |
