Access point and method for instructing link resumption of a station in a power saving mode

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. patent application Ser. No. 16/378,065, filed Apr. 8, 2019, which is a continuation of U.S. patent application Ser. No. 15/948,902, filed on Apr. 9, 2018 which issued as U.S. Pat. No. 10,257,868 on Apr. 9, 2019, which is a continuation of U.S. patent application Ser. No. 15/651,744 filed on Jul. 17, 2017, which issued as U.S. Pat. No. 9,942,927 on Apr. 10, 2018, which is a continuation of Ser. No. 15/362,305 filed on Nov. 28, 2016, which issued on Jul. 18, 2017 as U.S. Pat. No. 9,713,181, which is a continuation of U.S. patent application Ser. No. 14/942,127 filed on Nov. 16, 2015, which issued on Nov. 29, 2016 as U.S. Pat. No. 9,510,375, which claims the benefit of U.S. patent application Ser. No. 13/738,589 filed on Jan. 10, 2013, which issued on Dec. 1, 2015 as U.S. Pat. No. 9,204,473, which claims the benefit of U.S. Provisional Application Ser. No. 61/585,420 filed on Jan. 11, 2012 and U.S. Provisional Application Ser. No. 61/719,663 filed on Oct. 29, 2012, the contents of each of which are hereby incorporated by reference.

BACKGROUND

A link setup procedure may be configured in an Institute of Electrical and Electronics Engineers (IEEE) 802.11 communications system to include a number of phases. An example link setup process may include an access point (AP) discovery phase, a network discovery phase, an additional time sync function (TSF) phase, an authentication and association phase, and a higher layer internet protocol (IP) setup phase. Such a link setup procedure may take up to a few seconds or more to complete.

SUMMARY

A method and apparatus may be configured to perform accelerated link setup. A method may include a station (STA) acquiring information about an AP of an IEEE 802.11 network in advance through a previously connected IEEE 802.11 interface and/or an interface other than the IEEE 802.11 network. The STA may use the acquired information during a link setup procedure between the STA and the AP. The information may include a suggestion for a specific procedure to complete the link setup procedure between the STA and the AP.

A method and apparatus may be used to pre-establish a security association between a STA and a network to enable and optimize discovery of another network. For example, a fast-EAP may be encapsulated into an 802.11 frame, such as, for example, an authentication frame or an association frame. The authentication procedure performed on the new network may be non-EAP based.

An apparatus may transmit a request for network discovery information from a network entity and receive network discovery information in response. The network discovery information may be received over a cellular network, for example, a 3GPP network. The network discovery information may be received via a Layer 2 protocol.

An apparatus may transmit a request to obtain an IP address configuration from a network. For example, the apparatus may request and receive an IP address configuration during an EAP authentication process or during a non-EAP authentication process. The IP address configuration may be received over a cellular network, for example, a 3GPP network.

A method for performing active scanning by a non-AP STA may comprise transmitting, to a group of APs, one or more probe request frames and receiving in response, configuration chance count (CCC) values from first and second APs of the group of APs. The CCC values may be integer values that represent configuration instances of the respective APs. The CCC values may be stored in a memory of the non-AP STA. A determination may be made, based on the information stored in the memory, as to which AP is preferred. An association procedure may be performed with the preferred AP. Other disclosed methods employ passive scanning.

A power saving method performed by a STA may comprise receiving, from an AP, a first beacon comprising a CCC value. The CCC value may be an integer value that represents a configuration instance of the AP. The STA may return from a power saving mode upon receiving the first beacon and receive a second beacon from the AP. The second beacon may be a primary beacon of the AP. The first beacon may comprise an SSID of the AP. The STA may perform an association procedure with the AP upon receiving the first beacon.

A method performed by a STA may comprise transmitting a first access network query protocol (ANQP) message to an AP and receiving a second ANQP message in response. The second ANQP message may comprise a CCC value representing a configuration instance of the AP which is incremented by one upon a configuration change. The CCC value may wrap around once a maximum value is reached. The first ANQP message may comprise the CCC value or may comprise another CCC value which is different than the CCC value.

A method performed by an AP may comprise initializing a CCC and increasing the CCC upon a change of at least one of a plurality of parameters of the AP. The plurality of parameters may include at least a high throughput (HT) Operation element, one or more Enhanced Distributed Channel Access (EDCA) parameters, or one or more operational mode parameters. The method may further comprise transmitting a frame, to at least one STA, wherein the frame includes an indication of the CCC, and the frame indicates that the at least one STA return from a power saving mode.

BRIEF DESCRIPTION OF THE DRAWINGS

A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings wherein:

<figref idref="DRAWINGS">FIG. 1A</figref> is a system diagram of an example communications system in which one or more disclosed embodiments may be implemented;

<figref idref="DRAWINGS">FIG. 1B</figref> is a system diagram of an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in <figref idref="DRAWINGS">FIG. 1A</figref>;

<figref idref="DRAWINGS">FIG. 1C</figref> is a system diagram of an example radio access network and an example core network that may be used within the communications system illustrated in <figref idref="DRAWINGS">FIG. 1A</figref>;

<figref idref="DRAWINGS">FIG. 2A</figref> is a diagram of an example IEEE 802.11 setup procedure;

<figref idref="DRAWINGS">FIG. 2B</figref> is a continuation of the example IEEE 802.11 setup procedure shown in <figref idref="DRAWINGS">FIG. 2A</figref>;

<figref idref="DRAWINGS">FIG. 3</figref> is a flow chart of a baseline procedure for accelerated link setup (ALS) using pre-acquired information;

<figref idref="DRAWINGS">FIG. 4</figref> is a diagram of an example short beacon frame supporting accelerated link setup (ALS);

<figref idref="DRAWINGS">FIG. 5</figref> is a diagram of an example modification to a primary beacon frame supporting ALS;

<figref idref="DRAWINGS">FIG. 6</figref> is a diagram of an example fast initial link setup (FILS) management action frame;

<figref idref="DRAWINGS">FIG. 7</figref> is a diagram of an example of an optimized access point (AP) discovery procedure initiated by a STA based on pre-acquired knowledge;

<figref idref="DRAWINGS">FIG. 8</figref> is a diagram of an example of an optimized AP discovery procedure initiated by an AP based on pre-acquired information;

<figref idref="DRAWINGS">FIG. 9</figref> is a diagram of an example method in which an authentication, authorization, and accounting (AAA) server may integrate Identity Provider (OP) and enhanced access network discovery and selection function (eANDSF) functionalities to enable seamless authentication and fast link setup;

<figref idref="DRAWINGS">FIG. 10</figref> is a diagram of another example method in which an authentication, authorization and accounting (AAA) server may integrate OP and enhanced access network discovery and selection function (eANDSF) functionalities to enable seamless authentication and fast link setup;

<figref idref="DRAWINGS">FIG. 11</figref> is a diagram of an example method in which an AAA server may integrate OP functionality to enable seamless authentication and fast link setup;

<figref idref="DRAWINGS">FIG. 12</figref> is a diagram of another example method in which an AAA server may integrate OP functionality to enable seamless authentication and fast link setup;

<figref idref="DRAWINGS">FIG. 13</figref> is a diagram of an example method for a pre-established security association between a STA and a network to enable seamless authentication and fast initial link setup;

<figref idref="DRAWINGS">FIG. 14</figref> is a diagram of another example method for a pre-established security association between a STA and a network to enable seamless authentication and fast initial link setup;

<figref idref="DRAWINGS">FIG. 15</figref> is a diagram of another example method for a pre-established security association between a STA and a network to enable seamless authentication and fast initial link setup;

<figref idref="DRAWINGS">FIG. 16</figref> is a diagram of an example method for supporting the use of pre-defined system parameter sets;

<figref idref="DRAWINGS">FIG. 17</figref> is a diagram of another example method for supporting the use of pre-defined system parameter sets;

<figref idref="DRAWINGS">FIG. 18</figref> is a diagram of another example method for supporting the use of pre-defined system parameter sets;

<figref idref="DRAWINGS">FIG. 19</figref> is a diagram of an example method where a STA may receive configuration instance identifier information without full configuration instance information;

<figref idref="DRAWINGS">FIG. 20</figref> is a diagram of an example method where a STA may include configuration instance identifier information for pre-acquired system configurations;

<figref idref="DRAWINGS">FIG. 21</figref> is a diagram of an example method for performing fast link setup with location-based pre-acquired knowledge; and

<figref idref="DRAWINGS">FIG. 22</figref> is a diagram of an example method for link setup optimization.

DETAILED DESCRIPTION

<figref idref="DRAWINGS">FIG. 1A</figref> is a diagram of an example communications system <b>100</b> in which one or more disclosed embodiments may be implemented. The communications system <b>100</b> may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system <b>100</b> may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems <b>100</b> may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), and the like.

As shown in <figref idref="DRAWINGS">FIG. 1A</figref>, the communications system <b>100</b> may include wireless transmit/receive units (WTRUs) <b>102</b><i>a, </i><b>102</b><i>b, </i><b>102</b><i>c, </i><b>102</b><i>d, </i>a radio access network (RAN) <b>104</b>, a core network <b>106</b>, a public switched telephone network (PSTN) <b>108</b>, the Internet <b>110</b>, and other networks <b>112</b>, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs <b>102</b><i>a, </i><b>102</b><i>b, </i><b>102</b><i>c, </i><b>102</b><i>d </i>may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs <b>102</b><i>a, </i><b>102</b><i>b, </i><b>102</b><i>c, </i><b>102</b><i>d </i>may be configured to transmit and/or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, consumer electronics, a station (STA) in an IEEE 802.11 network, and the like.

The communications systems <b>100</b> may also include a base station <b>114</b><i>a </i>and a base station <b>114</b><i>b. </i>Each of the base stations <b>114</b><i>a, </i><b>114</b><i>b </i>may be any type of device configured to wirelessly interface with at least one of the WTRUs <b>102</b><i>a, </i><b>102</b><i>b, </i><b>102</b><i>c, </i><b>102</b><i>d </i>to facilitate access to one or more communication networks, such as the core network <b>106</b>, the Internet <b>110</b>, and/or the networks <b>112</b>. By way of example, the base stations <b>114</b><i>a, </i><b>114</b><i>b </i>may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. While the base stations <b>114</b><i>a, </i><b>114</b><i>b </i>are each depicted as a single element, it will be appreciated that the base stations <b>114</b><i>a, </i><b>114</b><i>b </i>may include any number of interconnected base stations and/or network elements.

The base station <b>114</b><i>a </i>may be part of the RAN <b>104</b>, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station <b>114</b><i>a </i>and/or the base station <b>114</b><i>b </i>may be configured to transmit and/or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into cell sectors. For example, the cell associated with the base station <b>114</b><i>a </i>may be divided into three sectors. Thus, in one embodiment, the base station <b>114</b><i>a </i>may include three transceivers, i.e., one for each sector of the cell. In another embodiment, the base station <b>114</b><i>a </i>may employ multiple-input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.

The base stations <b>114</b><i>a, </i><b>114</b><i>b </i>may communicate with one or more of the WTRUs <b>102</b><i>a, </i><b>102</b><i>b, </i><b>102</b><i>c, </i><b>102</b><i>d </i>over an air interface <b>116</b>, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface <b>116</b> may be established using any suitable radio access technology (RAT).

More specifically, as noted above, the communications system <b>100</b> may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station <b>114</b><i>a </i>in the RAN <b>104</b> and the WTRUs <b>102</b><i>a, </i><b>102</b><i>b, </i><b>102</b><i>c </i>may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface <b>116</b> using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA).

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

In other embodiments, the base station <b>114</b><i>a </i>and the WTRUs <b>102</b><i>a, </i><b>102</b><i>b, </i><b>102</b><i>c </i>may implement radio technologies such as IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1x, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

The base station <b>114</b><i>b </i>in <figref idref="DRAWINGS">FIG. 1A</figref> may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, and the like. In one embodiment, the base station <b>114</b><i>b </i>and the WTRUs <b>102</b><i>c, </i><b>102</b><i>d </i>may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, the base station <b>114</b><i>b </i>and the WTRUs <b>102</b><i>c, </i><b>102</b><i>d </i>may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station <b>114</b><i>b </i>and the WTRUs <b>102</b><i>c, </i><b>102</b><i>d </i>may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell. As shown in <figref idref="DRAWINGS">FIG. 1A</figref>, the base station <b>114</b><i>b </i>may have a direct connection to the Internet <b>110</b>. Thus, the base station <b>114</b><i>b </i>may not be required to access the Internet <b>110</b> via the core network <b>106</b>.

The RAN <b>104</b> may be in communication with the core network <b>106</b>, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs <b>102</b><i>a, </i><b>102</b><i>b, </i><b>102</b><i>c, </i><b>102</b><i>d. </i>For example, the core network <b>106</b> may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication. Although not shown in <figref idref="DRAWINGS">FIG. 1A</figref>, it will be appreciated that the RAN <b>104</b> and/or the core network <b>106</b> may be in direct or indirect communication with other RANs that employ the same RAT as the RAN <b>104</b> or a different RAT. For example, in addition to being connected to the RAN <b>104</b>, which may be utilizing an E-UTRA radio technology, the core network <b>106</b> may also be in communication with another RAN (not shown) employing a GSM radio technology.

The core network <b>106</b> may also serve as a gateway for the WTRUs <b>102</b><i>a, </i><b>102</b><i>b, </i><b>102</b><i>c, </i><b>102</b><i>d </i>to access the PSTN <b>108</b>, the Internet <b>110</b>, and/or other networks <b>112</b>. The PSTN <b>108</b> may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet <b>110</b> may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP/IP internet protocol suite. The networks <b>112</b> may include wired or wireless communications networks owned and/or operated by other service providers. For example, the networks <b>112</b> may include another core network connected to one or more RANs, which may employ the same RAT as the RAN <b>104</b> or a different RAT.

Some or all of the WTRUs <b>102</b><i>a, </i><b>102</b><i>b, </i><b>102</b><i>c, </i><b>102</b><i>d </i>in the communications system <b>100</b> may include multi-mode capabilities, i.e., the WTRUs <b>102</b><i>a, </i><b>102</b><i>b, </i><b>102</b><i>c, </i><b>102</b><i>d </i>may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU <b>102</b><i>c </i>shown in <figref idref="DRAWINGS">FIG. 1A</figref> may be configured to communicate with the base station <b>114</b><i>a, </i>which may employ a cellular-based radio technology, and with the base station <b>114</b><i>b, </i>which may employ an IEEE 802 radio technology. A WTRU may be referred to as a station (STA) or a non-access point (non-AP) STA.

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

The processor <b>118</b> may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor <b>118</b> may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU <b>102</b> to operate in a wireless environment. The processor <b>118</b> may be coupled to the transceiver <b>120</b>, which may be coupled to the transmit/receive element <b>122</b>. While <figref idref="DRAWINGS">FIG. 1B</figref> depicts the processor <b>118</b> and the transceiver <b>120</b> as separate components, it will be appreciated that the processor <b>118</b> and the transceiver <b>120</b> may be integrated together in an electronic package or chip.

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

