SELECTING A TRANSMITTING VAPS FOR AN MBSSID SET

Abstract

A procedure (200) comprising the following: Selecting (210) a virtual access point (VAP) from a set of VAPs (112) as a sending VAP based on initial contextual information about the set of VAPs (112) indicating the respective importance levels of a set of clients (120) connecting to the set of VAPs (112), by comparing the respective importance levels of the set of clients (120) with each other and according to a determination that an importance level of one client of the set of clients (120) is higher than that of other clients of the set of clients (120), selecting a VAP to which the client is connected as the sending VAP, wherein at least one from the set of VAPs (112) that is not the sending VAP is determined as at least one non-sending VAP; Generating (220) a beacon frame (300) for the set of VAPs (112) by inserting an identifier of the transmitting VAP into a header part of the beacon frame and inserting at least one identifier of the at least one non-transmitting VAP into a payload part of the beacon frame (300); and Transfer (230) of the beacon frame (300).

Description

background

[0001] A set of virtual access points (VAPs) can be created within a single physical access point (AP), with each VAP functioning as an individual "AP." The physical AP can use a single beacon or probe response frame to transmit information to the set of VAPs. In this case, the set of VAPs can be referred to as a Multiple Basic Service Set Identifier (MBSSID) set. According to Draft 6 of the 802.11ax specification, MBSSID support is mandatory for such APs operating at 6 GHz and optional for 2.4 GHz and 5 GHz.

[0002] US 2019 / 268892 A1 applies to systems, methods, and devices, including computer programs encoded on computer-readable media, for jointly localized Basic Service Sets (BSSs). A BSS refers to an access point (AP), a wireless channel configuration, and associated stations (STAs). In one aspect of US 2019 / 268892 A1, a wireless local area network (WLAN) can operate multiple virtual access points (VAPs) and multiple BSSs. The BSSs are considered to be in the same location if they are implemented in the same physical device (e.g., a WLAN device). Furthermore, the BSSs can be considered jointly hosted if they share the same band and wireless channel but independently signal different management frameworks.To assist STAs in becoming familiar with jointly located or jointly hosted BSSs, US 2019 / 268892A1 provides techniques for publicizing jointly located or jointly hosted BSSs.

[0003] US 2020 / 120711A1 refers to wireless communication networks consisting of a physical access point (AP) and stations organized in groups, also known as Basic Service Sets (BSS), and specifically to the transmission of data over a subchannel or resource unit (RU) that constitutes a transmission capability granted to the AP, and related equipment. Brief description

[0004] A method according to claims 1 to 7, a communication device according to claims 8 to 15 and a non-transitory, computer-readable medium according to claims 16 to 18 is disclosed. Brief description of the drawings

[0005] The following detailed descriptions, with reference to the accompanying drawings, will clarify the above and other objectives, features, and benefits of the example implementations disclosed herein. The drawings illustrate several example implementations disclosed herein in a non-exhaustive manner, including: Fig. shows a block diagram of an exemplary communication environment in which example implementations of the present disclosure can be implemented; Fig. shows a flowchart of a process in accordance with some embodiments of the present disclosure; The Fig. show an example of a beacon framework for a series of VAPs in accordance with some example implementations of the present disclosure; Fig. illustrate some scenarios for which a sending VAP is selected from the set of VAPs according to some example implementations of the present disclosure; and Fig. shows a block diagram of a communication device in accordance with some embodiments of the present disclosure. Detailed description

[0006] An MBSSID set typically contains one transmitting (TX) VAP and one or more non-transmitting (non-TX) VAPs. A beacon frame for an MBSSID set can be referred to as an "MBSSID beacon frame" or "MBSSID beacon." An MBSSID beacon is sent by the transmitting VAP of the MBSSID set, and the MBSSID beacon also contains information about the non-transmitting VAPs of the MBSSID set. When an MBSSID beacon is deployed, the BSSID of the transmitting VAP can be considered the BSSID of the MBSSID beacon.

[0007] The TX-VAP determined using conventional methods can be unsuitable in many cases, for example, because it results in an excessively large beacon frame size for the MBSSID set. If the AP is an EMA-AP (Enhanced MBSSID Advertisement), non-TX-VAPs can inherit information from the TX-VAP within the beacon frame. The beacon frame size can be reduced if most non-TX-VAPs can inherit information from the TX-VAP. However, this inheritance relationship between the TX-VAP and the non-TX-VAPs is not considered by conventional techniques. Therefore, example implementations in this disclosure involve actively selecting a sending VAP for a set of VAPs, allowing for the selection of a suitable sending VAP for different scenarios.

[0008] Fig. Figure 100 shows an example environment 100 in which example implementations of the present disclosure can be implemented. Example environment 100 can be implemented as a wireless communication network, such as a WLAN. Example environment 100 includes an AP 110 and a set of clients, including Client 120-1, Client 120-2, Client 120-3, ... and Client 120-M, where M is an integer greater than one. For the purposes of discussion, Client 120-1, Client 120-2, Client 120-3, ..., and Client 120-M can be referred to collectively as "Clients 120" or individually as "Client 120".

