Context transfer of incompatible features to allow seamless roaming with target aps

Abstract

A non-AP STA transmits context information to a source AP which transfers the context information to target APs to improve seamless roaming performance when the non-AP STA roams to a TAP. The context information shared with the APs not only include context items describing features supported by the non-AP STA and the SAP, but also context items describing features not supported by the SAP although supported by the non-AP STA. This allows all the non-AP STA's supported features to be transferred to the TAPs. The context items may be 802.11 elements arranged into elements compatible to both the transmitter and receiver stations and elements not compatible with one of both stations. A reorganization of the compatible and incompatible elements is provided by each receiver station when transferring received context information of the non-AP STA to another AP. A dedicated signalling is provided to identify the elements including context information.

Description

[0001] CONTEXT TRANSFER OF INCOMPATIBLE FEATURES TO ALLOW SEAMLESS ROAMING WITH TARGET APS

[0002] FIELD OF THE INVENTION

[0003] The present invention generally relates to wireless communications and more specifically to wireless communications involving seamless roaming between multiple access points.

[0004] BACKGROUND OF THE INVENTION

[0005] The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section. Furthermore, all embodiments are not necessarily intended to solve all or even any of the problems brought forward in this section.

[0006] Wireless communication networks are widely deployed to provide various communication services such as voice, video, packet data, messaging, broadcast, etc. These wireless networks may be multiple-access networks capable of supporting multiple users by sharing the available network resources. Examples of such multiple-access networks include Code Division Multiple Access (CDMA) networks, Time Division Multiple Access (TDMA) networks, Frequency Division Multiple Access (FDMA) networks, Orthogonal FDMA (OFDMA) networks, and Single-Carrier FDMA (SC-FDMA) networks.

[0007] The WLAN (Wireless Local Area Network) technology based on the IEEE (Institute of Electrical and Electronics Engineers - RTM) 802.11 family standards provides a wireless communication between two or more devices. In IEEE 802.11 , a non-AP station (non-AP STA) or a non-AP station MLD (Multi-Link Device) associates to an access point station (AP) or an AP MLD using a so-called association procedure. After the association is established, two stations (non-AP STA and AP) or two MLDs can exchange data frames with each other using the medium access mechanism. In IEEE 802.1 1 , a FT (Fast BSS Transition) mechanism is provided to allow non-AP STAs (or non-AP MLDs) to quickly roam from one AP (or AP MLD) to another AP (or AP MLD) inside the same ESS (Extended Service Set). However, the FT mechanism still has some limitation on the “seamless” aspect of the roaming (e.g. data loss / service interruption).

[0008] To overcome this drawback, the new task group IEEE 802.1 1 bn introduced a new 802.11 feature known as “seamless roaming” mechanism. The seamless roaming mechanism uses context transfer to share context information about the non-AP STA or MLD with other AP stations or MLDs (known as TAPs or Target APs) belonging to a roaming domain in which the non-AP STA or MLD can roam. The context information contains roaming information between the non-AP STA or MLD and the SAP (Source AP; the AP or AP MLD to which the non-AP STA or MLD is currently associated). Having this context information in advance (before the effective roaming), the roaming procedure between the non-AP STA or MLD and any TAP can be prepared to reduce the roaming delay which leads to more “seamless” roaming.

[0009] The “seamless roaming” mechanism has however some limitations that the present disclosure intends to overcome at least in part.

[0010] SUMMARY OF INVENTION

[0011] The SAP (AP station or AP MLD) is only aware of features of an associated non-AP STA or MLD that the SAP also supports. Furthermore, the SAP is able to share context information of the associated non-AP STA with a TAP only with respect to features that both SAP and TAP support. However, the TAPs may have enhanced or different supported features (such as capabilities), in which case the shared context information is partial with respect to all supported features from the TAP point of view. This reduces the performance of the “seamless” roaming to this TAP as the latter cannot prepare in advance the entire roaming. Embodiments of the present disclosure seek to overcome such limitations.

[0012] Furthermore, the various types of information that are shared appear restrictive. It would be profitable that additional information be shared in a generic way to allow a wider range of information to be shared. A more efficient “seamless” roaming can be obtained.

[0013] In this respect, the disclosure proposes a method of roaming a non-access point (non-AP) station (STA) or non-AP multi-link device (MLD) associated with a source AP station or MLD (SAP) to a target AP station or MLD (TAP), comprising, at one of the stations or MLDs (i.e., the non-AP STA or MLD, the SAP or any TAP of the roaming domain): obtaining context information of the non-AP station or MLD, and transferring (i.e., sharing) the context information of the non-AP station or MLD to one or more AP stations or MLDs (i.e., SAP or TAP), wherein the context information includes one or more context items describing features not supported by the SAP.

[0014] Therefore, the non-AP station (or MLD) may provide all its supported features, regardless of the SAP’s capabilities, in order that all its supported features are shared as context information with the TAPs of the roaming domain. As a result, each TAP becomes aware of the features supported by the non-AP station and can prepare in advance a quicker roaming to its network. An enhanced seamless roaming mechanism is obtained.

[0015] In addition, the transfer of the non-AP station’s supported features within the roaming domain allows additional processing to be performed within the roaming domain in order to further improve the mechanism. As an example - further described below, the knowledge of these supported features allows recommendations of appropriate TAPs to be proposed to the non-AP station for roaming based on the enhanced set of shared supported features. For example, a list of the most appropriate TAPs considering a matching between their supported features can be built. As a result, an improved seamless roaming mechanism is obtained, so that the context information is properly shared among the APs (or AP MLDs) even if they have different supported features.

[0016] Optional aspects of the disclosure are defined below with reference to methods, while they can be transposed into device features.

[0017] In some embodiments, the context information further includes one or more context items describing features supported by the SAP. In that way, the non-AP station (or MLD) provides all its supported features, regardless of the SAP’s capabilities.

[0018] In some embodiments, one or more of the context items are elements in the meaning of the IEEE802.11 series of standards. An “element” in the meaning of the IEEE802.11 series of standards is data made of an Element ID field and, if present, an Element ID Extension field, a Length field (indicating the number of octets in the element excluding the Element ID and Length fields) and an Information field carrying information specific to the element.

[0019] A context item corresponds to an attribute of the non-AP station or MLD that defines part of the communication context in which the non-AP station or MLD evolves. As mentioned above, this context is exchanged with the target APs or AP MLDs for them to prepare a roaming of the non-AP station or MLD.

[0020] In some embodiments, one or more of the context items describe one or more capabilities of the non-AP station or MLD. In particular, the one or more capabilities of the non- AP station or MLD are not supported by the SAP. The capabilities of the non-AP stations (or MLDs) can therefore be shared through multiple hops with TAPs, although any intermediary APs do not support all of these capabilities.

[0021] In some embodiments, one or more of the context items include a body of one or more Action frames prepared by the non-AP station or MLD. In particular, the one or more Action frame bodies define actions not recognized (i.e., supported) by the SAP. However, there may also be some Action frame bodies that the SAP could recognize. An “action” corresponds to a Category value as set in the Action field forming the Action frame body or the Organization Identifier value for the Vendor Specific (Protected) Action frames. Depending on the supporting generations, capabilities, or Organization Identifiers of the APs, some of them may support or not some actions.

[0022] This configuration allows the non-AP STA or MLD to pre-exchange, via the SAP, Action frames with any TAP supporting the corresponding Action frames, although the SAP cannot recognize these Action frames. This is a sort of pre-negotiation with the TAP that advantageously speeds the negotiation in case the non-AP STA roams to the TAP.

[0023] In specific embodiments, the one or more Action frame bodies include one or more communication parameters set between the non-AP station or MLD and the SAP by exchanging the one or more Action frames. As an example, the one or more communication parameters includes a Block Acknowledgment parameter negotiated between the non-AP station or MLD and the SAP. This configuration allows for example the SAP to share, further to the non-AP station (or MLD)’s capabilities, any communication (or 802.11) parameter defined for the non-AP station, to the TAPs. This is to ease the preparation of the roaming with the communication parameters already configured in the non-AP station.

[0024] In some embodiments, transferring the context information includes sending a management frame containing the context items.

[0025] In embodiments, the management frame is one from a (Re)Association Request frame, a Probe Request frame, an Authentication Request frame, an Action frame.

[0026] In some embodiments, the management frame includes, in its frame body, a toplevel container element whose Information field contains the context items. Preferably in that case, the context items are 802.11 elements within the container element, “top level” means here that the container element is directly includes in the frame body, without being a sub-element of another element within the frame body.

[0027] In embodiments, at least one of the context items contained in the top-level container element is duplicated next to the top-level container element, “next to the element” means at the same level - here top level - as the element within the frame body.

[0028] In some embodiments, the management frame includes, in its frame body, a toplevel container element whose Information field contains only the context items corresponding to features not supported by one of the stations or MLDs exchanging the management frame, and next to the top-level container element in the frame body, a plurality of elements including the context items corresponding to features supported by the stations or MLDs exchanging the management frame. Distinguishing between the “compatible” elements and the “incompatible” elements directly in the body frame allows an easier handling of these elements (hence of the context items) by the receiver station to, e.g., transfer them to another AP or AP MLD.

[0029] In embodiments, the management frame includes, in its frame body, a first top-level container element whose Information field contains one or more context items describing one or more capabilities of the non-AP station or MLD not supported by one of the stations or MLDs exchanging the management frame or a list of element identifiers to identify the context items within a sequence of elements provided in the frame body, and includes a second top-level container element whose Information field contains a body of one or more Action frames exchanged between the non-AP station or MLD and the SAP that are not recognized (i.e., supported) by one of the stations or MLDs exchanging the management frame. This allows both capabilities and negotiated communication parameters to be easily shared as context information.

[0030] In some embodiments, the management frame includes, in its frame body, a sequence of elements including a first element and elements that respectively include the context items, wherein the first element includes a list of element identifiers to identify the context items within the sequence of elements.

[0031] In some embodiments, the management frame is an Action frame and include one

[0032] Action field to contain the context items. In embodiments, the Action frame includes one Action field to contain a body of one or more Action frames exchanged between the non-AP station or MLD and the SAP that are not recognized (i.e., supported) by one of the stations or MLDs exchanging the Action frame, and includes a top-level container element whose Information field contains one or more context items describing one or more capabilities of the non-AP station or MLD not supported by one of the stations or MLDs exchanging the Action frame .

[0033] In some embodiments, an identifier of the non-AP station or MLD is provided in association with the context information.

[0034] In some embodiments, the method further comprises calculating a roaming score of a candidate target AP station or MLD based on the transferred context information and supported features of the candidate target AP station or MLD. The calculation may be performed by any AP (or MLD) or a controller within the roaming domain to which the APs belong.

[0035] Such scores may for example be used to build a list of candidate target AP stations or MLDs from a plurality of AP stations or MLDs based on the transferred context information.

[0036] In embodiments, the list is an ordered list of candidate target AP stations or MLDs based on respective roaming scores calculated based on the transferred context information and supported features of each respective candidate target AP station or MLD. The list may include a limited number of candidate TAPs, e.g. those having the best scores (given a number of candidate TAPs or given a score threshold).

[0037] In embodiments, the method further comprises sending the built list of candidate target AP stations or MLDs to the non-AP station.

[0038] In some embodiments, the method further comprises (e.g., at the non-AP station) obtaining features (e.g., capabilities) supported by the SAP (e.g., via Beacon frames or Probe Response frames or Association Response frames), and classifying features of the non-AP station or MLD into, on one hand, context items describing features also supported by the SAP and, on the other hand, context items describing features not supported by the SAP, to form the context information.

