RU2665894C2 - System and method for utilising stored higher layer information - Google Patents

Abstract

FIELD: information technology.SUBSTANCE: invention relates to a station and a method for operating a station during a discovery process. Method includes steps of transmitting first layer 2 frame to an access point (AP), said first layer 2 frame including a first version number associated with first higher layer information, and an identifier of a protocol associated with both the first higher layer information and the first version number, receiving second layer 2 frame from the access point including an indication that a second version number associated with a second higher layer information is same as the first version number, and deciding whether to perform a network selection process in accordance with the first higher layer information. Said first layer 2 frame is an IEEE 802.11 GAS initial request frame and second layer 2 frame is an IEEE 802.11 GAS initial response frame.EFFECT: technical result consists enabling network selection.25 cl, 22 dwg, 1 tbl

Description

Technical field

The invention generally relates to the field of digital communication and, more specifically, to a system and method for using stored information of a higher level.

State of the art

The IEEE 802.11 family of technical standards and related technologies, also commonly referred to as Wi-Fi, is evolving towards a service-oriented connectivity model when devices are connected for a specific purpose. Targeted connections are triggered by applications when searching for a network and / or peer devices that support certain services. Examples of such services include information sharing, printing, streaming media content, sensor information, and the like.

Disclosure of the invention

Exemplary embodiments of the present invention provide a system and method for utilizing high level stored information.

According to an exemplary embodiment of the present invention, a method for controlling a station during a detection process is provided. The method includes the steps of transmitting by the station a first level 2 frame to an access point (AP), the first level 2 frame including a first version number associated with the first high level information and a protocol identifier associated with both the first high-level information, and with the first version number, receive by the station a second level 2 frame from the AP, including an indication that the second version number associated with the second information of a higher level is the same as rvy version number, and make a decision with the help of the station, whether to perform a process for network selection according to the first high-level information.

According to another exemplary embodiment of the present invention, a method for controlling an access point is provided. The method includes the steps of receiving, using an access point, a first level 2 frame from a station, the first level 2 frame including a first version number associated with the first high level information and a protocol identifier associated with both the first high level information and the first version number, using the access point, the second version number associated with the second high-level information is obtained from the server, it is determined using the access point whether the first version number and the version number match And transmitting via a second access point on the frame-level station 2, when the first version and the second version number of the same, wherein the second layer 2 frame includes an indication that the first version and the second version number of the same.

According to another exemplary embodiment of the present invention, a station is provided configured to perform a detection process. The station includes a processor and a computer-readable storage medium for storing programs for execution by the processor. Programs include instructions for transmitting a first level 2 frame to an access point (AP), wherein the first level 2 frame includes a first version number associated with the first high level information and a protocol identifier associated with both the first high level information so and with the first version number, receiving the second level 2 frame from the AP, including an indication that the second version number associated with the second high level information is the same as the first version number, and making a decision, trace whether to perform a process for network selection in accordance with the first high-level information.

In accordance with another exemplary embodiment of the present invention, an access point configured to receive participation in a discovery process is provided. An access point includes a processor and a computer-readable storage medium for storing programs for execution by a processor. Programs include instructions for receiving a first level 2 frame from a station, the first level 2 frame including a first version number associated with the first high level information and a protocol identifier associated with both the first high level information and the first number version, receiving the second version number associated with the second high-level information from the server, determining if the first version number and the second version number match, and transmit the second level 2 frame to the station when the first omer version and the second version number of the same, wherein the second layer 2 frame includes an indication that the first version and the second version number of the same.

According to another exemplary embodiment of the present invention, a method for controlling the operation of a communication device configured to transmit a frame is provided. The method includes the steps of generating, using a communication device, a level 2 frame containing at least one tuple field of a common announcement group (CAG), in which at least one CAG tuple field contains a CAG version number field containing a CAG version number , an area field containing an area value, and an identifier of an announcement protocol field, and a level 2 frame is transmitted using the communication device.

In accordance with another exemplary embodiment of the present invention, a station is provided. The station includes a processor and a computer-readable storage medium for storing programs for execution by the processor. Programs include instructions for generating a level 2 frame containing at least one tuple field of a common ad group (CAG), in which at least one CAG tuple field contains a CAG version number field containing a CAG version number, an area field, containing the value of the region, and the identifier of the announcement protocol field, and sending a layer 2 frame.

In accordance with a further example of the first embodiment of the present invention, there is provided a station including:

means for transmitting the first level 2 frame to an access point (AP), wherein the first level 2 frame includes a first version number associated with the first higher level information and a protocol identifier associated with both the first high level information and the first version number

means for receiving a second level 2 frame from the access point, including an indication that the second version number associated with the second high level information is the same as the first version number, and

means for deciding whether to complete the network selection process in accordance with the first high-level information.

In a first aspect, in accordance with a first further example, the station may further include means for receiving first high level information and a first version number, and storing first higher level information and a first version number.

In the second aspect, in accordance with the first additional example or the first aspect in accordance with the first additional example, the first version number is contained in the announcement protocol element in the first layer 2 frame.

In the third aspect, in accordance with the first additional example or the first aspect in accordance with the first additional example, the first version number is contained in the common announcement group (CAG) number element in the first level 2 frame.

In the fourth aspect, in accordance with the first further example or the first aspect in accordance with the first further example, the first layer 2 frame further includes requesting second higher level information.

In the fifth aspect, in accordance with the first additional example or any of the aspects in accordance with the first additional example, the first layer 2 frame is a GAS frame of an IEEE 802.11 standard request, and the second layer 2 frame is a CAG frame of an IEEE 802.11 initial response.

In accordance with a second additional example of an embodiment of the present invention, an access point is provided. Access Point Includes:

means for receiving a first level 2 frame from the station, the first level 2 frame including a first version number associated with the first high level information and a protocol identifier associated with both the first high level information and the first version number,

means for obtaining a second version number associated with the second high-level information from the server,

means for determining whether the first version number and the second version number match, and

means for transmitting a second level 2 frame to the station when the first version number and the second version number are the same, the second level 2 frame including an indication that the first version number and the second version number are the same.

In a first aspect, in accordance with a second further example, the access point includes means for transmitting a third level 2 frame to the station when the first version number and the second version number do not match, and the third level 2 frame includes an indication that the first version number and second version number do not match.

In a second aspect, in accordance with a second further example, or with a first aspect in accordance with a second further example, the access point includes means for receiving a fourth level 2 frame from the station, the fourth level 2 frame including calling request, forwarding the request to a request to the server, receiving a response to the call from the server and transmitting the fifth level 2 frame to the station, the fifth level 2 frame including a response to the call.

In the third aspect, in accordance with the second additional example or any of the first aspect and the second aspect in accordance with the second additional example, the access point includes means for obtaining, when the first version number and the second version number do not match, request requests from the first frame level 2, the direction of the request to the server, in accordance with the protocol identifier, receiving a response to the request from the server and transmitting the sixth level 2 frame to the station, and the sixth level 2 frame includes an answer t on appeal.

In the fourth aspect, in accordance with the second additional example or any of the first aspect, the second aspect and the third aspect in accordance with the second additional example, an indication that the first version number and the second version number are the same is contained in the status code field in the second layer 2 frame.

According to a third further example, a station is provided. The station includes:

means for generating a level 2 frame containing at least one tuple field of the common ad group (CAG), wherein at least one CAG tuple field contains a CAG version number field containing a CAG version number, an area field containing an area value, and an identifier announcement protocol fields, and means for transmitting a layer 2 frame.

In accordance with the first aspect, in accordance with a third additional example, the CAG field of the version number is 8 bits.

In a second aspect, in accordance with a third further example, the announcement protocol field identifier is a partial declaration protocol identifier field containing a partial announcement protocol identifier and is 5 bits in size, with the partial announcement protocol identifier having the 5 least significant bits of the announcement protocol declaration protocol identifier associated with with the CAG version number and region value within the same CAG of the tuple field, and in which the region field is 3 bits in size.

In a third aspect, in accordance with a second aspect, in accordance with a third further example, the announcement protocol is an access network request protocol (ANQP) and the partial announcement protocol identifier field contains a value of zero.

According to a fourth aspect, according to a second aspect, according to a third additional example, the announcement protocol is a registered location request protocol (RLQP) and the partial declaration protocol identifier field contains a value of 4.

The implementation method of the above embodiments allows the AP to ensure that the request is sent along the shortest path that the STA initiates to the server supporting the high-level service, when the STA version number of the stored high-level information is the same as the version number of the current high-level information of the server, providing thereby, a quick response to the STA, and allowing the STA to make a quick decision, such as, for example, the decision to choose a network.

Moreover, in the case where the APs do not need to recognize the content of the request for a high level request or the response to the request by using a signaling tool outside the container field, which transmits a request for a high level request or a response to the request, for example, using an ad protocol element or CAG element number, to transmit the high level information version number and using the status code value to indicate that the version number of the high level stored information is the same as (or comes from him) the version number of the current high-level server information that supports the high-level service.