[0009] A client 120 can also be referred to as a user device or station (STA). Examples of a client 120 include a mobile phone, a tablet, a laptop, or similar devices. The AP 110 can be any suitable device that allows one or more clients 120 to connect to the wireless communication network in the example environment 100. The AP 110 can, for example, be an EMA-AP. An EMA-AP is a type of access point for the MBSSID set. With an EMA-AP, the TX-VAP is sent every time the beacon frame is transmitted, but the non-TX-VAP is not. The interval for announcing a non-TX-VAP is a multiple of the profile periodicity specified in the beacon frame. Thus, the interval for a non-TX-VAP can be a multiple of the interval for the TX-VAP.

[0010] As used here, an AP may include, be implemented as, or be known as a radio router, radio transmitter / receiver, switch, Wi-Fi hotspot device, Basic Service Set (BSS), Extended Service Set (ESS), Radio Base Station (RBS), or other terminology.

[0011] As in Fig. As depicted, the AP 110 can operate as a set of VAPs comprising VAP 112-1, VAP 112-2, VAP 112-3, ... and VAP 112-N, where N is an integer greater than one. VAP 112-1, VAP 112-2, VAP 112-3, ... and VAP 112-N can be referred to collectively as "VAPs 112" or individually as "VAP 112". The set of VAPs 112 can be referred to as the MBSSID set for the AP 110. The AP 110 can provide communication links for one or more clients 120 in the example environment 100 via the set of VAPs 112.

[0012] It goes without saying that the specific number of VAPs and clients in Fig. This is for illustrative purposes only and does not suggest any limitations. Example environment 100 can include any number of VAPs and clients configured to implement this disclosure.

[0013] Communication in the example environment 100 can be carried out according to wireless communication protocols such as the IEEE 802.11 standards (Institute of Electrical and Electronic Engineers), the specifications of the Wi-Fi Alliance, or other wireless communication standards. The IEEE 802.11 standards may include the IEEE 802.11ax standard (e.g., for operation at 6 GHz) or other wireless communication standards.

[0014] AP 110 sends a single beacon frame for the set of VAPs 112 to the clients 120, instead of sending multiple beacon frames for each individual VAP from the set of VAPs 112. A VAP is selected from the set of VAPs 112 as the sending VAP in accordance with implementations of this disclosure. This is described below with reference to Fig. described.

[0015] Fig. Figure 200 shows a flowchart of Method 200 in accordance with some example implementations of the present disclosure. Method 200 can be implemented at an AP with a number of VAPs according to the implementations described here. For the purpose of discussion, the description of Method 200 is referred to below. Fig. Reference is made to the above. It should be noted that, although only some blocks of Procedure 200 are shown, Procedure 200 may also include other processes described here.

[0016] At 210, AP 110 selects a VAP from a set of VAPs 112 as a sending VAP based on contextual information about the set of VAPs 112. At least one VAP from the set of VAPs 112 that is not the sending VAP is thus determined to be at least one non-sending VAP. For example, VAP 112-1 from the set of VAPs 112, as in Fig. As shown, the sending VAP is selected, and other VAPs 112, including VAP 112-2, VAP 112-3, ... and VAP 112-N, are designated as non-sending VAPs. In the implementations described here, AP 110 is able to actively assign the role of a sending VAP and the role of a non-sending VAP to the set of VAPs 112 by considering various types of contextual information about these VAPs 112. This contextual information can help AP 110 select an appropriate sending VAP for different situations. Some example implementations of such context-based selection of sending VAPs are discussed in detail below.

[0017] At 220, AP 110 generates a beacon frame for the set of VAPs 112 by inserting an identifier of the sending VAP and at least one identifier from at least one non-sending VAP into the beacon frame. A beacon frame can contain a header portion and a payload portion. Since one of the VAPs 112 was specifically selected as the sending VAP, the identifier of the sending VAP can be included in a header portion of the beacon frame. Furthermore, at least one identifier from at least one non-sending VAP can be included in a payload portion of the beacon frame.

[0018] In some example implementations, a BSSID of the selected transmitting VAP can be included in the header portion of the beacon frame, such as the Media Access Control (MAC) header. In other example implementations, instead of using a BSSID of a non-transmitting VAP as an identifier, an identifier of the non-transmitting VAP can be specified in the beacon frame as an offset to the BSSID of the transmitting VAP. For example, if the BSSID of the transmitting VAP is a MAC address, the identifier of a first non-transmitting VAP can be the BSSID of the MAC address plus one, the identifier of a second non-transmitting VAP the BSSID of the MAC address plus two, and so on. Different offsets can be specified for different non-transmitting identifiers. The offsets (e.g., one, two, etc.) can then be included in a payload portion of the beacon frame. B. into the Multiple BSSID Index element of the beacon frame according to the 802.11ax specification.The payload size for the offsets can be reduced compared to directly recording the BSSIDs of the non-transmitting VAPs. On the receiving side of the beacon frame, the identifiers of the non-transmitting VAPs can be calculated from the offsets and the BSSID of the transmitting VAP and then determined as the BSSIDs of the non-transmitting VAPs.

