Method and apparatus for accelerated link setup

Accelerated link setting method and device

METHOD AND APPARATUS FOR ACCELERATED LINK SETUP

Cross-references to related applications

This application claims the benefits of U.S. Provisional Application No. 61/585,420 filed on January 11, 2012 and U.S. Provisional Application No. 61/719,663 filed on October 29, 2012. The contents of these applications are incorporated herein by reference. .

The link setup program can be configured to include multiple stages in the Institute of Electrical and Electronics Engineers (IEEE) 802.11 communication system. Example link setup procedures may include an access point (AP) discovery phase, a network discovery phase, an additional time synchronization function (TSF) phase, an authentication and association phase, and a higher-level Internet protocol (IP) setup phase. This link setup procedure can take a few seconds or more to complete.

A method and apparatus can be configured to perform accelerated link settings. One method may include that the station (STA) obtains information about the AP of the IEEE 802.11 network in advance through the previously connected IEEE 802.11 interface and/or an interface different from the IEEE 802.11 network. The STA can use the information obtained during the link setup procedure between the STA and the AP. The information may include suggestions for specific procedures to complete the link setup procedure between the STA and the AP.

A method and device can be used to establish a security association between the STA and the network in advance to enable and optimize the discovery of another network. For example, fast EAP can be encapsulated in an 802.11 frame (for example, an authentication frame or an association frame). The authentication process performed on the new network can be non-EAP based.

A device can send a request for network discovery information from a network entity, and receive the network discovery information in response. The network discovery information can be received via a cellular network (for example, a 3GPP network). Network discovery information can be received via a layer 2 protocol.

A device can send a request to obtain an IP address configuration from the network. For example, the device can request and receive IP address configuration during an EAP authentication procedure or a non-EAP authentication procedure. The IP address configuration can be received via a cellular network (for example, a 3GPP network).

<p>100Communication System</p><p>102a, 102b, 102c, 102dWireless Transmission/Receiving Unit (WTRU)</p><p>104Radio Access Network (RAN)</p><p>106Core network</p><p>108Public Switched Telephone Network (PSTN)</p><p>110Internet</p><p>112Other networks</p><p>114a, 114b base station</p><p>116Air Interface</p><p>118Processor</p><p>120Transceiver</p><p>122Transmit/Receive Components</p><p>124Speaker/Microphone</p><p>126Keyboard</p><p>128Display/Touchpad</p><p>130Unremovable memory</p><p>132Removable memory</p><p>134Power</p><p>136Global Positioning System (GPS) Chipset</p><p>138peripheral equipment</p><p>140a, 140b, 140c, 142a, 142b, 142ce Node B</p><p>S1, X2Interface</p><p>142Mobility Management Gateway (MME)</p><p>144Service Gateway</p><p>146Packet Data Network (PDN) Gateway</p><p>150Access Router (AR) 150</p><p>155Wireless Local Area Network (WLAN)</p><p>160a, 160b, 160c, 209a, 209b, 209c, 302a, 302b, 302c, 710, 810, 960, 1030, 1107, 1204, 1305, 1407, 1505Access point (AP)</p><p>170a, 170b, 170c, 208, 301, 720, 820, 920, 1010, 1102, 1202, 1301, 1401, 1501Station (STA)</p><p>EAP, EAPOLExtensible Authentication Protocol</p><p>200, 300 program</p><p>201, 303AP discovery phase</p><p>202, 304Network discovery stage</p><p>203, 305Additional time synchronization function (TSF) stage</p><p>204, 306certification stage</p><p>205, 307Association stage</p><p>206,308Security setting stage</p><p>207, 309IP setting stage</p><p>209a, 302aAP1</p><p>209bAP2</p><p>209c, 302cAPn</p><p>209d, 302d, 725, 815Network components</p><p>210a, 210b, 210c, 730 beacon</p><p>211a, 211b, 211c, 212a, 212b, 212c, 213a, 213d, 213fe, 213f, 214a, 214b, 215a, 215b, 216a, 216b, 217a, 217b, 217c, 217d, 217f, 217g, 217h, 217i, 217j, 217k, 217l, 217m, 217n, 217o, 217p, 217q, 217r, 217s, 218a, 218b, 218c, 218d, 218e, 218f, 740, 750, 760, 770, 830, 840, 850, 860Frame</p><p>GASProtective Behavior System</p><p>213bEnquiry request</p><p>213cEnquiry response</p><p>TLSInquiry/Transport Layer Security</p><p>217s4 handshake</p><p>DHCPDynamic Host Configuration Protocol</p><p>218gAcknowledgement (ACK)</p><p>218hDHCP ACK</p><p>310Pre-obtain information stage</p><p>311, 775AP post-discovery stage</p><p>312a, 312b, 722, 817Candidate STA information</p><p>313a, 313b, 726, 819candidate AP information</p><p>400SMS beacon frame</p><p>410optimize/minimize header</p><p>420Information field</p><p>430Optimize/minimize subset fields</p><p>440, 540, 630AP discovery information field</p><p>450, 550, 640Network discovery information field</p><p>460, 560, 650Security-related information fields</p><p>470, 570, 660Higher level protocol information field</p><p>480, 580, 670Optional element field</p><p>500Main beacon frame</p><p>510Header</p><p>520Main beacon content field</p><p>530SMS related information fields</p><p>600FILS Management Behavior Frame</p><p>610Category field</p><p>620behavior field</p><p>700, 800AP discovery method</p><p>780Link settings</p><p>900, 1000, 1100, 1200, 1300, 1400, 1500, 1600, 1700, 1800, 1900, 2000, 2100, 2200Sample method</p><p>910, 1005, 1101, 1201, 1302, 1402, 1502, AAA server</p><p>930, 1015, 1103, 1303, 1403, 1503 Mutual authentication</p><p>950, 1025Detection request</p><p>970,1035Detection response</p><p>971, 1040, 1109, 1209Open certification</p><p>972, 1041, 1110, 1210Association</p><p>973, 1042, 1112, 1211EAP request</p><p>974, 1043, 1113, 1212EAP response</p><p>975, 1044, 1114, 1213Access request</p><p>976, 980Paired Master Key (PMK)</p><p>977, 1051, 1116, 1220, 1311, 1509Access to receive messages</p><p>978, 1119EAP success message</p><p>981, 1054, 1121, 12234-way handshake agreement</p><p>982, 984, 987, 988Key frame</p><p>983Temporary key</p><p>985Paired Transient Key (PTK)</p><p>986Group Temporary Key (GTK)</p><p>990Configuration</p><p>995WLAN network</p><p>1046,1215Access inquiry message</p><p>1047, 1216EAP request message</p><p>1049, 1218EAP response message</p><p>1050, 1219, 1309, 1507Access request message</p><p>1052, 1221EAP success message</p><p>1104, 1205Passive and/or active AP discovery</p><p>1105, 1206Internet discovery</p><p>1108, 1208GAS response message</p><p>1304Master Key (PSK) and FILS Identification Code</p><p>1306, 1405Snonce</p><p>1307, 1313, 1506, 1510Authentication information</p><p>1316,1317,1512,1514Related information</p><p>1406, 1413Associated frame</p><p>1409Access request frame</p><p>1411Access to receive frame</p><p>AAAAuthentication, authorization and accounting</p><p>EAP, EAPOLExtensible Authentication Protocol</p><p>WLANWireless Local Area Network</p><p>3GPPThe Third Generation Partnership Project</p><p>DHCPDynamic Host Configuration Protocol</p><p>IPInternet Protocol</p><p>PSKPre-shared key</p><p>FILSQuick initial link setup</p>

A more detailed understanding can be obtained from the following descriptions given in conjunction with the drawings and examples, in which: Figure 1A is a system diagram of an exemplary communication system in which one or more disclosed embodiments can be implemented; Figure 1B is A system diagram of an example wireless transmission/reception unit (WTRU) used in the communication system shown in Figure 1A; Figure 1C is an example radio access network that can be used in the communication system shown in Figure 1A And a system diagram of an example core network; Figure 2A is a schematic diagram of an example IEEE 802.11 setup procedure; Figure 2B is a continuation of the example IEEE 802.11 setup procedure shown in Figure 2A; Figure 3 is an acceleration for using pre-obtained information The flow chart of the basic procedure of the link setup (ALS); Figure 4 is a schematic diagram of an example short message beacon frame that supports accelerated link setup (ALS); Figure 5 is a diagram of the main beacon frame that supports ALS Schematic diagram of example modification; Figure 6 is a schematic diagram of an example fast initial link setup (FILS) management behavior frame; Figure 7 is a schematic diagram of an example of an optimized access point (AP) discovery procedure initiated by a STA based on pre-obtained knowledge; Figure 8 is a schematic diagram of an example of an optimized AP discovery procedure initiated by an AP based on pre-acquired knowledge; Figure 9 is a schematic diagram of an example method in which an authentication, authorization, and accounting (AAA) server can integrate an identity provider (OP) and enhanced access network discovery and selection function (eANDSF) functionality to achieve seamless authentication and fast link setting; Figure 10 is a schematic diagram of another example method, in which authentication, authorization and accounting ( AAA) server can integrate OP and enhanced access network discovery and selection function (eANDSF) functionality to achieve seamless authentication and fast link setting; Figure 11 is a schematic diagram of an example method, where AAA server can Integrate the functionality of OP to achieve seamless authentication and fast link setting; Figure 12 is a schematic diagram of another example method, in which the AAA server can integrate the functionality of OP to achieve seamless authentication and fast link setting; No. 13 Figure is a schematic diagram of an example method for pre-establishing security associations between STA and network to achieve seamless authentication and rapid initial link setup; Figure 14 is another schematic diagram of an example method for pre-establishing security associations between STA and network A schematic diagram of an example method for establishing a security association to achieve seamless authentication and fast initial link setting; Figure 15 is another method for pre-establishing a security association between STA and the network to achieve seamless authentication and fast initial link A schematic diagram of an example method of road setting; Figure 16 is a schematic diagram of an example method for supporting the use of a predefined system parameter set; Figure 17 is another example method for supporting the use of a predefined system parameter set Schematic diagram; Figure 18 is a schematic diagram of another example method for supporting the use of a predefined system parameter set; Figure 19 is a schematic diagram of an example method in which the STA can receive configuration instance identifier information without full configuration instance information; Figure 20 is a schematic diagram of an example method, where the STA may include configuration instance identifier information for the pre-obtained system configuration; Figure 21 is an example method of performing fast link setting using location-based pre-obtained knowledge Schematic diagram; and Figure 22 is a schematic diagram of an example method for link setup optimization.

Figure 1A is an illustration of an example communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content (for example, voice, data, video, messaging, broadcast, etc.) to multiple wireless users. The communication system 100 can enable multiple wireless users to access these contents via shared system resources (including wireless bandwidth). For example, the communication system 100 may use 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 so on.

As shown in Figure 1A, the communication system 100 may include wireless transmission/reception units (WTRU) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network 106, and a public switched telephone network (PSTN). ) 108, the Internet 110, and other networks 112, but it should be understood that the disclosed implementation takes into account any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. As an example, the WTRU 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals, and may Including user equipment (UE), mobile stations, fixed or mobile user units, pagers, cellular phones, personal digital assistants (PDAs), smart phones, laptops, netbooks, personal computers, wireless sensors Detectors, consumer electronics, stations (STA) in IEEE 802.11 networks, etc.

The communication system 100 may also include a base station 114a and a base station 114b. Each of the base stations 114a, 114b may be configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks (e.g., core network 106, Internet Any type of device on the network 110 and/or network 112). As an example, the base stations 114a, 114b may be base transceiver stations (BTS), Node B, eNode B, home Node B, home eNode B, site controller, access point (AP), wireless router, and so on. Although the base stations 114a, 114b are each described as separate components, it should be understood that the base stations 114a, 114b may include any number of interconnected base stations and/or network components.

The base station 114a may be part of the RAN 104, and the RAN 104 may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), and a relay Nodes and so on. The base station 114a and/or the base station 114b may be configured to transmit and/or receive wireless signals within a specific geographic area, which may be referred to as a cell (not shown). Cells can also be divided into cell sectors. For example, the cell associated with the base station 114a can be divided into three sectors. Therefore, in an embodiment, the base station 114a may include three transceivers, that is, each sector of the cell has one transceiver. In another embodiment, the base station 114a can use multiple input multiple output (MIMO) technology, so multiple transceivers can be used for each sector of the cell.

The base stations 114a, 114b can communicate with one or more of the WTRUs 102a, 102b, 102c, 102d via an air interface 116, which can be any suitable wireless communication link (e.g., radio frequency (RF), Microwave, infrared (IR), ultraviolet (UV), visible light, etc.). Any suitable radio access technology (RAT) can be used to establish the air interface 116.

More specifically, as described above, the communication system 100 may be a multiple access system, and may use one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and so on. For example, the base station 114a and the WTRUs 102a, 102b, 102c in the RAN 104 may implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use wideband CDMA (WCDMA) to establish an air interface 116 . 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 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may use Long Term Evolution (LTE) and/or LTE Advanced ( LTE-A) to establish the air interface 116.