Brief Description of the Drawings

For a more complete understanding of the present invention and its advantages, the following is a description together with the accompanying drawings, in which:

FIG. 1 shows a first example of a communication system in accordance with exemplary embodiments described herein;

FIG. 2 shows a second example of a communication system where CAG and ANQP operations are highlighted in accordance with the exemplary embodiments described herein;

FIG. 3a shows an example of a body format of a CAG frame of an original request frame;

FIG. 3b shows an example format of an announcement protocol element;

FIG. 4 shows a general format for ANQP elements;

FIG. 5 shows a list of examples of ANQP elements;

FIG. 6 shows an example of a query list format of an ANQP element;

FIG. 7 shows an example of a body format of a CAG frame of an original response frame;

FIG. 8 shows an example format of a CAG number element;

FIG. 9 shows an example CAG format of an ANQP element;

FIG. 10 illustrates a messaging circuit 1000, with emphasis on an example of messaging during a network discovery process performed between an STA, an AP, and an ANQP server, in accordance with exemplary embodiments described herein;

FIG. 11 shows the format of an exemplary announcement protocol element when an announcement protocol element is contained in a CAG frame of an initial request, in accordance with exemplary embodiments described herein;

FIG. 12 shows a messaging diagram, with emphasis on an example of messaging during the process of network discovery, service discovery, or information discovery performed between the STA, the AP, and the server, in accordance with the exemplary embodiments described herein;

FIG. 13 illustrates a messaging scheme with a focus on an alternative example of messaging during the network discovery, service discovery, or information discovery process performed between the STA, the AP, and the server, where the STA is also optimized to save network bandwidth by efficiently utilizing signaling overhead in in accordance with exemplary embodiments described herein;

FIG. 14a shows a flowchart of a first example of operations 1400 occurring in an STA when performing a network discovery process, a service discovery or an information discovery process, in accordance with exemplary embodiments described herein;

FIG. 14b shows a flowchart of a second example of operations 1450 occurring in an STA when performing a network discovery process, service discovery, or information discovery process, in accordance with exemplary embodiments described herein;

FIG. 15a shows a flowchart of a first example of operations 1500 occurring in an AP when performing a network discovery process, a service discovery, or an information discovery process, in accordance with exemplary embodiments described herein;

FIG. 15b shows a flowchart of a second example of operations 1550 occurring in an AP when performing a network discovery process, a service discovery or an information discovery process, in accordance with exemplary embodiments described herein;

FIG. 16 shows an example CAG of an IE 1600 by including in an identifier of a protocol identifier an announcement associated with a CAS version number, in accordance with the exemplary embodiments described herein;

FIG. 17 shows an example of an alternative embodiment of a CAG of an IE number, according to exemplary embodiments described herein;

FIG. 18 shows a flowchart of an example of operations 1800 that occur in a communication device when transmitting a frame including a CAG number IE, in accordance with exemplary embodiments described herein; and

FIG. 19 shows a computing platform that can be used to implement, for example, the devices and methods described herein in accordance with an embodiment.

The implementation of the invention

The following is a detailed description of the current exemplary embodiments and their structure. It should be borne in mind, however, that the present invention provides many applicable exemplary embodiments that can be embodied in a wide variety of specific contexts. The described exemplary embodiments illustrate only specific disclosure structures and methods for using the information of the invention and do not limit the scope of the invention.

One of the embodiments of the present invention relates to the use of stored information of a higher level. For example, a station transmits a first layer 2 frame to an access point (AP), the first layer 2 frame including a first version number associated with the first high level information and a protocol identifier associated with both the first higher level information and the first version number, receives the second level 2 frame from the AP, including an indication that the second version number associated with the second high-level information is the same as the first version number, and decides whether to execute The process of selecting a network according to the first high-level information.

The present invention will be described with reference to exemplary embodiments in a specific context, namely, with respect to communication systems that support service oriented connections and pre-association for service discovery prior to establishing a connection. The invention can be applied to the standards of compatible communication systems, such as those that comply with the IEEE 802.11ai, IEEE 802.11af, IEEE 802.11aq, Wi-Fi Alliance (WFA) specification for optimized connection (OCE), WFA TV (TVWS) specification unused frequency spectrum, WFA application service platform - infrastructure specification (ASP-I), third-generation partnership project (3GPP) device-to-device communication specification (D2D), etc., technical standards and non-standard compatible communication systems that support service orient th e compound and detecting the provisional association.

In FIG. 1 shows a first example of a communication system 100. The communication system 100 includes an access point (AP) 105, which services a plurality of devices, such as device 110, device 112, device 114, device 116, and device 118. The AP can also be referred to as a base station, communication controller, controller, NodeB, Advanced NodeB (eNB) and the like. A device may also commonly be called a station (STA), a user device (UE), a mobile station, a mobile device, a user, a subscriber, a terminal, and the like. In the first communication mode, devices can communicate through the AP 105 by transmitting a frame to the AP 105, which forwards the frame to the specified recipient. In the second communication mode, the first device can transmit a frame directly to the second device without the need for using the AP 105.

As will be appreciated, communication systems can use multiple APs that can communicate with multiple stations, but for ease of explanation, see FIG. 1 shows only one AP and several stations.

The STA typically performs network discovery and selection procedure (NDS) before learning access to the AP and the services it provides. The NDS procedure is performed prior to the authentication and association procedure and typically includes AP discovery.

The IEEE 802.11u technical standard defines a specialized message retrieval and exchange protocol (ANQP) and a layer 2 frame delivery vehicle known as group announcement service (GAS) frames to provide STAs with the ability to detect features, services, access network parameters and / or network provider subscription service (SSPN) connected to the AP, prior to association with the AP, so that the STAs make an informed decision about choosing a network. The GAS delivery mechanism has been expanded to support additional declaration protocols, such as medium independent handover (MIH), as defined in the IEEE 802.21 standard, and the Registered Location Request Protocol (RLQP), as defined in the IEEE 802.11af standard change. Currently, the IEEE 802.11aq project is also considering the use of GAS to support the pre-association detection protocol to detect service information before association.

In FIG. 2 shows a second example of a communication system 200 with a focus on GAS and ANQP operations. First, the device’s user initiates an intention to connect to Wi-Fi, and the user’s device scans for available access points, which are also referred to as Wi-Fi access points. In IEEE 802.11u, GAS frames are used to provide transport of Layer 2 request access data and response protocol request data between the client on the user's device and the access point that is connected to the server on the network, before authentication and association with the AP. Request request data and request response data are additionally transported between the AP and the server, usually by means of IP transport and a higher level protocol, such as diameter or Remote User Authentication over Telephone Lines (RADIUS). In IEEE 802.11u, ANQP is a specific announcement protocol used to detect various features and available access network services. After receiving the response data of the ANQP request, the user device selects a specific access point and then performs authentication and association procedures, which leads to the establishment of a connection with the AP.

The communication system 200 may be an example of a system compatible with Wi-Fi communication systems. The communication system 200 may use communication services and protocols, such as GAS and ANQP, to support operations including scanning and network selection. In general, GAS frames can be used to ensure the delivery of level 2 request data and response data of an announcement protocol, such as ANQP, between a terminal and a server in a communication system, such as communication system 200, before or after authentication and association (terminal, for example) . Typically, ANQP can be used to detect various features and / or services of a communication system. The device compares information regarding various networks or access points to select the most suitable for association, for example. The device can continue the authentication process.

Typically, a station can be used to refer to any of the devices (e.g., devices 205, 207, and 209), as shown in FIG. 2, which may include a cell phone, a laptop computer, a tablet, a smart sensor, a handheld or portable electronic device, and other devices that have an interface (eg, a Wi-Fi interface) that can communicate with the communication system 200. Some or all stations may also be able to interact with other types of communication systems, such as cellular networks, Bluetooth, company networks and the like.

The access point 210 and one or more stations can form a basic service set (BSS), which is the basic building block of a Wi-Fi communication system. The BSS can be identified by a Service Set Identifier (SSID), which is an identifier and can be transmitted by a BSS, such as an AP 210. The AP 210 can communicate with an AP controller and / or ANQP server, which can be combined or not with AP 210. AP 210 can be connected to a network service provider 215, which is connected to one or more concentrators 220 for roaming. Roaming hubs 220 may be connected to a reference location register (HLRs) 225. Roaming hubs 220 and HLRs 225 provide support for device mobility, i.e., roaming.

GAS frames were defined in 802.11u and are currently integrated in the IEEE 802.11-2012 standard. GAS frames include a GAS frame of the original request, a GAS frame of the response to the request, a GAS frame of the initial response, and a GAS frame of the response. The GAS frame of the original request is sent to the requesting STA to initiate the request process. As shown in FIG. 3a, the GAS body of the source request frame contains a category field 305 and an action field 310 that together indicate that the frame is a GAS frame of the original request, a dialog token field 315 containing a sequence number used to match the response to the request, announcement protocol element 320, field 360 calls to the request and the field 340 of the length of the calls to the request indicating the length in octets of the field 360 requests to request.