[0019] After generating the beacon frame, AP 110 sends the generated beacon frame to clients 120 at 230. In this way, a sending VAP of a set of VAPs is no longer determined by default, but can be dynamically selected for different cases.

[0020] In some example implementations, the context information about the VAPs 112 can include information about the set of VAPs 112 themselves and / or information about the clients 120 connected to the set of VAPs 112. The selection of the sending VAP based on different types of context information in some example implementations will be discussed later with reference to the Fig. discussed.

[0021] In some example implementations, AP 110 can select VAP 112 as the sending VAP based on contextual information that specifies the size of the beacon frame to be generated. The size of the beacon frame can vary if a different VAP 112 is selected as the sending VAP. In particular, the inheritance relationship between information elements (IEs) of the sending and non-sending VAPs in the beacon frame can cause the size of the beacon frame to vary between different VAPs. This is discussed further below with reference to the Fig. discussed in detail.

[0022] The Fig. We show an example of a Beacon Frame 300 for a set of VAPs 112 according to some example implementations of the present disclosure. The Beacon Frame 300 can be derived from an AP 110, as shown in Fig. shown, using method 200, as in Fig. described, are generated. While only some elements are shown, the beacon frame can include 300 other elements described here or elements according to the 802.11 specification.

[0023] As described above, an identifier (e.g., BSSID) of a selected sending VAP and identifiers (e.g., an offset from the BSSID of a sending VAP) of non-sending VAPs can be included in the Beacon Frame 300. Other configuration information of the sending and non-sending VAPs can be included as information elements (IEs) in the Beacon Frame 300.

[0024] There can be some overlap between the IEs of sending and non-sending VAPs. Additionally, there can be some vendor-specific IEs, such as in VAP 112-N. Vendor-specific IEs can include configuration information specified by the vendor and configuration information defined by users. According to the 802.11ax specification, the IEs of a sending VAP in a set of VAPs can be inherited by other non-sending VAPs in the same set, with the exception of vendor-specific IEs.

[0025] For example, VAP 112-1 has IEs, including IE 1, IE 4, and IE R, VAP 112-2 has IEs, including IE 1 and IE 3, and VAP 112-N has IEs, including IE 4 and IE 5. If VAP 112-2 is selected as the sending VAP, since VAP 112-1 can inherit IE 1 from VAP 112-2, a Beacon Frame 300 will be generated as shown in Fig. As shown, if VAP 112-1 is selected as the sending VAP, since VAPs 112-2 and 112-N can inherit IE 1 and IE 4 respectively from VAP 112-1, a Beacon Frame 300 is generated as shown. Fig. The beacon frame is shown. It can be seen that the size of the beacon frame is 300 in Fig. smaller than the size of the Beacon frame 300 in Fig. This is because VAP 112-1 has more common IEs than VAP 112-2 and VAP 112-N.

[0026] It is evident that by generating the Beacon Frame 300 as described above, the size of the Beacon Frame 300 becomes smaller. Therefore, a sending VAP can be selected taking into account the size of the Beacon Frame to be generated.

[0027] In some example implementations, in a case where there are overlaps between the IEs of one or more VAPs from the set of VAPs, e.g., as in Fig. It was shown that the VAP with the most identical IEs to other IEs can be selected as a sending VAP. Fig. For example, VAP 112-1 has IE 1, IE 4 and IE R, VAP 112-2 has IE 1 and IE 3, and VAP 112-N has IE 4 and IE 5. VAP 112-1 can be selected as the sending VAP because VAPs 112-2 and 112-N can inherit IE 1 and IE 4, respectively, from VAP 112-1.

[0028] In some example implementations, if there are no overlaps between IEs from one or more VAPs in the set of VAPs, a VAP with shorter IEs than the sending VAP can be selected. Since a beacon frame is periodically sent for the set of VAPs, and the IEs for the sending VAP can also be repeatedly sent within the beacon frame, selecting a VAP with a shorter IEs allows for the creation of a smaller beacon frame, thereby reducing the communication overhead of the beacon frame.

[0029] In some example implementations, if one or more VAPs in the set of VAPs have vendor-specific IEs, a VAP with vendor-specific IEs of a shorter length than other VAPs in that set, or a VAP without any vendor-specific IEs, can be selected as the sending VAP. As mentioned earlier, vendor-specific IEs of one VAP cannot be inherited by other VAPs. Therefore, for the same reason, a VAP with vendor-specific IEs of a shorter length, or without vendor-specific IEs, can be selected to ensure that each individual beacon frame is preserved within the AP.