In other embodiments, the base station 114a and the WTRU 102a, 102b, 102c may implement, for example, IEEE 802.16 (ie, 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 Rate (EDGE) for GSM Evolution, GSM EDGE (GERAN), etc. Radio technology.

The base station 114b in Figure 1A can be a wireless router, home Node B, home eNode B, or access point, and can use any appropriate RAT to facilitate wireless connections in local areas, such as commercial places, houses, vehicles, Campus and so on. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d may implement radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may use a cellular-based RAT (eg, WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish picocells or femtocells. As shown in Figure 1A, the base station 114b may have a direct connection to the Internet 110 connect. Therefore, the base station 114b may not need to access the Internet 110 through the core network 106.

The RAN 104 may communicate with a core network 106, which may be configured to provide voice, data, applications, and/or Internet protocols to one or more of the WTRUs 102a, 102b, 102c, 102d Any type of network with Voice over Internet Protocol (VoIP) service. For example, the core network 106 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connection, video distribution, etc., and/or perform advanced security functions, such as user authentication. Although not shown on the way of 1A, it should be understood that the RAN 104 and/or the core network 106 may directly or indirectly communicate with other RANs that use the same RAT as the RAN 104 or a different RAT. For example, in addition to connecting to the RAN 104 that is using E-UTRA radio technology, the core network 106 can also communicate with another RAN (not shown) that uses GSM radio technology.

The core network 106 may also serve as a gateway for the WTRUs 102a, 102b, 102c, and 102d to access the PSTN 108, the Internet 110, and/or other networks 112. PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use public communication protocols, such as the Transmission Control Protocol (TCP) in the TCP/IP Internet Protocol Suite, and the User Datagram Protocol ( UDP) and Internet Protocol (IP) and so on. The network 112 may include a wired or wireless communication network owned and/or operated by other service providers. For example, the network 112 may include another core network connected to one or more RANs, which may use the same RAT as the RAN 104 or a different RAT.

Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 may include multi-mode capabilities, that is, the WTRUs 102a, 102b, 102c, and 102d may include multiple modes for communicating with different wireless networks via different wireless links. A transceiver. For example, the WTRU 102c shown in Figure 1A may be configured to communicate with a base station 114a, which may use cellular-based radio technology, and communicate with a base station 114b, which may use IEEE 802 Radio technology. A WTRU may be referred to as a station (STA) or a non-access point (non-AP) STA.

Figure 1B is a system diagram of an example WTRU 102. As shown in Figure 1B, the WTRU 102 may Including processor 118, transceiver 120, transmission/reception element 122, speaker/microphone 124, keyboard 126, display/touchpad 128, non-removable memory 130, removable memory 132, power supply 134, global positioning system (GPS) Chipset 136, and other peripheral devices 138. It should be understood that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the implementation.

The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with the DSP core, a controller, a micro Controller, dedicated integrated circuit (ASIC), field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), state machine, etc. The processor 118 may perform signal encoding, data processing, power control, input/output processing, and/or any other functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmission/reception element 122. Although FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it is understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

The transmitting/receiving element 122 may be configured to transmit signals to a base station (e.g., base station 114a) or receive signals from a base station (e.g., base station 114a) via the air interface 116. For example, in one embodiment, the transmission/reception element 122 may be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmitting/receiving element 122 may be a transmitter/detector configured to transmit and/or receive, for example, IR, UV, or visible light signals. In yet another embodiment, the transmission/reception element 122 may be configured to transmit and receive both RF and optical signals. It should be understood that the transmission/reception element 122 may be configured to transmit and/or receive any combination of wireless signals.

In addition, although the transmission/reception element 122 is described as a single element in Figure 1B, the WTRU 102 may include any number of transmission/reception elements 122. More specifically, the WTRU 102 may use MIMO technology. Therefore, in one embodiment, the WTRU 102 may include two or more transmission/reception elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via the air interface 116.

The transceiver 120 may be configured to modulate the signal to be transmitted by the transmission/reception element 122 and demodulate the signal received by the transmission/reception element 122. As mentioned above, the WTRU 102 may have multi-mode capabilities. Therefore, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11.

The processor 118 of the WTRU 102 may be coupled to the following devices, and may receive user input from the following devices: speaker/microphone 124, keyboard 126, and/or display/touch panel 128 (e.g., liquid crystal display (LCD) display) Unit or organic light emitting diode (OLED) display unit). The processor 118 can also output user data to the speaker/microphone 124, the keyboard 126, and/or the display/touchpad 128. In addition, the processor 118 can access information from any type of appropriate memory, and can store data in the memory, such as the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), hard disk, or any other type of storage memory device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and so on. In other embodiments, the processor 118 may access information from memory that is not actually located on the WTRU 102 (for example, on a server or a local computer (not shown)), and may store data in the memory middle.

The processor 118 may receive power from the power source 134, and may be configured to generate and/or control power to other components in the WTRU 102. The power source 134 may be any suitable device that powers the WTRU 102. For example, the power source 134 may include one or more dry batteries (eg, nickel cadmium (NiCd), nickel zinc (NiZn), nickel metal hydride (NiMH), lithium ion (Li-ion), etc.), solar cells, fuel cells, etc. Wait.

The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition, in addition to or as an alternative to the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via the air interface 116, and/or based on two Or more adjacent base stations receive the signal timing to determine its location. It should be understood that while maintaining consistency with the implementation, the WTRU 102 may obtain location information through any appropriate location determination method.

The processor 118 may also be coupled to other peripheral devices 138, and the peripheral devices 138 may include one or more software and/or hardware modules that provide additional features, functions, and/or wired or wireless connections. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos or videos), universal serial bus (USB) ports, vibration devices, TV transceivers, hands-free headsets, Bluetooth R modules, frequency modulation (FM) radio units, digital music players, media players, video game console modules, Internet browsers, etc.

Figure 1C is an example system diagram of the RAN 104 and the core network 106. As described above, the RAN 104 may employ E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c via the air interface 116. The RAN 104 can also communicate with the core network 106.

The RAN 104 may include eNodeBs 140a, 140b, and 140c, but it is understood that, while maintaining consistency with the embodiment, the RAN 104 may include any number of eNodeBs. Each of the eNodeBs 140a, 140b, 140c may include one or more transceivers to communicate with the WTRU 102a, 102b, 102c via the air interface 116. In an embodiment, the eNodeB 140a, 140b, 140c may implement MIMO technology. Therefore, the eNodeB 140a may, for example, use multiple antennas to transmit wireless signals to and receive wireless signals from the WTRU 102a.

Each of the eNodeBs 140a, 140b, 140c can be associated with a specific cell (not shown), and can be configured to handle radio resource management decisions, handover decisions, users in uplink and/or downlink Scheduling etc. As shown in Figure 1C, eNodeBs 140a, 140b, and 140c can communicate with each other via the X2 interface.

The core network 106 shown in FIG. 1C may include a mobility management gateway (MME) 142, a service gateway 144, and a packet data network (PDN) gateway 146. Although each of the aforementioned elements is described as part of the core network 106, it should be understood that any of these elements All can be owned and/or operated by entities other than the core network operator.

The MME 142 can be connected to each of the eNodeBs 142a, 142b, and 142c in the RAN 104 via the S1 interface, and can act as a control node. For example, the MME 142 may be responsible for authenticating users of WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a specific service gateway during the initial attachment of WTRUs 102a, 102b, 102c, and so on. The MME 142 may also provide control plane functions to exchange between the RAN 104 and other RANs (not shown) that use other radio technologies (e.g., GSM or WCDMA).

The service gateway 144 can be connected to each of the eNodeBs 140a, 140b, and 140c in the RAN 104 via the S1 interface. The service gateway 144 can generally route and forward user data packets to/from the WTRU 102a, 102b, 102c. The service gateway 144 can also perform other functions, such as anchoring the user plane during handover between eNodeBs, triggering paging when downlink data is available for WTRUs 102a, 102b, 102c, and managing and storing WTRUs 102a, 102b, 102c context, etc.

The service gateway 144 may also be connected to a PDN gateway 146, which may provide the WTRU 102a, 102b, 102c with access to a packet-switched network (e.g., the Internet 110) to facilitate the WTRU 102a, Communication between 102b, 102c and IP-enabled devices. The access router (AR) 150 of the wireless local area network (WLAN) 155 can communicate with the Internet 110. The AR 150 may facilitate communication between the APs 160a, 160b, and 160c. The AP 160a, 160b, and 160c may communicate with the STA 170a, 170b, and 170c.

The core network 106 can facilitate communication with other networks. For example, the core network 106 may provide WTRUs 102a, 102b, 102c with access to a circuit-switched network (e.g., PSTN 108) to facilitate communication between the WTRUs 102a, 102b, 102c and traditional landline communication devices. For example, the core network 106 may include an IP gateway (for example, an IP Multimedia Subsystem (IMS) server), or may communicate with an IP gateway that serves as a connection between the core network 106 and the PSTN 108 interface. In addition, the core network 106 may provide the WTRUs 102a, 102b, 102c with access to the network 112, which 112 may include other wired or wireless networks owned and/or operated by other service providers.

Figures 2A and 2B are schematic diagrams of example IEEE 802.11 link setup procedures, in which 802.11i/Extensible Authentication Protocol (EAP) can be used. This example program 200 may include an AP discovery phase 201, a network discovery phase 202, an additional time synchronization function (TSF) phase 203, an authentication phase 204, an association phase 205, a security setting phase 206, and an IP setting phase 207. The wireless communication system may include one or more stations (STA) 208, one or more APs 209a, 209b, 209c, and one or more network elements 209d. The STA 208 may include a wireless transmission and reception unit (WTRU) or a non-AP STA, and the network element 209d may include, for example, a router, a home agent (HA), an authentication, authorization and accounting (AAA) server, and an authentication server (AS) , Or remote authentication dial-in user service (RADIUS).

In the AP discovery phase 201, the STA 208 can use active or passive scanning to find the AP within range. In the active scanning example, the STA 208 may transmit respective probe request frames 211a, 211b, and 211c to AP1 209a, AP2 209b, and APn 209c. In response, each AP can send its own probe response frame 212a, 212b, 212c to the STA 208. In the passive scanning example, the STA 208 may wait to receive the respective beacons 210a, 210b, 210c from the AP1 209a, AP2 209b, and APn 209c before performing the probe request/response frame exchange.

In the network discovery phase 202, the STA 208 can search for a suitable service provider network by sending a protective behavior system (GAS) initial request frame 213a to, for example, AP1 209a. In response, the AP1 209a can send a query request 213b to the network element 209d and receive a query response 213c. In response to receiving the query response 213c, the AP1 209a may send the GAS initial response frame 213d to the STA 208. The STA 208 may send a GAS recovery request frame 213e to the AP1 209a, and receive a GAS recovery request frame 213f in response. If necessary, for example, if the GAS response is too large to be filled into a MAC Management Protocol Data Unit (MMPDU), and the GAS fragmentation is used for delivery, one or more GAS recovery request/response exchanges can be performed 213g .

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

The authentication phase 204 can be performed. During the authentication phase 204, the STA 208 may send an authentication request frame 215a to, for example, the AP1 209a, and receive an authentication response frame 215b in response.

The association phase 205 can be executed. During the association phase 205, the STA 208 may transmit an association request frame 216a to, for example, AP1 209a, and receive an association response frame 216b in response.

The security setting phase 206 may be executed. The STA 208 may initiate the security setting phase 206 via the extensible authentication protocol (EAP) (EAPOL) start frame 217a of the local area network (LAN) transmitted to, for example, AP1 209a. AP1 209a may send an EAP request frame 217b to STA 208. The EAP request frame 217b may include a field indicating the identification code of the AP1 209a. The STA 208 may send an EAP response frame 217c to the AP1 209a as a response. The EAP response frame 217c may include a field indicating the identification code of the STA 208. AP1 209a may use, for example, the AAA protocol to send a request frame 217d to the network element 209d. The request frame 217d may include a field indicating the identification code of the STA 208.

The network element 209d can send a query/transport layer security (TLS) start frame to the AP1 209a in response. AP1 209a may send an EAP request/TLS start frame 217f to STA 208. In response, the STA 208 may send an EAP response/TLS client greeting frame 217g to the AP1 209a. AP1 209a can send a request/pass frame 217h to the network element 209d, and receive a query/server certificate frame 217i in response. AP1 209a can send an EAP request/pass frame 217j to STA 208, and receive an EAP response/client certificate frame 217k in response.

AP1 209a can send a request/pass frame 2171 to the network element 209d, and receive a query/encryption type frame 217m in response. AP1 209a can send an EAP request/pass frame 217n to STA 208, and receive an EAP response frame 217o in response. The AP1 209a can send a request frame 217p to the network element 209d, and receive an acceptance frame 217q in response. AP1 209a can Send an EAP success message 217r to the STA 208. In response to the EAP success message 217r, the STA 208 and the AP1 209a can perform a 4-way handshake 217s.

The IP setting stage 207 can be executed to obtain IP address allocation. For example, the STA 208 may transmit a dynamic host configuration protocol (DHCP) discovery frame 218a to, for example, AP1 209a. AP1 209a can send a DHCP discovery frame 218b to the network element 209d, and receive a DHCP offer frame 218c in response. AP1 209a may transmit a DHCP offer frame 218d to STA 208. The STA 208 may send a DHCP request frame 218e to the AP1 209a. AP1 209a can send a DHCP request frame 218f to the network element 209d, and receive a DHCP acknowledgement (ACK) 218g in response. AP1 209a may transmit DHCP ACK 218h to STA 208.

Other EAP methods that provide mutual authentication can also be used, such as EAP User Identity Module (EAP-SIM), EAP Authentication and Key Agreement (AKA), and EAP Tunneling Layer Security (EAP-TTLS).

The 802.11 initial link setup procedure (such as the example protocol shown in Figure 2) faces some problems. One problem may include, for example, the length of time required for an 802.11 network to establish an initial connection with the STA, as much as a few seconds or more. Another problem may be when users of the STA are involved in an interactive conversation (for example, Skype video), when the STA switches from another network to an 802.11 network (for example, from the third-generation partner project ( 3GPP) network may not be able to maintain the connection when switching to a wireless local area network (WLAN)). Another problem may be that IEEE 802.11 networks are required to support a large number of users simultaneously entering the extended service set (ESS) and providing them with authentication securely.

Some goals of 802.11 networks can be set in terms of initial link setup time, minimum user load, and robustness in the presence of high background load. Regarding the initial link setup time, an example goal may be that the initial link setup time of the IEEE 802.11 network is less than 100ms while maintaining the robust security network association (RSNA) security level, where the initial link setup time may be obtained via AP The amount of time required for the ability to send Internet Protocol (IP) traffic and a valid IP address. Regarding the minimum user load, an example target can be that the IEEE 802.11 network supports at least 100 non-APs The STA enters the ESS within one second and successfully performs link settings. Regarding robustness in the presence of high background load, an example goal may be to provide link settings for at least 50% of the media load.