[0039] In some embodiments, the method further comprises (e.g., at the source AP) reorganizing the context items of the obtained context information into, on one hand, the context items describing features not supported by the station or MLD and an AP station or MLD addressee of the transfer, and, on the other hand, the context items describing features supported by both the station or MLD and the addressee AP station or MLD.

[0040] The disclosure also proposes a method of roaming a non-access point (non-AP) station or multi-link device (MLD) associated with a source AP station or MLD (SAP) to a target AP station or MLD (TAP), comprising, at the SAP: setting one or more communication parameters of the non-AP station or MLD by exchanging at least one Action frame with the non-AP station or MLD, and transferring (i.e., sharing) context information of the non-AP station or MLD to one or more TAPs, wherein the context information includes the body of the Action frame to communicate the one or more communication parameters of the non-AP station or MLD to the one or more TAPs.

[0041] The Action frame allows configurations to be set between the stations. Transferring the Action frame bodies advantageously allows any type of negotiated configuration to be shared with the TAPs without specific signalling. It also allows this information to be forwarded by any TAP that does not support the concerned configuration or even cannot recognize the underlying Action frame.

[0042] Correlatively, the invention also provides a wireless communication device comprising at least one microprocessor configured for carrying out any method as described above.

[0043] Another aspect of the invention relates to a non-transitory computer-readable medium storing a program which, when executed by a microprocessor or computer system in a wireless device, causes the wireless device to perform any method as described above.

[0044] At least parts of the methods according to the invention may be computer implemented. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit", "module" or "system". Furthermore, the present invention may take the form of a computer program product embodied in any tangible medium of expression having computer usable program code embodied in the medium.

[0045] Since the present invention can be implemented in software, the present invention can be embodied as computer readable code for provision to a programmable apparatus on any suitable carrier medium. A tangible, non-transitory carrier medium may comprise a storage medium such as a floppy disk, a CD-ROM, a hard disk drive, a magnetic tape device or a solid- state memory device and the like. A transient carrier medium may include a signal such as an electrical signal, an electronic signal, an optical signal, an acoustic signal, a magnetic signal or an electromagnetic signal, e.g. a microwave or RF signal.

[0046] BRIEF DESCRIPTION OF THE DRAWINGS

[0047] Embodiments of the invention will now be described, by way of example only, and with reference to the following drawings in which:

[0048] Figure 1 illustrates an exemplary network environment in which embodiments of the present disclosure can be implemented;

[0049] Figure 2 illustrates exemplary supported features of the stations of Figure 1 in which embodiments of the disclosure can be implemented;

[0050] Figure 3 illustrates the frame format of the (PVO) Management frame which is defined in the IEEE 802.1 1 specification;

[0051] Figure 4, 5a, 5b, 6, 7 and 8 illustrate exemplary frame formats of a Management frame according to some embodiments of the disclosure; Figure 9 illustrates, using a timeline, exemplary communication methods involving one or more management frames to perform seamless roaming, according to some embodiments of the disclosure;

[0052] Figure 10 illustrates, using a flowchart, general steps at a transmitter STA generating and transmitting frames which include context information according to embodiments of the disclosure;

[0053] Figures 11a and 11 b illustrate, using flowcharts, steps at the transmitter STA generating frames with Context Container element as context information according to embodiments corresponding to Figures 5a and 5b;

[0054] Figures 12a and 12b illustrate, using flowcharts, steps at the transmitter STA generating frames with Action frame bodies as context information according to embodiments corresponding to Figures 7 and 8;

[0055] Figure 13 illustrates, using a flowchart, general steps at a receiver STA receiving the management frame which includes context information, according to some embodiments of the disclosure;

[0056] Figure 14, 15a, 15b, 16, 17a and 17b illustrate, using flowcharts, steps at the receiver STA extracting context information from a received frame, according to embodiments corresponding respectively to the formats of Figure 4, 5a, 5b, 6, 7 and 8;

[0057] Figure 18a and Figure 18b illustrate exemplary signalling of features supported by STA1 in the management frames sent from each transmitter STA to each receiver STAs, according to some embodiments of the disclosure;

[0058] Figure 19 illustrates, using a flowchart, general steps at an SAP to share communication parameters of that non-AP station or MLD they have negotiated together by exchanging Action frames, according to some embodiments of the disclosure;

[0059] Figure 20a shows a schematic representation of a wireless communication device in accordance with embodiments of the present invention; and

[0060] Figure 20b illustrates schematically the architecture of the communication device of Figure 20a.

[0061] DETAILLED DESCRIPTION OF EMBODIMENTS

[0062] The present specification regards communication methods where a non-AP STA or MLD performs a seamless roaming from the SAP (Source or Serving AP station or MLD) to one of the TAPs (Target AP stations or MLDs) of a roaming domain, in a case where stations or MLDs (including non-AP STA / MLD, SAP and TAPs) have different capabilities or supported features. The non-AP STA (or MLD) may transmit context information to SAP and SAP may transfer the context information to TAPs. The context information includes information which may be used to improve the seamless roaming performance when the non-AP STA (or MLD) roams to a TAP. The context information shared with the AP stations (SAP and TAPs) (or MLDs) not only include one or more context items (or “attributes”) describing features supported by the non-AP STA (or MLD) and the SAP, but also one or more context items describing features not supported by the SAP although supported by the non-AP STA (or MLD). This allows all the non-AP STA (or MLD) ’s context to be transferred to the TAPs. The context items may be 802.11 elements arranged into elements compatible to both the transmitter station and the receiver station and elements not compatible with one of both stations. A reorganization of the compatible and incompatible elements is provided by each receiver station when transferring received context information of the non-AP STA (or MLD) to another AP station (or MLD). A dedicated signalling is provided to identify the elements including context information.

[0063] The techniques described herein may be used for various broadband wireless communication systems, including communication systems that are based on an orthogonal multiplexing scheme. Examples of such communication systems include Spatial Division Multiple Access (SDMA) system, Time Division Multiple Access (TDMA) system, Orthogonal Frequency Division Multiple Access (OFDMA) system, and Single-Carrier Frequency Division Multiple Access (SC-FDMA) system. An SDMA system may utilize sufficiently different directions to simultaneously transmit data belonging to multiple user terminals, i.e., wireless devices or stations. A TDMA system may allow multiple user terminals to share the same frequency channel by dividing the transmission signal into different time slots or resource units, each time slot being assigned to different user terminal. An OFDMA system utilizes orthogonal frequency division multiplexing (OFDM), which is a modulation technique that partitions the overall system bandwidth into multiple orthogonal sub-carriers or resource units. These sub-carriers may also be called tones, bins, etc. With OFDM, each sub-carrier may be independently modulated with data. An SC-FDMA system may utilize interleaved FDMA (IFDMA) to transmit on sub-carriers that are distributed across the system bandwidth, localized FDMA (LFDMA) to transmit on a block of adjacent sub-carriers, or enhanced FDMA (EFDMA) to transmit on multiple blocks of adjacent sub-carriers.

[0064] The teachings herein may be incorporated into (e.g., implemented within or performed by) a variety of apparatuses (e.g., stations). In some aspects, a wireless device or station implemented in accordance with the teachings herein may comprise an access point (so- called AP) or not (so-called non-AP STA (station)). STA includes both AP and non-AP STA.

[0065] An AP may comprise, be implemented as, or known as a Node B, Radio Network Controller (“RNC”), evolved Node B (eNB), 5G Next generation base station (gNB), Base Station Controller (“BSC”), Base Transceiver Station (“BTS”), Base Station (“BS”), Transceiver Function (“TF”), Radio Router, Radio Transceiver, Basic Service Set (“BSS”), Extended Service Set (“ESS”), Radio Base Station (“RBS”), or some other terminology.

[0066] A non-AP station may comprise, be implemented as, or known as a subscriber station, a subscriber unit, a mobile station (MS), a remote station, a remote terminal, a user terminal (UT), a user agent, a user device, user equipment (UE), a user station, or some other terminology. In some implementations, a non-AP STA may comprise a cellular telephone, a cordless telephone, a Session Initiation Protocol (“SIP”) phone, a wireless local loop (“WLL”) station, a personal digital assistant (“PDA”), a handheld device having wireless connection capability, or some other suitable processing device connected to a wireless modem. Accordingly, one or more aspects taught herein may be incorporated into a phone (e.g., a cellular phone or smart phone), a computer (e.g., a laptop), a tablet, a portable communication device, a portable computing device (e.g., a personal data assistant), an entertainment device (e.g., a music orvideo device, or a satellite radio), a global positioning system (GPS) device, or any other suitable device that is configured to communicate via a wireless or wired medium. In some aspects, the non-AP station may be a wireless node. Such wireless node may provide, for example, connectivity for or to a network (e.g., a wide area network such as the Internet or a cellular network) via a wired or wireless communication link.

[0067] An AP manages a set of STAs (registered to it or associated with it) that together organize their accesses to the wireless medium for communication purposes. The STAs (including the AP to which they register) form a service set, here below referred to as basic service set, BSS (although other terminology can be used). A same physical STA acting as an access point may manage two or more BSSs (and thus corresponding WLANs): each BSS is thus uniquely identified by a specific basic service set identification, BSSID and managed by a separate virtual AP implemented in the physical AP. Each STA is identified within a BSS thanks to an identifier, AID, assigned to it by the AP upon registration. Multiple BSSs may form an ESS (Extended Service Set), which is the union of the infrastructure BSSs with the same SSID connected by a single DS (Distribution System).

[0068] The current discussions in the task group 802.11 be, as illustrated by draft IEEE P802.11 be / D7.0, introduce the Multi-Link Operation (MLO) when it comes to MAC layer operation. The MLO allows multi-link devices to establish or setup multiple links and operate them simultaneously. A Multi-Link Device (MLD) is a logical entity and has more than one affiliated STA (STA) and has a single MAC service access point (SAP) to logical link control (LLC), which includes one MAC data service. Multiple affiliated non-AP STAs of a non-AP MLD can then setup communication links with multiple affiliated APs of an AP MLD, hence forming a multi-link channel. A communication link or “link” thus corresponds to a given channel (e.g. , 20 MHz, 40 MHz, and so on) in a given frequency band (e.g., 2.4 GHz, 5 GHz, 6 GHz) between an AP affiliated with the AP MLD and a non-AP STA affiliated with the non-AP MLD.

[0069] The description below mostly concentrates on a single link for ease of explanation. However, similar considerations can be made with respect to each link forming a multiple link set for MLD devices. Therefore, the term “non-AP STA” or “non-AP station” may refer to one affiliated STA of a non-AP MLD (non-AP STAs of a non-AP MLD), and “AP station” may refer to one affiliated AP of an AP MLD. The word “station” has a broad meaning encompassing both non-AP stations and AP stations.

[0070] Similarly, it is mainly made reference to non-AP stations and APs, rather than non- AP MLDs and AP MLDs, for ease of description. However, the teachings and embodiments described below between stations also apply between MLDs. Figure 1 illustrates an exemplary network environment in which embodiments of the present disclosure can be implemented.

[0071] The illustrated wireless network environment comprises a group of BSSs that form a seamless roaming domain (or called as a seamless mobility domain). Seamless roaming domain is a set of APs implementing seamless features allowing non-AP STA to perform seamless roaming among the BSSs inside the domain. This seamless roaming domain may be identical to an ESS or a Mobility Domain or may be different (i.e. , the seamless roaming domain can consist in multiple ESSs / Mobility Domains or an ESS / Mobility Domain may include multiple seamless roaming domains). Each BSS typically operates on a different wireless channel from the other BSSs, to avoid interfering one each other. In variants, it can also operate on the same wireless channel as one or more other BSSs.