[0030] The implementations described above are just a few examples. Other cases may exist that are not covered here, such as overlapping IEs between one or more VAPs in the set of VAPs, or one or more VAPs in the set of VAPs having vendor-specific IEs. As long as the size of the beacon frame is taken into account, the scope of this disclosure is not limited in this respect. According to these implementations, selecting a suitable VAP as the transmitting VAP can reduce the size of the beacon frame.

[0031] In some example implementations, AP 110 can alternatively or additionally select VAP 112 as the sending VAP based on contextual information indicating the respective importance levels of a set of clients 120 connecting to that set of VAPs 112. The importance levels of the set of clients 120 can be compared. If it is determined that the importance of one client in the set of clients 120 is higher than that of the other clients, a VAP 112 to which client 120 is connected can be selected as the sending VAP.

[0032] In some implementation examples, the customer priority level can be described as a customer requirement for the Service Level Agreement (SLA). In other implementations, the customer priority level can be determined based on various other factors or assigned by the users. The scope of this disclosure is not limited in this respect.

[0033] Fig. Scenario 400 (e.g., in a hospital) shows a scenario in which a sending VAP 112-1 is selected from the set of VAPs 112 based on the respective priority levels of a set of clients 120 connecting to the set of VAPs 112. Fig. It is assumed that VAP 112-1 is connected to client 120-1 of a set of clients 120. Other VAPs 112 are connected to other clients 120. Client 120-1 may be a device in a hospital with higher SLA requirements than other devices in the hospital. Therefore, VAP 112-1, to which client 120-1 is connected, can be selected as the transmitting VAP.

[0034] By selecting the VAP that connects to a client with relatively high SLA requirements as the sending VAP, it is possible to ensure the network connection for the critical client. For example, if the configuration of AP 110 needs to be changed, e.g., at the MAC layer, the change can be made to other VAPs 112 to ensure a stable connection between client 120-1 and the sending VAP 112-1.

[0035] Although a single client 120-1 is shown connecting to the selected sending VAP 112-1, this is for illustrative purposes only and does not represent a limitation. Two or more clients 120 can also be connected to VAP 112-1.

[0036] In some example implementations, AP 110 can alternatively or additionally select VAP 112 as the sending VAP based on contextual information that specifies the respective latency requirement levels of the set of clients 120 connecting to the set of VAPs 112. A client 120's latency requirement level can be determined from its respective latency requirement levels. The determined latency requirement level of client 120 can be below a latency threshold. Then, a VAP 112 to which client 120 is connected can be selected as the sending VAP. The respective latency requirement here can refer, for example, to an acceptable latency that a client needs to be answered by a VAP. Latency can be in milliseconds, seconds, etc. The latency threshold can be specified by a user or learned through machine learning.

[0037] Fig. Scenario 400 shows a scenario in which a sending VAP 112-2 is selected from the set of VAPs 112, based on context information that specifies the respective latency requirements of the set of clients 120 connecting to the set of VAPs 112. Fig. AP 110 is an EMA AP. VAP 112-2 is connected to a client 120-2 from a set of clients 120. Other VAPs 112 are connected to other clients 120. Client 120-2 may be a latency-sensitive device or a device to which VAP 112-2 is about to transmit broadcast / multicast (BC / MC) traffic. If the latency requirement of client 120-2 is determined to be below a latency threshold, VAP 112-2 is selected as the sending VAP. Other VAPs 112, including VAPs 112-1, 112-3, and 112-N, are designated as non-sending VAPs.

[0038] In this case, multiple beacons can be used to publicize the information of VAP sentence 112 by sending the beacon frame multiple times. If there are many VAPs, some non-TX VAPs might not be transmitted every time. As mentioned earlier, the transmitting VAP is sent every time the beacon frame is transmitted, but the non-TX VAP might not. The DTIM (Delivery Traffic Indication Message) interval for a non-TX VAP is a multiple of the DTIM interval for the TX VAP. For a latency-sensitive device, the data should be transmitted from a transmitting VAP to avoid excessive waiting time, as the data will be transmitted according to the DTIM interval for the transmitting VAP, not the DTIM interval for the non-TX VAP. Therefore, VAP 112-2, which is connected to a latency-sensitive client 120-2, should be selected as the TX-VAP.

[0039] BC / MC traffic must be sent during the negotiated Broadcast Target Wake Time (BTWT) service period. Sometimes BC / MC traffic is very high. Therefore, the data for client 120-2 may need to be pre-buffered in AP 110. If the data is to be transferred from a non-TX VAP, the DTIM interval for a non-TX VAP is much longer than that of a TX VAP, and by the time the non-TX VAP is due to transfer the data to client 120-2, the data in AP 110 may already be empty. Therefore, VAP 112-2 should be selected as the transmit VAP so that the data buffered in AP 110 is transferred earlier to client 120-2, which has heavy BC / MC traffic.