Example methods to reduce the initial link setup time for 802.11 networks are summarized in Table 1. However, these examples may not be sufficient to meet the 100ms link setup time goal. This is because, even if aggregate prediction is used, even without considering the network discovery phase, the possible completion time for link setup using passive scanning is 90ms. In an actual network where there are a large number of APs, the actual time consumption will be significantly longer. In addition, the IEEE 802.11 link setup protocol shown in Figure 2 is very long and will not meet the initial link setup time requirement.

<tables><img he="2056" wi="1480" file="twi620449b_d0001.tif" img-content="drawing" img-format="tif" orientation="portrait" inline="no" /></tables>With reference to Table 1, the time value displayed in the "possible completion" column may be based on 802.11ai, for example.

Although it is possible to remove the 802.11 authentication phase when using RSNA, the authentication phase can still be performed to assist in reverse compatibility. IP address allocation can be incorporated into the earlier stages of the link setup procedure in 802.11ai.

An example Internet Engineering Task Force (IETF) program may include DHCP that quickly performs an optimized IP allocation phase, which is a fast IP allocation scheme. The configuration change count (CCC) or configuration serial number can be used for GAS configuration and/or AP configuration to optimize system information communication between STA and AP/network.

The 802.11ai program may not be enough to meet the requirement that the initial link setup time is less than 100ms. This may be because the current "possible" completion time for link setup using passive scanning is 90ms, even if the network discovery phase is not considered. In addition, the numbers given in the "possible to complete" column are very aggressive, for example 2ms for active scanning. In an actual network where there are a large number of APs, the actual time consumption will be significantly longer. Some or all stages of the link setup procedure can be initiated by the STA. The AP can respond to STA requests, and there may be no mechanism that enables the AP to initiate the optimization in the link setup procedure. In order to speed up the link setup time while maintaining the RSNA security level, most of the current 802.11 link setup procedures can be further optimized.

The current initial link setup procedure is very long and does not meet the initial link setup time requirements. It is impossible for a large number of users to enter the ESS at the same time within the identified link setup time frame. There is a need for methods and devices for optimizing link setup procedures using dynamic, flexible and interoperable procedures.

The link setting procedure in 802.11 does not allow optimization of the procedure including the elimination of some steps or stages at the AP. For example, in 802.11, all stages of the link setup procedure can be initiated by the STA as shown in Figure 2A.

The system configuration can be defined. For example, you can define a configuration change count or configuration serial number. and Also, in IEEE 802.11, the example initial setup procedure (for example, the agreement shown in Figure 2A and Figure 2B), all stages in the link setup procedure can be initiated by the STA. The AP only responds to STA requests, and therefore may not have a mechanism for initiating optimization in the link setup procedure. Moreover, it is impossible to accommodate a large number of users entering the ESS at the same time within the identified link setup time frame (for example, 100ms).

In addition to the above, as mobility requirements increase and the availability of multi-mode devices with multiple wireless interfaces increases, such as 3GPP and IEEE 802.11, seamless handover and service continuity between these networks may become operational The differentiated services provided by the provider to its users. Security access procedures to 802.1x/EAP WLAN networks may suffer from lack of automation, significantly increased latency, non-seamless handover, and due to the usual requirements for user interaction, pre-provisioning of equipment, and credential WLAN networks The handover of the mobile phone caused the interruption of services previously established via the cellular network (for example, Voice over Internet Protocol (VoIP) sessions).

One or more of the embodiments disclosed herein can speed up the initial link setup of the 802.11 device by using information obtained in advance by the AP and/or STA. The AP and/or STA can obtain certain information about the other party in advance. For example, the STA can switch from its previous connection (such as a 3G network) to a WLAN network, or switch from one AP to another AP in the ESS. In this example, it is possible for a suitable or better WLAN AP to obtain some information about the candidate STA in advance. It is also possible for the STA to obtain knowledge about a better AP in advance based on, for example, geographic location and network access history (including but not limited to frequently accessed locations, daily work, etc.).

Since AP and/or STA obtain this information in advance, it is possible to skip and/or merge certain stages in the link setup procedure. In addition, depending on what information and how much information the AP and/or STA have obtained in advance, various optimizations can be applied to the link setup procedure to reduce the link setup time. This shortened or optimized procedure can also be initiated by the AP.

Figure 3 is a flowchart of the basic procedure for accelerated link setup using pre-obtained information. The wireless communication system may include one or more stations STA 301, one or more APs 302a, 302b, 302c, and one or more network components 302d. The STA 301 may include a wireless transmission and reception unit (WTRU), and the network element 302d may include, for example, a router, a home agent (HA), an AAA server, AS or RADIUS.

In the example program 300 shown in FIG. 3, the APn 302c can initiate link setting optimization by using pre-obtained information about the STA 301. In addition, the example program shown in Figure 3 can adapt to a variety of different acceleration link setting procedures in a dynamic, flexible, and interoperable manner, while maintaining backward compatibility.

Regarding the link setting procedure shown in FIG. 2, the basic procedure of accelerated link setting (ALS) using pre-obtained information shown in FIG. 3 can be driven by entities other than the STA 301. If the information about the STA or AP is not obtained in advance, then ALS can include AP discovery stage 303, network discovery stage 304, additional TSF stage 305, authentication stage 306, association stage 307, security setting stage 308, IP setting stage 309 802.11 link setup program. However, if the AP has already performed the pre-obtained information stage 310 to obtain information about the STA 301, or vice versa, the STA 301 and the AP can use the pre-obtained information to optimize the AP discovery stage 303. In addition, AP and STA can negotiate to skip or shorten the phase after AP discovery based on the amount of information that STA and AP have obtained about each other, for example, network discovery phase 304, additional TSF phase 305, authentication phase 306, and association phase 307 , Security setting stage 308 and IP setting stage 309.

For example, if the STA is making an interactive network video call on a 3G cellular network, if the STA arrives at a location with a strong signal from a better AP, the STA can switch to the WLAN network. The STA and the better AP can obtain information about each other in advance via the 3G network before the link is set up, such as security-related parameters, available network services, and so on. Assuming pre-obtained information, the STA can actively scan for better APs instead of scanning all available APs in the area, which can significantly shorten the AP discovery process. Moreover, because STAs and APs may have obtained security-related parameters and available network service information in advance, they can skip the network discovery phase 304 and the additional TSF phase 305 (because TSF can be used during the initial probe request/probe response exchange. In progress) and security setup phase 308 to achieve faster link setup while maintaining the required RSNA security level.

The example basic procedure shown in FIG. 3 may include a pre-acquisition stage 310, an AP discovery stage 303, and an AP post-discovery stage 311. In the pre-acquisition stage 310, the AP and/or STA can directly obtain knowledge about each other between the AP and the STA via an interface other than the IEEE 802.11 air link. The pre-obtaining information stage 310 may not be part of the link setup time, and may be performed at any time before the link setup between the AP and the STA. The pre-obtaining stage 310 may not necessarily occur just before the link is set up. In the AP discovery phase 303, the STA 301 may use or not use pre-obtained information to find a suitable AP. If the information obtained in advance is available, AP discovery can be optimized from this, and specific procedures for the remaining link setup procedures can be transmitted and negotiated between the AP and the STA. Otherwise, the AP discovery procedure 303 and the remaining link setup phase can be used to maintain backward compatibility. The post-AP discovery stage 311 may include all the remaining stages of the setting of the IP connection between the SAT and the AP, for example, network discovery 304, additional TFS 305, authentication 306, association 307, security setting 308, and IP setting 309. The post-AP discovery stage 311 can be flexibly constructed so that no stage is mandatory. In order to speed up the link setup process, each stage can be skipped or optimized based on the availability and amount of information obtained in advance about STAs and APs. In addition, the ALS program shown in Figure 3 provides a framework for the merged phase or newly defined program. The selection of a specific procedure for the link setup situation can be communicated between the AP and the STA via the suggested signaling mechanism when the AP discovery step is completed.

Referring to Figure 3, the STA 301 and the AP1 302a can obtain information in advance in the information advance stage 310. For example, if STA 301 is connected to a WLAN, AP1 may receive candidate STA information 312a from APn 302c, and STA 301 may receive candidate AP information 313a from APn 302c. In another example, if the STA is connected to a cellular network (eg, network element 302d), AP1 302a may receive candidate STA information 312b from network element 302d, and STA 301 may receive candidate AP information 313b from network element 302d .

Candidate STA information 312a, 312b may be obtained in advance, for example, AP1 302a may be Knowledge of candidate STAs with which to communicate at some point in the future. The candidate STA information 312a, 312b may include, for example, the media access control (MAC) address of the candidate STA, the capabilities of the candidate STA, security information, and/or service packages. The candidate AP information 313a, 313b may be pre-obtained knowledge about candidate APs with which the STA 301 can communicate at some point in the future, for example. Candidate AP information 313a, 313b may include, for example, service set identifier (SSID), basic service set identifier (BSSID), AP capability, physical (PHY) mode, one or more rates, security information, and access to network services Information, and any other information that can be included in a beacon or probe response frame. The candidate STA information 312a, 312b and the candidate AP information 313a, 313b may also include the information shown in Table 2 below.

The accelerated link setup (ALS) capability indicator may be used to indicate whether the STA supports ALS, and the STA includes AP and non-AP STAs. The ALS indicator can include, for example, bit mark information, which can be encoded into an existing information field by using reserved bits. For example, the reserved bit may be the capability information field of the beacon frame. The reserved bits can also be encoded into one or more information fields or information elements (IE).

AP and STA can use the ALS capability indicator to inform each other of their ALS capabilities, so that the ALS procedure can be effectively triggered. During the initial link setup, both AP and STA can send ALS capability indicator information at their earliest possible opportunity. For example, the AP can send the ALS capability indicator in the beacon frame and/or the detection response frame, and the STA can send the ALS to the AP in the detection request frame and/or other management/control frames as the initial frame Ability indicator.

IE can be used to assist ALS procedures, and can include, for example, I know you IE, I know you respond to IE, need more information IE, and need more information to respond to IE. These IEs can be included in the management frame and can be transmitted via the WLAN air link between two STAs, including AP and non-AP STAs.

I know that your IE can allow the AP and/or STA to notify the other party that they have obtained information about the other party in the early stage of the initial link setup. When AP uses I know your IE, it can be from AP to The STA's first unicast frame (for example, a probe response or an authentication response) is sent to notify the STA of what information the AP has obtained. This information can include, for example, AP can know the STA identification code (for example, 48-bit MAC address); AP can know the service requirements of the STA and the ability of the AP to provide these services; AP and STA share certificates/keys, etc., and/or needs What information, for example, the AP may need more information about the STA, such as confirmation from the STA and/or the STA's knowledge of the shared key, etc. When I know that your IE is used by a STA, it can be sent in the first message from the STA to the AP to inform the AP what information the STA has obtained about the AP in advance. For example, the AP is the better for the STA AP: The STA has obtained the MAC/PHY parameters of the AP in advance; the STA has a shared certificate/key with the AP; the STA is providing information about the STA to the AP and/or what information the STA still needs to obtain from the AP.

In addition, I know that your IE can also include suggestions from its sender on how to continue the remaining link setup procedures. For example, the suggestion may include a specific procedure to complete the link setup procedure, and may be based on information obtained in advance.

I know that your response to IE can be a response to IE that I know you can request more information. This response may include one or more confirmations, additions, and/or amendments to the information items listed in the I know you IE received.

Need more information IE can allow AP and STA to further exchange information, in order to assist ALS in the case that I know that you and I know that you respond to the IE message did not complete the necessary information communication. For example, in order to negotiate how to complete the link setup procedure, the AP and/or STA may need another round of message exchange to reach an agreement. Need more information response IE can be a response to IE that needs more information or can request other information I know you respond to IE.

The beacon transmission protocol can be implemented to reduce system overhead and assist in fast initial link setup. For example, short beacons can be transmitted in addition to regular beacons. The content of the short beacon can be minimized to reduce system overhead and carry basic information for quick initial link setup. In this example, the short beacon can be transmitted as frequently as required by the link setup delay requirement, and such Then, the regular primary beacon can be replaced in one or more continuous beacon cycles, the regular primary beacon can be replaced in a periodic manner, or it can be transmitted more frequently than the regular primary beacon. In addition, the content of the short beacon may be affected by the AP knowing mode, where in the AP knowing mode, the AP may have information about one or more STAs in advance. The short beacon can include information related to one or more of the following: AP discovery; network discovery; security (for example, authentication and association); higher-level protocols used to speed up the link setup process; I know you IE ; I know you respond to IE; need more information IE; and/or need more information to respond to IE.

An example short message beacon 400 supporting ALS is shown in Figure 4. For example, the short message frame 400 may include an optimization/minimization header 410, an information field 420 related to the main beacon, an optimization/minimization subset field 430 of the main beacon content, and an AP discovery information field Bit 440, a network discovery information field 450, a security-related information field 460, a higher-level protocol information field 470; and one or more optional element fields 480. The AP discovery information field 440, the network discovery information field 450, the security-related information field 460, and/or the higher-level protocol information field 470 may be included in the short message frame 400 as needed.

In another example, the beacon frame can be modified to assist in fast initial link setup. For example, the primary beacon can be modified to allow it to include basic information for quick initial link setup. In this example, the content of the beacon may be affected by the AP-aware mode, where in the AP-aware mode, the AP may have information about one or more STAs in advance. Beacons can include information related to one or more of the following: AP discovery; network discovery; security (for example, authentication and association); higher-level protocols used to speed up the link setup process; I know you IE ; I know you respond to IE; need more information IE; and/or need more information to respond to IE.