In addition, although the transmit/receive element <b>122</b> is depicted in <figref idref="DRAWINGS">FIG. 1B</figref> as a single element, the WTRU <b>102</b> may include any number of transmit/receive elements <b>122</b>. More specifically, the WTRU <b>102</b> may employ MIMO technology. Thus, in one embodiment, the WTRU <b>102</b> may include two or more transmit/receive elements <b>122</b> (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface <b>116</b>.

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

The processor <b>118</b> of the WTRU <b>102</b> may be coupled to, and may receive user input data from, the speaker/microphone <b>124</b>, the keypad <b>126</b>, and/or the display/touchpad <b>128</b> (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor <b>118</b> may also output user data to the speaker/microphone <b>124</b>, the keypad <b>126</b>, and/or the display/touchpad <b>128</b>. In addition, the processor <b>118</b> may access information from, and store data in, any type of suitable memory, such as the non-removable memory <b>130</b> and/or the removable memory <b>132</b>. The non-removable memory <b>130</b> may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory <b>132</b> may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor <b>118</b> may access information from, and store data in, memory that is not physically located on the WTRU <b>102</b>, such as on a server or a home computer (not shown).

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

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

The processor <b>118</b> may further be coupled to other peripherals <b>138</b>, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals <b>138</b> may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

<figref idref="DRAWINGS">FIG. 1C</figref> is an example system diagram of the RAN <b>104</b> and the core network <b>106</b>. As noted above, the RAN <b>104</b> may employ an E-UTRA radio technology to communicate with the WTRUs <b>102</b><i>a, </i><b>102</b><i>b, </i><b>102</b><i>c </i>over the air interface <b>116</b>. The RAN <b>104</b> may also be in communication with the core network <b>106</b>.

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

Each of the eNode-Bs <b>140</b><i>a, </i><b>140</b><i>b, </i><b>140</b><i>c </i>may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and/or downlink, and the like. As shown in <figref idref="DRAWINGS">FIG. 10</figref>, the eNode-Bs <b>140</b><i>a, </i><b>140</b><i>b, </i><b>140</b><i>c </i>may communicate with one another over an X2 interface.

The core network <b>106</b> shown in <figref idref="DRAWINGS">FIG. 1C</figref> may include a mobility management gateway (MME) <b>142</b>, a serving gateway <b>144</b>, and a packet data network (PDN) gateway <b>146</b>. While each of the foregoing elements are depicted as part of the core network <b>106</b>, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

The MME <b>142</b> may be connected to each of the eNode-Bs <b>142</b><i>a, </i><b>142</b><i>b, </i><b>142</b><i>c </i>in the RAN <b>104</b> via an S1 interface and may serve as a control node. For example, the MME <b>142</b> may be responsible for authenticating users of the WTRUs <b>102</b><i>a, </i><b>102</b><i>b, </i><b>102</b><i>c, </i>bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs <b>102</b><i>a, </i><b>102</b><i>b, </i><b>102</b><i>c, </i>and the like. The MME <b>142</b> may also provide a control plane function for switching between the RAN <b>104</b> and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

The serving gateway <b>144</b> may be connected to each of the eNode Bs <b>140</b><i>a, </i><b>140</b><i>b, </i><b>140</b><i>c </i>in the RAN <b>104</b> via the S1 interface. The serving gateway <b>144</b> may generally route and forward user data packets to/from the WTRUs <b>102</b><i>a, </i><b>102</b><i>b, </i><b>102</b><i>c. </i>The serving gateway <b>144</b> may also perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs <b>102</b><i>a, </i><b>102</b><i>b, </i><b>102</b><i>c, </i>managing and storing contexts of the WTRUs <b>102</b><i>a, </i><b>102</b><i>b, </i><b>102</b><i>c, </i>and the like.

The serving gateway <b>144</b> may also be connected to the PDN gateway <b>146</b>, which may provide the WTRUs <b>102</b><i>a, </i><b>102</b><i>b, </i><b>102</b><i>c </i>with access to packet-switched networks, such as the Internet <b>110</b>, to facilitate communications between the WTRUs <b>102</b><i>a, </i><b>102</b><i>b, </i><b>102</b><i>c </i>and IP-enabled devices. An access router (AR) <b>150</b> of a wireless local area network (WLAN) <b>155</b> may be in communication with the Internet <b>110</b>. The AR <b>150</b> may facilitate communications between APs <b>160</b><i>a, </i><b>160</b><i>b, </i>and <b>160</b><i>c. </i>The APs <b>160</b><i>a, </i><b>160</b><i>b, </i>and <b>160</b><i>c </i>may be in communication with STAs <b>170</b><i>a, </i><b>170</b><i>b, </i>and <b>170</b><i>c. </i>

The core network <b>106</b> may facilitate communications with other networks. For example, the core network <b>106</b> may provide the WTRUs <b>102</b><i>a, </i><b>102</b><i>b, </i><b>102</b><i>c </i>with access to circuit-switched networks, such as the PSTN <b>108</b>, to facilitate communications between the WTRUs <b>102</b><i>a, </i><b>102</b><i>b, </i><b>102</b><i>c </i>and traditional land-line communications devices. For example, the core network <b>106</b> may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the core network <b>106</b> and the PSTN <b>108</b>. In addition, the core network <b>106</b> may provide the WTRUs <b>102</b><i>a, </i><b>102</b><i>b, </i><b>102</b><i>c </i>with access to the networks <b>112</b>, which may include other wired or wireless networks that are owned and/or operated by other service providers.

<figref idref="DRAWINGS">FIGS. 2A and 2B</figref> are diagrams of an example IEEE 802.11 link setup procedure where the 802.11i/Extensible Authentication Protocol (EAP) may be used. This example procedure <b>200</b> may include an AP discovery phase <b>201</b>, a network discovery phase <b>202</b>, an additional time sync function (TSF) phase <b>203</b>, an authentication phase <b>204</b>, an association phase <b>205</b>, a security setup phase <b>206</b>, and an IP setup phase <b>207</b>. A wireless communication system may include one or more stations (STA)s <b>208</b>, one or more APs <b>209</b><i>a, </i><b>209</b><i>b, </i><b>209</b><i>c, </i>and one or more network elements <b>209</b><i>d. </i>A STA <b>208</b> may include a wireless transmit receive unit (WTRU) or a non-AP STA, and a network element <b>209</b><i>d </i>may include, for example, a router, a home agent (HA), an authentication, authorization, and accounting (AAA) server, an authentication server (AS), or a remote authentication dial-in user service (RADIUS).

In the AP discovery phase <b>201</b>, the STA <b>208</b> may use active or passive scanning to find APs in range. In an active scanning example, the STA <b>208</b> may transmit respective probe request frames <b>211</b><i>a, </i><b>211</b><i>b, </i><b>211</b><i>c </i>to AP1 <b>209</b><i>a, </i>AP2 <b>209</b><i>b, </i>and APn <b>209</b><i>c. </i>In response, each AP may transmit a respective probe response frame <b>212</b><i>a, </i><b>212</b><i>b, </i><b>212</b><i>c </i>to the STA <b>208</b>. In a passive scanning example, the STA <b>208</b> may wait to receive respective beacons <b>210</b><i>a, </i><b>210</b><i>b, </i><b>210</b><i>c </i>from AP1 <b>209</b><i>a, </i>AP2 <b>209</b><i>b, </i>and APn <b>209</b><i>c </i>prior to performing a probe request/response frame exchange.

In the network discovery phase <b>202</b>, the STA <b>208</b> may search for the proper service provider network by transmitting a guarded action system (GAS) initial request frame <b>213</b><i>a </i>to, for example, AP1 <b>209</b><i>a. </i>In response, AP1 <b>209</b><i>a </i>may transmit a query request <b>213</b><i>b </i>to network element <b>209</b><i>d, </i>and receive a query response <b>213</b><i>c. </i>In response to receiving the query response <b>213</b><i>c, </i>AP1 <b>209</b><i>a </i>may transmit a GAS initial response frame <b>213</b><i>d </i>to STA <b>208</b>. The STA <b>208</b> may transmit a GAS comeback request frame <b>213</b><i>e </i>to AP1 <b>209</b><i>a </i>and receive a GAS comeback request frame <b>213</b><i>f </i>in response. If necessary, one or more GAS comeback request/response exchanges <b>213</b><i>g </i>may be performed, for example, if the GAS response is too large to fit into one MAC management protocol data unit (MMPDU) and GAS fragmentation is used for delivery.

An additional TSF phase <b>203</b> may be performed. During the TSF phase <b>203</b>, STA <b>208</b> may transmit a probe request frame <b>214</b><i>a </i>to, for example, AP1 <b>209</b><i>a, </i>and receive a probe response frame <b>214</b><i>b </i>in response. The additional TSF phase may be used to further synchronize the time synchronization timers between, for example, AP1 <b>209</b><i>a </i>and STA <b>208</b>. The synchronization may be performed by using a timestamp field in the probe response frame <b>214</b><i>b. </i>

An authentication phase <b>204</b> may be performed. During the authentication phase <b>204</b>, STA <b>208</b> may transmit an authentication request frame <b>215</b><i>a </i>to, for example, AP1 <b>209</b><i>a, </i>and receive an authentication response frame <b>215</b><i>b </i>in response.

An association phase <b>205</b> may be performed. During the association phase <b>205</b>, STA <b>208</b> may transmit an association request frame <b>216</b><i>a </i>to, for example, AP1 <b>209</b><i>a, </i>and receive an association response frame <b>216</b><i>b </i>in response.

A security setup phase <b>206</b> may be performed. STA <b>208</b> may initiate the security setup phase <b>206</b> by transmitting an extensible authentication protocol (EAP) over local area network (LAN) (EAPOL) start frame <b>217</b><i>a </i>to, for example, AP1 <b>209</b><i>a. </i>AP1 <b>209</b><i>a </i>may transmit an EAP request frame <b>217</b><i>b </i>to STA <b>208</b>. The EAP request frame <b>217</b><i>b </i>may include a field that indicates an identity of AP1 <b>209</b><i>a. </i>The STA <b>208</b> may transmit an EAP response frame <b>217</b><i>c </i>to AP1 <b>209</b><i>a </i>in response. The EAP response frame <b>217</b><i>c </i>may include a field that indicates an identity of STA <b>208</b>. AP1 <b>209</b><i>a </i>may transmit a request frame <b>217</b><i>d </i>to a network element <b>209</b><i>d </i>using an AAA protocol, for example. The request frame <b>217</b><i>d </i>may include a field that indicates an identity of the STA <b>208</b>.

The network element <b>209</b><i>d </i>may transmit a challenge/transport layered security (TLS) start frame to AP1 <b>209</b><i>a </i>in response. AP1 <b>209</b><i>a </i>may transmit an EAP request/TLS start frame <b>217</b><i>f </i>to STA <b>208</b>. In response, STA <b>208</b> may transmit an EAP response/TLS client hello frame <b>217</b><i>g </i>to AP1 <b>209</b><i>a. </i>AP1 <b>209</b><i>a </i>may transmit a request/pass through frame <b>217</b><i>h </i>to network element <b>209</b><i>d, </i>and receive a challenge/server certificate frame <b>217</b><i>i </i>in response. AP1 <b>209</b><i>a </i>may transmit an EAP request/pass through frame <b>217</b><i>j </i>to STA <b>208</b>, and receive an EAP response/client certificate frame <b>217</b><i>k </i>in response.

AP1 <b>209</b><i>a </i>may transmit a request/pass through frame <b>217</b><i>l </i>to the network element <b>209</b><i>d, </i>and receive a challenge/encryption type frame <b>217</b><i>m </i>in response. AP1 <b>209</b><i>a </i>may transmit an EAP request/pass through frame <b>217</b><i>n </i>to STA <b>208</b>, and receive an EAP response frame <b>217</b><i>o </i>in response. AP1 <b>209</b><i>a </i>may transmit a request frame <b>217</b><i>p </i>to network element <b>209</b><i>d, </i>and receive an accept frame <b>217</b><i>q </i>in response. AP1 <b>209</b><i>a </i>may transmit an EAP success frame <b>217</b><i>r </i>to STA <b>208</b>. In response to the EAP success frame <b>217</b><i>r, </i>STA <b>208</b> and AP1 <b>209</b><i>a </i>may perform a 4-way handshake <b>217</b><i>s. </i>

An IP setup phase <b>207</b> may be performed to obtain an IP address assignment. For example, STA <b>208</b> may transmit a dynamic host configuration protocol (DHCP) discovery frame <b>218</b><i>a </i>to, for example, AP1 <b>209</b><i>a. </i>AP1 <b>209</b><i>a </i>may transmit a DHCP discovery frame <b>218</b><i>b </i>to network element <b>209</b><i>d, </i>and receive a DHCP offer frame <b>218</b><i>c </i>in response. AP1 <b>209</b><i>a </i>may transmit a DHCP offer frame <b>218</b><i>d </i>to STA <b>208</b>. STA <b>208</b> may transmit a DHCP request frame <b>218</b><i>e </i>to AP1 <b>209</b><i>a. </i>AP1 <b>209</b><i>a </i>may transmit a DHCP request frame <b>218</b><i>f </i>to network element <b>209</b><i>d, </i>and receive a DHCP acknowledgement (ACK) <b>218</b><i>g </i>in response. AP1 <b>209</b><i>a </i>may transmit a DHCP ACK <b>218</b><i>h </i>to STA <b>208</b>.

Other EAP methods that provide mutual authentication, for example, EAP-Subscriber Identity Module (EAP-SIM), EAP-Authentication and Key Agreement (AKA) and EAP-Tunneled Transport Layer Security (EAP-TTLS) may also be used.

Some issues have been encountered with 802.11 initial link setup procedures, such as the example protocol illustrated in <figref idref="DRAWINGS">FIG. 2</figref>. One issue may include the length of time, for example, up to several seconds or more, required for the 802.11 network to establish an initial connection with a STA. Another issue may be that when a user of a STA is involved in an interactive session, for example, a Skype video, a connection may not be able to be maintained when the STA switches from another network to an 802.11 network, for example, from a Third Generation Partnership Project (3GPP) network to wireless local area network (WLAN). Another issue may be that IEEE 802.11 networks may be required to support a large number of users simultaneously entering an extended service set (ESS) and securely provide them with authentication.

Some goals for 802.11 networks may be set with respect to initial link set up time, minimum user load and robustness in the presence of high background load. With respect to initial link set up time, one example goal may be for the initial link set up time for IEEE 802.11 networks to be less than 100 ms while maintaining a Robust Security Network Association (RSNA) security level where the initial link setup time may be the amount of time required to gain the ability to send internet protocol (IP) traffic with a valid IP address through the AP. With respect to minimum user load, an example goal may be for IEEE 802.11 networks to support at least 100 non-AP STAs entering an ESS within one second and to successfully conduct link setup. With respect to robustness in the presence of a high background load, an example goal may be to provide a link setup for media loads of at least fifty percent.

Example methods to reduce the initial link setup time for 802.11 networks are summarized in Table 1. These examples, however, may not be sufficient to meet the 100 ms link setup time goal because, even using aggressive predictions, the possible achievement time for link setup using passive scanning is 90 ms, even without considering the network discovery phase. A realistic time consumption may be significantly longer in real networks where a large number of APs may be present. Further, the IEEE 802.11 link setup protocol illustrated in <figref idref="DRAWINGS">FIG. 2</figref> is very long and will not satisfy the initial link setup time requirements.

<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="6"><colspec colname="1" colwidth="42pt" align="center" /><colspec colname="2" colwidth="84pt" align="center" /><colspec colname="3" colwidth="56pt" align="center" /><colspec colname="4" colwidth="42pt" align="left" /><colspec colname="5" colwidth="49pt" align="left" /><colspec colname="6" colwidth="56pt" align="left" /><thead><row><entry namest="1" nameend="6" rowsep="1">TABLE 1</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="6" align="center" rowsep="1" /></row><row><entry /><entry>AP Discovery</entry><entry /><entry /><entry /><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="7"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="42pt" align="left" /><colspec colname="3" colwidth="42pt" align="left" /><colspec colname="4" colwidth="56pt" align="left" /><colspec colname="5" colwidth="42pt" align="left" /><colspec colname="6" colwidth="49pt" align="left" /><colspec colname="7" colwidth="56pt" align="left" /><tbody valign="top"><row><entry /><entry>Active</entry><entry>Passive</entry><entry>Network</entry><entry>Additional</entry><entry>Auth. &amp;</entry><entry>Higher Layer</entry></row><row><entry>Phase</entry><entry>scanning</entry><entry>scanning</entry><entry>Discovery</entry><entry>TSF</entry><entry>Assoc.</entry><entry>(DHCP/IP)</entry></row><row><entry namest="1" nameend="7" align="center" rowsep="1" /></row><row><entry># of message</entry><entry>1+, STA-AP</entry><entry>1.5, STA-AP</entry><entry>2+, STA-AP</entry><entry>1, STA-AP</entry><entry>7~13, </entry><entry>2, STA-AP</entry></row><row><entry>rounds</entry><entry>Per AP</entry><entry>Per AP</entry><entry>1, AP-AS </entry><entry /><entry>STA-AP 4+, </entry><entry>2, AP-DHCP</entry></row><row><entry /><entry>per channel</entry><entry>per channel</entry><entry>per AP</entry><entry /><entry>AP-RADIUS</entry><entry>server</entry></row><row><entry>Time</entry><entry>Mean:</entry><entry>Mean:</entry><entry>5 ms to 30 ms </entry><entry>2 ms to 5 ms</entry><entry>15 ms to 2 s</entry><entry>~100ms</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="5"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="42pt" align="left" /><colspec colname="3" colwidth="42pt" align="left" /><colspec colname="4" colwidth="56pt" align="left" /><colspec colname="5" colwidth="147pt" align="center" /><tbody valign="top"><row><entry>(Today)</entry><entry>102 ms for</entry><entry>1100 ms for</entry><entry>per AP</entry><entry>Extensible Authentication Protocol </entry></row><row><entry /><entry>2.4 GHz:</entry><entry>2.4 GHz:;</entry><entry>Multiple AP: </entry><entry>Generalized Pre-Shared Key (EAP-GPSK)</entry></row><row><entry /><entry>n/a for 5.8</entry><entry>2300 ms for</entry><entry>n/a</entry><entry>@ OFDM6: 6 ms + 71 ms processing time,</entry></row><row><entry /><entry>Worst case:</entry><entry>5.8 GHz;</entry><entry /><entry>where OFDM6 may be a mode in 802.11PHY </entry></row><row><entry /><entry>680 ms</entry><entry>Worst case:</entry><entry /><entry>with a minimum data rate of 6 Mbps</entry></row><row><entry /><entry /><entry>3400 ms</entry><entry /><entry /></row><row><entry>Possible</entry><entry>2 ms </entry><entry>50 ms</entry><entry>Optmizations </entry><entry>EAP-GPSK w/Piggyback@ OFDM6:</entry></row><row><entry>achievement</entry><entry>(possibly at</entry><entry /><entry>for large number </entry><entry>5 ms + 35 ms processing time </entry></row><row><entry>(with </entry><entry>5 GHz)</entry><entry /><entry>of users </entry><entry>(reduced number of messages require less</entry></row><row><entry>knowledge)</entry><entry /><entry /><entry>simultaneously</entry><entry>processing time, further optimization </entry></row><row><entry /><entry /><entry /><entry>entering a </entry><entry>might be possible)</entry></row><row><entry /><entry /><entry /><entry>network</entry></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

Referring to Table 1, time values shown in the “possible achievement” row may be based on, for example, 802.11ai.

Although the 802.11 Authentication Phase may be removed when RSNA is used, the Authentication Phase may nevertheless be performed to aid in backward compatibility. The IP address assignment may be combined into earlier Phases of the link setup process in 802.11ai.

Example Internet Engineering Task Force (IETF) procedures may include DHCP with rapid commit to optimize IP Assignment Phase, which is a fast IP Assignment scheme. Configuration change counts (CCC)s or configuration sequence numbers may be used for the GAS configuration and/or AP configuration to optimize the system information communication between the STA and the AP/Network.

802.11ia procedures may not be sufficient to achieve the requirements of an initial link setup time of less than 100 ms. This may be because the current “possible” achievement time for link setup using passive scanning is 90 ms, even without considering the network discovery phase. In addition, the numbers given in the “possible achievement” row are very aggressive, for example, 2 ms for active scanning. A realistic time consumption may be significantly longer in real networks where there may be a large number of APs present. Some or all phases in the link setup process may be initiated by the STA. The AP may respond to a STA request, and may not have a mechanism to enable the AP to initiate an optimization in the link setup process. Most of the phases in the current 802.11 link setup process may be further optimized for faster link setup time while maintaining an RSNA level of security.

The current initial link setup process is very long and may not satisfy the initial link setup time requirements. Accommodation of a large number of users simultaneously entering the ESS may not be possible within the link setup time frames that have been identified. A method and apparatus that optimizes the link setup process using a dynamic, flexible, and interoperable procedure is needed.

The link setup process in 802.11 may not allow optimization of the process that includes the elimination of some steps or phases at the AP. For example, in 802.11, all phases in the link setup process may be initiated by STA as shown in <figref idref="DRAWINGS">FIG. 2A</figref>.

The system configuration may be defined. For example, the configuration change count or configuration sequence number may be defined. Further, in IEEE 802.11 an example initial setup procedure such as the protocol illustrated in <figref idref="DRAWINGS">FIG. 2A</figref> and <figref idref="DRAWINGS">FIG. 2B</figref>, all phases in the link setup process may be initiated by the STA. The AP only responds to a STA request, and, therefore, may not have a mechanism to initiate optimizations in the link setup process. Further yet, accommodation of a large number of users simultaneously entering the ESS may not be possible within the link setup time frames that have been identified, for example, 100 ms.

In addition to the above, with the increasing demand for mobility, and increased availability of multimode devices with multiple wireless interfaces, for example, 3GPP and IEEE 802.11, seamless handover and service continuity across these networks may become a differentiating service for an operator to offer to its users. Secure access procedures to 802.1x/EAP WLAN networks may suffer from lack of automation, significant added latency, non-seamless handoff, and disruption of previously established services over cellular networks, for example, voice over internet protocol (VoIP) sessions as a result of a handoff that often require user interaction, pre-provisioning devices, and WLAN networks with credentials.

One or more embodiments disclosed herein may speed up initial link setup for 802.11 devices by using information that the AP and/or STA pre-acquires. APs and/or STAs may pre-acquire certain information about each other. For example, a STA may switch from its previous connection, such as a 3G network, to a WLAN network, or from one AP to another AP in an ESS. In this example, it may be possible for a suitable or preferred WLAN AP to pre-acquire certain information about the candidate STA. It may also be possible for a STA to pre-acquire knowledge about a preferred AP based on, for example, geography locations and network access history, including but not limited to frequently visited places, daily routines, etc.

With an AP and/or STA pre-acquiring such information, it may be possible to skip and/or combine certain phases in the link setup procedure. In addition, depending on what and how much information an AP and/or STA has pre-acquired, various optimizations may be applied to a link setup procedure to reduce the link setup time. Such a shortened or optimized procedure may also be initiated by the AP.

<figref idref="DRAWINGS">FIG. 3</figref> is a flow chart of a baseline procedure for accelerated link setup using pre-acquired information. A wireless communication system may include one or more stations STAs <b>301</b>, one or more APs <b>302</b><i>a, </i><b>302</b><i>b, </i><b>302</b><i>c, </i>and one or more network elements <b>302</b><i>d. </i>A STA <b>301</b> may include a wireless transmit receive unit (WTRU), and a network element <b>302</b><i>d </i>may include, for example, a router, a home agent (HA), an AM server, an AS, or a RADIUS.

In the example procedure <b>300</b> illustrated in <figref idref="DRAWINGS">FIG. 3</figref>, an APn <b>302</b><i>c </i>may initiate link setup optimizations by using pre-acquired information about a STA <b>301</b>. Further, the example procedure illustrated in <figref idref="DRAWINGS">FIG. 3</figref> may accommodate multiple variants of accelerated link setup procedures in a dynamic, flexible, and interoperable manner while maintaining backward compatibility.

With respect to the link setup procedure illustrated in <figref idref="DRAWINGS">FIG. 2</figref>, the baseline procedure for accelerated link setup (ALS) using pre-acquired information illustrated in <figref idref="DRAWINGS">FIG. 3</figref> may be driven by entities other than the STA <b>301</b>. If no information on a STA or AP has been pre-acquired, then the ALS may function as an 802.11 link setup procedure that includes an AP discovery phase <b>303</b>, a network discovery phase <b>304</b>, an additional TSF phase <b>305</b>, an authentication phase <b>306</b>, an association phase <b>307</b>, a security setup phase <b>308</b>, an IP setup phase <b>309</b>. If, however, the AP has performed a pre-acquired information phase <b>310</b> to obtain information about the STA <b>301</b> or vice versa, the STA <b>301</b> and AP may optimize the AP discovery phase <b>303</b> using the pre-acquired information. In addition, the AP and STA may negotiate to skip or shorten the post-AP-discovery phases, for example, network discovery phase <b>304</b>, additional TSF phase <b>305</b>, authentication phase <b>306</b>, association phase <b>307</b>, security setup phase <b>308</b>, and IP setup phase <b>309</b>, depending on the amount of the information that the STA and AP have acquired with respect to each other.

For example, if a STA is conducting an interactive Skype call on a 3G cellular network, the STA may switch to the WLAN network if it arrives at a location where there are strong signals from a preferred AP. The STA and the preferred AP may pre-acquire information about each other prior to link setup through the 3G network, such as security related parameters, available network services, etc. Given the pre-acquired information, the STA may actively scan for only the preferred AP instead of scanning for all available APs in the area, which may significantly shorten the AP discovery process. Further, since the STA and AP may have already pre-acquired security related parameters and available network services information, they may skip the network discovery phase <b>304</b>, additional TSF phase <b>305</b> (since TSF may be conducted during the initial probe request/probe response exchange) and the security setup phase <b>308</b>, achieving even faster link setup, while maintaining the required RSNA level of security.

The example baseline procedure illustrated in <figref idref="DRAWINGS">FIG. 3</figref> may include a pre-acquiring information phase <b>310</b>, an AP discovery phase <b>303</b> and a post-AP discovery phase <b>311</b>. In the pre-acquiring information phase <b>310</b>, APs and/or STAs may acquire knowledge about each other through interfaces other than the IEEE 802.11 air link directly between them. The pre-acquiring information phase <b>310</b> may not count as part of link setup time and may be performed any time before the link setup between the AP and the STA. The pre-acquiring information phase <b>310</b> may not necessarily occur just prior to the link setup. In the AP discovery phase <b>303</b>, the STA <b>301</b> may find a proper AP with or without pre-acquired information. If pre-acquired information is available, AP discovery may be optimized accordingly and the specific procedure for the rest of the link setup process may be communicated and negotiated between the AP and STA. Otherwise, the AP discovery procedure <b>303</b> and the rest of the link setup phases may be used to maintain backward compatibility. The post-AP discovery phase <b>311</b> may include all remaining phases for setup of IP connectivity between the STA and the AP, such as network discovery <b>304</b>, additional TSF <b>305</b>, authentication <b>306</b>, association <b>307</b>, security setup <b>308</b>, and IP setup <b>309</b>. The Post-AP discovery phase <b>311</b> may be flexibly structured such that none of its phases are mandatory. In order to accelerate the link setup process, each of the phases may be skipped or optimized depending on the availability and the amount of the information pre-acquired about the STA and the AP. In addition, the ALS procedure illustrated in <figref idref="DRAWINGS">FIG. 3</figref> provides a framework for combined phases or a newly defined procedure. The selection of a specific procedure for a link setup case may be communicated between the AP and the STA through the proposed signaling mechanisms at the completion of the AP discovery step.

Referring to <figref idref="DRAWINGS">FIG. 3</figref>, STA <b>301</b> and AP1 <b>302</b><i>a </i>may pre-acquire information in the pre-acquiring information phase <b>310</b>. For example, if the STA <b>301</b> is connected to a WLAN, AP1 may receive candidate STA information <b>312</b><i>a </i>from APn <b>302</b><i>c, </i>and STA <b>301</b> may receive candidate AP information <b>313</b><i>a </i>from APn <b>302</b><i>c. </i>In another example, if the STA is connected to a cellular network, for example, a network element <b>302</b><i>d, </i>AP1 <b>302</b><i>a </i>may receive candidate STA information <b>312</b><i>b </i>from network element <b>302</b><i>d, </i>and STA <b>301</b> may receive candidate AP information <b>313</b><i>b </i>from network element <b>302</b><i>d. </i>

The candidate STA information <b>312</b><i>a, </i><b>312</b><i>b </i>may be pre-acquired knowledge about a candidate STA that, for example, AP1 <b>302</b><i>a </i>may communicate with at some point in the future. The candidate STA information <b>312</b><i>a, </i><b>312</b><i>b </i>may include, for example, the medium access control (MAC) address of the candidate STA, a capability of the candidate STA, security information, and/or a service package. The candidate AP information <b>313</b><i>a, </i><b>313</b><i>b </i>may be pre-acquired knowledge about a candidate AP that STA <b>301</b> may communicate with at some point in the future. The candidate AP information <b>313</b><i>a, </i><b>313</b><i>b </i>may include, for example, a service set identification (SSID), a basic service set identifier (BSSID), an AP capability, a physical (PHY) mode, one or more rates, security information, access network services information, and any other information that may be included in a beacon or probe response frame. The candidate STA information <b>312</b><i>a, </i><b>312</b><i>b </i>and the candidate AP information <b>313</b><i>a, </i><b>313</b><i>b </i>may also include information shown in Table 2 below.

An accelerated link setup (ALS) capability indicator may be used to indicate whether or not ALS is supported by STAs, including AP and non-AP STAs. The ALS indicator may include, for example, bit flag information that may be encoded in an existing information field by using a reserved bit. For example, the reserved bit may be the capability information field of the beacon frame. The reserved bit may also be encoded in one or more information fields or information elements (IE)s.

The AP and the STA may use the ALS capability indicator to inform each other about their ALS capabilities so that an ALS procedure may be triggered effectively. At initial link setup, both the AP and the STA may send ALS capability indicator information at their earliest possible opportunity. For example, an AP may send an ALS capability indicator in beacon frames and/or probe response frames while a STA may send an ALS capability indicator in probe request frames and/or other management/control frames as an initial frame to the AP.

IEs may be used to aid ALS procedures, and may include, for example, an I-know-you IE, an I-know-you-response IE, a Need-more-info IE, and a Need-more-info-response IE. These IEs may be included in management frames and may be transmitted over the WLAN air link between two STAs, including AP and non-AP STAs.

The I-know-you IE may allow the AP and/or the STA to notify the other at an early stage of initial link setup that it has pre-acquired information about the other. When an I-know-you IE is used by an AP, it may be sent in a first unicast frame from the AP to the STA, for example, a probe response or an authentication response, to notify the STA what information the AP has already pre-acquired. This information may include, for example, that the AP may know the STA identity such as a 48-bit MAC address; the AP may know the service needs of the STA and the ability of the AP to provide those services; that the AP and the STA share a credential/key, etc., and/or what information is needed, for example, the AP may need more information about the STA, such as confirmation from the STA and/or knowledge of the STA regarding the shared keys, etc. When an I-know-you IE is used by the STA, it may be transmitted in a first message from the STA to the AP, notifying the AP what information the STA has pre-acquired about the AP, for example, that the AP is the preferred AP of the STA; the STA has pre-acquired the MAC/PHY parameters of the AP; that the STA has a shared credential/key with the AP, that the STA is providing the AP with information about the STA and/or what information the STA still needs from the AP.

In addition, an I-know-you IE may also include a suggestion from its transmitter regarding how to pursue the remaining link setup process. For example, the suggestion may include a specific procedure to complete the link setup process, and may be based on the pre-acquired information.

An I-know-you-response IE may be a response to an I-know-you IE that may require further information. Such a response may include one or more confirmations, additions, and/or corrections to the information items listed in a received I-know-you IE.

A Need-more-info IE may allow the AP and the STA to further exchange information to aid ALS if messages with I-Know-You and I-Know-You-Response IEs do not complete the necessary information communications. For example, to negotiate how to complete the link setup process, the AP and/or the STA may need another round of message exchanges to reach an agreement. The Need-more-info-response IE may be a response to a Need-more-info IE or an I-know-you-response IE that may request further information.

A beacon transmission protocol may be performed to reduce system overhead and aid fast initial link setup. For example, a short beacon may be transmitted in addition to a regular beacon. Contents of the short beacon may be minimized to reduce system overhead and carry essential information for fast initial link setup. In this example, a short beacon may be transmitted as frequently as demanded by link setup delay requirements and, as such, may replace the regular primary beacon in one or more consecutive beacon cycles, replace the regular primary beacon in a periodic manner, or may be transmitted more frequently than the regular primary beacon. In addition, the short beacon contents may be influenced by an AP aware mode where the AP may have advance information about one or more STAs. A short beacon may include information relevant to one or more of: AP discovery; network discovery; security, for example, authentication and association; higher layer protocol to speed up the link setup process; I-know-you IE; I-know-you-response IE; Need-more-info IE; and/or Need-more-info-response IE.

An example short beacon frame <b>400</b> supporting ALS is illustrated in <figref idref="DRAWINGS">FIG. 4</figref>. For example, the short beacon frame <b>400</b> may include an optimized/minimized header <b>410</b>, a primary beacon related information field <b>420</b>, an optimized/minimized subset of primary beacon content field <b>430</b>, an AP discovery information field <b>440</b>, a network discovery information field <b>450</b>, a security related information field <b>460</b>, a higher layer protocol information field <b>470</b>, and one or more optional elements field <b>480</b>. The AP discovery information field <b>440</b>, network discovery information field <b>450</b>, security related information field <b>460</b>, and/or higher layer protocol information field <b>470</b> may be included in the short beacon frame <b>400</b> on an as needed basis.

In another example, a beacon frame may be modified to aid fast initial link setup. For example, a primary beacon may be modified to allow it to include essential information for fast initial link setup. In this example, the beacon contents may be influenced by an AP aware mode where the AP may have advance information about one or more STAs. The beacon may include information relevant to one or more of: AP discovery; network discovery; security, for example, authentication and association; higher layer protocol to speed up the link setup process; I-know-you IE; I-know-you-response IE; Need-more-info IE; and/or Need-more-info-response IE.

An example modification to a primary beacon frame <b>500</b> supporting ALS is illustrated in <figref idref="DRAWINGS">FIG. 5</figref>. For example, the primary beacon frame <b>500</b> may include a header <b>510</b>, a primary beacon content field <b>520</b>, a short beacon related information field <b>530</b>, an AP discovery information field <b>540</b>, a network discovery information field <b>550</b>, a security related information field <b>560</b>, a higher layer protocol information field <b>570</b>, and/or one or more optional elements field <b>580</b>. The short beacon related information field <b>530</b>, AP discovery information field <b>540</b>, network discovery information field <b>550</b>, security related information field <b>560</b>, and/or higher layer protocol information field <b>570</b> may be included in the primary beacon frame <b>500</b> on an as needed basis.

In addition, an ALS capability indicator may be included in the beacon frames, in both the short beacon and the modified primary beacon. The ALS capability indicator may be either encoded in the capability information field of the beacon frame by using a reserved bit or encoded in other information fields or information elements in the beacon frames.

IEEE 802.11 management frames that are typically used in link setup may be modified to aid fast initial link setup (FILS). For example, association/re-association and probe request and response messages may be modified to aid FILS by including information relevant to one or more of AP discovery; network discovery; security, for example, authentication and association; higher layer protocol to speed up the link setup process; I-know-you IE; I-know-you-response IE; Need-more-info IE; and/or Need-more-info-response IE.

An IEEE 802.11 measurement pilot frame to assist STAs with scanning may be modified to aid FILS. The measurement pilot frame may be a public action frame that may include a subset of the information included in a primary beacon and may be transmitted more often than the primary beacon. For example, the measurement pilot may be modified to aid FILS by including information relevant to one or more of AP discovery; network discovery; security, for example, authentication and association; higher layer protocol to speed up the link setup process; I-know-you IE; I-know-you-response IE; Need-more-info IE; and/or Need-more-info-response IE.

In addition, other IEEE 802.11u frames, such as generic advertisement service (GAS) initial request/response and GAS comeback request/response frames, may be modified to aid FILS by including information relevant to one or more of AP discovery; network discovery; security, for example, authentication and association; higher layer protocol to speed up the link setup process; I-know-you IE; I-know-you-response IE; Need-more-info IE; and/or Need-more-info-response IE.

In another example, a management frame to aid FILS, referred to as a FILS management frame, may include information relevant to one or more of AP discovery; network discovery; security, for example, authentication and association; higher layer protocol to speed up the link setup process; I-know-you IE; I-know-you-response IE; and/or Need-more-info IE. The FILS management frame may be defined and implemented as a FILS management action frame with the action defined as supporting the FILS function. The FILS management action frame may include one or more of the following modes: a regular mode that requires an acknowledgement (ACK) response and a No ACK mode that will not require an ACK response from the receiver.

A FILS management action frame may be a public action frame. A FILS management action frame may be used for an inter-Basic Service Set (inter-BSS) and AP information exchange with an unassociated-STA. Examples of such information exchange scenarios may include the transmitting STA or AP and receiving STA or AP being associated with different BSSs and one or both of the transmitting and receiving STAs not being associated to a BSS. A FILS management action frame may also have a dual protected mode, which may be used for STA to STA communication.

An example FILS management action frame <b>600</b> is illustrated in <figref idref="DRAWINGS">FIG. 6</figref>. For example, the FILS management action frame <b>600</b> may include a category field <b>610</b>, an action field <b>620</b>, an AP discovery information field <b>630</b>, a network discovery information field <b>640</b>, a security related information field <b>650</b>, a higher layer protocol information field <b>660</b>, and one or more optional elements field <b>670</b>. The category field <b>610</b> may indicate, for example, that the FILS management action frame is a public action frame. The action field <b>620</b> may indicate a FILS action. The AP discovery information field <b>630</b>, network discovery information field <b>640</b>, security related information field <b>650</b>, and/or higher layer protocol information field <b>660</b> may be included in the FILS management action frame on an as needed basis.

A FILS management action frame may be transmitted by an AP and may be transmitted in a unicast or a broadcast mode. The AP may transmit the FILS management action frame as frequently as needed to support efficient operation of FILS in the BSS/system.

In another example, a FILS management action function may be supported by a FILS request frame and a FILS response/report frame. A device transmitting a FILS request frame may request information relevant to one or more of: AP discovery; network discovery; security, for example, authentication and association; higher layer protocol to speed up the link setup process; I-know-you IE; I-know-you-response IE; and/or Need-more-info IE. A device transmitting a FILS response/report frame may respond with or report information relevant to one or more of: AP discovery; network discovery; security, for example, authentication and association; higher layer protocol to speed up the link setup process; I-know-you IE; I-know-you-response IE; Need-more-info IE; and/or Need-more-info-response IE.

Information pre-acquired by an AP and/or a STA may be used to effectively optimize AP discovery. For example, a STA may obtain preferred AP information through multiple mechanisms, such as a connection to a network before switching to a WLAN network, and memorized historic data with APs and locations, etc. At a STA, pre-acquired information may be classified into two major types: air interface MAC/PHY parameters, for example, those in beacon and/or probe response frames such as service set identification (SSID)/basic service set identification (BSSID), service offerings, capability, PHY parameters, supported rates, quality of service (QoS) capability, etc., and security-related information, for example, robust security network (RSN) information, shared key/credential with expiration time and/or valid authentication context with expiration time. A minimum pre-acquired information at the STA may include a MAC address of a preferred AP, for example, the BSSID. Other information items may be available and used in an incremental manner.

If the BSSID of the AP is the only information that a STA has pre-acquired with respect to the coverage area of the AP, the AP discovery process may be optimized from at least two aspects. First, the STA may transmit a unicast probe request frame (not wildcard). Second, the AP discovery process may be returned once the probe response frame is received confirming its preferred AP selection, without a need to scan all the available APs in the area. If the BSSID of the AP and any other information items have been pre-acquired by the STA, further optimizations may be applied to AP discovery.

<figref idref="DRAWINGS">FIG. 7</figref> is a diagram illustrating an example AP discovery method <b>700</b> with pre-acquired knowledge of the AP. In this example, the AP <b>710</b> and/or the STA <b>720</b> may have pre-acquired information from a previous connection to a network, for example 3G, other WLAN AP, etc. The pre-acquired information may also be from the memory of the STA <b>720</b> and its current location. Pre-acquired information may be obtained in a variety of ways. In one example, the AP <b>710</b> may receive a message that includes candidate STA information <b>722</b> from a network element <b>725</b>. In another example, the STA <b>720</b> may receive a message that includes candidate AP information <b>726</b> from the network element <b>725</b>.

Referring to <figref idref="DRAWINGS">FIG. 7</figref>, the STA <b>720</b> may receive a beacon <b>730</b> from the AP <b>710</b>. The beacon <b>730</b> may include an ALS capability indicator. The STA may transmit a unicast request frame <b>740</b> to the AP <b>710</b>. The unicast request frame <b>740</b> may be a probe request frame, and may include an I-Know-You IE. The unicast request frame <b>740</b> may be a new MAC management frame or a modified 802.11 MAC management frame. The I-Know-You IE may include the information items about the knowledge of the STA regarding the AP to seek confirmations and/or corrections from the AP, and it may also include request indicators to ask for further information from the AP.

When the AP <b>710</b> receives such a request frame with an I-Know-You IE from the STA <b>720</b>, the AP <b>710</b> may transmit a response frame <b>750</b> back to the STA <b>720</b>. The response frame <b>750</b> may include an I-Know-You-Response IE including further details regarding how to complete the link setup process. Another round of message exchanges may be used for the AP <b>710</b> and the STA <b>720</b> to gain further information about each other and reach an agreement regarding how to complete the link setup procedure. For example, the STA <b>720</b> may transmit a need-more information request frame <b>760</b>, and receive an need-more information response frame <b>770</b> from the AP <b>710</b> in response. When the AP discovery phase <b>775</b> is completed, the rest of the link setup <b>780</b> may be performed.

In this example, the AP discovery phase <b>775</b> may be completed in one or two message rounds between the STA and the AP and take approximately 4 ms to 10 ms to complete. Additionally, in such AP discovery phase <b>775</b>, the pre-acquired knowledge may be applied to derive an optimized way to complete the rest of link setup functions by the AP <b>710</b> and the STA <b>720</b>.

An AP may pre-acquire a candidate STA's knowledge through its connections to a network. The pre-acquired information about a STA may include the MAC address of the STA; service requirements; security related information, for example, shared key/credential with expiration time; and/or valid authentication context with expiration time, etc. Similarly, a minimum pre-acquired knowledge that an AP may have about a STA may include the MAC address of the STA. Other information items, for example, a STA capability, one or more service requirements, security information, etc., may be available and used in an incremental manner.

If an AP has pre-acquired knowledge about a STA, for example, either the MAC address of the STA only or its MAC address with additional information items, the AP may initiate an ALS procedure after receiving a first frame from the STA including the MAC address of the STA.

<figref idref="DRAWINGS">FIG. 8</figref> is a diagram illustrating an example of optimized AP discovery method <b>800</b> initiated by an AP <b>810</b> based on pre-acquired information. Pre-acquired information may be obtained in a variety or ways. For example, a network element <b>815</b> may transmit a message that includes candidate STA information <b>817</b> to the AP <b>810</b>. In another example, the network element <b>815</b> may transmit a message that includes candidate AP information <b>819</b> to STA <b>820</b>.

In the example illustrated in <figref idref="DRAWINGS">FIG. 8</figref>, when an AP <b>810</b> receives a first frame <b>830</b>, for example a probe request frame, from a STA <b>820</b> including the MAC address of the STA <b>820</b>, if the AP <b>810</b> has pre-acquired information about the STA <b>820</b>, the AP <b>810</b> may transmit a response frame <b>840</b>, for example, a probe response frame. The response frame <b>840</b> may include an I-Know-You IE that indicates that it may be the correct AP for the STA <b>820</b>. The I-Know-You IE may be used to request further information from the STA <b>820</b>. The first frame <b>830</b> and the response frame <b>840</b> may each include an ALS capability indicator. When receiving such a response from the AP <b>810</b>, the STA <b>820</b> may terminate the scanning process so that the time used for scanning may be significantly reduced. The AP <b>810</b> and STA <b>820</b> may perform further information exchanges. For example, the STA <b>820</b> may transmit a frame <b>850</b> that includes more information about the STA. The frame <b>850</b> may include a suggestion for a link setup procedure. In response, the AP <b>810</b> may transmit a frame <b>860</b> in response. The frame <b>860</b> may include a confirmation of the suggested link setup procedure.

In addition, through a response of the STA <b>820</b> to an I-Know-You IE of the AP <b>810</b>, and further information exchanges between the AP <b>810</b> and the STA <b>820</b> if needed, the AP <b>810</b> and the STA <b>820</b> may reach an agreement regarding how to complete the link setup process in a time efficient manner. For example, the AP <b>810</b> and STA <b>820</b> may agree to skip, optimize, or combine certain link setup phases. In this way, the AP <b>810</b> may successfully apply its pre-acquired information to actively participate in determining how to optimize the link setup process.

Post-AP-discovery link setup optimizations may vary with the available information that an AP and a STA may have pre-acquired prior to AP discovery and during an AP discovery phase. Table 2 provides example post-AP-discovery link setup optimizations based on different assumptions of pre-acquired knowledge.

<tables id="TABLE-US-00002" num="00002"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="63pt" align="left" /><colspec colname="2" colwidth="70pt" align="left" /><colspec colname="3" colwidth="161pt" align="left" /><thead><row><entry namest="1" nameend="3" rowsep="1">TABLE 2</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Phase</entry><entry>Function</entry><entry>Optimization Considerations</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Network Discovery</entry><entry>Find a right service</entry><entry>May be skipped if the AP knows the service need of</entry></row><row><entry /><entry>provider network</entry><entry>the STA and also knows the connected network can</entry></row><row><entry /><entry /><entry>provide the services</entry></row><row><entry>Additional TSF</entry><entry>Further time</entry><entry>May be skipped depending on the air link status; the</entry></row><row><entry /><entry>synchronization with</entry><entry>AP may also inform the STA if it can be skipped</entry></row><row><entry /><entry>the selected AP</entry></row><row><entry>802.11</entry><entry>Verify the STA, but</entry><entry>may be skipped if RSNA is used</entry></row><row><entry>Authentication</entry><entry>not useful for RSNA</entry></row><row><entry>802.11 Association</entry><entry>Check RSN info</entry><entry>may be combined into the last message round in AP-</entry></row><row><entry /><entry>provided by the STA,</entry><entry>discovery phase;</entry></row><row><entry /><entry>also assign</entry><entry>may also be another standalone message round, but</entry></row><row><entry /><entry>association identifier</entry><entry>may be used to carry some information items for the</entry></row><row><entry /><entry>(AID)</entry><entry>next link setup phases, e.g., EAP/802.1x</entry></row><row><entry /><entry /><entry>authentication, and/or IP address assignment</entry></row><row><entry>EAP/802.1x</entry><entry>EAP authentication,</entry><entry>Multiple variants of possible optimizations, e.g.:</entry></row><row><entry>authentication &amp;</entry><entry>plus Keys/parameters</entry><entry>skipped or shortened, if upper layer session keys are</entry></row><row><entry>Security</entry><entry>setup</entry><entry>provided</entry></row><row><entry /><entry /><entry>Fast EAP using STA pre-established security</entry></row><row><entry /><entry /><entry>association with a network</entry></row><row><entry /><entry /><entry>Fast EAP authentication and Fast Key provisioning</entry></row><row><entry /><entry /><entry>using STA pre-established security association with a</entry></row><row><entry /><entry /><entry>network</entry></row><row><entry /><entry /><entry>Fast network discovery and fast EAP authentication</entry></row><row><entry /><entry /><entry>using STA pre-established security association with</entry></row><row><entry /><entry /><entry>the network;</entry></row><row><entry /><entry /><entry>Fast network discovery, fast EAP authentication, and</entry></row><row><entry /><entry /><entry>fast key provisioning using STA pre-established</entry></row><row><entry /><entry /><entry>security association with a network</entry></row><row><entry /><entry /><entry>Optimization to a 4-Way handshake protocol by</entry></row><row><entry /><entry /><entry>reducing number of EAPOL-Key frame messages</entry></row><row><entry /><entry /><entry>exchanged between the AP and the STA from four to</entry></row><row><entry /><entry /><entry>two. This may be achieved by leveraging a pre-</entry></row><row><entry /><entry /><entry>established master key shared between a network and</entry></row><row><entry /><entry /><entry>a STA to derive pairwise master key (PMK) and GMK</entry></row><row><entry /><entry /><entry>keys.</entry></row><row><entry>IP address</entry><entry>Assign IP address to</entry><entry>The IP address can be assigned via the eANDSF over</entry></row><row><entry>assignment</entry><entry>the STA</entry><entry>the cellular network</entry></row><row><entry /><entry /><entry>The AAA server may send the IP address to the STA</entry></row><row><entry /><entry /><entry>in an EAP message.</entry></row><row><entry /><entry /><entry>Combined into previous phases, e.g., through</entry></row><row><entry /><entry /><entry>piggybacking Layer-2 information element</entry></row><row><entry /><entry /><entry>Optimized through some fast IP address assignment</entry></row><row><entry /><entry /><entry>schemes</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

Established security association between a STA and a network, for example, a cellular network, may be leveraged to enable authentication and secure link setup on another network, for example, a WLAN network, in an on-demand and seamless fashion. In one example, a reverse bootstrap of application-layer credentials on a network may be used to generate credentials used in a follow-on new access-layer authentication procedure in another network. An objective in developing the authentication mechanisms may be to optimize the steps and procedures involved and facilitate seamless authentication while roaming across all forms of access networks.

An example of using Single Sign-On (SSO) protocols, for example, OpenID Connect, and reverse bootstrapping may allow a STA to discover and access previously unknown networks such as WLAN networks. There may be no need to pre-provision credentials at a new network since these may be bootstrapped from an already running application service security.

Implementation options for SSO integration with WLAN networks may include use of an AAA server that integrates Identity Provider (OP) and enhanced ANDSF (eANDSF) functionalities and an AAA server integrates OP functionality.

<figref idref="DRAWINGS">FIG. 9</figref> is a diagram of an example method <b>900</b> in which an AAA server <b>910</b> may integrate OP and enhanced ANDSF (eANDSF) functionalities to enable seamless authentication and fast link setup. This example may assume that the STA <b>920</b> and the OP unit of the AAA server <b>910</b> have already established a security association and master keys that may be leveraged for accessing the WLAN network. On a condition that an association between the STA <b>920</b> and the OP unit of the AAA server <b>910</b> is not established, an active 3GPP connection may be used between the STA <b>920</b> and the OP unit of the AAA server <b>910</b> to exchange OpenID Connect authentication and generate a master key on both entities.

In a first example, the STA <b>920</b> may have successfully completed mutual authentication <b>930</b> towards the OP unit of the AAA server <b>910</b> over a 3GPP access network and shared Master keys, for example, a pre-shared key (PSK), may have been established on both the STA <b>920</b> and OP unit of the AAA server <b>910</b>. In addition, the STA <b>920</b> and the eANDSF unit of the AAA <b>910</b> may have a mutually authenticated and established secure connection <b>940</b>, for example via a 3GPP enhanced S14 (eS14) interface. The STA <b>920</b> may request WLAN network information from the eANDSF unit of the AAA server <b>910</b> and/or the eANDSF unit of the AAA server may push WLAN network information to the STA over a secure 3GPP connection. The network information may include available APs, SSIDs, authentication method to use, and other access network parameters. Using the information about the available APs and WLAN networks, the STA <b>920</b> may not need to perform passive scanning for beacons or perform a lengthy network discovery procedure. The STA <b>920</b> may immediately transmit a probe request <b>950</b> to a selected AP <b>960</b> from a prioritized list provided to the STA <b>920</b> by the eANDSF unit of the AAA server <b>910</b>.

After the STA <b>920</b> receives a probe response <b>970</b> from the selected AP <b>960</b>, it may perform open authentication <b>971</b> and associate <b>972</b> with the selected AP <b>960</b>. Open authentication <b>971</b> may not provide any security measures and may be skipped if an 802.1x/EAP method is used.

The AP <b>960</b> may be referred to as the authenticator in this example, and may issue an EAP Request <b>973</b> requesting a STA identity. The STA <b>920</b> may return an EAP Response <b>974</b> that may include a unique identity, for example, an international mobile subscriber Identity (IMSI) with its realm. The realm may include a hint to use SSO authentication, for example, IMSI@sso.MNO.com. The AP <b>960</b> may transmit an access request <b>975</b> to an AAA server using, for example, a RADIUS access request. The Access Request <b>975</b> may include an EAP ID. The OP unit of the AAA server <b>910</b> may recognize STA identity and correlate it with the existing security association. The OP unit of the AAA server <b>910</b> may decide that the STA <b>920</b> is already authenticated, perform fast EAP authentication, and generate a PMK <b>976</b> based on the previously generated Master key shared with the STA. The AAA server <b>910</b> may transmit an Access Accept message <b>977</b> to the AP <b>960</b>. The Access Accept message <b>977</b> may include an EAP success and the key material to the AP <b>960</b>. The AP <b>960</b> may forward an EAP Success message <b>978</b> to the STA <b>920</b>. The STA <b>920</b> may generate a PMK <b>980</b> using its shared master key with the OP.

The 802.1X/EAP authentication may be completed when the AP <b>960</b> transmits an EAP Success message <b>978</b> and the AP <b>960</b> may initiate a 4-Way Handshake protocol <b>981</b> to derive the temporal keys <b>983</b>, which may include a pairwise transient key (PTK) for encryption of unicast traffic and a group temporal key (GTK) for encryption of broadcast and multicast traffic. The 4-Way Handshake protocol <b>981</b> may use four EAPOL-Key frame messages between the AP <b>960</b> and the STA <b>920</b>.

The 4-Way Handshake may use pseudo-random functions (PRF) to hash various inputs to derive pseudo-random values. The PMK may be one of the inputs combined with other inputs to create the PTK on the STA <b>920</b> and the AP <b>960</b>. Some of the other inputs used by the pseudo-random function may be referred to as nonces. A nonce may be a random numerical value that is generated one time only, is used in cryptographic operations, and is associated with a given cryptographic key. For the 4-Way Handshake, a nonce may be associated with the PMK. A nonce may only be used once and may not be used again with the PMK. Two nonces may be created by the 4-Way Handshake, an AP nonce (ANonce) and a supplicant nonce (SNonce). The Snonce may also be referred to as a STA nonce.

To create the PTK, the 4-Way Handshake may use a pseudo-random function that combines the PMK, a numerical authenticator nonce, a supplicant nonce, the authenticator's MAC address (AA), and the supplicant's MAC address (SPA).

In a 4-Way Handshake procedure, the AP and STA may each randomly create their respective nonces. The authenticator, for example AP <b>960</b>, may transmit an EAPOL-Key frame <b>982</b> to the supplicant, for example STA <b>920</b>. The EAPOL-Key frame <b>982</b> may include an ANonce. The STA <b>920</b> may now have all the necessary inputs for the pseudo-random function. The STA <b>920</b> may derive a PTK <b>983</b> from the PMK, ANonce, SNonce, and MAC addresses. The STA <b>920</b> may now be in possession of a PTK that may be used to encrypt unicast traffic.

The STA <b>920</b> may transmit an EAPOL-Key frame <b>984</b> to AP <b>960</b>. The EAPOL-Key frame may include an SNonce. The AP <b>960</b> may now have all the necessary inputs for the pseudo-random function. The STA <b>920</b> may also transmit its RSN information element capabilities and a message integrity code (MIC) to the AP <b>960</b>. The AP <b>960</b> may derive a PTK <b>985</b> from the PMK, ANonce, SNonce, and MAC addresses. The AP <b>960</b> may also validate the MIC. The AP <b>960</b> may now be in possession of a pairwise transient key that may be used to encrypt unicast traffic.

The AP <b>960</b> may derive a GTK <b>986</b> from the group master key (GMK) it may possess. The AP <b>960</b> may transmit an EAPOL-Key frame <b>987</b> to the STA <b>920</b>. The EAPOL-Key frame <b>987</b> may include the ANonce, the AP's RSN information element capabilities, and a MIC. The EAPOL-Key frame <b>987</b> may also include a message to the STA <b>920</b> to install the temporal keys. The GTK <b>986</b> may be delivered inside the unicast EAPOL-Key frame <b>987</b> to the STA <b>920</b>. The confidentiality of the GTK <b>986</b> may be protected because it may be encrypted with the PTK <b>985</b>. The STA <b>920</b> may transmit an EAPOL-Key frame <b>988</b> to the AP <b>960</b> to confirm that the temporal keys have been installed.

As an optimization to the 4-Way Handshake procedure described above, it may be possible to reduce the number of EAPOL-Key frame messages between the AP and the STA to two. This may be achieved using any of the following example optimizations. The OP unit of the AAA server and the STA may leverage the Master key to derive PMK and GMK keys. The AAA server may transmit both the PMK and the GMK to the AP. The first message of the 4-Way Handshake may be modified to include, in addition to the ANonce, a group nonce (GNonce) randomly generated by the AP. The STA may derive a PTK from the PMK, ANonce, SNonce, and MAC addresses. The STA may also derive a GTK from the GMK, GNonce, and MAC addresses. The STA may now be in possession of pairwise transient keys (PTK, GTK) that may be used to encrypt and decrypt unicast, broadcast, and multicast traffic. The STA may transmit an EAPOL-Key frame including an SNonce to the AP. The STA may also transmit its RSN information element capabilities and a message integrity code (MIC) to the AP. The AP may derive a PTK from the PMK, ANonce, SNonce, and MAC addresses. The AP may also derive a GTK from the GMK, GNonce, and MAC addresses. In addition, the AP may validate the MIC.

At one point during the 4-Way Handshake procedure, both the STA and the AP may have PTK and GTK keys that may be used to encrypt and decrypt unicast, broadcast and multicast traffic. Thus, the remainder of the 4-Way Handshake procedure may not be needed.

At the end of the 4-Way Handshake procedure, the STA <b>920</b> may obtain an IP address and necessary configurations <b>990</b>, for example, one or more domain name servers (DNS)s to use, using a DHCP protocol, and the STA may now access the WLAN network <b>995</b>.

As a variant to achieve optimization for a STA acquiring its IP address and the necessary configurations, this step may be skipped if the eANDSF provides the IP address and necessary configuration to the STA over a cellular network and the AAA server sends the IP address and necessary configurations to the STA encapsulated into an EAP message, for example, using EAP-Notify message.

<figref idref="DRAWINGS">FIG. 10</figref> is a diagram of an example method <b>1000</b> in which the AAA server <b>1005</b> integrates OP and eANDSF functionalities to enable seamless authentication and fast link setup. This example may assume that the STA <b>1010</b> and the OP unit of the AAA server <b>1005</b> have already established security association and master keys that may be leveraged for accessing the WLAN network. The STA <b>1010</b> may have successfully completed mutual authentication <b>1015</b> towards the OP unit of the AAA server <b>1005</b> over a network that it may have been previously connected to, for example, a 3GPP access network, and shared Master keys (PSK) may be established on the STA <b>1010</b> and the OP unit of the AAA server <b>1005</b>. In addition, the STA <b>1010</b> and the eANDSF unit of the AAA server may be mutually authenticated and a secure connection may be established <b>1020</b>, for example over a 3GPP STA-eS14 interface. The STA <b>1010</b> may request WLAN network info from the eANDSF unit of the AAA server <b>1005</b> and/or the eANDSF unit of the AAA server <b>1005</b> may push WLAN network information to the STA <b>1010</b> over a secure 3GPP connection. The network information may include available APs, SSIDs, authentication method to use, and other access network parameters. Using the information about the available APs and WLAN networks, the STA <b>1010</b> may not need to perform passive scanning for beacons or perform a lengthy network discovery procedure. The STA <b>1010</b> may immediately transmit a probe request <b>1025</b> to a selected AP <b>1030</b> from a prioritized list provided to the STA <b>1010</b> by the eANDSF unit of the AAA server <b>1005</b>.

After the STA <b>1010</b> receives a probe response <b>1035</b> from the selected AP <b>1030</b>, it may perform open authentication <b>1040</b> and associate <b>1041</b> with the selected AP <b>1030</b>. Open authentication <b>1040</b> may not provide any security measures and may be skipped if an 802.1x/EAP method is used.

The AP <b>1030</b> may be referred to as the authenticator in this example, and may issue an EAP Request <b>1042</b> requesting a STA identity. The STA <b>1010</b> may return an EAP Response <b>1043</b> that may include a unique identity, for example, an international mobile subscriber Identity (IMSI) with its realm. The realm may include a hint to use SSO authentication, for example, IMSI@sso.MNO.com. The AP <b>1030</b> may transmit an access request <b>1044</b> to an AAA server <b>1005</b> using, for example, a RADIUS access request. The Access Request <b>1044</b> may include an EAP ID.

The OP unit of the AAA server <b>1005</b> may determine that the STA <b>1010</b> needs to be re-authenticated before sending an Access Accept message to the AP. Therefore, one or more rounds of EAP-Challenge/Response messages may be exchanged before sending an EAP-Success and keying material to the AP. For example, the AAA server <b>1005</b> may generate a challenge based on a STA-OP PSK <b>1045</b> and transmit an access challenge message <b>1046</b> to AP <b>1030</b>. The access challenge message <b>1046</b> may include an EAP ID and/or an EAP challenge. The AP <b>1030</b> may transmit an EAP-Request message <b>1047</b> to STA <b>1010</b> in response to the access challenge message <b>1046</b>. The EAP-Request message <b>1047</b> may include an identity and/or a challenge. The STA <b>1010</b> may receive the EAP-Request message <b>1047</b>, verify the MAC and generate an SRES <b>1048</b>, and transmit an EAP-Response message <b>1049</b> to the AP <b>1030</b>. The EAP-Response message <b>1049</b> may include an identity and/or a response to the challenge.

The AP <b>1030</b> may transmit an access request message <b>1050</b> to the AAA server <b>1005</b>, and receive an access accept message <b>1051</b> from the AAA server <b>1005</b> in response. The access request message <b>1050</b> may include an EAP ID and/or a response to the challenge. The access accept message <b>1051</b> may include an EAP ID, an indication of success, and the PMK key to the AP. In response to receiving the access accept message <b>1051</b>, the AP <b>1030</b> may transmit an EAP-Success message <b>1052</b> to the STA <b>1010</b>. In response to receiving the EAP-Success message <b>1052</b>, the STA <b>1010</b> may generate a PMK <b>1053</b> using the STA-OP PSK and may perform a 4-way handshake protocol <b>1054</b> with the AP <b>1030</b>, request IP address assignment using DHCP <b>1055</b>, and access the internet over WLAN <b>1056</b>, as described in <figref idref="DRAWINGS">FIG. 9</figref> above.

<figref idref="DRAWINGS">FIG. 11</figref> is a diagram of an example method <b>1100</b> in which the AAA server <b>1101</b> integrates OP functionality to enable seamless authentication and FILS. The example in <figref idref="DRAWINGS">FIG. 11</figref> may assume that the STA <b>1102</b> and the OP unit of the AAA server <b>1101</b> have already established security association and master keys that may be leveraged for accessing the WLAN network. The STA <b>1102</b> may have successfully completed mutual authentication towards the OP over, for example, the 3GPP access network, and shared Master keys (PSK) may be established on the STA <b>1102</b> and the OP unit of the AAA server <b>1101</b>. The STA <b>1102</b> may not have connectivity to an eANDSF and, therefore, may perform WLAN network discovery through other mechanisms, for example, using 802.11u.

In the example shown in <figref idref="DRAWINGS">FIG. 11</figref>, during a fast EAP procedure, the OP unit of the AAA server <b>1101</b> may recognize a STA identity and correlate it with an existing security association. The OP unit of the AAA server <b>1101</b> may determine that the STA <b>1102</b> is already authenticated, perform fast EAP authentication, and generate PMK based on the previously generated Master key shared with the STA <b>1102</b>.

For example, the STA <b>1102</b> may have successfully completed mutual authentication <b>1103</b> towards the OP unit of the AAA server <b>1101</b> over a network that it may have been previously connected to, for example, a 3GPP access network, and shared Master keys (PSK) may be established on the STA <b>1102</b> and the OP unit of the AAA server <b>1101</b>. The STA <b>1102</b> may perform passive and/or active AP discovery <b>1104</b> as described in <figref idref="DRAWINGS">FIG. 9</figref>. The STA <b>1102</b> may perform one or more GAS message exchanges to perform Network discovery <b>1105</b>. For example, the STA <b>1102</b> may transmit a GAS message <b>1106</b> to AP <b>1107</b>, and receive a GAS response message <b>1108</b> from the AP <b>1107</b> in response.

The STA <b>1102</b> may perform open authentication <b>1109</b> and associate <b>1110</b> with the selected AP <b>1107</b>. Open authentication <b>1109</b> may not provide any security measures and may be skipped if an 802.1x/EAP method is used.

The AP <b>1107</b> may be referred to as the authenticator in this example, and may issue an EAP Request <b>1112</b> requesting a STA identity. The STA <b>1102</b> may return an EAP Response <b>1113</b> that may include a unique identity, for example, an international mobile subscriber Identity (IMSI) with its realm. The realm may include a hint to use SSO authentication, for example, IMSI@sso.MNO.com. The AP <b>1107</b> may transmit an access request <b>1114</b> to an AAA server <b>1101</b> using, for example, a RADIUS access request. The Access Request <b>1114</b> may include an EAP ID.

The AAA server <b>1101</b> may generate a PMK from the STA-OP PSK <b>1115</b>, and transmit an Access Accept message <b>1116</b> to the AP <b>1107</b>. The Access Accept message <b>1116</b> may include an EAP ID, an indication of success, and the PMK key to the AP. The AP <b>1107</b> may transmit an EAP Success message <b>1119</b> to the STA <b>1102</b>. In response, the STA <b>1102</b> may generate a PMK using the STA-OP PSK <b>1120</b> and may perform a 4-way handshake protocol <b>1121</b> with the AP <b>1107</b>, request IP address assignment using DHCP <b>1122</b>, and access the internet over WLAN <b>1123</b>, as described in <figref idref="DRAWINGS">FIG. 9</figref> above.

<figref idref="DRAWINGS">FIG. 12</figref> is a diagram of an example method <b>1200</b> in which a AAA server <b>1201</b> may integrate OP functionality to enable seamless authentication and FILS. This example may assume that the STA <b>1202</b> and the OP unit of the AAA server <b>1201</b> have already established security association and master keys that may be leveraged for accessing the WLAN network. The STA <b>1202</b> may have successfully completed mutual authentication <b>1203</b> towards the OP unit of the AAA server <b>1201</b> over, for example, a 3GPP access network, and shared Master keys, for example, PSK, may be established on the STA <b>1202</b> and the OP unit of the AAA server <b>1201</b>. The STA <b>1202</b> may not have connectivity to an eANDSF and, therefore, may perform WLAN network discovery through other mechanisms, for example, using 802.11u.

Referring to <figref idref="DRAWINGS">FIG. 12</figref>, the STA <b>1204</b> may perform passive and/or active AP discovery <b>1205</b> as described in <figref idref="DRAWINGS">FIG. 9</figref>. The STA <b>1202</b> may perform one or more GAS message exchanges to perform Network discovery <b>1206</b>. For example, the STA <b>1202</b> may transmit a GAS message <b>1207</b> to AP <b>1204</b>, and receive a GAS response message <b>1208</b> from the AP <b>1204</b> in response.

The STA <b>1202</b> may perform open authentication <b>1209</b> and associate <b>1210</b> with the selected AP <b>1204</b>. Open authentication <b>1209</b> may not provide any security measures and may be skipped if an 802.1x/EAP method is used.

The AP <b>1204</b> may be referred to as the authenticator in this example, and may issue an EAP Request <b>1211</b> requesting a STA identity. The STA <b>1202</b> may return an EAP Response <b>1212</b> that may include a unique identity, for example, an international mobile subscriber Identity (IMSI) with its realm. The realm may include a hint to use SSO authentication, for example, IMSI@sso.MNO.com. The AP <b>1204</b> may transmit an Access Request <b>1213</b> to the AAA server <b>1201</b> using, for example, a RADIUS access request. The Access Request <b>1213</b> may include an EAP ID.

The OP unit of the AAA server <b>1201</b> may determine that the STA <b>1202</b> needs to be re-authenticated before transmitting an Access Accept message to the AP <b>1204</b>. Accordingly, one or more rounds of EAP-Challenge/Response messages may be exchanged before transmitting an EAP-Success message and keying material to the AP <b>1204</b>. For example, the AAA server <b>1201</b> may generate a challenge based on a STA-OP PSK <b>1214</b> and transmit an access challenge message <b>1215</b> to AP <b>1204</b>. The access challenge message <b>1215</b> may include an EAP ID and/or an EAP challenge. The AP <b>1204</b> may transmit an EAP-Request message <b>1215</b> to STA <b>1202</b> in response to the access challenge message <b>1215</b>. The EAP-Request message <b>1216</b> may include an identity and/or a challenge. The STA <b>1202</b> may receive the EAP-Request message <b>1216</b>, verify the MAC and generate an SRES <b>1217</b>, and transmit an EAP-Response message <b>1218</b> to the AP <b>1204</b>. The EAP-Response message <b>1218</b> may include an identity and/or a response to the challenge.

The AP <b>1204</b> may transmit an access request message <b>1219</b> to the AAA server <b>1201</b>, and receive an access accept message <b>1220</b> from the AAA server <b>1201</b> in response. The access request message <b>1219</b> may include an EAP ID and/or a response to the challenge. The access accept message <b>1220</b> may include an EAP ID, an indication of success, and the PMK key to the AP. In response to receiving the access accept message <b>1220</b>, the AP <b>1204</b> may transmit an EAP-Success message <b>1221</b> to the STA <b>1202</b>. In response to receiving the EAP-Success message <b>1221</b>, the STA <b>1202</b> generate a PMK <b>1222</b> using the STA-OP PSK, and may perform a 4-way handshake protocol <b>1223</b> with AP <b>1204</b>, request IP address assignment using DHCP <b>1224</b>, and access the internet over WLAN <b>1225</b>, as described in <figref idref="DRAWINGS">FIG. 9</figref> above.

<figref idref="DRAWINGS">FIG. 13</figref> is a diagram of an example method <b>1300</b> for a pre-established security association between a STA <b>1301</b> and a network to enable seamless authentication and fast initial link setup. In this example, Fast EAP may be encapsulated into 802.11 Authentication frames. This may assume that the STA <b>1301</b> and the network, for example an AAA server <b>1302</b> with integrated OP functionality, have already established security association and master keys that may be leveraged for secure access to the WLAN network. The STA may have successfully completed mutual authentication <b>1303</b> towards the AAA/OP over 3GPP access network and shared Master keys (PSK), and FILS Identity <b>1304</b> may have been established on both the STA <b>1301</b> and AAA server <b>1302</b>.

In this example, the 802.11 Authentication frames may encapsulate Fast EAP messages between the STA <b>1301</b> and the AP <b>1305</b>. In addition Snonce and Anonce may be exchanged using the Authentication frames, which may enable a 4-Way Handshake Protocol to be performed concurrently. For example, the STA <b>1301</b> may generate a Snonce <b>1306</b> and transmit an authentication message <b>1307</b> to the AP <b>1305</b>. The authentication message <b>1307</b> may include an EAP Response message, and indicate a sequence number, FILS ID, Snonce, and/or an Auth-tag. The AP <b>1305</b> may store <b>1308</b> the Snonce and transmit an access request message <b>1309</b> to the AAA server <b>1302</b>. The access request message <b>1309</b> may be an EAP message, and may include a FILS ID, a sequence number (SEQ), and/or an Auth-tag.

The AAA server <b>1302</b> may use the FILS identity to look up the pre-established security context with the STA <b>1301</b>. The AAA server <b>1302</b> may verify the sequence number. The server may then proceed to verify the integrity of the message using the integrity key, thereby verifying proof of possession of that key by the peer. If all verifications are successful, the AAA server <b>1302</b> may generate a PMK <b>1310</b> from a STA-OP PSK and transmit an access accept message <b>1311</b> to the AP <b>1305</b>. The access accept message may include a session key, for example a PMK, an EAP-Success message, an SEQ, a FILS ID, a Channel binding information (CB-Info) field, and/or an authentication tag (Auth-tag). The Auth-tag may enable a receiver, for example a STA or an AAA server, to verify the integrity of the received message and determine its validity. The AAA server <b>1302</b> may transmit CB-Info in an EAP message (not shown) so that the STA may verify that the EAP message was received via the correct AP and not a compromised AP.

If the STA <b>1301</b> includes an optional [IP_CFG_REQ] field in the authentication message <b>1307</b>, the AAA server <b>1302</b> may transmit the IP configurations to the STA <b>1301</b> in an [IP_CFG_Reply] field of the EAP-Success message. Note that the brackets may indicate optional fields.

In addition, the AAA server <b>1302</b> may transmit Channel binding information [CB-Info] in the EAP-Success message so that the STA <b>1301</b> may verify that the EAP message was received via the correct AP and not a compromised one.

In response to receiving the access accept message <b>1311</b>, the AP <b>1305</b> may derive a PTK <b>1312</b> from the PMK, Anonce, and/or Snonce, and generate a GTK. The AP <b>1305</b> may transmit an authentication message <b>1313</b> to the STA <b>1301</b>. The authentication message <b>1313</b> may include, for example, an EAP Success message that may indicate an SEQ, FILS ID, CB-Info, Anonce, and/or an Auth-tag.

In response to receiving the authentication message <b>1313</b>, the STA <b>1301</b> may derive a PTK <b>1314</b> and install the GTK. At the end of successful authentication, the STA <b>1301</b> and the AP <b>1305</b> may have the (PTG, GTK) Keys ready to protect data exchanged between STA <b>1301</b> and the AP <b>1305</b> over the 802.11 radio <b>1315</b>.

In the case where the STA <b>1301</b> may not have the necessary IP configurations, the STA <b>1301</b> may use, for example, an 802.11 Association frame exchange to provide the necessary IP address configurations for the FILS authenticated STA such that it may be ready to launch applications, for example, internet browsing, or switch ongoing sessions from one network, for example, 3GPP, to the WLAN network securely. For example, the STA <b>1301</b> may transmit an association message <b>1316</b> to the AP <b>1305</b>, and receive an association message <b>1317</b> in response from the AP <b>1305</b>. The association message <b>1316</b> may include an [IP-CFG-REQ] field, and the association message <b>1317</b> may include an [IP-CFG-Reply] field.

<figref idref="DRAWINGS">FIG. 14</figref> is a diagram of an example method <b>1400</b> for a pre-established security association between a STA <b>1401</b> and a network, for example, an AAA server <b>1402</b> to enable seamless authentication and fast initial link setup. In this example, Fast EAP may be encapsulated into 802.11 Association frames. The AAA server <b>1402</b> may be configured to perform OP functions.

This example may assume that the STA and the AAA server <b>1402</b> have already established security association and master keys that may be leveraged for secure access to the WLAN network. It may be assumed that the STA <b>1401</b> successfully completed mutual authentication <b>1403</b> towards the OP unit of the AAA server <b>1402</b> over a 3GPP access network and that shared Master keys (PSK) and FILS Identity <b>1404</b> are established on both the STA <b>1401</b> and AAA server <b>1402</b>.

In this example, the STA <b>1401</b> may generate a Snonce <b>1405</b>, and transmit an association frame <b>1406</b> to the AP <b>1407</b>. The association frame <b>1406</b> may include an EAP message, and indicate an SEQ, FILS ID, [IP-CFG-REQ], Snonce <b>1405</b>, and/or an Auth-tag. The AP <b>1407</b> may receive the association frame <b>1406</b> and store <b>1408</b> the Snonce <b>1405</b>. The AP <b>1407</b> may transmit an access request frame <b>1409</b> to the AAA server <b>1402</b>. The access request frame <b>1409</b> may include an EAP-Response message, and indicate an SEQ, FILS ID, [IP-CFG-REQ], and/or Auth-tag.

In response to receiving the access request frame <b>1409</b>, the AAA server <b>1402</b> may generate <b>1410</b> a PMK from the STA-OP PSK. The AAA server <b>1402</b> may transmit an access accept frame <b>1411</b> to the AP <b>1407</b>. The access accept frame <b>1411</b> may include a PMK and/or an EAP-Success message, and indicate an SEQ, FILS ID, [IP-CFG-Reply], [CB-Info], and/or an Auth-tag.

In response to receiving the access accept frame <b>1411</b>, the AP <b>1407</b> may derive <b>1412</b> a PTK from the PMK, Anonce, and/or Snonce, and generate a GTK. The AP <b>1407</b> may transmit an association frame <b>1413</b> to the STA <b>1401</b>. The association frame <b>1413</b> may include an EAP-Success message, and indicate an SEQ, FILS ID, [CB-Info], Anonce, [IP-CFG-Reply], and/or an Auth-tag. The STA <b>1401</b> may derive <b>1414</b> a PTK and install the GTK and access the internet over the WLAN <b>1415</b>.

In this example, the 802.11 Association frames may include at least the following: (1) Fast EAP messages between the STA and the AP; (2) Snonce and Anonce needed to complete the 4-Way Handshake Protocol concurrently; (3) [IP-CFG-REQ] from the STA to the AP and [IP-CFG-Reply] from the AP to the STA for concurrent IP address assignment. At the end of association, the FILS authenticated STA may have the necessary IP address configurations to access the WLAN network securely.

<figref idref="DRAWINGS">FIG. 15</figref>. is a diagram of an example method <b>1500</b> for a pre-established security association between a STA <b>1501</b> and a network, for example an AAA server <b>1502</b>, to enable seamless authentication and fast link setup. This example may be based on a Non-EAP FILS Authentication. The AAA server <b>1502</b> may be configured to perform OP and/or eANDSF functions.

This example may assume that the STA <b>1501</b> and the AAA server <b>1502</b> have already established security association and master keys that may be leveraged for secure access to the WLAN network. It may be assumed that the STA <b>1501</b> successfully completed mutual authentication <b>1503</b> towards the OP unit of the AAA server <b>1502</b> over, for example, a 3GPP access network, and that a shared Master keys (PSK) and FILS Identity are established <b>1504</b> on both the STA <b>1501</b> and AAA server <b>1502</b>.

In this example, the 802.11 Authentication frames carry non-EAP Authentication messages between the STA <b>1501</b> and the AP <b>1505</b>. In addition Anonce may be transmitted from the AP <b>1505</b> to the STA <b>1501</b> using the Authentication frames which may enable the STA <b>1501</b> to derive PTK.

The 802.11 Association frames may carry a Snonce from the STA <b>1501</b> to the AP <b>1505</b> such that the AP <b>1505</b> may derive a PTK on its side. In addition, the Association frames may carry an optional IP configuration request [IP-CFG-REQ] from the STA <b>1501</b> to the AP <b>1505</b> and [IP-CFG-Reply] from the AP <b>1505</b> to the STA <b>1501</b>. At the end of association, the FILS authenticated STA has the necessary IP address configurations to access the WLAN network securely.

For example, the STA <b>1501</b> may transmit an authentication message <b>1506</b> to the AP <b>1505</b>. The authentication message <b>1506</b> may include an SEQ, FILS ID, and/or an Auth-tag. In response to receiving the authentication message <b>1506</b>, the AP <b>1505</b> may transmit an access request message <b>1507</b> to the AAA server <b>1502</b>. The access request message <b>1507</b> may include an SEQ, FILS ID, and/or an Auth-tag. The AAA server may generate <b>1508</b> a PMK from the STA-OP PSK, and transmit an access accept message <b>1509</b> to the AP <b>1505</b>. The access accept message may include a PMK, SEQ, FILS ID, [CB-Info], and/or an Auth-tag.

In response to receiving the access accept message <b>1509</b>, the AP <b>1505</b> may transmit an authentication message <b>1510</b> to the STA <b>1501</b>. The authentication message <b>1510</b> may include an SEQ, [CB-Info], Anonce, and/or an Auth-tag. The STA <b>1501</b> may generate <b>1511</b> an Snonce, derive a PTK, and transmit an association message <b>1512</b> to the AP <b>1505</b>. The association message <b>1512</b> may include an Snonce, [IP-CFG-REQ], and/or an Auth-tag.

The AP <b>1505</b> may derive <b>1513</b> a PTK from the PMK, Anonce, and Snonce, and generate a GTK. The AP <b>1505</b> may transmit an association message <b>1514</b> to the STA <b>1501</b>. The association message <b>1514</b> may include a GTK, [IP-CFG-Reply], and/or an Auth-tag. In response to receiving the association message <b>1514</b>, the STA <b>1501</b> may install the GTK <b>1515</b>, and access the internet securely over the WLAN <b>1516</b>.

At the end of the AP discovery phase, ALS capable STAs and APs may negotiate ALS post-AP-discovery procedures based on the availability and amount of information the STAs and APs have pre-acquired about each other. This pre-acquired information may include, for example, one or more of network services information, TSF Information, 802.11 authentication and association information, EAP/802.1x authentication and security information, and IP address assignment information. Based on this available pre-acquired information, the STA or the AP may initiate negotiation of customized post-AP-discovery procedures.

Examples of signaling used for the Post-AP-Discovery procedure negotiations are shown in Table 3, where potential actions in each phase of the Post-AP-Discovery link setup process are listed and expressed by a binary sequence. A sequence of numbers beginning with “Ob” in Table <b>3</b> may indicate that the numbers after “0b” is an expression in the binary format.

<tables id="TABLE-US-00003" num="00003"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="63pt" align="left" /><colspec colname="1" colwidth="231pt" align="center" /><thead><row><entry /><entry namest="offset" nameend="1" rowsep="1">TABLE 3</entry></row></thead><tbody valign="top"><row><entry /><entry namest="offset" nameend="1" align="center" rowsep="1" /></row><row><entry /><entry>Examples of Negotiation Signaling</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="63pt" align="left" /><colspec colname="2" colwidth="21pt" align="center" /><colspec colname="3" colwidth="210pt" align="left" /><tbody valign="top"><row><entry>Phase</entry><entry># bits</entry><entry>Details</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Network Discovery</entry><entry>3</entry><entry>0b000: 802.11u</entry></row><row><entry /><entry /><entry>0b001: 802.11u-plus</entry></row><row><entry /><entry /><entry>0b010-0b110: reserved</entry></row><row><entry /><entry /><entry>0b111: skip Network Discovery Phase</entry></row><row><entry>Additional TSF</entry><entry>1</entry><entry>0b0: unchanged</entry></row><row><entry /><entry /><entry>0b1: skip Additional TSF</entry></row><row><entry>802.11</entry><entry>2</entry><entry>0b00: unchanged</entry></row><row><entry>Authentication</entry><entry /><entry>0b01-0b10: Reserved</entry></row><row><entry /><entry /><entry>0b11: skip 802.11 Authentication Phase</entry></row><row><entry>802.11 Association</entry><entry>2</entry><entry>0b00: unchanged</entry></row><row><entry /><entry /><entry>0b01: updated to carry more information elements;</entry></row><row><entry /><entry /><entry>0b10: reserved</entry></row><row><entry /><entry /><entry>0b11: skip 802.11 Association Phase</entry></row><row><entry>EAP/802.1x</entry><entry>4</entry><entry>0b0000: unchanged</entry></row><row><entry>Authentication &amp;</entry><entry /><entry>0b0001: use fast EAP authentication</entry></row><row><entry>Security</entry><entry /><entry>0b0010: use Fast EAP authentication and fast key provisioning</entry></row><row><entry /><entry /><entry>0b0011: Fast network discovery and fast EAP authentication;</entry></row><row><entry /><entry /><entry>0b0100: Fast network discovery, fast EAP authentication, and fast key</entry></row><row><entry /><entry /><entry>provisioning.</entry></row><row><entry /><entry /><entry>0b0101-0b1110: reserved</entry></row><row><entry /><entry /><entry>0b1111: skip EAP/802.1x Authentication &amp; Security Phase</entry></row><row><entry>IP Address</entry><entry>3</entry><entry>0b000: unchanged;</entry></row><row><entry>Assignment</entry><entry /><entry>0b001: do it in Layer-2 messages,</entry></row><row><entry /><entry /><entry>0b010-0b110: reserved</entry></row><row><entry /><entry /><entry>0b111: skip IP address assignment Phase</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

An implementation of post-AP-discovery negotiation signaling may be multi-fold. For example, post-AP-discovery negotiation may be implemented using the FILS management action frame described above, where the negotiation signaling code for each phase of the post-AP discovery may be located in a corresponding field in the FILS management action frame. In another example, the negotiation signaling codes may be implemented as a bit map in IEs of AP discovery messages, for example, in the I-Know-You IE and/or I-know-you-response IEs. In another example, the negotiation signaling codes may be implemented in IEs included in other management and control frames, such as beacon, probe requests and probe responses.

Using the example encoding in Table 3, a 15-bit ALS information field may be included by the STA or the AP to express its most optimized post-AP-discovery link setup procedure. The ALS information field may be segmented into different sizes of segments, each segment corresponding to a post-AP-discovery link setup phase. The bit order in the identifier may be the same order of the functional phases illustrated in Table 3, for example, bits <b>14</b> and <b>13</b> corresponding to network a discovery phase.

If, for example, the AP has pre-acquired identity information of a candidate STA, such as the MAC address and/or service need information, the AP may determine that the network discovery, additional TSF, and 802.11 authentication phases may be skipped and the link setup procedure should go through the 802.11 association, EAP authentication, and/or DHCP-based IP address assignment phases when the AP receives a frame from the STA, for example, a probe request frame. The AP may, therefore, transmit a probe response frame to the STA with an I-know-you IE including a 15-bit Post-AP-discovery procedure code of “0b111 1110 0000 0000”. If the STA receives such a post-AP-discovery procedure code, the STA may either transmit an I-know-you-response IE with the same or revised code in a management frame to confirm or revise the post-AP-discovery procedure, or it may implicitly accept it by directly proceeding to the next phase as suggested by the code, for example, 802.11 association. In this way, the AP may initiate the link setup optimizations by using its pre-acquired knowledge about the STA.

In another example, when a STA includes the ALS Information Field “0b111 111 01 0010 001” for its ALS Post-AP-Discovery procedure in its probe request frame to a preferred AP, the STA may be indicating to the AP one or more of the following: the most optimized ALS post-AP-discovery procedure with this particular AP may include the phases of network discovery, and additional TSF and 802.11 authentication may be skipped; a modified 802.11 association phase may be used; a fast EAP authentication and fast key provisioning scheme may be used; and/or an optimized IP address assignment may be used, for example, by carrying one or more DHCP messages in one or more Layer-2 messages. The AP receiving a probe request that indicates that the STA is a STA with pre-acquired information, may transmit a probe response frame using a similar sequence depending on the amount of information the AP has pre-acquired about the STA. The STA receiving the probe request may respond by transmitting a FILS management action frame to confirm the agreed optimized and customized ALS post-AP-discovery procedure.

When an AP and a STA negotiate the post-AP-discovery procedure, if for one or more phases of the link setup processes of the AP and STA have different requirements, then the stricter requirement may prevail. An example of the different requirements may be where the STA may request to skip the network discovery phase while the AP may request an 802.11u network discovery phase. In this example, the STA may agree to an 802.11u network discovery phase at the request of the AP. In addition, the final agreed upon optimized ALS post-AP-discovery procedure may be positively confirmed for the correct functioning of the ALS. Such a confirmation may be achieved by transmitting a FILS management action frame including the agreed ALS post-AP-discovery procedure and an ALS information field indicating the agreed upon ALS post-AP-discovery procedure in a unicast frame, such as a probe request frame, a probe response frame, an association request frame, etc., to the corresponding STA or AP.

Another example method may include using pre-acquired system configuration knowledge. The system configuration for this example may be referred to as a set of system parameters that are either static or semi-static for a specific system deployment and operational mode. Such system parameters may also be referred to as system configuration parameters, and the “system” in this context may refer to the IEEE 802.11-based Wireless LAN systems.

The system configuration may be pre-acquired by the STA prior to initiating a link setup process with a BSS/AP, and it may be used to accelerate the initial link setup process.

System configuration parameter sets may be defined. For example, to specify the operational mode of a Wireless LAN system, the following three different configurations may be defined and used: (1) BSS/AP configuration, also referred to as the BSS configuration or AP configuration; (2) Access Network configuration; and (3) Combined AP/Network configuration also referred to as the AP/Network configuration.

Each of the above configurations may contain a set of system parameters that specifies the corresponding system operational settings. The AP configuration parameter set may include the BSS/AP operational parameters/descriptors that are static or semi-static over time with regard to value changes.

In order to use system configuration information as pre-acquired knowledge to accelerate the link setup process, the following basic criteria may be applied to select the AP configuration parameters: (a) the parameters that may be used to start a BSS/AP operation, for example, the parameters used in the MLME_START.request primitives in 802.11; (b) the parameters that may be used to specify BSS/AP operation settings that may be communicated between an AP and STAs, for example, in a Beacon frame or Probe Response frame, etc.; (c) the parameters that may not dynamically change the values over time, for example, keeping the same values for hours, days, even months; and/or (d) the parameters that may be relevant for link setup.

Based on the basic selection criteria, Table 4 below provides an example of an infrastructure BSS/AP configuration parameter set.

<tables id="TABLE-US-00004" num="00004"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="357pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 4</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>An Example of Infrastructure BSS/AP Configuration Parameter Set</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="84pt" align="left" /><colspec colname="1" colwidth="105pt" align="center" /><colspec colname="2" colwidth="168pt" align="left" /><tbody valign="top"><row><entry /><entry>Value</entry><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="5"><colspec colname="1" colwidth="84pt" align="left" /><colspec colname="2" colwidth="35pt" align="left" /><colspec colname="3" colwidth="70pt" align="left" /><colspec colname="4" colwidth="91pt" align="left" /><colspec colname="5" colwidth="77pt" align="left" /><tbody valign="top"><row><entry>Parameter</entry><entry>present</entry><entry /><entry /><entry /></row><row><entry>Name</entry><entry>indicator</entry><entry>Valid Value Range</entry><entry>Description</entry><entry>Additional Notes</entry></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row><row><entry>BSSID</entry><entry>Must</entry><entry>6-byte MAC</entry><entry>6-byte MAC address of the</entry><entry>in MAC frame header</entry></row><row><entry /><entry>present</entry><entry>address of the AP</entry><entry>AP STA</entry><entry>sent by the AP STA</entry></row><row><entry /><entry /><entry>STA</entry></row><row><entry>SSID</entry><entry>Must</entry><entry>Octet string, 0-32</entry><entry>The SSID of the BSS.</entry><entry>in Beacon/Probe</entry></row><row><entry /><entry>present</entry><entry>octets</entry><entry /><entry>Response/FD frame</entry></row><row><entry>SSIDEncoding</entry><entry>Present/</entry><entry>Enumeration:</entry><entry>The encoding used for the</entry><entry>in the exended</entry></row><row><entry /><entry>Not-</entry><entry>UNSPECIFIED,</entry><entry>SSID</entry><entry>capability IE in Beacon/</entry></row><row><entry /><entry>Present</entry><entry>Universal Character</entry><entry /><entry>Probe Response;</entry></row><row><entry /><entry /><entry>Set (UCS)</entry></row><row><entry /><entry /><entry>Transformation</entry></row><row><entry /><entry /><entry>Format 8 (UTF8).</entry></row><row><entry /><entry /><entry>This value may be</entry></row><row><entry /><entry /><entry>an 8 bit value.</entry></row><row><entry>BSSType</entry><entry>Present/</entry><entry>Enumeration:</entry><entry>The type of the BSS.</entry><entry>in the capability IE in</entry></row><row><entry /><entry>Not-</entry><entry>INFRASTRUCTURE,</entry><entry /><entry>Beacon/Probe</entry></row><row><entry /><entry>Present</entry><entry>INDEPENDENT,</entry><entry /><entry>Response;</entry></row><row><entry /><entry /><entry>MESH</entry></row><row><entry>BeaconPeriod</entry><entry>Present/</entry><entry>Integer: &gt;=1</entry><entry>The Beacon period (in Time</entry><entry>Beacon Interval in</entry></row><row><entry /><entry>Not-</entry><entry /><entry>Unit (TU)) of the BSS.</entry><entry>Beacon/Probe</entry></row><row><entry /><entry>Present</entry><entry /><entry /><entry>Response.</entry></row><row><entry>Contention Free</entry><entry>Present/</entry><entry>The CF Parameter</entry><entry>The parameter set for CF</entry><entry>in Beacon/Probe</entry></row><row><entry>(CF) parameter</entry><entry>Not-</entry><entry>Set element</entry><entry>periods, if the BSS supports</entry><entry>Response</entry></row><row><entry>set</entry><entry>Present</entry><entry>contains the set of</entry><entry>CF mode.</entry></row><row><entry /><entry /><entry>parameters</entry></row><row><entry /><entry /><entry>necessary to</entry></row><row><entry /><entry /><entry>support the point</entry></row><row><entry /><entry /><entry>coordination</entry></row><row><entry /><entry /><entry>function (PCF). The</entry></row><row><entry /><entry /><entry>Information</entry></row><row><entry /><entry /><entry>field contains the</entry></row><row><entry /><entry /><entry>CFPCount,</entry></row><row><entry /><entry /><entry>CFPPeriod,</entry></row><row><entry /><entry /><entry>CFPMaxDuration,</entry></row><row><entry /><entry /><entry>and</entry></row><row><entry /><entry /><entry>CFPDurRemaining</entry></row><row><entry /><entry /><entry>fields. The total</entry></row><row><entry /><entry /><entry>length</entry></row><row><entry /><entry /><entry>of the Information</entry></row><row><entry /><entry /><entry>field is 6 octets.</entry></row><row><entry>PHY parameter</entry><entry>Present/</entry><entry>The Information</entry><entry>The parameter sets relevant</entry><entry>in Beacon/Probe</entry></row><row><entry>set</entry><entry>Not-</entry><entry>field may contain</entry><entry>to the PHY</entry><entry>Response</entry></row><row><entry /><entry>Present</entry><entry>Dwell Time, Hop</entry></row><row><entry /><entry /><entry>Set, Hop Pattern,</entry></row><row><entry /><entry /><entry>and Hop Index</entry></row><row><entry /><entry /><entry>parameters. The</entry></row><row><entry /><entry /><entry>total length of the</entry></row><row><entry /><entry /><entry>Information field</entry></row><row><entry /><entry /><entry>may be 5 octets.</entry></row><row><entry /><entry /><entry>Alternatively, the</entry></row><row><entry /><entry /><entry>Information field</entry></row><row><entry /><entry /><entry>may contain a</entry></row><row><entry /><entry /><entry>single parameter</entry></row><row><entry /><entry /><entry>containing the</entry></row><row><entry /><entry /><entry>dot11CurrentChannel,</entry></row><row><entry /><entry /><entry>and may be 1</entry></row><row><entry /><entry /><entry>octet in length.</entry></row><row><entry>CapabilityInformation</entry><entry>Present/</entry><entry>The length of the</entry><entry>The capabilities to be</entry><entry>in Beacon/Probe</entry></row><row><entry /><entry>Not-</entry><entry>Capability</entry><entry>advertised for the BSS.</entry><entry>Response</entry></row><row><entry /><entry>Present</entry><entry>Information field</entry></row><row><entry /><entry /><entry>may be 2 octets.</entry></row><row><entry>BSSBasicRateSet</entry><entry>Present/</entry><entry>Set of Integers:</entry><entry>The set of data rates that</entry><entry>in the Supported Rates</entry></row><row><entry /><entry>Not-</entry><entry>1-127 inclusive (for</entry><entry>shall be supported by all</entry><entry>IE in Beacon/Probe</entry></row><row><entry /><entry>Present</entry><entry>each integer in the</entry><entry>STAs to join this BSS. The</entry><entry>Response</entry></row><row><entry /><entry /><entry>set)</entry><entry>STA that is creating the BSS</entry></row><row><entry /><entry /><entry /><entry>shall be able to receive and</entry></row><row><entry /><entry /><entry /><entry>transmit at each of the data</entry></row><row><entry /><entry /><entry /><entry>rates listed in the set.</entry></row><row><entry>OperationalRate</entry><entry>Present/</entry><entry>Set of Integers:</entry><entry>The set of data rates that the</entry><entry>in the Supported Rates</entry></row><row><entry>Set</entry><entry>Not-</entry><entry>1-127 inclusive (for</entry><entry>STA desires to use for</entry><entry>IE, extended supported</entry></row><row><entry /><entry>Present</entry><entry>each integer in the</entry><entry>communication within the</entry><entry>Rates IE, and/or ERP IE</entry></row><row><entry /><entry /><entry>set)</entry><entry>BSS. The STA shall be able</entry><entry>in Beacon/Probe</entry></row><row><entry /><entry /><entry /><entry>to receive at each of the</entry><entry>Response</entry></row><row><entry /><entry /><entry /><entry>data rates listed in the set.</entry></row><row><entry /><entry /><entry /><entry>This set is a superset of the</entry></row><row><entry /><entry /><entry /><entry>rates contained in the</entry></row><row><entry /><entry /><entry /><entry>BSSBasicRateSet</entry></row><row><entry /><entry /><entry /><entry>parameter.</entry></row><row><entry>Country</entry><entry>Present/</entry><entry>The length may be</entry><entry>The information required to</entry><entry>in Beacon/Probe</entry></row><row><entry /><entry>Not-</entry><entry>6 to 7 octets.</entry><entry>identify the regulatory</entry><entry>Response</entry></row><row><entry /><entry>Present</entry><entry /><entry>domain in which the STA is</entry></row><row><entry /><entry /><entry /><entry>located and to configure its</entry></row><row><entry /><entry /><entry /><entry>PHY for operation in that</entry></row><row><entry /><entry /><entry /><entry>regulatory domain.</entry></row><row><entry>EDCAParameter</entry><entry>Present/</entry><entry>The length may be</entry><entry>The initial enhanced</entry><entry>in Beacon/Probe</entry></row><row><entry>Set</entry><entry>Not-</entry><entry>20 octets.</entry><entry>distributed channel access</entry><entry>Response</entry></row><row><entry /><entry>Present</entry><entry /><entry>(EDCA) parameter set</entry></row><row><entry /><entry /><entry /><entry>values to be used in the</entry></row><row><entry /><entry /><entry /><entry>BSS.</entry></row><row><entry>DSERegisteredLocation</entry><entry>Present/</entry><entry>The length may be</entry><entry>The information for the data</entry><entry>in Beacon/Probe</entry></row><row><entry /><entry>Not-</entry><entry>22 octets.</entry><entry>service element (DSE)</entry><entry>Response</entry></row><row><entry /><entry>Present</entry><entry /><entry>Registered Location</entry></row><row><entry /><entry /><entry /><entry>element.</entry></row><row><entry>High Throughput</entry><entry>Present/</entry><entry>The length may be</entry><entry>The HT capabilities to be</entry><entry>in Beacon/Probe</entry></row><row><entry>(HT) Capabilities</entry><entry>Not-</entry><entry>28 octets.</entry><entry>advertised for the BSS.</entry><entry>Response</entry></row><row><entry /><entry>Present</entry></row><row><entry>HT Operation</entry><entry>Present/</entry><entry>The length may be</entry><entry>The additional HT</entry><entry>in Beacon/Probe</entry></row><row><entry /><entry>Not-</entry><entry>24 octets.</entry><entry>capabilities to be advertised</entry><entry>Response</entry></row><row><entry /><entry>Present</entry><entry /><entry>for the BSS.</entry></row><row><entry>BSSMembership</entry><entry>Present/</entry><entry>set of integers: A</entry><entry>The BSS membership</entry><entry>included as one value</entry></row><row><entry>SelectorSet</entry><entry>Not-</entry><entry>value from Table 8-</entry><entry>selectors that represent the</entry><entry>setting in Supported rate</entry></row><row><entry /><entry>Present</entry><entry>55 for each</entry><entry>set of features that shall be</entry><entry>IE, in Beacon/Probe</entry></row><row><entry /><entry /><entry>member of the set.</entry><entry>supported by all STAs to join</entry><entry>Response</entry></row><row><entry /><entry /><entry /><entry>this BSS. The STA that is</entry></row><row><entry /><entry /><entry /><entry>creating the BSS shall be</entry></row><row><entry /><entry /><entry /><entry>able to support each of the</entry></row><row><entry /><entry /><entry /><entry>features represented by the</entry></row><row><entry /><entry /><entry /><entry>set.</entry></row><row><entry>BSSBasicMCSSet</entry><entry>Present/</entry><entry>set of integers:</entry><entry>The set of modulation and</entry><entry>included as one subfield</entry></row><row><entry /><entry>Not-</entry><entry>Each representing</entry><entry>coding scheme (MCS)</entry><entry>in the HT operation IE in</entry></row><row><entry /><entry>Present</entry><entry>an MAC index</entry><entry>values that shall be</entry><entry>Beacon/Probe</entry></row><row><entry /><entry /><entry>value in the range 0</entry><entry>supported by all HT STAs to</entry><entry>Response</entry></row><row><entry /><entry /><entry>to 76.</entry><entry>join this BSS. The STA that</entry></row><row><entry /><entry /><entry /><entry>is creating the BSS shall be</entry></row><row><entry /><entry /><entry /><entry>able to receive and transmit</entry></row><row><entry /><entry /><entry /><entry>at each of the MCS values</entry></row><row><entry /><entry /><entry /><entry>listed in the set.</entry></row><row><entry>HTOperationalMCSSet</entry><entry>Present/</entry><entry>set of integers:</entry><entry>The set of MCS values that</entry><entry>included as one subfield</entry></row><row><entry /><entry>Not-</entry><entry>Each representing</entry><entry>the STA desires to use for</entry><entry>in the HT capability IE in</entry></row><row><entry /><entry>Present</entry><entry>an MAC index</entry><entry>communication within the</entry><entry>Beacon/Probe</entry></row><row><entry /><entry /><entry>value in the range 0</entry><entry>BSS. The STA shall be able</entry><entry>Response.</entry></row><row><entry /><entry /><entry>to 76.</entry><entry>to receive at each of the</entry></row><row><entry /><entry /><entry /><entry>data rates listed in the set.</entry></row><row><entry /><entry /><entry /><entry>This set is a superset of the</entry></row><row><entry /><entry /><entry /><entry>MCS values contained in the</entry></row><row><entry /><entry /><entry /><entry>BSSBasicMCSSet</entry></row><row><entry /><entry /><entry /><entry>parameter.</entry></row><row><entry>Extended</entry><entry>Present/</entry><entry>The length may be</entry><entry>Specifies the parameters</entry><entry>in Beacon/Probe</entry></row><row><entry>Capabilities</entry><entry>Not-</entry><entry>variable.</entry><entry>within the Extended</entry><entry>Response</entry></row><row><entry /><entry>Present</entry><entry /><entry>Capabilities element that are</entry></row><row><entry /><entry /><entry /><entry>supported by the MAC</entry></row><row><entry /><entry /><entry /><entry>entity.</entry></row><row><entry>20/40 BSS</entry><entry>Present/</entry><entry>The length may be</entry><entry>Specifies the parameters</entry><entry>in Beacon/Probe</entry></row><row><entry>Coexistence</entry><entry>Not-</entry><entry>3 octets.</entry><entry>within the 20/40 BSS</entry><entry>Response</entry></row><row><entry /><entry>Present</entry><entry /><entry>Coexistence element that</entry></row><row><entry /><entry /><entry /><entry>are indicated by the MAC</entry></row><row><entry /><entry /><entry /><entry>entity.</entry></row><row><entry>Overlapping BSS</entry><entry>Present/</entry><entry>The length may be</entry><entry>Specifies the parameters</entry><entry>in Beacon/Probe</entry></row><row><entry>Scan Parameters</entry><entry>Not-</entry><entry>16 octets.</entry><entry>within the Overlapping BSS</entry><entry>Response</entry></row><row><entry /><entry>Present</entry><entry /><entry>Scan Parameters element</entry></row><row><entry /><entry /><entry /><entry>that are indicated by the</entry></row><row><entry /><entry /><entry /><entry>MAC entity.</entry></row><row><entry>MultipleBSSID</entry><entry>Present/</entry><entry>The length may be</entry><entry>Specify the multiple BSSID</entry><entry>in Beacon/Probe</entry></row><row><entry /><entry>Not-</entry><entry>variable.</entry><entry>information when the AP is a</entry><entry>Response</entry></row><row><entry /><entry>Present</entry><entry /><entry>member of a Multiple BSSID</entry></row><row><entry /><entry /><entry /><entry>Set with two or more</entry></row><row><entry /><entry /><entry /><entry>members.</entry></row><row><entry>InterworkingInfo</entry><entry>Present/</entry><entry>The length may be</entry><entry>Specifies the Interworking</entry><entry>in Beacon/Probe</entry></row><row><entry /><entry>Not-</entry><entry>3, 5, 9, or 11</entry><entry>capabilities of STA.</entry><entry>Response</entry></row><row><entry /><entry>Present</entry><entry>octets.</entry></row><row><entry>AdvertismentProtocolInfo</entry><entry>Present/</entry><entry>0-255</entry><entry>Identifies zero or more</entry><entry>in Beacon/Probe</entry></row><row><entry /><entry>Not-</entry><entry /><entry>Advertisement Protocols and</entry><entry>Response</entry></row><row><entry /><entry>Present</entry><entry /><entry>advertisement control to be</entry></row><row><entry /><entry /><entry /><entry>used in the BSSs.</entry></row><row><entry>RoamingConsortiumInfo</entry><entry>Present/</entry><entry>The length may be</entry><entry>Specifies identifying</entry><entry>in Beacon/Probe</entry></row><row><entry /><entry>Not-</entry><entry>variable.</entry><entry>information for subscription</entry><entry>Response</entry></row><row><entry /><entry>Present</entry><entry /><entry>service provider (SSP)s</entry></row><row><entry /><entry /><entry /><entry>whose security credentials</entry></row><row><entry /><entry /><entry /><entry>can be used to authenticate</entry></row><row><entry /><entry /><entry /><entry>with the AP.</entry></row><row><entry>Power Constraint</entry><entry>Present/</entry><entry>The length may be</entry><entry>contains the information</entry><entry>in Beacon/Probe</entry></row><row><entry /><entry>Not-</entry><entry>3 octets.</entry><entry>necessary to allow a STA to</entry><entry>Response</entry></row><row><entry /><entry>Present</entry><entry /><entry>determine the local</entry></row><row><entry /><entry /><entry /><entry>maximum transmit power in</entry></row><row><entry /><entry /><entry /><entry>the current channel.</entry></row><row><entry>RSN</entry><entry>Present/</entry><entry>The length may be</entry><entry>contains authentication and</entry><entry>in Beacon/Probe</entry></row><row><entry /><entry>Not-</entry><entry>up to 255 octets.</entry><entry>pairwise cipher suite</entry><entry>Response</entry></row><row><entry /><entry>Present</entry><entry /><entry>selectors, a single group</entry></row><row><entry /><entry /><entry /><entry>data cipher suite selector, an</entry></row><row><entry /><entry /><entry /><entry>RSN Capabilities field, the</entry></row><row><entry /><entry /><entry /><entry>PMK identifier (PMKID)</entry></row><row><entry /><entry /><entry /><entry>count, a PMKID list, and a</entry></row><row><entry /><entry /><entry /><entry>single group management</entry></row><row><entry /><entry /><entry /><entry>cipher suite selector.</entry></row><row><entry>AP Channel</entry><entry>Present/</entry><entry>The length may be</entry><entry>contains a list of channels</entry><entry>in Beacon/Probe</entry></row><row><entry>Report</entry><entry>Not-</entry><entry>variable.</entry><entry>where a STA is likely to find</entry><entry>Response</entry></row><row><entry /><entry>Present</entry><entry /><entry>an AP.</entry></row><row><entry>Supported</entry><entry>Present/</entry><entry>The length may be</entry><entry>advertise the operating</entry><entry>in Beacon/Probe</entry></row><row><entry>Regulatory</entry><entry>Not-</entry><entry>between 2 and 253</entry><entry>classes that it is capable of</entry><entry>Response</entry></row><row><entry>Classes</entry><entry>Present</entry><entry>octets.</entry><entry>operating in the country.</entry></row><row><entry>VendorSpecificInfo</entry><entry>Present/</entry><entry>The length may be</entry><entry>containing vendor-specific</entry><entry>in Beacon/Probe</entry></row><row><entry /><entry>Not-</entry><entry>variable.</entry><entry>information.</entry><entry>Response</entry></row><row><entry /><entry>Present</entry></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

The example BSS/AP configuration parameter set above is per BSS/AP that is identified by the BSSID, for example the 6-byte MAC address of the AP.

As shown in Table 4, each parameter in the AP configuration parameter set has a present-indicator to indicate whether or not the value of the parameter is present in a specific configuration instance. A configuration instance may be referred to as a configuration indicator. This may allow a subset of the parameters in the configuration set to specify a specific BSS/AP operation mode with the use of a specific PHY mode and/or the selection of certain optional system features and functionalities, for example, QoS support, Interworking services, etc.

The Access Network configuration parameter set may include the static or semi-static operational parameters or descriptors of the access network behind the BSS/AP that may be relevant to link setup of STAs. Similarly, in order to use the access network configuration information as the pre-acquired knowledge to accelerate the link setup process, the following basic criteria may be applied to select the access network configuration parameters: (a) the parameters that may be used to specify the access network services, capabilities, attributes, and/or functionalities, for example, those parameters used in the access network discovery messages, such as access network query protocol (ANQP/GAS; (b) the parameters that may not dynamically change the values over time, for example, keeping the same values for hours, days, even months; and/or (c) the parameters that may be relevant for link setup.

Based on the above selection criteria, Table 5 below provides an example access network configuration parameter set.

<tables id="TABLE-US-00005" num="00005"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="287pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 5</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>An Example of Access Network Configuration Parameter Set</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="70pt" align="left" /><colspec colname="2" colwidth="63pt" align="left" /><colspec colname="3" colwidth="154pt" align="left" /><tbody valign="top"><row><entry>Parameter Name</entry><entry>Present Indicator</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Venue Name</entry><entry>Present/not-present</entry><entry>Provides zero or more venue names associated</entry></row><row><entry>information</entry><entry /><entry>with the BSS.</entry></row><row><entry>Emergency Call</entry><entry>Present/not-present</entry><entry>provides a list of emergency phone numbers to an</entry></row><row><entry>Number information</entry><entry /><entry>emergency responder, such as directed by a public</entry></row><row><entry /><entry /><entry>safety answering point (PSAP), that is used in the</entry></row><row><entry /><entry /><entry>geographic location of the STA.</entry></row><row><entry>Network</entry><entry>Present/not-present</entry><entry>provides a list of authentication types.</entry></row><row><entry>Authentication Type</entry></row><row><entry>Roaming Consortium</entry><entry>Present/not-present</entry><entry>provides a list of information about the Roaming</entry></row><row><entry /><entry /><entry>Consortium and/or SSPs whose networks are</entry></row><row><entry /><entry /><entry>accessible via this AP.</entry></row><row><entry>IP Address Type</entry><entry>Present/not-present</entry><entry>provides STA with the information about the</entry></row><row><entry>Availability</entry><entry /><entry>availability of IP address version and type that</entry></row><row><entry /><entry /><entry>could be allocated to the STA after successful</entry></row><row><entry /><entry /><entry>association.</entry></row><row><entry>NAI Realm</entry><entry>Present/not-present</entry><entry>provides a list of network access identifier (NAI)</entry></row><row><entry /><entry /><entry>realms corresponding to SSPs or other entities</entry></row><row><entry /><entry /><entry>whose networks or services are accessible via this</entry></row><row><entry /><entry /><entry>AP; optionally included for each NAI realm is a list</entry></row><row><entry /><entry /><entry>of one or more EAP Method subfields, which that</entry></row><row><entry /><entry /><entry>NAI realm uses for authentication.</entry></row><row><entry>3GPP Cellular</entry><entry>Present/not-present</entry><entry>contains cellular information such as network</entry></row><row><entry>Network</entry><entry /><entry>advertisement information e.g., network codes and</entry></row><row><entry /><entry /><entry>country codes to assist a 3GPP non-AP STA in</entry></row><row><entry /><entry /><entry>selecting an AP to access 3GPP networks.</entry></row><row><entry>AP Geospatial</entry><entry>Present/not-present</entry><entry>provides the AP's location in LCI (Location</entry></row><row><entry>Location</entry><entry /><entry>Configuration Information) format, which includes</entry></row><row><entry /><entry /><entry>Latitude, Longitude, Altitude, and optional Azimuth</entry></row><row><entry /><entry /><entry>information.</entry></row><row><entry>AP Civic Location</entry><entry>Present/not-present</entry><entry>provides the AP's location in Civic format.</entry></row><row><entry>AP Location Public</entry><entry>Present/not-present</entry><entry>provides an indirect reference to the location</entry></row><row><entry>Identifier URI</entry><entry /><entry>information for the AP.</entry></row><row><entry>Domain Name</entry><entry>Present/not-present</entry><entry>provides a list of one or more domain names of the</entry></row><row><entry /><entry /><entry>entity operating the IEEE 802.11 access network.</entry></row><row><entry>Emergency Alert</entry><entry>Present/not-present</entry><entry>provides a Uniform Resource Identifier (URI) for</entry></row><row><entry>Identifier URI</entry><entry /><entry>EAS message retrieval.</entry></row><row><entry>Tunneled Direct Link</entry><entry>Present/not-present</entry><entry>Contains the information to be used by a STA to</entry></row><row><entry>Setup (TDLS)</entry><entry /><entry>discover the TDLS capabilities of a peer STA.</entry></row><row><entry>capability</entry></row><row><entry>Emergency NAI</entry><entry>Present/not-present</entry><entry>contains an emergency string, which is available</entry></row><row><entry /><entry /><entry>for use by a STA as its identity to indicate</entry></row><row><entry /><entry /><entry>emergency access request.</entry></row><row><entry>Neighbor Report</entry><entry>Present/not-present</entry><entry>provides zero or more neighbor reports about</entry></row><row><entry /><entry /><entry>neighboring APs.</entry></row><row><entry>vendor-specific</entry><entry>Present/not-present</entry><entry>Contains vendor specific information about the</entry></row><row><entry /><entry /><entry>access network.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

Similarly, the above access network configuration parameter set may be per BSS/AP, where the access network may be the network that the STA may connect to through the Wireless LAN of the BSS/AP. Also, as shown in Table 5, for each parameter in the access network configuration parameter set, a present-indicator may be used to indicate whether or not the value of the parameter is present in a specific configuration instance, such that a subset of configuration parameters may be allowed to specify a specific network operation with the selected optional features and functionalities, for example, emergency alert service, etc.

As an alternative to defining separate AP and network configuration parameter sets, a combined single AP/Network configuration parameter set may be defined to specify the operation settings and services of both the AP and access network. The combined single AP/Network configuration parameter may contain the operational parameters/descriptors for both the BSS/AP and the access network.

The selection criteria of a combined AP/Network configuration parameter set may be a combination of the AP configuration parameter selection criteria and the access network configuration selection criteria. In addition, the two parameter sets in Table 4 and Table 5 may be combined to provide an example of a combined AP/network configuration parameter set.

A system configuration instance with a configuration change count may be identified. A system configuration instance may refer to a configuration parameter set with specific values assigned to each of the configuration parameters. The configuration parameters may be used to specify a corresponding system operational mode. If a configuration parameter set may be defined for a system with optional features or functionalities, and a configuration instance may include a subset of configuration parameters with valid values, while the remaining parameters may be marked as “not-present.”

Any changes to a configuration instance may result in a new configuration instance, for example, a parameter value change, or a “not-present” parameter changed to “present” with a valid value assigned, or a “present” parameter changed to “not-present,” etc. A configuration instance may be identified by its version number, also referred to as a Configuration Change Count (CCC), or a Configuration Sequence Number (CSN). The CCC may be an integer variable whose value may change every time a configuration instance changes. The CCC may be changed based on a pre-defined function. One example may be that the CCC increments by 1 every time a configuration instance changes and wraps around to 0 once reaching its maximum value.

A BSS/AP configuration may be defined per BSS/AP, which may be identified by the BSSID, for example, the MAC address of the AP. An AP Configuration Change Count (AP-CCC) may be used to identify an instance of AP configuration. Accordingly, a combination of BSSID, configuration type, and/or AP-CCC, for example, may be used to identify a configuration instance of the given AP, where the configuration type may indicate a specific configuration among the multiple configurations that may be defined and used, for example, BSS/AP configuration, access network configuration, etc.

Similarly, an integer variable, such as an Access Network Configuration Change Count (AN-CCC), may be used to identify the version number of an Access Network configuration instance. A combination of BSSID, configuration type, and/or AN-CCC, may be used to identify a configuration instance of the access network through an AP.

If a combined AP/Network configuration is used, then an integer variable, such as an AP/Access Network Configuration Change Count (AP/AN-CCC), may be used to identify the version number of a combined configuration instance. For example, a combination of BSSID, configuration type, and/or AP/AN-CCC, may be used to identify a configuration instance of an AP and the access network through the AP.

System information communication may be performed with pre-defined system configuration parameter sets. In Wireless LAN systems, the system information, for example, the BSS/AP operational parameters, access network functionalities, and/or attributes, etc., may be communicated to STAs for initial link setup and for link resumption when returning from power saving modes. The system configuration parameter sets may be defined to improve the efficiency of the system information communication between AP/Network and the STAs.

When system configurations are used to facilitate efficient system communications, the definitions of the system configuration parameter sets may be known by the AP/Network and STAs. One method to meet such a requirement may be to standardize the definitions of the configuration parameter sets through Standard Bodies, for example, IEEE 802. Alternatively, the definitions of the system configuration parameter sets may be communicated first between the AP/Network and the STAs through the wireless link and/or wired links, before the configuration may be used.

Pre-defined system configuration parameter sets may be used at the AP/Network and STAs. The following examples summarize how the AP/Network may support the use of pre-defined system parameter sets to communicate the system information with STAs.

In a first example, for each defined/used system configuration parameter set, the AP may maintain the configuration instance and its corresponding CCC, for example, AP-CCC, AN-CCC, and/or AP/AN-CCC, including updating the Configuration Change Count every time the configuration instance changes.

In a second example, the AP may provide AP system information based on a pre-defined BSS/AP configuration parameter set. This example may include providing a full BSS/AP configuration instance with its corresponding AP-CCC, for example, in a Beacon frame and/or Probe Response frame. Alternatively, the AP may provide AP system information through AP-CCC only, for example, in a FILS Discovery Frame, Short Beacon frame, etc.

In a third example, the AP may provide access network system information based on a pre-defined Access Network configuration parameter set. For example, the AP may provide a full access network configuration instance with its corresponding AN-CCC, for example, in the GAS/ANQP frames. Alternatively, the AP may provide access network information through AN-CCC only, for example, in a Beacon, Probe Response, FILS Discovery, and/or Short Beacon frames.

In a fourth example, the AP may provide AP/Network system information based on a pre-defined combined AP/Network configuration parameter set. For example, the AP may provide a full AP/network configuration instance with its corresponding AP/AN-CCC, for example, in a Beacon frame, Probe Response frame, and/or GAP/ANQP frames. Alternatively, the AP may provide AP/network information through an AP/AN-CCC only, for example, in a FILS Discovery Frame, Short Beacon frame, etc.

<figref idref="DRAWINGS">FIG. 16</figref> is a diagram of an example method <b>1600</b> for supporting the use of pre-defined system parameter sets. Referring to <figref idref="DRAWINGS">FIG. 16</figref>, an AP may receive <b>1610</b> a probe request that includes a system configuration identifier, for example, a combination of BSSID, configuration type, and/or CCC that may match what the AP has. If the received system configuration identifier matches <b>1620</b> a system configuration identifier of the AP, the AP may transmit <b>1630</b> a Reduced Probe Response. A Reduced Probe Response may refer to a Probe Response frame in which a set of configuration parameters may not each be individually presented in the response frame. Instead, the same CCC value as in the Probe Request frame may be used to represent the configuration parameter set, indicating that the Probe Request transmitter STA has the valid configuration instance. If the received system configuration identifier does not match <b>1620</b> a system configuration identifier of the AP, the AP may transmit <b>1640</b> a full Probe Response with an updated set of configuration parameter values and corresponding configuration instance identifiers, or transmit a Partially-Reduced Probe Response, where a Partially-Reduced Probe Response may refer to a Probe Response frame that may not contain a full configuration instance. Instead, a Partially-Reduced Probe Response may contain a new configuration instance identifier and a subset of the configuration parameters, for example, those configuration parameters with new values. In other words, it may contain different values from the configuration instance as identified by the configuration instance identifier provided in the Probe Request frame.

This example may require that the AP is able to identify the differences between its current configuration instance and the one identified by the configuration instance identifier provided in the Probe Request frame, which may be achieved by storing several copies of previous configuration instances and the respective changes compared to the current configuration instances, and/or, dividing the configuration instances into subsets of parameters, for example, Subset 1, Subset 2, Subset 3 and Subset 4. The CCC may be divided into four parts as well, with for example, the first 4 bits associated with Subset 1; and/or the last 4 bits associated with Subset 4. By examining the CCC from the STA in the Probe Request, the AP may discover the changed parameter subsets.

A STA may keep track of and use the pre-acquired knowledge about the BSS and/or network in the form of pre-defined system configuration parameter sets to obtain the system information. For example, a STA may keep track of its acquired knowledge about BSS/AP and/or access network system information by using a configuration knowledge database. For each BSS/AP that the STA has acquired knowledge about, there may be an entry in the database, which may contain a BSSID, SSID, location, last-updated-time, configuration parameter sets and/or the corresponding configuration change counts, for example, BSS/AP configuration, access network configuration, and/or combined AP/Network configuration, etc., and values for each configuration parameter that may be present as indicated by its present-indicator. The entries in the configuration database may be organized to facilitate a fast access to the contents, for example, ordered based on the STA usage of the BSS/AP, or ordered based on locations of the BSS/APs, or ordered based on the physical movement routine of the STA, etc. An entry in the configuration database may be initialized when the STA acquires knowledge about a new BSS/AP, and the entry may be maintained every time the STA may receive an update about the BSS/AP, for example, a configuration instance with a new CCC value. A STA may acquire the knowledge of the BSS/AP configuration and/or access network configuration through a wireless link with the BSS/AP, or a wireless link with another BSS/AP, or a wireless link in a cellular network, or a wired link, etc.

<figref idref="DRAWINGS">FIG. 17</figref> is a diagram of another example method <b>1700</b> for supporting the use of pre-defined system parameter sets. For example, when a STA receives <b>1710</b> a full configuration instance and its corresponding CCC, for example, in Beacon frames, Probe Response frames, and/or GAS/ANQP frames, it may check <b>1720</b> if there is an entry in its acquired configuration knowledge database. If there is no entry in its acquired configuration knowledge database, then it may create <b>1730</b> an new entry. If there is an entry in its acquired configuration knowledge database, then it may check <b>1740</b> if the newly received configuration change count matches one in the configuration database. If there is a match, then no update <b>1750</b> is needed in the configuration database. If there is no match, then the STA may update <b>1760</b> the database with the newly received configuration instance and its corresponding CCC value.

<figref idref="DRAWINGS">FIG. 18</figref> is a diagram of another example method <b>1800</b> for supporting the use of pre-defined system parameter sets. For example, a STA may receive <b>1810</b> a configuration instance identifier without full configuration instance information, for example, in FILS Discovery frames, short beacon frames, or in Reduced Probe Response frames. The STA may determine <b>1820</b> whether the CCC value in the received configuration instance identifier matches a stored value. If the CCC value in the newly received configuration instance identifier does not match the value stored in the configuration database, then the STA may mark <b>1830</b> the corresponding configuration instance as “obsolete” in the database. If the CCC value in the newly received configuration instance identifier matches the value stored in the configuration database, it may not make any changes <b>1840</b> to the configuration database.

<figref idref="DRAWINGS">FIG. 19</figref> is a diagram of an example method <b>1900</b> where a STA may use the received configuration instance identifier information without full configuration instance information to determine if it has acquired up-to-date system information of the AP and/or network. This example may be use to improve the system information communication efficiency. For example, the STA may begin scanning <b>1910</b>. The STA may perform either active or passive scanning. The STA may receive <b>1920</b> a BSS/AP Configuration Change Count value without full AP configuration instance information, for example, in FILS Discovery frames, Short Beacon frames, or Reduced Probe Response frames. The STA may determine <b>1930</b> if there is a valid entry of the BSS/AP in the configuration database. If there is a valid entry of the BSS/AP in the configuration database, the STA may determine <b>1940</b> whether the received configuration change count value matches one in the database. If the received AP-CCC matches the AP-CCC in the database, then the STA may conclude that it has valid up-to-date BSS/AP system information. The STA may then complete the scanning process <b>1950</b> of the BSS/AP without waiting for a Beacon frame or a Probe Response frame. In this case, the BSS/AP configuration information in the database may be used for the MLME of the STA to construct the scanning report <b>1960</b> in MLME-SCAN.confirm primitive, and also it may be used for the STA to initiate the next-step action, for example, association, in the initial link setup process. If there is not a valid BSS/AP entry in the configuration database, or the received configuration change count value does not match one in the database, the STA may continue scanning <b>1970</b>.

<figref idref="DRAWINGS">FIG. 20</figref> is a diagram of an example method <b>2000</b> where a STA may include configuration instance identifier information for pre-acquired system configurations. During active scanning <b>2010</b>, the STA may transmit <b>2020</b> a Probe Request frame that includes configuration instance identifier information for its pre-acquired system configurations, where a configuration instance identifier may be a combination of BSSID, configuration type, and/or CCC. When used in a Probe Request frame, a configuration instance identifier, for example, AP-configuration identifier, represents the parameters in the configuration. Then those configuration parameters are no longer needed to be included individually in each Probe Request frame or Reduced Probe Request frame. In other words, the use of configuration instance identifier information allows the STA to use a Reduced Probe Request frame, so that the airtime occupancy of the Probe Request can be reduced.

When the STA receives <b>2030</b> a response, it may determine <b>2040</b> whether the received response is a Full, Partial, or Reduced Probe Response frame. When the STA receives a Reduced Probe Response frame <b>2045</b> with configuration identifier information but without full configuration instance, it may use its configuration database to retrieve <b>2050</b> its pre-acquired knowledge, in a way as described above. When the STA receives a Partial Probe Response frame <b>2055</b>, the STA may update <b>2060</b> the database accordingly. When the STA receives a Full Probe Response frame <b>2065</b>, the STA may determine <b>2070</b> whether the CCC value in the received response matches on in the database. If the CCC value matches <b>2075</b>, then no update <b>2080</b> is required in the database. If the CCC value does not match <b>2085</b>, the STA may update <b>2060</b> the database accordingly.

During network discovery and selection, for example, using a GAS/ANQP, the STA may include access network configuration identifier information in the GAS request frame to indicate its pre-acquired network configuration knowledge. Additionally, when a GAS response is received with configuration instance identifier information but without a full network configuration instance, the STA may use its configuration database to retrieve its pre-acquired network configuration knowledge.

There may also be multiple alternatives regarding how the pre-acquired configuration knowledge database may be managed in the layered protocol architecture of the STA. For example, the pre-acquired configuration knowledge database may be managed by a MAC Layer Management Entity (MLME), a Station Management Entity (SME), or a connection manager module above the MAC/PHY of a WirelessLAN air interface, etc.

If the pre-acquired configuration knowledge database is not managed by the MLME, some information from the database, for example, the configuration instance identifier, may be needed to be included in primitives in the service access points (SAP)s between the MLME and the module managing the database, for example, the SME.

If the pre-acquired configuration knowledge database is not managed by the MLME, for example, if it is managed by SME, two parameters may be included in the primitive MLME-Scan.request, for example ConfigurationType and APConfigurationChangeCount. An example is shown in Table 6 below.

<tables id="TABLE-US-00006" num="00006"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="287pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 6</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>An Example of New Parameters Added in MLME-Scan.request Primitive</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="77pt" align="left" /><colspec colname="2" colwidth="28pt" align="left" /><colspec colname="3" colwidth="42pt" align="left" /><colspec colname="4" colwidth="140pt" align="left" /><tbody valign="top"><row><entry>Name</entry><entry>Type</entry><entry>Valid Range</entry><entry>Description</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row><row><entry>APConfigurationType</entry><entry>Integer</entry><entry>0~N-1</entry><entry>The configuration type of the AP/Network that</entry></row><row><entry /><entry /><entry /><entry>the STA acquired in the last time</entry></row><row><entry>APConfigurationChange</entry><entry>Integer</entry><entry>0~K-1</entry><entry>The AP Configuration Change Count of the</entry></row><row><entry>Count</entry><entry /><entry /><entry>AP/Network that the STA acquired in the last</entry></row><row><entry /><entry /><entry /><entry>time</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

If the pre-acquired configuration knowledge database is not managed by the MLME, for example, if it is managed by SME, a BSSDescriptionUsingConfigurationChangeCountSet parameter may be included in the primitive MLME-Scan.confirm to enable the case where only the configuration type and AP-CCC may be used from the FILS Discovery Beacon, Short Beacon or Reduced Probe Response frames. An example is shown in Table 7 below.

<tables id="TABLE-US-00007" num="00007"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="364pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 7</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>An Example of New Parameters Added in MLME-Scan.confirm Primitive</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="84pt" align="left" /><colspec colname="2" colwidth="84pt" align="left" /><colspec colname="3" colwidth="42pt" align="left" /><colspec colname="4" colwidth="154pt" align="left" /><tbody valign="top"><row><entry>Name</entry><entry>Type</entry><entry>Valid Range</entry><entry>Description</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row><row><entry>BSSDescriptionUsingCon-</entry><entry>Set of</entry><entry>N/A</entry><entry>BSSDescriptionUsingConfigurationChangeCountSet</entry></row><row><entry>figurationChangeCountSet</entry><entry>BSSDescriptionUsingCon-</entry><entry /><entry>is returned to indicate the</entry></row><row><entry /><entry>figurationChangeCount</entry><entry /><entry>results of the scan request expressed in</entry></row><row><entry /><entry /><entry /><entry>terms of Configuration Type and AP-CCC.</entry></row><row><entry /><entry /><entry /><entry>It is a set containing zero or more</entry></row><row><entry /><entry /><entry /><entry>instances of a</entry></row><row><entry /><entry /><entry /><entry>BSSDescriptionUsingConfigurationChangeCount.</entry></row><row><entry /><entry /><entry /><entry>Present only for 802.11 systems</entry></row><row><entry /><entry /><entry /><entry>where AP-CCC is used.</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

Each BSSDescriptionUsingConfigurationChangeCount may include one or more of the elements shown in Table 8 below.

<tables id="TABLE-US-00008" num="00008"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="287pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 8</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>An Example of BSSDescriptionUsingConfigurationChangeCount</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="63pt" align="left" /><colspec colname="2" colwidth="42pt" align="left" /><colspec colname="3" colwidth="49pt" align="left" /><colspec colname="4" colwidth="133pt" align="left" /><tbody valign="top"><row><entry>Name</entry><entry>Type</entry><entry>Valid Range</entry><entry>Description</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row><row><entry>SSID or</entry><entry>Octet string</entry><entry>0-32 octets for</entry><entry>The SSID or the hashed SSID of the found</entry></row><row><entry>Compressed SSID</entry><entry /><entry>SSID or 0-4</entry><entry>BSS</entry></row><row><entry /><entry /><entry>octets for</entry></row><row><entry /><entry /><entry>compressed</entry></row><row><entry /><entry /><entry>SSID</entry></row><row><entry>Short timestamp</entry><entry>Interger</entry><entry>N/A</entry><entry>The least significant 4 bytes of the</entry></row><row><entry /><entry /><entry /><entry>Timestamp of the received frame (probe</entry></row><row><entry /><entry /><entry /><entry>response/beacon) from the found BSS</entry></row><row><entry>Time to the next</entry><entry>Integer</entry><entry>N/A</entry><entry>The time between the received short beacon</entry></row><row><entry>full beacon</entry><entry /><entry /><entry>frame to the next full beacon</entry></row><row><entry>BSSID or MAC</entry><entry>MAC</entry><entry>6 bytes</entry><entry>MAC Address of the AP is obtained from the</entry></row><row><entry>Address of the AP</entry><entry>address</entry><entry /><entry>Source address (SA) in the received short</entry></row><row><entry /><entry /><entry /><entry>beacon frame</entry></row><row><entry>Configuration Type</entry><entry>Integer</entry><entry>Log₂N bits</entry><entry>The configuration type of the found AP</entry></row><row><entry>AP-CCC</entry><entry>Integer</entry><entry>Log₂K bits</entry><entry>The AP Configuration Change Count of the</entry></row><row><entry /><entry /><entry /><entry>found AP</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

In yet another example, fast link setup with location-based pre-acquired knowledge may be used. Location-based pre-acquired knowledge may refer to what a STA has learned regarding the accessible and/or preferred networks for certain geographical locations, such as those frequently visited places, including home, office, meeting rooms, train stations on a daily-routine, local airport, parents' house, or other family members' houses, etc. The location-based accessible/preferred network knowledge may include not only the system information about the network operation mode, but also the security association information of the STA with the network. When entering a frequently visited place, such location-based pre-acquired accessible/preferred network knowledge may be used to accelerate the link setup process. In addition, it may also be used to facilitate fast transitions between accessible networks, for example, offloading from cellular to WLAN, or transitioning from WiFi to cellular.

A STA may keep track of location-based pre-acquired knowledge in a location-based preferred network database, which may also be referred to as a location-based network profile, or simply a location profile. A location in the database may be specified by geographical location descriptors, for example, Latitude, Longitude, Altitude, and optional Azimuth information, and/or civic location descriptions.

For each location in the database, there may be one or multiple accessible and/or preferred networks. For each of the accessible/preferred networks, the database may record the STA pre-acquired knowledge, for example, the network identifier, network type, network configuration parameter sets and values, and the security association information of the STA with the network, etc.

<figref idref="DRAWINGS">FIG. 21</figref> is a diagram of an example method <b>2100</b> for performing fast link setup with location-based pre-acquired knowledge. In this example, the STA may begin link setup <b>2110</b>, and determine <b>2120</b> whether the STA location is available. If the STA location is not available <b>2130</b>, the STA may proceed with a normal link setup process <b>2140</b>. If the STA location is available <b>2150</b>, the STA may determine <b>2160</b> whether a STA location profile is available. If a STA location profile is available <b>2170</b>, the STA may proceed with an optimized link setup <b>2180</b>. If a STA location profile is not available <b>2185</b>, the STA may proceed with a normal link setup <b>2140</b>.

The contents in the location-based network database may be configured to the STA and/or may be self-learned and maintained by the STA. When the information of a current location of a STA is available, the network management module of the STA, for example, the network connection manager, may use its location-based network database to optimize its network operations, for example, offloading from the cellular network to a WiFi network with fast initial link setup, establishing additional connection with a second network to distribute different types of traffic, and/or reselecting a more suitable network, etc.

The following examples may use the location-based pre-acquired knowledge to accelerate the link setup process in a WiFi network, for example, when the STA knows its current location, for example, through an existing network connection, and/or an embedded location utility.

<figref idref="DRAWINGS">FIG. 22</figref> is a diagram of a first example method <b>2200</b> for link setup optimization where a STA with access to its location-based network database knows exactly the BSS to connect to for a given location. In this example, the STA may skip all steps before the Association step in a typical 802.11 link setup procedure. The STA may transmit <b>2210</b> an Association Request frame to the BSS/AP with some additional information items comparable to a regular Association Request Frame, for example, its knowledge about AP/network operational settings, using for example a configuration instance identifier with a combination of BSSID, configuration type, and/or CCC; and/or its knowledge about security association with the AP/Network. The STA may determine <b>2220</b> whether a response was received from the BSS/AP.

If the STA does not receive <b>2225</b> a response within a pre-defined time interval, the BSS/AP may not be available, and the STA may perform <b>2230</b> a BSS/AP reselection either using the location-based network database or through a normal scanning process. It should be pointed out that this scenario is possible, but it is a more rare case because it may include the assumption that the STA is aware that the preferred network is accessible, such as the home network, or the office network.

If the STA receives <b>2235</b> a response from the AP that confirms that the STA's pre-acquired knowledge is valid with respect to, for example, inclusion of a matching configuration change count, the STA can move forward to the next step in the link setup procedure, without any maintenance actions for its pre-acquired knowledge database. This example may assume that the received response may also include the normal Association response content items.

If the STA receives a response from the AP that indicates that the STA's pre-acquired knowledge needs one or more updates <b>2240</b> with respect to, for example, inclusion of a different configuration change count and corresponding configuration instance information in addition to the normal Association response content items. In this example, the STA may perform an update <b>2250</b> to its pre-acquired knowledge about the AP/network, and it may perform a corresponding update to its database before moving forward to the next step in the link setup procedure <b>2260</b>. If the STA receives a response from the AP that indicates that the STA's pre-acquired knowledge does not need an update, the STA may continue the link setup procedure <b>2260</b>.

The STA may use the pre-acquired security association information with the AP/Network to optimize the security setup process. Note that, with the above optimizations, the link setup procedure may completely skip one time-consuming step, for example, AP/Network discovery, and also significantly reduce the time for another time-consuming step, for example, security setup by using the location-based pre-acquired knowledge. The procedure may only need approximately 5 message rounds between the STA and AP, for example, 1 for Association, 2 for security, and 2 for IP address assignment, plus 2 message rounds between the AP and DHCP server, to complete the IP connectivity establishment between the STA and AP/Network. Accordingly, the link setup time may be reduced to about 20 ms, if the procedure uses the same time values of the link setup steps given above.

In a second example with the access to its location-based network database, the STA may have the knowledge about the preferred BSS/AP(s) at a given location, but may need further confirmation before establishing the connection. In this example, the STA may verify that it has valid information about the AP/network first, and then it may use the steps given in the previous example to complete the link setup process. The following optimizations may be considered to accelerate the AP/Network information verification.

The STA may use the Reduced Probe Request/Response frames and/or Reduced GAS Request/Response frames, where “Reduced” may refer to the configuration identifier information, for example, a combination of BSSID, configuration-type, and/or CCC, to represent a set of parameters in those frames, instead of including the parameters of each individually. When the STA receives a response frame with configuration identifier information that matches information in the database, the STA may verify its data about the AP/Network and may move forward to the next step in the link setup process.

Additionally, if the STA receives a response frame with a full configuration instance and a different CCC value, then the STA may have actually acquired a new update of the corresponding system information, therefore it may also move forward to the next step. Furthermore, there may be multiple ways to transmit a Reduced Probe Request/Response frames, for example: the STA may transmit a unicast Reduced Probe Request, where the configuration instance identifier information may be provided by the BSSID in the MAC frame header, and one or multiple combinations of the configuration type and CCC value are provided in the frame body. With the unicast Reduced Probe Request, the STA may verify its pre-acquired knowledge about one BSS/AP and its associated access network with one or multiple pre-defined system configuration parameter sets; the STA may transmit a broadcast Reduced Probe request, where multiple configuration instance identifiers may be included, each with a combination of BSSID, configuration type, and CCC. With the broadcast Reduced Probe Request, the STA may verify its pre-acquired knowledge about one or multiple BSSs/APs and their associated networks in the same coverage area. After receiving a broadcast Reduced Probe Request, an AP and/or STA may respond if the BSSID of the AP is one of the BSSIDs in the configuration instance identifier information provided in the request frame; an AP and/or STA may respond to a received Reduced Probe Request with a Reduced Probe Response frame if it has at least one configuration instance identifier that matches one of the identifiers provided in the request frame; an AP and/or STA may respond to a received Reduced Probe Request with a regular Probe Response frame with a full configuration instance and its identifier if the BSSID and configuration type of its configuration instance match the corresponding values in one of the identifiers provided in the request frame but the configuration change count does not match.

The STA may use the configuration instance identifier information, for example, a combination of BSSID, configuration-type, and/or CCC value provided in a more frequently transmitted smaller system information announcement frame (compared to regular Beacon frame), for example, a short beacon frame, a fast beacon frame, or a FILS Discovery frame, etc. If the configuration instance identifier matches the corresponding configuration instance identifier in the database, then the verification is complete and the STA may move forward to the next step in the link setup process.

Note that the link setup time in this case may be the sum of the time used to verify AP/Network information and the time of the previous example. If using active scanning, for example, using the Reduced Probe Request/Response frames, the link setup time may be approximately 25 ms. If using more frequently transmitted smaller system information announcement frames (compared to regular Beacon frame), for example, a short beacon frame, or a fast beacon frame, or a FILS Discovery frame, etc., the link setup time may be approximately 20 ms plus the interval of such frames.

Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.