[0040] This allows for a quick response to a latency-sensitive client, since the speed at which a sending VAP responds to the client is much lower than that of a non-sending VAP.

[0041] Although a single Client 120-2 is shown connecting to the selected sending VAP 112-2, this is for illustrative purposes only and does not imply any limitations. Two or more Client 120s can be connected to the VAP 112-2.

[0042] In some example implementations, the AP 110 can alternatively or additionally select a VAP 112 as the sending VAP based on contextual information indicating a VAP communication request from at least one client 120, where the VAP communication request indicates that the at least one client 120 needs to be served by a sending VAP. A VAP 112 connected to such a client 120 can be selected as the sending VAP.

[0043] Fig. Scenario 400 shows a scenario where a sending VAP, 112-3, is selected from the set of VAPs 112 based on contextual information indicating a VAP communication request from clients 120-2 and 120-3. For example, clients 120-2 and 120-3 do not support EMA functionality. Such devices can detect a sending VAP but cannot communicate with non-sending VAPs. Therefore, clients 120-2 and 120-3 must be served by a sending VAP. In another example, clients 120-2 and 120-3 are legacy clients (e.g., 802.11ac clients) that do not support MBSSID functionality. If assigned to a non-transmitting VAP, they will be unable to connect to the network. In a mixed deployment serving both legacy clients and clients for 802.11ax, the VAP assigned to the legacy clients should be the TX-VAP.

[0044] In Fig. VAP 112-3 is connected to clients 120-2 and 120-3. Other VAPs 112 are connected to other clients 120. Therefore, VAP 112-3, which is connected to clients 120-2 and 120-3, is selected as the sending VAP. Other VAPs 112, including VAPs 112-1, 112-2, and 112-N, are designated as non-sending VAPs. In this way, all clients 120 can interact with the set of VAPs 112.

[0045] Although two clients, 120-2 and 120-3, are shown connecting to the selected sending VAP 112-3, this is for illustrative purposes only and does not imply any limitations. Fewer or more clients (120) may also be connected to VAP 112-3.

[0046] In some example implementations, AP 110 can select VAP 112 as the sending VAP based on contextual information indicating how often a client 120 has switched between APs (containing the set of VAPs 112) and other APs within a specific time period. If the number of switches is determined to exceed a threshold, VAP 112, to which client 120 is connected, is selected as the sending VAP. The number of switches a client 120 makes between APs can be obtained, for example, from a cloud server or an access control (AC) system. The threshold can be user-defined or learned through machine learning. The time period can be minutes, hours, days, weeks, etc.

[0047] Fig. Scenario 400 shows a scenario in which a sending VAP 112-N is selected from the set of VAPs 112, based on contextual information indicating the number of times a client 120-M switches from an AP 110 to an AP 410 within a given time period. The AP 410 includes VAP 412-1, VAP 412-2, VAP 412-3, ..., and VAP 412-N, where N is an integer greater than one. The AP 410 has the same configuration as the AP 110. The client 120-M could be a mobile device moving between the first and second floors of a building. For example, the AP 110 could be on the first floor and the AP 410 on the second floor.

[0048] A VAP 112-N in AP 110 and a VAP 412-3 in AP 410 can both have the same Service Set Identifiers (SSIDs), for example, "Building WIFI". An SSID can be thought of as the name of an AP or VAP. VAPs in the same AP can have different names, and VAPs in different APs can have the same name. When client 120-M moves between the first and second floors, it switches between APs 110 and 410. During each switch, a user of client 120-M can choose to connect to VAP 112-N, since it shares the name "Building WIFI" with VAP 412-3 in AP 410. Therefore, if it is determined that the number of times client 120-M switches from / to AP 110 to / from AP 410 within a period of time (e.g., a day) exceeds a threshold, VAP 112-N, which is connected to client 120-M, is selected as the sending VAP of the set of VAPs 112.Other VAPs 112, including VAPs 112-1, 112-2 and 112-3, are identified as non-transmitting VAPs.

[0049] In this way, a client 120-M switching back to the APs 112 can be quickly connected to the wireless communication network, since the transmitting VAP can be detected by the client 120-M earlier than the non-transmitting VAPs.

[0050] Although a single Client 120-M is shown connecting to the selected sending VAP 112-N, this is for illustrative purposes only and does not imply any limitations. Two or more Client 120 devices can be connected to the VAP 112-N.

[0051] The context information described above can be used in any combination. It goes without saying that the context information described above is only an example. A person skilled in the art can imagine using other context information to select a VAP from a set of VAPs as the sending VAP.