An example modification of the main beacon frame 500 supporting ALS is shown in FIG. 5. For example, the main beacon frame 500 may include a header 510, a main beacon content field 520, a short message beacon related information field 530, an AP discovery information field 540, a network discovery information field 550, and security related information fields. Information field 560, higher-level agreement information field 570; and/or one or more optional element fields 580. short Beacon-related information field 530, AP discovery information field 540, network discovery information field 550, security-related information field 560, and/or higher-level protocol information field 570 can be included as needed Main beacon frame 500.

In addition, the ALS capability indicator can be included in the beacon frame (both in the short beacon and in the modified main beacon). The ALS capability indicator can be encoded into the capability information field of the beacon frame by using reserved bits, or encoded into other information fields or information elements in the beacon frame.

The IEEE 802.11 management frame usually used in link setup can be modified to assist fast initial link setup (FILS). For example, association/re-association and probe request and response messages can be modified to assist FILS by including information related to one or more of the following: AP discovery; network discovery; security (for example, authentication and association); A higher-level protocol used to speed up the link setup process; I know you IE; I know you respond to IE; need more information IE; and/or need more information to respond to IE.

The IEEE 802.11 measurement pilot frame used to assist the STA in scanning can be modified to assist FILS. The measurement pilot frame may be a public behavior frame, which may include a subset of the information included in the main beacon, and may be transmitted more frequently than the main beacon frame. For example, the measurement pilot can be modified to assist FILS by including information related to one or more of the following: AP discovery; network discovery; security (for example, authentication and association); used to speed up link setup The higher-level protocol of the process; I know you IE; I know you respond to IE; need more information IE; and/or need more information to respond to IE.

In addition, other IEEE 802.11u frames (for example, General Advertising Service (GAS) initial request/response and GAS recovery request/response frames) can be modified to assist by including information related to one or more of the following FILS: AP discovery; network discovery; security (for example, authentication and association); higher-level protocols used to speed up the link setup process; I know you IE; I know you respond to IE; need more information IE; and/ Or need more information to respond to IE.

In another example, a management frame for assisting FILS (referred to as a FILS management frame) may include information related to one or more of the following: AP discovery; network discovery; security (for example, Authentication and association); higher-level protocols used to speed up the link setup process; I know your IE; I know you respond to IE; and/or need more information IE. The FILS management frame can be defined and implemented as a FILS management behavior frame that is defined as a behavior that supports the FILS function. The FILS management behavior 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 does not require an ACK response from the receiver.

The FILS management behavior frame can be a public behavior frame. The FILS management behavior frame can be used for AP information exchange between basic service sets (between BSSs) and with unassociated STAs. An example of such an information exchange scenario may include a transmitting STA or AP and a receiving STA or AP associated with a different BSS, and one or both of the transmitting and receiving STAs are not associated with the BSS. The FILS management behavior frame can also have a dual protection mode, which can be used for STA to STA communication.

An example FILS management behavior frame 600 is shown in FIG. 6. For example, the FILS management behavior frame 600 may include a category field 610, a behavior field 620, an AP discovery information field 630, a network discovery information field 640, a security-related information field 650, and a higher-level protocol information field. 660, and one or more optional element fields 670. The category field 610 may, for example, indicate that the FILS management behavior frame is a public behavior frame. The behavior field 620 may indicate FILS behavior. The AP discovery information field 630, the network discovery information field 640, the security-related information field 650, and/or the higher-level protocol information field 660 can be included in the FILS management behavior frame as needed.

The FILS management action frame can be transmitted by AP, and can be transmitted in unicast or broadcast mode. The AP can transmit FILS management behavior frames as frequently as needed to support the effective operation of FILS in the BSS/system.

In another example, the FILS management behavior function can be supported by FILS request frames and FILS response/report frames. The device sending the FILS request frame can request information related to one or more of the following: AP discovery; network discovery; security (for example, authentication and association); Higher-level protocols to accelerate the link setup process; I know your IE; I know you respond to IE; and/or need more information IE. The device that sends the FILS response/report frame can respond or report with information related to one or more of the following: AP discovery; network discovery; security (for example, authentication and association); for acceleration The higher-level protocol of the link setup process; I know you IE; I know you respond to IE; need more information IE; and/or need more information to respond to IE.

Information obtained in advance by AP and/or STA can be used to effectively optimize AP discovery. For example, the STA can obtain better AP information through a variety of mechanisms, such as the connection to the network before switching to the WLAN network, and the stored historical data of the AP and location. At the STA, the pre-obtained information can be divided into two main types: air interface MAC/PHY parameters, such as those in the beacon and/or probe response frame, such as the service set identifier (SSID)/basic service Set identifier (BSSID), service provision, capabilities, PHY parameters, supported rates, quality of service (QoS) capabilities, etc., and another type is security-related information, such as robust security network (RSN) information, A shared key/certificate with an expiry time and/or a valid authentication context with an expiry time. The minimum information obtained in advance at the STA may include the MAC address of the preferred AP, for example, the BSSID. Other information items can be available and used incrementally.

If the BSSID of the AP is the only information about the coverage area of the AP that the STA has obtained in advance, the AP discovery procedure can be optimized from at least two aspects. First, the STA can transmit a unicast probe request frame (non-wildcard). Second, once the detection response frame confirming the selection of the better AP is received, it can return to the AP discovery procedure without scanning all available APs in the area. If the AP's BSSID and any other information items have been obtained in advance by the STA, further optimization can be applied to the AP discovery.

Figure 7 is a schematic diagram showing an example AP discovery method 700 with pre-acquired knowledge of APs. In this example, AP 710 and/or STA 720 may have obtained information in advance from previous connections to the network (eg, 3G, other WLAN APs, etc.). The information obtained in advance can also come from the memory of the STA 720 and its current location. Information obtained in advance can be obtained in various ways. In a In this example, the AP 710 may receive a message including candidate STA information 722 from the network element 725. In another example, the STA 720 may receive a message including candidate AP information 726 from the network element 725.

Referring to FIG. 7, the STA 720 may receive a beacon 730 from the AP 710. The beacon 730 may include an ALS capability indicator. The STA may transmit a unicast request frame 740 to the AP 710. The unicast request frame 740 may be a probe request frame, and may include I know you IE. The unicast request frame 740 may be a new MAC management frame or a modified 820.11 MAC management frame. I know that your IE can include information items about the knowledge that the AP asks the STA for confirmation and/or correction from the AP, and it can also include a request indicator to request further information from the AP.

When the AP 710 receives such a request frame with I know you IE from the STA 720, the AP 710 can send a response frame 750 back to the STA 720. The response box 750 may include I know you responded to the IE, and I know you responded to the IE including further details on how to complete the link setup procedure. Another round of message exchange can be used for AP 710 and STA 720 to obtain further information about each other and reach an agreement on how to complete the link setup procedure. For example, the STA 720 may send a more information request frame 760, and receive a more information response frame 770 from the AP 710 in response. When the AP discovery phase 775 is completed, the remainder of the link setup 780 can be performed.

In this example, the AP discovery phase 775 can be completed in one or two message rounds between the STA and the AP, and it takes about 4ms to 10ms to complete. In addition, in this AP discovery stage 775, the pre-acquired knowledge can be used to derive an optimization method for the remaining part of the link setting function completed by the AP 710 and the STA 720.

The AP can obtain knowledge of candidate STAs in advance via its connection to the network. The information about the STA obtained in advance may include the MAC address of the STA; service requirements; security-related information (for example, a shared key/certificate with an expiration time); and/or a valid authentication context with an expiration time, etc. . Similarly, the minimum pre-acquired knowledge about the STA that the AP can have may include the MAC address of the STA. Other information items (for example, STA capabilities, one or more service requirements, safety Comprehensive information, etc.) can be available and used incrementally.

If the AP has obtained information about the STA in advance (for example, only the MAC address of the STA or the MAC address with additional information items), the AP can receive the first frame including the MAC address of the STA from the STA. After that, the ALS program is initiated.

FIG. 8 is a schematic diagram showing an example of an optimized AP discovery method 800 initiated by the AP 810 based on information obtained in advance. Information obtained in advance can be obtained in many different ways. For example, the network element 815 may send a message including candidate STA information 817 to the AP 810. In another example, the network element 815 may send a message including candidate AP information 819 to the STA 820.

In the example shown in Figure 8, when the AP 810 receives the first frame 830 (for example, a probe request frame) including the MAC address of the STA 820 from the STA 820, if the AP 810 has obtained information about STA 820 information, then the AP 810 can send a response frame 840 (for example, a probe response frame). The response frame 840 may include the I know you IE indicating that it may be the correct AP for the STA 820. I know your IE can be used to request further information from STA 820. The first frame 830 and the response frame 840 may each include an ALS capability indicator. When receiving such a response from the AP 810, the STA 820 can terminate the scanning procedure, so that the time for scanning can be significantly reduced. AP 810 and STA 820 can perform further information exchange. For example, the STA 820 may transmit a frame 850 that includes more information about the STA. The frame 850 may include suggestions for link setup procedures. In response, the AP 810 can send a frame 860 as a response. The frame 860 may include a confirmation of the suggested link setup procedure.

In addition, through STA 820 to AP 810 I know your IE response, and if necessary, further information exchange between AP 810 and STA 820, AP 810 and STA 820 can complete the link in a time-efficient manner Agree on the setup procedures. For example, AP 810 and STA 820 may agree to skip, optimize, or merge certain link setup stages. In this way, the AP 810 can successfully apply its pre-obtained information to actively participate in determining how to optimize the link setup process.

The optimization of link settings after AP discovery can vary with the available information that the AP and STA have obtained in advance before and during the AP discovery phase. Table 2 provides example AP discovery link settings optimization based on different assumptions of pre-acquired knowledge.

<tables><img he="2302" wi="1607" file="twi620449b_d0002.tif" img-content="drawing" img-format="tif" orientation="portrait" inline="no" /></tables>The security association established between the STA and the network (for example, a cellular network) can be enhanced to enable authentication and security on another network (for example, a WLAN network) in an on-demand and seamless manner Link settings. In one example, the reverse bootstrapping of application layer certificates on the network can be used to generate certificates for use in subsequent new access layer authentication procedures in another network. The goal of developing an authentication mechanism can be to optimize the steps and procedures involved, and to facilitate seamless authentication when roaming between various access networks.

Examples of using single sign-on (SSO) protocol (for example, OpenID connection) and reverse bootstrapping can allow STAs to discover and access previously unknown networks, such as WLAN networks. It may not be necessary to provide credentials in advance at the new network, as these can be bootstrapped from the security of the already operating application services.

Implementation options for the integration of SSO and WLAN networks can include the use of an AAA server, which integrates the functionality of an identity provider (OP) and enhanced ANDSF (eANDSF), and the AAA server integrates OP functionality .

Figure 9 is a schematic diagram of an example method 900 in which the AAA server 910 can integrate OP and enhanced ANDSF (eANDSF) functionality to enable seamless authentication and fast link setup. This example may assume that the STA 920 and the OP unit of the AAA server 910 have established a security association and a master key that can be enhanced for accessing the WLAN network. In the case that the association between the OP unit of the STA 920 and the AAA server 910 has not been established, an active 3GPP connection can be used between the STA 920 and the OP unit of the AAA server 910 to exchange OpenID connection authentication, and the two The master key is generated on each entity.

In the first example, the STA 920 can successfully complete the mutual authentication 930 of the OP unit of the AAA server 910 via the 3GPP access network, and share a master key (such as a pre-shared key (PSK)) ) May have been established on the OP unit of the STA 920 and the AAA server 910. In addition, the STA 920 and the eANDSF unit of the AAA server 910 may have mutually authenticated and established a secure connection 940 via the 3GPP enhanced S14 (eS14) interface, for example. STA 920 can be served from AAA The eANDSF unit of the server 910 requests WLAN network information, and/or the eANDSF unit of the AAA server can push the WLAN network information to the STA via a secure 3GPP connection. Network information can include available APs, SSIDs, authentication methods used, and other access network parameters. Using information about available APs and WLAN networks, the STA 920 may not need to perform passive scanning for beacons or perform lengthy network discovery procedures. The STA 920 may immediately transmit the probe request 950 to the AP 960 selected from the prioritized list provided to the STA 920 by the eANDSF unit of the AAA server 910.

After the STA 920 receives the probe response 970 from the selected AP 960, it can perform open authentication 971 and association 972 with the selected AP 960. If the 802.1x/EAP method is used, the open authentication 971 may not provide any security measurement and can be skipped.

The AP 960 may be referred to as an authenticator in this example, and may issue an EAP request 973 requesting an STA identification code. The STA 920 may return an EAP response 974, which may include a unique identification code, such as an International Mobile Subscriber Identity (IMSI) and its realm. This field can include a prompt to use SSO authentication, for example, IMSI@sso.MNO.com. The AP 960 can transmit an access request 975 to the AAA server using, for example, a RADIUS access request. The access request 975 may include the EAP ID. The OP unit of the AAA server 910 can identify the STA identification code and correlate it with the existing security association. The OP unit of the AAA server 910 may determine that the STA 920 has been authenticated, perform fast EAP authentication, and generate the PMK 976 based on the previously generated master key shared with the STA. The AAA server 910 can send an access acceptance message 977 to the AP 960. The access acceptance message 977 may include the EAP success to the AP 960 and key material. The AP 960 may forward the EAP success message 978 to the STA 920. The STA 920 can use the master key shared with the OP to generate the PMK 980.

When the AP 960 sends an EAP success message 978, the 802.1X/EAP authentication can be completed, and the AP 960 can initiate a 4-way handshake protocol 981 to obtain a temporary key 983. The temporary key 983 can include a key for encrypting unicast traffic. Paired transient key (PTK) and group transient key (GTK) used to encrypt broadcast and multicast traffic. The 4-way handshake protocol 981 can use four between AP 960 and STA 920 EAPOL key frame message.

The 4-way handshake can use a pseudo-random function (PRF) to hash different inputs to get a pseudo-random value. PMK may be one of the inputs combined with other inputs to create PTKs for STA 920 and AP 960. Some other inputs used by the pseudo-random function can be called random numbers. The random number can be a random value generated only once, which is used in an encryption operation and is associated with a given encryption key. For the 4-way handshake, random numbers can be associated with PMK. Random numbers can be used only once and cannot be used with PMK again. Two random numbers can be created by a 4-way handshake. The two random numbers are AP random number (ANonce) and requester random number (SNonce). Snonce can also be called STA random number.