Announcement Protocol Element 320 is used to indicate an announcement protocol associated with requesting a request contained in a GAS frame of the original request. When a response request return frame or a GAS response response frame is included in the GAS, the announcement protocol element is also used to indicate the announcement protocol associated with the request response included in the GAS response request frame or the GAS response return frame. As shown in FIG. 3b, the announcement protocol element 320 includes a request response information field 325 and an announcement protocol ID field 331. The announcement protocol ID field 331 contains the identifier specified for the corresponding announcement protocol. The request response information field 325 is a 1-octet field consisting of a 7-bit subfield 327 of the request response length limit and a 1-bit PAME-BI subfield 329. The IEEE 802.11-2012 standard defines that when an announcement protocol element is contained in a beacon, sample response, GAS frame of the original request, or GAS response response frame, then the subfield for limiting the length of the response to the request contains the maximum number of octets that the responder can pass to the field the response to the request contained in one or more GAS response return frames, and when the announcement protocol element is contained in the GAS frame of the original request, such as announcement protocol element 320, then only 1 octet field 325 of the response information to the request anavlivaetsya to zero, and the respondent (e.g., access point) field is ignored during reception.

Request field 360 is a common container that transmits a request for announcement protocol request, which is usually above level 2 in the protocol stack and uses the level 2 delivery service provided by GAS frames. Thus, the AP is not required to receive the GAS frame of the original request to interpret the contents of the request field 360. The AP can simply extract the content of the request field 360 on the basis of the value of the request length field field 340 and forward it to the corresponding announcement protocol server based on the value in the announcement protocol ID field 331 and using the protocol and delivery means that were established between the access point and server. In a typical deployment scheme, the AP connects to the server via a wired connection using IP-based delivery. Examples of top-level protocols used between the AP and the server include Diameter and RADIUS.

For ANQPs, the request call contained in the request call field 360 typically contains a request sheet of an ANQP element that provides an identifier sheet of ANQP elements for which receiving STAs are requested. ANQP elements are defined to have a common format consisting of a 2-octet information ID field, a 2-octet length field, and a variable-specific data information field specific to the element, as shown in FIG. 4. FIG. 5 illustrates a sheet of several examples of ANQP elements defined in 802.11-2012. Most of the ANQP elements listed in FIG. 5 are used to generate ANQP responses to a request. Request sheet An ANQP element is one exception, and it is used to generate ANQP requests for a request. Other announcement protocols may define protocol-specific elements with a similar general format as shown in FIG. 4. For example, changes to the 802.11af standard define some RLQP elements that are specific to RLQP.

The format of the ANQP element query sheet is shown in FIG. 6. As shown in FIG. 6, the ANQP element query sheet contains an information identifier field 610 containing a value corresponding to the ANQP element query sheet, as defined in FIG. 5, a field 620 is long indicating the length in octets of the remaining fields in the request sheet of the ANQP element and one or more fields of the ANQP request ID, such as the ANQP request ID field 630 and the ANQP request ID field 640, each of which contains ANQP ID information The item that the STA requests. The ID information contained in the query sheet of the ANQP element indicates that the STA, by sending an ANQP call to the request, wishes to receive the ANQP element corresponding to the information ID in the ANQP response to the request.

After sending a request for a request to the corresponding server of the announcement protocol, the AP can receive a response to the request from the server. An access point may use a GAS frame of the original response to transmit the response to the request to the requesting STA if the size of the response to the request is within the size limited by one GAS frame of the original response. Then, the request process may end. Otherwise, the AP fragments the size of the response to the request for several GAS response direction frames and sends a GAS frame of the original response with a non-zero value of the return delay and without taking into account any part of the response to the request for inviting the requesting STA to send GAS request return frames, to accept a plurality of GAS response return frames for retrieving all fragments of the response to the request. The STA then sends a GAS request return frame, in response receives a GAS response return frame, and repeats these steps until the GAS response return frame carrying the last fragment of the response to the request is received. Then, the STA can restore the response to the request. After that, the request process may end. The AP does not need to interpret the content of the response to the request received from the announcement protocol server. The AP simply extracts the content of the response to the request, fragments of it if its size is too large, and sends it to the requesting STA using the GAS frame of the original response or one or more GAS response return frames.

In FIG. 7 shows the body of a GAS frame of an original response frame. As shown in FIG. 7, the GAS body of the source response frame contains a category field 705 and an action field 710 that together indicate that the frame is a GAS source response frame, a dialog token field 715 containing the same value obtained from the dialogue token field corresponding to the GAS frame of the original request, a status code field 720 indicating the status of the corresponding request process, a return delay field 730 containing a return delay value, an announcement protocol element 740 having the same structure as the announcement protocol element 320, and an o length field 750 veto the request. The GAS frame body of the original response may possibly include a request response field 760. A value of zero contained in the field 750 length of the answer to the question indicates the absence of the field 760 response to the request. A non-zero value contained in the question answer length field 750 indicates the presence and length in octets of the query response field 760.

Since the features of the service and the parameters of the access network can remain unchanged for a long time, and in the meantime, the STA can visit the same access point and through the AP, the same access network or subscription service of the network provider (SSPN) day after day, this may be wasteful for the STA to re-send the ANQP request request to the same ANQP server. In the 802.11ai project, the ANQP sequence number configuration concept was developed, where the ANQP sequence number configuration, which is also known as the ANQP general group version number (CAG version number), is currently renamed IEEE 802.11 by the Ai working group as the version number of the general announcement group ( also abbreviated as CAG version number), which is associated with a group of service features of the access network and parameters that are expressed as ANQP elements. This group of ANQP elements is called the Common ANQP Group (CAG) and is currently renamed IEEE 802.11 by the Ai Working Group to the General Advertisement Group (CAG). The ANQP server and access network provider can decide which ANQP elements are within C AG and can support CAG version number. With AG, the version number is incremented each time the ANQP element (s) within the CAG changes, or any attribute value of the ANQP element (s) within the CAG changes. During a previous visit to the access point, the STA may receive the CAG (i.e., an ANQP element group) associated with the access point corresponding to the CAG version number and region value, BSSID, HESSID and / or ESSID AP, from the access point and / or from ANQP server after AR. This information may be referred to as high level information. STA can store high-level information for later use.

The CAG element number was defined in the IEEE 802.11ai project, changing D2.0 for the AP to indicate the current CAG version number for STAs. The access point can get the current CAG version number from the corresponding ANQP server. An access point may include a CAG number element in beacon frames or response frames of samples that the AP sends. The CAG number element can be used by the STA to determine whether the CAG information (higher level information), that is, the group of ANQP elements and values in these ANQP elements, which is stored by the STA for the AP during the previous visit, is still valid or not, by comparing the stored CAG version number with the CAG version number in the received CAG number element. If the two CAG version numbers are equal, then the STA can continue the NDS procedure using the stored CAG information and without initiating the ANQP request process, as a response to the request, which otherwise would be the same as the stored one. In this way, the number of ANQP requests and responses to requests can be reduced, and the number of associated CAG frames can be reduced.

In FIG. Figure 8 shows the format of the CAG element number in the IEEE project 802.11ai D2.0 change. As shown in FIG. 8, the CAG number element 800 contains an element ID field 810 containing the element identifier value corresponding to the CAG number element, a length field 820 indicating the length in octets of the remaining fields in the CAG number element, the CAG version field 830 indicates the current CAG version number and the 840 field area. The value in the CAG version field 830 can always be a positive number, so a value of zero in this area will be ignored by the receiving STA. The area field 840 contains a value indicating the actual CAG area associated with the value contained in the version CAG field 830. A value of 0 in the field field 840 indicates that the CAG is valid only within the current basic service set (BSS), which is identified by the BSSID value of the AP. A value of 1 in the field 840 indicates that the CAG operates in a uniform extended service set (ESS), which is identified by the HESSID value of the AP. And the value 2 in the field 840 of the region indicates that the CAG operates within the extended service set (ESS), which is a combination of BSSs with the same SSID AP. Values from 3 to 255 are currently reserved for area field 840.

As mentioned earlier, the inclusion of a CAG version of the beacon (in the CAG element of the number), which the access point periodically broadcasts, can help reduce the number of ANQP requests for requests and responses to requests. This approach is usually characterized as “pushing”. However, the inclusion of the CAG element of the number in the beacon frames also represents additional overhead for the signaling that the access point needs to periodically transmit. In places where STAs often use Wi-Fi, such as train stations and shopping malls, it may be useful for the AR to “push” the current CAG version number to STAs by broadcasting it in a beacon frame, given the possibility of cure benefits due to the lack of frequent need exchanges of ANQP requests, which can devalue the transmission of additional unproductive signaling in bioacon frames. However, given that most access points in the absence of high-density Wi-Fi STAs do not accept ANQP requests as often as transmitted in beacon frames in practice, these access points may decide not to include the IE CAG number in their beacon frames. Therefore, it may be better to use the pull mechanism, where it is more important for the STA to obtain information about the current CAG version number by sending a request for such information that can be returned by the responder.