[0052] Several example implementations were developed in relation to the Fig. described. In some example implementations, the example implementations can be combined. For example, any combination of the example context information mentioned above can be used to select the sending VAP. In some example implementations, different types of context information can be assigned appropriate weights to weigh the impact of the context information on selecting the sending VAP. In some examples, the weights can be configured by an operator or administrator of the AP or learned automatically through machine learning.

[0053] Fig. Shows a block diagram of an example device 500 according to some embodiments of the present disclosure. The device 500 can be referred to as AP 110 in Fig. be implemented or contained therein.

[0054] The device 500 comprises at least one processor 510 and a memory 520 connected to the at least one processor 510. The memory 520 stores instructions to cause the at least one processor 510 to perform actions of a procedure according to some example implementations described here.

[0055] As in Fig. As shown, the memory stores 520 instructions 522 to select a VAP from a set of VAPs as a sending VAP, based on context information about the set of VAPs, and to determine at least one from the set of VAPs that is not the sending VAP as at least one non-sending VAP.

[0056] In some example implementations, the 522 instructions for selecting a VAP from a set of VAPs as the sending VAP include instructions for selecting a VAP from the set of VAPs as the sending VAP based on at least one of the following: first context information indicating the respective priority levels of a set of clients connecting to the set of VAPs; second context information indicating the size of the beacon frame to be generated, with the size varying according to a selection of the sending VAP; third context information indicating the respective latency request levels of the set of clients connecting to the set of VAPs; fourth context information indicating a VAP communication request from at least one client, with the VAP communication request indicating that the at least one client must be served by a sending VAP; or fifth context information indicatinghow often a client switches between access points (APs) containing the set of VAPs within a given time period.

[0057] In some example implementations, the instructions for selecting a VAP from the set of VAPs as the sending VAP based on the initial context information include instructions for comparing the respective importance levels of the set of clients with each other and for selecting a VAP to which the client is connected as the sending VAP in accordance with a determination that one client's importance level in the set of clients is higher than that of other clients in the set of clients.

[0058] In some example implementations, the instructions for selecting a VAP from the set of VAPs as the sending VAP based on the second context information include instructions for selecting a VAP from the set of VAPs as the sending VAP, such that the size of the beacon frame determined for the selected VAP is smaller than that of selecting other VAPs from the set of VAPs.

[0059] In some example implementations, the instructions for selecting a VAP from the set of VAPs as the sending VAP based on the third context information include instructions for determining, from the respective latency request levels, a latency request level of a client that is below a threshold latency level, and for selecting a VAP from the set of VAPs to which the client is connected as the sending VAP.

[0060] In some example implementations, the instructions for selecting a VAP from the set of VAPs as the sending VAP based on the fourth context information include instructions for selecting a VAP from the set of VAPs to which the at least one client is connected as the sending VAP.

[0061] In some example implementations, the instructions for selecting a VAP from the set of VAPs as the sending VAP based on the fifth context information include instructions for selecting a VAP from the set of VAPs to which the client is connected as the sending VAP in accordance with a stipulation that the number of times exceeds a threshold.

[0062] Memory 520 further stores instructions 524 for generating a beacon frame for the set of VAPs by including an identifier of the sending VAP and at least one identifier of the at least one non-sending VAP in the beacon frame. In some example implementations, the identifier of the sending VAP includes a Basic Service Set Identifier (BSSID) of the sending VAP.

[0063] In some example implementations, inserting the at least one identifier of at least one non-transmitting VAP into the payload portion of the beacon frame involves: for one non-transmitting VAP, determining at least one offset from the BSSID of the transmitting VAP; and inserting the determined at least one offset into the payload portion of the beacon frame as the at least one identifier of the non-transmitting VAP.

[0064] The present disclosure also provides at least one computer program product stored on a non-transitory, computer-readable storage medium. The computer program product contains program code or instructions that can be executed to perform the above-mentioned Fig. to carry out the described procedures.

[0065] While the above discussion used a Wi-Fi communication standard as an illustrative example, other implementations could employ a wide variety of communication standards and, more generally, wireless communication technologies. Furthermore, although some of the operations in the preceding implementations were implemented in hardware or software, in general, the operations in the preceding implementations can be implemented in a wide variety of configurations and architectures. Therefore, some or all of the operations in the preceding implementations can be performed in hardware, in software, or in both.

[0066] It should be noted that specific terms disclosed in this disclosure are proposed for the purpose of simplifying the description and facilitating a better understanding of the exemplary implementations of this disclosure, and the use of these specific terms may be changed to a different format within the technical scope or spirit of this disclosure.

[0067] Program code or instructions for carrying out the procedures of this disclosure may be written in any combination of one or more programming languages. These program codes or instructions may be fed to a processor or controller of a general-purpose computer, a specialized computer, or any other programmable data processing device, such that when executed by the processor or controller, the program codes perform the functions / operations specified in the flowcharts and / or block diagrams. The program code or instructions may be executed entirely on one machine, partially on the machine, as a standalone software package, partially on the machine and partially on a remote machine, or entirely on the remote machine or server.