In order to create PTK, the 4-way handshake can use a pseudo-random function, which combines PMK, numerical authenticator random number, requester random number, authenticator's MAC address (AA), and requester's MAC address ( SPA).

In the 4-way handshake procedure, AP and STA can each randomly create their own random numbers. The authenticator (for example, AP 960) may transmit an EAPOL key frame 982 to the requester (for example, STA 920). The EAPOL key frame 982 may include ANonce. The STA 920 can now have all the inputs necessary for the pseudo-random function. STA 920 can get PTK 983 based on PMK, ANonce, SNonce and MAC address. STA 920 can now have a PTK that can be used for encrypted unicast traffic.

The STA 920 can transmit an EAPOL key frame 984 to the AP 960. The EAPOL key frame can include SNonce. AP 960 can now have all the inputs needed for pseudo-random functions. The STA 920 can also transmit its RSN information element capability and message integrity code (MIC) to the AP 960. AP 960 can get PTK 985 based on PMK, ANonce, SNonce and MAC address. AP 960 can also verify MIC. AP 960 can now have paired transient keys that can be used to encrypt unicast traffic.

AP 960 can derive GTK 986 based on the group master key (GMK) it can possess. The AP 960 may transmit an EAPOL key frame 987 to the STA 920. The EAPOL key frame 987 may include ANonce, AP's RSN information element capability, and MIC. The EAPOL key frame 987 may also include a message to the STA 920 for installing a temporary key. GTK 986 can be used in unicast EAPOL keys The frame 987 is delivered to the STA 920. The confidentiality of GTK 986 can be protected because it can be encrypted with PTK 985. The STA 920 may send an EAPOL key frame 988 to the AP 960 to confirm that the temporary key has been installed.

Due to the optimization of the 4-way handshake procedure described above, it is possible to reduce the number of EAPOL key frame messages between AP and STA to two. This can be achieved using any of the following example optimizations. The OP unit and STA of the AAA server can enhance the master key to derive PMK and GMK keys. The AAA server can send both PMK and GMK to the AP. The first message of the 4-way handshake can be modified to include a random number (GNonce) randomly generated by the AP in addition to ANonce. STA can get PTK based on PMK, ANonce, SNonce and MAC address. STA can also derive GTK based on GMK, GNonce, and MAC address. The STA can now have a pair of transient keys (PTK, GTK), which can be used to encrypt and decrypt unicast, broadcast, and multicast traffic. The STA can send an EAPOL key frame including SNonce to the AP. The STA can also send its RSN information element capability and message integrity code (MIC) to the AP. AP can get PTK based on PMK, ANonce, SNonce and MAC address. AP can also derive GTK based on GMK, GNonce, and MAC address. In addition, the AP can verify the MIC.

At some point during the 4-way handshake procedure, the STA and AP may have PTK and GTK keys, which can be used to encrypt and decrypt unicast, broadcast, and multicast traffic. Therefore, the remaining procedures of the 4-way handshake procedure may not be needed.

At the end of the 4-way handshake procedure, the STA 920 can use the DHCP protocol to obtain the IP address and the necessary configuration 990, for example, one or more functional variable name servers (DNS) will be used, and the STA can now access the WLAN Network 995.

As a change to optimize the STA to obtain its IP address and necessary configuration, if eANDSF provides the IP address and necessary configuration to the STA via the cellular network, and the AAA server sends an encapsulated message to the STA, for example, using an EAP notification message To the IP address and necessary configuration in the EAP message, this step can be skipped.

Figure 10 is a schematic diagram of an example method 1000, in which the AAA server 1005 integrates the functionality of OP and eANDSF to enable seamless authentication and fast link settings. This example may assume that the STA 1010 and the OP unit of the AAA server 1005 have established a security association and a master key that can be enhanced for accessing the WLAN network. The STA 1010 can successfully complete the mutual authentication 1015 of the OP unit of the AAA server 1005 via the previously connected network (for example, the 3GPP access network), and the shared master key (PSK) can be in the STA 1010 and AAA server 1005 are established on the OP unit. In addition, the STA 1010 and the eANDSF unit of the AAA server can mutually authenticate, and a secure connection 1020 can be established, for example, via the 3GPP STA-eS14 interface. The STA 1010 can request WALN network information from the eANDSF unit of the AAA server 1005, and/or the eANDSF unit of the AAA server 1005 can push the WLAN network information to the STA 1010 via a secure 3GPP connection. Network information can include available APs, SSIDs, authentication methods used, and other access network parameters. Use information about available APs and WLAN networks, STA 1010 may not need to perform passive scanning of beacons or perform lengthy network discovery procedures. The STA 1010 may immediately transmit a probe request 1025 to the AP 1030 selected from the prioritized list provided to the STA 1010 by the eANDSF unit of the AAA server 1005.

After the STA 1010 receives the probe response 1035 from the selected AP 1030, it may perform open authentication 1040 and association 1041 with the selected AP 1030. If the 802.1x/EAP method is used, the open authentication 1040 may not provide any security measurement, and it can be skipped.

The AP 1030 may be referred to as an authenticator in this example, and may issue an EAP request 1042 requesting an STA identification code. The STA 1010 may return an EAP response 1043, and the EAP response 1043 may include a unique identification code, such as an International Mobile Subscriber Identity (IMSI) and its domain. This field can include a prompt to use SSO authentication, for example, IMSI@sso.MNO.com. The AP 1030 can transmit an access request 1044 to the AAA server 1005 using, for example, a RADIUS access request. The access request 1044 may include an EAP ID.

The OP unit of the AAA server 1005 can determine that the STA 1010 needs to send an access acceptance to the AP Re-authenticate before the message. Therefore, one or more rounds of EAP inquiry/response messages can be exchanged before sending the EAP success and key material to the AP. For example, the AAA server 1005 may generate an inquiry based on the STA-OP PSK (1045), and send an access inquiry message 1046 to the AP 1030. The access query message 1046 may include EAP ID and/or EAP query. The AP 1030 may send an EAP request message 1047 in response to the access query message 1046 to the STA 1010. The EAP request message 1047 may include an identification code and/or a query. STA 1010 can receive EAP request message 1047, verify MAC and generate SRES (1048), and send EAP response message 1049 to AP 1030. The EAP response message 1049 may include an identification code and/or a response to the query.

The AP 1030 may send an access request message 1050 to the AAA server 1005, and receive an access acceptance message 1051 from the AAA server 1005 in response. The access request message 1050 may include an EAP ID and/or a response to the query. The access acceptance message 1051 may include an EAP ID, a success indication, and a PMK key to the AP. In response to receiving the access acceptance message 1051, the AP 1030 may send an EAP success message 1052 to the STA 1010. In response to receiving the EAP success message 1052, STA 1010 can use STA-OP PSK to generate PMK (1053), and can perform 4-way handshake protocol 1054 with AP 1030, use DHCP to request IP address allocation (1055), and use WLAN Access the Internet (1056), as described in Figure 9 above.

Figure 11 is a schematic diagram of an example method 1100 in which the AAA server 1101 integrates the functionality of OP to enable seamless authentication and FILS. The example in Figure 11 may assume that the STA 1102 and the OP unit of the AAA server 1101 have established a security association and a master key that can be enhanced for accessing the WLAN network. The STA 1102 may have successfully completed mutual authentication of the OP via, for example, the 3GPP access network, and a shared master key (PSK) may be established on the OP unit of the STA 1102 and the AAA server 1101. The STA 1102 may not have a connection to eANDSF, and therefore, may perform WLAN network discovery through other mechanisms (for example, using 802.11u).

In the example shown in Figure 11, during the fast EAP procedure, the OP unit of the AAA server 1101 can recognize the STA identification code and correlate it with the existing security association. AAA server The OP unit of 1101 can determine that the STA 1102 has been authenticated, perform fast EAP authentication, and generate a PMK based on the previously generated master key shared with the STA 1102.

For example, the STA 1102 can successfully complete the mutual authentication 1103 of the OP unit of the AAA server 1101 via the network it has previously connected to (for example, the 3GPP access network), and the shared master key (PSK) can be It is established on the OP unit of the STA 1102 and the AAA server 1101. The STA 1102 may perform passive and/or active AP discovery 1104, as described in Figure 9. The STA 1102 can perform one or more GAS message exchanges to perform network discovery 1105. For example, the STA 1102 may send a GAS message 1106 to the AP 1107, and receive a GAS response message 1108 from the AP 1107 in response.

The STA 1102 can perform open authentication 1109 and association 1110 with the selected AP 1107. If the 802.1x/EAP method is used, the open authentication 1109 may not provide any security measurement, and it can be skipped.

The AP 1107 may be referred to as an authenticator in this example, and may issue an EAP request 1112 requesting an STA identification code. The STA 1102 may return an EAP response 1113, which may include a unique identification code, such as an International Mobile Subscriber Identity (IMSI) and its domain. This field can include a prompt to use SSO authentication, for example, IMSI@sso.MNO.com. The AP 1107 can transmit an access request 1114 to the AAA server 1101 using, for example, a RADIUS access request. The access request 1114 may include an EAP ID.

The AAA server 1101 can generate a PMK (1115) from the STA-OP PSK, and send an access acceptance message 1116 to the AP 1107. The access acceptance message 1116 may include an EAP ID, a success indication, and a PMK key to the AP. The AP 1107 may send an EAP success message 1119 to the STA 1102. In response, STA 1102 can use STA-OP PSK to generate PMK (1102), and can perform 4-way handshake protocol 1121 with AP 1107, use DHCP to request IP address allocation (1122), and access the Internet via WLAN ( 1123), as described in Figure 9 above.

Figure 12 is a schematic diagram of an example method 1200, in which the AAA server 1201 can integrate OP functions Performance to enable seamless authentication and FILS. This example may assume that the STA 1202 and the OP unit of the AAA server 1201 have established a security association and a master key that can be enhanced for accessing the WLAN network. The STA 1202 can successfully complete the mutual authentication of the OP unit of the AAA server 1201 via, for example, the 3GPP access network, and the shared master key (such as PSK) can be on the OP unit of the STA 1202 and the AAA server 1201 It is established. The STA 1202 may not be connected to eANDSF, and therefore, may perform WLAN network discovery through other mechanisms (for example, using 802.11u).

Referring to Figure 12, STA 1202 may perform passive and/or active AP discovery 1205, as described in Figure 9. The STA 1202 may perform one or more GAS message exchanges to perform network discovery 1206. For example, the STA 1202 may send a GAS message 1207 to the AP 1204, and receive a GAS response message 1208 from the AP 1204 in response.

The STA 1202 may perform open authentication 1209 and association 1210 with the selected AP 1204. If the 802.1x/EAP method is used, the open authentication 1209 may not provide any security measurement, and it can be skipped.

The AP 1204 may be referred to as an authenticator in this example, and may issue an EAP request 1211 requesting an STA identification code. The STA 1202 may return an EAP response 1212, which may include a unique identification code, such as an International Mobile Subscriber Identity (IMSI) and its domain. This field can include a prompt to use SSO authentication, for example, IMSI@sso.MNO.com. The AP 1204 can transmit an access request 1213 to the AAA server 1201 using, for example, a RADIUS access request. The access request 1213 may include an EAP ID.

The OP unit of the AAA server 1201 can determine that the STA 1202 needs to perform re-authentication before sending an access acceptance message to the AP 1204. Therefore, one or more rounds of EAP inquiry/response messages can be exchanged before sending the EAP success message and key material to AP 1204. For example, the AAA server 1201 may generate an inquiry from the STA-OP PSK (1214), and send an access inquiry message 1215 to the AP 1204. The access query message 1215 may include EAP ID and/or EAP query. AP 1204 can send The STA 1202 sends an EAP request message 1216 in response to the access query message 1215. The EAP request message 1216 may include an identification code and/or a query. The STA 1202 can receive the EAP request message 1216, verify the MAC and generate an SRES (1217), and send an EAP response message 1218 to the AP 1204. The EAP response message 1218 may include an identification code and/or a response to the query.

The AP 1204 may send an access request message 1219 to the AAA server 1201, and receive an access acceptance message 1220 from the AAA server 1201 in response. The access request message 1219 may include an EAP ID and/or a response to the query. The access acceptance message 1220 may include an EAP ID, a success indication, and a PMK key to the AP. In response to receiving the access acceptance message 1220, the AP 1204 may send an EAP success message 1221 to the STA 1202. In response to receiving the EAP success message 1221, STA 1202 can use STA-OP PSK to generate PMK (1222), and can perform 4-way handshake agreement 1223 with AP 1204, use DHCP to request IP address allocation (1224), and save via WLAN Take the Internet (1225), as described in Figure 9 above.

Figure 13 is a schematic diagram of an example method 1300 for implementing a pre-established security association between the STA 1301 and the network to achieve seamless authentication and fast initial link setup. In this example, Fast EAP can be encapsulated into an 802.11 authentication frame. It can be assumed that the STA 1301 and the network (such as the AAA server 1302 with integrated OP functionality) have established a security association and a master key that can be enhanced for secure access to the WLAN network. The STA may have successfully completed the mutual authentication of AAA/OP 1303 via the 3GPP access network, and the shared master key (PSK) and FILS identification code 1304 may have been established on the STA 1301 and the AAA server 1302.

In this example, the 802.11 authentication frame can encapsulate a fast EAP message between the STA 1301 and the AP 1305. In addition, Snonce and Anonce can use an authentication frame to exchange, and the authentication frame can enable the 4-way handshake protocol to be executed at the same time. For example, the STA 1301 can generate a Snonce 1306 and send an authentication message 1307 to the AP 1305. The authentication message 1307 may include an EAP response message and indicate the serial number, FILS ID, Snonce, and/or Auth-tag. AP 1305 can store Snonce (1308) and send an access request message to AAA server 1302 1309. The access request message 1309 may be an EAP message, and may include FILS ID, sequence number (SEQ), and/or Auth-tag.