[0072] The depicted seamless roaming domain 100 consists of four BSSs. A first wireless network (or Basic Service Set) BSS1 comprises SAP1 (Source access point, or Serving access point) 110 and non-AP station (STA) 101 associated with SAP1 110 (i.e., registered to it). Second, third and fourth wireless network BSS2, BSS3 and BSS4 comprise TAP1 (Target access point) 111 , TAP2 112 and TAP3 113 respectively. Inside the seamless roaming domain, it is assumed that the APs - including SAP and TAPs - have inter-connections and can communicate one with each other. They may have direct connections or in-direct connections (i.e., via intermediate station). The connection can be either a wireless connection or a wired connection.

[0073] Of course, another number of wireless networks and any number of non-AP stations per wireless network can be contemplated. In the present disclosure, non-AP STA1 101 , SAP1 110, TAP1 111 , TAP2 112 and TAP3 1 13 are also referred to, respectively, as STA1 , SAP1 , TAP1 , TAP2 and TAP3. A device may act as an AP of one wireless network and at the same time may belong to another wireless network as an associated STA.

[0074] All or part of the APs may be affiliated APs to the same AP MLD. They also can be separate devices. Any AP broadcasts management frames, such as Beacon frames, to share parameters to be used for the functioning of its BSS.

[0075] The stations (AP and non-AP) of each BSS exchange data frames with each other over the communication channel of the BSS, under the management of the AP, using the primary channel of the BSS and optional secondary channels aggregated to the primary channel.

[0076] The stations (including the AP) compete one against each other over the primary channel using EDCA (Enhanced Distributed Channel Access) contention to access the communication channel in order to be granted a transmission opportunity (TXOP) over an operating channel made of the primary channel and a secondary channel to increase bandwidth.

[0077] STA1 registers to one of the APs of the seamless roaming domain during an initial association procedure. In Figure 1 , SAP1 is the AP to which STA1 initially associates. After the initial association, STA1 may discover that one of the other APs (hence TAPs) provides better connection. In such a case, STA1 may perform roaming procedure to switch its association from SAP to one TAP. IEEE 802.11 r amendment defined the FT (Fast BSS Transition) protocol which enables fast roaming inside the Mobility Domain. Although this protocol reduces the roaming delay thanks to the sharing of the PMK (Pairwise Master Key) in advance inside the Mobility Domain, it still requires some delay during the roaming procedure.

[0078] In this context, the “seamless roaming” mechanism introduced by the IEEE 802.11 bn Task Group aims at reducing the roaming delay. Context information transfer is one of the methods to achieve this: a non-AP STA transmits context information to SAP and SAP may transfer this context information to one or more TAPs. This context information includes information which improves the seamless roaming performance. For example, without the context information, the non-AP STA must renegotiate some parameters when roaming to the TAP. This renegotiation introduces additional delay until the completion of negotiation, which degrades the performance of communication between the non-AP STA and the TAP. Context information transfer seeks to reduce or eliminate this delay by replacing the renegotiation procedure, when the transferred context information includes the negotiated parameter.

[0079] For example, one or more neighbouring or target APs may be prepared for roaming by transferring near static contexts (e.g. STA capabilities, Block Acknowledgment (BA) agreements, Stream classification service + QoS Characteristics, Target Wake Time). For a more concrete example, regarding the block ack (BA) agreement negotiation procedure, non-AP STA and AP negotiates parameters regarding the block ack using the ADDBA Request / Response frame exchange. After this block ack agreement negotiation procedure, STAs can communicate using the aggregation technologies such as A-MPDU and A-MSDU. This boosts upthe throughput between the STAs. The sharing of the negotiated BA agreement between APs avoids the BA agreement renegotiation procedure with the TAP and the non-AP STA can seamlessly continue using the aggregation technology after the roaming execution with TAP.

[0080] Various types of information can be utilized as context information to reduce such kind of degradation after the roaming execution.

[0081] For example, non-AP STA’s capability can be treated as context information. Non- AP STA’s capability can include supported features such as UHR (802.11 bn), EHT (802.11 be), HE (802.11 ax) etc. or TWT (Target Wake Time), QoS (Quality of Service) etc. or vendor information (non-AP STA developed by a specific Vendor X). These capabilities are typically informed by corresponding elements included in a management frame (such as an Association Request frame) exchanged between the non-AP STA and the SAP, and then between the SAP and the TAPs. For example, EHT Capabilities element indicates the EHT generational support, TWT element and QoS Capability element, Vendor Specific element respectively indicates support of TWT feature, QoS feature, specific vendor features as well. TAPs that know such capability information (as context information) before the roaming execution, are able to prepare their association with the non-AP STA in advance, hence achieving better performance (seamless) when the non-AP STA roams to the TAP. It is often the case that the roaming domain mixes APs supporting different features (e.g., different capabilities due to different versions or generations of APs), which features can also differ from those supported by the non-AP STA to a more or less extend.

[0082] Figure 2 illustrates exemplary supported features of the stations of Figure 1 in which embodiments of the present disclosure can be implemented. In this scenario, STA1 performs an initial association 201 to SAP1 . SAP1 then performs Context Transfer 203 to TAP1 and / or TAP2. TAP1 may also perform Context Transfer 203 to TAP2 instead of SAP1. And STA1 potentially performs seamless roaming 202 to TAP1 or TAP2.

[0083] In this scenario, exemplary capabilities for each station are shown in 200 for STA1 , 210 for SAP1 , 21 1 for TAP1 and 212 for TAP2. Concerning the supported 802.11 generations, STA1 and TAP1 supports post-UHR (post-802.11 bn) generation, which is the next future generation of the UHR (802.11 bn) generation. SAP1 and TAP2 supports UHR (802.11 bn) generation. Generations are not limited to post-UHR or UHR and can be any generations including the future IEEE 802.11 generations. Concerning the supported mechanisms, STA1 supports mechanisms A, B, C, SAP1 supports mechanism A, TAP1 supports mechanisms A, B, TAP2 supports mechanism C. Mechanisms A, B, C can be any kind of mechanism which has corresponding element showing the STA’s capability, including those defined in the future IEEE 802.11 standards. Concerning the supported vendor, STA1 and TAP1 support vendor X, SAP1 and TAP2 support vendor Y.

[0084] In such a scenario, when STA1 performs an initial association to SAP1 , it is aware of SAPTs supported features because they are advertised by SAP1 , e.g., via Beacon frames or Probe Response frames. Therefore, STA1 does not send the full context information to SAP1 , i.e. , all its supported features because part of them cannot be understood by SAP1 in case it has limited supported features. For example, STA1 omits post-UHR capabilities element, elements corresponding to mechanisms B and C, elements corresponding the vendor X support (e.g. Vendor specific element with the Organization identifier of vendor X).

[0085] As another example, STA1 does not send any Action frame with a Category field value that is not compatible with SAP1. In more detail, if STAI supports new Action frame defined in the post-UHR generation, it does not send this Action frame to SAP1 since SAP1 does not support post-UHR generation and cannot recognize the Action frame correctly. STA1 also does not send Action frame that SAP1 does not indicate support. SAP1 can indicate support by one of the capability bits included in one of the elements or the value of the Organization Identifier field included in the Vendor Specific element that SAP1 transmits in its Beacon, Probe Response, or Association Response frame.

[0086] Although the information exchanged between STA1 and SAP1 is enough to establish the best possible communication with SAP1 , this is no longer the case when STA1 roams to a TAP. STA1 is not sharing its entire context (e.g. all supported features) but a partial context compatible with SAP1 . As a consequence, there may lack some context information to establish the best connection between STA1 and any TAPs, due to the differences of supported features between the APs. The difference includes those features supported by the TAP that were not declared to SAP1 , but also features declared to SAP1 which does not forward them to the TAP as the latter does not support them. For instance, TAP1 is supporting post-UHR generation, mechanism B and vendor X which STA1 also supports, whereas SAP1 does not support them.

[0087] The present disclosure intends to overcome this situation by allowing more context information to be shared, i.e., transferred from the non-AP station and between the APs within the roaming domain. To illustrate, STA1 could better share its context information (e.g. elements, Action frame bodies) for post-UHR generation, feature B and vendor X to SAP1 , in order for the latter to perform Context Transfer of these information items to TAP1. Preferably, STA1 may transmit its full context to SAP1 which can transfer it to the TAPs.

[0088] To that end, enhanced methods of roaming a non-AP station (STA) associated with an SAP to a TAP are proposed. The methods comprise, at one of the stations (i.e., the non-AP STA, the SAP or any TAP of the roaming domain, or all of them): obtaining context information of the non-AP station and transferring (i.e., sharing) the context information of the non-AP station to one or more AP stations (i.e., SAP or TAP). The enhancement lies in the fact that the context information includes one or more context items describing features not supported by the SAP.

[0089] In embodiments, the context information also includes context items describing features supported by the non-AP station.

[0090] In that way, the station, e.g. STA1 to SAP1 or SAP1 to any TAP, provides an enhanced context of STA1 to the APs, with the addition of features non supported by SAP1 . In the scenario above, STA1 further provides an indication of its support of Post-UHR, of mechanisms B, C and of vendor X, which further indications can be transferred to any TAP which can therefore prepare the roaming procedure for STA1 in a better way than before.

[0091] The enhanced methods achieve efficient Context Transfers between stations having different supported features.

[0092] Any type of frame may convey the context items.

[0093] In some embodiments described below with reference to Figures 3 to 8, transferring the context information includes sending a management frame containing the context items. A management frame in the meaning of 802.11 is a MAC frame wherein the Type field of the Frame Control field in the MAC header is set to ‘00’.

[0094] Exemplary management frames to convey the context items include a (Re)Association Request frame, a Probe Request frame, an Authentication Request frame, an Action frame.

[0095] Figure 3 illustrates the frame format of the (PVO: Protocol Version 0) Management frame which is defined in the IEEE 802.11 specification. Management frame 300 consists of MAC Header 301 , Frame Body 302 and FCS (Frame Check Sequence) 303. Frame Body 302 consists of Fields that are not elements 304 and Elements 305. Elements 305 consists of zero or more Element 306. In this example N elements (Element 1 to Element N) are shown. Each element consists of Element ID field 307, Length field 308, Element ID Extension field 309 and Information field 310. Element ID field 307 and, if present, the Element ID Extension field 309 identifies the type of the element which is defined in the IEEE 802.1 1 specification (e.g., Table 9-130 of IEEE P802.11-REVme / D6.0, June 2024). Length field 308 indicates the number of octets in the element excluding the Element ID field 307 and Length field 308. Information field 310 contains information specific to the element.

[0096] Figure 4, 5a, 5b, 6, 7 and 8 illustrate exemplary frame formats of the Management frame according to some embodiments, that allow the context items describing features supported by the SAP and the context items describing features not supported by the SAP to be conveyed. Figure 4, 5a, 5b, 6 and 7 rely on 802.11 elements to convey the context items, whereas Figure 8 relies on an Action field in the meaning of the 802.11 Action frames.

[0097] As apparent from above, one or more of the context items may describe one or more capabilities of the non-AP station. Part or all of the capabilities are not supported by the SAP.