[0068] In the context of this disclosure, a computer-readable medium can be any physical medium capable of containing or storing a program for use by or in conjunction with a command-execution system, apparatus, or device. The computer-readable medium can be a computer-readable signaling medium or a computer-readable storage medium. A computer-readable medium can be, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination thereof.More specific examples of a computer-readable storage medium would be an electrical connection with one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only storage device (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0069] Even though the processes are presented in a specific order, this does not mean that these processes must be executed in the presented order or sequentially, or that all presented processes must be executed to achieve the desired results. Multitasking and parallel processing can be advantageous under certain circumstances. Certain features described in connection with separate implementations can also be implemented in combination within a single implementation. Conversely, various features described in connection with a single implementation can also be implemented separately in multiple implementations or in any suitable subcombination.

[0070] The preceding detailed description of this disclosure refers to the accompanying drawings, which form part of this disclosure and illustrate how examples of the disclosure can be carried out. These examples are described in sufficient detail to enable those skilled in the art to put the examples of this disclosure into practice, and it is understood that other examples may be used and that process, electrical, and / or structural modifications may be made without departing from the scope of this disclosure.

Claims

[1] A procedure (200) comprising the following: Selecting (210) a virtual access point (VAP) from a set of VAPs (112) as a sending VAP based on initial contextual information about the set of VAPs (112) indicating the respective importance levels of a set of clients (120) connecting to the set of VAPs (112), by comparing the respective importance levels of the set of clients (120) with each other and according to a determination that an importance level of one client of the set of clients (120) is higher than that of other clients of the set of clients (120), selecting a VAP to which the client is connected as the sending VAP, wherein at least one from the set of VAPs (112) that is not the sending VAP is determined as at least one non-sending VAP; Generating (220) a beacon frame (300) for the set of VAPs (112) by inserting an identifier of the transmitting VAP into a header part of the beacon frame and inserting at least one identifier of the at least one non-transmitting VAP into a payload part of the beacon frame (300); and Transfer (230) of the beacon frame (300). [2] Method (200) according to claim 1, wherein the identifier of the sending VAP comprises a Basic Service Set Identifier (BSSID) of the sending VAP, and wherein the insertion of the at least one identifier of the at least one non-sending VAP into the payload part of the beacon frame (300) comprises: Determine at least one offset from the BSSID of the sending VAP; and Inserting the specified at least one offset into the payload portion of the beacon frame (300) as the at least one identifier of the non-transmitting VAP. [3] Method (200) according to claim 1, wherein selecting a VAP from the set of VAPs (112) as the sending VAP comprises: Selecting a VAP from the set of VAPs (112) as the sending VAP based on at least one of the following: a second contextual piece of information that specifies the size of the beacon frame to be generated (300), where the size varies according to a selection by the sending VAP, a third contextual information that specifies the respective latency requirement levels of the clients connecting to the set of VAPs (112), a fourth piece of contextual information that specifies a VAP communication request from at least one client, where the VAP communication request specifies that the at least one client must be served by a sending VAP, or a fifth piece of contextual information, which indicates the number of times a client (120-M) switches from one access point (AP) (110), which includes the set of VAPs (112), to other APs (410) within a certain period of time. [4] Method (200) according to claim 3, wherein selecting a VAP from the set of VAPs (112) as the sending VAP based on the second context information comprises: Selecting a VAP from the set of VAPs (112) as the sending VAP, such that the size of the beacon frame (300) determined for the selected VAP is smaller than when selecting other VAPs from the set of VAPs (112). [5] Method (200) according to claim 3, wherein selecting a VAP from the set of VAPs (112) as the sending VAP based on the third context information comprises: Determine, from the respective latency request levels, a latency request level of a client that is below a threshold latency level; and Selecting a VAP from the set of VAPs (112) to which the client is connected, as the sending VAP. [6] Method (200) according to claim 3, wherein selecting a VAP from the set of VAPs (112) as the sending VAP based on the fourth context information comprises: Selecting a VAP from the set of VAPs (112) to which the at least one client is connected, as the sending VAP. [7] Method (200) according to claim 3, wherein selecting a VAP from the set of VAPs (112) as the sending VAP based on the fifth context information comprises: According to a determination that the number of times exceeds a threshold, select a VAP from the set of VAPs (112) to which the client is connected as the sending VAP. [8] A communication device comprising the following: at least one processor; and a memory coupled to the at least one processor, wherein the memory stores instructions to cause the at least one processor to perform operations that include: Selecting a virtual access point (VAP) from a set of VAPs as a sending VAP based on initial context information about the set of VAPs (112) specifying a size of the beacon frame (300) to be generated, by selecting a VAP from the set of VAPs as the sending VAP, such that the size of the beacon frame (300) determined for the selected VAP is smaller than that determined when selecting other VAPs from the set of VAPs, wherein at least one VAP from the set of VAPs (112) that is not the sending VAP is determined as at least one non-sending VAP; Generating a beacon frame (300) for the set of VAPs (112) by inserting an identifier of the sending VAP and at least one identifier of the at least one non-sending VAP into the beacon frame (300); and Transferring the beacon frame (300). [9] The communication device according to claim 8, comprising generating the beacon frame (300): Inserting the identifier of the sending VAP, which includes a Basic Service Set Identifier (BSSID) of the sending VAP, into a header part of the beacon frame (300). [10] The communication device according to claim 9, wherein generating the beacon frame (300) further comprises: for a non-sending VAP of at least one non-sending VAP, Determine at least one offset from the BSSID of the sending VAP; and Inserting the specified at least one offset into a payload part of the beacon frame (300) as the at least one identifier of the non-transmitting VAP. [11] The communication device according to claim 8, wherein selecting a VAP from the set of VAPs (112) as the sending VAP comprises: Selecting a VAP from the set of VAPs (112) as the sending VAP based on at least one of the following: a second contextual information that indicates the respective importance levels of a set of clients (120) that connect to the set of VAPs (112), a third contextual information that specifies a respective latency requirement level for the set of clients (120) connecting to the set of VAPs (112), a fourth piece of contextual information that specifies a VAP communication request from at least one client, where the VAP communication request specifies that the at least one client must be served by a sending VAP, or a fifth piece of contextual information, which indicates the number of times a client (120-M) switches from one access point (AP) (110), which includes the set of VAPs (112), to other APs (410) within a certain period of time. [12] The communication device according to claim 11, wherein selecting a VAP from the set of VAPs (112) as the sending VAP based on the second context information comprises: Comparing the respective importance levels of the set of clients with each other; and According to a determination that a priority level of one client in the set of clients (120) is higher than that of other clients in the set of clients (120), selecting a VAP to which the client is connected as the sending VAP. [13] The communication device according to claim 11, wherein selecting a VAP from the set of VAPs (112) as the sending VAP based on the third context information comprises: Determine, from the respective latency request levels, a latency request level of a client that is below a threshold latency level; and Selecting a VAP from the set of VAPs (112) to which the client is connected, as the sending VAP. [14] The communication device according to claim 11, wherein selecting a VAP from the set of VAPs (112) as the sending VAP based on the fourth context information comprises: Selecting a VAP from the set of VAPs (112) to which the at least one client is connected, as the sending VAP. [15] The communication device according to claim 11, wherein selecting a VAP from the set of VAPs (112) as the sending VAP based on the fifth context information comprises: According to a determination that the number of times exceeds a threshold, select a VAP from the set of VAPs (112) to which the client is connected as the sending VAP. [16] A non-transitory, computer-readable medium comprising instructions stored on it which, when executed by a device, cause the device to: to select a virtual access point (VAP) from a set of VAPs (112) as the sending VAP, based on initial context information about the set of VAPs (112) that specifies the respective latency request levels of a set of clients (120) connecting to the set of VAPs, by determining a client's latency request level below a threshold latency level from the respective latency request levels and selecting a VAP from the set of VAPs (112) to which the client is connected as the sending VAP; to determine at least one non-sending VAP from the set of VAPs (112) that is not the sending VAP; to create a beacon frame (300) for the set of VAPs (112) by inserting an identifier of the sending VAP into a header part of the beacon frame (300) and inserting at least one identifier of the at least one non-sending VAP into a payload part of the beacon frame; and to transmit the beacon frame (300). [17] The non-transitory, computer-readable medium according to claim 16, wherein the identifier of the sending VAP comprises a Basic Service Set Identifier (BSSID) of the sending VAP, wherein the insertion of the at least one identifier of the at least one non-transmitting VAP into the payload portion of the beacon frame (300) comprises: For a non-sending VAP of at least one non-sending VAP, determine at least one offset from the BSSID of the sending VAP; and Inserting the specified at least one offset into the payload portion of the beacon frame (300) as the at least one identifier of the non-transmitting VAP. [18] The non-transitory, computer-readable medium according to claim 16, wherein the instructions that cause the device to select a VAP from the set of VAPs (112) as the sending VAP include instructions that cause the device to: to select a VAP from the set of VAPs (112) as the sending VAP based on at least one of the following points: a second contextual information that indicates the respective importance levels of a set of clients (120) that connect to the set of VAPs (112), a third contextual piece of information that specifies the size of the beacon frame to be generated (300), the size of which varies according to a selection of the sending VAP, a fourth piece of contextual information that specifies a VAP communication request from at least one client, where the VAP communication request specifies that the at least one client must be served by a sending VAP, or a fifth piece of contextual information, which indicates the number of times a client (120-M) switches from one access point (110)(AP) comprising the set of VAPs (112) to other APs (410) within a given period of time.

Images