The AAA server 1302 can use the FILS identification code to look up the pre-established security context with the STA 1301. The AAA server 1302 can verify the serial number. The server can then continue to use the integrity key to verify the integrity of the message, thereby verifying the proof that the peer owns that key. If all verifications are successful, the AAA server 1302 can generate a PMK (1310) from the STA-OP PSK, and send an access acceptance message 1311 to the AP 1305. The access acceptance message may include the session key (for example, PMK), EAP success message, SEQ, FILS ID, channel binding information (CB-Info) field, and/or authentication tag (Auth-tag). Auth-tag can enable the receiver (such as STA or AAA server) to verify the integrity of the received message and determine its validity. The AAA server 1302 can send the CB-Info in the EAP message (not shown) so that the STA can verify that the EAP message was received via the correct AP instead of a compromised AP.

If the STA 1301 includes the optional [IP_Configuration_Request]([IP_CFG_REQ]) field in the authentication message 1307, the AAA server 1302 can use the [IP_Configuration_Reply]([IP_CFG_Reply]) field in the EAP success message The IP configuration is transmitted to the STA 1301. Note that parentheses can indicate optional fields.

In addition, the AAA server 1302 can send channel binding information [CB-Info] in the EAP success message, so that the STA 1301 can verify that the EAP message was received via the correct AP instead of a compromised AP.

In response to receiving the access acceptance message 1311, the AP 1305 can derive PTK (1312) from PMK, Anonce, and/or Snonce, and generate GTK. The AP 1305 may send an authentication message 1313 to the STA 1301. The authentication message 1313 may include, for example, an EAP success message that may indicate SEQ, FILS ID, CB-Info, Anonce, and/or Auth-tag.

In response to receiving the authentication message 1313, STA 1301 can derive PTK (1314) and install GTK. At the end of successful authentication, STA 1301 and AP 1305 can use (PTG, GTK) key Be prepared to protect the data exchanged via 802.11 radio between STA 1301 and AP 1305 (1315).

In the case that the STA 1301 does not have the necessary IP configuration, the STA 1301 can use, for example, the 802.11 associated frame exchange to provide the IP address configuration necessary for the FILS-certified STA, so that it can be ready to start applications, such as Internet streaming View, or safely switch an ongoing session from a network (such as 3GPP) to a WLAN network. For example, the STA 1301 may send an association message 1316 to the AP 1305, and receive an association message 1317 from the AP 1305 in response. The associated message 1316 may include the [IP-CFG-REQ] field, and the associated message 1317 may include the [IP-CFG-Reply] field.

Figure 14 is a schematic diagram of an example method 1400 for pre-established security associations between the STA 1401 and the network (for example, the AAA server 1402) to achieve seamless authentication and fast initial link setup. In this example, Fast EAP can be encapsulated into an 802.11 association frame. The AAA server 1402 may be configured to perform OP functions.

This example may assume that the STA and the AAA server 1402 have established a security association and a master key that can be enhanced for secure access to the WLAN network. It can be assumed that the STA 1401 has successfully completed the mutual authentication 1403 of the OP unit of the AAA server 1402 via the 3GPP access network, and the shared master key (PSK) and FILS identification code 1404 can be used in the STA 1401 and the AAA server It was established on 1402.

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

In response to receiving the access request frame 1409, the AAA server 1402 can download the STA-OP PSK Generate PMK (1410). The AAA server 1402 can send an access acceptance frame 1411 to the AP 1407. The access acceptance frame 1411 may include PMK and/or EAP success messages, and indicate SEQ, FILS ID, [IP-CFG-Reply], [CB-Info], and/or Auth-tag.

In response to receiving the access acceptance frame 1411, the AP 1407 can derive PTK (1412) from PMK, Anonce, and/or Snonce, and generate GTK. The AP 1407 may transmit an association frame 1413 to the STA 1401. The association frame 1413 may include an EAP success message and indicate SEQ, FILS ID, [CB-Info], Anonce, [IP-CFG-Reply], and/or Auth-tag. STA 1401 can obtain PTK (1414) and install GTK, and access the Internet via WLAN (1415).

In this example, the 802.11 association frame can include at least the following content: (1) Fast EAP message between STA and AP; (2) Snonce and Anonce required to complete the 4-way handshake protocol at the same time; (3) For simultaneous [IP-CFG-REQ] from the STA to the AP and [IP-CFG-Reply] from the AP to the STA of the occurred IP address allocation. At the end of the association, the FILS-certified STA can have the necessary IP address configuration to safely access the WLAN network.

Figure 15 is a schematic diagram of an example method 1500 for pre-established security associations between the STA 1501 and the network (for example, the AAA server 1502) to achieve seamless authentication and fast link setting. This example can be based on non-EAP FILS authentication. The AAA server 1502 may be configured to perform OP and/or eANDSF functions.

This example may assume that the STA 1501 and the AAA server 1502 have established a security association and a master key that can be enhanced for secure access to the WLAN network. It can be assumed that the STA 1501 has successfully completed the mutual authentication 1503 of the OP unit of the AAA server 1502 via, for example, the 3GPP access network, and the shared master key (PSK) and FILS identification code are in the STA 1501 and the AAA server 1502. Was established on (1504).

In this example, the 802.11 authentication frame carries a non-EAP authentication message between the STA 1501 and the AP 1505. In addition, Anonce can use an authentication frame to transmit from AP 1505 to STA 1501, and the authentication frame can enable STA 1501 to derive PTK.

The 802.11 association frame can carry Snonce from the STA 1501 to the AP 1505, so that the AP 1505 can derive the PTK on its own side. In addition, the association frame can carry the optional IP configuration request [IP-CFG-REQ] from the STA 1501 to the AP 1505, and carry the [IP-CFG-Reply] from the AP 1505 to the STA 1501. At the end of the association, the FILS-certified STA has the necessary IP address configuration to safely access the WLAN network.

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

In response to receiving the access acceptance message 1509, the AP 1505 may send an authentication message 1510 to the STA 1501. The authentication message 1510 may include SEQ, [CB-Info], Anonce, and/or Auth-tag. The STA 1501 can generate a Snonce (1511), obtain a PTK, and send an association message 1512 to the AP 1505. The association information 1512 may include Snonce, [IP-CFG-REQ], and/or Auth-tag.

AP 1505 can derive PTK (1513) from PMK, Anonce, and Snonce, and generate GTK. The AP 1505 may send an association message 1514 to the STA 1501. The association message 1514 may include GTK, [IP-CFG-Reply], and/or Auth-tag. In response to receiving the association message 1514, the STA 1501 can install GTK (1515) and securely access the Internet via WLAN (1516).

At the end of the AP discovery phase, ALS capable STAs and APs can negotiate the ALS AP post-discovery procedure based on the availability and amount of information about each other obtained in advance by the STA and AP. This pre-obtained information may include, for example, one or more of network service information, TSF information, 802.11 authentication and association information, EAP/802.1x authentication and security information, and IP address allocation information. Based on this available pre-obtained information, the STA or AP can initiate a customized (customized) negotiation of AP discovery procedures.

An example of the signaling used for AP discovery procedure negotiation is shown in Table 3, which lists potential behaviors in each stage of the link setup procedure after AP discovery, and is represented by a binary sequence. A series of digits starting with "0b" in Table 3 can indicate that the digits after "0b" are expressed in a binary format.

<tables><img he="2091" wi="1678" file="twi620449b_d0003.tif" img-content="drawing" img-format="tif" orientation="portrait" inline="no" /></tables>The realization of negotiation signaling after AP discovery can be multiple. For example, the negotiation after AP discovery can be implemented using the above FILS management behavior frame, wherein the negotiation signaling code used for each stage after AP discovery can be located in the corresponding field of the FILS management behavior frame. In another example, the negotiation letter The code can be implemented as a bitmap in the IE of the AP discovery message (for example, I know you IE and/or I know you respond to IE). In another example, the negotiation signaling code can be implemented in IEs included in other management and control frames (such as beacons, probe requests, and probe responses).

Using the example code in Table 3, a STA or AP can include a 15-bit ALS information field to express its most optimized link setup procedure after AP discovery. The ALS information field can be divided into segments of different sizes, and each segment corresponds to a link setup phase after AP discovery. The order of the bits in the identifier may be the same as the order of the functional stages shown in Table 3. For example, bits 14 and 13 correspond to the network discovery stage.

For example, if the AP has obtained the identification information of the candidate STA in advance (for example, MAC address and/or service requirement information), the AP can determine that the network discovery, additional TSF, and 802.11 authentication phases can be skipped, and when the AP is from When the STA receives a frame (for example, a probe request frame), the link setup procedure should go through the 802.11 association, EAP authentication, and/or DHCP-based IP address allocation phases. Therefore, the AP can send a detection response frame with I know your IE to the STA. The I know your IE includes the 15-bit AP-discovered program code "0b111 1110 0000 0000". If the STA receives this AP discovery program code, the STA can send the I know you response IE with the same or modified code in the management frame to confirm or modify the AP discovery program, or the STA can directly send The next stage of the code proposal (e.g., 802.11 association) is to implicitly accept the code. In this way, the AP can initiate link setup optimization via the use of its pre-obtained knowledge about the STA.

In another example, when the STA includes the ALS information field "0b111 111 01 0010 001" for its ALS AP post-discovery procedure in its probe request frame to a better AP, the STA can indicate One or more of: The most optimized ALS AP discovery procedure using this specific AP can include the network discovery phase, and additional TSF and 802.11 authentication can be skipped; the modified 802.11 association phase can be used; Use fast EAP authentication and fast key provision schemes; and/or can use optimized IP address allocation, for example, via one or more layer 2 The message carries one or more DHCP messages. An AP that receives a probe request indicating that the STA is a STA with pre-obtained information can use a similar sequence to transmit a probe response frame, depending on the amount of information about the STA that the AP has obtained in advance. The STA that receives the probe request can respond by sending a FILS management behavior frame to confirm that it agrees to the optimization and customization of the ALS AP post-discovery program.

When the AP and the STA negotiate the AP-discovery procedure, if the AP and the STA have different requirements for one or more stages of the link setup procedure, then more stringent requirements can prevail. An example of different requirements may be a situation where the STA can request to skip the network discovery phase and the AP can request the 802.11u network discovery phase. In this example, the STA can agree to the 802.11u network discovery phase when requested by the AP. In addition, the final agreement to the program after the optimized ALS AP is discovered can be positively confirmed for the correct operation of the ALS. This confirmation can be achieved by transmitting the FILS management behavior frame, which includes the agreed ALS AP post-discovery procedure, and the unicast frame to the corresponding STA or AP (for example, the detection request frame). , Detection response frame, association request frame, etc.) Instruct to agree to the ALS information field of the procedure after ALS AP discovery.

Another example method may include the use of pre-acquired system configuration knowledge. The system configuration for this example can be referred to as a system parameter set that is static or semi-static for a particular system deployment and operation mode. Such system parameters may also be referred to as system configuration parameters, and "system" in this context may refer to a wireless LAN system based on IEEE 802.11.

The system configuration can be obtained in advance by the STA before initiating the link setup procedure with the BSS/AP, and it can be used to speed up the initial link setup procedure.

The system configuration parameter set can be defined. For example, in order to specify the operating mode of a wireless LAN system, the following three different configurations can be defined and used: (1) BSS/AP configuration, also known as BSS configuration or AP configuration; (2) Access network configuration; and ( 3) Combined AP/network configuration, also known as AP/network configuration.

Each of the above configurations can contain a set of system parameters, which specify the corresponding system parameters System operation settings. The AP configuration parameter set may include BSS/AP operating parameters/descriptors that are static or semi-static as the value changes over time.

In order to use the system configuration information as pre-obtained knowledge to speed up the link setup process, the following basic rules can be used to select AP configuration parameters: (a) Parameters that can be used to start BSS/AP operation, for example, in 802.11 The parameters used by the MLME_START.request primitive; (b) The parameters used to specify the BSS/AP operation settings, which can be transmitted between AP and STA, such as in a beacon frame or a detection response frame, etc. Medium; (c) Parameters that do not dynamically change values over time, for example, maintaining the same value for hours, days, or even months; and/or (d) Parameters that can be related to link settings.

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

<tables><img he="1831" wi="1379" file="twi620449b_d0004.tif" img-content="drawing" img-format="tif" orientation="portrait" inline="no" /></tables><tables><img he="2205" wi="1388" file="twi620449b_d0005.tif" img-content="drawing" img-format="tif" orientation="portrait" inline="no" /></tables><tables><img he="2240" wi="1376" file="twi620449b_d0006.tif" img-content="drawing" img-format="tif" orientation="portrait" inline="no" /></tables>The above example BSS/AP configuration parameter set is based on each BSS/AP 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 an existence indicator to indicate whether the parameter value exists in a specific configuration instance. The configuration instance may be referred to as a configuration indicator. This allows a subset of the parameters in the configuration set to specify specific BSS/AP operations with the help of specific PHY modes and/or the selection of certain optional system features and functions (such as QoS support, interworking services, etc.) model.

The access network configuration parameter set may include static or semi-static operating parameters or descriptors of the access network after the BSS/AP, which may be related to the link settings of the STA. Similarly, in order to use access network configuration information as pre-acquired knowledge to speed up the link setup process, the following basic rules can be applied to select access network configuration parameters: (a) can be used to specify access network services, Parameters of capabilities, attributes, and/or functions, such as those used in accessing network discovery messages (for example, access network query protocol (ANQP/GAS)); (b) parameters that do not dynamically change values over time , For example, keep the same value for hours, days, or even months; and/or (c) parameters related to link settings.

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