In the draft 802.11ai D2.0 change, such a pull mechanism was provided. The 802.11ai D2.0 change project defined the CAG ANQP element, which is shown in FIG. 9. As shown in FIG. 9, C AG-ANQP element 900 contains identifier information field 910 containing the identifier value of the corresponding CAG ANQP element, length field 920 indicates the total length in octets of the remaining fields in CAG ANQP element 900, CAG field 930 containing the current CAG number a version associated with the CAG, and one or more IDs information fields (CAG member), such as ID information field 940 and ID information field 950 containing member identifiers of ANQP elements in the CAG. The number (CAG member) of ID information fields included in the CAG ANQP of element 900 can be inferred from the value contained in length field 920, such as CAG version field 930 and the length of each (CAG member) ID information field (such as field 940 information ID and field 950 information ID) is fixed. This CAG ANQP element can be extended (the requested value) using the STA using the ANQP request sheet of the element in the ANQP request call, which is encapsulated in the GAS frame of the original request. An alternative pull mechanism involves sending a sample request frame through an STA, requesting the CAG number of the IE to be returned, and then awaiting a sample response. The difference between the two alternative approaches is that the sample request was processed using an access point that can provide the current CAG version number, but not the CAG content in response, while the ANQP request is ultimately processed by ANQP a server that can optionally provide CAG content, as well as additional ANQP elements that can be located outside the CAG. In either of these two pull mechanisms, there may be an additional delay for the NDS decision due to waiting for a response.

STAs vendors tend to focus on optimizing STA designs to improve user experience, rather than increasing network bandwidth. Very often, in practice, this means that reducing network discovery and selection (NDS) delay has a higher priority than reducing the signaling overhead for the STA. If the access points do not transmit the CAG IE number in beacon frames, thus, the STAs implementation can ensure that there is no delay in transmitting the sample or request, ignoring the CAG information that may be stored together, initiating an ANQP request to receive the updated CAG information from the server directly .

FIG. 10 illustrates a messaging circuit 1000 with a focus on an example of a messaging during a network discovery process performed between an STA, an access point and an ANQP server in which the AP will not include the CAG IE number in the beacon, which is broadcast periodically. As shown in FIG. 10, the messaging circuit 1000 illustrates an example of a messaging process between the STA 1005, the AP 1010 and the ANQP server 1015, as well as the operations performed by the STA 1005, the AP 1010 and / or the ANQP server 1015. The messaging process circuit 1000 may begin STA 1005 CAG and associated CAG version numbers from ANQP server 1015 during a visit to AP 1010 (shown as event 1020). STA 1005 can store CAG information (i.e., higher level information), CAG version number, and AP information for later use. Then, at a later time, the STA 1005 reconnects to the AP 1010 and receives a beacon frame from the AP 1010 (shown as event 1025).

Due to the presence of the transfer of redundant overhead information, as discussed earlier, AP 1010 does not include the CAG number IE in the beacon frame. From the BSSID, which is usually the MAC address of the access point included in the beacon frame, the STA 1005 can obtain information about the stored CAG information associated with the AP 1010. However, as the AP 1010 does not include the CAG IE number in the beacon frame and the STA 1005 does not gets information about the validity of the stored CAG information associated with the access point. To avoid delay in transmitting the sample and the request, the STA 1005 prefers to ignore the stored CAG information and sends the CAG frame of the original request to encapsulate the ANQP request request (shown as event 1030). After receiving the GAS frame of the original request, the AP 1010 obtains the announcement protocol ID in the announcement protocol element (e.g., announcement protocol element 320) and the request call contained in the request request field (e.g., request request field 360) and from the announcement protocol ID The AP 1010 selects the ANQP server 1015 and forwards the request request to, as well as the protocol frame and delivery vehicle that should be used to send the request request between the AP 1010 and the ANQP server 1015 (shown as event 1035), based on an earlier connection Ia established between the AP 1010 and ANQP server 1015. Diameter and RADIUS are some examples of protocols that are commonly used between the access point and a server.

Then, the AP 1010 forwards the ANQP request request to the ANQP server 1015 using the selected protocol frame and delivery vehicle (shown as event 1040). After receiving the protocol frame from the AP 1010, the ANQP server 1015 retrieves the ANQP request request and generates an ANQP response to the request accordingly (shown as event 1045). Then, the ANQP server 1015 sends an ANQP response to the request to the AP 1010 using a different protocol frame (shown as event 1050). After receiving the response protocol frame from the ANQP server 1015AP 1010 retrieves the ANQP response to the request and sends it to the STA 1005 using the CAG of the original response frame by encapsulating the ANQP of the response to the request in the request response field (for example, request response field 760) in the GAS frame original response (shown as event 1055).

As shown in FIG. 10, STA 1005 seeks the shortest path to ensure that it has access network information in order to decide which network to choose. Since the AP 1010 does not include the CAG IE number in the beacon frame, the STA 1005 decides not to use the stored CAG information, since the “pull” operation of the current CAG version number will, first of all, cause additional delay. In practice, a large number of STAs can successfully use the same strategy, so using a CAG tag, as defined in the 802.11ai D2.0 change project, will be less useful than it could be.

To address this drawback, as described above, an improved signaling mechanism is proposed in the exemplary embodiments presented herein. According to an exemplary embodiment, the STA provides the CAG AP with the version number associated with the access point that the STA stored during the initiation of the CAG request, which means that the STA provides the stored CAG version number in the GAS frame of the original request. Then, the AP compares the STA stored CAG version number with the last CAG version number that the AP received from the ANQP server. If the two CAG version numbers are the same, then the AP closes the request process by returning the GAS frame of the original response bearing an indication to the requesting STA, where the stored CAG version number (and thus the CAG information associated with it is stored) remains the same as and the current one, so that the requesting STA can use the stored CAG information to decide on the network selection, and that the ANQP request process is thus terminated. If the two CAG version numbers are different, then the AP sends the request request to the ANQP server, as usual, and the rest of the process steps are performed as in the usual ANQP request process.

The disadvantage of the STA structure for transmitting the saved CAG version number in the GAS frame of the original request is that it should not be transmitted in the encapsulated ANQP element in the request call field, since there is no need for access points to read the content in the request call. Similarly, another design task for transmitting an indication that the stored CAG version number is the same as the current one in the GAS frame of the original response, that the indication should not be transmitted in the ANQP element encapsulated in the request response field. Although in an exemplary embodiment, the access point can generate a false ANQP element and include it in the request response field to indicate that the stored CAG version number is the same as the current one, which would change the traditional structure of the layering protocol and add additional functional requirements to the AR. In addition, for ad protocols, where requests for requests and responses to requests can be protected through end-to-end encryption between the requesting STA and the server, the AP present in the middle of the path may not be able to fake the response to the request. Therefore, this option cannot be practical. On the other hand, the fields carried in the GAS frame of the original request, except the request call field, and the fields carried in the GAS frame of the original response, except the request response field, are fixed to provide backward compatibility function, which means adding a new field, which can not be one option.

According to an exemplary embodiment, the required additional signaling is provided by reusing existing fields in the GAS frames of the original request and GAS frames of the original response to provide backward compatibility.

In an exemplary embodiment, the request response information field in the announcement protocol element may be used to provide the stored CAG of the STA version number when the announcement protocol element is included in the GAS frame of the original request. FIG. 11 illustrates the format of an example announcement protocol element 1100 when the announcement protocol element is included in the GAS of the original request frame. The announcement protocol element 1100 is improved and modified in comparison with the announcement protocol element 320, for example. As shown in FIG. 11, the enhanced announcement protocol element 1100 includes an IE ID field 1110 that contains the same element identifier value as the quality of the announcement protocol element that is currently being used (e.g., announcement protocol element 320), a length field 1120 indicating the full length , in the octets of the remaining fields in the element, the CAG field 1130 of the request response version information and the announcement protocol ID field 1140. The definition and meaning of the announcement protocol ID field 1140 are the same as the currently used announcement protocol ID fields (for example, announcement protocol ID field 331). If, contained in the GAS frame of the initial request, the CAG field 1130 of the request response information version contains the stored CAG of the STA version number, if the STA stores the CAG (i.e., higher level information) and the associated CAG version number corresponding to the access point and the declaration protocol used; otherwise, it is set to zero if the STA does not have a stored CAG or an associated CAG version number corresponding to the access point or the advertisement protocol used. This is consistent with the draft 802.11ai D2.0 change, where a null value is not a valid CAG version number. It should be noted that the CAG version number is also associated with the announcement protocol used. Thus, the CAG version number contained in the CAG field 1130 of the request response information version is associated with the announcement protocol indicated by the value contained in the announcement protocol ID field 1140. If the sample field contained in the bicon, the GAS source request, or the GAS response return frame, the CAG field 1130 of the request response information version contains the request response information field, which consists of a 7-bit subfield of the length of the response to the request (for example, a subfield 327 of the restriction request response lengths) and a 1-bit PAME-BI subfield (for example, as the PAME-BI subfield 329).