[0098] Also, one or more of the context items may include a body of one or more Action frames prepared by the non-AP station, for example to pre-negotiate some communication parameters. Therefore, all or part of the Action frame bodies include one or more communication parameters that may be set for the non-AP station by exchanging the one or more Action frames with an AP, e.g., a Block Acknowledgment parameter negotiated between the non-AP station and the SAP. There is an interest of transferring Action frame bodies (prepared by the non-AP station) that are not recognized (i.e. , supported) by the SAP, because they can be recognized by any TAP with a view of preparing the roaming of the non-AP station. The Action frame bodies may not be exchanged with the SAP in classical Action frame exchanges to set any parameter, but only provided as context items to the SAP (which cannot recognize them) for the latter to transfer them to the TAPs.

[0099] The frame formats are shown in the Figures based on the PV0 (Protocol Version 0) format of Management frame. However, they are not limited to PV0 and they can be applied to PV1 or any future protocol versions.

[0100] The Management frame is sent by a transmitter station or STA (which may be the non-AP station, the SAP or any TAP) to a receiver or addressee AP station or STA (which may be the SAP or any TAP).

[0101] The transmitter STA and the receiver STA may have different supported features. In this respect, “Compatible features” or “Compatible context item” or “Compatible context attribute” or “Compatible elements” are meant to designate the features, items, elements that are compatible among the transmitter and receiver STAs, whereas “Incompatible features” or “Incompatible context item” or “Incompatible context attribute” or “Incompatible elements” are meant to designate the features, items, elements that are incompatible among the transmitter and receiver STAs. Below, it is mainly made reference to “Compatible elements” and “Incompatible elements” rather than the other wordings, for ease of description. Similarly, it is made reference to “support elements” rather than “context items” to highlight some embodiments may be element- based. However, the skilled person will recognize that using 802.11 elements is only one possible implementation of context items.

[0102] Both transmitter and receiver STAs can recognize (or do support) the Compatible elements properly, while one of them cannot recognize (or does not support) the Incompatible elements properly.

[0103] First embodiments are shown in Figure 4 in which the Compatible and Incompatible elements are listed in the frame body.

[0104] In these embodiments, Elements 305 includes both Compatible elements 401 and Incompatible elements 402, sharply contrasting with the conventional approach wherein a legacy transmitter STA does not include Incompatible elements in a Management frame since at least one of the transmitter and receiver STAs cannot properly handle the element. The fact that the transmitter STA adds Incompatible elements 402 in the frame to convey additional elements which include context information aids the seamless roaming procedure.

[0105] Compatible elements 401 may include both Elements which include context 403 and Elements without context 404. Elements which include context 403 consists of zero or more Elements (Element 1 to Element M) as shown in 405. These elements 405 include context information (e.g. non-AP STA’s capability, non-AP STA’s parameter) which aids the seamless roaming procedure. Elements without context 404 consists of zero or more Elements (Element 1 to Element N) as shown in 406. These elements do not include context information that need to be transferred to aid the seamless roaming procedure.

[0106] Similarly, Incompatible elements 402 may include both Elements which includes context 403 and Elements without context 404.

[0107] In variants, Incompatible elements 402 includes only Elements which includes context 403. Indeed, between the non-AP station and the SAP for example, the receiver STA (SAP) cannot recognize the Incompatible elements 402 because they are related to features it does not support. Therefore, it cannot distinguish between Elements which include context 403 and Elements without context 404, and has to blindly treat all of them as elements which contain context information, with a view of transferring them to a TAP. It is thus favourable for the transmitter STA to include only Elements which include context 403 inside the Incompatible elements 402. This variant reduces overhead of the frame between the non-AP station and the SAP, but also of the frames between the SAP (or any TAP) and any TAP.

[0108] The order of fields 401 and 402, 403 and 404, of Elements inside fields 405 and 406 is not limited to the order depicted in the figure and it can be shuffled in any order. Fields 401 , 402, 403 and 404 may be virtual fields shown for explanation purposes and those may not be physical fields clearly defined in the real frame formats.

[0109] As the context information provided in the Compatible and Incompatible elements are context information of the non-AP station (e.g. STA1), an identifier of the latter is provided in the frame. For example, in the management frame 300 sent from the non-AP station to the SAP, the MAC header 301 of the frame contains the MAC address of the non-AP station in its TA field. This is sufficient to correlate the context information with the non-AP station concerned.

[0110] For management frames exchanged between APs, an identifier of the non-AP station may be added in a STA ID field (not shown in Figure 4) provided in the frame body 302, e.g. as a starting field. STA ID field identifies the non-AP station for which the following context information are provided in the frame body 302. To have consistent frame formats, STA ID field can be also used in the frame between the non-AP station and the SAP. Or, to reduce the size of the frame, STA ID field can be omitted from the frame between the non-AP station and the SAP.

[0111] Second and third embodiments are shown in Figures 5a and 5b in which the management frame 300 includes, in its frame body 302, a top-level container element 501 a, 501 b whose Information field contains at least part of the context items forming the context information of the non-AP station, namely the Incompatible context items or elements.

[0112] In these embodiments, Context Container element 501 a or 501 b is introduced, that is supported (i.e., recognized and compatible) by both transmitter and receiver STAs. The name “Context Container” element is only an example and any other name - e.g. Context element, Container element, Context Transfer element, Context Information element, Seamless Roaming element, Seamless Roaming Context element, etc. - can be used.

[0113] Context Container element 501 a or 501 b is included in Elements 305 and contains the support elements which includes context information of the non-AP station that aids the seamless roaming. Context Container element 501 a or 501 b consists of Element ID field 307, Length field 308, Element ID Extension field 309 and Information field 310 as the conventional Element format. Element ID field 307 and Element ID Extension field 309 are set to specific values, not yet assigned in the latest IEEE 802.11 specification, to dedicatedly signal this new Context Container element (e.g. 255 for Element ID field 307 and 144 - or above up to 255 - for Element ID Extension field 309). Length field 308 indicates the number of octets in the element 501 a, 501 b excluding the Element ID field 307 and Length field 308.

[0114] In the second embodiments as shown in Figure 5a, the management frame 300 includes, in its frame body 302, the top-level container element 501 a whose Information field 310 contains all the context items, i.e., support elements that convey context information (hence to be transferred to the TAPs). That is, Information field 310 contains STA ID field 506a and both Compatible elements 503a and Incompatible elements 504a.

[0115] STA ID field 506a identifies the STA that originates the context information included in the following Compatible elements 503a and Incompatible elements 504a. STA ID is shared among the APs (i.e., SAP and at least the candidate TAPs) inside the roaming domain so that the APs can identify a STA uniquely by the STA ID. This ID can be the MAC Address of the non-AP station, the MAC Address of the affiliated STA in case of non-AP MLD, or the MAC Address of the non-AP MLD, or an AID (Association I Dentifier) of the non-AP station or MLD shared between the APs or AP MLDs in the roaming domain. Compatible elements 503a and Incompatible elements 504a further consist of zero or more Elements (respectively Element 1 to Element M, and Element M+1 to Element M+N) as shown in 505a. To compare with Figure 4, here fields 503a / 504a of Context Container element 501 a only includes support elements that contain context information for seamless roaming, and no additional element describing other features supported by the non-AP station. These other features not related to context information are included as Other elements 502a. In contrast, the elements of Figure 4 mix both support elements with context information and without context information.

[0116] Advantageously, all context information of the non-AP station the transmitter STA wants to transfer is gathered inside the Context Container element 501 a which simplifies the process of both transmitter STA and receiver STA to handle the context information of the non- AP station.

[0117] It may happen that some elements in the Context Container element 501 a describe support features that are not only used for the context transfer but also for other purposes such as establishing the proper association. This is for example the case of the generational capability elements (e.g. EHT Capabilities element). These elements should not be only contained inside the Context Container element 501 a to avoid being hidden inside, but rather also be inside the Other elements 502a to be visible at the same level of the Context Container element 501 a. In this case, such elements may be duplicated: one occurrence inside the Context Container element 501 a as context information, and one other occurrence inside the Other elements 502a for other purpose than context transfer. In other words, at least one of the context items contained in the top-level container element is duplicated next to the top-level container element.

[0118] Of course, this would increase the overhead of the size of the Management frame. That is why in third embodiments as in Figure 5b, it is proposed to rather have the management frame 300 including, in its frame body 302, the top-level container element 501 b whose Information field 310 contains only the Incompatible elements from amongst the support elements. Of course, non-element information may be also present, such as the STA ID field. For instance, it means that only the context items describing features not supported by the SAP are included in the top-level container element 501 b in the frame sent by the non-AP station to the SAP. Furthermore, the Compatible elements are inserted next to the top-level container element in the frame body. For instance, the Other elements in the frame sent by the non-AP station to the SAP include the context items describing features supported by the SAP.

[0119] As the support elements describing features supported by the SAP are included in the Other elements section, the duplication of these elements is no longer required.

[0120] As shown in the Figure, Context Container element 501 b contains only Incompatible elements 503b. Compatible elements which include context information are included in Other elements 502b. Since the receiver STA can recognize the Compatible elements, it can identify which ones contains context information from the Other elements field and then extract such context information even if the context information is outside the Context Container element 501 b. The order of the elements included in fields 501 a and 502a, 501 b and 502b are preferably in the relative order specified in the IEEE 802.11 specification. The order of fields 503a and 504a, and of Elements inside fields 505a, 504b and 505b is not limited to the order depicted in the Figure and it can be shuffled in any order. Fields 502a, 503a, 504a, 502b, and 503b may be virtual fields shown for explanation purposes and those may not be physical fields clearly defined in the real frame formats.

[0121] If the context information is too large to fit inside one Context Container element (the maximum size of the element is 256 octets excluding Element ID field 307 and Length field 308), two or more Context Container element can be provided in one management frame.

[0122] As for Figure 4, an identifier of the non-AP station (e.g., STA ID field 506a) is added in association with the elements provided, for the TAPs to be able to use them when the non-AP station roams to them.

[0123] Fourth embodiments are shown in Figure 6 in which the management frame includes, in its frame body, a sequence of elements including a first element and elements that respectively include the context items, wherein the first element includes a list of element identifiers to identify the elements of the context items within the sequence of elements. In other words, the support elements having context information are mixed with other elements in Elements 305, and the first element is used to identify those elements having context information within Elements 305.

[0124] In the Figure, the first element is named “Context ID” element 601 . The name of the Context ID element is one an example and any other names, e.g. Context Identifier element, Context Transfer Identifier element, Context Information Identifier element, etc., can be used.

[0125] Elements 305 contains both Compatible elements 401 and Incompatible elements 402 as defined above.

[0126] Context ID element 601 is supported (i.e., recognized and compatible) by both transmitter and receiver STAs. Therefore, it is included in Compatible elements 401 .

[0127] Context ID element 601 contains a list of Element IDs of the elements which includes the context information of the non-AP station, that aids the seamless roaming. In details, Context ID element 601 consists of Element ID field 307, Length field 308, Element ID Extension field 309 and Information field 310 as the normal Element format.

[0128] Element ID field 307 and Element ID Extension field 309 are set to specific values, not yet assigned in the latest IEEE 802.11 specification, to dedicatedly signal this new Context ID element (e.g. 255 for Element ID field 307 and 145 - or above up to 255 - for Element ID Extension field 309). Length field 308 indicates the number of octets in the element excluding the Element ID field 307 and Length field 308.

[0129] Information field 310 contains STA ID field 506a and a list 603 of Element IDs of the elements which include the context information of the non-AP station, those elements being any element of Other elements 602 in Compatible elements 401 and / or any element of Incompatible elements 402. Compared to the previous embodiments, the new element, Context ID element 601 , only comprises Element IDs and not the support elements.