<tables><img he="1856" wi="1382" file="twi620449b_d0007.tif" img-content="drawing" img-format="tif" orientation="portrait" inline="no" /></tables>Similarly, the above-mentioned access network configuration parameter set may be based on each BSS/AP, where the access network may be a network that the STA can connect via the wireless LAN of the BSS/AP. In addition, as shown in Table 5, for each parameter in the access network configuration parameter set, the presence indicator can be used to indicate whether the parameter value exists in a specific configuration instance, so that a subset of the configuration parameters can be allowed to specify Specific network operation of selected optional features and functions (for example, emergency alert service, etc.).

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

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

A system configuration instance with a configuration change count can be identified. A system configuration instance may refer to a configuration parameter set having a specific value assigned to each configuration parameter. Configuration parameters can be used to specify the corresponding system operation mode. If the configuration parameter set can be defined for use in a system with optional features or functions, then the configuration instance can include a subset of configuration parameters with valid values, and the remaining parameters can be marked as "non-existent."

Any change to the configuration instance can result in a new configuration instance, for example, a parameter value change, or a "non-existent" parameter is changed to "exist" with an assigned valid value, or a "existent" parameter is changed to "non-existent", etc. A configuration instance can be identified by its version number, which is also called configuration change count (CCC), or configuration serial number (CSN). CCC can be an integer variable, and its value can be changed every time the configuration instance changes. CCC can be changed based on a predefined function. An example may be that the CCC increases by 1 every time the configuration instance changes, and returns to 0 once it reaches its maximum value.

The BSS/AP configuration can be defined based on each BSS/AP, which can be identified by the BSSID (for example, the MAC address of the AP). AP configuration change count (AP-CCC) can be used to identify AP configuration Instance. Therefore, for example, a combination of BSSID, configuration type, and/or AP-CCC can be used to identify a configuration instance of a given AP, where the configuration type can indicate a specific configuration among multiple configurations that can be defined and used, such as BSS/AP configuration , Access network configuration, etc.

Similarly, integer variables (for example, access network configuration change count (AN-CCC)) can be used to identify the version number of the access network configuration instance. The combination of BSSID, configuration type, and/or AN-CCC can be used to identify the configuration instance of the access network through the AP.

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

The system information communication can be performed using a predefined set of system configuration parameters. In a wireless LAN system, system information (for example, BSS/AP operating parameters, access network functions, and/or attributes, etc.) can be sent to the STA for initial link settings and when returning from power saving mode The link is restored. The system configuration parameter set can be defined to improve the efficiency of system information communication between AP/network and STA.

When the system configuration is used to facilitate effective system communication, the definition of the system configuration parameter set can be known by the AP/network and STA. One way to meet this requirement may be to standardize the definition of configuration parameter sets via a standards organization (eg, IEEE 802). Alternatively, the definition of the system configuration parameter set may be first transmitted between the AP/network and the STA via a wireless link and/or a wired link before the configuration is used.

Pre-defined system configuration parameter sets can be used at AP/network and STA. The following example outlines how the AP/network can support the use of a predefined set of system parameters to send system information to the STA.

In the first example, for each defined/used system configuration parameter set, the AP can 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 each time the configuration instance changes.

In the second example, the AP can provide AP system information based on a predefined BSS/AP configuration parameter set. This example may include, for example, providing a full BSS/AP configuration example and its corresponding AP-CCC in the beacon frame and/or probe response frame. Alternatively, the AP may only provide AP system information via the AP-CCC, for example, in the FILS discovery frame, short message beacon frame, etc.

In the third example, the AP can provide access network system information based on a predefined access network configuration parameter set. For example, the AP can provide a full-access network configuration example and its corresponding AN-CCC in the GAS/ANQP frame, for example. Alternatively, the AP may only provide access to network information via AN-CCC, for example, in the beacon, probe response, FILS discovery, and/or short message beacon frame.

In the fourth example, the AP can provide AP/network system information based on a predefined combined AP/network configuration parameter set. For example, the AP may provide a full AP/network configuration example and its corresponding AP/AN-CCC in a beacon frame, a probe response frame, and/or a GAP/ANQP frame, for example. Alternatively, the AP may only provide AP/network information via the AP/AN-CCC, for example, in the FILS discovery frame, short message beacon frame, etc.

Figure 16 is a schematic diagram of an example method 1600 for supporting the use of a predefined system parameter set. Referring to FIG. 16, the AP may receive a probe request including a system configuration identifier (for example, a combination of BSSID, configuration type, and/or CCC that can match the CCC possessed by the AP) (1610). If the received system configuration identifier matches the AP's system configuration identifier (1620), the AP can transmit a reduced probe response (1630). The reduced detection response may refer to a detection response frame in which the configuration parameter sets do not exist independently in the response frame. On the contrary, the CCC value that is the same as the CCC value in the probe request frame can be used to indicate the configuration parameter set to indicate that the probe request sender STA has a valid configuration instance. If the received system configuration identifier does not match the AP's system configuration identifier (1620), the AP can send a full probe response with an update set of configuration parameter values and the corresponding configuration instance identifier, or send a partially reduced probe response ( 1640), the partially reduced detection response may refer to a detection response frame that does not include a fully configured instance. Conversely, a partially reduced probe response can contain a new configuration instance identifier and a subset of configuration parameters (e.g., Those configuration parameters with new values). In other words, it may contain a value different from the configuration instance identified by the configuration instance identifier provided in the probe request frame.

This example may require the AP to be able to recognize the difference between its current configuration instance and the configuration instance identified by the configuration instance identifier provided in the probe request frame. The configuration examples are compared with their respective changes, and/or the configuration examples are divided into parameter subsets (for example, subset 1, subset 2, subset 3, and subset 4) to achieve. The CCC can also be divided into four parts, for example, the first 4 bits are associated with subset 1; and/or the last 4 bits are associated with subset 4. By checking the CCC from the STA in the probe request, the AP can discover the changed parameter subset.

The STA can keep track and use pre-obtained knowledge about the BSS and/or network in the form of a predefined system configuration parameter set to obtain system information. For example, the STA can 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 for which the STA has acquired knowledge, there may be an entry in the database, which may include BSSID, SSID, location, last update time, configuration parameter set and/or corresponding configuration change count (for example , BSS/AP configuration, access network configuration, and/or combined AP/network configuration, etc.), and the value of each configuration parameter that can be indicated by its presence indicator. The entries in the configuration database can be organized to facilitate quick access to content, for example, sorting based on BSS/AP STA usage, or sorting based on BSS/AP location, or sorting based on STA-based entity movement routines, etc. . When the STA obtains knowledge about the new BSS/AP, the entry in the configuration database can be initialized and can be maintained every time the STA receives an update about the BSS/AP (for example, a configuration instance with a new CCC value) The entry. STA can obtain BSS/AP configuration and/or access via a wireless link with a BSS/AP, or a wireless link with another BSS/AP, or a wireless link in a cellular network, or a wired link, etc. Knowledge of network configuration.

Figure 17 is another example method 1700 for supporting the use of a predefined system parameter set. Schematic. For example, when an STA receives a fully configured instance and its corresponding CCC in a beacon frame, a probe response frame, and/or a GAS/ANQP frame (1710), it can check the configuration knowledge it has acquired Whether there is an entry in the database (1720). If there is no entry in the configuration knowledge database that it has acquired, it can create a new entry (1730). If there is an entry in the configuration knowledge database it has obtained, it can check whether the newly received configuration change count matches the value in the configuration database (1740). If it matches, then there is no need to update the configuration database (1750). If it does not match, the STA can update the database with the newly received configuration instance and its corresponding CCC value (1760).

Figure 18 is a schematic diagram of another example method 1800 for supporting the use of a predefined system parameter set. For example, the STA may receive configuration instance identifiers that do not have full configuration instance information in the FILS discovery frame, short message beacon frame, or reduced detection response frame (1810). The STA may determine whether the CCC value in the received configuration instance identifier matches the stored value (1820). If the CCC value in the newly received configuration instance identifier does not match the value stored in the configuration database, the STA can mark the corresponding configuration instance as "discarded" in the database (1830). If the CCC value in the newly received configuration instance identifier matches the value stored in the configuration database, it does not need to make any changes to the configuration database (1840).

FIG. 19 is a schematic diagram of an example method 1900 in which the STA can use the received configuration instance identifier information without full configuration instance information to determine whether it has obtained the latest system information of the AP and/or the network. This example can be used to improve the efficiency of system information communication. For example, the STA may start scanning (1910). The STA can perform active or passive scanning. The STA can, for example, receive the BSS/AP configuration change count value without full AP configuration instance information in the FILS discovery frame, short message beacon frame, or reduced detection response frame (1920). The STA can determine whether there is a valid entry for the BSS/AP in the configuration database (1930). If there is a valid entry for the BSS/AP in the configuration database, the STA can determine whether the received configuration change count value matches the value in the database (1940). If the received AP-CCC matches the AP-CCC in the database, then the STA can It is determined that it has valid latest BSS/AP system information. The STA can then complete the BSS/AP scanning procedure (1950) without waiting for the beacon frame or the detection response frame. In this case, the BSS/AP configuration information in the database can be used by the MLME of the STA to construct a scan report (1960) in the MLME-SCAN.confirm primitive, and can also be used in the STA to initiate the initial link setup procedure The next step (for example, association). If there is no valid BSS/AP entry in the configuration database, or the received configuration change count does not match the value in the database, the STA can continue scanning (1970).

FIG. 20 is a schematic diagram of an example method 2000 in which an STA may include configuration instance identifier information for a pre-obtained system configuration. During the active scan (2010), the STA can send a detection request frame (2020) including configuration instance identifier information for its pre-obtained system configuration, where the configuration instance identifier can be BSSID, configuration type, and/or CCC The combination. When used in the probe request frame, the configuration instance identifier (for example, AP configuration identifier) represents a parameter in the configuration. After that, those configuration parameters no longer need to be separately included in each probe request frame or reduced probe request frame. In other words, the use of the configuration instance identifier information allows the STA to use a reduced detection request frame, so that the airtime occupied by the detection request can be reduced.

When the STA receives a response (2030), it can determine whether the received response is a full, partial, or reduced detection response frame (2040). When the STA receives a reduced detection response frame with configuration identifier information but no full configuration instance (2045), the STA can use its configuration database to retrieve its pre-obtained knowledge in the above-mentioned manner (2050). When the STA receives a partial detection response frame (2055), the STA can update the database accordingly (2060). When the STA receives the full probe response frame (2065), the STA can determine whether the CCC value in the received response matches the value in the database (2070). If the CCC value matches (2075), then there is no need to update the database (2080). If the CCC value does not match (2085), the STA can update the database accordingly (2060).

During network discovery and selection, for example, using GAS/ANQP, STA can request in GAS The frame includes access to the network configuration identifier information to indicate the network configuration knowledge obtained in advance. In addition, when receiving a GAS response with configuration instance identifier information but no full network configuration instance, the STA can use its configuration database to retrieve its pre-obtained network configuration knowledge.

There are also many alternatives for how to manage the pre-obtained configuration knowledge database in the STA's layered agreement architecture. For example, the pre-obtained configuration knowledge database can be managed by the MAC layer management entity (MLME), the station management entity (SME), or the connection manager module on the MAC/PHY of the wireless LAN air interface.

If the pre-obtained configuration knowledge database is not managed by MLME, some information from the database (for example, configuration instance identifier) may need to be included in the service access between MLME and the module that manages the database (for example, SME) Point (SAP) in the primitive.

If the pre-obtained configuration knowledge database is not managed by MLME, for example, if it is managed by SME, two parameters (for example, configuration type and AP configuration change count) may need to be included in the primitive MLME-Scan.request. Table 6 below shows an example.

<tables><img he="480" wi="1537" file="twi620449b_d0008.tif" img-content="drawing" img-format="tif" orientation="portrait" inline="no" /></tables>If the pre-obtained configuration knowledge database is not managed by MLME, for example, if it is managed by SME, the BSS description using configuration change count set parameters may need to be included in the primitive MLME-Scan.confirm to allow the discovery of beacons and short beacons from FILS Or the reduced detection response frame is only the configuration type and AP-CCC can be used. Table 7 below shows an example.

<tables><img he="670" wi="1602" file="twi620449b_d0009.tif" img-content="drawing" img-format="tif" orientation="portrait" inline="no" /></tables>Each BSS description usage configuration change count may include one or more of the elements shown in Table 8 below.

<tables><img he="1278" wi="1528" file="twi620449b_d0010.tif" img-content="drawing" img-format="tif" orientation="portrait" inline="no" /></tables>In another example, a fast link setup with pre-acquired knowledge based on location can be used. Location-based pre-acquired knowledge can refer to what the STA already knows about a certain geographic location (for example, those frequently accessed locations, including residences, offices, meeting rooms, daily train stations, local airports, parents' residences, or other families Knowledge of the accessible and/or better network of the member's residence, etc.). Location-based accessibility/better network knowledge can include not only system information about network operation modes, but also security association information between STAs and the network. When entering frequent deposit When fetching the location, this location-based pre-obtained accessible/better network knowledge can be used to speed up the link setup process. In addition, it can also be used to facilitate fast switching between accessible networks, for example, offloading from cellular to WLAN, or switching from WiFI to cellular.

The STA can keep track of location-based pre-acquired knowledge in a better location-based network database, which may also be referred to as a location-based network profile, or simply a location profile. The location in the database can be specified by geographic location descriptors, such as longitude, latitude, altitude, and optional location information, and/or civilian location descriptions. For each location in the database, there can be one or more accessible and/or better networks. For each accessible and/or better network, the database can record the knowledge acquired by the STA in advance, such as network identifier, network type, network configuration parameter set and value, and STA and network Security-related information, etc.

Figure 21 is a schematic diagram of an example method 2100 for performing fast link setup using location-based pre-acquired knowledge. In this example, the STA may start link setup (2110), and determine whether the STA location is available (2120). If the STA location is unavailable (2130), the STA can perform a regular link setting procedure (2140). If the STA location is available (2150), the STA may determine whether the STA location profile is available (2160). If the STA location profile is available (2170), the STA can perform optimized link settings (2180). If the STA location profile is not available (2185), the STA can perform normal link settings (2140).