In an alternative exemplary embodiment of the invention, in contrast to changing an existing request response information field (e.g., request response information field 325) requesting an STA, may include a CAG number IE in the GAS frame of the original request to indicate a stored CAG number access point version. However, this IE CAG number must be inserted into the GAS frame of the original request after the request field (e.g., request field 360) to maintain backward compatibility, and should not be considered as part of the request field (this means that the value in the request call length field is not considered to be the CAG number of IE, as part of the request call field), since the access point does not need to interpret the contents of the request call field.

In another exemplary embodiment of the invention, the new status code value contained in the status code field (eg, status code field 720) in the GAS frame of the original response is used to indicate to the requesting STA that the current CAG version number remains unchanged as the stored CAG version number of the STA . This new status code value also serves as an indication to the requesting STA that the stored CAG information remains valid for a decision, such as a decision to select a network, and the request process that initiated the STA is thus terminated.

FIG. 12 illustrates a messaging circuit 1200 with a focus on an example of messaging during the network discovery process, service discovery or information discovery process among the STAs, an access point and a server in which the STAs and APs support an advanced signaling mechanism, as described herein. As shown in FIG. 12, the messaging circuit 1200 illustrates an example of a messaging process performed between the STA 1205, the AP 1210 and the server 1215, as well as the operations performed by the STA 1205, the AP 1210, and / or the server 1215. The announcement protocol used between the STA 1205 and the server 1215 may be ANQP or another declaration protocol, such as RLQP or pre-association detection protocol (PADP), which remains to be determined using the 802.11aq project or any other declaration protocol that can use GAS frames or any public frames as a means Layer 2 delivery. Thus, server 1215 can be an ANQP server, an RLQP server, a PADP proxy or server and the like, or a server that supports many of these protocols.

The messaging process flowchart 1200 may begin when the STA 1205 receives the CAG information (i.e., higher level information) and the associated CAG version number from the server 1215 while using the AP 1210 (shown as event 1220). STA 1205 may store CAG information, CAG version number, area value and AP / server information (such as access point identifier, advertisement protocol used by the server, etc.) for later use. Meanwhile, the AP 1210 can receive an update of the latest CAG version number from the server 1215 periodically or when the CAG of the version number changes (shown as event 1225). Then, at a later time, the STA 1205 may again contact the AP 1210 and receive a beacon frame from the AP 1210 (shown as event 1230). Due to the presence of redundant signaling information, as discussed earlier, the AP 1210 may not include the IE CAG number in the beacon frame. From the BSSID included in the beacon frame, the STA 1205 can recognize that it stores CAG information and the associated CAG version number associated with the AP 1210. The STA 1205 can send a GAS frame of the original request to the AP 1210 (shown as event 1235). The GAS frame of the original request may include the saved CAG version number, which is associated with the AP 1210 and associated with the used announcement protocol (as indicated by the value contained in the announcement protocol ID field 1130, for example), in the CAG field of the response information version of the request ( such as the CAG field 1130 of the request response information version, for example). The GAS frame of the original request can additionally encapsulate the request request, which STA 1205 will typically send to the request request field (for example, request request field 360, for example).

After receiving the GAS frame of the initial request from STA 1205, the AP 1210 can compare the stored CAG version number of the STA with the last CAG version number (associated with the same announcement protocol, as indicated by the value contained in the announcement protocol ID field 1130 in the received GAS frame of the initial request) which AP 1210 is received from server 1215, event 1225 (for example, shown as event 1240). If the AP 1210 determines that the two CAG version numbers are equal, then the AP 1210 may send a GAS frame of the initial response to the STA 1205, the GAS frame of the initial response may include, in the status code field (e.g., status code field 720), the status code value, which indicates that the saved CAG version number matches the current CAG version number that the AP has, that the stored CAG remains valid for making a decision (for example, a decision on choosing a network, choosing a service, a decision on choosing a peer device, etc. .), as well as that the request is initiated by The requesting STA thus ends (shown as event 1245). The GAS frame of the original response that the AP 1210 sends at event 1245 does not include a request response field. A zero value contained in the query response length field (for example, the query response length field 750) indicates that the query response field is not contained in the GAS frame of the original response. After receiving the GAS frame of the original response, STA 1205 may complete the request process. STA 1205 may continue the decision operation, or may initiate request processes for other access points and / or other servers before deciding how to complete the network selection process.

If the AP 1210 determines that the two CAG version numbers are not equal at step 1240, then the AP 1210 may receive a request call contained in a request call field (for example, a request call field 360) in the GAS frame of the original request. Based on the announcement protocol ID contained in the announcement protocol ID field 1130, the AP 1210 selects the server 1215 to direct the request to the request, as well as the protocol frame and delivery vehicle that should be used to complete the request between the AP 1210 and the server 1215. Then, The AP 1210 may direct the request to the server 1215 using the selected protocol frame and delivery vehicle (as event 1250). After receiving the protocol frame from the AP 1210, the server 1215 extracts the request request from the protocol frame and generates a response to the request accordingly (shown as event 1255). Then, server 1215 sends a response to the request to AP 1210 using a different protocol frame (shown as event 1260).

After receiving the protocol response frame from server 1215, the AP 1210 can receive a response to the request and sends it to STA 1205 using the GAS frame of the initial response, if the response to the request does not exceed the size, then by encapsulating the response to the request in the request response field ( for example, request response field 760) in the GAS frame of the original response (shown as event 1265). Then, the request process may end. If the response to the request exceeds the size, then the AP 1210 fragmentes the response to the request for several GAS response return frames and sends a GAS frame of the initial response to invite the requesting STA to request the reception of multiple GAS response return frames to obtain the entire answer to the question. STA 1205 sends a GAS request return frame, receives a GAS response return frame in response, and repeats these steps until a GAS response return frame carrying the last fragment of the response to the request is received. Then, STA 1205 may reassemble the response to the request. After that, the request process may end.

As shown in FIG. 12, STA 1205 provides the stored CAG version number, because if the stored CAG STA version number is the same as the current one, then the AP 1210 can speed up the query process (shown as event 1245), so that the STA 1205 can make a decision in advance ( e.g. network choice) to provide an improved user experience mechanism. Even if the saved STA version number of the STA is different from the current one, the AP 1210 still correctly sends the request to the server 1215. The STA 1205 does not lose time when receiving an updated response to the request from the server 1215. Therefore, using the advanced signal transmission mechanism, as shown in the exemplary embodiment presented herein, many STAs will be interested in using the CAG information that is stored.

It should be noted that the GAS frame of the original response transmitted at 1245 does not include a request response field. Compared to using sample request and sample response frames to obtain the current CAG version number, as described above, this is a fairly effective alternative, in the sense of no unnecessary signaling, to use the GAS frame of the original request to deliver the stored CAG version number and to receive the GAS frame of the original A response indicating if the saved CAG version number is the same as the current or not. However, some changes must be made with respect to the GAS frame of the original request. Currently, as defined in the IEEE 802.11-2012 standard and the 802.11ai D2.0 measurement project, the GAS frame of the original request must contain the request field, and the request for the announcement protocol request is encapsulated. Thus, a null value in the request call length field in the GAS frame of the original request is currently not allowed.

In accordance with an alternative exemplary embodiment of an improved signaling mechanism, a GAS frame of an initial request without a request field and a GAS frame of an initial response without a response field are used as an alternative to using sample request and sample response frames to obtain the CAG of the version number through the pull process ". Strictly speaking, this option is not a pull operation mechanism because the requesting STA does not receive the current CAG version number. Instead, it simply receives an indication if the stored CAG version number is the same as the current one, or the stored CAG version number is not delivered via STA to the access point using the GAS frame of the original request, and the access point provides an indication in response.

FIG. 13 illustrates a messaging circuit 1300, focusing on an alternative example of message exchange during network discovery, service discovery, or information discovery process among STAs, APs and a server in which the STAs and APs support an advanced signaling mechanism, and the STAs are also optimized to increase throughput networks, effectively using redundant alarms. As shown in FIG. 13, the messaging circuit 1300 illustrates an example of a messaging process among the STA 1305, the AP 1310 and the server 1315, as well as the operations performed by the STA 1305, the AP 1310 and / or the server 1315. The messaging circuit 1300 may begin upon receipt of the CAG STA 1305 and the associated CAG version number from server 1315 while visiting AP 1310 (shown as event 1320). STA 1305 can store CAG information, CAG version number, area value and AP / server information for later use. Meanwhile, the AP 1310 may receive an update of the latest CAG version number from the server 1315 periodically or when the CAG of the version number changes (shown as event 1325).