[0130] For illustrative purposes, Element ID 1 604 is included in list 603 to signal that Element 1 606 (here in Compatible elements 401) contains context information of the non-AP station. Similarly, Element ID M+1 605 is included in list 603 to signal that Element M+1 607 (here in Incompatible elements 402) contains context information of the non-AP station.

[0131] By referring to the Context ID element 601 , the receiver STA can easily identify which element includes context information for a given non-AP station.

[0132] This format also reduces the overhead of the management frame by avoiding duplication of the elements which contains context information.

[0133] The order of fields 401 and 402, 601 and 602, and of Elements inside fields 402, 602 and 603 is not limited to the order depicted in the Figure and it can be shuffled in any order. Fields 401 , 402 and 602 may be virtual fields shown for explanation purposes and those may not be the physical fields clearly defined in the real frame formats.

[0134] As for the previous embodiments, an identifier of the non-AP station is added in association with the Context ID element 601 provided, for the TAPs to be able to use them when the non-AP station roams to them.

[0135] To be noted that multiple Context ID elements provided in association with multiple respective IDs of non-AP stations make it possible to provide, within a single management frame, the support elements of the plurality of non-AP stations.

[0136] The above embodiments particularly apply to context items that describe capabilities of the non-AP station.

[0137] Other types of context information may be beneficial to seamless roaming. For example, some context information can be parameters or information set for the non-AP station by exchanging the one or more Action frames with the SAP. This is the case of negotiations of communication parameters conducted between the non-AP station and the SAP, that may be reused in communications with other APs. The Block Ack Parameter Set field negotiated with the ADDBA Request Response Action frame exchange is an example.

[0138] Also, the non-AP station may be able to exchange Action frames that are not recognized by the SAP but may be of interest to compatible TAPs to ease seamless roaming (meaning the Action frames include some context information).

[0139] To fully transfer such kind of context information from the non-AP STA to TAPs through the SAP, Action frame bodies could also be taken into account as context items or as elements in element-based embodiments. One embodiment is that even if the SAP does not recognize or support the Action frame (i.e. , does not recognize or support the category value, which is indicated in the Category field, of a received action frame), the SAP may store the Action frame body of the received Action frame as context information and transfer it to the TAPs. If one or more TAPs receiving this context information is able to recognize or support this Action frame body, the TAP can utilize this information as context information to improve the seamless roaming performance.

[0140] In this respect, fifth embodiments are shown in Figure 7 in which, as for Figure 5a, the management frame includes, in its frame body, a top-level container element whose Information field contains the context items, which are in this case Action frame bodies.

[0141] In the Figure, the top-level container element is named Context Container Action element 700. Of course, this name is only an example and any other names - e.g., Context Action element, Context Transfer element, Context Information element, etc. - can be used.

[0142] Context Container Action element 700 is included in Elements 305 and contains all the Action frame bodies (including both Compatible and Incompatible ones with respect to the capabilities of the transmitter and receiver STAs) that the transmitter STA wants to transmit as context information of the non-AP station, to aid the performance of seamless roaming.

[0143] Context Container Action element 700 consists of Element ID field 307, Length field 308, Element ID Extension field 309 and Information field 310 as the normal Element format.

[0144] Element ID field 307 and Element ID Extension field 309 are set to specific value, not yet assigned in the latest IEEE 802.11 specification, to dedicatedly signal this new Context ID element (e.g. 255 for Element ID field 307 and 146 - or above up to 255 - for Element ID Extension field 309).

[0145] Length field 308 indicates the number of octets in the element excluding the Element ID field 307 and Length field 308.

[0146] Information field 310 contains STA ID field 506a, Compatible Action frames 703 (i.e., recognized by both the transmitter and receiver STAs) and Incompatible Action frames 704 (i.e., at least not recognized by one of the two STAs). Both Compatible Action frames 703 and Incompatible Action frames 704 consists of zero or more Action frame bodies as shown in 705 and 706 respectively. Action frame bodies 705 included in Compatible Action frames 703 are compatible (i.e., recognizable or supported) Action frame bodies to both transmitter and receiver STAs. Action frame bodies 706 included in Incompatible Action frames 704 are incompatible (i.e., not recognizable or unsupported) Action frame bodies to the transmitter STA or the receiver STA. Each Action frame body included in 705 and 706 may include Length field information to indicate the length of each Action frame body.

[0147] The order of fields 700 and 701 , 703 and 704 are not limited to the order depicted in the figure and it can be shuffled in any order. Fields 703 and 704 may be virtual fields shown for explanation purposes and those may not be the physical fields clearly defined in the real frame formats.

[0148] As for the above embodiments, an identifier of the non-AP station (e.g., STA ID) is added in association with the elements provided, for the TAPs to be able to use them when the non-AP station roams to them.

[0149] To be noted that Context Container Action element 700 for the Action frame bodies can be used together with any of the above embodiments of Figure 4, 5a, 5b and 6 for the supported capabilities of the non-AP station. For example, in that case, the management frame includes, in its frame body, a first top-level container element 501 a, 501 b, 601 whose Information field contains one or more context items describing one or more capabilities of the non-AP station not supported by one of the stations exchanging the management frame or a list of element identifiers to identify the context items within a sequence of elements provided in the frame body, and includes a second top-level container element 700 whose Information field contains a body of one or more Action frames exchanged between the non-AP station and the SAP that are not recognized (i.e., supported) by one of the stations exchanging the management frame. The second top-level container element 700 may also include one or more Action frames exchanged between the non-AP station and the SAP that are recognized (i.e., supported) by the stations exchanging the management frame (the Compatible Action frame bodies).

[0150] Sixth embodiments are shown in Figure 8 in which the management frame is an Action frame and include one Action field to contain the context items. An Action field in the meaning of the 802.11 standards is made of a Category field and an Action Details field.

[0151] The frame may be named Context Container Action frame, although this name is only an example and any other names such as Context Action frame, Context Transfer Action frame, Context Information Action frame, etc. can be used. For appropriate signalling, Context Container Action frame is compatible to both transmitter and receiver STAs.

[0152] Context Container Action frame 300 contains all the Action frame bodies (including both compatible and incompatible ones) that the transmitter STA wants to transmit as context information, to aid the performance of seamless roaming.

[0153] Frame body 302 of the Context Container Action frame consists of Action field 800 and other fields 801 , complying with the normal Action field format defined in the IEEE802.11 specification.

[0154] Action field 800 consists of Category field 802 and Action Details field 803. The value of the Category field 802 can be set to a specific value, which is not yet assigned in the latest IEEE 802.1 1 specification, to dedicatedly signal this new Context Container Action frame (e.g. value 125). Action Details field 803 contains STA ID field 506a, Compatible Action frames 703 and Incompatible Action frames 704 described above.

[0155] 801 field may be extended to have additional elements such as Context Container element introduced in Figure 5a or 5b to transmit both context information of the Action frame bodies and context information of the support elements within one Action frame. In this case, the Action frame includes one Action field 800 to contain the body of one or more Action frames exchanged between the non-AP station and the SAP that are not recognized (i.e., supported) by one of the two stations exchanging the Action frame, and includes a top-level container element 501 a, 501 b whose Information field contains one or more context items describing one or more capabilities of the non-AP station not supported by one of the stations exchanging the Action frame. Figure 9 illustrates, using a timeline, exemplary communication methods involving one or more management frames to perform seamless roaming, according to some embodiments of the disclosure. Not all the messages (e.g. Authentication frames or four-way handshake) between the stations are explicitly shown in the figure. Furthermore, a Controller (not shown in the figure) can intermediate the messages between SAP1 and TAPs. In such case, the Controller may decide which context should be transferred to which TAPs instead of SAP1 .

[0156] Corresponding to Initial Association 201 , STA1 performs the first association procedure with one of the APs inside the seamless roaming domain 100: SAP1 . STA1 may send Probe Request 901 to probe potential APs and may receive Probe Response from APs which received the Probe Request and are able to respond to it. In this scenario, SAP1 responds with Probe Response 902. In Probe Response 902, SAP1 provides its capability information by including elements in the frame. For example, as shown in Figure 2, SAP1 includes elements to signal its UHR support such as the UHR Capabilities element and the UHR Operation element, and it may include elements corresponding to mechanism A and Vendor Y. Of course, other ways exist to have knowledge of the AP’s capabilities, e.g., by receiving their Beacon frames that also may include the capabilities elements.

[0157] If STA1 decides to associate to SAP1 , STA1 sends Association Response 903 to SAP1. Next, SAP1 responds with Association Response 904 indicating the result of the Association Request. If the result is success, the association between STA1 and SAP1 is established.

[0158] A management frame for Initiate Seamless Roaming 905 can be sent optionally to activate the seamless roaming mechanism at STA1 level. This can be a new Action frame (i.e. , not yet defined in the 802.11 standards) or can be an existing Action frame such as a Link Reconfiguration Notify frame or a Link Reconfiguration Request frame. Alternatively, it may be an Authentication frame or any Action frame used for the FT protocol. Yet alternatively, the activation can be explicitly signalled inside Association Request 903 using a dedicated element, in order to reduce overhead. The “seamless roaming activation” frame or dedicated element can be omitted to further reduce overhead when the seamless roaming mechanism is activated by default in the BSS of SAP1 and / or in the roaming domain 100.

[0159] Turning now to the signalling of STA1 ’s context information from STA1 to SAP1 , a preferred frame to attach the support elements containing context information (context items describing features supported by the SAP and context items describing features not supported by the SAP) is Association Request 903. However, the disclosure is not limited to this frame and Probe Request 901 or any management (Authentication, Reassociation Request or Action) frame for Initiate Seamless Roaming 905 can be used. Any embodiment described above with reference to Figures 4, 5a, 5b and 6 can be used to provide the supported features or capabilities of STA1 to SAP1 , including those that SAP1 does not support. Here, the Compatible elements are those corresponding to features supported by both STA1 and SAP1 , whereas the Incompatible elements are those corresponding to features supported by STA1 but not by SAP1 . SAP1 may respond with a management (Probe Response, (Re)Association Response, Authentication or Action) frame to acknowledge the reception of the context information. In some embodiments, the receiver station may indicate an acceptance status (e.g. accept or not) of the context information, which may, in turn, accept or reject the association. For example, the receiver side may reject the declared context information as it does not suit it (via a status code such as INVALID CONTEXT), and due to that, reject the Authentication or Association.

[0160] SAP1 obtains the context information of SAT1 via one of these management frames and can then perform Context transfer 920 to one or more TAPs. In this sequence, SAP1 decides to send the context information of STA1 to TAP1 and TAP2 in order for the latter to prepare any roaming of STA1 in a seamless fashion. Context transfer 920 can be done through wireless communication or wired communication. For wireless communication, management frame such as an Action frame can be sent from SAP1 to any TAP including the context items of STA1 as explained in Figures 4, 5a, 5b and 6. Here, the Compatible elements are the context items corresponding to features supported by both SAP1 and TAP, whereas the Incompatible elements are those corresponding to features not supported by one of SAP1 and TAP. For wired communication, the frame format can be different from the ones shown in Figures 4, 5a, 5b and 6. However, the contents should be the same including both Compatible elements of STATs context information and Incompatible elements among the transmitter STA (SAP1) and receiver STA (TAP). For example, the frame itself or the extracted context information can be encapsulated inside a frame format which is compliant to the wired connection (e.g. Ethernet, IEEE1905, etc.). Note that Context transfer 920 can further include transfer between TAPs.

[0161] Furthermore, Context transfer 920 may include any useful information regarding negotiated parameters between STA1 and SAP1 that can be reused with the TAPs in case of roaming. These are also context information and may be provided in context items (support elements or Action frame bodies) as explained in Figures 7 and 8.