The content in the location-based network database may be configured to the STA and/or may be self-learned and maintained by the STA. When information about the STA's current location is available, the STA's network management module (for example, Network Connection Manager) can use its location-based network database to optimize its network operations, for example, using fast initial The link setting is offloaded from the cellular network to the WiFi network, establishing an additional connection with the second network to distribute different types of traffic, and/or reselecting a more suitable network, etc.

The following example can use location-based pre-acquired knowledge to speed up the link setup process in a WiFi network. For example, when an STA is connected via an existing network connection and/or an embedded location When you know its current location.

Figure 22 is a schematic diagram of the first example method 2200 for link setup optimization, in which an STA that has access to its location-based network database knows exactly which BSS to connect to for a given location. In this example, the STA can skip all steps before the association step in the typical 802.11 link setup procedure. The STA can send an association request frame to the BSS/AP (2210). Compared with the conventional association request frame, the association request frame also has some additional information items, for example, its knowledge about AP/network operation settings, such as A configuration instance identifier with a combination of BSSID, configuration type, and/or CCC; and/or its knowledge about security association with AP/network. The STA may determine whether a response is received from the BSS/AP (2220).

If the STA does not receive a response within the predetermined time interval (2225), the BSS/AP may be unavailable, and the STA can use a location-based network database or perform a BSS/AP reselection through a regular scanning procedure ( 2230). It should be noted that this scenario is possible, but it is a rare case because it can include the assumption that the STA knows that a better network (for example, a home network or an office network) is accessible.

If the STA receives a response from the AP confirming that the STA's pre-acquired knowledge is valid for, for example, a configuration change count including a match (2235), the STA can proceed to the next step in the link setup procedure without the pre-acquired knowledge. The knowledge database performs arbitrary maintenance actions. This example may assume that the received response may also include regular associated response content items.

If the STA receives the pre-obtained knowledge from the AP indicating that the STA needs one or more updates for including different configuration change counts and corresponding configuration instance information in addition to the conventional association response content items (2240). In this example, the STA can perform an update of its pre-obtained knowledge about the AP/network, and it can perform a corresponding update of its database before proceeding to the next step (2260) of the link setup procedure . If the STA receives a response from the AP indicating that the STA's pre-obtained knowledge does not need to be updated, the STA can continue the link setup procedure (2260).

STA can use pre-obtained security association information with AP/network to optimize security Set up the program. Note that with the above optimization, the link setup procedure can completely skip a time-consuming step (for example, AP/network discovery), and can also significantly reduce another time-consuming step by using location-based pre-acquired knowledge The time of the step (for example, security settings). This procedure may only require about 5 message rounds between the STA and the AP (for example, 1 for association, 2 for security, and 2 for IP address assignment), plus the connection between the AP and the DHCP server The two messages in between will complete the establishment of the IP connection between the STA and the AP/network. Therefore, if the program uses the same time value of the link setup steps given above, the link setup time can be reduced to about 20ms.

In the second example of accessing its location-based network database, the STA may have knowledge about the better BSS/AP at a given location, but may require further confirmation before establishing a connection. In this example, the STA can first verify whether it has valid information about the AP/network, and then it can use the steps given in the previous example to complete the link setup procedure. The following optimizations can be considered to accelerate AP/network information verification.

STAs can use reduced probe request/response frames and/or reduced GAS request/response frames, where "reduced" can refer to the parameter sets in those frames, rather than including the configuration of each parameter separately Identifier information (for example, a combination of BSSID, configuration type, and/or CCC). When the STA receives a response frame with configuration identifier information that matches the information in the database, the STA can verify its information about the AP/network, and can proceed to the next step in the link setup procedure.

In addition, if the STA receives a response frame with a full configuration instance and different CCC values, then the STA has actually obtained a new update of the corresponding system information, so it can also proceed to the next step. In addition, there can be multiple ways to send reduced probe request/response frames, for example: STA can send reduced unicast probe requests, where the configuration instance identifier information can be provided by the BSSID in the MAC frame header, and the configuration type One or more combinations of CCC and CCC values are provided in the frame body. With the reduced probe request of unicast, the STA can verify its pre-obtained knowledge about a BSS/AP and its associated access network, and configure it with one or more predefined systems. Setting parameter set; STA can transmit broadcast reduced probe request, which can include multiple configuration instance identifiers, each with a combination of BSSID, configuration type, and CCC. By broadcasting reduced probe requests, the STA can verify its pre-obtained knowledge about one or more BSS/APs and their associated networks in the same coverage area. After receiving the broadcast reduced probe request, if the BSSID of the AP is one of the BSSIDs in the configuration instance identifier information provided in the request frame, the AP and/or STA can respond; if the AP and/or The STA has at least one configuration instance identifier that matches one of the identifiers provided in the request frame, and the AP and/or STA can use the reduced detection response frame to perform the received reduction of the detection request. Response; if the BSSID and configuration type of the configuration instance of the AP and/or STA match the corresponding value in one of the identifiers provided in the request frame but the configuration change count does not match, the AP and/or STA can A conventional probe response frame with a fully configured instance and the identifier of the AP and/or STA is used to respond to the received reduced probe request.

STA can use configuration instance identifier information, for example, in smaller system information notification frames that are sent more frequently (compared to regular beacon frames) (for example, short message beacon frame, fast beacon frame, or FILS discovery The combination of BSSID, configuration type, and/or CCC value provided in the frame, etc.). If the configuration instance identifier matches the corresponding configuration instance identifier in the database, the verification is complete and the STA can proceed to the next step in the link setup procedure.

Note that the link setup time in this case can be the sum of the time used to verify the AP/network information and the time in the previous example. If active scanning is used, for example, using reduced detection request/response frames, the link setup time can be about 25ms. If you use a smaller system information notification frame that is sent more frequently (compared to a regular beacon frame) (such as a short message beacon frame, or a fast beacon frame, or a FILS discovery frame, etc.), the link setting time can be It is about 20ms plus the interval between these frames.

Example

1. A device comprising: The receiver is configured to receive messages; the processor is configured to generate a paired master key (PMK); and the transmitter is configured to transmit a request to an access point (AP) to pass a wireless local area network (WLAN) Establishing an Internet Protocol (IP) address allocation; and wherein the receiver and the transmitter are further configured to communicate with a server via the WLAN using the PMK.

2. The device according to embodiment 1, wherein the message indicates that the Extensible Authentication Protocol (EAP) procedure is successful.

3. The device according to embodiment 1 or 2, wherein the request is a request for dynamic host configuration protocol (DHCP).

4. The apparatus according to any one of the preceding embodiments, wherein the server is an authentication, authorization, and accounting (AAA) server.

5. The apparatus according to any one of the preceding embodiments, wherein the receiver and the transmitter are further configured to communicate with a server including an enhanced access network discovery and selection function (eANDSF).

6. The apparatus according to any one of the preceding embodiments, wherein the receiver and the transmitter are further configured to communicate with a server including an identity provider (OP) function.

7. The apparatus according to any one of the preceding embodiments, wherein the processor is configured to use a station identity provider (STA-OP) pre-shared key (PSK) to generate the PMK.

8. The device according to any one of the foregoing embodiments, wherein the transmitter and the receiver are further configured to perform a 4-way handshake protocol.

9. The device of embodiment 8, wherein the 4-way handshake protocol uses a pseudo-random function to obtain a pseudo-random value.

10. The device of embodiment 9, wherein the pseudo-random value is a random number.

11. The apparatus of embodiment 10, wherein the random number is associated with a pre-shared key (PSK).

12. The apparatus according to any one of the preceding embodiments, wherein the receiver is further configured to receive an Extensible Authentication Protocol (EAP) (EAPOL) key frame of the first local area network (LAN).

13. The device of embodiment 12, wherein the transmitter is further configured to transmit a second EAPOL key frame in response to the first EAPOL key frame.

14. The device of embodiment 12, wherein the first EAPOL key frame includes a random number associated with the AP.

15. The device of embodiment 14, wherein the second EAPOL key frame includes a random number associated with the device.

16. The device according to any one of the embodiments 13-15, wherein the receiver is further configured to receive the third EAPOL key frame.

17. The device of embodiment 16, wherein the transmitter is further configured to transmit a fourth EAPOL key frame in response to the third EAPOL key frame.

18. The device according to any one of the preceding embodiments, wherein the transmitter is further configured to send a request for WLAN information to the server.

19. The device according to embodiment 18, wherein the WLAN information includes available AP, service set identification code (SSID), authentication method, or access network parameters.

20. The device according to embodiment 18 or 19, wherein the transmitter is further configured to transmit a probe request frame to an access point (AP) without performing scanning based on the requested WLAN information.

twenty one. The device of embodiment 20, wherein the scan is an active scan.

twenty two. The device of embodiment 20, wherein the scan is a passive scan.

twenty three. The device according to any one of the preceding embodiments, wherein the receiver is further configured to receive a probe response frame.

twenty four. The apparatus according to any one of the preceding embodiments, wherein the processor is further configured to perform an open authentication protocol and association with the AP.

25. The apparatus according to any one of the preceding embodiments, wherein the receiver is further configured to The AP receives an Extensible Authentication Protocol (EAP) request.

26. The apparatus of embodiment 25, wherein the transmitter is further configured to transmit an EAP response to the AP.

27. The device of embodiment 26, wherein the EAP response includes an identification code of the device.

28. The device according to any one of the preceding embodiments, wherein the device is a station (STA).

29. The device of any one of embodiments 1-27, wherein the device is an integrated circuit (IC).

30. An apparatus including: a transmitter configured to transmit a request; and a receiver configured to receive a response in response to the request.

31. The device of embodiment 30, wherein the request is an access request message.

32. The device according to embodiment 30 or 31, wherein the response is an access acceptance message.

33. The apparatus according to any one of the embodiments 30-32, wherein the transmitter is further configured to transmit the Extensible Authentication Protocol (EAP) (EAPOL) of the first local area network (LAN) to the station (STA) Key frame.

34. The device of embodiment 33, wherein the receiver is further configured to receive a second EAPOL key frame in response to the first EAPOL key frame.

35. The device of embodiment 33 or 34, wherein the first EAPOL key frame includes a random number associated with the AP.

36. The device of embodiment 35, wherein the second EAPOL key frame includes a random number associated with the device.

37. According to the device of any one of embodiments 30-36, the device further includes a processor configured to derive a paired transient key (PTK).

38. The apparatus of embodiment 37, wherein the processor is further configured to obtain a group temporary Key (GTK).

39. The device according to any one of embodiments 34-38, wherein the transmitter is further configured to transmit a third EAPOL key frame.

40. The device of embodiment 39, wherein the receiver is further configured to receive a fourth EAPOL key frame in response to the third EAPOL key frame.

41. The device according to any one of the embodiments 30-40, wherein the response is an access query message.

42. The apparatus of embodiment 41, wherein the receiver is further configured to receive an EAP response from a station (STA).

43. The device according to embodiment 42, wherein the transmitter is further configured to transmit an access request in response to the received EAP response to the server.

44. The device of embodiment 43, wherein the receiver is further configured to receive an access acceptance message from the server.

45. The device according to any one of embodiments 30-44, wherein the device is an access point (AP).

46. The device of any one of embodiments 30-44, wherein the device is an integrated circuit (IC).

47. A method that can be executed by the device described in any one of Embodiments 1-29.

48. A method that can be executed by the device described in any one of embodiments 30-46.

49. A method, the method comprising: receiving a detection request frame; determining whether a system configuration identifier matches a stored system configuration identifier; and when the system configuration identifier matches the stored system configuration identifier, Sending a reduced detection response frame in response to the detection request frame.

50. The method according to embodiment 49, wherein the detection request frame includes a system configuration identification Do not match.

51. The method according to embodiment 49 or 50, wherein the reduced detection response frame is a detection response frame omitting parameters.

52. According to the method of any one of embodiments 49-51, the method further includes: in the case that the system configuration identifier does not match the stored system configuration identifier, transmitting a response to the detection request The full detection response frame or the partially reduced detection response frame of the frame.

53. The method according to embodiment 52, wherein the partially reduced detection response frame is a detection response frame that does not include a full configuration indicator.

54. A method, the method includes: receiving a configuration indicator and a corresponding configuration change count (CCC) value.

55. According to the method of embodiment 54, the method further includes: determining whether there is a configuration indicator entry in the obtained configuration knowledge database.

56. According to the method of embodiment 55, the method further includes: creating a new configuration indicator entry in the case that there is no configuration indicator entry in the obtained configuration knowledge database.

57. The method of embodiment 56, wherein the new configuration indicator entry is based on the received configuration indicator and the received corresponding CCC value.

58. According to the method of embodiment 57, the method further includes: determining whether the received CCC value matches the CCC value in the obtained configuration knowledge database.

59. According to the method of embodiment 58, the method further includes: in the case that the received CCC value does not match the CCC value in the obtained configuration knowledge database, updating the obtained configuration knowledge database.

60. The method of embodiment 59, wherein the obtained configuration knowledge database is based on The received CCC value is updated.

61. An access point (AP) configured to perform the method described in any one of embodiments 49-53.

62. An integrated circuit (IC) configured to perform the method described in any one of embodiments 49-53.

63. A non-access point (non-AP) configured to perform the method described in any of the embodiments 54-60.

64. An integrated circuit (IC) configured to perform the method described in any one of embodiments 54-60.

Although the features and elements are described above in specific combinations, those of ordinary skill in the art can understand that each feature or element can be used alone or in combination with other features and elements. In addition, the method described here can be implemented in a computer program, software, or firmware that is introduced into a computer-readable medium and operated by a computer or a processor. Examples of computer-readable media include electrical signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, buffer memory, semiconductor memory devices, magnetic media (such as internal hard drives and removable Diskettes), magneto-optical media, and optical media (such as CD-ROM discs, and digital versatile discs (DVD)). The processor associated with the software can be used to implement the radio frequency transceiver used in the WTRU, UE, terminal, base station, RNC, or any host computer.