Then at a later time, STA 1305 may re-establish communication with the AP 1310 and receive a beacon frame from the AP 1310 (shown as event 1330). Due to the need to consider excessive signaling, as discussed earlier, the AP 1310 may not include the IE CAG number in the beacon frame. From the BSSID included in the beacon frame, the STA 1305 can recognize that it stores C AG information and the corresponding CAG version number associated with the AP 1310. Then, the STA 1305 can send the GAS frame of the original request to the AP 1310, including the stored CAG number the version that is associated with the access point and associated with the advertisement protocol used (as indicated by the value contained in the announcement protocol ID field 1130), in the CAG field of the request response information version (for example, CAG field 1130 of the response information of the request) and without appeal field for request (shown as event 1335). A zero value contained in the request call length field (for example, request call length field 340) indicates that the request call field is absent and the GAS frame of the original request is sent to indicate whether the stored CAG is the STA version number the same as the current CAG version number, which has an AP 1310.

After receiving the GAS source frame from STA 1305, the AP 1310 can compare the stored CAG of the STA version number with the latest CAG version number (of the same announcement protocol as indicated by the value contained in the announcement protocol ID field 1130 in the received GAS source request frame) that the AP 1310 received from the server 1315 at step 1325, for example (shown as event 1340). Then, in accordance with the comparison result, the AP 1310 sends the GAS the original response frame to the STA 1305 (shown as event 1345). If the AP 1310 determines that the two CAG version numbers are equal, then the AP 1310 may include in the status code field (for example, the status code field 720, for example), the first status code value that indicates that the stored CAG version number is the same as the current CAG is the version number that AP has. If the AP 1310 determines that the two CAG version numbers are not equal, then the AP 1310 includes in the status code field (for example, status code field 720) a second status code value that indicates that the stored CAG version number is different from the current CAG version number, which AR has.

After receiving the GAS source response frame from the AP 1310, if the first status code value is contained in the status code field, STA 1305 may terminate the request process. STA 1205 may continue to make a decision or may initiate request processes for other access points and / or other servers before deciding how to proceed with the network selection process. If the second status code value is contained in the status code field, STA 1305 knows that the stored CAG information is outdated. Thus, STA 1305 can initiate a normal request process to obtain updated CAG information (shown as event 1350). And the remaining events of the normal request process are executed, such as events 1355, 1360, 1365, 1370 and 1375. As shown in FIG. 13, STA 1305, compared to STA 1205, as shown in FIG. 12 may save some redundant signaling (due to the exclusion of request access from the GAS of the original request frame) at step 1335 if the two CAG version numbers are the same, but there is a risk of a long delay (than STA 1205) if two CAG version numbers are different.

Currently, in the IEEE 802.11-2012 standard and in the 802.11ai project, the D2.0 change, when the announcement protocol element is contained in the GAS source frame of the request, the response field of the request information is set to zero and the AP, taking this field of response information to the request should ignore him. Thus, the legacy AP (for example, capable of using GAS frames, but not able to use CAG features or advanced signaling), receiving the GAS source request frame in step 1235, directs the request to the server based on the inherited 802.11u rules. Although the CAG stored version number that the STA has can be used inefficiently, the 802.11u request process remains unchanged. In fact, if the requesting STA has information that the AP is a legacy AR, for example, from information about the capabilities indicated in the beacon or sample response, the STA may not send its stored CAG version number to the GAS of the original request frame by setting the CAG field version information of the response to the request for zero. This is consistent with the draft 802.11ai D2.0 change when a null value is not valid for the CAG version number. Instead, a null value in the CAG field of the request response information version in the GAS of the original request can be used by the STA, which supports the advanced signaling mechanism, to indicate (and can be interpreted by an access point that supports the advanced signaling mechanism) that The STA does not have a CAG stored version number for the AP and an associated announcement protocol. Since the inherited STA (for example, capable of using GAS frames but cannot use CAG features or advanced signaling) by sending the original request frame to the GAS will set the request response information field to zero, the access point that supports the advanced signaling mechanism will process its as if the STA does not have a stored CAG version number for the AP and its associated announcement protocol. Thus, the access point will not shorten the execution process of the request process. Therefore, in general, the exemplary embodiments presented here do not have backward compatibility with legacy access points or legacy STAs. A communication system in accordance with these exemplary embodiments may coexist with legacy access points and legacy STAs.

In FIG. 14a is a flowchart of the first example operations 1400 performed by the STAs in a network discovery, service discovery, or information discovery process. Operations 1400 may indicate operations performed by the STA when the STA performs network discovery, service discovery, or information discovery process. Operations 1400 may correspond to a messaging circuit 1200.

Operations 1400 may begin from the moment the STA receives the first high-level information and the CAG number from the server (step 1405). The first higher-level information and the CAG number may be associated with a network, service, database, and the like. The STA may disconnect from the network (block 1407). At a later time, the STA can reconnect to the network, which it can identify in accordance with the BSSID included in the beacon frame transmitted by the access point, for example (step 1409). The STA may send a GAS frame to the original request including the stored CAG version number (block 1411). The STA may receive a GAS frame of the original response with an indicator that indicates if the stored CAG version number matches the current CAG version number (step 1413). The indicator may be located in the GAS status code field of the source response frame. If the stored CAG version number matches the current CAG version number, the GAS frame of the original response does not include high level information. If the stored CAG version number does not match the current CAG version number, then the GAS frame of the original response received by the STA may include high-level information and the current CAG number in the request response field. The STA may continue the network selection process (block 1415).

In FIG. 14b shows a flowchart of operations 1450 of the second example performed by the STA during network discovery, service discovery, or information discovery process. Operations 1450 may indicate operations occurring in the STA when the STA performs network discovery, service discovery, or information discovery process. Operations 1450 may correspond to a messaging circuit 1300.

Operations 1450 may start from the moment the STA receives the first high-level information and the CAG number from the server (step 1455). The first high-level information and the CAG number may be associated with a network, service, database, and the like. The STA may disconnect from the network (block 1457). At a later time, the STA may again refer to the network, which it can identify in accordance with the BSSID included in the beacon frame transmitted by the access point, for example (step 1459). The STA may send a GAS frame of the original request, including the stored CAG version number (step 1461). The STA may receive a GAS frame of the original response with a pointer that indicates whether the stored CAG version number matches the current CAG version number (step 1463). The pointer may be located in the GAS status code field of the source response frame. If the saved CAG version number corresponds to the current CAG version number, then the first pointer value is included in the GAS frame of the initial response, for example, contained in the status code field; otherwise, the second pointer value is contained in the GAS frame of the original response, for example, contained in the status code field.

The STA may perform a check according to the pointer (for example, the value contained in the status code field) in the received response frame of the GAS to determine if the first value of the pointer is received (step 1465). If the first pointer value is received (for example, in the status code field), which indicates that the stored CAG version number matches the current CAG version number, then the STA can continue the network selection process (step 1469). If the first pointer value is not accepted, indicating that the stored CAG version number does not match the current CAG version number, then the STA can receive and store updated high-level information (updated CAG information) and the current CAG version number from the AP (step 1467) . As an illustrative example, the STA may perform a standard query operation to obtain updated higher-level information (updated CAG information) and the current CAG version number from the AP. The STA may continue the network selection process (block 1469).

In FIG. 15a shows a flow chart of operations 1500 of the first example that are executed at an access point when a network is detected, a service is detected, or an information is detected. Operations 1500 may indicate operations occurring at the access point when the AP is involved in a network discovery process, service discovery, or information discovery process. Operations 1500 may correspond to a 1200 messaging circuit.

Operations 1500 may begin from the moment of receiving, by the GAS AP, a frame of the initial request including the stored CAG version number stored in the STA (step 1505). The access point may perform a check to determine whether the stored CAG of the GAS version number of the source request frame matches the current CAG version number that is associated with the same announcement protocol (step 1507). If the two CAG version numbers match, then the access point can send a GAS frame of the original response with an indicator indicating that the two CAG version numbers match (step 1509). If the two CAG version numbers do not match, then the access point can accept the request request from the GAS frame of the original request and send the request to the request to the server, requesting a response (step 1511). The access point may receive a response from the server (block 1513). The response from the server may include a request response for the requesting STA. The content of the response to the request may include an updated CAG version number and higher level information that may be transparent to the AP. The access point may receive a request response from a response received from the server and send a GAS frame of the original response with the response to the request (block 1515).

In FIG. 15b shows a flowchart of operations 1550 of a second example performed by an access point during network discovery, service discovery, or information discovery process. Operations 1550 may indicate operations occurring at the access point when the AP is involved in a network discovery process, service discovery, or information discovery process. Operations 1550 may correspond to a messaging circuit 1300.

Operation 1550 may begin from the moment the AP receives the first GAS frame of the original request, including the CAG stored version number stored in the STA (step 1555). The first GAS frame of the original request may not include a request call, for example, the request call length field contains a null value, and the request call field is invalid. The access point may perform a check to determine if the stored CAG of the GAS version number of the source request frame matches the current CAG version number associated with the same announcement protocol (block 1557). If the two CAG version numbers match, then the access point can send the first GAS frame of the original response with a pointer indicating that the two CAG version numbers match (step 1559).