[0162] In some embodiments, a cooperation between the APs (more generally in the roaming domain 100) can be implemented in order to building a list of candidate TAPs from the plurality of APs based on the transferred context information for STA1 . The creation of the candidate TAP list is shown by reference 921 . The context information transferred in 920 can be used to create the candidate TAP list. TAPs can evaluate the contents of the transferred context information - including STATs capabilities - to calculate a roaming score of each candidate TAP based on the transferred context information and supported features of the candidate TAP in order to show how good each TAP is as a roaming candidate.

[0163] Thanks to the new features of the present disclosure, SAP1 transfers to TAPs context information including Incompatible context items that SAP1 cannot recognize, whereas the TAPs are able recognize those context items if they are compatible with. As a result, the TAPs have more relevant context information to evaluate their “matching” with STA1 . The candidate TAP list may be created in a logical entity which exists inside the seamless roaming domain 100. It can be physically deployed in one of the APs inside the seamless roaming domain 100 or can be in any other physical device such as a separate controller. Candidate TAP list creation 921 can be done through wireless communication or wired communication. For wireless communication, management frames such as Action frames can be exchanged between the APs and the controller (not shown) if it is involved.

[0164] The candidate TAP list may be sent to STA1 with a management frame 906. In this frame, the list may be an ordered list of candidate target AP stations in order to ease any selection of a TAP by STA1 . The candidate TAP list may include information that indicates each TAP’s compatibility (e.g., roaming score) and / or additionally some preliminary negotiation result that each TAP can have made in advance considering the context information of STA1 as received. This frame 906 can be a new Action frame or any existing Action frame. For example, Context Container element 501 a, 501 b and / or Context Container Action element 700 can be attached to the Action frame to transmit the compatible context information and / or the preliminary negotiation results as made in advance by the TAPs for STA1 , which are transferred via SAP1 . Such preliminary negotiation result can be indicated as it is indicated in the Action frame responding to the requested Action frame (e.g., ADDBA Response Action frame responding to the request of ADDBA Request Action frame). A signalling through an Action frame body (Figures 7 and 8) can be used. Dialog Token field value inside the Action frame body can be used to identify the correspondence between the Response frame and the Request frame.

[0165] If a TAP appears to be more compatible with and more acceptable to STA1 (given its context information), STA1 may consider that this TAP is a good candidate for the next roaming target.

[0166] After the association procedure and the initiation of seamless roaming, STA1 may optionally send further context information to SAP1 , by including it in any Action frame 907. This can be updates of the context information sent previously for STA1 or some new context information added. SAP1 may respond with an Action frame 908 to acknowledge their reception and may indicate the acceptance status (e.g. accept or not). Upon receiving the updates or additional context information, SAP1 may trigger Context transfer 922 (as previously described). This may further trigger updating the candidate TAP list as shown in 923 and sending the updated candidate TAP list to STA1 as shown in 909.

[0167] STA1 sends Roaming Execution frame 910 when it decides to roam to one of the TAPs, e.g., a TAP selected from the candidate TAP list based on the roaming scores.

[0168] STA1 may directly send a management frame to the TAP or it may send the management frame to SAP1 that forwards it to the TAP with possibly additional context information (e.g., updates). This management frame may be a new Action frame or an existing Management frame such as a Link Reconfiguration Request frame or a Reassociation Request frame. Frame 910 may also include context information as explained in Figures 4, 5a, 5b, 6, 7 and 8. Such context information can be updates of the context information sent previously or some new context information added.

[0169] TAP may send Roaming Response frame 911 to acknowledge the reception of the roaming indication and may indicate the acceptance status (e.g. accept or not). This frame may include which context information of STA1 is compatible with the TAP is compatible and / or acceptable to it, and thus can be used to improve the performance of the established connection between STA1 and the TAP. For example, showing the support of Post-UHR generation or the support of mechanisms A and B by TAP1 can be indicated here and the Post-UHR generational communication or the communication using the mechanisms A and B can be performed seamlessly after the roaming procedure. The preliminary negotiation results made in advance by the TAP can also be indicated in Roaming Response frame 911 so that the connection between STA1 and the TAP starts with those negotiation already done. Such negotiation result can be indicated as it is indicated in the Action frame responding to the requested Action frame (e.g. ADDBA Response Action frame responding to the request of ADDBA Request Action frame). Dialog Token field value inside the Action frame body can be used to identify the correspondence between the Response frame and the Request frame.

[0170] Figure 10 illustrates, using a flowchart, general steps at a transmitter STA generating and transmitting frames which include context information of a non-AP station, according to embodiments. The signalling of the context information in the frames may use any format as described in the embodiments above.

[0171] Transmitter STA can be the non-AP station STA1 , or any AP such as SAP1 or a TAP, that transmits the context information of the non-AP station STA1 to a receiver STA.

[0172] The flowchart concentrates on the steps regarding the context information transmission. It does not describe how to generate existing fields such as MAC Header 301 , FCS 303, Fields that are not elements 304 and the Elements without context 404 etc., which are generated as specified in the IEEE 802.11 specification.

[0173] A transmitter STA starts the flowchart of Figure 10 when it has context information of STA1 that it wants to send to a receiver STA.

[0174] For STA1 , it can be during the initial association procedure (exchanges 901 , 903 and 905 in Figure 9), during addition or update of the context information as in exchange 907, during roaming execution 910.

[0175] For SAP1 or any TAP, it can be Context transfer 920, 922 or 910. SAP1 , as transmitter STA, may identify the ID of STA1 using the TA field inside the MAC Header of the management frame received from STA1 , or using STA ID field 506a of the corresponding frame format. Any TAP may identify the ID of STA1 using STA ID field 506a of the management frame received from another AP.

[0176] At preliminary step 1000, the transmitter STA identifies which context information of STA1 the transmitter STA wants to transfer. This step may be optional when the context information for STAI is predefined. Context information may include mandatory and optional context information. Step 1000 selects the mandatory context information. In addition, the transmitter STA may select some optional context information for STA1 , if it wants to send it, or may not select them for any reason.

[0177] Some sets of context items for STA1 may be defined, one of which is selected by the transmitter STA. As an example, there may be multiple Vendor specific contexts and the transmitter STA selects a specific context given a Vendor of STA1 .

[0178] Still at step 1000, the transmitter STA obtains the desired context information of STA1 . STA1 internally obtains its context information, while SAP1 or a TAP may obtain them from a management frame received from a transmitter STA as transmitted using e.g. the flowchart of Figure 10. The TA field or STA ID field 506a allows the transmitter STA to recognize that the received context items are those of STA1 .

[0179] At optional step 1001 , the transmitter STA obtains receiver STA’s supported features, in particular its capabilities for recognizing some context information. For STA1 , this can be obtained during the initial association procedure, from the Capabilities elements declared by SAP1 in its Beacon frames or in the Probe Response 902 or Association Response 904. For SAP1 or TAPs, this can be done by any means; for example, a frame exchange between the APs or information provided by another device such as a controller which manages all the APs information may be implemented. If this is done in an IEEE 802.1 1 (wireless) frame exchange, Management frames such as Beacon frames, Probe Request / Response frames, Authentication frames, (Re)Association Request / Response frames, or Action frames can be used to achieve this. The receiver STA’s supported features (e.g., capabilities) can be alternatively exchanged via the wired communication or by any other means.

[0180] At the end, the transmitter STA knows the features supported by itself and those supported by the receiver STA.

[0181] At step 1002, based on the information obtained at steps 1000 and 1001 , the transmitter STA generates a frame to convey the context information of STA1 .

[0182] If the frame format of Figure 4 is used, the transmitter STA includes all the identified (in step 1000) context items of STA1 inside Elements 305, regardless of which ones can be recognized by the transmitter and / or receiver STAs (i.e. , Compatible and Incompatible elements).

[0183] If the frame format of Figure 5a or 5b is used, the transmitter STA includes the identified (Incompatible and optionally Compatible) context items of STA1 inside Context Container element 501 a, 501 b. Figures 11a and 11 b show how the transmitter STA proceeds in this case to organize the context items in Context Container element 501 a, 501 b and Other elements 502a, 502b.

[0184] If the frame format of Figure 6 is used, the transmitter STA includes all the support elements for STA1 inside Elements 305 and additionally creates Context ID element 601 to reference which elements in Elements 305 contains the identified context items of STA1 . Context ID element 601 contains the list of element IDs corresponding to those context items. If Action frame bodies are transmitted using the frame format of Figure 7 or 8, the transmitter STA includes all the Action frame bodies in Context Container Action element 700 of the management frame or in Action field 800 of the Action frame, including both compatible and incompatible ones. Figures 12a and 12b show how the transmitter STA proceeds in this case to organize the Action frame bodies in Context Container Action element 700 and Action Details 803.

[0185] As some of these formats do not distinguish whether a context item is compatible or incompatible among the transmitter STA and the receiver STA, optional step 1001 may be omitted. However, in the case of Figure 5b for example, the transmitter STA may obtain the capabilities supported by the receiver STA (e.g., via Beacon frames or Probe Response frames or Association Response frames) and classify the supported features of STA1 in the context information into, on one hand, context items describing capabilities also supported by the receiver STA (e.g., Compatible elements) and, on the other hand, context items describing capabilities not supported by the receiver STA (e.g., Incompatible elements).

[0186] At step 1003, the transmitter STA sends the frame so generated to the receiver STA over a wireless or wired connection.

[0187] Figures 11a and 11 b illustrate, using flowcharts, steps at the transmitter STA generating frames with Context Container element as context information according to embodiments. Figure 11a corresponds to the flow inside step 1002 for a transmitter STA using the frame format of Figure 5a while Figure 11 b corresponds to the flow inside step 1002 for a transmitter STA using the frame format of Figure 5b. The process is performed for each element of STA1 to be inserted in the frame.

[0188] During frame generation step 1002, at test 1000a and 1000b, the transmitter STA determines whether the element includes context information of STA1 or not (based on the outcome of step 1000), i.e., whether it is a context item or not. If not, it proceeds to step 1001 a and 1001 b respectively and it does not include the element in Context Container element 501 a, 501 b, but includes it in Other elements section 502a and 502b.

[0189] Otherwise (element contains Context information), for Figure 11a, it goes to step 1102a where it includes or copies the element in Context Container element 501 a. If the transmitter STA prefers to copy the element (rather than including it without copy), it also includes the element in Other elements 502a. If the transmitter STA prefers not to copy the element, it only includes the element in Context Container element 501 a.

[0190] For Figure 11 b, it goes to test 1103b where it determines whether the element is compatible among the transmitter STA and the receiver STA. This determination can be based on the transmitter STA’s supported features and the receiver STA’s supported features as obtained at step 1001 . In the affirmative of test 1103b (Compatible element), it goes to step 1 101 b and do not include the element in Context Container element 501 b, but includes it in Other elements section 502b since it is compatible with the receiver STA. Otherwise, it goes to step 1102b where it includes the element in Context Container element 501 b. Figures 12a and 12b illustrate, using flowcharts, steps at the transmitter STA generating frames with Action frame bodies as context information according to embodiments. Figure 12a corresponds to the flow inside step 1002 for a transmitter STA using the frame format of Figure 7 while Figure 12b corresponds to the flow inside step 1002 for a transmitter STA using the frame format of Figure 8. The process is performed for each Action frame body to be inserted in the frame.

[0191] During frame generation step 1002, at test 1200a and 1200b, the transmitter STA determines whether the Action frame body includes context information of STA1 or not (based on the outcome of step 1000). If not, the process ends. Otherwise, it goes to step 1201 a or step 1201 b respectively, where the transmitter STA includes the Action frame body in Context Container Action element 700 or in Action Details 803 respectively, as one Compatible element 705 or Incompatible element 706 depending on the compatibility of the transmitter and receiver STAs with respect to the feature described by the element.

[0192] Turning now to the receiver side, Figure 13 illustrates, using a flowchart, general steps at a receiver STA receiving the management frame which includes context information of STA1 , according to some embodiments. The signalling of the context information in the frames may use any format as described in the embodiments above.

[0193] Receiver STA can be SAP1 or any TAP, that receives the context information of STA1 from a transmitter STA.

[0194] The flowchart concentrates on the steps regarding the context information reception. It does not describe how to parse existing fields such as MAC Header 301 , FCS 303, Fields that are not elements 304 and the Elements without context 404 etc. , which are parser and processed as specified in the IEEE 802.11 specification.

[0195] A receiver STA starts the flowchart of Figure 13 when it receives a specific frame that contains context information. The receiver STA can obtain the features (e.g., capabilities) supported by the transmitter STA that sends the frame to the receiver STA during the association procedure between STA1 and SAP or during a capability exchange between APs.

[0196] Capability of seamless roaming feature may be indicated as one of the capabilities and knowing this, the receiver STA can know that the specific transmitter STA is capable of seamless roaming or not. If the transmitter STA is capable of seamless roaming, the frames from the transmitter STA may contain context information. For the frames in the wireless connection, at least Management frames may contain contexts in one embodiment. The capability of seamless roaming may be implicitly indicated by other capability information (e.g. UHR capable STAs are capable of seamless roaming feature).

[0197] At step 1300, the receiver STA extracts the context information (e.g., of STA1) from the received frame. The identifier of the STA1 is extracted from the TA field of the MAC Header or from STA ID field 506a contained in the received frame.

[0198] If the frame format of Figure 4 is used, the receiver STA extracts all the context items - i.e., support elements having context information - of STA1 from inside Elements 305. Figure 14 shows how the receiver STA proceeds in this case to parse the support elements from

[0199] Elements 305.

[0200] If the frame format of Figure 5a or 5b is used, the receiver STA extracts the (Incompatible and optionally Compatible) context items of STA1 from Context Container element 501 a, 501 b. Figures 15a and 15b show how the receiver STA proceeds in this case to parse the support elements from Context Container element 501 a, 501 b and Other elements 502b.

[0201] If the frame format of Figure 6 is used, the receiver STA parses the elements in Elements 305 and extracts those containing context information (hence context items) thanks to the list contained in Context ID element 601 that references which elements in Elements 305 contains the context information of STAI . Figure 16 shows how the receiver STA proceeds in this case to parse the support elements in Elements 305 based on the identifiers listed in Context ID element 601 .

[0202] If Action frame bodies are conveyed using the frame format of Figure 7 or 8, the receiver STA extracts all the Action frame bodies (hence context items) from Context Container Action element 700 of the management frame or from Action field 800 of the Action frame, including both compatible and incompatible ones. Figures 17a and 17b show how the receiver STA proceeds in this case to parse Context Container Action element 700 and Action Details 803.

[0203] Next, at step 1301 , the receiver STA stores the context items of STA1 as extracted at step 1300, preferably together with an identifier of STA1 (e.g. the value retrieved from STA ID 506a).

[0204] At step 1302, the receiver STA optionally transfers the context information of STA1 stored at step 1301 if the receiver STA determines that it is useful to further transfer the context information of STA1 to one or more TAPs. For example, the context information may be transferred to all TAPs of the candidate TAP list that have the “highest” roaming scores (given a threshold or a predefined number of TAPs)

[0205] Step 1302 triggers the flowchart of Figure 10 inside the receiver STA, now acting as a transmitter STA to send (here transfer) the context information of STA1 to another receiver STA (here TAP). One understands that the compatibilities between the receiver STA and the STA receiving the Context transfer is different from the compatibilities between the transmitter STA and the receiver STA. Hence, Compatible elements between the transmitter STA and the receiver STA may become Incompatible elements between the receiver STA and the STA addressee of the Context transfer (and vice versa). In this respect, the receiver STA has to reorganize the obtained context items of STA1 into, on one hand, the context items describing features not supported by itself and an AP station addressee of the transfer, and, on the other hand, the context items describing features supported by both itself and the addressee AP station.

[0206] At step 1303, the receiver STA uses the Context information of STA1 as stored at step 1301. This step can be executed in several timings.

[0207] For example, it can be used to improve the seamless roaming performance when STA1 executes a roaming to the receiver STA, which corresponds to operation 910 in Figure 9. The identification of STA1 can be done by comparing the identification information stored at step 1301 with the identification information received in the Roaming execution frame 910.

[0208] As another example, it can be used to create the Candidate or Update AP list, which corresponds to operation 921 or 923 in Figure 9.

[0209] In some embodiments, the receiver STA, in particular SAP1 , may obtain additional Context information of STA1 to those included in the management frame sent by STAI . For example, the setting of the communication between STA1 and SAP1 may involve the setting of some communication parameters that could be reused by the TAPs in case of roaming as STA1 is already configured with these parameters. An example already mentioned above is the Block Acknowledgment parameter negotiated between the non-AP station and the SAP. In this respect, the receiver STA may perform the following operations: setting one or more communication parameters of the non-AP station by exchanging at least one Action frame with the non-AP station, and transferring (i.e., sharing) context information of the non-AP station to one or more TAPs, wherein the context information includes the body of the Action frame to communicate the one or more communication parameters of the non-AP station to the one or more TAPs.

[0210] More generally, the SAP may decide, independently to the context items provided by STA1 , to share communication parameters of STA1 negotiated between them. This is illustrated below with reference to Figure 19.

[0211] The frame format of Figures 7 and 8 may be used to transfer the Action frame bodies. In embodiments, Context Container Action element 700 is combined with the elements of Figures 4, 5a, 5b or 6 to combine the provision, within the same frame to the TAP, of the supported capabilities of STA1 (as stored at step 1301) and negotiated communication parameters.

[0212] Figure 14, 15a, 15b, 16, 17a and 17b illustrate, using flowcharts, steps at the receiver STA extracting context information from a received frame, according to embodiments. These figures correspond to the flows included in step 1300 of Figure 13 for the various frame formats that are contemplated. The retrieval of the identifier of STA1 from the frame is not illustrated in these flowcharts. It is however performed by parsing the TA field or STA ID field 506a of the received frame.

[0213] The flow of Figure 14 is repeated for each element until all of the elements included in the received frame are processed.

[0214] At test 1400, the receiver STA determines whether the element is supported by the receiver STA or not. If not, it goes to step 1402 where it extracts the element as context information. This means that the receiver STA treats all of the unsupported elements as elements which may include context information (i.e., as context items). Otherwise, it goes to test 1401 where the receiver STA determines whether the element includes context information or not. Here, as the receiver STA supports the element, it can recognize whether the element contains context information or not (the receiver STA knowing which information is context information, e.g. in the same way as the transmitter STA at step 1000). In the affirmative, it goes to step 1402 where the receiver STA extracts the element as context information. Otherwise, it goes to step 1403 where the receiver STA does not extract the element as context information.

[0215] The flows of Figure 15a and 15b are repeated for each element until all of the elements included in the received frame are processed.

[0216] At test 1500a and 1500b, the receiver STA determines whether the element is a Context Container element or not. This can be done by scrutinizing the value of Element ID field 307 whether it is identical to the value assigned for a Context Container element or not.

[0217] In the affirmative, it goes to step 1501 a and 1501 b where it extracts the element as context information.

[0218] Otherwise, in Figure 15a (when using the frame format of Figure 5a), it goes to step 1502a where it does not extract the element as context information. In Figure 15b (when using the frame format of Figure 5b), it goes to test 1503b where it determines whether the element includes context information or not (similar to step 1401 above). In the affirmative, it goes to step 1501 b where it extracts the element as context information. Otherwise, it goes to 1502b where it does not extract the element as context information.

[0219] The flow of Figure 16 (when using the frame format of Figure 6) starts once and the steps after step 1603 are repeated for each element in Other elements 602 of Compatible elements 401 and in Incompatible elements 402.

[0220] At step 1600, the receiver STA starts searching for the Context ID element. It may consist in parsing the elements until finding the one having its Element ID field 307 and Element ID Extension field 309 set to the dedicated values, inside the received frame, via test 1601 on the elements being parsed.

[0221] At test 1601 , if the Context ID element is not found, it goes to step 1608 where the element is not extracted as context information.

[0222] Otherwise, if the Context ID element is found, it goes to step 1602 and parses the Context ID element to extract the element IDs of the list of Element IDs 603 at step 1603. Next, step 1604 to step 1607 are applied for each element included in the received frame except the Context ID element. At step 1604, the receiver STA starts parsing the elements in Other elements 602 of Compatible elements 401 and in Incompatible elements 402. At test 1605, the receiver STA determines whether the element is referenced in the list of Context ID element identified at step 1602. In the affirmative, it goes to step 1606 where it extracts the element as context information. Otherwise, it goes to step 1607 where it does not extract the element as context information.

[0223] The flow of Figure 17a (when using the frame format of Figure 7) is repeated for each element until all of the elements included in the received frame are processed. Attest 1700a, the receiver STA identifies whether the element is Context Container Action element 700 or not. This can be done by checking whether the value of Element ID field 307 is identical to the value assigned for the Context Container Action element or not. In the affirmative, it goes to step 1701 a where it extracts the Action frame bodies 705, 706 included in Context Container Action element 700 as context information. Otherwise, the process ends.

[0224] The flow of Figure 17b (when using the frame format of Figure 8) starts if the receiver STA identifies that the received frame is a Context Container Action frame, at test 1700b. The receiver STA can identify this kind of frame merely by parsing the Category field value shown in Category field 802, and determining whether it is identical to the value assigned for the Context Container Action frame or not. In the affirmative, it goes to step 1701 b where it extracts the Action frame bodies 705, 706 included in the Action Details 803 as context information. Otherwise, the process ends.

[0225] Figure 18a and Figure 18b illustrate exemplary signalling of features supported by STA1 in the management frames sent from each transmitter STA to each receiver STAs on top of Figure 2, according to some embodiments of the disclosure.

[0226] Figure 18a relies on the frame format of Figure 5b: Context Container element 501 b excluding the Compatible elements is used.

[0227] In this case, as shown in 1801 a, STA1 attaches its supported features that are compatible with SAP1 (hence Compatible elements such as the UHR Capabilities element and the Mechanism A element) outside the Context Container element 501 b, in Other elements 502b, and STA1 attaches its supported features that are incompatible with SAP1 (hence Incompatible elements such as the Post-UHR Capabilities element, the Mechanism B, C elements, Vendor X element) inside Context Container element 501 b. The management frame containing all these elements is sent to SAP1 . To do the above, STA1 performs the flow of Figure 10 (together with Figure 11 b).

[0228] SAP1 receives the frame and extracts the context information of STA1 using the flow of Figure 13 (together with Figure 15b). Next, SAP1 may transfer the context information of STA1 to TAP1 and / or TAP2 as shown through the compositions 1802a and 1803a. The context transfer corresponds to step 1302 which may involve one occurrence of the flow of Figure 10. In the example of Figure 18a, even though TAP1 supports Post-UHR generation, SAP1 includes the Post-UHR related element inside Context Container element 501 b as shown in 1803a since SAP1 cannot understand what the Post-UHR element is (hence it is an Incompatible element). With the same principle, the mechanism C element is included inside Context Container element 501 b in 1802a even if TAP2 supports C. The support elements that are compatible to both SAP1 and TAP1 (or TAP2) are inserted in Other elements 502b. This is the case of the UHR element for instance. The management frame containing all these elements is sent to TAP1 and / or TAP2.