If the two CAG version numbers do not match, then the access point may send the first GAS frame of the original response with an indicator indicating that the two CAG version numbers do not match (block 1561). The access point may receive a second GAS frame of the original request, including request access (block 1563). The content of the request request, which may be transparent to the AP, may include a request for an updated CAG version number and higher level information (CAG information). The access point may receive a request request from the second GAS frame of the original request and direct the request to the server for a response (block 1565). The access point may receive a response from the server (block 1567). The response from the server may include a request response for the requesting STA. The content of the response to the request, which may be transparent to the AP, may include an updated CAG version number and higher level information (CAG information). The access point may receive a request response from a response received from the server and send a second GAS frame of the original response with the response to the request (step 1569).

As noted earlier, the CAG number is also associated with the advertisement protocol used. Therefore, when the AP reports the current CAG version number using the CAG number of IE included in the beacon frame or sample response, the access point should also indicate the announcement protocol associated with this CAG version number. In FIG. 16 shows an example CAG of the IE 1600, by using the announcement protocol identifier associated with the CAG version number. As shown in FIG. 16, the CAG number IE 1600 includes an IE ID field 1610 containing an element identifier value corresponding to the CAG element number, a length field 1620 indicating the total length in octets of the remaining fields in the element, one or more tuple CAG fields, such as a 1630 CAG field tuple, tuple field 1650 CAG and tuple field 1660 CAG. Each tuple CAG field (for example, a tuple 166 CAG field) includes a 1-octet CAG version subfield (for example, a 1635 CAG version subfield), a 1-octet region subfield (such as a region 1640 subfield), and a 1-octet protocol ID subfield announcements (e.g., subfield 1645 announcement protocol ID). The number of fields of the CAG tuple contained in the CAG number of the element 1600 can be obtained from the value contained in the length field 1620.

In FIG. 17 shows an example of an alternative embodiment of the CAG of the IE number 1700. As shown in FIG. 17, the CAG of the IE number 1700 includes IE ID 1710 containing the element identifier value corresponding to the CAG element number, a length field 1720 indicating the total length, in octets, of the remaining fields in the element, one or more fields of the GAG tuple, such as a field 1730 CAG tuple, field 1750 CAG tuple and field 1760 CAG tuple. Each tuple CAG field (for example, a tuple CAG field 1730) contains a 1-octet version CAG subfield (such as a CAG version 1735 subfield), a 3-bit region subfield (for example, a region 1740 subfield) and a 5-bit partial declaration protocol ID subfield (e.g., subfield 1745 of the partial announcement protocol). The number of tuple CAG fields contained in the CAG number IE 1700 can be inferred from the value contained in the length field 1720. The CAG number IE 1700 differs from the CAG number IE 1600 in that the 1-octet subfield of the announcement protocol ID (e.g., subfield 1645 of the ID of the announcement) is replaced with the 5-bit subfield 1745 ID of the partial protocol of the announcement, the 1-octet subfield of the region (e.g. the subfield 1640 regions) is replaced with a 3-bit subfield of the 1740 region, and these two subfields are combined into one 1-octet. Thus, each CAG field of a tuple in a CAG number of IE 1700 has a 2-octet length, instead of a 3-octet length, as in a CAG number of IE 1600. The 5-bit partial announcement protocol ID may be the first 5 bits (i.e., the 5 least significant bit) 1-octet announcement protocol ID, as currently defined, which means that only 32 1-octet announcement protocol Ids can be allocated in total to avoid possible duplication of their partial declaration protocol ids. As an illustrative example, if the CAG version number contained in the CAG version subfield (e.g., the CAG version 1735 subfield) is associated with ANQP, then the partial declaration protocol ID subfield within the same tuple CAG field (e.g., the 1745 partial declaration protocol ID subfield ) contains the value 0 (or 00000 if expressed in binary), since the ID of the entire declaration protocol for ANQP is 0 (or 00000000 if expressed in binary).

Table 1 below provides a series of examples of announcement protocols with their associated full announcement protocol ID values and partial announcement protocol ID values, where all are expressed in decimal notation, applicable to the example formats shown in FIG. 16 and FIG. 17 respectively.

The number of region values that can be determined using a 3-bit region subfield (such as a region subfield 1740) also decreases to 8, compared to 256 by a 1-octet region subfield (e.g., region subfield 1640). Since the number of region values of a 3-bit region subfield is significantly reduced, one possible solution is to re-interpret the value of each region value contained in the 3-bit region subfield based on the corresponding ID value of the partial declaration protocol contained in the same CAG field tuple. As an illustrative example, if the value of the partial announcement protocol ID indicates that the associated announcement protocol is ANQP, then a value of 0 in the 3-bit subfield of the area may indicate that the CAG number is a specific BSS, and a value of “1” may indicate that The CAG number is common in the same HESSID, the value “2” may indicate that the CAG number is common within the same extended service area (ESS) area, values from 3 to 7 may be reserved for the area subfield for ANQP; at the same time, if the ID value of the partial announcement protocol indicates that the associated announcement protocol is RLPQ (for TV technology of the unused frequency spectrum), then the value 0, 1, 2, 3, 4 or 5 in the 3-bit subfield of the region may indicate that the CAG number associated with the TV database of the technology of the unused frequency spectrum or channel accessibility map is common throughout the country, throughout the region, within the region, in the city, in the ESS scale or in the BSS, respectively, and the values 6 and 7 should be reserved for subfield about areas for RLQP.

In FIG. 18 is a flowchart of operations 1800 performed by a communication device by transmitting a frame including a CAG IE number. Operations 1800 may relate to operations performed by a communication device, such as an STA and / or access point, since the communication device transmits a frame including the CAG number of the IE.

Operations 1800 may begin from the moment of generation, by the communication device, of a frame including the CAG number of IE, in accordance with FIG. 16 or FIG. 17 (step 1805). The frame may be a beacon frame, a sample response frame, a GAS frame of the original request, a short beacon frame, an exported frame, and the like. The CAG number of the IE may include one or more CAG tuples, each of the CAG tuples includes a CAG version field, an area field (which may have either a 3-bit length or 8 bits) and an announcement protocol ID field (which may have either 5 -bit length or 8 bit length). The communication device may send a frame (block 1810).

It should be noted that the GAS frame of the original request and the GAS source response frame are used only as an example to describe exemplary embodiments. Other exported frames are also possible, such as a service discovery request frame and a service discovery response frame defined in the WFA Wi-Fi Direct specification, or any new exported frames that provide similar services as level 2 delivery of request data higher level and request response data.

The described exemplary embodiments can be applied not only to improve the current 802.11ai CAG tag, as defined in the draft 802.11ai change D2.0, which is defined only for ANQP, but also to improve other existing announcement protocols, such as RLQP, as defined in 802.11af changes for unused frequency spectrum television technology, medium independent transfer service (MIH) information service, medium independent transmission service (MIH) commands and technical discovery service events capabilities, emergency alert systems (EAS), access network discovery and selection function (ANDSF), as well as those that can still be determined by announcement protocols such as PADP, which is currently under review under the 802.11aq project to detect preliminary association. Thus, the server may be a server with support for one or more of ANQP, MIH, RLQP, PADP, ANDSF, and the like. A CAG can be defined as any group of higher-level information associated with a higher-level protocol that uses layer 2 frames as a vehicle between the STA and the AP that the server connects to. For example, higher-level information may be associated with overhead information, protocol information, configuration information, a TV card of an unused frequency spectrum, or a channel availability information database. The methods can be used for any detection process. For example, the discovery process may be a network discovery process in which the network can be an access network, a service provider's network (SSPN) and / or a cellular network, a process for detecting a service, detecting information, or detecting an available TV channel of an unused frequency spectrum. The decision will be made after the discovery process is completed and can be any decision, for example, a decision to select a network, a decision to select services, a decision to choose a peer device, a decision to use an available TV channel of an unused frequency spectrum for communication, etc. CAG version number can also be called as the number of configuration changes, serial number of the configuration, installation configuration number, index number of the TV card of the unused frequency spectrum, etc.

In general, a station (or device, user device, terminal, mobile device, etc.) can communicate with a server through an access point (or base station, controller, Nobe B, advanced Node B, etc.) for the purpose obtaining higher level information associated with the server using a level 2 delivery device between the station and the access point and between the access point and the server. The index number (or version number, change counter, configuration sequence number, etc.) may be associated with higher level information. The index number and higher level information can be sent to the station from the server, for example, during a previous communication session, and can be stored at the station. The last index number can also be sent for the access point by the server. During a previous communication session between the access point and the station, the station can provide its stored index number to the access point. Since higher-level information can be associated with a higher-level protocol that is identified by a protocol identifier, the station can also provide a corresponding protocol identifier to the access point. An access point can compare the index number provided by the station and the index number provided by the server. An access point can use the identifier of the protocol broadcast by the station to select a server whose index number is compared with the index number broadcast by the station. If these two index numbers are the same, then the access point may indicate that the station can thus use the stored information of a higher level for the purpose of its use (for example, selecting a network, discovering a service, etc.) without additional receiving information of a higher level from the server. The station may provide a stored index number to the access point in the portion of the layer 2 frame that is visible to the access point so that higher level information or a higher level request for such higher level information can remain transparent to the access point even if the higher level information or a higher level request may be contained in a part of a layer 2 frame that is transmitted between the station and the access point.

In FIG. 19 is a block diagram of a processing system 1900 that can be used to implement the devices and methods disclosed herein. Particular devices may use all of the components shown or only a subset of the components, and integration levels may vary from one device to another. In addition, the device may contain several instances of components, for example, several processing units, processors, memory, transmitters, receivers, etc. The processing system may include a processing unit 1905 equipped with one or more input / output devices, for example, a user interface 1915 (including a speaker, microphone, mouse, touch screen, keyboard, keyboard, printer, etc.), a display 1910, and etc. The data processing unit may include a central processing unit (CPU) 1920, a memory 1925, a memory device 1930, a video adapter 1935, and an input / output interface 1940 connected to the 1945 bus.

A bus may be one or more of any type of several bus architectures, including a memory bus or memory controller, a peripheral bus, a video bus, or the like. The processor may include any type of electronic data processing unit. The memory may include any type of system memory, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic RAM (SDRAM), read only memory (ROM) combinations thereof, or the like. In one embodiment, the memory may include a ROM for use at boot and DRAM for storing data and programs for use during program execution.

The storage device may comprise any type of storage device configured to store data, programs, and other information, and provide data, programs, and other information via the bus. The storage device may comprise, for example, one or more solid state drives, a hard disk, a magnetic disk drive, an optical disk drive, or the like.

The video adapter and the I / O interface provide an interface for connecting external input and output devices to the processing unit. As shown in the drawing, examples of input and output devices include a display connected to a video adapter and a mouse / keyboard / printer connected to an input / output interface. Other devices may be connected to the processing unit and additional or fewer interface boards may be used. For example, a serial interface, such as a universal serial bus (USB) (not shown), can be used to provide an interface for the printer.

The data processing unit also includes one or more network interfaces 1950, which may include wired communication lines, for example, via an Ethernet cable or the like, and / or wireless communication channels for accessing nodes or various networks 1955. The network interface allows the processing unit to communicate with remote devices through the network. For example, a network interface may provide wireless communication using one or more transmitters / transmitting antennas and one or more receivers / receive antennas. In one embodiment, the processing unit is connected to a local area network or to a global network to process data and establish communication with remote devices, such as other processing units, the Internet, remote storage devices, and the like.

Although the present invention and its advantages have been described in detail, it should be understood that various changes, substitutions, and changes can be made herein without departing from the scope of the invention as defined in the attached claims.

Claims (54)

1. The method of operation of the station during the detection process, comprising stages in which: transmitting (1411, 1461) via stations the first level 2 frame to an access point (AP), the first level 2 frame including a first version number associated with the first high level information and a protocol identifier associated with the first high level information, so with the first version number; receive (1413, 1463) using the stations, a second layer 2 frame from the AP, including an indication that the second version number associated with the second high-level information is the same as the first version number; and make a decision with the help of the stations whether to carry out the network selection process in accordance with the first high-level information; moreover the first layer of frame 2 is the IEEE 802.11 GAS frame of the original request, and the second frame of layer 2 is the IEEE 802.11 GAS frame of the original response. 2. The method according to claim 1, further comprising, before the step of transmitting the first level 2 frame, the steps of: receive first high-level information and a first version number; and save the first high-level information and the first version number. 3. The method according to claim 1 or 2, in which the first level 2 frame further includes requesting the request for second high level information. 4. The method of claim 1 or 2, wherein the first version number is contained in a common ad group (CAG) number element in a first layer 2 frame. 5. The method according to claim 1 or 2, in which the first version number and the second number are version numbers of the general announcement group (CAG), and the first high-level information and the second high-level information are general announcement groups (CAG). 6. The method of claim 1 or 2, wherein said protocol is one of an access network request protocol (ANQP), a registered location request protocol (RLQP), a preliminary association discovery protocol (PADP), a medium independent transfer service (MIH) information service ), commands and events of the Medium Independent Handover (MIH) and Emergency Alert System (EAS) functionality discovery services. 7. The method according to claim 1 or 2, in which an indication that the first version number and the second version number are the same is contained in the status code field in the second level 2 frame. 8. The method of operation of the access point, containing stages in which: receive (1505, 1555) using the access point a first level 2 frame from the station, the first level 2 frame including a first version number associated with the first high level information and a protocol identifier associated with both the first high level information and with the first version number; receive, using the access point, a second version number associated with the second high-level information from the server; determining (1507, 1557) using the access point whether the first version number and the second version number match; and transmit (1509, 1559) using the access point a second level 2 frame to the station, when the first version number and the second version number coincide, and the second level 2 frame includes an indication that the first version number and the second version number are the same; moreover the first layer of frame 2 is the IEEE 802.11 GAS frame of the original request, and the second frame of layer 2 is the IEEE 802.11 GAS frame of the original response. 9. The method according to p. 8, further comprising stages in which: when the first version number and the second version number do not match, retrieving the request request from the first level 2 frame, send a request to the server in accordance with the protocol identifier, receive a response to the request from the server, and transmitting the third level 2 frame to the station, the third level 2 frame including a response to the request. 10. The method of claim 8, wherein the first version number and the second version number are the version number of the general announcement group (CAG), and the first high-level information and the second high-level information are CAGs. 11. The method according to claim 8 or 10, in which an indication that the first version number and the second version number are the same is contained in the status code field in the second level 2 frame. 12. The method of claim 8 or 10, wherein the first level 2 frame further includes requesting second high level information. 13. A station configured to perform a detection process, comprising: CPU; and A computer-readable storage medium storing programs for execution by a processor, the programs including instructions for: transmitting the first level 2 frame to an access point (AP), the first level 2 frame including a first version number associated with the first high level information and a protocol indicator associated with both the first high level information and the first version number, receiving a second layer 2 frame from the AP, including an indication that the second version number associated with the second high level information is the same as the first version number, and deciding whether to complete the network selection process in accordance with the first high-level information; moreover the first layer of frame 2 is the IEEE 802.11 GAS frame of the original request, and the second frame of layer 2 is the IEEE 802.11 GAS frame of the original response. 14. The station of claim 13, wherein the programs include instructions for obtaining first high level information and a first version number and storing first high level information and a first version number. 15. The method of claim 13 or 14, wherein the first level 2 frame further includes requesting second high level information. 16. The station of claim 13 or 14, wherein the first version number is contained in a general announcement group (CAG) number element in the first layer 2 frame. 17. The station of claim 13 or 14, wherein said protocol is one of an access network request protocol (ANQP), a registered location request protocol (RLQP), a preliminary association discovery protocol (PADP), a medium independent transfer service (MIH) information service ), commands and events of the Medium Independent Handover (MIH) and Emergency Alert System (EAS) functionality discovery services. 18. The station of claim 13 or 14, wherein the first version number and the second version number are the general announcement group (CAG) version number, and the first high-level information and the second high-level information are CAGs. 19. The station according to claim 13 or 14, in which an indication that the first version number and the second version number are the same is contained in the status code field in the second level 2 frame. 20. An access point configured to receive participation in the discovery process, comprising: CPU; and A computer-readable storage medium storing programs for execution by a processor, the programs including instructions for: receiving a first level 2 frame from the station, the first level 2 frame including a first version number associated with the first high level information and a protocol identifier associated with both the first high level information and the first version number, obtaining a second version number associated with the second high-level information from the server, determining whether the first version number and the second version number match, and transmitting the second level 2 frame to the station, when the first version number and the second version number coincide, and the second level 2 frame includes an indication that the first version number and the second version number are the same, the first layer of frame 2 is the IEEE 802.11 GAS frame of the original request, and the second frame of layer 2 is the IEEE 802.11 GAS frame of the original response. 21. The access point according to claim 20, in which the programs include instructions for obtaining, when the first version number and the second version number do not match, requesting a request from the first level 2 frame, sending a request to the server, in accordance with the identifier protocol, receiving a response to the request from the server and transmitting the third level 2 frame to the station, the third level 2 frame including a response to the request. 22. The access point according to claim 20, in which an indication that the first version number and the second version number are the same is contained in the status code field in the second level 2 frame. 23. The access point according to claim 20 or 22, wherein the first version number and the second version number are the version number of the general announcement group (CAG), and the first high-level information and the second high-level information are CAGs. 24. The access point according to claim 20 or 22, wherein the first level 2 frame further includes requesting second high level information. 25. The access point according to claim 20 or 22, in which the specified protocol is one of the access network request protocol (ANQP), the registered location request protocol (RLQP), the preliminary association discovery protocol (PADP), the medium independent transfer service information service ( MIH), commands and events of medium independent handover (MIH) and emergency alert system (EAS) discovery functionality.

Images