[0229] In the same way, TAP1 receives the frame from SAP1 and extracts the context information of STA1 , reorganizes the support elements of STA1 in Compatible and Incompatible elements to form the management frame as shown in 1804a to be addressed to TAP2.

[0230] Figure 18b relies on the frame format of Figure 5b (as in Figure 18a) for STA1 and relies on the frame format of Figure 5a between the APs: Context Container element 501 a includes all the elements that contains context information (both the Compatible and Incompatible elements).

[0231] Nothing changes between STA1 and SAP1.

[0232] The difference with Figure 18a is that the management frames 1802b, 1803b, 1804b between the APs (e.g. between SAP1 and TAP1) include all the elements containing context information inside Context Container element 501 a.

[0233] Figure 19 illustrates embodiments where the SAP (AP station or MLD) decides, independently to the context items provided by the non-AP station or MLD, to share communication parameters of that non-AP station or MLD they have negotiated together by exchanging Action frames. Exemplary communication parameters include Block Acknowledgment (BA) agreements, Stream classification service + QoS Characteristics, Target Wake Time.

[0234] At step 1900, the SAP negotiates with the non-AP STA by exchanging at least one Action frame, to set one or more communication parameters of the non-AP STA. Multiple communication parameters can therefore be set for the non-AP STA that the SAP keeps in memory to properly communicate with the non-AP STA. In particular, the SAP may store the bodies of the Action frame that define the communication parameters.

[0235] At step 1901 , the SAP determines which ones of the communication parameters are worth to be shared with the TAPs.

[0236] Step 1901 may be triggered by the reception of a management frame from the non- AP STA providing some context items to be transferred to the TAPs.

[0237] Alternatively, it may be triggered by any event internal to the SAP.

[0238] A list of communication parameters to share may be predefined and / or provided by a Controller in the roaming domain. In variants, the non-AP STA may indicate to the SAP which parameters to share with the TAPs.

[0239] Once the communication parameters to share are known, the SAP retrieves the corresponding Action frame bodies stored at step 1900 and include them into Context Container Action element 700 or Action Details field 803 as compatible Action frame bodies or incompatible Action frame bodies depending on the compatibilities of the Action frame with the TAP. This is step 1902 where a frame is generated.

[0240] Note that Context Container Action element 700 or Action Details field 803 may be combined with any Context Container element 501 a, 501 b, Context ID element 601 in the same frame, to provide Capabilities element of the non-AP STA in addition to the Action frame bodies reporting communication parameters.

[0241] Next, at step 1903, the frame is sent to the TAP.

[0242] Figure 20a schematically illustrates a communication device 2000 configured to implement at least one embodiment of the present disclosure, for instance any of the (AP and non-AP) STAs shown in Figure 1. The communication device 2000 may preferably be a device such as a microcomputer, a workstation or a light portable device. The communication device 2000 comprises a communication bus 2013 to which there are preferably connected: a central processing unit 2001 , such as a processor, denoted CPU; a memory 2003 for storing an executable code of methods or steps of the methods according to embodiments of the invention as well as the registers adapted to record variables and parameters necessary for implementing the methods; and at least one communication interface 2002 connected to a wireless communication network, for example a communication network according to one of the IEEE 802.11 family of standards, via transmitting and receiving antennas 2004.

[0243] Preferably the communication bus provides communication and interoperability between the various elements included in the communication device 2000 or connected to it. The representation of the bus is not limiting and in particular the central processing unit is operable to communicate instructions to any element of the communication device 2000 directly or by means of another element of the communication device 2000.

[0244] The executable code may be stored in a memory that may either be read only, a hard disk or on a removable digital medium such as for example a disk. According to an optional variant, the executable code of the programs can be received by means of the communication network, via the interface 2002, in order to be stored in the memory of the communication device 2000 before being executed.

[0245] In an embodiment, the device is a programmable apparatus which uses software to implement embodiments of the invention. However, alternatively, embodiments of the present invention may be implemented, totally or in partially, in hardware (for example, in the form of an Application Specific Integrated Circuit or ASIC).

[0246] Figure 20b is a block diagram schematically illustrating the architecture of the communication device 2000, adapted to carry out, at least partially, the invention. As illustrated, device 2000 comprises a physical (PHY) layer block 2023, a MAC layer block 2022, and an application layer block 2021 .

[0247] The PHY layer block 2023 (here an 802.11 standardized PHY layer) has the task of formatting, modulating on or demodulating from any 20MHz channel or the common communication channel, and thus sending or receiving frames over the wireless radio medium used, such as 802.11 frames, for instance MAC data and management frames based on a 20MHz width.

[0248] The MAC layer block or controller 2022 preferably comprises a MAC 802.11 layer 2024 implementing conventional 802.11 be MAC operations, and additional block 2025 for carrying out, at least partially, the invention. The MAC layer block 2022 may optionally be implemented in software, which software is loaded into RAM 2003 and executed by CPU 2001 . Preferably, the additional block 2025, referred to as Seamless roaming managing module which has different operations to implement parts of the disclosure, depending on the role played by the communication device 2000.

[0249] MAC 802.11 layer 2024 and Seamless roaming Managing module 2025 interact one with the other in order to process accurately the seamless roaming procedure, e.g., to perform frame exchanges when appropriate according to embodiments.

[0250] On top of the Figure, application layer block 2021 runs an application that generates and receives data packets, for example data packets such as a video stream. Application layer block 2021 represents all the stack layers above MAC layer according to ISO standardization.

[0251] Although the present invention has been described hereinabove with reference to specific embodiments, the present invention is not limited to the specific embodiments, and modifications will be apparent to a skilled person in the art which lie within the scope of the present invention.

[0252] Many further modifications and variations will suggest themselves to those versed in the art upon referring to the foregoing illustrative embodiments, which are given by way of example only and which are not intended to limit the scope of the invention, that being determined solely by the appended claims. In particular the different features from different embodiments may be interchanged, where appropriate.

[0253] In the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. The mere fact that different features are recited in mutually different dependent claims does not indicate that a combination of these features cannot be advantageously used.

Claims

36CLAIMS1. A method of roaming a non-access point (non-AP) station (STA) or non-AP multilink device (MLD) associated with a source AP station or MLD (SAP) to a target AP station or MLD (TAP), comprising, at one of the stations or MLDs: obtaining context information of the non-AP station or MLD, and transferring the context information of the non-AP station or MLD to one or more AP stations or MLDs, wherein the context information includes one or more context items describing features not supported by the SAP.

2. The method of Claim 1 , wherein the context information further includes one or more context items describing features supported by the SAP.

3. The method of Claim 1 , wherein one or more of the context items are elements in the meaning of the IEEE802.11 series of standards.

4. The method of Claim 1 , wherein one or more of the context items describe one or more capabilities of the non-AP station or MLD.

5. The method of Claim 4, wherein the one or more capabilities of the non-AP station or MLD are not supported by the SAP.

6. The method of Claim 1 , wherein one or more of the context items include a body of one or more Action frames prepared by the non-AP station or MLD.

7. The method of Claim 6, wherein the one or more Action frame bodies define actions not recognized by the SAP.

8. The method of Claim 6, wherein the one or more Action frame bodies include one or more communication parameters set between the non-AP station or MLD and the SAP by exchanging the one or more Action frames.

9. The method of Claim 8, wherein the one or more communication parameters includes a Block Acknowledgment parameter negotiated between the non-AP station or MLD and the SAP.

10. The method of Claim 1 , wherein transferring the context information includes sending a management frame containing the context items.

11. The method of Claim 10, wherein the management frame is one from a (Re)Association Request frame, a Probe Request frame, an Authentication Request frame, an Action frame.

12. The method of Claim 1 , wherein the management frame includes, in its frame body, a top-level container element whose Information field contains the context items.3713. The method of Claim 12, wherein at least one of the context items contained in the top-level container element is duplicated next to the top-level container element.

14. The method of Claim 1 , wherein the management frame includes, in its frame body, a top-level container element whose Information field contains only the context items corresponding to features not supported by one of the stations or MLDs exchanging the management frame, and next to the top-level container element in the frame body, a plurality of elements including the context items corresponding to features supported by the stations or MLDs exchanging the management frame.

15. The method of Claim 14, wherein the management frame includes, in its frame body, a first top-level container element whose Information field contains one or more context items describing one or more capabilities of the non-AP station or MLD not supported by one of the stations or MLDs exchanging the management frame or a list of element identifiers to identify the context items within a sequence of elements provided in the frame body, and includes a second top-level container element whose Information field contains a body of one or more Action frames exchanged between the non-AP station or MLD and the SAP that are not recognized by one of the stations or MLDs exchanging the management frame.

16. The method of Claim 1 , wherein the management frame includes, in its frame body, a sequence of elements including a first element and elements that respectively include the context items, wherein the first element includes a list of element identifiers to identify the elements of the context items within the sequence of elements.

17. The method of Claim 1 , wherein the management frame is an Action frame and include one Action field to contain the context items.

18. The method of Claim 17, wherein the Action frame includes one Action field to contain a body of one or more Action frames exchanged between the non-AP station or MLD and the SAP that are not recognized by one of the stations or MLDs exchanging the Action frame, and includes a top-level container element whose Information field contains one or more context items describing one or more capabilities of the non-AP station or MLD not supported by one of the stations or MLDs exchanging the Action frame .

19. The method of Claim 1 , wherein an identifier of the non-AP station or MLD is provided in association with the context information.

20. The method of Claim 1 , further comprising calculating a roaming score of a candidate target AP station or MLD based on the transferred context information and supported features of the candidate target AP station or MLD.

21. The method of Claim 1 , further comprising building a list of candidate target AP stations or MLDs from a plurality of AP stations or MLDs based on the transferred context information.

22. The method of Claim 21 , wherein the list is an ordered list of candidate target AP stations or MLDs based on respective roaming scores calculated based on the transferred context information and supported features of each respective candidate target AP station or MLD.

23. The method of Claim 21 , further comprising sending the built list of candidate target AP stations or MLDs to the non-AP station.

24. The method of Claim 1 , further comprising obtaining features supported by the SAP, and classifying features of the non-AP station or MLD into, on one hand, context items describing features also supported by the SAP and, on the other hand, context items describing features not supported by the SAP, to form the context information.

25. The method of Claim 1 , further comprising reorganizing the context items of the obtained context information into, on one hand, the context items describing features not supported by the station or MLD and an AP station or MLD addressee of the transfer, and, on the other hand, the context items describing features supported by both the station or MLD and the addressee AP station or MLD.

26. A method of roaming a non-access point (non-AP) station or multi-link device (MLD) associated with a source AP station or MLD (SAP) to a target AP station or MLD (TAP), comprising, at the SAP: setting one or more communication parameters of the non-AP station or MLD by exchanging at least one Action frame with the non-AP station or MLD, and transferring context information of the non-AP station or MLD to one or more TAPs, wherein the context information includes the body of the Action frame to communicate the one or more communication parameters of the non-AP station or MLD to the one or more TAPs.

27. A wireless communication device comprising at least one microprocessor configured for carrying out the method according to any one of Claims 1 to 25.

28. A non-transitory computer-readable medium storing a program which, when executed by a microprocessor or computer system in a wireless device, causes the wireless device to perform the method according to any one of Claims 1 to 25.

Images